#4078 assigned defect

GCC C++ compiler for powerpc defines _GNU_SOURCE as a built-in

Reported by: Sebastian Huber Owned by: Sebastian Huber
Priority: normal Milestone: 6.1
Component: arch/powerpc Version: 6
Severity: normal Keywords:
Cc: Blocked By:
Blocking:

Description (last modified by Sebastian Huber)

For example:

powerpc-rtems6-g++ -E -P -v -dD empty.cc 2>&1 | grep GNU_SOURCE

Yields:

 /opt/rtems/6/libexec/gcc/powerpc-rtems6/10.2.1/cc1plus -E -quiet -v -P -D_GNU_SOURCE -Dmpc750 empty.cc -dD
#define _GNU_SOURCE 1

This is a GCC configuration bug. The reason is that the RTEMS GCC configuration includes gnu-user.h.

Change History (4)

comment:1 Changed on Sep 14, 2020 at 6:52:17 AM by Sebastian Huber

Description: modified (diff)

comment:2 Changed on Sep 14, 2020 at 12:53:32 PM by Joel Sherrill

I agree that this isn't right. We shouldn't be implicitly defining anything that enables extended APIs.

How did you spot this?

comment:3 Changed on Sep 14, 2020 at 3:19:38 PM by Sebastian Huber

I noticed this during the tests of the new build system. The powerpc is the only RTEMS target which defines _GNU_SOURCE.

comment:4 in reply to:  2 Changed on Sep 15, 2020 at 3:19:01 AM by Chris Johns

Replying to Joel Sherrill:

How did you spot this?

I have updated rtems-exeinfo to optionally output the full flags used to build an object file.

$ rtems-exeinfo -O --full-flags `find . -name hello.exe`

This is the output from hello.exe for the psim showing a mix of options:

   | wcrtomb.c                         : -mcpu=603e -mcpu=603e -g -O2 -fno-builtin -ffunction-sections -fdata-sections
   | wctomb_r.c                        : -mcpu=603e -mcpu=603e -g -O2 -fno-builtin -ffunction-sections -fdata-sections
   | wkspace.c                         : -mcall-sysv -meabi -mcpu=603e -msdata=sysv -g -O2 -fno-common -fno-keep-inline-functions -ffunction-sections -fdata-sections
   | wkspaceisunifieddefault.c         : -mcall-sysv -meabi -mcpu=603e -msdata=sysv -g -O2 -fno-common -fno-keep-inline-functions -ffunction-sections -fdata-sections
   | write.c                           : -mcall-sysv -meabi -mcpu=603e -msdata=sysv -g -O2 -fno-common -fno-keep-inline-functions -ffunction-sections -fdata-sections
   | write_r.c                         : -mcall-sysv -meabi -mcpu=603e -msdata=sysv -g -O2 -fno-common -fno-keep-inline-functions -ffunction-sections -fdata-sections
   | wsetup.c                          : -mcpu=603e -mcpu=603e -g -O2 -fno-builtin -ffunction-sections -fdata-sections

And there is the pc686 BSP with LibBSD showing the i386 issue:

   | tzset.c                               : -mtune=pentiumpro -march=i386 -g -O2 -fno-builtin -ffunction-sections -fdata-sections
   | tzset_r.c                             : -mtune=pentiumpro -march=i386 -g -O2 -fno-builtin -ffunction-sections -fdata-sections
   | tzvars.c                              : -mtune=pentiumpro -march=i386 -g -O2 -fno-builtin -ffunction-sections -fdata-sections
   | u_strerr.c                            : -mtune=pentiumpro -march=i386 -g -O2 -fno-builtin -ffunction-sections -fdata-sections
   | uart_bus_pci.c                        : -mtune=pentiumpro -march=pentium -g -O2 -ffunction-sections -fdata-sections
   | udp6_usrreq.c                         : -mtune=pentiumpro -march=pentium -g -O2 -ffunction-sections -fdata-sections -fno-strict-aliasing -ffreestanding -fno-common
   | udp_usrreq.c                          : -mtune=pentiumpro -march=pentium -g -O2 -ffunction-sections -fdata-sections -fno-strict-aliasing -ffreestanding -fno-common
   | uenvgetgroups.c                       : -mtune=pentiumpro -march=pentium -g -O2 -ffunction-sections -fdata-sections
   | uipc_accf.c                           : -mtune=pentiumpro -march=pentium -g -O2 -ffunction-sections -fdata-sections -fno-strict-aliasing -ffreestanding -fno-common
   | uipc_domain.c                         : -mtune=pentiumpro -march=pentium -g -O2 -ffunction-sections -fdata-sections -fno-strict-aliasing -ffreestanding -fno-common

I think preprocessor flags are not captured.

Last edited on Sep 15, 2020 at 3:20:36 AM by Chris Johns (previous) (diff)
Note: See TracTickets for help on using tickets.