Re: Resurrect PowrPC SPE port feasible?
- Am 16. Sep 2024 um 15:24 schrieb David Edelsohn dje@gmail.com: > On Mon, Sep 16, 2024 at 9:15 AM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> - Am 16. Sep 2024 um 15:02 schrieb David Edelsohn dje@gmail.com: >> >> > On Sun, Sep 15, 2024 at 7:29 PM Sebastian Huber < >> > sebastian.hu...@embedded-brains.de> wrote: >> > >> >> Hello, >> >> >> >> the PowerPC SPE port was obsoleted in GCC 8. It was moved from the >> general >> >> PowerPC directory (gcc/config/rs6000) to a separate directory >> >> (gcc/config/powerpcspe). In GCC 9, it was removed due to a lack of >> >> maintenance. >> >> >> >> I am not a compiler expert, so I have no idea how much work it is to >> keep >> >> a back-end up to date. How much work would it be roughly to bring the >> >> PowerPC SPE port from GCC 8 to the current version? Is this in the >> range of >> >> person weeks, months, years? >> >> >> > >> > Why do you wish to resurrect the port? >> >> Some products using the PowerPC SPE are still in service for at least the >> next ten years. We probably have not enough funding to continuously >> maintain the port. I am looking for options to bring it back to GCC 15 > > > NXP did not have the financial motivation nor the will to maintain the > port. NXP was free-riding on the IBM team. Yes, this was not really a great move from Freescale/NXP. > > Without analysis, it's difficult to estimate the amount of work. A lot of > things in GCC between GCC 8 and GCC 15 -- both in the common parts of the > compiler and in the PowerPC port from which PowerPC SPE was split. GCC 15 > is an ambitious goal. Thanks for your estimate, ambitious sounds not that good. > > >> Maybe this is not the right mailing list for this work. >> > > This is an odd reply to a simple question. Sorry, maybe my subject was a bit misleading. My intention was not to bring back the PowerPC SPE port as an official mainline GCC port. We definitely don't have the funding for this. I was hoping to get in contact with an individual or a company which may help us to get it from GCC 8 to a newer version. > > David > > >> >> -- >> embedded brains GmbH & Co. KG >> Herr Sebastian HUBER >> Dornierstr. 4 >> 82178 Puchheim >> Germany >> email: sebastian.hu...@embedded-brains.de >> phone: +49-89-18 94 741 - 16 >> fax: +49-89-18 94 741 - 08 >> >> Registergericht: Amtsgericht München >> Registernummer: HRB 157899 >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler >> Unsere Datenschutzerklärung finden Sie hier: >> https://embedded-brains.de/datenschutzerklaerung/ -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: Resurrect PowrPC SPE port feasible?
- Am 16. Sep 2024 um 15:02 schrieb David Edelsohn dje@gmail.com: > On Sun, Sep 15, 2024 at 7:29 PM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> Hello, >> >> the PowerPC SPE port was obsoleted in GCC 8. It was moved from the general >> PowerPC directory (gcc/config/rs6000) to a separate directory >> (gcc/config/powerpcspe). In GCC 9, it was removed due to a lack of >> maintenance. >> >> I am not a compiler expert, so I have no idea how much work it is to keep >> a back-end up to date. How much work would it be roughly to bring the >> PowerPC SPE port from GCC 8 to the current version? Is this in the range of >> person weeks, months, years? >> > > Why do you wish to resurrect the port? Some products using the PowerPC SPE are still in service for at least the next ten years. We probably have not enough funding to continuously maintain the port. I am looking for options to bring it back to GCC 15. Maybe this is not the right mailing list for this work. -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Resurrect PowrPC SPE port feasible?
Hello, the PowerPC SPE port was obsoleted in GCC 8. It was moved from the general PowerPC directory (gcc/config/rs6000) to a separate directory (gcc/config/powerpcspe). In GCC 9, it was removed due to a lack of maintenance. I am not a compiler expert, so I have no idea how much work it is to keep a back-end up to date. How much work would it be roughly to bring the PowerPC SPE port from GCC 8 to the current version? Is this in the range of person weeks, months, years? Kind regard, Sebastian -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: gnatlink vs. -mthumb -march=armv7-a+simd -mfloat-abi=hard
Hello Eric,
On 26.06.24 01:35, Eric Botcazou wrote:
Here, the "-march=armv7-a+simd" was moved after the "-gnatez". So this
option is dropped in switch-c.adb and doesn't get added to the ALI file.
This comes from the spec magic implemented in ada/gcc-interface/lang-specs.h
and it looks like the '+' character is not matched by '*' or some such.
thanks for the hint. So, maybe the problem is here:
%{gnatea:-gnatez} %{g*&m*&f*} \
From the documentation
(https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html):
%{S*}
Substitutes all the switches specified to GCC whose names start
with -S, but which also take an argument. This is used for switches like
-o, -D, -I, etc. GCC considers -o foo as being one switch whose name
starts with ‘o’. %{o*} substitutes this text, including the space. Thus
two arguments are generated.
%{S*&T*}
Like %{S*}, but preserve order of S and T options (the order of S
and T in the spec is not significant). There can be any number of
ampersand-separated variables; for each the wild card is optional.
Useful for CPP as ‘%{D*&U*&A*}’.
It looks like this is working as documented. I checked this with the
following spec file:
*startfile:
BEGIN %{g*&m*&f*} END
On my x86_64 host GCC, this works fine:
gcc -specs=test.spec -wrapper echo main.c -mfoo=bar+blub -march=armv7-a+simd
... BEGIN -mfoo=bar+blub -march=armv7-a+simd END ...
On the arm GCC, it looks good also:
arm-rtems6-gcc -specs=test.spec -wrapper echo main.c -mfoo=bar+blub
-march=armv7-a+simd
... BEGIN -mfoo=bar+blub -marm -mlibarch=armv7-a -march=armv7-a END ...
arm-rtems6-gcc -specs=test.spec -wrapper echo main.c -mfoo=bar+blub
-march=armv7-a+simd -mfloat-abi=hard
... BEGIN -mfoo=bar+blub -mfloat-abi=hard -marm -mlibarch=armv7-a+simd
-march=armv7-a+simd END ...
--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: gnatlink vs. -mthumb -march=armv7-a+simd -mfloat-abi=hard
On 25.06.24 14:53, Sebastian Huber wrote:
On 24.06.24 16:06, Sebastian Huber wrote:
On 28.04.22 10:16, Sebastian Huber wrote:
Hello,
I test currently the Ada support for RTEMS in GCC 12. We have a
-mthumb -march=armv7-a+simd -mfloat-abi=hard multilib for which the
Ada RTS is built like this:
make[4]: Entering directory
'/tmp/sh/b-gcc-arm-rtems6/arm-rtems6/thumb/armv7-a+simd/hard/libada'
make -C ../../../../.././gcc/ada "MAKEOVERRIDES=" "LDFLAGS=-mthumb
-march=armv7-a+simd -mfloat-abi=hard" "LN_S=ln -s" "SHELL=/bin/sh"
"GNATLIBFLAGS=-W -Wall -gnatpg -nostdinc -mthumb -march=armv7-a+simd
-mfloat-abi=hard" "GNATLIBCFLAGS=-g -O2 -mthumb -march=armv7-a+simd
-mfloat-abi=hard" "GNATLIBCFLAGS_FOR_C=-W -Wall -g -O2 -g -O2
-fexceptions -DIN_RTS -DHAVE_GETIPINFO -mthumb -march=armv7-a+simd
-mfloat-abi=hard" "PICFLAG_FOR_TARGET=-fPIC" "THREAD_KIND=native"
"TRACE=no" "MULTISUBDIR=/thumb/armv7-a+simd/hard"
"libsubdir=/tmp/sh/i-arm-rtems6/lib64/gcc/arm-rtems6/12.0.1/thumb/armv7-a+simd/hard" "toolexeclibdir=/tmp/sh/i-arm-rtems6/lib64/gcc/arm-rtems6/12.0.1/thumb/armv7-a+simd/hard/adalib" "objext=.o" "prefix=/tmp/sh/i-arm-rtems6" "exeext=.exeext.should.not.be.used " 'CC=the.host.compiler.should.not.be.needed' "GCC_FOR_TARGET=/tmp/sh/b-gcc-arm-rtems6/./gcc/xgcc -B/tmp/sh/b-gcc-arm-rtems6/./gcc/ -nostdinc -B/tmp/sh/b-gcc-arm-rtems6/arm-rtems6/newlib/ -isystem /tmp/sh/b-gcc-arm-rtems6/arm-rtems6/newlib/targ-include -isystem /home/EB/sebastian_h/src/gcc/newlib/libc/include -B/tmp/sh/i-arm-rtems6/arm-rtems6/bin/ -B/tmp/sh/i-arm-rtems6/arm-rtems6/lib/ -isystem /tmp/sh/i-arm-rtems6/arm-rtems6/include -isystem /tmp/sh/i-arm-rtems6/arm-rtems6/sys-include " "CFLAGS=-g -O2 -mthumb -march=armv7-a+simd -mfloat-abi=hard" ./bldtools/oscons/xoscons
When I try to link a test application I get this error:
arm-rtems7-gnatlink
/tmp/sh/b-rtems/arm/realview_pbx_a9_qemu/testsuites/ada/samples/nsecs/nsecs.ali testsuites/ada/samples/nsecs/init.o -qnolinkcmds -T linkcmds.realview_pbx_a9_qemu -Wl,--wrap=printf -Wl,--wrap=puts -Wl,--wrap=putchar -L. -lrtemscpu -lrtemsbsp -lrtemstest -qrtems -mthumb -march=armv7-a+simd -mfloat-abi=hard -mtune=cortex-a9 -Wl,--gc-sections -L/home/EB/sebastian_h/src/rtems/bsps/arm/shared/start -L/home/EB/sebastian_h/src/rtems/bsps/arm/realview-pbx-a9/start -o /tmp/sh/b-rtems/arm/realview_pbx_a9_qemu/testsuites/ada/ada_nsecs.exe
/opt/rtems/7/lib/gcc/arm-rtems7/12.0.1/thumb/armv7-a+simd/hard/adainclude/s-secsta.ads:288:9:
sorry, unimplemented: Thumb-1 'hard-float' VFP ABI
The s-secsta.ads seems to be from the right multilib directory
(Thumb-2), however, I get a sorry message related to Thumb-1?
I tried it again with GCC 13, but the problem still exists. I tried to
use strace to get some more insights (the environment variables are
partially shown):
[pid 110912] execve("/opt/rtems-6-zynq-1/bin/arm-rtems6-gnatmake",
["/opt/rtems-6-zynq-1/bin/arm-rtems6-gnatmake", "-D",
"testsuites/ada/tmtests/tm20", "-bargs", "-Mgnat_main", "-margs",
"-Icpukit/include/adainclude",
"-I../../../../src/rtems/cpukit/include/adainclude",
"-Itestsuites/ada/support",
"-I../../../../src/rtems/testsuites/ada/support", "-cargs",
"-march=armv7-a", "-mthumb", "-mfpu=neon", "-mfloat-abi=hard",
"-mtune=cortex-a9", "-largs", "testsuites/ada/tmtests/tm20/init.o",
"-Wl,--wrap=printf", "-Wl,--wrap=puts", "-Wl,--wrap=putchar", "-L.",
"-lrtemscpu", "-lrtemsbsp", "-lrtemstest", "-qrtems",
"-march=armv7-a", "-mthumb", "-mfpu=neon", "-mfloat-abi=hard",
"-mtune=cortex-a9", "-Wl,--gc-sections",
"-L/opt/rtems-6-zynq-1/src/rtems/bsps/arm/shared/start",
"-L/opt/rtems-6-zynq-1/src/rtems/bsps/arm/xilinx-zynq/start",
"-margs", "-a",
"/opt/rtems-6-zynq-1/src/rtems/testsuites/ada/tmtests/tm20/tm20.adb",
"-o",
"/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/ada_tm20.exe"], []
[pid 110913] execve("/opt/rtems-6-zynq-1//bin/arm-rtems6-gcc",
["/opt/rtems-6-zynq-1//bin/arm-rtems6-gcc", "-march=armv7-a",
"-mthumb", "-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9",
"-march=armv7-a", "-mthumb", "-mfpu=neon", "-mfloat-abi=hard",
"-mtune=cortex-a9", "-print-multi-directory"], []) = 0
The above call is used to get the multi-lib directory. Wh
Re: gnatlink vs. -mthumb -march=armv7-a+simd -mfloat-abi=hard
On 24.06.24 16:06, Sebastian Huber wrote:
On 28.04.22 10:16, Sebastian Huber wrote:
Hello,
I test currently the Ada support for RTEMS in GCC 12. We have a
-mthumb -march=armv7-a+simd -mfloat-abi=hard multilib for which the
Ada RTS is built like this:
make[4]: Entering directory
'/tmp/sh/b-gcc-arm-rtems6/arm-rtems6/thumb/armv7-a+simd/hard/libada'
make -C ../../../../.././gcc/ada "MAKEOVERRIDES=" "LDFLAGS=-mthumb
-march=armv7-a+simd -mfloat-abi=hard" "LN_S=ln -s" "SHELL=/bin/sh"
"GNATLIBFLAGS=-W -Wall -gnatpg -nostdinc -mthumb -march=armv7-a+simd
-mfloat-abi=hard" "GNATLIBCFLAGS=-g -O2 -mthumb -march=armv7-a+simd
-mfloat-abi=hard" "GNATLIBCFLAGS_FOR_C=-W -Wall -g -O2 -g -O2
-fexceptions -DIN_RTS -DHAVE_GETIPINFO -mthumb -march=armv7-a+simd
-mfloat-abi=hard" "PICFLAG_FOR_TARGET=-fPIC" "THREAD_KIND=native"
"TRACE=no" "MULTISUBDIR=/thumb/armv7-a+simd/hard"
"libsubdir=/tmp/sh/i-arm-rtems6/lib64/gcc/arm-rtems6/12.0.1/thumb/armv7-a+simd/hard" "toolexeclibdir=/tmp/sh/i-arm-rtems6/lib64/gcc/arm-rtems6/12.0.1/thumb/armv7-a+simd/hard/adalib" "objext=.o" "prefix=/tmp/sh/i-arm-rtems6" "exeext=.exeext.should.not.be.used " 'CC=the.host.compiler.should.not.be.needed' "GCC_FOR_TARGET=/tmp/sh/b-gcc-arm-rtems6/./gcc/xgcc -B/tmp/sh/b-gcc-arm-rtems6/./gcc/ -nostdinc -B/tmp/sh/b-gcc-arm-rtems6/arm-rtems6/newlib/ -isystem /tmp/sh/b-gcc-arm-rtems6/arm-rtems6/newlib/targ-include -isystem /home/EB/sebastian_h/src/gcc/newlib/libc/include -B/tmp/sh/i-arm-rtems6/arm-rtems6/bin/ -B/tmp/sh/i-arm-rtems6/arm-rtems6/lib/ -isystem /tmp/sh/i-arm-rtems6/arm-rtems6/include -isystem /tmp/sh/i-arm-rtems6/arm-rtems6/sys-include " "CFLAGS=-g -O2 -mthumb -march=armv7-a+simd -mfloat-abi=hard" ./bldtools/oscons/xoscons
When I try to link a test application I get this error:
arm-rtems7-gnatlink
/tmp/sh/b-rtems/arm/realview_pbx_a9_qemu/testsuites/ada/samples/nsecs/nsecs.ali testsuites/ada/samples/nsecs/init.o -qnolinkcmds -T linkcmds.realview_pbx_a9_qemu -Wl,--wrap=printf -Wl,--wrap=puts -Wl,--wrap=putchar -L. -lrtemscpu -lrtemsbsp -lrtemstest -qrtems -mthumb -march=armv7-a+simd -mfloat-abi=hard -mtune=cortex-a9 -Wl,--gc-sections -L/home/EB/sebastian_h/src/rtems/bsps/arm/shared/start -L/home/EB/sebastian_h/src/rtems/bsps/arm/realview-pbx-a9/start -o /tmp/sh/b-rtems/arm/realview_pbx_a9_qemu/testsuites/ada/ada_nsecs.exe
/opt/rtems/7/lib/gcc/arm-rtems7/12.0.1/thumb/armv7-a+simd/hard/adainclude/s-secsta.ads:288:9:
sorry, unimplemented: Thumb-1 'hard-float' VFP ABI
The s-secsta.ads seems to be from the right multilib directory
(Thumb-2), however, I get a sorry message related to Thumb-1?
I tried it again with GCC 13, but the problem still exists. I tried to
use strace to get some more insights (the environment variables are
partially shown):
[pid 110912] execve("/opt/rtems-6-zynq-1/bin/arm-rtems6-gnatmake",
["/opt/rtems-6-zynq-1/bin/arm-rtems6-gnatmake", "-D",
"testsuites/ada/tmtests/tm20", "-bargs", "-Mgnat_main", "-margs",
"-Icpukit/include/adainclude",
"-I../../../../src/rtems/cpukit/include/adainclude",
"-Itestsuites/ada/support",
"-I../../../../src/rtems/testsuites/ada/support", "-cargs",
"-march=armv7-a", "-mthumb", "-mfpu=neon", "-mfloat-abi=hard",
"-mtune=cortex-a9", "-largs", "testsuites/ada/tmtests/tm20/init.o",
"-Wl,--wrap=printf", "-Wl,--wrap=puts", "-Wl,--wrap=putchar", "-L.",
"-lrtemscpu", "-lrtemsbsp", "-lrtemstest", "-qrtems", "-march=armv7-a",
"-mthumb", "-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9",
"-Wl,--gc-sections",
"-L/opt/rtems-6-zynq-1/src/rtems/bsps/arm/shared/start",
"-L/opt/rtems-6-zynq-1/src/rtems/bsps/arm/xilinx-zynq/start", "-margs",
"-a",
"/opt/rtems-6-zynq-1/src/rtems/testsuites/ada/tmtests/tm20/tm20.adb",
"-o",
"/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/ada_tm20.exe"], []
[pid 110913] execve("/opt/rtems-6-zynq-1//bin/arm-rtems6-gcc",
["/opt/rtems-6-zynq-1//bin/arm-rtems6-gcc", "-march=armv7-a", "-mthumb",
"-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9", "-march=armv7-a",
"-mthumb", "-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9",
"-print-multi-directory"], []) = 0
The above call is used to get the multi-lib directory. Which yields:
--RTS=thumb/armv7-a+simd/hard
The
Re: gnatlink vs. -mthumb -march=armv7-a+simd -mfloat-abi=hard
On 28.04.22 10:16, Sebastian Huber wrote:
Hello,
I test currently the Ada support for RTEMS in GCC 12. We have a -mthumb
-march=armv7-a+simd -mfloat-abi=hard multilib for which the Ada RTS is
built like this:
make[4]: Entering directory
'/tmp/sh/b-gcc-arm-rtems6/arm-rtems6/thumb/armv7-a+simd/hard/libada'
make -C ../../../../.././gcc/ada "MAKEOVERRIDES=" "LDFLAGS=-mthumb
-march=armv7-a+simd -mfloat-abi=hard" "LN_S=ln -s" "SHELL=/bin/sh"
"GNATLIBFLAGS=-W -Wall -gnatpg -nostdinc -mthumb -march=armv7-a+simd
-mfloat-abi=hard" "GNATLIBCFLAGS=-g -O2 -mthumb -march=armv7-a+simd
-mfloat-abi=hard" "GNATLIBCFLAGS_FOR_C=-W -Wall -g -O2 -g -O2
-fexceptions -DIN_RTS -DHAVE_GETIPINFO -mthumb -march=armv7-a+simd
-mfloat-abi=hard" "PICFLAG_FOR_TARGET=-fPIC" "THREAD_KIND=native"
"TRACE=no" "MULTISUBDIR=/thumb/armv7-a+simd/hard"
"libsubdir=/tmp/sh/i-arm-rtems6/lib64/gcc/arm-rtems6/12.0.1/thumb/armv7-a+simd/hard" "toolexeclibdir=/tmp/sh/i-arm-rtems6/lib64/gcc/arm-rtems6/12.0.1/thumb/armv7-a+simd/hard/adalib" "objext=.o" "prefix=/tmp/sh/i-arm-rtems6" "exeext=.exeext.should.not.be.used " 'CC=the.host.compiler.should.not.be.needed' "GCC_FOR_TARGET=/tmp/sh/b-gcc-arm-rtems6/./gcc/xgcc -B/tmp/sh/b-gcc-arm-rtems6/./gcc/ -nostdinc -B/tmp/sh/b-gcc-arm-rtems6/arm-rtems6/newlib/ -isystem /tmp/sh/b-gcc-arm-rtems6/arm-rtems6/newlib/targ-include -isystem /home/EB/sebastian_h/src/gcc/newlib/libc/include -B/tmp/sh/i-arm-rtems6/arm-rtems6/bin/ -B/tmp/sh/i-arm-rtems6/arm-rtems6/lib/ -isystem /tmp/sh/i-arm-rtems6/arm-rtems6/include -isystem /tmp/sh/i-arm-rtems6/arm-rtems6/sys-include " "CFLAGS=-g -O2 -mthumb -march=armv7-a+simd -mfloat-abi=hard" ./bldtools/oscons/xoscons
When I try to link a test application I get this error:
arm-rtems7-gnatlink
/tmp/sh/b-rtems/arm/realview_pbx_a9_qemu/testsuites/ada/samples/nsecs/nsecs.ali testsuites/ada/samples/nsecs/init.o -qnolinkcmds -T linkcmds.realview_pbx_a9_qemu -Wl,--wrap=printf -Wl,--wrap=puts -Wl,--wrap=putchar -L. -lrtemscpu -lrtemsbsp -lrtemstest -qrtems -mthumb -march=armv7-a+simd -mfloat-abi=hard -mtune=cortex-a9 -Wl,--gc-sections -L/home/EB/sebastian_h/src/rtems/bsps/arm/shared/start -L/home/EB/sebastian_h/src/rtems/bsps/arm/realview-pbx-a9/start -o /tmp/sh/b-rtems/arm/realview_pbx_a9_qemu/testsuites/ada/ada_nsecs.exe
/opt/rtems/7/lib/gcc/arm-rtems7/12.0.1/thumb/armv7-a+simd/hard/adainclude/s-secsta.ads:288:9:
sorry, unimplemented: Thumb-1 'hard-float' VFP ABI
The s-secsta.ads seems to be from the right multilib directory
(Thumb-2), however, I get a sorry message related to Thumb-1?
I tried it again with GCC 13, but the problem still exists. I tried to
use strace to get some more insights (the environment variables are
partially shown):
[pid 110912] execve("/opt/rtems-6-zynq-1/bin/arm-rtems6-gnatmake",
["/opt/rtems-6-zynq-1/bin/arm-rtems6-gnatmake", "-D",
"testsuites/ada/tmtests/tm20", "-bargs", "-Mgnat_main", "-margs",
"-Icpukit/include/adainclude",
"-I../../../../src/rtems/cpukit/include/adainclude",
"-Itestsuites/ada/support",
"-I../../../../src/rtems/testsuites/ada/support", "-cargs",
"-march=armv7-a", "-mthumb", "-mfpu=neon", "-mfloat-abi=hard",
"-mtune=cortex-a9", "-largs", "testsuites/ada/tmtests/tm20/init.o",
"-Wl,--wrap=printf", "-Wl,--wrap=puts", "-Wl,--wrap=putchar", "-L.",
"-lrtemscpu", "-lrtemsbsp", "-lrtemstest", "-qrtems", "-march=armv7-a",
"-mthumb", "-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9",
"-Wl,--gc-sections",
"-L/opt/rtems-6-zynq-1/src/rtems/bsps/arm/shared/start",
"-L/opt/rtems-6-zynq-1/src/rtems/bsps/arm/xilinx-zynq/start", "-margs",
"-a",
"/opt/rtems-6-zynq-1/src/rtems/testsuites/ada/tmtests/tm20/tm20.adb",
"-o",
"/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/ada_tm20.exe"],
[]
[pid 110913] execve("/opt/rtems-6-zynq-1//bin/arm-rtems6-gcc",
["/opt/rtems-6-zynq-1//bin/arm-rtems6-gcc", "-march=armv7-a", "-mthumb",
"-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9", "-march=armv7-a",
"-mthumb", "-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9",
"-print-multi-directory"], []) = 0
The above call is used to get the multi-lib directory. Which yields:
--RTS=thumb/armv7-a+simd/hard
The flags seem to be obtained by getting a
Re: ZynqMP APU RAM Start
On 14.05.24 08:03, Sebastian Huber wrote: Hello, the ZynqMP APU RAM start addresses are far away from 0x0: Sorry, I selected the wrong mailing list. -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
ZynqMP APU RAM Start
Hello,
the ZynqMP APU RAM start addresses are far away from 0x0:
cat spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
actions:
- get-integer: null
- assert-uint32: null
- env-assign: null
- format-and-define: null
build-type: option
copyrights:
- Copyright (C) 2020 On-Line Applications Research (OAR)
default:
- enabled-by:
- aarch64/xilinx_zynqmp_lp64_a53
- aarch64/xilinx_zynqmp_ilp32_zu3eg
- aarch64/xilinx_zynqmp_lp64_cfc400x
- aarch64/xilinx_zynqmp_lp64_zu3eg
value: 0x1000
- enabled-by: true
value: 0x40018000
description: |
base address of memory area available to the BSP
enabled-by: true
format: '{:#010x}'
links: []
name: BSP_XILINX_ZYNQMP_RAM_BASE
type: build
What is the rationale for doing this? Any objections to change the start
address to 0x0?
What is the MMU page size used by the BSPs? Would it be possible to add
a NULL pointer protection page?
--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
License of libgcc/config/sparc/lb1spc.S?
Hello, under which license is libgcc/config/sparc/lb1spc.S? The header says: /* This is an assembly language implementation of mulsi3, divsi3, and modsi3 for the sparc processor. These routines are derived from the SPARC Architecture Manual, version 8, slightly edited to match the desired calling convention, and also to optimize them for our purposes. */ -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: Third GC 13.1 Release Candidate available from gcc.gnu.org
On 21.04.23 23:14, William Seurer via Gcc wrote: I bootstrapped and tested this on powerpc64 power 7, 8, 9, and 10 and on both BE and LE and saw nothing unexpected. I have problems to build a 32-bit powerpc compiler. It cannot build Newlib: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566 -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: Why is there no libatomic default implementation using gthr.h?
On 19/12/2022 13:41, Jonathan Wakely wrote: 3. Use gthr as the default implementation of libatomic. I have no objection to doing this, but I don't see why you need to touch libstdc++ to do it. Just make libatomic create its own copy of gthr.h (if a fallback gthreads-based implementation is actually needed) and compile that locally in the libatomic build dir. That shouldn't need changes to libgcc or libstdc++, should it? Yes, this would also work. I can probably duplicate the gthr configure/Makefile stuff from libstdc++ for this. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Why is there no libatomic default implementation using gthr.h?
Hello, I would like to fix the -fprofile-update=atomic implementation so that it works on all targets. Currently, it works only on targets with 64-bit atomic operations in hardware (and some special cases). I tried to fix it like this: https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608620.html The problem with this patch is that it falls back to use functions provided by libatomic. The libatomic is currently not supported on all targets, for example: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77466 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77378 Why is there no libatomic default implementation using gthr.h? The C++ library already depends on gthr.h and installs the headers in "bits/gthr.h" etc. For this the libstdc++-v3 configure/Makefile duplicates some logic from libgcc. Why is the gthr.h stuff not installed by libgcc itself? In libatomic, the POSIX implementation could be easily rewritten to use the gthr interface. Any objections to do the following? 1. Install gthr.h to "bits/gthr.h" by libgcc (including the other gthr headers). 2. Remove the gthr configure/Makefile support from libstdc++-v3. 3. Use gthr as the default implementation of libatomic. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: -fprofile-update=atomic vs. 32-bit architectures
On 04.11.22 09:27, Sebastian Huber wrote: Hello, even recent 32-bit architectures such as RISC-V do not support 64-bit atomic operations. Using -fprofile-update=atomic for the 32-bit RISC-V RV32GC ISA yields: warning: target does not support atomic profile update, single mode is selected For multi-threaded applications it is quite important to use atomic counter increments to get valid coverage data. I think this fall back is not really good. Maybe we should consider using this approach from Jakub Jelinek for 32-bit architectures lacking 64-bit atomic operations: if (__atomic_add_fetch_4 ((unsigned int *) &val, 1, __ATOMIC_RELAXED) == 0) __atomic_fetch_add_4 (((unsigned int *) &val) + 1, 1, __ATOMIC_RELAXED); https://patchwork.ozlabs.org/project/gcc/patch/19c4a81d-6ecd-8c6e-b641-e257c1959...@suse.cz/#1447334 Last year I added the TARGET_GCOV_TYPE_SIZE target hook to optionally reduce the gcov type size to 32 bits. I am not really sure if this was a good idea. Longer running executables may observe counter overflows leading to invalid coverage data. If someone wants atomic updates, then the updates should be atomic even if this means to use a library implementation (libatomic). What about the following approach if -fprofile-update=atomic is given: 1. Use 64-bit atomics if available. 2. Use if (__atomic_add_fetch_4 ((unsigned int *) &val, 1, __ATOMIC_RELAXED) == 0) __atomic_fetch_add_4 (((unsigned int *) &val) + 1, 1, __ATOMIC_RELAXED); if 32-bit atomics are available. This approach works fine for the edge counters in gimple_gen_edge_profiler() because we don't have to read the counter value. We just have to do an increment. In gimple_gen_time_profiler() we have to do this: /* Emit: counters[0] = ++__gcov_time_profiler_counter. */ So here we have to do an atomic increment and fetch the value. This doesn't work with the approach above. For example let thread A increment the lower part from 0xfffe to 0x, then let thread B increment the lower part from 0x to 0x0, then the higher part from 0x7 to 0x8, then let thread A read 0x8. Thread A would then get 0x8_ instead of the correct 0x7_. 3. Else use a library call (libatomic). -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: -fprofile-update=atomic vs. 32-bit architectures
On 07.12.22 10:09, Richard Biener wrote:
On Wed, Dec 7, 2022 at 9:51 AM Sebastian Huber
wrote:
On 06.12.22 17:08, Richard Biener wrote:
Likely. I'd use the gimple_build () API from gimple-fold.h which
builds the expression(s) to a gimple_seq creating necessary temporaries
on-the-fly and then insert that sequence on the edge.
Thanks, I will have a look at this.
I am struggling to convert a uint32_type_node node to a gcov_type_node
(64-bit). I tried to use this:
if (result != NULL_TREE)
{
tree tmp1 = make_temp_ssa_name (gcov_type_node, NULL, name);
gassign *stmt7 = gimple_build_assign (result, VIEW_CONVERT_EXPR,
build1 (VIEW_CONVERT_EXPR, gcov_type_node,
high));
You want
gimple_build_assign (result, NOP_EXPR, high);
here (a conversion, from unsigned it will zero-extend)
Thanks, with this NOP_EXPR it did work. I have now a proof of concept
ready. Should I wait for the GCC 14 development cycle or can I post a
patch set now?
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: -fprofile-update=atomic vs. 32-bit architectures
On 06.12.22 17:08, Richard Biener wrote:
Likely. I'd use the gimple_build () API from gimple-fold.h which
builds the expression(s) to a gimple_seq creating necessary temporaries
on-the-fly and then insert that sequence on the edge.
Thanks, I will have a look at this.
I am struggling to convert a uint32_type_node node to a gcov_type_node
(64-bit). I tried to use this:
if (result != NULL_TREE)
{
tree tmp1 = make_temp_ssa_name (gcov_type_node, NULL, name);
gassign *stmt7 = gimple_build_assign (result, VIEW_CONVERT_EXPR,
build1 (VIEW_CONVERT_EXPR, gcov_type_node,
high));
tree tmp2 = make_temp_ssa_name (gcov_type_node, NULL, name);
gassign *stmt8 = gimple_build_assign (tmp2, LSHIFT_EXPR, tmp1,
build_int_cst (integer_type_node, 32));
gassign *stmt9 = gimple_build_assign (result, BIT_IOR_EXPR, tmp2,
tmp1);
gsi_insert_after (gsi, stmt7, GSI_NEW_STMT);
gsi_insert_after (gsi, stmt8, GSI_NEW_STMT);
gsi_insert_after (gsi, stmt9, GSI_NEW_STMT);
}
This ends up in:
../test.c: In function 'f':
../test.c:4:1: error: conversion of register to a different size in
'view_convert_expr'
4 | }
| ^
VIEW_CONVERT_EXPR(PROF_time_profiler_15);
PROF_time_profile_9 = VIEW_CONVERT_EXPRint>(PROF_time_profiler_15);
during IPA pass: profile
../test.c:4:1: internal compiler error: verify_gimple failed
0xdddc95 verify_gimple_in_cfg(function*, bool, bool)
/home/EB/sebastian_h/src/gcc/gcc/tree-cfg.cc:5647
0xc20221 execute_function_todo
/home/EB/sebastian_h/src/gcc/gcc/passes.cc:2091
0xc1efd6 do_per_function
/home/EB/sebastian_h/src/gcc/gcc/passes.cc:1701
0xc20416 execute_todo
/home/EB/sebastian_h/src/gcc/gcc/passes.cc:2145
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: -fprofile-update=atomic vs. 32-bit architectures
On 05/12/2022 08:44, Richard Biener wrote:
On Mon, Dec 5, 2022 at 8:26 AM Sebastian Huber
wrote:
On 08/11/2022 11:25, Richard Biener wrote:
It would be great to have a code example for the construction of the "if
(f()) f();".
I think for the function above we need to emit __atomic_fetch_add_8,
not the emulated form because we cannot insert the required control
flow (if (f()) f()) on an edge. The __atomic_fetch_add_8 should then be
lowered after the instrumentation took place.
Would it help to change the
if (__atomic_add_fetch_4 ((unsigned int *) &val, 1, __ATOMIC_RELAXED)
== 0)
__atomic_fetch_add_4 (((unsigned int *) &val) + 1, 1,
__ATOMIC_RELAXED);
into
unsigned int v = __atomic_add_fetch_4 ((unsigned int *) &val, 1,
__ATOMIC_RELAXED)
== 0)
v = (unsigned int)(v == 0);
__atomic_fetch_add_4 (((unsigned int *) &val) + 1, 1,
__ATOMIC_RELAXED);
that's supposed to add 'v' instead of 1? Possibly use uint32_t here
(aka uint32_type_node).
to get rid of an inserted control flow?
That for sure wouldn't require any changes to how the profile
instrumentation works,
so yes it would be simpler.
Yes, this seems to work. After a bit of trial and error I ended up with
something in gimple_gen_edge_profiler() like this (endian support is
missing):
else if (flag_profile_update == PROFILE_UPDATE_SPLIT_ATOMIC)
{
tree addr = tree_coverage_counter_addr (GCOV_COUNTER_ARCS, edgeno);
tree f = builtin_decl_explicit (BUILT_IN_ATOMIC_ADD_FETCH_4);
gcall *stmt1 = gimple_build_call (f, 3, addr, one,
build_int_cst (integer_type_node,
MEMMODEL_RELAXED));
tree low = create_tmp_var (uint32_type_node);
gimple_call_set_lhs (stmt1, low);
tree is_zero = create_tmp_var (boolean_type_node);
gassign *stmt2 = gimple_build_assign (is_zero, EQ_EXPR, low,
build_zero_cst (uint32_type_node));
tree high_inc = create_tmp_var (uint32_type_node);
gassign *stmt3 = gimple_build_assign (high_inc, COND_EXPR, is_zero,
build_one_cst (uint32_type_node),
build_zero_cst (uint32_type_node));
tree addr_high = create_tmp_var (TREE_TYPE (addr));
gassign *stmt4 = gimple_build_assign (addr_high, addr);
gassign *stmt5 = gimple_build_assign (addr_high, POINTER_PLUS_EXPR,
addr_high,
build_int_cst (size_type_node, 4));
gcall *stmt6 = gimple_build_call (f, 3, addr_high, high_inc,
build_int_cst (integer_type_node,
MEMMODEL_RELAXED));
gsi_insert_on_edge (e, stmt1);
gsi_insert_on_edge (e, stmt2);
gsi_insert_on_edge (e, stmt3);
gsi_insert_on_edge (e, stmt4);
gsi_insert_on_edge (e, stmt5);
gsi_insert_on_edge (e, stmt6);
}
It can be probably simplified. The generated code:
.type f, @function
f:
lui a4,%hi(__gcov0.f)
li a3,1
addia4,a4,%lo(__gcov0.f)
amoadd.w a5,a3,0(a4)
lui a4,%hi(__gcov0.f+4)
addia5,a5,1
seqza5,a5
addia4,a4,%lo(__gcov0.f+4)
amoadd.w zero,a5,0(a4)
li a0,3
ret
looks good for this code:
int f(void)
{
return 3;
}
The loading of the high address could be probably optimized from
lui a4,%hi(__gcov0.f+4)
addia4,a4,%lo(__gcov0.f+4)
to
addia4,a4,4
I wasn't able to figure out how to do this.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: -fprofile-update=atomic vs. 32-bit architectures
On 08/11/2022 11:25, Richard Biener wrote: It would be great to have a code example for the construction of the "if (f()) f();". I think for the function above we need to emit __atomic_fetch_add_8, not the emulated form because we cannot insert the required control flow (if (f()) f()) on an edge. The __atomic_fetch_add_8 should then be lowered after the instrumentation took place. Would it help to change the if (__atomic_add_fetch_4 ((unsigned int *) &val, 1, __ATOMIC_RELAXED) == 0) __atomic_fetch_add_4 (((unsigned int *) &val) + 1, 1, __ATOMIC_RELAXED); into unsigned int v = __atomic_add_fetch_4 ((unsigned int *) &val, 1, __ATOMIC_RELAXED) == 0) v = (unsigned int)(v == 0); __atomic_fetch_add_4 (((unsigned int *) &val) + 1, 1, __ATOMIC_RELAXED); to get rid of an inserted control flow? On riscv this is optimized to: li a4,1 amoadd.w a5,a4,0(a0) addia5,a5,1 seqza5,a5 addia4,a0,4 amoadd.w zero,a5,0(a4) -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: -fprofile-update=atomic vs. 32-bit architectures
On 08.11.22 11:25, Richard Biener wrote: How do I get ((unsigned int *) &val) + 1 from tree addr? It would be great to have a code example for the construction of the "if (f()) f();". I think for the function above we need to emit __atomic_fetch_add_8, not the emulated form because we cannot insert the required control flow (if (f()) f()) on an edge. The __atomic_fetch_add_8 should then be lowered after the instrumentation took place. Ok, I am not a compiler expert, so I have just a vague feeling how this works. I am not sure which piece is responsible for the "lowering" of this particular __atomic_fetch_add_8. I guess we don't want to split all __atomic_fetch_add_8 into this if (f()) f(); form? There's currently no helper to create a diamond so the canonical way is to create a GIMPLE_COND, split the block after this stmt, split the outgoing edge and then redirect edges to form a half-diamond. move_sese_in_condition has most of that CFG manipulation (but it performs sth different) Thanks, I will probably able to do this with a bit trial and error. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: -fprofile-update=atomic vs. 32-bit architectures
On 05.11.22 12:18, Richard Biener wrote:
On Fri, Nov 4, 2022 at 9:28 AM Sebastian Huber
wrote:
Hello,
even recent 32-bit architectures such as RISC-V do not support 64-bit
atomic operations. Using -fprofile-update=atomic for the 32-bit RISC-V
RV32GC ISA yields:
warning: target does not support atomic profile update, single mode is
selected
For multi-threaded applications it is quite important to use atomic
counter increments to get valid coverage data. I think this fall back is
not really good. Maybe we should consider using this approach from Jakub
Jelinek for 32-bit architectures lacking 64-bit atomic operations:
if (__atomic_add_fetch_4 ((unsigned int *) &val, 1, __ATOMIC_RELAXED)
== 0)
__atomic_fetch_add_4 (((unsigned int *) &val) + 1, 1,
__ATOMIC_RELAXED);
https://patchwork.ozlabs.org/project/gcc/patch/19c4a81d-6ecd-8c6e-b641-e257c1959...@suse.cz/#1447334
Last year I added the TARGET_GCOV_TYPE_SIZE target hook to optionally
reduce the gcov type size to 32 bits. I am not really sure if this was a
good idea. Longer running executables may observe counter overflows
leading to invalid coverage data. If someone wants atomic updates, then
the updates should be atomic even if this means to use a library
implementation (libatomic).
What about the following approach if -fprofile-update=atomic is given:
1. Use 64-bit atomics if available.
2. Use
if (__atomic_add_fetch_4 ((unsigned int *) &val, 1, __ATOMIC_RELAXED)
== 0)
__atomic_fetch_add_4 (((unsigned int *) &val) + 1, 1,
__ATOMIC_RELAXED);
if 32-bit atomics are available.
3. Else use a library call (libatomic).
sounds good, though a library call would really be prohibitly expensive?
I someone wants to profile a multi-threaded application and selects
-fprofile-update=atomic, then probably a correct result is preferred.
You still have the option to select -fprofile-update=prefer-atomic.
For 2. I have to modify:
void
gimple_gen_edge_profiler (int edgeno, edge e)
{
tree one;
one = build_int_cst (gcov_type_node, 1);
if (flag_profile_update == PROFILE_UPDATE_ATOMIC)
{
/* __atomic_fetch_add (&counter, 1, MEMMODEL_RELAXED); */
tree addr = tree_coverage_counter_addr (GCOV_COUNTER_ARCS, edgeno);
tree f = builtin_decl_explicit (TYPE_PRECISION (gcov_type_node) > 32
? BUILT_IN_ATOMIC_FETCH_ADD_8:
BUILT_IN_ATOMIC_FETCH_ADD_4);
gcall *stmt = gimple_build_call (f, 3, addr, one,
build_int_cst (integer_type_node,
MEMMODEL_RELAXED));
gsi_insert_on_edge (e, stmt);
}
Is
if (WORDS_BIG_ENDIAN)
the right way to check for big/little endian?
How do I get ((unsigned int *) &val) + 1 from tree addr?
It would be great to have a code example for the construction of the "if
(f()) f();".
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: -fprofile-update=atomic vs. 32-bit architectures
On 04/11/2022 10:53, Gabriel Paubert wrote: 2. Use if (__atomic_add_fetch_4 ((unsigned int *) &val, 1, __ATOMIC_RELAXED) == 0) __atomic_fetch_add_4 (((unsigned int *) &val) + 1, 1, __ATOMIC_RELAXED); if 32-bit atomics are available. This assumes little-endian byte order. Yes, but this approach would also work on big-endian architectures. You just have to use other addresses. I guess the compiler knows for which endianess it generates code. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
-fprofile-update=atomic vs. 32-bit architectures
Hello, even recent 32-bit architectures such as RISC-V do not support 64-bit atomic operations. Using -fprofile-update=atomic for the 32-bit RISC-V RV32GC ISA yields: warning: target does not support atomic profile update, single mode is selected For multi-threaded applications it is quite important to use atomic counter increments to get valid coverage data. I think this fall back is not really good. Maybe we should consider using this approach from Jakub Jelinek for 32-bit architectures lacking 64-bit atomic operations: if (__atomic_add_fetch_4 ((unsigned int *) &val, 1, __ATOMIC_RELAXED) == 0) __atomic_fetch_add_4 (((unsigned int *) &val) + 1, 1, __ATOMIC_RELAXED); https://patchwork.ozlabs.org/project/gcc/patch/19c4a81d-6ecd-8c6e-b641-e257c1959...@suse.cz/#1447334 Last year I added the TARGET_GCOV_TYPE_SIZE target hook to optionally reduce the gcov type size to 32 bits. I am not really sure if this was a good idea. Longer running executables may observe counter overflows leading to invalid coverage data. If someone wants atomic updates, then the updates should be atomic even if this means to use a library implementation (libatomic). What about the following approach if -fprofile-update=atomic is given: 1. Use 64-bit atomics if available. 2. Use if (__atomic_add_fetch_4 ((unsigned int *) &val, 1, __ATOMIC_RELAXED) == 0) __atomic_fetch_add_4 (((unsigned int *) &val) + 1, 1, __ATOMIC_RELAXED); if 32-bit atomics are available. 3. Else use a library call (libatomic). -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: Use -ftls-model=local-exec for RTEMS by default?
On 21.07.22 10:03, Iain Sandoe wrote:
This sounds like an interesting approach in the long run, however, I need a
short term solution which I can back port to GCC 10, 11, and 12. I guess I will
add a
MULTILIB_EXTRA_OPTS = ftls-model=local-exec
to all RTEMS multilib configurations.
In general I think the target hooks are hard to customize for operating systems.
(IMO) It can be not too tricky - Darwin customises several - you just have to
override the default definition in your target-specific header and provide the
replacement e.g ( override in config/darwin.h, replacement in config/darwin.cc):
#undef TARGET_ENCODE_SECTION_INFO
#define TARGET_ENCODE_SECTION_INFO darwin_encode_section_info
The problem is that in this case you need a target-specific copy and
paste solution. For example lets suppose you want to use
#define CC1_SPEC "%{!ftls-model=*:-ftls-model=local-exec}"
for RTEMS (in gcc/config/rtems.h), then you have a problem on for
example microblaze (gcc/config/microblaze/microblaze.h):
#ifndef CC1_SPEC
#define CC1_SPEC " \
%{G*} \
%(subtarget_cc1_spec) \
%{mxl-multiply-high:-mcpu=v6.00.a} \
"
#endif
or nios2 (gcc/config/nios2/nios2.h):
#define CC1_SPEC "%{G*}"
For each target you would have to check if you have to provide some
extra times for CC1_SPEC through copy and paste.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: Use -ftls-model=local-exec for RTEMS by default?
On 20.07.22 15:01, Alexander Monakov wrote:
On Wed, 20 Jul 2022, Sebastian Huber wrote:
On 20/07/2022 13:41, Alexander Monakov wrote:
On Wed, 20 Jul 2022, Sebastian Huber wrote:
How does Ada get its default TLS model?
You shouldn't need to do anything special, GCC automatically selects
initial-exec or local-exec for non-PIC (including PIE).
I am not sure, for this test program:
extern _Thread_local int i;
_Thread_local int j;
int f(void)
{
return i + j;
}
I get:
[snip]
Thanks, I missed that you are asking about promoting initial-exec to local-exec
rather than x-dynamic to y-exec. There's a pending patch that implements such
promotion based on visibility information:
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598017.html
With that patch, you'll get local-exec model for the extern variable 'i' if you
inform the compiler that its definition will end up in the current module:
__attribute__((visibility("hidden")))
extern _Thread_local int i;
_Thread_local int j;
int f(void)
{
return i + j;
}
Thus I would try to enhance the binds_local_p target hook for RTEMS to inform
the compiler that there's no dynamic linking (although apart from TLS variables
I cannot instantly name other places where it would enhance optimization).
This sounds like an interesting approach in the long run, however, I
need a short term solution which I can back port to GCC 10, 11, and 12.
I guess I will add a
MULTILIB_EXTRA_OPTS = ftls-model=local-exec
to all RTEMS multilib configurations.
In general I think the target hooks are hard to customize for operating
systems.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: Use -ftls-model=local-exec for RTEMS by default?
On 20/07/2022 13:41, Alexander Monakov wrote:
On Wed, 20 Jul 2022, Sebastian Huber wrote:
How does Ada get its default TLS model?
You shouldn't need to do anything special, GCC automatically selects
initial-exec or local-exec for non-PIC (including PIE).
I am not sure, for this test program:
extern _Thread_local int i;
_Thread_local int j;
int f(void)
{
return i + j;
}
I get:
powerpc-rtems6-gcc -S -O2 -o - tls.c
.file "tls.c"
.machine ppc
.section".text"
.align 2
.globl f
.type f, @function
f:
.LFB0:
.cfi_startproc
lis 9,_GLOBAL_OFFSET_TABLE_@ha
addis 10,2,j@tprel@ha
la 9,_GLOBAL_OFFSET_TABLE_@l(9)
addi 10,10,j@tprel@l
lwz 9,i@got@tprel(9)
lwz 10,0(10)
add 9,9,i@tls
lwz 3,0(9)
add 3,3,10
blr
.cfi_endproc
.LFE0:
.size f,.-f
.globl j
.section.tbss,"awT",@nobits
.align 2
.type j, @object
.size j, 4
j:
.zero 4
.ident "GCC: (GNU) 12.1.1 20220711 [master 5efa23f3389]"
.section.note.GNU-stack,"",@progbits
and:
powerpc-rtems6-gcc -S -O2 -o - tls.c -ftls-model=local-exec
.file "tls.c"
.machine ppc
.section".text"
.align 2
.globl f
.type f, @function
f:
.LFB0:
.cfi_startproc
addis 10,2,i@tprel@ha
addis 9,2,j@tprel@ha
addi 10,10,i@tprel@l
addi 9,9,j@tprel@l
lwz 3,0(10)
lwz 9,0(9)
add 3,3,9
blr
.cfi_endproc
.LFE0:
.size f,.-f
.globl j
.section.tbss,"awT",@nobits
.align 2
.type j, @object
.size j, 4
j:
.zero 4
.ident "GCC: (GNU) 12.1.1 20220711 [master 5efa23f3389]"
.section.note.GNU-stack,"",@progbits
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: Use -ftls-model=local-exec for RTEMS by default?
On 20/07/2022 10:43, Sebastian Huber wrote:
Hello,
RTEMS applications are usually fully statically linked together with the
operating system. So, we can use the -ftls-model=local-exec TLS model.
The default value for this option is defined in common.opt:
ftls-model=
Common Joined RejectNegative Enum(tls_model) Var(flag_tls_default)
Init(TLS_MODEL_GLOBAL_DYNAMIC)
-ftls-model=[global-dynamic|local-dynamic|initial-exec|local-exec]
Set the default thread-local storage code generation model.
Would it be possible to customize the default value for RTEMS?
I think this could be done by adding
#define CC1_SPEC "%{!ftls-model=*:-ftls-model=local-exec}"
to gcc/config/rtems.h. However, the CC1_SPEC is also defined by several
targets. Would it be possible to add an OS_CC1_SPEC like this?
diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index bb07cc244e3..7ddabc888b0 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -709,6 +709,12 @@ proper position among the other output files. */
#define CC1_SPEC ""
#endif
+/* config.h can define OS_CC1_SPEC to provide extra args to cc1 and cc1plus
+ or operating system specific extra switch-translations. */
+#ifndef OS_CC1_SPEC
+#define OS_CC1_SPEC ""
+#endif
+
/* config.h can define CC1PLUS_SPEC to provide extra args to cc1plus
or extra switch-translations. */
#ifndef CC1PLUS_SPEC
@@ -1194,7 +1200,7 @@ proper position among the other output files. */
static const char *asm_debug = ASM_DEBUG_SPEC;
static const char *asm_debug_option = ASM_DEBUG_OPTION_SPEC;
static const char *cpp_spec = CPP_SPEC;
-static const char *cc1_spec = CC1_SPEC;
+static const char *cc1_spec = CC1_SPEC OS_CC1_SPEC;
static const char *cc1plus_spec = CC1PLUS_SPEC;
static const char *link_gcc_c_sequence_spec = LINK_GCC_C_SEQUENCE_SPEC;
static const char *link_ssp_spec = LINK_SSP_SPEC;
How does Ada get its default TLS model?
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Use -ftls-model=local-exec for RTEMS by default?
Hello, RTEMS applications are usually fully statically linked together with the operating system. So, we can use the -ftls-model=local-exec TLS model. The default value for this option is defined in common.opt: ftls-model= Common Joined RejectNegative Enum(tls_model) Var(flag_tls_default) Init(TLS_MODEL_GLOBAL_DYNAMIC) -ftls-model=[global-dynamic|local-dynamic|initial-exec|local-exec] Set the default thread-local storage code generation model. Would it be possible to customize the default value for RTEMS? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: _Unwind_Resume() references in libgcc division functions
On 21/06/2022 15:24, Jakub Jelinek wrote: On Tue, Jun 21, 2022 at 03:13:19PM +0200, Sebastian Huber wrote: Hello, I noticed that several division related routines provided by libgcc such as __divdi3, __moddi3 and __umoddi3 have references to _Unwind_Resume for the sparc-rtems target. For example: That is because: ifeq ($(LIB2_DIVMOD_EXCEPTION_FLAGS),) # Provide default flags for compiling divmod functions, if they haven't been # set already by a target-specific Makefile fragment. LIB2_DIVMOD_EXCEPTION_FLAGS := -fexceptions -fnon-call-exceptions endif which is there so that e.g. Ada or other -fnon-call-exceptions languages can have properly working divisions. Thanks for the hint. It seems also the optimization level has an impact. The _Unwind_Resume dependency is only present if I use CFLAGS_FOR_TARGET="-O0 -g". -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
_Unwind_Resume() references in libgcc division functions
Hello,
I noticed that several division related routines provided by libgcc such
as __divdi3, __moddi3 and __umoddi3 have references to _Unwind_Resume
for the sparc-rtems target. For example:
.file "libgcc2.c"
! GNU C17 (GCC) version 13.0.0 20220621 (experimental) [master
r13-1187-gab981aab92c] (sparc-rtems6)
! compiled by GNU C version 12.1.1 20220517 [revision
325d82b08696da17fb26bd2e1b6ba607649357fb], GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version isl-0.16.1-GMP
! GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
! options passed: -msoft-float -mcpu=leon3 -g -g -g -O0 -O2 -O0
-fbuilding-libgcc -fno-stack-protector -fexceptions
-fnon-call-exceptions -fvisibility=hidden
.LLBE7:
.LLBE6:
! /home/EB/sebastian_h/src/gcc/libgcc/libgcc2.c:1225: w = __udivmoddi4
(uu.ll, vv.ll, (UDWtype *) 0);
.loc 1 1225 5
std %g2, [%fp-16] ! D.3900, w
! /home/EB/sebastian_h/src/gcc/libgcc/libgcc2.c:1226: if (c)
.loc 1 1226 6
ld [%fp-4], %g1! c, tmp284
cmp %g1, 0 ! tmp284,
be .LL25
nop!
b .LL28
nop!
.LL27:
mov %i0, %g1!, tmp283
mov %g1, %o0! D.3909,
.LLEHB2:
call_Unwind_Resume, 0
nop!,
.LL28:
Could someone please give me a hint, why the compiler generates this
code? I was unable to figure this out by looking at the pre-processed
code. I tried to reproduce it with a simple division by zero test case,
but this didn't work:
unsigned f(unsigned i)
{
return i / 0;
}
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
gnatlink vs. -mthumb -march=armv7-a+simd -mfloat-abi=hard
Hello, I test currently the Ada support for RTEMS in GCC 12. We have a -mthumb -march=armv7-a+simd -mfloat-abi=hard multilib for which the Ada RTS is built like this: make[4]: Entering directory '/tmp/sh/b-gcc-arm-rtems6/arm-rtems6/thumb/armv7-a+simd/hard/libada' make -C ../../../../.././gcc/ada "MAKEOVERRIDES=" "LDFLAGS=-mthumb -march=armv7-a+simd -mfloat-abi=hard" "LN_S=ln -s" "SHELL=/bin/sh" "GNATLIBFLAGS=-W -Wall -gnatpg -nostdinc -mthumb -march=armv7-a+simd -mfloat-abi=hard" "GNATLIBCFLAGS=-g -O2 -mthumb -march=armv7-a+simd -mfloat-abi=hard" "GNATLIBCFLAGS_FOR_C=-W -Wall -g -O2 -g -O2 -fexceptions -DIN_RTS -DHAVE_GETIPINFO -mthumb -march=armv7-a+simd -mfloat-abi=hard" "PICFLAG_FOR_TARGET=-fPIC" "THREAD_KIND=native" "TRACE=no" "MULTISUBDIR=/thumb/armv7-a+simd/hard" "libsubdir=/tmp/sh/i-arm-rtems6/lib64/gcc/arm-rtems6/12.0.1/thumb/armv7-a+simd/hard" "toolexeclibdir=/tmp/sh/i-arm-rtems6/lib64/gcc/arm-rtems6/12.0.1/thumb/armv7-a+simd/hard/adalib" "objext=.o" "prefix=/tmp/sh/i-arm-rtems6" "exeext=.exeext.should.not.be.used " 'CC=the.host.compiler.should.not.be.needed' "GCC_FOR_TARGET=/tmp/sh/b-gcc-arm-rtems6/./gcc/xgcc -B/tmp/sh/b-gcc-arm-rtems6/./gcc/ -nostdinc -B/tmp/sh/b-gcc-arm-rtems6/arm-rtems6/newlib/ -isystem /tmp/sh/b-gcc-arm-rtems6/arm-rtems6/newlib/targ-include -isystem /home/EB/sebastian_h/src/gcc/newlib/libc/include -B/tmp/sh/i-arm-rtems6/arm-rtems6/bin/ -B/tmp/sh/i-arm-rtems6/arm-rtems6/lib/ -isystem /tmp/sh/i-arm-rtems6/arm-rtems6/include -isystem /tmp/sh/i-arm-rtems6/arm-rtems6/sys-include " "CFLAGS=-g -O2 -mthumb -march=armv7-a+simd -mfloat-abi=hard" ./bldtools/oscons/xoscons When I try to link a test application I get this error: arm-rtems7-gnatlink /tmp/sh/b-rtems/arm/realview_pbx_a9_qemu/testsuites/ada/samples/nsecs/nsecs.ali testsuites/ada/samples/nsecs/init.o -qnolinkcmds -T linkcmds.realview_pbx_a9_qemu -Wl,--wrap=printf -Wl,--wrap=puts -Wl,--wrap=putchar -L. -lrtemscpu -lrtemsbsp -lrtemstest -qrtems -mthumb -march=armv7-a+simd -mfloat-abi=hard -mtune=cortex-a9 -Wl,--gc-sections -L/home/EB/sebastian_h/src/rtems/bsps/arm/shared/start -L/home/EB/sebastian_h/src/rtems/bsps/arm/realview-pbx-a9/start -o /tmp/sh/b-rtems/arm/realview_pbx_a9_qemu/testsuites/ada/ada_nsecs.exe /opt/rtems/7/lib/gcc/arm-rtems7/12.0.1/thumb/armv7-a+simd/hard/adainclude/s-secsta.ads:288:9: sorry, unimplemented: Thumb-1 'hard-float' VFP ABI The s-secsta.ads seems to be from the right multilib directory (Thumb-2), however, I get a sorry message related to Thumb-1? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
MC/DC support for gcov?
Hello,
gcov supports currently branch coverage. Some projects require modified
condition/decision coverage (MC/DC):
https://en.wikipedia.org/wiki/Modified_condition/decision_coverage
In general, 100% branch coverage does not imply 100% MC/DC coverage:
https://www.adacore.com/uploads_gems/Couverture_ERTS-2012.pdf
The paper contains a criterion under which 100% branch coverage implies
100% MC/DC coverage:
"Theorem 1 If the BDD of a decision D is a tree (with
only one path from the root to any condition node),
then BDD edge coverage implies MCDC"
The BDD is the Binary Decision Diagram. I have no idea how the compiler
and the coverage supports works in GCC. Is this BDD available for the
coverage support and could the coverage support check for this property
and then for example add it to the gcov information? If the BDD of a
decision is not a tree, then we would have to record which paths through
the BDD are covered to get the MC/DC coverage. This would require extra
storage and instrumentation. According to the paper, the BDD is usually
a tree in real world applications. Does this sound like feasible feature
for GCC? Could it be even a GSoC project?
Kind regards,
Sebastian
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: [PATCH v2] Document that the 'access' and 'nonnull' attributes are independent
On 23/03/2022 17:31, Martin Sebor via Gcc-patches wrote:
The concern is that the constraints implied by atttributes access and
nonnull are independent of each other. I would suggest to document
that without talking about dereferencing because that's not implied
by either of them. E.g., something like this (feel free to tweak it
as you see fit):
Note that the @code{access} attribute doesn't imply the same
constraint as attribute @code{nonnull} (@pxref{Attribute nonnull}).
The latter attribute should be used to annotate arguments that must
never be null, regardless of the value of the size argument.
I would not give an advice on using the nonnull attribute here. This
attribute could have pretty dangerous effects in the function definition
(removal of null pointer checks).
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: gcc_assert() and inhibit_libc
On 16/08/2021 18:50, Jason Merrill wrote: On Mon, Aug 16, 2021 at 9:51 AM Sebastian Huber wrote: On 16/08/2021 14:33, Martin Liška wrote: On 8/12/21 4:31 PM, Sebastian Huber wrote: This would be suitable for me, however, I am not sure if you want such a customization feature just for a niche operating system. I don't see a reason why not. Please send a patch. Ok, good. I will try to figure out what can be done. One problem is that tsystem.h is included before tm.h. Independent of this Joseph S. Myers said in the recent patch review with respect to the gcov_type size that removing tm.h from the target libraries is a development goal. I guess we have a couple of options. 1. Detect the presence of __assert_func and add the result to tconfig.h. This can't be a link time check, since libgcc is build before Newlib. 2. Use __builtin_trap() instead of abort() if inhibit_libc is defined. I still think this seems the most straightforward approach. I sent a patch for this: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577544.html -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: gcc_assert() and inhibit_libc
On 16/08/2021 14:33, Martin Liška wrote: On 8/12/21 4:31 PM, Sebastian Huber wrote: This would be suitable for me, however, I am not sure if you want such a customization feature just for a niche operating system. I don't see a reason why not. Please send a patch. Ok, good. I will try to figure out what can be done. One problem is that tsystem.h is included before tm.h. Independent of this Joseph S. Myers said in the recent patch review with respect to the gcov_type size that removing tm.h from the target libraries is a development goal. I guess we have a couple of options. 1. Detect the presence of __assert_func and add the result to tconfig.h. This can't be a link time check, since libgcc is build before Newlib. 2. Use __builtin_trap() instead of abort() if inhibit_libc is defined. The trap builtin is target-specific. Making this system-specific (in this case RTEMS) could be an issue. 3. Add a new target hook for the gcc_assert() failure. This has the same problem as 2. with respect to customization by system and not architecture. 4. Disable gcc_assert() if inhibit_libc is defined. 5. Use builtin __rtems__ define in tsystem.h as a hack. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: gcc_assert() and inhibit_libc
On 12/08/2021 16:29, Martin Liška wrote: On 8/12/21 4:12 PM, Sebastian Huber wrote: On 12/08/2021 16:08, Martin Liška wrote: On 7/21/21 2:44 PM, Sebastian Huber wrote: Hello, while testing this patch https://www.google.com/search?client=firefox-b-e&q=gcc+enable_runtime_checking I noticed that __gcov_info_to_gcda() uses abort(). This is due to (from tsystem.h): #ifdef ENABLE_RUNTIME_CHECKING #define gcc_assert(EXPR) ((void)(!(EXPR) ? abort (), 0 : 0)) #else /* Include EXPR, so that unused variable warnings do not occur. */ #define gcc_assert(EXPR) ((void)(0 && (EXPR))) #endif In tsystem.h there is this if inhibit_libc is defined: #ifndef abort extern void abort (void) __attribute__ ((__noreturn__)); #endif Who is supposed to define abort here optionally? Can this be defined for example by a target configuration header like gcc/config/rtems.h? Apparently, it's a hairy revision: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=7e7de68b8938 What happens now on RTERM where you have inhibit_libc set to true? Do you end up with an undefined symbol? No, we have abort() in RTEMS (from Newlib). The problem is that abort() is a very heavy weight function which pulls in the signal and file streams support. Oh, I see. In case of RTEMS, the application and the operating system is statically linked into one executable. The more features an application uses the bigger will be the executable. The abort() function pulls in a lot of stuff since it uses signals and may attempt to close all open streams. It would be nice if the gcc_assert() could be customized by the target configuration. For RTEMS we could use the Newlib defined __assert_func() from : # define assert(__e) ((__e) ? (void)0 : __assert_func (__FILE__, __LINE__, \ __ASSERT_FUNC, #__e)) void __assert_func (const char *, int, const char *, const char *) _ATTRIBUTE ((__noreturn__)); Then what about adding a condition to gcc/tsystem.h where where you would define a different gcc_assert based on rtems target? This would be suitable for me, however, I am not sure if you want such a customization feature just for a niche operating system. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: gcc_assert() and inhibit_libc
On 12/08/2021 16:08, Martin Liška wrote: On 7/21/21 2:44 PM, Sebastian Huber wrote: Hello, while testing this patch https://www.google.com/search?client=firefox-b-e&q=gcc+enable_runtime_checking I noticed that __gcov_info_to_gcda() uses abort(). This is due to (from tsystem.h): #ifdef ENABLE_RUNTIME_CHECKING #define gcc_assert(EXPR) ((void)(!(EXPR) ? abort (), 0 : 0)) #else /* Include EXPR, so that unused variable warnings do not occur. */ #define gcc_assert(EXPR) ((void)(0 && (EXPR))) #endif In tsystem.h there is this if inhibit_libc is defined: #ifndef abort extern void abort (void) __attribute__ ((__noreturn__)); #endif Who is supposed to define abort here optionally? Can this be defined for example by a target configuration header like gcc/config/rtems.h? Apparently, it's a hairy revision: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=7e7de68b8938 What happens now on RTERM where you have inhibit_libc set to true? Do you end up with an undefined symbol? No, we have abort() in RTEMS (from Newlib). The problem is that abort() is a very heavy weight function which pulls in the signal and file streams support. In case of RTEMS, the application and the operating system is statically linked into one executable. The more features an application uses the bigger will be the executable. The abort() function pulls in a lot of stuff since it uses signals and may attempt to close all open streams. It would be nice if the gcc_assert() could be customized by the target configuration. For RTEMS we could use the Newlib defined __assert_func() from : # define assert(__e) ((__e) ? (void)0 : __assert_func (__FILE__, __LINE__, \ __ASSERT_FUNC, #__e)) void __assert_func (const char *, int, const char *, const char *) _ATTRIBUTE ((__noreturn__)); -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: get_gcov_type() vs. -fprofile-update=atomic
On 10/08/2021 09:59, Richard Biener wrote: On Tue, Aug 10, 2021 at 8:07 AM Sebastian Huber wrote: On 09/08/2021 14:13, Richard Biener wrote: But I guess using 32bit counters on sparc-rtems might be the way to go ... Yes, you somehow just have to make sure that your test programs don't overflow the counters. Right - thus in principle it would be "nice" to allow to alter this with a command-line switch (even per TU in case 64bit is slow). Setting the gcov type size per TU would require to store this information in the object so that libgcov is able to know which type size was used (probably somewhere in struct gcov_info). Currently, the gcov type size for libgcov is hard coded in "libgcc/libgcov.h": #if __CHAR_BIT__ == 8 typedef unsigned gcov_unsigned_t __attribute__ ((mode (SI))); typedef unsigned gcov_position_t __attribute__ ((mode (SI))); #if GCOV_TYPE_SIZE > 32 typedef signed gcov_type __attribute__ ((mode (DI))); typedef unsigned gcov_type_unsigned __attribute__ ((mode (DI))); #else typedef signed gcov_type __attribute__ ((mode (SI))); typedef unsigned gcov_type_unsigned __attribute__ ((mode (SI))); #endif #else #if __CHAR_BIT__ == 16 typedef unsigned gcov_unsigned_t __attribute__ ((mode (HI))); typedef unsigned gcov_position_t __attribute__ ((mode (HI))); #if GCOV_TYPE_SIZE > 32 typedef signed gcov_type __attribute__ ((mode (SI))); typedef unsigned gcov_type_unsigned __attribute__ ((mode (SI))); #else typedef signed gcov_type __attribute__ ((mode (HI))); typedef unsigned gcov_type_unsigned __attribute__ ((mode (HI))); #endif #else typedef unsigned gcov_unsigned_t __attribute__ ((mode (QI))); typedef unsigned gcov_position_t __attribute__ ((mode (QI))); #if GCOV_TYPE_SIZE > 32 typedef signed gcov_type __attribute__ ((mode (HI))); typedef unsigned gcov_type_unsigned __attribute__ ((mode (HI))); #else typedef signed gcov_type __attribute__ ((mode (QI))); typedef unsigned gcov_type_unsigned __attribute__ ((mode (QI))); #endif #endif #endif Why is the mode attribute used here? Wouldn't this work also? I suppose this is historic. typedef gcov_unsigned_t __UINT32_TYPE__; typedef gcov_position_t __UINT32_TYPE__; #if GCOV_TYPE_SIZE > 32 typedef gcov_type __INT64_TYPE__; typedef gcov_type_unsigned __UINT64_TYPE__; #else typedef gcov_type __INT32_TYPE__; typedef gcov_type_unsigned __UINT32_TYPE__; #endif Or simply use stdint.h names, since this is for the target GCC arranges for an appropriate stdint header. No, including doesn't work: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576838.html The GCC provided does an # include_next if __STDC_HOSTED__ is defined. Maybe this could be fixed by using -ffreestanding if inhibit_libc is defined but I don't want to touch the build system if it is not absolutely necessary. blaming a bit yields commit 9b514d25867f14eb1b430765ba6d5083e592fcd7 Author: Nathan Sidwell Date: Sat May 10 19:02:21 2003 + defaults.h (GCOV_TYPE_SIZE): Remove. * defaults.h (GCOV_TYPE_SIZE): Remove. ... so - as we're about to re-introduce that let's as Nathan if he remembers why we removed it ;) (well, no target overrided the macro) Also the -fprofile-update=atomic didn't exist at the time (it was introduced 2016). -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: get_gcov_type() vs. -fprofile-update=atomic
On 09/08/2021 14:13, Richard Biener wrote: But I guess using 32bit counters on sparc-rtems might be the way to go ... Yes, you somehow just have to make sure that your test programs don't overflow the counters. Right - thus in principle it would be "nice" to allow to alter this with a command-line switch (even per TU in case 64bit is slow). Setting the gcov type size per TU would require to store this information in the object so that libgcov is able to know which type size was used (probably somewhere in struct gcov_info). Currently, the gcov type size for libgcov is hard coded in "libgcc/libgcov.h": #if __CHAR_BIT__ == 8 typedef unsigned gcov_unsigned_t __attribute__ ((mode (SI))); typedef unsigned gcov_position_t __attribute__ ((mode (SI))); #if GCOV_TYPE_SIZE > 32 typedef signed gcov_type __attribute__ ((mode (DI))); typedef unsigned gcov_type_unsigned __attribute__ ((mode (DI))); #else typedef signed gcov_type __attribute__ ((mode (SI))); typedef unsigned gcov_type_unsigned __attribute__ ((mode (SI))); #endif #else #if __CHAR_BIT__ == 16 typedef unsigned gcov_unsigned_t __attribute__ ((mode (HI))); typedef unsigned gcov_position_t __attribute__ ((mode (HI))); #if GCOV_TYPE_SIZE > 32 typedef signed gcov_type __attribute__ ((mode (SI))); typedef unsigned gcov_type_unsigned __attribute__ ((mode (SI))); #else typedef signed gcov_type __attribute__ ((mode (HI))); typedef unsigned gcov_type_unsigned __attribute__ ((mode (HI))); #endif #else typedef unsigned gcov_unsigned_t __attribute__ ((mode (QI))); typedef unsigned gcov_position_t __attribute__ ((mode (QI))); #if GCOV_TYPE_SIZE > 32 typedef signed gcov_type __attribute__ ((mode (HI))); typedef unsigned gcov_type_unsigned __attribute__ ((mode (HI))); #else typedef signed gcov_type __attribute__ ((mode (QI))); typedef unsigned gcov_type_unsigned __attribute__ ((mode (QI))); #endif #endif #endif Why is the mode attribute used here? Wouldn't this work also? typedef gcov_unsigned_t __UINT32_TYPE__; typedef gcov_position_t __UINT32_TYPE__; #if GCOV_TYPE_SIZE > 32 typedef gcov_type __INT64_TYPE__; typedef gcov_type_unsigned __UINT64_TYPE__; #else typedef gcov_type __INT32_TYPE__; typedef gcov_type_unsigned __UINT32_TYPE__; #endif -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: get_gcov_type() vs. -fprofile-update=atomic
On 09/08/2021 14:13, Richard Biener wrote: Ok, something like this? Yeah, plus in defaults.h do #ifndef GCOV_TYPE_SIZE #define GCOV_TYPE_SIZE (LONG_LONG_TYPE_SIZE > 32 ? 64 : 32) #endif Thanks for your help. I didn't know this file. It gives a nice overview what targets can define. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: get_gcov_type() vs. -fprofile-update=atomic
On 09/08/2021 13:27, Richard Biener wrote:
Can you not implement 64bit atomic support for 32bit SPARC somehow?
The 32-bit SPARC/LEON3 has only a 32-bit compare and swap instruction
(gcc/config/sparc/sync.md). I don't know how you could implement a
64-bit atomic support using this without spin locks (this is how
libatomic support for RTEMS works).
I see. Note the above get_gcov_type_could_ use a separate target macro
instead of LONG_LONG_TYPE_SIZE (GCOV_TYPE_SIZE?), that
way targets could opt to use a smaller counter.
Ok, something like this?
diff --git a/gcc/config/sparc/rtemself.h b/gcc/config/sparc/rtemself.h
index fa972af640cc..ac4f70c48c43 100644
--- a/gcc/config/sparc/rtemself.h
+++ b/gcc/config/sparc/rtemself.h
@@ -40,3 +40,5 @@
/* Use the default */
#undef LINK_GCC_C_SEQUENCE_SPEC
+
+#define GCOV_TYPE_SIZE 32
diff --git a/gcc/coverage.c b/gcc/coverage.c
index ac9a9fdad228..51297665e7f4 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -146,7 +146,7 @@ tree
get_gcov_type (void)
{
scalar_int_mode mode
-= smallest_int_mode_for_size (LONG_LONG_TYPE_SIZE > 32 ? 64 : 32);
+= smallest_int_mode_for_size (GCOV_TYPE_SIZE > 32 ? 64 : 32);
return lang_hooks.types.type_for_mode (mode, false);
}
diff --git a/gcc/tree-profile.c b/gcc/tree-profile.c
index 5a74cc96e132..b7f3f445d05b 100644
--- a/gcc/tree-profile.c
+++ b/gcc/tree-profile.c
@@ -250,7 +250,7 @@ gimple_gen_edge_profiler (int edgeno, edge e)
{
/* __atomic_fetch_add (&counter, 1, MEMMODEL_RELAXED); */
tree addr = tree_coverage_counter_addr (GCOV_COUNTER_ARCS, edgeno);
- tree f = builtin_decl_explicit (LONG_LONG_TYPE_SIZE > 32
+ tree f = builtin_decl_explicit (GCOV_TYPE_SIZE > 32
? BUILT_IN_ATOMIC_FETCH_ADD_8:
BUILT_IN_ATOMIC_FETCH_ADD_4);
gcall *stmt = gimple_build_call (f, 3, addr, one,
@@ -525,7 +525,7 @@ gimple_gen_time_profiler (unsigned tag)
tree_time_profiler_counter);
gassign *assign = gimple_build_assign (ptr, NOP_EXPR, addr);
gsi_insert_before (&gsi, assign, GSI_NEW_STMT);
- tree f = builtin_decl_explicit (LONG_LONG_TYPE_SIZE > 32
+ tree f = builtin_decl_explicit (GCOV_TYPE_SIZE > 32
? BUILT_IN_ATOMIC_ADD_FETCH_8:
BUILT_IN_ATOMIC_ADD_FETCH_4);
gcall *stmt = gimple_build_call (f, 3, ptr, one,
Note that it isn't currently feasible to for example use a 32bit gcov type
with =atomic but 64bit with =single since the "ABI" of the gcov data isn't
self-descriptive in this aspect. But it should be possible to record the
counter size in the meta-data and keep the on-disk format use "big"
counters in theory.
The on-disk format shouldn't be an issue since we have:
/* Dump the COUNTER using the DUMP handler called with ARG. */
static inline void
dump_counter (gcov_type counter,
void (*dump_fn) (const void *, unsigned, void *),
void *arg)
{
dump_unsigned ((gcov_unsigned_t)counter, dump_fn, arg);
if (sizeof (counter) > sizeof (gcov_unsigned_t))
dump_unsigned ((gcov_unsigned_t)(counter >> 32), dump_fn, arg);
else
dump_unsigned (0, dump_fn, arg);
}
But I guess using 32bit counters on sparc-rtems might be the way to
go ...
Yes, you somehow just have to make sure that your test programs don't
overflow the counters.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: get_gcov_type() vs. -fprofile-update=atomic
On 09/08/2021 12:22, Richard Biener wrote:
On Mon, Aug 9, 2021 at 8:52 AM Sebastian Huber
wrote:
Hello,
I would like to use gcov for a multi-threaded program running on an SMP
machine using a 32-bit SPARC/LEON3 target. This target supports
HAVE_atomic_compare_and_swapsi but not HAVE_atomic_compare_and_swapdi.
Unfortunately we have:
/* Return the type node for gcov_type. */
tree
get_gcov_type (void)
{
scalar_int_mode mode
= smallest_int_mode_for_size (LONG_LONG_TYPE_SIZE > 32 ? 64 : 32);
return lang_hooks.types.type_for_mode (mode, false);
}
The long long type is 64-bit, the get_gcov_type() returns a 64-bit type.
This disables the atomic support in tree_profiling().
For what is the gcov type used? Could we add an option to force it to
32-bit? What would be the consequences?
It's a generic counter used for number of CFG edge traversal tracking.
So I guess if this counter overflows, then you get inconsistent
coverage/profiling information?
Can you not implement 64bit atomic support for 32bit SPARC somehow?
The 32-bit SPARC/LEON3 has only a 32-bit compare and swap instruction
(gcc/config/sparc/sync.md). I don't know how you could implement a
64-bit atomic support using this without spin locks (this is how
libatomic support for RTEMS works).
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: get_gcov_type() vs. -fprofile-update=atomic
On 09/08/2021 08:51, Sebastian Huber wrote:
Hello,
I would like to use gcov for a multi-threaded program running on an SMP
machine using a 32-bit SPARC/LEON3 target. This target supports
HAVE_atomic_compare_and_swapsi but not HAVE_atomic_compare_and_swapdi.
Unfortunately we have:
/* Return the type node for gcov_type. */
tree
get_gcov_type (void)
{
scalar_int_mode mode
= smallest_int_mode_for_size (LONG_LONG_TYPE_SIZE > 32 ? 64 : 32);
return lang_hooks.types.type_for_mode (mode, false);
}
The long long type is 64-bit, the get_gcov_type() returns a 64-bit type.
This disables the atomic support in tree_profiling().
For what is the gcov type used? Could we add an option to force it to
32-bit? What would be the consequences?
Another option would be to add something like an
-fprofile-update=force-atomic option which would resort to libatomic.
Which would deliver bad performance, however, correct results in a
multi-threaded program I guess.
Here is a proposed patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576947.html
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
get_gcov_type() vs. -fprofile-update=atomic
Hello,
I would like to use gcov for a multi-threaded program running on an SMP
machine using a 32-bit SPARC/LEON3 target. This target supports
HAVE_atomic_compare_and_swapsi but not HAVE_atomic_compare_and_swapdi.
Unfortunately we have:
/* Return the type node for gcov_type. */
tree
get_gcov_type (void)
{
scalar_int_mode mode
= smallest_int_mode_for_size (LONG_LONG_TYPE_SIZE > 32 ? 64 : 32);
return lang_hooks.types.type_for_mode (mode, false);
}
The long long type is 64-bit, the get_gcov_type() returns a 64-bit type.
This disables the atomic support in tree_profiling().
For what is the gcov type used? Could we add an option to force it to
32-bit? What would be the consequences?
Another option would be to add something like an
-fprofile-update=force-atomic option which would resort to libatomic.
Which would deliver bad performance, however, correct results in a
multi-threaded program I guess.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: gcc_assert() and inhibit_libc
On 22/07/2021 14:15, Richard Biener wrote: On Wed, Jul 21, 2021 at 2:45 PM Sebastian Huber wrote: Hello, while testing this patch https://www.google.com/search?client=firefox-b-e&q=gcc+enable_runtime_checking I noticed that __gcov_info_to_gcda() uses abort(). This is due to (from tsystem.h): #ifdef ENABLE_RUNTIME_CHECKING #define gcc_assert(EXPR) ((void)(!(EXPR) ? abort (), 0 : 0)) #else /* Include EXPR, so that unused variable warnings do not occur. */ #define gcc_assert(EXPR) ((void)(0 && (EXPR))) #endif In tsystem.h there is this if inhibit_libc is defined: #ifndef abort extern void abort (void) __attribute__ ((__noreturn__)); #endif Who is supposed to define abort here optionally? Can this be defined for example by a target configuration header like gcc/config/rtems.h? I suppose for inhibit_libc we could use __builtin_trap () (but that might expand to abort() on some targets) In case of RTEMS, the application and the operating system is statically linked into one executable. The more features an application uses the bigger will be the executable. The abort() function pulls in a lot of stuff since it uses signals and may attempt to close all open streams. It would be nice if the gcc_assert() could be customized by the target configuration. For RTEMS we could use the Newlib defined __assert_func() from : # define assert(__e) ((__e) ? (void)0 : __assert_func (__FILE__, __LINE__, \ __ASSERT_FUNC, #__e)) void __assert_func (const char *, int, const char *, const char *) _ATTRIBUTE ((__noreturn__)); -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
gcc_assert() and inhibit_libc
Hello, while testing this patch https://www.google.com/search?client=firefox-b-e&q=gcc+enable_runtime_checking I noticed that __gcov_info_to_gcda() uses abort(). This is due to (from tsystem.h): #ifdef ENABLE_RUNTIME_CHECKING #define gcc_assert(EXPR) ((void)(!(EXPR) ? abort (), 0 : 0)) #else /* Include EXPR, so that unused variable warnings do not occur. */ #define gcc_assert(EXPR) ((void)(0 && (EXPR))) #endif In tsystem.h there is this if inhibit_libc is defined: #ifndef abort extern void abort (void) __attribute__ ((__noreturn__)); #endif Who is supposed to define abort here optionally? Can this be defined for example by a target configuration header like gcc/config/rtems.h? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: How to avoid that compiler generated objects get optimized away?
On 14/07/2021 09:33, Richard Biener wrote: I tried to add a TREE_USED (var) = 1, but this seems to have no effect. Could someone give me a hint what needs to be added so that this object is created? The object is placed in a linker set. You can call mark_decl_referenced (var), TREE_USED is only used by frontends. Thanks, this worked. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
How to avoid that compiler generated objects get optimized away?
Hello,
I noticed that the following static read-only object gets optimized away
if optimization is enabled:
/* Generate the pointer to the gcov_info_var in a dedicated section. */
static void
build_gcov_info_var_registration (tree gcov_info_type)
{
tree var = build_decl (BUILTINS_LOCATION,
VAR_DECL, NULL_TREE,
build_pointer_type (gcov_info_type));
TREE_STATIC (var) = 1;
TREE_READONLY (var) = 1;
char name_buf[32];
ASM_GENERATE_INTERNAL_LABEL (name_buf, "LPBX", 2);
DECL_NAME (var) = get_identifier (name_buf);
get_section (profile_info_section, SECTION_UNNAMED, NULL);
set_decl_section_name (var, profile_info_section);
DECL_INITIAL (var) = build_fold_addr_expr (gcov_info_var);
varpool_node::finalize_decl (var);
}
I tried to add a TREE_USED (var) = 1, but this seems to have no effect.
Could someone give me a hint what needs to be added so that this object
is created? The object is placed in a linker set.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: How can operating systems add linker flags to the GCC specs?
On 22/01/2021 10:46, Sebastian Huber wrote:
Hello,
for RTEMS we have in gcc/config/rtems.h the following LIB_SPEC:
#undef LIB_SPEC
#define LIB_SPEC "%{!qrtems:" STD_LIB_SPEC "} " \
"%{qrtems:%{!nostdlib:%{!nodefaultlibs:" \
"--start-group -lrtemsbsp -lrtemscpu -latomic -lc -lgcc --end-group} " \
"%{!qnolinkcmds:-T linkcmds%s}}}"
The intention was that a GCC command line to link an executable with
-qrtems -nodefaultlibs
still uses "-T linkcmds", however, this didn't work. I think this is
due to
*link_gcc_c_sequence:
%G %{!nolibc:%L %G}
*link_command:
... %{!nostdlib:%{!r:%{!nodefaultlibs:%(link_ssp)
%(link_gcc_c_sequence)}}} ...
%(post_link) }}
So, if nodefaultlib is present, the LIB_SPEC is not evaluated at all?
The problem is that LINK_SPEC is specialized by target. For RTEMS, we
have to use the target definitions. In the default definition of
LINK_COMMAND_SPEC (gcc/gcc.c) there is no define for operating system
customization. Would it be possible to add something this?
I think the STARTFILES_SPEC can be used as a workaround:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564101.html
This avoids modifications in "gcc/gcc.c".
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
How can operating systems add linker flags to the GCC specs?
Hello,
for RTEMS we have in gcc/config/rtems.h the following LIB_SPEC:
#undef LIB_SPEC
#define LIB_SPEC "%{!qrtems:" STD_LIB_SPEC "} " \
"%{qrtems:%{!nostdlib:%{!nodefaultlibs:" \
"--start-group -lrtemsbsp -lrtemscpu -latomic -lc -lgcc --end-group} " \
"%{!qnolinkcmds:-T linkcmds%s}}}"
The intention was that a GCC command line to link an executable with
-qrtems -nodefaultlibs
still uses "-T linkcmds", however, this didn't work. I think this is due to
*link_gcc_c_sequence:
%G %{!nolibc:%L %G}
*link_command:
... %{!nostdlib:%{!r:%{!nodefaultlibs:%(link_ssp)
%(link_gcc_c_sequence)}}} ...
%(post_link) }}
So, if nodefaultlib is present, the LIB_SPEC is not evaluated at all?
The problem is that LINK_SPEC is specialized by target. For RTEMS, we
have to use the target definitions. In the default definition of
LINK_COMMAND_SPEC (gcc/gcc.c) there is no define for operating system
customization. Would it be possible to add something this?
diff --git a/gcc/config/rtems.h b/gcc/config/rtems.h
index 743161c4bac..a7cea9b1d2f 100644
--- a/gcc/config/rtems.h
+++ b/gcc/config/rtems.h
@@ -49,9 +49,9 @@
#undef LIB_SPEC
#define LIB_SPEC "%{!qrtems:" STD_LIB_SPEC "} " \
-"%{qrtems:%{!nostdlib:%{!nodefaultlibs:" \
-"--start-group -lrtemsbsp -lrtemscpu -latomic -lc -lgcc --end-group} " \
-"%{!qnolinkcmds:-T linkcmds%s}}}"
+"%{qrtems:--start-group -lrtemsbsp -lrtemscpu -latomic -lc -lgcc
--end-group}"
+
+#define SYSTEM_LINK_SPEC "%{qrtems:%{!qnolinkcmds:-T linkcmds%s}}"
#define TARGET_POSIX_IO
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 7dccfadfef2..eff72cb3412 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -1107,6 +1107,11 @@ proper position among the other output files. */
%{%:sanitize(leak):" LIBLSAN_SPEC ""
#endif
+/* Linker command line options defined by the operating system. */
+#ifndef SYSTEM_LINK_SPEC
+#define SYSTEM_LINK_SPEC ""
+#endif
+
#ifndef POST_LINK_SPEC
#define POST_LINK_SPEC ""
#endif
@@ -1158,7 +1163,8 @@ proper position among the other output files. */
%:include(libgomp.spec)%(link_gomp)}\
%{fgnu-tm:%:include(libitm.spec)%(link_itm)}\
%(mflib) " STACK_SPLIT_SPEC "\
- %{fprofile-arcs|fprofile-generate*|coverage:-lgcov} "
SANITIZER_SPEC " \
+ %{fprofile-arcs|fprofile-generate*|coverage:-lgcov} " \
+ SANITIZER_SPEC " " SYSTEM_LINK_SPEC " \
%{!nostdlib:%{!r:%{!nodefaultlibs:%(link_ssp)
%(link_gcc_c_sequence)}}}\
%{!nostdlib:%{!r:%{!nostartfiles:%E}}} %{T*} \n%(post_link) }}"
#endif
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: nios2 -mcustom-round vs. libatomic
On 14/01/2021 15:16, Sebastian Huber wrote: Hello, I try to add a nios2 multilib to support the "Nios II Floating Point Hardware 2 Component": https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_nios2_custom_instruction.pdf If I add all custom instructions supported by the component, then I get an error in libatomic since -Werror is used: cc1: error: switch '-mcustom-fmins' has no effect unless '-ffinite-math-only' is specified [-Werror] cc1: error: switch '-mcustom-fmaxs' has no effect unless '-ffinite-math-only' is specified [-Werror] cc1: error: switch '-mcustom-round' has no effect unless '-fno-math-errno' is specified [-Werror] I am not sure how to fix this. Is a compiler warning the right diagnostic for an inconsistent use of compiler options? This warning is not related to code processed by GCC. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
nios2 -mcustom-round vs. libatomic
Hello, I try to add a nios2 multilib to support the "Nios II Floating Point Hardware 2 Component": https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_nios2_custom_instruction.pdf If I add all custom instructions supported by the component, then I get an error in libatomic since -Werror is used: cc1: error: switch '-mcustom-fmins' has no effect unless '-ffinite-math-only' is specified [-Werror] cc1: error: switch '-mcustom-fmaxs' has no effect unless '-ffinite-math-only' is specified [-Werror] cc1: error: switch '-mcustom-round' has no effect unless '-fno-math-errno' is specified [-Werror] I am not sure how to fix this. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: GCC's instrumentation and the target environment
Hello David,
I also would like to use GCC to get code coverage on an embedded system.
My approach would be to place the gcov information in a dedicated linker
set:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559004.html
Please have a look at the attached patches for a proposal to get the
data from the target.
--
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
Phone: +49-89-18 94 741 - 16
Fax: +49-89-18 94 741 - 08
PGP: Public key available on request.
embedded brains GmbH
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
>From ace43807e322dbdb075e507d9a84e676d4c34c64 Mon Sep 17 00:00:00 2001
From: Sebastian Huber
Date: Sat, 14 Nov 2020 13:51:09 +0100
Subject: [PATCH 1/2] gcov: Add and use gcov_are_all_counters_zero()
libgcc/
libgcov.h (gcov_are_all_counters_zero): New.
libgcov-driver.c (write_one_data): Use gcov_are_all_counters_zero().
---
libgcc/libgcov-driver.c | 12 ++--
libgcc/libgcov.h| 12
2 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/libgcc/libgcov-driver.c b/libgcc/libgcov-driver.c
index e53e4dc392a..ba308438474 100644
--- a/libgcc/libgcov-driver.c
+++ b/libgcc/libgcov-driver.c
@@ -428,16 +428,8 @@ write_one_data (const struct gcov_info *gi_ptr,
write_top_counters (ci_ptr, t_ix, n_counts);
else
{
- /* Do not stream when all counters are zero. */
- int all_zeros = 1;
- for (unsigned i = 0; i < n_counts; i++)
- if (ci_ptr->values[i] != 0)
- {
- all_zeros = 0;
- break;
- }
-
- if (all_zeros)
+ if (gcov_are_all_counters_zero (ci_ptr))
+ /* Do not stream when all counters are zero. */
gcov_write_tag_length (GCOV_TAG_FOR_COUNTER (t_ix),
GCOV_TAG_COUNTER_LENGTH (-n_counts));
else
diff --git a/libgcc/libgcov.h b/libgcc/libgcov.h
index e70cf63b414..915a1b1530d 100644
--- a/libgcc/libgcov.h
+++ b/libgcc/libgcov.h
@@ -304,6 +304,18 @@ extern void __gcov_average_profiler_atomic (gcov_type *, gcov_type);
extern void __gcov_ior_profiler (gcov_type *, gcov_type);
extern void __gcov_ior_profiler_atomic (gcov_type *, gcov_type);
+/* Return 1, if all counter values are zero, otherwise 0. */
+
+static inline int
+gcov_are_all_counters_zero (const struct gcov_ctr_info *ci_ptr)
+{
+ for (unsigned i = 0; i < ci_ptr->num; i++)
+if (ci_ptr->values[i] != 0)
+ return 0;
+
+ return 1;
+}
+
#ifndef inhibit_libc
/* The wrappers around some library functions.. */
extern pid_t __gcov_fork (void) ATTRIBUTE_HIDDEN;
--
2.26.2
>From 9235be68b52ee7b321d985fe2d82a38d685ffb4f Mon Sep 17 00:00:00 2001
From: Sebastian Huber
Date: Fri, 13 Nov 2020 22:01:14 +0100
Subject: [PATCH 2/2] gcov: Add __gcov_info_to_gdca()
libgcc/
Makefile.in: Add libgcov-info-to-gcda.c to libgcov.a.
gcov.h (gcov_info): Declare.
(__gcov_info_to_gdca): Likewise.
libgcov-info-to-gcda.c: New.
---
libgcc/Makefile.in| 7 ++-
libgcc/gcov.h | 9 +++
libgcc/libgcov-info-to-gcda.c | 106 ++
3 files changed, 121 insertions(+), 1 deletion(-)
create mode 100644 libgcc/libgcov-info-to-gcda.c
diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
index d6075d32bd4..ae8ddc23955 100644
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -909,13 +909,16 @@ LIBGCOV_INTERFACE = _gcov_dump _gcov_fork\
_gcov_execle _gcov_execv _gcov_execvp _gcov_execve _gcov_reset \
_gcov_lock_unlock
LIBGCOV_DRIVER = _gcov
+LIBGCOV_INFO_TO_GCDA = _gcov_info_to_gcda
libgcov-merge-objects = $(patsubst %,%$(objext),$(LIBGCOV_MERGE))
libgcov-profiler-objects = $(patsubst %,%$(objext),$(LIBGCOV_PROFILER))
libgcov-interface-objects = $(patsubst %,%$(objext),$(LIBGCOV_INTERFACE))
libgcov-driver-objects = $(patsubst %,%$(objext),$(LIBGCOV_DRIVER))
+libgcov-info-to-gcda-objects = $(patsubst %,%$(objext),$(LIBGCOV_INFO_TO_GCDA))
libgcov-objects = $(libgcov-merge-objects) $(libgcov-profiler-objects) \
- $(libgcov-interface-objects) $(libgcov-driver-objects)
+ $(libgcov-interface-objects) $(libgcov-driver-objects) \
+ $(libgcov-info-to-gcda-objects)
$(libgcov-merge-objects): %$(objext): $(srcdir)/libgcov-merge.c $(srcdir)/gcov.h $(srcdir)/libgcov.h
$(gcc_compile) -DL$* -c $(srcdir)/libgcov-merge.c
@@ -926,6 +929,8 @@ $(libgcov-interface-objects): %$(objext): $(srcdir)/libgcov-interface.c $(srcdir
$(libgcov-driver-objects): %$(objext): $(srcdir)/libgcov-driver.c \
$(srcdir)/libgcov-driver-system.c $(srcdir)/gcov.h $(srcdir)/libgcov.h
$(gcc_compile) -DL$* -c $(srcdir)/libgcov-driver.c
+$(libgcov-info-to-gcda-objects): %$(objext): $(srcdir)/libgcov-info-to-gcda.c $(srcdir)/gcov.h $(srcdir)/libgcov.h
+ $(gcc_compi
Re: Gcov info registration without constructor?
On 10/11/2020 17:23, Sebastian Huber wrote: I am not sure how I can make the new section read-only. Currently, it is writable: .section .gcov_info,"aw" .align 2 .type .LPBX2, @object .size .LPBX2, 4 .LPBX2: .long .LPBX0 I changed the section by adding: TREE_READONLY (var) = 1; get_section (profile_info_section, SECTION_UNNAMED, NULL); This is the generated data: .section .gcov_info,"a" .align 2 .type .LPBX2, @object .size .LPBX2, 4 .LPBX2: .long .LPBX0 .section .rodata .align 2 -- embedded brains GmbH Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de Phone: +49-89-18 94 741 - 16 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. embedded brains GmbH Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: Gcov info registration without constructor?
Hello Martin,
attached is a proof of concept. I am not sure how I can make the new
section read-only. Currently, it is writable:
.section .gcov_info,"aw"
.align 2
.type .LPBX2, @object
.size .LPBX2, 4
.LPBX2:
.long .LPBX0
I probably need also a patch for the GCC options documentation, test
cases, a GCC bootstrap on Linux, release notes, ...? Do I have to wait
for the GCC 11 development start?
--
embedded brains GmbH
Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
Phone: +49-89-18 94 741 - 16
Fax: +49-89-18 94 741 - 08
PGP: Public key available on request.
embedded brains GmbH
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
>From 305eb4066742418d3b14ee6e8bec76bfb2835a99 Mon Sep 17 00:00:00 2001
From: Sebastian Huber
Date: Tue, 10 Nov 2020 16:21:07 +0100
Subject: [PATCH] Add -fprofile-info-section support
---
gcc/common.opt | 8
gcc/coverage.c | 19 +--
gcc/opts.c | 4
3 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/gcc/common.opt b/gcc/common.opt
index 7d0e0d9c88a..1b69da681e3 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2268,6 +2268,14 @@ fprofile-generate=
Common Joined RejectNegative
Enable common options for generating profile info for profile feedback directed optimizations, and set -fprofile-dir=.
+fprofile-info-section
+Common RejectNegative
+Register a pointer to the profile information in the .gcov_info section.
+
+fprofile-info-section=
+Common Joined RejectNegative Var(profile_info_section)
+Register a pointer to the profile information in the named section.
+
fprofile-partial-training
Common Report Var(flag_profile_partial_training) Optimization
Do not assume that functions never executed during the train run are cold.
diff --git a/gcc/coverage.c b/gcc/coverage.c
index 7711412c3be..ec1c5d3d125 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -1151,8 +1151,23 @@ coverage_obj_init (void)
ASM_GENERATE_INTERNAL_LABEL (name_buf, "LPBX", 0);
DECL_NAME (gcov_info_var) = get_identifier (name_buf);
- build_init_ctor (gcov_info_type);
- build_gcov_exit_decl ();
+ if (profile_info_section)
+{
+ tree var = build_decl (BUILTINS_LOCATION,
+ VAR_DECL, NULL_TREE,
+ build_pointer_type (gcov_info_type));
+ TREE_STATIC (var) = 1;
+ ASM_GENERATE_INTERNAL_LABEL (name_buf, "LPBX", 2);
+ DECL_NAME (var) = get_identifier (name_buf);
+ set_decl_section_name (var, profile_info_section);
+ DECL_INITIAL (var) = build_fold_addr_expr (gcov_info_var);
+ varpool_node::finalize_decl (var);
+}
+ else
+{
+ build_init_ctor (gcov_info_type);
+ build_gcov_exit_decl ();
+}
return true;
}
diff --git a/gcc/opts.c b/gcc/opts.c
index 96291e89a49..fd6e669471e 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -2602,6 +2602,10 @@ common_handle_option (struct gcc_options *opts,
SET_OPTION_IF_UNSET (opts, opts_set, flag_ipa_bit_cp, value);
break;
+case OPT_fprofile_info_section:
+ opts->x_profile_info_section = ".gcov_info";
+ break;
+
case OPT_fpatchable_function_entry_:
{
char *patch_area_arg = xstrdup (arg);
--
2.26.2
Re: Gcov info registration without constructor?
Hallo Martin, On 10/11/2020 13:05, Martin Liška wrote: On 11/9/20 6:45 PM, Sebastian Huber wrote: Hello, Hello. There was a similar need some time ago: https://gcc.gnu.org/legacy-ml/gcc/2019-11/msg9.html Please take a look for a possible inspiration. thanks for the pointer. I would like to use the -ftest-coverage -fprofile-arcs support on a bare metal system (no operating system or very early stages in the system startup). In this environment I cannot use the gcov info registration via a constructor and __gcov_init(), because there may be some other (more complex) constructors registered which cannot be called at this stage.. Would it be acceptable to add a compiler option which changes the gcov info registration via a constructor to a linker set? If enabled, then for each translation unit (see coverage_obj_init()) a pointer to the gcov info is placed into a special linker section (for example .gcov_info). The linker script collects all .gcov_info data and adds a begin/end symbol. The runtime support can then iterate over all linker section entries (pointers to struct gcov_info) to dump the aggregated gcov data during program termination. Would such changes be acceptable for GCC integration or is this too specific? That's definitely something we can support. Similarly to the linked message, are you capable of using normal system I/O to stream .gcda files? I cannot use I/O to files. I also cannot use dynamic memory (e.g. malloc()). This is actually not an issue, since it is very easy to dump the gcov info via a simple character output function as plain text. In the Linux kernel see for example convert_to_gcda() in "kernel/gcov/gcc_4_7.c". Instead of copying the data to a buffer you can directly output the data via some printk() function. On the host computer you can collect the text and generate the .gcda files. I guess the first thing we need is a name for the option. What about: -fprofile-info-section -fprofile-info-section=name Register a pointer to the profile information generated by -fprofile-arcs in the named section for each translation unit. If name is not given, then .gcov_info will be used. This option disables the profile information registration through a constructor and it disables the profile information processing through a destructor. This option can be used to support profiling in environments which do not support constructors and destructors. The linker could collect the content of the named section in a continuous memory block and add begin and end symbols. The runtime support could dump the profiling information registered in this linker set during program termination to a serial line for example. -- embedded brains GmbH Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de Phone: +49-89-18 94 741 - 16 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. embedded brains GmbH Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Gcov info registration without constructor?
Hello, I would like to use the -ftest-coverage -fprofile-arcs support on a bare metal system (no operating system or very early stages in the system startup). In this environment I cannot use the gcov info registration via a constructor and __gcov_init(), because there may be some other (more complex) constructors registered which cannot be called at this stage.. Would it be acceptable to add a compiler option which changes the gcov info registration via a constructor to a linker set? If enabled, then for each translation unit (see coverage_obj_init()) a pointer to the gcov info is placed into a special linker section (for example .gcov_info). The linker script collects all .gcov_info data and adds a begin/end symbol. The runtime support can then iterate over all linker section entries (pointers to struct gcov_info) to dump the aggregated gcov data during program termination. Would such changes be acceptable for GCC integration or is this too specific? Kind regards, Sebastian -- embedded brains GmbH Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de Phone: +49-89-18 94 741 - 16 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. embedded brains GmbH Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
gcc-7-arm vendor branch
Hi, I would like to thank David Edelsohn for his help during the process of getting Amazon’s contributions to GCC covered by an FSF copyright assignment. As a first contribution, I would like to create a vendor branch for gcc-7 that will contain back-ported patches for Arm such as -moutline-atomics flag and missing NEON intrinsics. The branch will facilitate integration of these important changes in systems such as Ubuntu 18.04 and Amazon Linux 2 that are still relying on gcc-7. I will ask reviews and recommendations from Arm maintainers for the patches to be integrated in the gcc-7-arm branch. Thanks, Sebastian
Help porting a plugin to more recent GCC
Hi everybody, I'm trying to adapt an existing, open source GCC plugin so that it will work with more recent versions of GCC (it is currently working with 4.7 only). During my research I came across your suggestion on the Wiki[1] to get in touch if one has any questions concerning developing plugins, so I'll try this and see if anybody would be so kind to give me a little guidance! The plugin is GCC-Bridge of the Renjin project which has been discussed on this mailing list before[2]. It is part of an effort to create a JVM runtime for the R language. The GCC-Brigde plugin compiles Gimple to JVM bytecode to make that runtime possible. The original project lives here[3], however, I have created a fork[4] that concentrates on just the part that compiles C code to JVM bytecode. The plugin is currently written using the plugin API of GCC 4.7. Since 4.7 is not available on my current Ubuntu-based system any longer, I would like to migrate to a newer version. 4.8 is available on my system, so migrating to that version would suffice as a first step. I tried that, however compilation fails using gcc-4.8 and after some reading the docs and going through the GCC source code history it seems that 4.7 to 4.8 was a rather big evolution. If anyone wants to take a look at the error messages, I created a branch[5] that has everything set up so that you can just run the compiler and see what happens; the README[6] file contains the necessary compilation instructions. It also shows the current output of gcc-4.8 and the error messages it produces. The plugin consists of a single file[7]. It seems that a global variable called "varpool_nodes" is not available anymore and also the members of the struct varpool_node changed. I haven't been able to figure out a way to traverse the Gimple tree and data structures the way the plugin did with the older API. If anyone here is familiar with the changes to the plugin API from 4.7 to 4.8, maybe you have a few hints for me? Pointers to a different plugin that went through a migration from 4.7 to a newer version could also be very very helpful. Any ideas? Thank you! Sebastian [1] https://gcc.gnu.org/wiki/plugins [2] https://gcc.gnu.org/legacy-ml/gcc/2016-02/msg4.html [3] https://github.com/bedatadriven/renjin/ [4] https://github.com/mobanisto/gcc-bridge [5] https://github.com/mobanisto/gcc-bridge/tree/gcc-4.8 [6] https://github.com/mobanisto/gcc-bridge/blob/gcc-4.8/README.md [7] https://github.com/mobanisto/gcc-bridge/blob/gcc-4.8/compiler/src/main/resources/org/renjin/gcc/plugin.c
[AArch64] Backporting -moutline-atomics to gcc 9.x and 8.x
Hi, is somebody already working on backporting -moutline-atomics to gcc 8.x and 9.x branches? Thanks, Sebastian
Re: [PATCH] analyzer: fix build error with clang (PR 93543)
On 04/02/2020 16:45, David Malcolm wrote: On Tue, 2020-02-04 at 16:26 +0100, Jakub Jelinek wrote: On Tue, Feb 04, 2020 at 09:00:37AM -0500, David Malcolm wrote: gcc/analyzer/ChangeLog: PR analyzer/93543 * engine.cc (pod_hash_traits::mark_empty): Eliminate reinterpret_cast. (pod_hash_traits::is_empty): Likewise. This is ok for trunk. Thanks. This should now be fixed on master (r10-6434- g1dae549dccfec1edb0cb4e65feadc4722bb3bcc8); I verified the build with the patch with gcc, and Sebastian verified it with clang. Thanks a lot for the quick fix. The master builds now again.
GCC build error on FreeBSD 12.1 with LLVM 8.0.1
Hello,
I tried to build a recent GCC master on FreeBSD 12.1 and it failed with
a compile error:
$ clang --version
FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on
LLVM 8.0.1)
Target: x86_64-unknown-freebsd12.1
Thread model: posix
InstalledDir: /usr/bin
../../gnu-mirror-gcc-5bc9d2f5ed4/gcc/analyzer/engine.cc:2965:13: error:
reinterpret_cast from 'nullptr_t' to 'function *' is not allowed
v.m_fun = reinterpret_cast (NULL);
^~~
../../gnu-mirror-gcc-5bc9d2f5ed4/gcc/analyzer/engine.cc:2977:21: error:
reinterpret_cast from 'nullptr_t' to 'function *' is not allowed
return v.m_fun == reinterpret_cast (NULL);
^~~
This simple test program fails also:
struct function;
function *f(void)
{
return reinterpret_cast(nullptr);
}
$ clang -c test.cc
test.cc:5:10: error: reinterpret_cast from 'nullptr_t' to 'function *'
is not allowed
return reinterpret_cast(nullptr);
^
1 error generated.
I was able to build the GCC master on January 2nd 2020. Does this look
like an LLVM 8.0.1 issue or a GCC issue?
Re: For which gcc release is going to be foreseen the support for the Coroutines TS extension?
Hello, On 06/06/2018 08:33, Florian Weimer wrote: On 06/04/2018 07:36 PM, Jonathan Wakely wrote: On 4 June 2018 at 18:32, Marco Ippolito wrote: Hi all, clang and VS2017 already support the Coroutines TS extensions. For which gcc release is going to be foreseen the support for the Coroutines TS extension? This has been discussed recently, search the mailing list. It will be supported after somebody implements it. If it is in fact implementable on top of the GNU ABI. Some variants of coroutines are not. it seems C++20 will contain coroutines. Are there already some plans to support them in GCC? I ask this so that I can plan my work to support it for RTEMS. For example, are there plans to build them on top of ucontext? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Gcov Internals
Hi, I am currently trying to understand the internals of Gcov. Specifically I am wondering of the following: 1) Certain Basic Blocks are instrumented with counters that are incremented during execution. During compilation a destructor is registered that actually goes through a gcov_info struct and finds all counters in the appropriate gcov_fn_info struct(s). My question is how (and where in the source code) do the references to the various counters are linked to the gcov_info struct? 2) What exactly is the purpose of the constructor (__gcov_init()) and where are the values of the passed gcov_info struct set (probably related to 1)? --Sebastian smime.p7s Description: S/MIME Cryptographic Signature
Re: libgomp platform customization
On 31/01/2019 11:07, Jakub Jelinek wrote: On Thu, Jan 31, 2019 at 10:58:27AM +0100, Sebastian Huber wrote: On 31/01/2019 10:56, Jakub Jelinek wrote: On Thu, Jan 31, 2019 at 10:37:29AM +0100, Sebastian Huber wrote: My problem is that our real-time operating system (RTEMS) is somewhere in between a full blown Linux and the offload hardware. I would like to get rid of stuff which depends on the Newlib struct _reent since this pulls in a lot of dependencies. The heavy weight functions are just used for the initialization (env.c) and error reporting. Containing the heap allocation functions helps to control the memory used by OpenMP computations. Heap allocations are everywhere in libgomp, not just in initialization, for parallel, offloading, tasking, worksharing constructs, ... You won't get far without that. I would like to use a specialized heap for OpenMP and not the general purpose malloc(), etc. I'd prefer not to clobber the generic code with that though. So, if you in some config/rtems/ header or overriding *.c file #undef strtoul #define strtoul(p, e, b) rtems_strtoul (p, e, b) and similarly for malloc, free, calloc, I won't object, but I'm against introducing gomp_strtoul, etc. (we do already have gomp_malloc, but expect free to be usable against that). The strtoul() is used in combination with errno, so using a macro is not enough. I really would like to be able to use env.c in general, since the standard configuration via environment variables is fine. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: libgomp platform customization
On 31/01/2019 10:56, Jakub Jelinek wrote: On Thu, Jan 31, 2019 at 10:37:29AM +0100, Sebastian Huber wrote: My problem is that our real-time operating system (RTEMS) is somewhere in between a full blown Linux and the offload hardware. I would like to get rid of stuff which depends on the Newlib struct _reent since this pulls in a lot of dependencies. The heavy weight functions are just used for the initialization (env.c) and error reporting. Containing the heap allocation functions helps to control the memory used by OpenMP computations. Heap allocations are everywhere in libgomp, not just in initialization, for parallel, offloading, tasking, worksharing constructs, ... You won't get far without that. I would like to use a specialized heap for OpenMP and not the general purpose malloc(), etc. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: libgomp platform customization
On 31/01/2019 10:29, Richard Biener wrote:
On Wed, Jan 30, 2019 at 3:46 PM Sebastian Huber
wrote:
Hello,
we would like to use libgomp in a quite constraint environment. In this
environment using for example the C locale support, errno, malloc(),
realloc(), free(), and abort() are problematic. One option would be to
introduce a new header file "config/*/platform.h" which is included in
libgomp.h right after the #include "config.h". A platform could then do
something like this:
#define malloc(size) platform_malloc(size)
...
In env.c there are some uses of strto*() like this:
errno = 0;
stride = strtol (env, &env, 10);
if (errno)
return false;
I would like to introduce a new header file "strto.h" which defines
something like this:
static inline char *
gomp_strtol (char *s, long *value)
{
char *end;
errno = 0;
*value = strtol (s, &end, 10);
if (errno != 0)
return NULL;
return end;
}
Then use:
env = gomp_strtol (env, &stride);
if (env == NULL)
return false;
A platform could then provide its own "config/*/strto.h" with an
alternative implementation.
Would this be acceptable after the GCC 9 release?
I guess you could look at what nvptx and HSA (and GCN on some branch)
do here?
My problem is that our real-time operating system (RTEMS) is somewhere
in between a full blown Linux and the offload hardware. I would like to
get rid of stuff which depends on the Newlib struct _reent since this
pulls in a lot of dependencies. The heavy weight functions are just used
for the initialization (env.c) and error reporting. Containing the heap
allocation functions helps to control the memory used by OpenMP
computations.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
libgomp platform customization
Hello,
we would like to use libgomp in a quite constraint environment. In this
environment using for example the C locale support, errno, malloc(),
realloc(), free(), and abort() are problematic. One option would be to
introduce a new header file "config/*/platform.h" which is included in
libgomp.h right after the #include "config.h". A platform could then do
something like this:
#define malloc(size) platform_malloc(size)
...
In env.c there are some uses of strto*() like this:
errno = 0;
stride = strtol (env, &env, 10);
if (errno)
return false;
I would like to introduce a new header file "strto.h" which defines
something like this:
static inline char *
gomp_strtol (char *s, long *value)
{
char *end;
errno = 0;
*value = strtol (s, &end, 10);
if (errno != 0)
return NULL;
return end;
}
Then use:
env = gomp_strtol (env, &stride);
if (env == NULL)
return false;
A platform could then provide its own "config/*/strto.h" with an
alternative implementation.
Would this be acceptable after the GCC 9 release?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: RTEMS Ada build problem on trunk
On 17/01/2019 15:25, Sebastian Huber wrote: On 17/01/2019 12:40, Eric Botcazou wrote: I can build the trunk with a native gnat --version GNAT 8.2.1 20190103 [gcc-8-branch revision 267549] Copyright (C) 1996-2018, Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This would suggest that bldtools/oscons/xoscons is miscompiled by the trunk native compiler. How did you configure this latter compiler? Are there some build/source path limits involved while building Ada? With long path names the build failed (path includes full Git hashes). Then I move the source and build roots to a shorter path, then build was successful using the same configure options. I reduced the path lengths via short Git hashes. I was able to build GCC 597c6d15f88 sparc-rtems5-gnat --version GNAT 9.0.0 20190118 (RTEMS 6, RSB b794966eebc2cb09f14fee16e402f2b0eb8c0fcf, Newlib 7f983079d) on openSUSE with a native GCC gcc --version gcc (SUSE Linux) 8.2.1 20190103 [gcc-8-branch revision 267549 provided by openSUSE. On Debian GNU/Linux 9 (stretch) with a self built native GCC gcc --version --verbose Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/user/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper gcc (GCC) 8.2.0 Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Target: x86_64-pc-linux-gnu Configured with: ../src/gcc-8.2.0/configure --prefix=/home/user/gcc-8.2.0 --disable-multilib --enable-languages=c,c++,ada Thread model: posix gcc version 8.2.0 (GCC) COLLECT_GCC_OPTIONS='--version' '-v' '-mtune=generic' '-march=x86-64' /home/user/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/cc1 -quiet -v -imultiarch x86_64-linux-gnu help-dummy -quiet -dumpbase help-dummy -mtune=generic -march=x86-64 -auxbase help-dummy -version --version -o /tmp/cc7wWgjz.s GNU C17 (GCC) version 8.2.0 (x86_64-pc-linux-gnu) compiled by GNU C version 8.2.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='--version' '-v' '-mtune=generic' '-march=x86-64' as -v --64 --version -o /tmp/ccKF8BFi.o /tmp/cc7wWgjz.s GNU assembler version 2.28 (x86_64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.28 GNU assembler (GNU Binutils for Debian) 2.28 Copyright (C) 2017 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-linux-gnu'. COMPILER_PATH=/home/user/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/:/home/user/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/:/home/user/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/:/home/user/gcc-8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0/:/home/user/gcc-8.2.0/lib/gcc/x86_64-pc-linux-gnu/ LIBRARY_PATH=/home/user/gcc-8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0/:/home/user/gcc-8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/home/user/gcc-8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='--version' '-v' '-mtune=generic' '-march=x86-64' /home/user/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/collect2 -plugin /home/user/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/liblto_plugin.so -plugin-opt=/home/user/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper -plugin-opt=-fresolution=/tmp/cc1NHm21.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 --version /usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o /home/user/gcc-8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0/crtbegin.o -L/home/user/gcc-8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0 -L/home/user/gcc-8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/home/user/gcc-8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../.. /tmp/ccKF8BFi.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /home/user/gcc-8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0/crtend.o /usr/lib/x86_64-linux-gnu/crtn.o collect2 version 8.2.0 /usr/bin/ld -plugin /home/user/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/liblto_plugin.so -plugin-opt=/home/user/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2
Re: RTEMS Ada build problem on trunk
On 17/01/2019 12:40, Eric Botcazou wrote: I can build the trunk with a native gnat --version GNAT 8.2.1 20190103 [gcc-8-branch revision 267549] Copyright (C) 1996-2018, Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This would suggest that bldtools/oscons/xoscons is miscompiled by the trunk native compiler. How did you configure this latter compiler? Are there some build/source path limits involved while building Ada? With long path names the build failed (path includes full Git hashes). Then I move the source and build roots to a shorter path, then build was successful using the same configure options. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail :sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: RTEMS Ada build problem on trunk
On 17/01/2019 09:56, Sebastian Huber wrote: Hello, I tried to build the arm-rtems target with Ada support on the trunk yesterday. It fails with: /home/user/rtems-source-builder/rtems/build/arm-rtems6-gcc-0ca47588bd2e38bbfa427503968e08a6b8ab3166-newlib-068182e26c7b397df579b69a18f745092844d1b4-x86 _64-linux-gnu-1/build/./gcc/xgcc -B/home/user/rtems-source-builder/rtems/build/arm-rtems6-gcc-0ca47588bd2e38bbfa427503968e08a6b8ab3166-newlib-068182e26 c7b397df579b69a18f745092844d1b4-x86_64-linux-gnu-1/build/./gcc/ -nostdinc -B/home/user/rtems-source-builder/rtems/build/arm-rtems6-gcc-0ca47588bd2e38bb fa427503968e08a6b8ab3166-newlib-068182e26c7b397df579b69a18f745092844d1b4-x86_64-linux-gnu-1/build/arm-rtems6/newlib/ -isystem /home/user/rtems-source-b uilder/rtems/build/arm-rtems6-gcc-0ca47588bd2e38bbfa427503968e08a6b8ab3166-newlib-068182e26c7b397df579b69a18f745092844d1b4-x86_64-linux-gnu-1/build/arm -rtems6/newlib/targ-include -isystem /home/user/rtems-source-builder/rtems/build/arm-rtems6-gcc-0ca47588bd2e38bbfa427503968e08a6b8ab3166-newlib-068182e 26c7b397df579b69a18f745092844d1b4-x86_64-linux-gnu-1/gnu-mirror-gcc-0ca47588bd2e38bbfa427503968e08a6b8ab3166/newlib/libc/include -B/home/user/rtems-ins tall/arm-rtems6/bin/ -B/home/user/rtems-install/arm-rtems6/lib/ -isystem /home/user/rtems-install/arm-rtems6/include -isystem /home/user/rtems-install/ arm-rtems6/sys-include -c -g -O2 -W -Wall -gnatpg -nostdinc a-envvar.adb -o a-envvar.o a-direct.adb:743:28: "SIZEOF_struct_dirent_alloc" is undefined s-filatt.ads:62:18: "SIZEOF_struct_file_attributes" not declared in "OS_Constants" s-oscons.ads:408:01: (style) multiple blank lines s-oscons.ads:413:01: (style) multiple blank lines In the build tree(gcc/ada/rts) I have this: grep -- '->CND' s-oscons-tmplt.s ... ->CND:#1699:CLOCK_REALTIME:#1:System realtime clock ->CND:#1702:CLOCK_MONOTONIC:#4:System monotonic clock ->CND:#1712:CLOCK_THREAD_CPUTIME_ID:#3:Thread CPU clock ->CND:#1771:PTHREAD_SIZE:#4:pthread_t ->CND:#1772:PTHREAD_ATTR_SIZE:#96:pthread_attr_t ->CND:#1773:PTHREAD_MUTEXATTR_SIZE:#24:pthread_mutexattr_t ->CND:#1774:PTHREAD_MUTEX_SIZE:#64:pthread_mutex_t ->CND:#1775:PTHREAD_CONDATTR_SIZE:#24:pthread_condattr_t ->CND:#1776:PTHREAD_COND_SIZE:#28:pthread_cond_t ->CND:#1777:PTHREAD_RWLOCKATTR_SIZE:#8:pthread_rwlockattr_t ->CND:#1778:PTHREAD_RWLOCK_SIZE:#32:pthread_rwlock_t ->CND:#1779:PTHREAD_ONCE_SIZE:#1:pthread_once_t ->CND:#1800:SIZEOF_struct_file_attributes:#24:struct file_attributes ->CND:#1812:SIZEOF_struct_dirent_alloc:#278:struct dirent allocation The ../bldtools/oscons/xoscons s-oscons produces this tail -20 s-oscons.ads - -- Threads support -- - -- Clock identifier definitions CLOCK_REALTIME : constant := 1; -- System realtime clock CLOCK_MONOTONIC : constant := 4; -- System monotonic clock CLOCK_THREAD_CPUTIME_ID : constant := 3; -- Thread CPU clock CLOCK_RT_Ada : constant := CLOCK_REALTIME; -- Sizes of pthread data types -- File and directory support -- end System.OS_Constants; With GCC 7.4.0 it works and the s-oscons-tmplt.s dosn't look that much different. My native GNAT is: gnat --version GNAT 9.0.0 20190116 (experimental) Copyright (C) 1996-2019, Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I can build the trunk with a native gnat --version GNAT 8.2.1 20190103 [gcc-8-branch revision 267549] Copyright (C) 1996-2018, Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
RTEMS Ada build problem on trunk
Hello, I tried to build the arm-rtems target with Ada support on the trunk yesterday. It fails with: /home/user/rtems-source-builder/rtems/build/arm-rtems6-gcc-0ca47588bd2e38bbfa427503968e08a6b8ab3166-newlib-068182e26c7b397df579b69a18f745092844d1b4-x86 _64-linux-gnu-1/build/./gcc/xgcc -B/home/user/rtems-source-builder/rtems/build/arm-rtems6-gcc-0ca47588bd2e38bbfa427503968e08a6b8ab3166-newlib-068182e26 c7b397df579b69a18f745092844d1b4-x86_64-linux-gnu-1/build/./gcc/ -nostdinc -B/home/user/rtems-source-builder/rtems/build/arm-rtems6-gcc-0ca47588bd2e38bb fa427503968e08a6b8ab3166-newlib-068182e26c7b397df579b69a18f745092844d1b4-x86_64-linux-gnu-1/build/arm-rtems6/newlib/ -isystem /home/user/rtems-source-b uilder/rtems/build/arm-rtems6-gcc-0ca47588bd2e38bbfa427503968e08a6b8ab3166-newlib-068182e26c7b397df579b69a18f745092844d1b4-x86_64-linux-gnu-1/build/arm -rtems6/newlib/targ-include -isystem /home/user/rtems-source-builder/rtems/build/arm-rtems6-gcc-0ca47588bd2e38bbfa427503968e08a6b8ab3166-newlib-068182e 26c7b397df579b69a18f745092844d1b4-x86_64-linux-gnu-1/gnu-mirror-gcc-0ca47588bd2e38bbfa427503968e08a6b8ab3166/newlib/libc/include -B/home/user/rtems-ins tall/arm-rtems6/bin/ -B/home/user/rtems-install/arm-rtems6/lib/ -isystem /home/user/rtems-install/arm-rtems6/include -isystem /home/user/rtems-install/ arm-rtems6/sys-include -c -g -O2 -W -Wall -gnatpg -nostdinc a-envvar.adb -o a-envvar.o a-direct.adb:743:28: "SIZEOF_struct_dirent_alloc" is undefined s-filatt.ads:62:18: "SIZEOF_struct_file_attributes" not declared in "OS_Constants" s-oscons.ads:408:01: (style) multiple blank lines s-oscons.ads:413:01: (style) multiple blank lines In the build tree(gcc/ada/rts) I have this: grep -- '->CND' s-oscons-tmplt.s ... ->CND:#1699:CLOCK_REALTIME:#1:System realtime clock ->CND:#1702:CLOCK_MONOTONIC:#4:System monotonic clock ->CND:#1712:CLOCK_THREAD_CPUTIME_ID:#3:Thread CPU clock ->CND:#1771:PTHREAD_SIZE:#4:pthread_t ->CND:#1772:PTHREAD_ATTR_SIZE:#96:pthread_attr_t ->CND:#1773:PTHREAD_MUTEXATTR_SIZE:#24:pthread_mutexattr_t ->CND:#1774:PTHREAD_MUTEX_SIZE:#64:pthread_mutex_t ->CND:#1775:PTHREAD_CONDATTR_SIZE:#24:pthread_condattr_t ->CND:#1776:PTHREAD_COND_SIZE:#28:pthread_cond_t ->CND:#1777:PTHREAD_RWLOCKATTR_SIZE:#8:pthread_rwlockattr_t ->CND:#1778:PTHREAD_RWLOCK_SIZE:#32:pthread_rwlock_t ->CND:#1779:PTHREAD_ONCE_SIZE:#1:pthread_once_t ->CND:#1800:SIZEOF_struct_file_attributes:#24:struct file_attributes ->CND:#1812:SIZEOF_struct_dirent_alloc:#278:struct dirent allocation The ../bldtools/oscons/xoscons s-oscons produces this tail -20 s-oscons.ads - -- Threads support -- - -- Clock identifier definitions CLOCK_REALTIME : constant := 1; -- System realtime clock CLOCK_MONOTONIC : constant := 4; -- System monotonic clock CLOCK_THREAD_CPUTIME_ID : constant := 3; -- Thread CPU clock CLOCK_RT_Ada : constant := CLOCK_REALTIME; -- Sizes of pthread data types -- File and directory support -- end System.OS_Constants; With GCC 7.4.0 it works and the s-oscons-tmplt.s dosn't look that much different. My native GNAT is: gnat --version GNAT 9.0.0 20190116 (experimental) Copyright (C) 1996-2019, Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: [PATCH v3 1/3] or1k: libgcc: initial support for openrisc
On 13/11/2018 21:20, Stafford Horne wrote: On Tue, Nov 13, 2018 at 11:57:13AM -0600, Joel Sherrill wrote: Sebastian confirmed he couldn't get a complete RTEMS build either. I looked into this enough to spot that old or1k port's libgcc/config.host has an extra_parts line for or1k-*-* that the gcc master does not: The gcc master repo is missing the "extra_parts" line that was in the other repository. or1k-*-*) tmake_file="$tmake_file or1k/t-or1k" tmake_file="$tmake_file t-softfp-sfdf t-softfp-excl t-softfp" extra_parts="$extra_parts crti.o crtn.o" ;; OK for Sebastian or I to add that line? Hi Joel, Did adding that fix the issue? We removed crti.o and crtn.o because we switched to exclusive libc_init/fini_array. It should not help to add those back, see the commit here: https://github.com/stffrdhrn/gcc/commit/46131027c9775ebcddc48bd0ae64ceec5b1f801f What is the error you are seeing? It was an error in our GCC specs file. I fixed it like this: https://git.rtems.org/rtems/commit/?id=28bf4cae7878f4e47cc24c114fc9c5567247ecc1 I was able to build the RTEMS BSP and link the tests with the upstream GCC 9. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: [PATCH v3 1/3] or1k: libgcc: initial support for openrisc
Hello Stafford, I tried to build the or1k-rtems5 target with GCC 4c0c3d1029e79b6709b43fed8c5a5944f245516d and Binutils 417e50dbcfd4b8dd699f48df5ac9b9a733fd80e2. It failed in the libgcc build: /scratch/git-rtems-source-builder/rtems/build/or1k-rtems5-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d-newlib-2ab57ad59bc35dafffa69cd4da5e228971de069f-x86_64-linux-gnu-1/build/./gcc/xgcc -B/scratch/git-rtems-source-builder/rtems/build/or1k-rtems5-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d-newlib-2ab57ad59bc35dafffa69cd4da5e228971de069f-x86_64-linux-gnu-1/build/./gcc/ -nostdinc -B/scratch/git-rtems-source-builder/rtems/build/or1k-rtems5-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d-newlib-2ab57ad59bc35dafffa69cd4da5e228971de069f-x86_64-linux-gnu-1/build/or1k-rtems5/mcmov/newlib/ -isystem /scratch/git-rtems-source-builder/rtems/build/or1k-rtems5-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d-newlib-2ab57ad59bc35dafffa69cd4da5e228971de069f-x86_64-linux-gnu-1/build/or1k-rtems5/mcmov/newlib/targ-include -isystem /scratch/git-rtems-source-builder/rtems/build/or1k-rtems5-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d-newlib-2ab57ad59bc35dafffa69cd4da5e228971de069f-x86_64-linux-gnu-1/gnu-mirror-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d/newlib/libc/include -B/build/rtems/5/or1k-rtems5/bin/ -B/build/rtems/5/or1k-rtems5/lib/ -isystem /build/rtems/5/or1k-rtems5/include -isystem /build/rtems/5/or1k-rtems5/sys-include -mcmov -g -O2 -O2 -I../../../../gnu-mirror-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../gnu-mirror-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d/libgcc -I../../../../gnu-mirror-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d/libgcc/. -I../../../../gnu-mirror-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d/libgcc/../gcc -I../../../../gnu-mirror-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d/libgcc/../include -o _ffssi2.o -MT _ffssi2.o -MD -MP -MF _ffssi2.dep -DL_ffssi2 -c ../../../../gnu-mirror-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS -save-temps libgcc2.s: Assembler messages: libgcc2.s:60: Error: junk at end of line `l.movhi r17,ha(__clz_tab)' The file content in this area is: .L4: .LVL4: .LM17: .LBE3: .LM18: .LBE2: .LM19: .LBB6: .LBB4: .LM20: l.movhi r17, ha(__clz_tab) l.addi r17, r17, lo(__clz_tab) l.add r3, r17, r3 .LVL5: l.lbz r11, 0(r3) -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: Can support TRUNC_DIV_EXPR, TRUNC_MOD_EXPR in GCC vectorization/scalar evolution -- and/or linearization?
On Fri, Oct 12, 2018 at 2:14 PM Marc Glisse wrote:
> On Fri, 12 Oct 2018, Thomas Schwinge wrote:
>
> > Hmm, and without any OpenACC/OpenMP etc., actually the same problem is
> > also present when running the following code through the vectorizer:
> >
> >for (int tmp = 0; tmp < N_J * N_I; ++tmp)
> > {
> >int j = tmp / N_I;
> >int i = tmp % N_I;
> >a[j][i] = 0;
> > }
> >
> > ... whereas the following variant (obviously) does vectorize:
> >
> >int a[NJ * NI];
> >
> >for (int tmp = 0; tmp < N_J * N_I; ++tmp)
> > a[tmp] = 0;
>
> I had a quick look at the difference, and a[j][i] remains in this form
> throughout optimization. If I write instead *((*(a+j))+i) = 0; I get
>
>j_10 = tmp_17 / 1025;
>i_11 = tmp_17 % 1025;
>_1 = (long unsigned int) j_10;
>_2 = _1 * 1025;
>_3 = (sizetype) i_11;
>_4 = _2 + _3;
>
> or for a power of 2
>
>j_10 = tmp_17 >> 10;
>i_11 = tmp_17 & 1023;
>_1 = (long unsigned int) j_10;
>_2 = _1 * 1024;
>_3 = (sizetype) i_11;
>_4 = _2 + _3;
>
> and in both cases we fail to notice that _4 = (sizetype) tmp_17; (at least
> I think that's true).
>
>
If this folding is correct, the dependence analysis would not have
to handle array accesses with div and mod, and it would be able
to classify the loop as parallel which will enable vectorization.
> So there are missing match.pd transformations in addition to whatever
> scev/ivdep/other work is needed.
>
> --
> Marc Glisse
>
Re: RISC-V and Ada: undefined references to `__gnat_raise_nodefer_with_msg'
On 03/07/18 09:10, Eric Botcazou wrote: It seems the a-except.adb was replaced by a-except-2005.adb in this commit: Right, it's by design, the old support for SJLJ exceptions has been ditched for full runtimes. You probably just need to swap the values of Frontend_Exceptions : constant Boolean := True; ZCX_By_Default: constant Boolean := False; in system-rtems.ads. Thanks, this worked. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: RISC-V and Ada: undefined references to `__gnat_raise_nodefer_with_msg'
On 02/07/18 22:03, Eric Botcazou wrote:
I cannot find it in the GCC sources:
grep -ri raise_nodefer_with_msg
gcc/ada/gcc-interface/trans.c: (get_identifier
("__gnat_raise_nodefer_with_msg"), NULL_TREE, ftype,
Who is supposed to provide an implementation of
__gnat_raise_nodefer_with_msg?
No one, it's obsolete. The port is very likely not (properly) configured.
In master and gcc-8-branch:
grep -ri raise_nodefer_with_msg gcc/ada
gcc/ada/gcc-interface/trans.c: (get_identifier
("__gnat_raise_nodefer_with_msg"), NULL_TREE, ftype,
In gcc-7-branch:
grep -ri raise_nodefer_with_msg gcc/ada
gcc/ada/a-exexpr.adb: pragma Export (C, Propagate_Continue,
"__gnat_raise_nodefer_with_msg");
gcc/ada/gcc-interface/trans.c: (get_identifier
("__gnat_raise_nodefer_with_msg"), NULL_TREE, ftype,
gcc/ada/a-except.adb: pragma Export (C, Raise_Current_Excep,
"__gnat_raise_nodefer_with_msg");
It seems the a-except.adb was replaced by a-except-2005.adb in this commit:
commit 4af1de5b4b45c597d63e935dc3fae6d94b27d39e
Author: charlet
Date: Thu Apr 27 09:48:45 2017 +
2017-04-27 Claire Dross
* a-cfdlli.adb, a-cfdlli.ads (Formal_Model): Adapt to
modifications in functional containers.
* a-cofuba.ads, a-cofuma.ads, a-cofuse.ads, a-cofuve.ads
Reformat
to improve readablity. Subprograms are separated between basic
operations, constructors and properties. Universally quantified
formulas in contracts are factorized in independant functions
with a name and a comment. Names of parameters are improved.
2017-04-27 Gary Dismukes
* exp_spark.adb, sem_elab.adb: Minor reformatting and typo fix.
2017-04-27 Hristian Kirtchev
* sem_res.adb (Resolve_Type_Conversion): Do not
install a predicate check here since this is already done
during
the expansion phase. Verify whether the operand satisfies the
static predicate (if any) of the target type.
* sem_ch3.adb (Analyze_Object_Declaration): Do
not install a predicate check if the object is initialized by
means of a type conversion because the conversion is subjected
to the same check.
2017-04-27 Tristan Gingold
* raise.c (__gnat_builtin_longjmp): Remove.
(__gnat_bracktrace):
Add a dummy definition for the compiler (__gnat_eh_personality,
__gnat_rcheck_04, __gnat_rcheck_10) (__gnat_rcheck_19,
__gnat_rcheck_20, __gnat_rcheck_21) (__gnat_rcheck_30,
__gnat_rcheck_31, __gnat_rcheck_32): Likewise.
* a-exexpr.adb: Renamed from a-exexpr-gcc.adb
* a-except.ads, a-except.adb: Renamed from a-except-2005.ads
and a-except-2005.adb.
* raise-gcc.c: Allow build in compiler, compiled as a C++
file.
(__gnat_Unwind_ForcedUnwind): Adjust prototype.
(db): Constify msg_format.
(get_call_site_action_for): Don't use void arithmetic.
* system.ads (Frontend_Exceptions): Set to False.
(ZCX_By_Default): Set to True.
(GCC_ZC_Support): Set to True.
* gcc-interface/Makefile.in: No more variants for
a-exexpr.adb and
a-except.ad[sb].
* gcc-interface/Make-lang.in: Add support for backend zcx
exceptions
in gnat1 and gnatbind.
* gnat1, gnatbind: link with raise-gcc.o, a-exctra.o,
s-addima.o,
s-excmac.o, s-imgint.o, s-traceb.o, s-trasym.o, s-wchstw.o
* s-excmac.ads, s-excmac.adb: Copy of variants.
* a-except.o: Adjust preequisites.
Add handling of s-excmac-arm.adb and s-excmac-gcc.adb.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@247301
138bc75d-0d04-0410-961f-82ee72b054a4
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
RISC-V and Ada: undefined references to `__gnat_raise_nodefer_with_msg'
Hello,
I get the following link-time error while building an Ada test program
on RISC-V and RTEMS:
riscv64-rtems5-gnatlink hello.ali -march=rv64imafd -mabi=lp64d
-mcmodel=medany -O2 -g -ffunction-sections -fdata-sections -Wall
-Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes
-Wnested-externs
-B/build/git-build/b-rv64imafd_medany/riscv64-rtems5/c/rv64imafd_medany/lib/libbsp/riscv/riscv
-B/home/EB/sebastian_h/git-rtems-5/bsps/riscv/riscv/start -specs
bsp_specs -qrtems -L../../../../../../rv64imafd_medany/lib
-L/home/EB/sebastian_h/git-rtems-5/bsps/riscv/shared/start
-Wl,--wrap=printf -Wl,--wrap=puts -Wl,--wrap=putchar -Wl,--gc-sections
init.o -o ada_hello.exe
/build/rtems/5/lib/gcc/riscv64-rtems5/8.1.1/../../../../riscv64-rtems5/bin/ld:
/build/rtems/5/lib/gcc/riscv64-rtems5/8.1.1/rv64imafd/lp64d/medany/adalib/libgnat.a(a-calend.o):
in function `ada__calendar__arithmetic_operations__add':
/scratch/git-rtems-source-builder/rtems/build/riscv64-rtems5-gcc-2e2052934b0c82e0726ed44de4a9b0a29ed6b276-newlib-3.0.0-x86_64-linux-gnu-1/build/gcc/ada/rts_rv64imafd_lp64d_medany/a-calend.adb:797:
undefined reference to `__gnat_raise_nodefer_with_msg'
/build/rtems/5/lib/gcc/riscv64-rtems5/8.1.1/../../../../riscv64-rtems5/bin/ld:
/build/rtems/5/lib/gcc/riscv64-rtems5/8.1.1/rv64imafd/lp64d/medany/adalib/libgnat.a(a-calend.o):
in function `ada__calendar__arithmetic_operations__subtract':
/scratch/git-rtems-source-builder/rtems/build/riscv64-rtems5-gcc-2e2052934b0c82e0726ed44de4a9b0a29ed6b276-newlib-3.0.0-x86_64-linux-gnu-1/build/gcc/ada/rts_rv64imafd_lp64d_medany/a-calend.adb:894:
undefined reference to `__gnat_raise_nodefer_with_msg'
/build/rtems/5/lib/gcc/riscv64-rtems5/8.1.1/../../../../riscv64-rtems5/bin/ld:
/build/rtems/5/lib/gcc/riscv64-rtems5/8.1.1/rv64imafd/lp64d/medany/adalib/libgnat.a(a-calend.o):
in function `ada__calendar__conversion_operations__to_ada_time':
/scratch/git-rtems-source-builder/rtems/build/riscv64-rtems5-gcc-2e2052934b0c82e0726ed44de4a9b0a29ed6b276-newlib-3.0.0-x86_64-linux-gnu-1/build/gcc/ada/rts_rv64imafd_lp64d_medany/a-calend.adb:917:
undefined reference to `__gnat_raise_nodefer_with_msg'
/build/rtems/5/lib/gcc/riscv64-rtems5/8.1.1/../../../../riscv64-rtems5/bin/ld:
/build/rtems/5/lib/gcc/riscv64-rtems5/8.1.1/rv64imafd/lp64d/medany/adalib/libgnat.a(a-calend.o):
in function `ada__calendar__conversion_operations__to_unix_time':
/scratch/git-rtems-source-builder/rtems/build/riscv64-rtems5-gcc-2e2052934b0c82e0726ed44de4a9b0a29ed6b276-newlib-3.0.0-x86_64-linux-gnu-1/build/gcc/ada/rts_rv64imafd_lp64d_medany/a-calend.adb:1095:
undefined reference to `__gnat_raise_nodefer_with_msg'
/build/rtems/5/lib/gcc/riscv64-rtems5/8.1.1/../../../../riscv64-rtems5/bin/ld:
/build/rtems/5/lib/gcc/riscv64-rtems5/8.1.1/rv64imafd/lp64d/medany/adalib/libgnat.a(a-calend.o):
in function `ada__calendar__Oadd':
/scratch/git-rtems-source-builder/rtems/build/riscv64-rtems5-gcc-2e2052934b0c82e0726ed44de4a9b0a29ed6b276-newlib-3.0.0-x86_64-linux-gnu-1/build/gcc/ada/rts_rv64imafd_lp64d_medany/a-calend.adb:249:
undefined reference to `__gnat_raise_nodefer_with_msg'
/build/rtems/5/lib/gcc/riscv64-rtems5/8.1.1/../../../../riscv64-rtems5/bin/ld:
/build/rtems/5/lib/gcc/riscv64-rtems5/8.1.1/rv64imafd/lp64d/medany/adalib/libgnat.a(a-calend.o):/scratch/git-rtems-source-builder/rtems/build/riscv64-rtems5-gcc-2e2052934b0c82e0726ed44de4a9b0a29ed6b276-newlib-3.0.0-x86_64-linux-gnu-1/build/gcc/ada/rts_rv64imafd_lp64d_medany/a-calend.adb:261:
more undefined references to `__gnat_raise_nodefer_with_msg' follow
I cannot find it in the GCC sources:
grep -ri raise_nodefer_with_msg
gcc/ada/gcc-interface/trans.c: (get_identifier
("__gnat_raise_nodefer_with_msg"), NULL_TREE, ftype,
Who is supposed to provide an implementation of
__gnat_raise_nodefer_with_msg?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
RE: Question regarding preventing optimizing out of register in expansion
> Subject: Re: Question regarding preventing optimizing out of register in > expansion > > On 6/26/18 4:05 AM, Peryt, Sebastian wrote: > > With some changes simplified implementation of my expansion is as follows: > > tmp_op0 = gen_reg_rtx (mode); > > emit_move_insn (tmp_op0, op0); > > You set tmp_op0 here, and then > > > > emit_insn (gen_rtx_SET (tmp_op0, reg)); > > You set it again here without ever using it above, so it's dead code, which > explains why it's removed. Oh My bad - I oversimplified my code. Now I can see it. This should be more appropriate: tmp_op0 = gen_reg_rtx (mode); emit_move_insn (tmp_op0, op0); tmp_op1 = gen_reg_rtx (mode); emit_move_insn (tmp_op1, op1); // This is important part reg = gen_rtx_REG(wide_mode, XMM2_REG); op3 = gen_rtx_PLUS (mode, tmp_op1, GEN_INT (128)); emit_insn (gen_rtx_SET (reg, op3)); emit_insn (gen_myinsn(op2, reg)); op3 = gen_rtx_PLUS (mode, tmp_op0, GEN_INT (128)); emit_insn (gen_rtx_SET (op3, reg)); Also I'd like to one more time point out that without additional -mavx or -mavx2 I'm getting expected register moves before and after my instr. With those options only *after*. This is the part that I don't get especially - why. > > Peter >
RE: Question regarding preventing optimizing out of register in expansion
After some more digging and adjusting I found additional cases that are optimizing out registers thus I decided to continue this thread to keep discussion compact. With some changes simplified implementation of my expansion is as follows: tmp_op0 = gen_reg_rtx (mode); emit_move_insn (tmp_op0, op0); tmp_op1 = gen_reg_rtx (mode); emit_move_insn (tmp_op1, op1); // This is important part reg = gen_rtx_REG(wide_mode, XMM2_REG); emit_insn (gen_rtx_SET (reg, tmp_op1)); emit_insn (gen_myinsn(op2, reg)); emit_insn (gen_rtx_SET (tmp_op0, reg)); And my md is as follows: (define_insn "myinsn" [(unspec [(match_operand:SI 0 "register_operand" "r") (match_operand:V4SI 1 "vector_operand")] UNSPEC_MYINSN) (clobber (reg:V4SI XMM2_REG))] "TARGET_MYTARGET" "instr\t%0" [(set_attr "type" "other")]) This is working like a charm when built with any optimization level producing something like this: movdqu %eax, %xmm2 instr %edx movups %xmm2, %eax Unfortunately, when I build it with additional -mavx2 or -mavx512f first move (from reg to xmm2) is optimized out. I'm using those extra flags because I also want to use YMM2 and ZMM2 in my instruction. Does anyone have idea why might such thing happen? And how this can be overcome? Thanks, Sebastian > -Original Message- > Subject: Re: Question regarding preventing optimizing out of register in > expansion > > On 06/21/2018 05:20 AM, Peryt, Sebastian wrote: > > Hi, > > > > I'd appreciate if someone could advise me in builtin expansion I'm currently > writing. > > > > High level description for what I want to do: > > > > I have 2 operands in my builtin. > > IIUC you're defining an UNSPEC. > > > First I set register (reg1) with value from operand1 (op1); Second I > > call my instruction (reg1 is called implicitly and updated); > > Here is your error -- NEVER have implicit register settings. The data flow > analysers need accurate information. > > > > Simplified implementation in i386.c I have: > > > > reg1 = gen_reg_rtx (mode); > > emit_insn (gen_rtx_SET (reg1, op1); > > emit_clobber (reg1); > > At this point reg1 is dead. That means the previous set of reg1 from > op1 is unneeded and can be deleted. > > > emit_insn (gen_myinstruction ()); > > This instruction has no inputs or outputs, and is not marked volatile(?) > so can be deleted. > > > emit_insn (gen_rtx_SET (op2,reg1)); > > And this is storing a value from a dead register. > > You need something like: >rtx reg1 = force_reg (op1); >rtx reg2 = gen_reg_rtx (mode); >emit_insn (gen_my_insn (reg2, reg1)); >emit insn (gen_rtx_SET (op2, reg2)); > > your instruction should be an UNSPEC showing what the inputs and outputs > are. That tells the optimizers what depends on what, but the compiler > has no clue about what the transform is. > > nathan > -- > Nathan Sidwell
RE: Question regarding preventing optimizing out of register in expansion
Thank you very much! Your suggestions helped me figure this out. Sebastian -Original Message- From: Nathan Sidwell [mailto:nathanmsidw...@gmail.com] On Behalf Of Nathan Sidwell Sent: Thursday, June 21, 2018 1:43 PM To: Peryt, Sebastian ; gcc@gcc.gnu.org Subject: Re: Question regarding preventing optimizing out of register in expansion On 06/21/2018 05:20 AM, Peryt, Sebastian wrote: > Hi, > > I'd appreciate if someone could advise me in builtin expansion I'm currently > writing. > > High level description for what I want to do: > > I have 2 operands in my builtin. IIUC you're defining an UNSPEC. > First I set register (reg1) with value from operand1 (op1); Second I > call my instruction (reg1 is called implicitly and updated); Here is your error -- NEVER have implicit register settings. The data flow analysers need accurate information. > Simplified implementation in i386.c I have: > > reg1 = gen_reg_rtx (mode); > emit_insn (gen_rtx_SET (reg1, op1); > emit_clobber (reg1); At this point reg1 is dead. That means the previous set of reg1 from op1 is unneeded and can be deleted. > emit_insn (gen_myinstruction ()); This instruction has no inputs or outputs, and is not marked volatile(?) so can be deleted. > emit_insn (gen_rtx_SET (op2,reg1)); And this is storing a value from a dead register. You need something like: rtx reg1 = force_reg (op1); rtx reg2 = gen_reg_rtx (mode); emit_insn (gen_my_insn (reg2, reg1)); emit insn (gen_rtx_SET (op2, reg2)); your instruction should be an UNSPEC showing what the inputs and outputs are. That tells the optimizers what depends on what, but the compiler has no clue about what the transform is. nathan -- Nathan Sidwell
Question regarding preventing optimizing out of register in expansion
Hi, I'd appreciate if someone could advise me in builtin expansion I'm currently writing. High level description for what I want to do: I have 2 operands in my builtin. First I set register (reg1) with value from operand1 (op1); Second I call my instruction (reg1 is called implicitly and updated); At the end I'm setting operand2 (op2) with value from reg1. Simplified implementation in i386.c I have: reg1 = gen_reg_rtx (mode); emit_insn (gen_rtx_SET (reg1, op1); emit_clobber (reg1); emit_insn (gen_myinstruction ()); emit_insn (gen_rtx_SET (op2,reg1)); Everything works fine for -O0, but when I move to higher level optimizations setting value into reg1 (lines before emit_clobber) are optimized out. I already tried moving emit_clobber just after assignment but it doesn't help. Could you please suggest how I can prevent it from happening? Thanks, Sebastian
RE: What is dump_file in gcc ?
> Subject: What is dump_file in gcc ? > > I have ever seen "fprintf(dump_file,"something writes into dump_file") many > times. > I want to know what dump_file is and how can I check its content ? I'm not 100% sure, but my best guess is that this is related to GCC dumps, e.g. related to passes. You can do -fdump-- where type can be e.g. rtl and pass the pass for which you want to gather information. I suppose there is more to those dumps, but this should get you started. Sebastian > >
Re: RISC-V ELF multilibs
On 01/06/18 10:23, Michael Clark wrote: On 1/06/2018, at 6:16 PM, Sebastian Huber wrote: On 29/05/18 20:02, Jim Wilson wrote: Most variants include the C extension. Would it be possible to add -march=rv32g and -march=rv64g variants? The expectation is that most implementations will include the C extension. It reduces code size, improves performance, and I think I read somewhere that it takes only 400 gates to implement. It isn't practical to try to support every possible combination of architecture and ABI here, as there are too many possible combinations. But if there is a major RISC-V target that is rv32g or rv64g then we should consider it. You can of course define your own set of multilibs. I am not a hardware developer, but I heard that the C extension is not easy to implement in out of order machines. Easy is relative. The RISC-V ISA encoding has been designed so that wide fetch is relatively easy, possibly an order of magnitude easier than an ISA with a complex variable length encoding like x86. RV64GC instruction lengths can be derived from the 2 least significant bits in the first half-word packet of each instruction for mixed 16/32 bit instructions. It does not require an attempt to parse multiple prefixes with instructions ranging from 1 byte up to 15 bytes, before arriving at an instruction length (x86). From that perspective RV64GC is decidedly simple. That said, RV64GC is a little more complex than regular 32-bit encodings like RV64G, PowerPC, AArch64, or SPARC. I don’t think the paper you have linked to draws the conclusion you are arriving at. Yes, please use my words with care. I am not a hardware developer. Reading "A.3 The Compressed (“C”) ISA Extension" in https://github.com/ccelio/riscv-boom-doc/ lead me to this statement that it is not easy from my inexperienced point of view. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: RISC-V ELF multilibs
On 31/05/18 11:08, Palmer Dabbelt wrote: On Tue, 29 May 2018 11:02:58 PDT (-0700), Jim Wilson wrote: On 05/26/2018 06:04 AM, Sebastian Huber wrote: Why is the default multilib and a variant identical? This is supposed to be a single multilib, with two names. We use MULTILIB_REUSE to map the two names to a single multilib. rohan:1030$ ./xgcc -B./ -march=rv64imafdc -mabi=lp64d --print-libgcc ./rv64imafdc/lp64d/libgcc.a rohan:1031$ ./xgcc -B./ -march=rv64gc -mabi=lp64d --print-libgcc ./rv64imafdc/lp64d/libgcc.a rohan:1032$ ./xgcc -B./ --print-libgcc ./libgcc.a rohan:1033$ So this is working right when the -march option is given, but not when no -march is given. I'd suggest a bug report so I can track this, if you haven't already filed one. IIRC this is actually a limit of the GCC build system: there needs to be some default multilib, and it has to be unprefixed. I wanted to keep the library paths orthogonal (ie, not bake in a default that rv64gc/lp64d lives at /lib), so I chose to just build a redundant multilib. It'd be great to get rid of this, but I'm afraid it's way past my level of understanding as to how all this works. Ok, I just wanted to know if this was intentional or some sort of a bug. Some way to disable the default multilib would be nice in general. Ending up with the default multilib usually indicates some build system misconfiguration. It is not easy for the average user to figure out what is going on especially on targets where the linker silently links ABI incompatible objects together. Most variants include the C extension. Would it be possible to add -march=rv32g and -march=rv64g variants? The expectation is that most implementations will include the C extension. It reduces code size, improves performance, and I think I read somewhere that it takes only 400 gates to implement. It isn't practical to try to support every possible combination of architecture and ABI here, as there are too many possible combinations. But if there is a major RISC-V target that is rv32g or rv64g then we should consider it. You can of course define your own set of multilibs. While that's the standard answer, note that Sebastian added the RISC-V RTEMS target in the first place so as far as I'm concerned he can add additional multilibs to it if he wants. While I'm not opposed to RTEMS multilibs for rv32g/ilp32d and rv64g/lp64d, note that we have made the decision in Linux land that the C extension will be common and thus I expect most RISC-V implementations with virtual memory to also have the C extension. If you go down this route then you should move RTEMS to its own multilib target fragment (t-rtems-multilib or something similar). If you need help figuring out the patch feel free to ask. I wrote a blog that might be useful https://www.sifive.com/blog/2017/09/18/all-aboard-part-5-risc-v-multilib/ I will probably add a special multilib set for RTEMS. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: RISC-V ELF multilibs
On 29/05/18 20:02, Jim Wilson wrote: Most variants include the C extension. Would it be possible to add -march=rv32g and -march=rv64g variants? The expectation is that most implementations will include the C extension. It reduces code size, improves performance, and I think I read somewhere that it takes only 400 gates to implement. It isn't practical to try to support every possible combination of architecture and ABI here, as there are too many possible combinations. But if there is a major RISC-V target that is rv32g or rv64g then we should consider it. You can of course define your own set of multilibs. I am not a hardware developer, but I heard that the C extension is not easy to implement in out of order machines. For example: https://www2.eecs.berkeley.edu/Pubs/TechRpts/2017/EECS-2017-157.html -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: RISC-V problem with weak function references and -mcmodel=medany
Hello Jim,
- Am 29. Mai 2018 um 20:27 schrieb Jim Wilson j...@sifive.com:
> On 05/28/2018 06:32 AM, Sebastian Huber wrote:
>> I guess, that the resolution of the weak reference to the undefined
>> symbol __deregister_frame_info somehow sets __deregister_frame_info to
>> the absolute address 0 which is illegal in the following "call
>> __deregister_frame_info"? Is this construct with weak references and a
>> -mcmodel=medany supported on RISC-V at all?
>
> Yes. It works for me. Given a simple testcase
>
> extern void *__deregister_frame_info (const void *)
> __attribute__ ((weak));
> void * foo;
> int
> main (void)
> {
> if (__deregister_frame_info)
> __deregister_frame_info (foo);
> return 0;
> }
>
> and compiling with -mcmodel=medany -O -Ttext=0x8000, I get
would you mind trying this with -Ttext=0x9000?
Please have a look at:
https://sourceware.org/bugzilla/show_bug.cgi?id=23244
https://sourceware.org/ml/binutils/2018-05/msg00296.html
Re: RISC-V problem with weak function references and -mcmodel=medany
Changing the code to something like this
void f(void) __attribute__((__weak__));
void _start(void)
{
void (*g)(void) = f;
if (g != 0) {
(*g)();
}
}
doesn't work either, since this is optimized to
.option nopic
.text
.align 1
.globl _start
.type _start, @function
_start:
lla a5,f
beqz a5,.L1
tail f
.L1:
ret
.size _start, .-_start
.weak f
Why doesn't the RISC-V generate a trampoline code to call far functions?
The non-optimized example code with "tail f" replaced by "jalr a5" links
well:
.option nopic
.text
.align 1
.globl _start
.type _start, @function
_start:
addi sp,sp,-32
sd ra,24(sp)
sd s0,16(sp)
addi s0,sp,32
lla a5,f
sd a5,-24(s0)
ld a5,-24(s0)
beqz a5,.L3
ld a5,-24(s0)
jalr a5
.L3:
nop
ld ra,24(sp)
ld s0,16(sp)
addi sp,sp,32
jr ra
.size _start, .-_start
.weak f
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
RISC-V problem with weak function references and -mcmodel=medany
Hello,
I try to build a 64-bit RISC-V tool chain for RTEMS. RTEMS doesn't use
virtual memory. The reference chips for 64-bit RISC-V such as FU540-C000
locate the RAM at 0x8000_. This forces me to use -mcmodel=medany in
64-bit mode. The ctrbegin.o contains this code (via crtstuff.c):
extern void *__deregister_frame_info (const void *)
__attribute__ ((weak));
...
# 370 "libgcc/crtstuff.c"
static void __attribute__((used))
__do_global_dtors_aux (void)
{
static _Bool completed;
if (__builtin_expect (completed, 0))
return;
# 413 "libgcc/crtstuff.c"
deregister_tm_clones ();
# 423 "libgcc/crtstuff.c"
if (__deregister_frame_info)
__deregister_frame_info (__EH_FRAME_BEGIN__);
completed = 1;
}
Which is:
.text
.align 1
.type __do_global_dtors_aux, @function
__do_global_dtors_aux:
lbu a5,completed.3298
bnez a5,.L22
addi sp,sp,-16
sd ra,8(sp)
call deregister_tm_clones
lla a5,__deregister_frame_info
beqz a5,.L17
lla a0,__EH_FRAME_BEGIN__
call __deregister_frame_info
.L17:
ld ra,8(sp)
li a5,1
sb a5,completed.3298,a4
addi sp,sp,16
jr ra
.L22:
ret
If I link an executable I get this:
/opt/rtems/5/lib64/gcc/riscv64-rtems5/9.0.0/../../../../riscv64-rtems5/bin/ld:
/opt/rtems/5/lib64/gcc/riscv64-rtems5/9.0.0/crtbegin.o: in function `.L0 ':
crtstuff.c:(.text+0x72): relocation truncated to fit: R_RISCV_CALL
against undefined symbol `__deregister_frame_info'
I guess, that the resolution of the weak reference to the undefined
symbol __deregister_frame_info somehow sets __deregister_frame_info to
the absolute address 0 which is illegal in the following "call
__deregister_frame_info"? Is this construct with weak references and a
-mcmodel=medany supported on RISC-V at all?
If I change crtstuff.c like this using weak function definitions
diff --git a/libgcc/crtstuff.c b/libgcc/crtstuff.c
index 5e894455e16..770e3420c92 100644
--- a/libgcc/crtstuff.c
+++ b/libgcc/crtstuff.c
@@ -177,13 +177,24 @@ call_ ## FUNC
(void) \
/* References to __register_frame_info and __deregister_frame_info should
be weak in this file if at all possible. */
-extern void __register_frame_info (const void *, struct object *)
- TARGET_ATTRIBUTE_WEAK;
+extern void __register_frame_info (const void *, struct object *) ;
+TARGET_ATTRIBUTE_WEAK void __register_frame_info (const void *unused,
struct object *unused2)
+{
+ (void)unused;
+ (void)unused2;
+}
+
extern void __register_frame_info_bases (const void *, struct object *,
void *, void *)
TARGET_ATTRIBUTE_WEAK;
-extern void *__deregister_frame_info (const void *)
- TARGET_ATTRIBUTE_WEAK;
+
+extern void *__deregister_frame_info (const void *);
+TARGET_ATTRIBUTE_WEAK void *__deregister_frame_info (const void *unused)
+{
+ (void)unused;
+ return 0;
+}
+
extern void *__deregister_frame_info_bases (const void *)
TARGET_ATTRIBUTE_WEAK;
extern void __do_global_ctors_1 (void);
then the example program links.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
RISC-V ELF multilibs
Hello, I built a riscv64-rtems5 GCC (it uses gcc/config/riscv/t-elf-multilib). The following multilibs are built: riscv64-rtems5-gcc -print-multi-lib .; rv32i/ilp32;@march=rv32i@mabi=ilp32 rv32im/ilp32;@march=rv32im@mabi=ilp32 rv32iac/ilp32;@march=rv32iac@mabi=ilp32 rv32imac/ilp32;@march=rv32imac@mabi=ilp32 rv32imafc/ilp32f;@march=rv32imafc@mabi=ilp32f rv64imac/lp64;@march=rv64imac@mabi=lp64 rv64imafdc/lp64d;@march=rv64imafdc@mabi=lp64d If I print out the builtin defines and search paths for the default settings and the -march=rv64imafdc and compare the results I get: riscv64-rtems5-gcc -E -P -v -dD empty.c > def.txt 2>&1 riscv64-rtems5-gcc -E -P -v -dD empty.c -march=rv64imafdc > rv64imafdc.txt 2>&1 diff -u def.txt rv64imafdc.txt --- def.txt 2018-05-26 14:53:26.277760090 +0200 +++ rv64imafdc.txt 2018-05-26 14:53:47.705638409 +0200 @@ -4,8 +4,8 @@ Configured with: ../gcc-7.3.0/configure --prefix=/opt/rtems/5 --bindir=/opt/rtems/5/bin --exec_prefix=/opt/rtems/5 --includedir=/opt/rtems/5/include --libdir=/opt/rtems/5/lib --libexecdir=/opt/rtems/5/libexec --mandir=/opt/rtems/5/share/man --infodir=/opt/rtems/5/share/info --datadir=/opt/rtems/5/share --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=riscv64-rtems5 --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --verbose --with-newlib --disable-nls --without-included-gettext --disable-win32-registry --enable-version-specific-runtime-libs --disable-lto --enable-newlib-io-c99-formats --enable-newlib-iconv --enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258 --enable-threads --disable-plugin --enable-libgomp --enable-languages=c,c++,ada Thread model: rtems gcc version 7.3.0 20180125 (RTEMS 5, RSB a3a6c34c150a357e57769a26a460c475e188438f, Newlib 3.0.0) (GCC) -COLLECT_GCC_OPTIONS='-E' '-P' '-v' '-dD' '-march=rv64gc' '-mabi=lp64d' - /opt/rtems/5/libexec/gcc/riscv64-rtems5/7.3.0/cc1 -E -quiet -v -P -imultilib rv64imafdc/lp64d empty.c -march=rv64gc -mabi=lp64d -dD +COLLECT_GCC_OPTIONS='-E' '-P' '-v' '-dD' '-march=rv64imafdc' '-mabi=lp64d' + /opt/rtems/5/libexec/gcc/riscv64-rtems5/7.3.0/cc1 -E -quiet -v -P -imultilib rv64imafdc/lp64d empty.c -march=rv64imafdc -mabi=lp64d -dD ignoring nonexistent directory "/opt/rtems/5/lib/gcc/riscv64-rtems5/7.3.0/../../../../riscv64-rtems5/sys-include" #include "..." search starts here: #include <...> search starts here: @@ -338,4 +338,4 @@ #define __ELF__ 1 COMPILER_PATH=/opt/rtems/5/libexec/gcc/riscv64-rtems5/7.3.0/:/opt/rtems/5/libexec/gcc/riscv64-rtems5/7.3.0/:/opt/rtems/5/libexec/gcc/riscv64-rtems5/:/opt/rtems/5/lib/gcc/riscv64-rtems5/7.3.0/:/opt/rtems/5/lib/gcc/riscv64-rtems5/:/opt/rtems/5/lib/gcc/riscv64-rtems5/7.3.0/../../../../riscv64-rtems5/bin/ LIBRARY_PATH=/opt/rtems/5/lib/gcc/riscv64-rtems5/7.3.0/rv64imafdc/lp64d/:/opt/rtems/5/lib/gcc/riscv64-rtems5/7.3.0/../../../../riscv64-rtems5/lib/rv64imafdc/lp64d/:/opt/rtems/5/lib/gcc/riscv64-rtems5/7.3.0/:/opt/rtems/5/lib/gcc/riscv64-rtems5/7.3.0/../../../../riscv64-rtems5/lib/:/lib/:/usr/lib/ -COLLECT_GCC_OPTIONS='-E' '-P' '-v' '-dD' '-march=rv64gc' '-mabi=lp64d' +COLLECT_GCC_OPTIONS='-E' '-P' '-v' '-dD' '-march=rv64imafdc' '-mabi=lp64d' This looks pretty much the same and the documentation says that G == IMAFD. Why is the default multilib and a variant identical? Most variants include the C extension. Would it be possible to add -march=rv32g and -march=rv64g variants? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
GCC-8 branching
Hi, I'd like to ask what is the expected date for GCC branching to GCC-8 release version? I'm mostly interested because I'd like to know when it'll be ok again to add new features? Or are we still able to add them? Thanks, Sebastian
RE: Google Summer of Code 2018: Call for mentors and ideas
Hi Martin, Frankly speaking I believe that students who discussed topics on mailing list might eventually just decide that they were too challenging for them and also competition appeared too difficult. As far as I remember student can only pick few organizations and maybe they just decided to pick some other projects where they expected higher chance of success. After all, as you wrote, it is students work to come up with good projects. Nevertheless, I'd suggest keeping discussions regarding GSoC projects, that took place in mailing list in wiki (as a summary or direct links) for future reference if someone would like to better understand how some elements work in GCC or would like to continue those works. Without any external link I'm afraid it might get lost in the mailing list soon. >From my personal point of view I think you did a great work with handling all >communication regarding GSoC participation and I believe you are a perfect candidate for admin role next year. Sebastian > -Original Message- > Sent: Thursday, March 29, 2018 7:08 PM > Subject: Re: Google Summer of Code 2018: Call for mentors and ideas > > Hi, > > I was wondering how much I should announce publicly about GSoC proposals > since students are not supposed to know in advance that we want any particular > one before they are officially accepted or not by google, but I hope I will > not > overstep any line by saying the following: > > (I am willing to invite any GCC contributer among the mentors, then you can > look at the proposals at the GSoC "dashboard" website. You need gmail account > for that, however.) > > > On Thu, Mar 29 2018, Joseph Myers wrote: > > Now the student application deadline has, I understand, passed, how do > > we go about collectively deciding which are the best proposals to > > request slots for? > > GCC has received 11 proposals for projects, but 7 of them were clearly > unsuitable (two were completely blank, one was a link to a live google > document with the string "WIP" in it, one contained only a short CV of the > applicants, one was three lines suggesting we use a "linked list" > and "hash tags" for memory management, there was also a proposal for driver > able to compile C and python in different sections of a single file, and one > proposal was just spam or an elaborate report on some past java project, I > cannot tell) and 2 were inferior to the point that I also decided they should > not > be considered. None of these two was discussed on the mailing list and both > were basically copied text from an (outdated) wiki page. > > The remaining two are strong candidates, both proposals were discussed at > length here on the mailing list and so I asked for two student slots. > My plan forward is basically to sincerely hope that we get two. If we get > only > one (IIRC we will know on April 10th), I will bring this question up here > (but let's > just toss a coin in that case). > > Generally speaking, I am somewhat disappointed that one or two topics that > were also discussed on the mailing list did not eventually turn up among the > proposals. I should have probably pinged one student and perhaps also two gcc > developers a bit in order to make them come up with something. It also did > not > help that I was traveling to an important meeting in the US last week (and I > had > much less time for email than I thought I would). Nevertheless, it is mostly > students' responsibility to come up with good projects and there is only so > much > we can do about it. However, if the community decides I should be the admin > also next year, I believe I will be able to organize it slightly better. > > Martin
Re: Status of m32c target?
On 13/01/18 00:16, Jeff Law wrote: On 01/12/2018 04:07 PM, Joseph Myers wrote: On Fri, 12 Jan 2018, Jeff Law wrote: I was going to suggest deprecation for gcc-8 given how badly it was broken in gcc-7 and the lack of maintenance on the target. While we're considering deprecations, what happened to the idea of setting a timescale by which cc0 targets need to be converted away from cc0 or be removed? I don't think we ever really hashed through what that might look like. I'd be comfortable saying gcc-8 is the deprecation point. I know some folks won't like that (someone already said so WRT the m68k, but didn't step up to do the conversion), but I think that unless we set a point nothing is likely to happen. How much work is it to convert the m68k to LRA. Is this person days, weeks, months or years? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Status of m32c target?
Hello, what is the status of the m32c target? There are some open bugs that prevent the C/C++ compiler build: https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&list_id=197687&product=gcc&query_format=advanced&short_desc=m32c&short_desc_type=allwordssubstr -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: Build Ada compiler for nios2?
On 04/01/18 16:03, Andreas Schwab wrote: On Jan 04 2018, Sebastian Huber wrote: /home/sh/src/gcc/gcc/config/nios2/nios2.h:436:31: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'nios2_section_threshold' extern unsigned HOST_WIDE_INT nios2_section_threshold; Change the preprocessor conditional to check USED_FOR_TARGET instead of IN_LIBGCC2. Thanks, this worked: nios2-rtems5-gnat --version GNAT 8.0.0 20180105 (experimental) [master revision 9b012eb:c9100e4:1c579c0e17cba22beb7bd87244d1148784c52dab] Copyright (C) 1996-2018, Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Build Ada compiler for nios2?
Hello, I tried to build an Ada compiler for nios2-rtems5 and ended up with this: /run/user/10351/b-gcc-nios2/./gcc/xgcc -B/run/user/10351/b-gcc-nios2/./gcc/ -nostdinc -B/run/user/10351/b-gcc-nios2/nios2-rtems5/newlib/ -isystem /run/user/10351/b-gcc-nios2/nios2-rtems5/newlib/targ-include -isystem /home/sh/src/gcc/newlib/libc/include -B/home/sh/install/nios2-rtems5/bin/ -B/home/sh/install/nios2-rtems5/lib/ -isystem /home/sh/install/nios2-rtems5/include -isystem /home/sh/install/nios2-rtems5/sys-include -c -DCROSS_DIRECTORY_STRUCTURE -DIN_GCC -W -Wall -g -O2 -g -O2 -fexceptions -DIN_RTS -DHAVE_GETIPINFO \ -iquote /home/sh/src/gcc/gcc \ -iquote . -iquote .. -iquote ../.. -iquote /home/sh/src/gcc/gcc/ada -iquote /home/sh/src/gcc/gcc -I/home/sh/src/gcc/include \ targext.c -o targext.o In file included from ../../tm.h:19, from targext.c:46: /home/sh/src/gcc/gcc/config/nios2/nios2.h:436:31: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'nios2_section_threshold' extern unsigned HOST_WIDE_INT nios2_section_threshold; This HOST_WIDE_INT is defined in gcc/hwint.h. Who is supposed to include this file? Is this done via an #include or via a tm_file (gcc/config.gcc)? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: PowerPC64 + Ada + RTEMS: Infinite loop in process_bb_lives()
On 05/12/17 15:17, Segher Boessenkool wrote: Hi! On Mon, Dec 04, 2017 at 03:34:09PM +0100, Sebastian Huber wrote: I added support for the 64-bit PowerPC some months ago using a variant of the ELFv2 ABI. I don't know which kind of long double support I use on this target. This is difficult for me to understand how this works on 64-bit PowerPC. This was no problem up to now since nobody used long double with RTEMS on this target. I tried to build a GCC with Ada support today for the powerpc-rtems5 target. It ends up in infinite loops while building the Ada run-time multilib for a 64-bit PowerPC variant (similar a-coteio.ads): Is this against trunk? Please open a bug, with enough info so we can reproduce the problem. Ideally a simple reduced testcase, but we'll take whatever you have, as long as it allows to reproduce the problem ;-) Thanks for your offer to look at this problem. I opened a bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387 -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
PowerPC64 + Ada + RTEMS: Infinite loop in process_bb_lives()
Hello, I added support for the 64-bit PowerPC some months ago using a variant of the ELFv2 ABI. I don't know which kind of long double support I use on this target. This is difficult for me to understand how this works on 64-bit PowerPC. This was no problem up to now since nobody used long double with RTEMS on this target. I tried to build a GCC with Ada support today for the powerpc-rtems5 target. It ends up in infinite loops while building the Ada run-time multilib for a 64-bit PowerPC variant (similar a-coteio.ads): gdb --args /build/git-build/b-gcc-git-powerpc-rtems5/./gcc/gnat1 -gnatwa -quiet -nostdinc -nostdinc -dumpbase a-scteio.ads -auxbase-strip a-scteio.o -O2 -Wextra -Wall -g -mcpu=e6500 -msoft-float -gnatpg -mcpu=e6500 -m64 -msoft-float -mno-altivec -gnatO a-scteio.o a-scteio.ads ... (gdb) bt #0 process_bb_lives (bb=0x7700a680, curr_point=@0x7fffd38c: 387, dead_insn_p=dead_insn_p@entry=false) at /scratch/svn-gcc/gcc/lra-lives.c:838 #1 0x00b32b3a in lra_create_live_ranges_1 (all_p=all_p@entry=true, dead_insn_p=dead_insn_p@entry=false) at /scratch/svn-gcc/gcc/lra-lives.c:1305 #2 0x00b33620 in lra_create_live_ranges (all_p=all_p@entry=true, dead_insn_p=dead_insn_p@entry=false) at /scratch/svn-gcc/gcc/lra-lives.c:1369 #3 0x00b159c2 in lra (f=) at /scratch/svn-gcc/gcc/lra.c:2438 #4 0x00ac95d2 in do_reload () at /scratch/svn-gcc/gcc/ira.c:5443 #5 (anonymous namespace)::pass_reload::execute (this=) at /scratch/svn-gcc/gcc/ira.c:5627 #6 0x00bc1d49 in execute_one_pass (pass=pass@entry=0x24cc430) at /scratch/svn-gcc/gcc/passes.c:2497 #7 0x00bc25f1 in execute_pass_list_1 (pass=0x24cc430) at /scratch/svn-gcc/gcc/passes.c:2586 #8 0x00bc2603 in execute_pass_list_1 (pass=0x24cb350) at /scratch/svn-gcc/gcc/passes.c:2587 #9 0x00bc2645 in execute_pass_list (fn=, pass=) at /scratch/svn-gcc/gcc/passes.c:2597 #10 0x00883683 in cgraph_node::expand (this=0x76fd6000) at /scratch/svn-gcc/gcc/cgraphunit.c:2139 #11 0x00884bd1 in expand_all_functions () at /scratch/svn-gcc/gcc/cgraphunit.c:2275 #12 symbol_table::compile (this=this@entry=0x76e48000) at /scratch/svn-gcc/gcc/cgraphunit.c:2623 #13 0x00887477 in symbol_table::compile (this=0x76e48000) at /scratch/svn-gcc/gcc/cgraphunit.c:2719 #14 symbol_table::finalize_compilation_unit (this=0x76e48000) at /scratch/svn-gcc/gcc/cgraphunit.c:2716 #15 0x00c938dd in compile_file () at /scratch/svn-gcc/gcc/toplev.c:480 #16 0x0044485d in do_compile () at /scratch/svn-gcc/gcc/toplev.c:2059 #17 toplev::main (this=this@entry=0x7fffd72e, argc=, argc@entry=23, argv=, argv@entry=0x7fffd828) at /scratch/svn-gcc/gcc/toplev.c:2194 #18 0x00446bdb in main (argc=23, argv=0x7fffd828) at /scratch/svn-gcc/gcc/main.c:39 (gdb) -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: atomic_thread_fence() semantics
On 19/10/17 14:18, Andrew Haley wrote: On 19/10/17 13:10, Jonathan Wakely wrote: There are no atomic operations on atomic objects here, so the fence doesn't synchronize with anything. Really? This seems rather unhelpful, to say the least. An atomic release operation X in thread A synchronizes-with an acquire fence F in thread B, if there exists an atomic read Y (with any memory order) Y reads the value written by X (or by the release sequence headed by X) Y is sequenced-before F in thread B In this case, all non-atomic and relaxed atomic stores that happen-before X in thread A will be synchronized-with all non-atomic and relaxed atomic loads from the same locations made in thread B after F. Where is the acquire fence or a load in the example? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: -ffunction-sections and -fdata-sections documentation
On 16/10/17 12:31, David Brown wrote:
On 13/10/17 09:06, Sebastian Huber wrote:
Hello,
I would like to update the documentation of these compiler flags and
have some questions. The -ffunction-sections and -fdata-sections
documentation is currently:
Do these options affect the code generation?
-fdata-sections certainly can affect code generation on some targets.
Testing with this sample, using gcc 6.3 for the ARM with -O2:
int a, b, c;
void foo(void) {
a = 1;
b = 1;
c = 1;
}
Generated assembly code is:
foo():
mov r2, #1
ldr r3, .L2
str r2, [r3]
str r2, [r3, #4]
str r2, [r3, #8]
bx lr
.L2:
.word .LANCHOR0
With -fdata-section, you get:
foo():
mov r3, #1
ldr r0, .L2
ldr r1, .L2+4
ldr r2, .L2+8
str r3, [r0]
str r3, [r1]
str r3, [r2]
bx lr
.L2:
.word .LANCHOR0
.word .LANCHOR1
.word .LANCHOR2
I only realised this recently, but it can make a significant difference
on targets that don't use direct addressing modes (such as ARM). It is
maybe worth mentioning this in any changes to the gcc documentation.
I already sent a documentation patch:
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00959.html
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: -ffunction-sections and -fdata-sections documentation
- Am 13. Okt 2017 um 20:39 schrieb David Edelsohn dje@gmail.com: > On Fri, Oct 13, 2017 at 2:34 PM, Sebastian Huber > wrote: > >>>> Do these options affect the code generation? >>> They can affect code generation. By placing each object into its own >>> section it's no longer viable to use one object to refer to another >>> because the relative addresses are unknown until link time. Without >>> those options the assembler can compute the offset between two objects >>> within a given section when they come from the same translation unit. >> >> Is this similar to moving all distinct objects into one compiler generated >> structure? > > It places each function and each datum into a separate section, which > can be placed or removed independently. It is not combining data or > altering the order of structures. It allows the linker to position > functions and data items as individual components instead of a single > object file "text" or "data" blobs. Is the optimization opportunity described by Jeff (which is prevented by the use of function and data sections) similar to moving all distinct objects into one compiler generated structure?
