Re: [PATCH] Check for sysconf decl on vxworks

Good for me, thanks Alex! > On 24 May 2023, at 07:08, Alexandre Oliva wrote: > > > The sysconf function is only available in rtp mode on vxworks. In > kernel mode, it is not even declared, but the feature test macro in > the testsuite doesn't notice its absence because it's a link test, and

Re: [patch] configury support for VxWorks shared libraries

> On 10 Oct 2022, at 21:38, Jonathan Wakely wrote: > > On Mon, 10 Oct 2022 at 19:06, Olivier Hainque via Libstdc++ > wrote: >> >> Sorry, I forgot to cc libstdc++ on >> >> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603182.html >> >> which includes a regen of libstdc++-v3/config

Re: [patch] configury support for VxWorks shared libraries

Sorry, I forgot to cc libstdc++ on https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603182.html which includes a regen of libstdc++-v3/configure after an update libtool.m4. Not committed yet. With Kind Regards, Olivier > On 10 Oct 2022, at 19:05, Olivier Hainque wrote: > > Hello,

[patch] configury support for VxWorks shared libraries

Hello, This change introduces configury infrastructure allowing the production of shared libraries for VxWorks, amenable to use with non-static rtps (linked with "-non-static"). The ability to produce PIC code is not a given on all VxWorks configurations, so activating this has to be explicitly r

[patch] Tighten VXWORKS_LIBGCC_SPEC wrt libgcc_eh

Hello, VxWorks has a custom definition of LIBGCC_SPEC to accommodate the variety of "modules" a user can build (dkm, sharedlib (-shared), static rtp, or rtp depending on shared libs (-non-static)) This change reworks that spec to better support configurations with shared libraries enabled (patch

[patch] specialize paths to version.h in _vxworks-versions.h

The _vxworks-versions.h runtime file helps us control the compilation of some library components depending on the OS version extracted out of a system header. The system header name is "version.h", and gcc has a "version.h" file of its own. gcc's version.h is now generated and the current #inclu

[patch] Downgrade DWARF_VERSION_DEFAULT to 3 for VxWorks >= 7

Hello, Using 4 as the DWARF_VERSION_DEFAULT value for VxWorks observably still hangs recent system debuggers on tbreak for some contructs, and downgrading to 3 improves the situation. Committing to mainline shortly. Cheers, Olivier 2022-03-06 Olivier Hainque gcc/ * config/vxworks.h

Re: [PATCH] undef offsetof before defining it in stddef.h

> On 6 Oct 2022, at 14:17, Richard Biener wrote: >> >> Ok to commit? > > OK. Thanks!

Re: [PATCH] Introduce DWARF_VERSION_DEFAULT (and redefine for VxWorks)

> On 6 Oct 2022, at 14:15, Richard Biener wrote: > >> Is this ok to commit? > > I think this is reasonable, thus OK. Great, thanks Richard :-)

Re: [patch] Fix thinko in powerpc default specs for -mabi

Hi Segher, > On 3 Oct 2022, at 18:13, Segher Boessenkool > wrote: > > -mabi= does two separate things, unfortunately. > > First, you can use it to set the base ABI: elfv1, elfv2. But you can > also use it to set ABI variants, ABI options: -mabi={no-,}altivec, > -mabi={ieee,ibm}longdouble, -ma

Re: [patch] Fix thinko in powerpc default specs for -mabi

Hello, Gentle ping for https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602143.html > 2022-09-14 Olivier Hainque > > * config/rs6000/option-defaults.h (OPTION_DEFAULT_SPECS): > Have any -mabi, not only -mabi=elfv*, override the --with-abi > configuration defa

[PATCH] undef offsetof before defining it in stddef.h

Hello, The attached patch is a proposal to #undef offsetof before the #define we do in ginclude/stddef.h, which prevents redefinition warnings from dg tests passing -Wsystem-headers on systems which provide a definition in system headers, such as VxWorks. We have been using this for a while with

[PATCH] Introduce DWARF_VERSION_DEFAULT (and redefine for VxWorks)

Hello, This change is a proposal to introduce a target overridable macro to replace the hardcoded value used in common.opt to initialize dwarf_version. The main advantage compared to special code in a target override_options hook is that redefinitions by target config files are visible by both th

[patch] Prevent secondary warning from diagnostic tweak in gthr-vxworks.h

Within gthr-vxworks.h, we prevent C++ errors from missing declarations in some system headers by prepending their inclusion with a #pragma GCC diagnostic ignored "-Wstrict-prototypes" But Wstrict-prototypes is internally registered as valid for C/ObjC only, not C++, and this trick in turn tr

[patch] Refine INITFINI condition for vxworks crtstuff spec

Hello, Working on the reintroduction of shared libraries support (and of modules depending on shared libraries) exposed a few test failures of simple c++ constructor tests on arm-vxworks7r2. Investigation revealed that we were not linking the crtstuff objects as needed from a compiler configured

[patch] Adjust LIBGCC2_INCLUDES for VxWorks and augment comment

Hello, Investigating the reasons for libgcc build failures in a canadian context, orthogonally to the recent update of vxcrtstuff, exposed interesting differences in the way include search paths are managed between a regular Linux->VxWorks cross build and a canadian setup building a Windows->VxWor

[patch] Improve comments and INITFINI macro use in vxcrtsutff.c

Hello, This change augments the comment attached to the use of auto-host.h in vxcrtstuff.c to better describe the reason for including it and for the associated series of #undef directives. It also augments the comment on dso_handle and removes a redundant guard on HAVE_INITFINI_ARRAY_SUPPORT for

[patch] Define a GCC_DRIVER_HOST_INITIALIZATION for VxWorks

Hello, This change prepares the ground prior to the reintroduction of shared libs support for VxWorks. On this platform, the use of shared libraries involves unusual steps compared to standard native systems and enforcing static links by default improves user experience. This change arranges for

[patch] Arrange to --disable-shared by default for VxWorks

Hello, Preparing a set of changes to support shared libs for VxWorks (again), this patch makes sure that shared libraries for this family of targets are only built on explicit request, when configured with --enable-shared (by passing down --disable-shared to subdirs otherwise). This provides us w

[patch] comment about HAVE_INITFINI_ARRAY_SUPPORT in vxworks.h

Hello, This change simply adds a comment in vxworks.h, describing our expectations wrt our use of HAVE_INITFINI_ARRAY_SUPPORT from this header. Committing to mainline shortly. Cheers, Olivier 2022-09-29 Olivier Hainque gcc/ * config/vxworks.h: Add comment on our use of HAVE

[patch] Robustify DWARF2_UNWIND_INFO handling in vx-common.h

Hello, This adjusts vx-common.h to #define DWARF2_UNWIND_INFO to 0 when ARM_UNWIND_INFO is set, preventing defaults.h from possibly setting DWARF2_UNWIND_INFO to 1 (as well) on its own afterwards if the macro isn't defined. We have been using this for a while in gcc-11 development toolchains for

[patch] Add an mcmodel=large multilib for aarch64-vxworks

Hello, This makes good sense in general anyway, and in particular with forthcoming support for shared shared libraries, which will work for mrtp alone but not yet for mrtp+mcmodel=large. We have been using this in gcc-11 based development toolchains for a while. Committing to mainline. Regards,

[patch] Remove TARGET_FLOAT128_ENABLE_TYPE setting for VxWorks

Hello, We have, in vxworks.h: /* linux64.h enables this, not supported in vxWorks. */ #undef TARGET_FLOAT128_ENABLE_TYPE #define TARGET_FLOAT128_ENABLE_TYPE 0 We inherit linux64.h for a few reasons, but don't really support float128 for vxworks, so the setting made sense. Many tests rely

[patch] Fix thinko in powerpc default specs for -mabi

Hello, For a powerpc compiler configured with --with-abi=elfv2, an explicit -mabi option other than elfv1 fails to override the default. For example, after [...]/configure --enable-languages=c --target=powerpc-elf --with-abi=elfv2 make all-gcc This command: ./gcc/xgcc -B./gcc/ t.c -mabi=

Re: [PATCH] libstdc++: vxworks: remove stray include

Good for me, thanks Rasmus. > On 4 Mar 2022, at 09:27, Rasmus Villemoes wrote: > > There doesn't seem to be any reason for this TU to include > , and it causes errors when the resulting libstdc++ is used > on our VxWorks 5.5 target - presumably because now libstdc++ itself > contains an instanc

Re: [PATCH] Add VxWorks fixincludes hack, open posix API

Hi Rasmus, > On 17 Dec 2021, at 13:49, Rasmus Villemoes wrote: > > In the end, we ended up adding a two-argument overload for C++ only, as > this is/was only relevant for getting libstdc++ (more specifically, the > new filesystem abstraction stuff) to build. That is, we added > > +#if __GNUC__

Re: [PATCH] Add VxWorks fixincludes hack, kernel math.h FP_ constants

Hi Rasmus, > On 17 Dec 2021, at 21:47, Olivier Hainque wrote: > >>> Don't you also need to add an fpclassify() macro? There's a >> >> We have a separate "fix" for a set of such functions indeed. > I probably can merge the two, actually. I'll do that. We have had pretty good results with the a

[PATCH] Add VxWorks fixincludes hack, #include sysLib.h in time.h

Hello, This change instates a new vxworks fixincludes hack to make sure there is a visible prototype of sysClkRateGet() when CLOCKS_PER_SEC is #defined to that in time.h for VxWorks < 7 (fixincludes not run otherwise). The function is provided by sysLib.h, so we arrange to #include this one at a

Re: [PATCH] Improve sequence logic in cxx_init_decl_processing

> On 10 Jan 2022, at 20:02, Jason Merrill wrote: > >> The attached patch just moves the reset above the test. > > OK. Great, thanks Jason! >> 2021-12-30 Olivier Hainque >> gcc/ >> * cp/decl.c (cxx_init_decl_processing): Move code possibly >> altering flag_weak before code testi

Re: [PATCH] Register --sysroot in the driver switches table

> On 10 Jan 2022, at 09:00, Richard Biener wrote: > > On Wed, Jan 5, 2022 at 6:58 PM Olivier Hainque via Gcc-patches > wrote: >> >> >> >>> On 5 Jan 2022, at 10:26, Olivier Hainque wrote: >>> >>> The change should also s

[PATCH] Improve sequence logic in cxx_init_decl_processing

Hello, commit aa2c978400f3b3ca6e9f2d18598a379589e77ba0, introduced per https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545552.html makes references to __cxa_pure_virtual weak and this is causing issues on some VxWorks configurations, where weak symbols are only supported for one of the two

Re: [PATCH] Register --sysroot in the driver switches table

> On 5 Jan 2022, at 10:26, Olivier Hainque wrote: > > The change should also set "validated" true > when requesting to save --sysroot. The attached adjustment fixes the failure I could reproduce, bootstraps and regtests fine on x86_64-linux, and passes a build + a couple of in-house testsuite

Re: [PATCH] Register --sysroot in the driver switches table

Hi Martin, > On 5 Jan 2022, at 08:45, Martin Liška wrote: > > On 12/20/21 22:28, Olivier Hainque via Gcc-patches wrote: > I think the patch broke my cross-rx-gcc12 package, failing now with: > configure: error: in > `/home/abuild/rpmbuild/BUILD/gcc-12.0.0+git190624/obj-x8

Re: [PATCH] Register --sysroot in the driver switches table

> On 28 Dec 2021, at 17:38, Jeff Law wrote: >> gcc/ >> * gcc.c (driver_handle_option): do_save --sysroot. > OK. Thanks for the prompt review Jeff! I have another simple one coming :)

[PATCH] Register --sysroot in the driver switches table

Hello, This change adjusts the processing of --sysroot to save the option in the internal "switches" array, which lets self-specs test for it and provide a default value possibly dependent on environment variables, as in --with-specs=%{!-sysroot*:--sysroot=%:getenv("WIND_BASE" /target)} This h

Re: [PATCH] Adjust VxWorks fixincludes hack for mkdir to work for C++

> On 20 Dec 2021, at 17:31, Jeff Law wrote: > > Given how vxworks specific these fixinc bits are, I think they reasonably > fall under maintainership of vxworks bits. > > So I think you can/should self-approve :-) Thanks Jeff, Rasmus has provided useful feedback on some of the hunks and I'

Re: [PATCH] Leverage sysroot for VxWorks

Hi Rasmus, > On 20 Dec 2021, at 12:40, Rasmus Villemoes wrote: > > On 10/12/2021 19.24, Olivier Hainque wrote: > >> For the toolchains we build, this is achieved with a few >> configure options like: >> >> --with-sysroot >> --with-build-sysroot=${WIND_BASE}/target > > So forward-porting o

Re: [PING] Fix size of static array in gcc.dg/vect/vect-simd-20.c

> On 20 Dec 2021, at 16:32, Jeff Law wrote: > > > > On 12/17/2021 4:21 AM, Olivier Hainque via Gcc-patches wrote: >> Hello, >> >> Ping for https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583222.html >> >> please ? >> >>

Re: [PATCH] Add VxWorks fixincludes hack, kernel math.h FP_ constants

> On 17 Dec 2021, at 20:16, Olivier Hainque wrote: > >> Don't you also need to add an fpclassify() macro? There's a >> >> checking for ISO C99 support in for C++98 >> >> which checks whether math.h supplies (among others) fpclassify(). > > We have a separate "fix" for a set of such functio

Re: [PATCH] Add VxWorks fixincludes hack, kernel math.h FP_ constants

Hi again Rasmus, > On 17 Dec 2021, at 14:03, Rasmus Villemoes wrote: > > On 17/12/2021 13.10, Olivier Hainque wrote: >> Hello, >> >> The attached patch adds a fixincludes add for VxWorks >> to add missing FP_ constant definition to math.h, intended >> for old versions of the kernel math.h heade

Re: [PATCH] Add -mdejagnu-cpu=power9 to dg-options for pr97142.c

> On 17 Dec 2021, at 16:17, Segher Boessenkool > wrote: > >> In this instance, it's simple enough to be quoted directly: > > You may want to look into git send-email :-) Eh, indeed. >> --- a/gcc/testsuite/gcc.target/powerpc/pr97142.c >> +++ b/gcc/testsuite/gcc.target/powerpc/pr97142.c >> @

Re: [PATCH] Add VxWorks fixincludes hack, open posix API

> On 17 Dec 2021, at 15:33, Rasmus Villemoes wrote: > > On 17/12/2021 15.12, Olivier Hainque wrote: >> Hi Rasmus >> >>> On 17 Dec 2021, at 13:49, Rasmus Villemoes >>> wrote: >> >>> I'm not sure what to do. But this patch will definitely break our build >>> - primarily because we've done a

Re: [PATCH] Add VxWworks fixincludes hack, prevent #include_next yvals.h

> On 17 Dec 2021, at 14:16, Rasmus Villemoes wrote: > > There's no yvals.h header in VxWorks 5.5, so I'm not sure I need to have > an opinion on this one. I wasn't sure about the situation on 5.5 but the fix just wont apply if there's no yvals.h around anyway. Cheers, Olivier

Re: [PATCH] Add VxWorks fixincludes hack, open posix API

Hi Rasmus > On 17 Dec 2021, at 13:49, Rasmus Villemoes wrote: > I'm not sure what to do. But this patch will definitely break our build > - primarily because we've done a private workaround. I don't think we can reasonably cope with private changes to system headers. Can't you just undo your w

Re: [PATCH] Add -mdejagnu-cpu=power9 to dg-options for pr97142.c

> On 17 Dec 2021, at 13:58, Segher Boessenkool > wrote: > > Hi Olivier, > > Thanks for the patch! > > Please use p7 instead of p9. Sure. > Also, you attached some binary, so I cannot reply to it easily. Ah, sorry. I did remember you told me this in the past and renamed the file .diff to

[PATCH] Add VxWworks fixincludes hack, prevent #include_next yvals.h

Hello, yvals.h on VxWorks expects the toolchain to provide its own version of the header, which we don't do. The attached patch adds a fixincludes hack to arrange to fallback on the common system definitions instead. We were able to get a successful complete build with c++ and libstdc++ after th

[PATCH] Add VxWorks fixincludes hack, kernel math.h FP_ constants

Hello, The attached patch adds a fixincludes add for VxWorks to add missing FP_ constant definition to math.h, intended for old versions of the kernel math.h header. As the other patches in the series, this helps libstdc++ build failures for old versions of VxWorks, 6.9 in particular for which we

[PATCH] Add VxWorks fixincludes hack, open posix API

Hello, The attach patch adds a fixincludes "hack" for VxWorks to expose a more flexible (varargs) function prototype for 'open', able to accept calls with 2 or 3 arguments as we observe during libraries builds for powerpc vxworks 6.9. We have been using this for a while in-house. I could still ob

[PATCH] Adjust VxWorks fixincludes hack for mkdir to work for C++

Hello, The attached patch adjusts a very old fixincludes hack for VxWorks, to expose a varargs function prototype for "mkdir" instead of a varargs macro (!). The function version is more amenable to calls from C++ like std::mkdir(arg1, arg2). This helps libstdc++ build failures for old versions

[PATCH] Add -mdejagnu-cpu=power9 to dg-options for pr97142.c

Hello, gcc.target/powerpc/pr97142.c scans the output assembly for specific instructions which our toolchain configured to default to -mcpu=604 doesn't produce. The PR refers to a power9 configuration for the original report, so the attached patch is a suggestion to add a -mdejagnu-cpu=power9 to d

[PING] Fix size of static array in gcc.dg/vect/vect-simd-20.c

Hello, Ping for https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583222.html please ? Thanks in advance! With Kind Regards, Olivier > On 3 Nov 2021, at 15:54, Olivier Hainque wrote: > > Hello, > > This fixes the definition of the "p" static array in > gcc.dg/vect/vect-simd-20.c to a

[PATCH] Remove fpic multilib on x86_64-vxworks

The addition of fPIC for shared libraries is performed independently from multilibs and fpic multilibs have no other particular purpose for VxWorks at this stage. Tested together with our recent cleanups in the shared-objects support area, for a mix of builds/tests for vxworks 6.9 and 7.2 with our

[PATCH] Drop the fpic multilib for VxWorks on powerpc

The addition of fPIC for shared libraries is performed independently from multilibs and fpic multilibs have no other particular purpose for VxWorks at this stage. They incur extra build time, complexify the install tree and are a bit tricky because -fpic is not supported for kernel mode. Tested t

[PATCH] Rework VXWORKS_LINK_SPEC for shared objects support

This change reworks the VXWORKS_LINK_SPEC a bit to fix a couple of issues observed while working on improving the support for shared objects, in particular differences between vxworks 7 and earlier regarding the need to pass specific linker options. It also introduces an internal VXWORKS_LINK_OS_

[PATCH] Remove ppc*-vxworks7* inadequate libgcc Makefile fragments

This change removes a couple of entries from the tmake_file list for ppc-vxworks7*, in particular: t-linux, which assigns .so version numbers to a set of symbols, some of which aren't included the VxWorks libgcc on powerpc (from ibm-ldouble.c, in particular). t-slibgcc-libgcc, which yields a kin

[PATCH] Remove special case for arm-vxworks on the use of vxcrtstuff

The special case for arm on the use of vxcrtstuff is not needed any more after the previous patches in this area. Cheers, Olivier 2021-12-13 Olivier Hainque libgcc/ * config.host (*vxworks*): Remove special case for arm on the use of vxcrtstuff. 0007-Remove-special-cas

[PATCH] Tigthen libc_internal and vxcrtstuff for VxWorks shared objects

This change tightens and documents the use of libc_internal, then strengthens the VxWorks crtstuff objects for the support of shared libraries. In particular: - Define __dso_handle, which libstdc++.so requires, - Provide _init and _fini functions to run through the init/fini arrays for shared

[PATCH] VxWorks config fixes for shared objects

This strengthens the VxWorks configuration files on the support of shared objects, which encompasses a VxWorks specific "non-static" mode for RTPs (in addition to -static and -shared). I had good builds and test results with this in-house for gcc-11 based toolchains for a variety of targets, with

[PATCH] Preserve cpu specific CRTSTUFF_T_CFLAGS on powerpc-vxworks7

The unconditional assignment performed in t-vxworks to handle include flags currently overrides what specific cpu ports had for the regular (!vxworks) crtstuff objects. This was not done on purpose and the proposed change adjusts the configuration bits to apply the vxworks specific flags on top o

[PATCH] Include yvals.h for VxWorks < 7 RTPs as well

Hello, For -mrtp on VxWorks 6.9, at least inttypes.h ends up #including system headers checking that _BITS_BYTES is 8, which the system yvals.h defines. We do pre-include _yvals.h ahead of inttypes.h for this kind of purpose, but it currently assumes that only VxWorks >= 7 provides yvals.h. This

Re: [PATCH] #undef isblank before def or decl in libstdc++ headers

> On 11 Dec 2021, at 18:09, Jonathan Wakely wrote: > > * config/vxworks.h (VXWORKS_OS_CPP_BUILTINS): Define > _C99 for C++. > > Makes sense? > > Yes. I can't approve patches outside libstdc++, but that looks definitely > correct for C++11 and later, because C++11 incorporate

Re: [PATCH] #undef isblank before def or decl in libstdc++ headers

(Thanks for your feedback Jonathan) > On 10 Dec 2021, at 19:24, Jonathan Wakely wrote: > > I'm curious why _GLIBCXX_USE_C99_CTYPE_TR1 is not defined if VxWorks > has isblank, the configure check is: Oh, hmm, very good point. The reason was that the definition of isblank is conditioned on _C99/_

[PATCH] Leverage sysroot for VxWorks

Hello, The build of a VxWorks toolchain relies a lot on system headers and VxWorks has a few very specific features that require special processing. For example, different sets of headers for the kernel vs the rtp modes, which the compiler knows about by way of -mrtp on the command line. If we ma

[PATCH] #undef isblank before def or decl in libstdc++ headers

Hello, The attached patch helps fix a build failure of libstdc++ on some variants of VxWorks where the system headers expose an "isblank" macro. I understand this kind of thing normally is handled through fixincludes, however fixincludes on VxWorks is very tricky and we already have libstdc++-

Re: [PATCH] Define _C99 in libstdc++ vxworks/os_defines.h

> On 10 Dec 2021, at 16:42, Jonathan Wakely wrote: > > > OK to commit then, thanks. > > The comment is a bit misleading though: > > +// libstdc++ relies on C99 features for virtually all versions of C++, > +// up to at least C++98. > +#undef _C99 > +#define _C99 1 > > The "up to" seems bac

Re: [PATCH 2/4] libgcc: vxcrtstuff.c: remove ctor/dtor declarations

> On 1 Nov 2021, at 10:34, Rasmus Villemoes wrote: > > These declarations prevent the priority given in the > constructor/destructor attributes from taking effect, thus emitting > the function pointers in the ordinary (lowest-priority) > .init_array/.fini_array sections. > > libgcc/ > *

Re: [PATCH 3/4] libgcc: vxcrtstuff.c: make ctor/dtor functions static

> On 10 Dec 2021, at 16:07, Rasmus Villemoes wrote: > >> >> This is OK, can you please commit? > > Well, yes, but it depends contextually (but not functionally) on patch > 2/4. Should I redo this one, or can I get you to take a look at 2/4 first? > > You've already ok'ed 1/4 and 4/4 (which

[PATCH] Define _C99 in libstdc++ vxworks/os_defines.h

Hello, The attached patch for libstdc++ / VxWorks helps building the library for old versions of the OS, as witnessed with VxWorks 6.9 in particular. It explicitly requests C99 features from old system headers, on which libstc++ relies since at least c++98. The specific issue that exposed this wa

Re: [PATCH 3/4] libgcc: vxcrtstuff.c: make ctor/dtor functions static

Hi again Rasmus, > On 1 Nov 2021, at 10:34, Rasmus Villemoes wrote: > > When the translation unit itself creates pointers to the ctors/dtors > in a specific section handled by the linker (whether .init_array or > .ctors.*), there's no reason for the functions to have external > linkage. That end

[PATCH] Fix inaccuracies in VxWorks LINK_SPEC

Hello, The attached patch fixes a couple of incorrect things in the VxWorks default LINK_SPEC, exposed during our work on the support for building shared libraries. -v needs to generate a -V not -v, as most/all other ports do, to output the available emulations. The latter causes collect2 to out

[PATCH] Remove assignment to STMP_FIXINC from t-vxworks

Hello, The attached patch just removes the assignment to STMP_FIXINC from t-vxworks. This aligns VxWorks with what the vast majority of targets do and the value set was redundant with the default Makefile setting anyway, possibly confusing on a target when the management of fixincludes is pretty

Re: [PATCH] replace t-ppccomm for libgcc powerpc*-vxworks*

> On 10 Dec 2021, at 14:29, Rasmus Villemoes wrote: > > On 10/12/2021 14.08, Olivier Hainque wrote: >> Hello, >> >> The attached patch is the one originally sent by Rasmus at >> >> https://gcc.gnu.org/pipermail/gcc-patches/2018-October/508026.html. (*) >> >> and which escaped the radar at

[PATCH] replace t-ppccomm for libgcc powerpc*-vxworks*

Hello, The attached patch is the one originally sent by Rasmus at https://gcc.gnu.org/pipermail/gcc-patches/2018-October/508026.html. (*) and which escaped the radar at the time. The change looked good and turned out helpful in the context of work on the support of shared library for VxWorks.

[PATCH] Fix path to t-ppc64-fp for ppc*-vxworks7* libgcc tmake_file

Hello, This fixes a basic mistake in the relative path used to reference a rs6000 specific Makefile fragment in the libgcc configuration bits for powerpc*-vxworks7*. This addresses build failures from link errors observed during preliminary work on the support for shared libraries on powerpc64.

Leverage VX_CPU_PREFIX in aarch64-vxworks.h

Hello, The attached patch tightens the CPU macro definitions issued for VxWorks system headers on aarch64 to incorporate the common VX_CPU_PREFIX facility, as the powperpc port does. The net effect for current configurations is the addition of an actual "_VX_" prefix to the references to archi

Re: [PATCH] gcc: vxworks: fix providing stdint.h header

> On 6 Dec 2021, at 04:05, Alexandre Oliva wrote: > > On Dec 3, 2021, Olivier Hainque wrote: > >> Alex, how does that look to you? > > LGTM, thanks, Great, thanks. I'll commit shortly and will soon start proposing the batch of other changes I have been mentioning. Some of this might not

Re: [PATCH] gcc: vxworks: fix providing stdint.h header

> On 3 Dec 2021, at 11:27, Rasmus Villemoes wrote: > > Reverting my fix and applying this on top of my gcc-11.2 based branch > seems to work. I haven't used the compiler for building or running any > modules (don't have the hardware handy), but I've done an 'objdump -d' > comparison on all the

Re: [PATCH] gcc: vxworks: fix providing stdint.h header

Hi Rasmus, Some new on this. > On 20 Nov 2021, at 09:07, Olivier Hainque wrote: > > I'll check how our build sequence proceeds. Turns out our build succeeds thanks to the presence of a vendor version of stdint.h in the VxWorks6/7 header dirs and we're lucky that the need to pre-include yvals.h

Re: [PATCH v2] fix spelling of -linker-output-auto-nolto-rel

Hi Rasmus, The VxWorks part is ok. The plugin part looks good to me as well, now in line with Richard's comment, but is not for me to approve. Thanks, and Thanks Richard for the original review. Cheers, Olivier > On 2 Dec 2021, at 08:22, Rasmus Villemoes wrote: > > The transposition nolto ->

Re: [PATCH 3/4] libgcc: vxcrtstuff.c: make ctor/dtor functions static

Hi Rasmus, We had something close but slight different for the support of shared libraries (for which I'm preparing the patches). I think your version should work as well but we have quite a few configurations and the devil is in the details so I'm testing the effects in a few cases before approvi

Re: [PATCH 4/4] libgcc: vxcrtstuff.c: add a few undefs

Hi Rasmus, > On 1 Nov 2021, at 10:34, Rasmus Villemoes wrote: > > libgcc/ > * config/vxcrtstuff.c: Undefine caddr_t, pid_t, rlim_t, > ssize_t and vfork after including auto-host.h. Ok, thanks;

Re: [PATCH 1/4] libgcc: remove crt{begin,end}.o from powerpc-wrs-vxworks target

Hi Rasmus, (making progress but not quite there on the stdint business) > On 1 Nov 2021, at 10:34, Rasmus Villemoes wrote: > > Since commit 78e49fb1bc (Introduce vxworks specific crtstuff support), > the generic crtbegin.o/crtend.o have been unnecessary to build. So > remove them from extra_par

Re: [PATCH] gcc: vxworks: fix providing stdint.h header

> On 19 Nov 2021, at 21:47, Rasmus Villemoes wrote: >> >> Your error triggers on O2ggnu++0x.gch and we configure with >> --disable-libstdcxx-pch. >> > > ISTR I already tried that, but just for good measure I did it again, and > no luck: > > /bin/sh ../libtool --tag CXX --tag disable-shared

Re: [PATCH] gcc: vxworks: fix providing stdint.h header

Hi Rasmus, > On 12 Nov 2021, at 17:35, Olivier Hainque wrote: > We have had to use for stdbool a similar trick as we had > for stdint (need to preinclude yyvals.h), which we will need to > propagate somehow. I'm not yet sure how to reconcile that with > your observations. >> In file included fr

Re: [PATCH] gcc: vxworks: fix providing stdint.h header

Hi Rasmus, We have had to use for stdbool a similar trick as we had for stdint (need to preinclude yyvals.h), which we will need to propagate somehow. I'm not yet sure how to reconcile that with your observations. Olivier > On 12 Nov 2021, at 11:15, Rasmus Villemoes wrote: > > Commit bbbc05957

Re: [i386] Fix couple of issues in large PIC model on x86-64/VxWorks

> On 8 Nov 2021, at 09:27, Eric Botcazou wrote: > >> LGTM for the generic part, no idea for VxWorks. > > Thanks. The VxWorks-specific hunk is needed to make GCC compatible with the > system compiler on this architecture (LLVM) and I have CCed Olivier. Good for me, thanks Eric!

Re: [PATCH] libstdc++: only define _GLIBCXX_HAVE_TLS for VxWorks >= 6.6

> On 8 Nov 2021, at 10:56, Rasmus Villemoes wrote: > > According to > https://gcc.gnu.org/legacy-ml/gcc-patches/2008-03/msg01698.html, the > TLS support, including the __tls_lookup function, was added to VxWorks > in 6.6. > > It certainly doesn't exist on our VxWorks 5 platform, but the fallb

Re: [PATCH] gcc: vx-common.h: fix test for VxWorks7

> On 5 Nov 2021, at 15:12, Rasmus Villemoes wrote: > >> Yes, I think so. The builds you do used to work before >> the change that introduced the ifdef, > > Well, apart from all the other fixups, some of which are not > upstreamable, that I also need to apply :) Sure. My comment was only mea

Re: [PATCH] gcc: vx-common.h: fix test for VxWorks7

> On 5 Nov 2021, at 09:48, Rasmus Villemoes wrote: > Applied to master and pushed - hope I've done it right. AFAICS, yes. > How about the gcc-11 branch, can it be applied there as well, Yes, I think so. The builds you do used to work before the change that introduced the ifdef, IIUC, and the

Re: [PATCH] gcc: vx-common.h: fix test for VxWorks7

Hi Rasmus, > On 3 Nov 2021, at 14:18, Rasmus Villemoes wrote: > > The macro TARGET_VXWORKS7 is always defined (see vxworks-dummy.h). > Thus we need to test its value, not its definedness. > > Fixes aca124df (define NO_DOT_IN_LABEL only in vxworks6). > > gcc/ChangeLog: > > * config/vx-co

Fix size of static array in gcc.dg/vect/vect-simd-20.c

Hello, This fixes the definition of the "p" static array in gcc.dg/vect/vect-simd-20.c to accommodate the number of strides performed by foo() for s == 78, which will be 129 and not 128 since 1 / 78 > 128. This fixes a failure of the test we first observed in-house on a x86_64-elf run, where