Re: [PATCH v2] [libstdc++] add _GLIBCXX_CLANG to workaround predefined __clang__

>>> Here's what I've retested on x86_64-linux-gnu and, slightly adjusted for >>> gcc-13, on arm-vx7r2. Ok to install? >> >> OK Thanks Jonathan! >> If there's any chance of getting the vxworks system headers fixed to >> work with GCC properly, that would be nice. That would be nice for sure.

Re: [PATCH] [libstdc++] add _GLIBCXX_CLANG to workaround predefined __clang__

> On 31 May 2024, at 17:52, Alexandre Oliva wrote: >> Does the vxworks toolchain need to support the PSTL headers? > > Maybe we can do without them. I really don't know. Olivier? I have no indication that we can not-support these. We are seeing many cases of C++/Ada combined codebases in

Re: [PATCH] [vxworks] avoid mangling __STDC_VERSION_LIMITS_H__

> On 16 Apr 2024, at 05:27, Alexandre Oliva wrote: > > > The mangling of the macro name that guards limits.h from reinclusion > was mangling a c23-required macro as well. Make the edit pattern > stricter. > > Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-, > aarch64-, x86

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 >>

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: > &

[patch] configury support for VxWorks shared libraries

ccessful sanity check build with mainline for that cpu as well. Will commit to mainline shortly. Cheers, Olivier 2022-10-09 Olivier Hainque gcc/ * config.gcc (*vxworks*): Add t-slibgcc fragment if enable_shared. libgcc/ * config.host (*vxworks*): When ena

[patch] Tighten VXWORKS_LIBGCC_SPEC wrt libgcc_eh

commit shortly. Cheers, Olivier 2022-10-09 Olivier Hainque * config/vxworks (VX_LGCC_EH_SO0, VX_LGCC_EH_SO1): New internal macros. (VXWORKS_LIBGCC_SPEC): Use them and document. 0001-Tigthen-the-addition-of-lgcc_eh-to-vxworks_libgcc_sp.patch Description: Binary data

[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

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 >

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

to commit? Thanks in advance! With Kind Regards, Olivier 2022-09-30 Olivier Hainque gcc/ * ginclude/stddef.h: #undef offsetof before #define. 0003-undef-offsetof-before-defining-it-in-stddef.h.patch Description: Binary data

[PATCH] Introduce DWARF_VERSION_DEFAULT (and redefine for VxWorks)

regression tested for mainline on x86_64-linux. Is this ok to commit? Thanks in advance! Best Regards, Olivier 2022-09-30 Olivier Hainque gcc/ * defaults.h (DWARF_DEFAULT_VERSION): Define if not defined already. * common.opt (gdwarf-): Use it. * doc

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

overflow-6.C. Sanity checked with a build + basic testing with a gcc-12 compiler, then a mainline build for arm-vxworks7r2. Cheers Olivier 2021-02-03 Olivier Hainque * config/gthr-vxworks.h: Prevent Wpragma warning for the pragma diagnostics on Wstrict-prototypes. 00

[patch] Refine INITFINI condition for vxworks crtstuff spec

for vxowkrs7r2 on a variety of architectures). Tested further with a gcc-12 build + basic test cycle on both arm and ppc64 vxworks7r2, as well as ppc vxworks 6.9. Will commit to mainline shortly. Cheers, Olivier 2022-09-30 Olivier Hainque gcc/ * config/vxworks.h (VX_CRT

[patch] Adjust LIBGCC2_INCLUDES for VxWorks and augment comment

gcc in the two kinds of configurations. Will commit to mainline shortly. Cheers, Olivier 2022-03-06 Olivier Hainque libgcc/ * config/t-vxworks (LIBGCC2_INCLUDE): Augment comment. Move -I options for gcc/include and gcc/include-fixed at the end and make them -isystem.

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

mainline shortly. Olivier 2022-03-06 Olivier Hainque libgcc/ * config/vxcrtstuff.c: Improve the comment attached to the use of auto-host.h and of __dso_handle. Remove redundant guard on HAVE_INITFINI_ARRAY_SUPPORT within a USE_INITFINI_ARRAY section. 0017-Improve

[patch] Define a GCC_DRIVER_HOST_INITIALIZATION for VxWorks

of build+test cycles on gcc-12 for powerpc64-vxworks7r2 and powerpc-vxworks6.9, and did a sanity checking build of all-gcc for arm-wrs-vxworks7r2. Cheers, Olivier 2022-09-29 Marc Poulhies Olivier Hainque gcc/ * config/vxwkorks/vxwkorks-driver.cc: New. * config

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

and without shared lib support (depending on the CPU). I have performed a couple of build + test checks with gcc-12 for powerpc64, then bootstrapped and regression tested on x86_64-linux. Committing to mainline shortly. Best Regards, Olivier 2022-09-29 Olivier Hainque * configure.ac

[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

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

d. Cheers, Olivier 2022-03-10 Olivier Hainque gcc/ * config/vx-common.h (DWARF2_UNWIND_INFO): #define to 0 when ARM_UNWIND_INFO is set. 0015-Robustify-DWARF_UNWIND_INFO-handling-in-vx-common.h.patch Description: Binary data

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

, Olivier 2022-03-20 Olivier Hainque gcc/ * config/aarch64/t-aarch64-vxworks: Request multilib variants for mcmodel=large. 0004-Add-an-mcmodel-large-multilib-for-aarch64-vxworks.patch Description: Binary data

[patch] Remove TARGET_FLOAT128_ENABLE_TYPE setting for VxWorks

ites with a gcc-12 compiler for ppc64-vx7r2. Committing to mainline. Olivier 2022-04-19 Olivier Hainque * config/vxworks.h (TARGET_FLOAT128_ENABLE_TYPE): Remove resetting to 0. 0002-Remove-TARGET_FLOAT128_ENABLE_TYPE-setting-for-VxWor.patch Description: Binary data

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

s and regtests fine on powerpc64-linux. Is this OK to commit? Thanks in advance! With Kind Regards, Olivier 2022-09-14 Olivier Hainque * config/rs6000/option-defaults.h (OPTION_DEFAULT_SPECS): Have any -mabi, not only -mabi=elfv*, override the --with-

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

) to the OS build. I guess it could > also have been an inline. I experimented with the inline track (patch attached) and we're having good results with it. It builds and test results we get are on par with those we had with the varargs approach. Works better for you? Thanks ag

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

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

t a spot which "works" for either kernel or rtp headers, as those we have for VxWorsk 6.9. This allowed us getting at least a first reasonable batch of libstdc++ test results. 2021-01-10 Olivier Hainque * inclhack.def (vxworks_time_h_syslib): New hack. * tests/base/t

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 &g

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

tests fine on x86_64-linux and allows better control on vxWorks. I'm not yet clear on some of the ramifications there (tigthening the definitions of SUPPORTS_ONE_ONLY and TARGET_SUPPORTS_WEAK yields lots of dg test failures) but that's another story. Ok to commit? Thanks in advance! 2021

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

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

uot; /target)} This helps the use we have of self specs for VxWorks, and was bootstrapped and regression tested on native 64bit linux. Ok to commit ? Thanks in advance, With Kind Regards, Olivier >From 964829ee06ffe1bedcbab6a3b4c92c5d161aaaed Mon Sep 17 00:00:00 2001 From: Olivier Hainque

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=$

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(). &

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 >>

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 defi

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

after this. Also bootstrapped and regression tested ok for x86_64-linux, just in case. Ok to commit? Thanks in advance, With Kind Regards, Olivier 2021-12-16 Olivier Hainque fixincludes/ * inclhack.def (vxworks_next_yvals): New hack. * tests/base/yvals.h: New expected test r

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

we were able to get a successful complete build after this. Also bootstrapped and regression tested ok for x86_64-linux, just in case. Ok to commit? Thanks in advance, With Kind Regards, Olivier 2021-12-16 Olivier Hainque fixincludes/ * inclhack.def (vxworks_math_h_FP_macros): New

[PATCH] Add VxWorks fixincludes hack, open posix API

house. I could still observe related failures with mainline sources without the change and get a complete successful with it (plus a couple of others). Also bootstrapped and regression tested ok for x86_64-linux, just in case. Ok to commit? Thanks in advance, With Kind Regards, Olivier 2021-12

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

th Kind Regards, Olivier 2021-12-16 Olivier Hainque fixincludes/ * inclhack.def (vxworks_posix_mkdir): Refine to expose a varargs interface. * tests/base/sys/stat.h: Update expected results. * fixinc.x: Regenerate. 0001-Adjust-VxWorks-fixincludes-hack-fo

[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 > g

[PATCH] Remove fpic multilib on x86_64-vxworks

our in-house gcc-11 based toolchains, including for x86_64 with support for shared libraries enabled. Cheers, Olivier 2021-12-14 Olivier Hainque * config/i386/t-vxworks: Drop the fPIC multilibs. 0001-Remove-fpic-multilib-on-x86_64-vxworks.patch Description: Binary data

[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

VXWORKS_LINK_OS_SPEC to allow reuse of everything else by the powerpc-vxworks7 specific configuration. Tested as the previous patches in the current series. Best Regards, Olivier 2021-12-07 Doug Rupp Olivier Hainque gcc/ * config/vxworks.h (VXWORKS_LINK_OS_SPEC): New spec

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

tree (for VxWorks 7.2), then sanity checked that a build with mainline sources finishes as expected. Olivier 2021-12-13 Olivier Hainque * config.host (powerpc*-*-vxworks7*): Remove rs6000/t-linux and t-slibgcc-libgcc from tmake_file. 0008-Remove-ppc-vxworks7-inadequate-libgc

[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

[PATCH] Tigthen libc_internal and vxcrtstuff for VxWorks shared objects

for shared libs. The change also adds guards the eh table registration code in vxcrtstuff so the objects can be used for either init/fini or eh tables independently. Tested together with the other patches in the current series. Olivier 2021-12-07 Fred Konrad Olivier Hain

[PATCH] VxWorks config fixes for shared objects

of targets, with both static and dynamic links (modulo other patches for the latter). I checked that a build for vx6.9 passes with mainline sources. Olivier 2020-11-06 Fred Konrad Olivier Hainque gcc/ * config/vx-common.h: Define REAL_LIBGCC_SPEC since the '-non

[PATCH] Preserve cpu specific CRTSTUFF_T_CFLAGS on powerpc-vxworks7

of the cpu ones instead. I had good builds and test results with this in-house for gcc-11 based toolchains for a variety of targets. I checked that a build for vx6.9 passes with mainline sources and verified that the spurious configure test failures are gone. Olivier 2021-12-07 Olivier Hainque

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

y to adjust if need be. Olivier 2021-12-13 Olivier Hainque * config/vxworks/_yvals.h: #include yvals.h also if defined(__RTP__). 0002-Include-yvals.h-for-VxWorks-7-RTPs-as-well.patch Description: Binary data

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

th a few fixincludes adjustments as expected. This touches only VxWorks related items and, all in all, I believe this robustifies the family of ports and helps avoid build failure with mainline sources so remains applicable to the current stage. Olivier --- 2021-12-09 Olivier Hainqu

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

linux. Ok to commit? Thanks in advance, With Kind Regards, Olivier 2021-12-07 Olivier Hainque libstdc++-v3/ * include/bits/locale_facets.h: #undef isblank before providing a definition. * libstdc++-v3/include/bits/localefwd.h: Likewise. 0001-Add-undef-isbl

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

en _C99 is. Ok to commit? Thanks in advance! 2021-12-07 Olivier Hainque libstdc++-v3/ * config/os/vxworks/os_defines.h: #define _C99. Olivier 0001-Define-_C99-in-libstdc-vxworks-os_defines.h.patch Description: Binary data

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

sensitive (more patches coming for that). Tested with build + tests on both Vxworks 6.9 and 7.2. Olivier 2021-12-07 Olivier Hainque * config/t-vxworks: Remove assignment to STMP_FIXINC. 0001-Remove-assignment-to-STMP_FIXINC-from-t-vxworks.patch Description: Binary data

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. (*

[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

e of years now, on variations of VxWorks 7. I'll commit to mainline shortly. Olivier -- 2021-04-09 Olivier Hainque gcc/ * config/aarch64/aarch64-vxworks.h (TARGET_OS_CPP_BUILTINS): Use VX_CPU_PREFIX in CPU definitions. 0001-Leverage-VX_CPU_PREFIX-in-aarch64-

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 mentio

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

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.

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

lf run, where the first call to foo() was clobbering part of a static object we provide to __register_frame_info, causing an abort() from __deregister_frame_info at termination time. Ok to commit? Thanks in advance, With Kind Regards, Olivier 2021-11-02 Olivier Hainque testsuite/

Re: [FYI] zero-call-used-regs attr for ada

> On 15 Sep 2021, at 18:45, Alexandre Oliva wrote: > > On Sep 15, 2021, Alexandre Oliva wrote: > >> Regstrapped on x86_64-linux-gnu. Patch pre-approved by Olivier Hainque. > > Uhh, actually, Olivier had only seen and approved these changes: > >> for g

Re: restore EH on x86-vx7r2

> On 4 May 2021, at 04:45, Alexandre Oliva wrote: > > > x86-vx7r2 needs svr4_dbx_register_map, but the default in i386/i386.h > was dbx_register_map, partially swapping ebp and esp in unwind info. > > i386/vxworks.h had a correct overrider, but it was conditional for > vxworks < 7. This pat

Fix for PR target/99660 - vxworksae/mils build failure from missing VX_CPU_PREFIX

. With Kind Regards, Olivier 2021-03-19 Olivier Hainque gcc/ PR target/99660 * config/config/vxworksae.h (VX_CPU_PREFIX): Define. diff --git a/gcc/config/vxworksae.h b/gcc/config/vxworksae.h index 0f9b55357892..86d1923b718f 100644 --- a/gcc/config/vxworksae.h +++ b/gcc

Re: [patch] gcc.dg/analyzer tests: relax dependency on alloca.h

Hi Alex, > On 14 Jan 2021, at 22:13, Alexandre Oliva wrote: > > Hello, Olivier, > > On Dec 18, 2020, Olivier Hainque wrote: > >> Ping for https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557548.html >> (copied below for convenience), please ? > > I

Re: Add missing vxworks filters to lib/target-supports.exp functions

inux-gnu, and tested with -x-arm-wrs-vxworks7r2. >> Ok to install? >> >> >> from Olivier Hainque >> for gcc/testsuite/ChangeLog >> >> * lib/target-supports.exp (check_weak_available, >> check_fork_available, check_effective_target_lto,

Re: robustify vxworks glimits.h overriding

> On 5 Jan 2021, at 08:51, Alexandre Oliva wrote: > > > The glimits.h overriding used in gcc/config/t-vxworks was fragile: the > intermediate file would already be there in a rebuild, and so the > adjustments would not be made, so the generated limits.h would miss > them, causing limits-width

  1   2   3   4   5   6   >