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/
Re: No type checking in ctype builtins
* Andreas Schwab:
> On Apr 27 2022, Andrea Monaco via Gcc wrote:
>
>> This program
>>
>> #include
>>
>> int main ()
>> {
>> char *s;
>> isspace (s);
>> }
>>
>> compiles with no warning in gcc 8.3.0, even though there's a type
>> mistake; the correct call would be isspace (*s).
>
> Try -Wsystem-headers.
>
>> The ctype functions are implemented as macros in glibc, so you can't
>> have type checking. But they are also provided as builtins by gcc, so I
>> wonder why type checking is not performed in that case, either.
>
> You need to suppress the macro to get the builtin.
Shouldn't that happen automatically with -O2?
I think it's a header bug, we don't use inline functions in C mode, only
in C++ mode:
#ifndef __cplusplus
# define __isctype(c, type) \
((*__ctype_b_loc ())[(int) (c)] & (unsigned short int) type)
#elif defined __USE_EXTERN_INLINES
# define __isctype_f(type) \
__extern_inline int \
is##type (int __c) __THROW \
{ \
return (*__ctype_b_loc ())[(int) (__c)] & (unsigned short int) _IS##type; \
}
#endif
Thanks,
Florian
Re: No type checking in ctype builtins
On Wed, Apr 27, 2022 at 12:20 PM Jonathan Wakely via Gcc
wrote:
>
> On Wed, 27 Apr 2022 at 16:29, Andrea Monaco via Gcc wrote:
> >
> >
> > This program
> >
> > #include
> >
> > int main ()
> > {
> > char *s;
> > isspace (s);
> > }
> >
> > compiles with no warning in gcc 8.3.0, even though there's a type
> > mistake; the correct call would be isspace (*s).
>
> N.B. The correct call would be isspace((unsigned char)*s) because
> isspace has undefined behaviour if you pass it a char with a negative
> value.
>
> It would be nice if GCC warned about *that*.
Related bugs:
78155: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78155
99950: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99950
Re: gnatlink vs. -mthumb -march=armv7-a+simd -mfloat-abi=hard
On Thu, Apr 28, 2022, 3:17 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> 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? > Any chance you can see in the tools build log how that file is actually compiled? I'm suspicious that this multilib is named in a complicated way and their command line parsing doesn't get it all the way through the layers. Years ago I added -Gn support to this process so they could handle the MIPS for RTEMS. What would have to be stripped off of the arts to result in this? --joel > -- > 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 12.0.1 Status Report (2022-04-28)
Status == We have reached zero P1 regressions today and releases/gcc-12 branch has been created. GCC 12.1-rc1 will be built likely tomorrow. The branch is now frozen for blocking regressions and documentation fixes only, all changes to the branch require a RM approval now. If no show stoppers appear, we'd like to release 12.1 late next week, or soon after that, if any important issues are discovered and fixed, rc2 could be released next week. Quality Data Priority # Change from last report --- --- P1 0 - 23 P2 364 - 23 P3 76- 8 P4 253 + 5 P5 26+ 1 --- --- Total P1-P3 440 - 54 Total 719 - 48 Previous Report === https://gcc.gnu.org/pipermail/gcc/2022-April/238491.html
Re: gnatlink vs. -mthumb -march=armv7-a+simd -mfloat-abi=hard
On 28/04/2022 09:16, Sebastian Huber wrote: /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 Does that source file somehow attempt to change the architecture on that line? This looks like something equivalent to a pragma changing things. R.
GCC 13.0.0 Status Report (2022-04-28)
Status == The trunk has branched for the GCC 12 release and is now open again for general development, stage 1. Please consider not disrupting it too much during the RC phase of GCC 12 so it is possible to test important fixes for 12.1 on it. Quality Data Priority # Change from last report --- --- P1 0 - 23 P2 371 - 16 P3 77- 7 P4 253 + 5 P5 26+ 1 --- --- Total P1-P3 448 - 46 Total 727 - 40 Previous Report === https://gcc.gnu.org/pipermail/gcc/2022-April/238491.html
Re: GCC 12.0.1 Status Report (2022-04-28)
On 4/28/2022 8:59 AM, Jakub Jelinek via Gcc wrote: Status == We have reached zero P1 regressions today and releases/gcc-12 branch has been created. GCC 12.1-rc1 will be built likely tomorrow. The branch is now frozen for blocking regressions and documentation fixes only, all changes to the branch require a RM approval now. If no show stoppers appear, we'd like to release 12.1 late next week, or soon after that, if any important issues are discovered and fixed, rc2 could be released next week. Do you want me to adjust the testsuite so that we handle the new linker warnings for executable stacks better? The situation now isn't ideal in that we're showing spurious regressions if we use the development binutils bits. My pending change backs out my change to gcc.dg/lto/pr04157_0.c and instead prunes the new warnings out in prune.exp. I was waiting on validation of a couple targets in my tester which completed yesterday. Jeff
Re: GCC 12.0.1 Status Report (2022-04-28)
On Thu, Apr 28, 2022 at 09:25:43AM -0600, Jeff Law via Gcc wrote: > On 4/28/2022 8:59 AM, Jakub Jelinek via Gcc wrote: > > Status > > == > > > > We have reached zero P1 regressions today and releases/gcc-12 branch has > > been created. GCC 12.1-rc1 will be built likely tomorrow. > > The branch is now frozen for blocking regressions and documentation > > fixes only, all changes to the branch require a RM approval now. > > > > If no show stoppers appear, we'd like to release 12.1 late next week, > > or soon after that, if any important issues are discovered and > > fixed, rc2 could be released next week. > Do you want me to adjust the testsuite so that we handle the new linker > warnings for executable stacks better? The situation now isn't ideal in > that we're showing spurious regressions if we use the development binutils > bits. > > My pending change backs out my change to gcc.dg/lto/pr04157_0.c and instead > prunes the new warnings out in prune.exp. I was waiting on validation of a > couple targets in my tester which completed yesterday. Ok if committed today. With the RC we are mainly waiting on PR105417 fix. Jakub
Re: GCC 12.0.1 Status Report (2022-04-28)
On 4/28/2022 9:29 AM, Jakub Jelinek wrote: On Thu, Apr 28, 2022 at 09:25:43AM -0600, Jeff Law via Gcc wrote: On 4/28/2022 8:59 AM, Jakub Jelinek via Gcc wrote: Status == We have reached zero P1 regressions today and releases/gcc-12 branch has been created. GCC 12.1-rc1 will be built likely tomorrow. The branch is now frozen for blocking regressions and documentation fixes only, all changes to the branch require a RM approval now. If no show stoppers appear, we'd like to release 12.1 late next week, or soon after that, if any important issues are discovered and fixed, rc2 could be released next week. Do you want me to adjust the testsuite so that we handle the new linker warnings for executable stacks better? The situation now isn't ideal in that we're showing spurious regressions if we use the development binutils bits. My pending change backs out my change to gcc.dg/lto/pr04157_0.c and instead prunes the new warnings out in prune.exp. I was waiting on validation of a couple targets in my tester which completed yesterday. Ok if committed today. With the RC we are mainly waiting on PR105417 fix. I'll push it shortly. jeff
gcc-10-20220428 is now available
Snapshot gcc-10-20220428 is now available on https://gcc.gnu.org/pub/gcc/snapshots/10-20220428/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 10 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-10 revision acbd0fbdfbffc43b4aa7def2d527b2be50e7dd02 You'll find: gcc-10-20220428.tar.xz Complete GCC SHA256=98e8c2c8335e035df2b48e9e50fec20379de767d53852742474b272bac00bfcd SHA1=8241747ab05b99105197c3957f32cad5d055afd9 Diffs from 10-20220422 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-10 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
