aboutsummaryrefslogtreecommitdiff
path: root/libgcc
AgeCommit message (Collapse)AuthorFilesLines
2021-01-04Update copyright years.Jakub Jelinek1058-1059/+1059
2021-01-04Update Copyright in ChangeLog filesJakub Jelinek2-2/+2
Do this separately from all other Copyright updates, as ChangeLog files can be modified only separately.
2020-12-21Daily bump.GCC Administrator1-0/+7
2020-12-20gcc: xtensa: implement bswapsi2, bswapdi2 and helpersMax Filippov2-0/+40
2020-12-20 Max Filippov <jcmvbkbc@gmail.com> gcc/ * config/xtensa/xtensa.md (bswapsi2, bswapdi2): New patterns. gcc/testsuite/ * gcc.target/xtensa/bswap.c: New test. libgcc/ * config/xtensa/lib1funcs.S (__bswapsi2, __bswapdi2): New functions. * config/xtensa/t-xtensa (LIB1ASMFUNCS): Add _bswapsi2 and _bswapdi2.
2020-12-09Daily bump.GCC Administrator1-0/+5
2020-12-08libgcc: block signals when releasing split-stack memoryIan Lance Taylor1-0/+14
* generic-morestack-thread.c (free_segments): Block signals during thread exit.
2020-12-04Daily bump.GCC Administrator1-0/+18
2020-12-03PowerPC: PR libgcc/97543 and libgcc/97643, fix long double issuesMichael Meissner1-0/+22
If you use a compiler with long double defaulting to 64-bit instead of 128-bit with IBM extended double, you get linker warnings about mis-matches in the gnu attributes for long double (PR libgcc/97543). Even if the compiler is configured to have long double be 64 bit as the default with the configuration option '--without-long-double-128' you get the warnings. You also get the same issues if you use a compiler with long double defaulting to IEEE 128-bit instead of IBM extended double (PR libgcc/97643). The issue is the way libgcc.a/libgcc.so is built. Right now when building libgcc under Linux, the long double size is set to 128-bits when building libgcc. However, the gnu attributes are set, leading to the warnings. One feature of the current GNU attribute implementation is if you have a shared library (such as libgcc_s.so), the GNU attributes for the shared library is an inclusive OR of all of the objects within the library. This means if any object file that uses the -mlong-double-128 option and uses long double, the GNU attributes for the library will indicate that it uses 128-bit IBM long doubles. If you have a static library, you will get the warning only if you actually reference an object file with the attribute set. This patch does two things: 1) All of the object files that support IBM 128-bit long doubles explicitly set the ABI to IBM extended double. 2) I turned off GNU attributes for building the shared library or for building the IBM 128-bit long double support. libgcc/ 2020-12-03 Michael Meissner <meissner@linux.ibm.com> PR libgcc/97543 PR libgcc/97643 * config/rs6000/t-linux (IBM128_STATIC_OBJS): New make variable. (IBM128_SHARED_OBJS): New make variable. (IBM128_OBJS): New make variable. Set all objects to use the explicit IBM format, and disable gnu attributes. (IBM128_CFLAGS): New make variable. (gcc_s_compile): Add -mno-gnu-attribute to all shared library modules.
2020-12-02introduce overridable clear_cache emitterAlexandre Oliva3-37/+0
This patch introduces maybe_emit_call_builtin___clear_cache for the builtin expander machinery and the trampoline initializers to use to clear the instruction cache, removing a source of inconsistencies and subtle errors in low-level machinery. I've adjusted all trampoline_init implementations that used to issue explicit calls to __clear_cache or similar to use this new primitive. Specifically on vxworks targets, we needed to drop the __clear_cache symbol in libgcc, for reasons related with linking that I didn't need to understand, and we wanted to call cacheTextUpdate directly, despite the different calling conventions: the second argument is a length rather than the end address. So I introduced a target hook to enable target OS-level overriding of builtin __clear_cache call emission, retaining nearly (*) the same logic to govern the decision on whether to emit a call (or nothing, or a machine-dependent insn) but enabling a call to a target system-defined function with different calling conventions to be issued, without having to modify .md files of the various architectures supported by the target system to introduce or modify clear_cache insns. (*) I write "nearly" mainly because, when not optimizing, we'd issue a call regardless, but since the call may now be overridden, I added it to the set of builtins that are not directly turned into calls when not optimizing, following the normal expansion path instead. It wouldn't be hard to skip the emission of cache-clearing insns when not optimizing, but it didn't seem very important, especially for the new uses from trampoline init. Another difference that might be relevant is that now we expand the begin and end arguments unconditionally. This might make a difference if they have side effects. That's prettty much impossible at expand time, but I thought I'd mention it. I have NOT modified targets that did not issue cache-clearing calls in trampoline init to use the new clear_cache-calling infrastructure even if it would expand to nothing. I have considered doing so, to have __builtin___clear_cache and trampoline init call cacheTextUpdate on all vxworks targets, but decided not to, since on targets that don't do any cache clearing, cacheTextUpdate ought to be a no-op, even though rs6000 seems to use icbi and dcbf instructions in the function called to initialize a trampoline, but AFAICT not in the __clear_cache builtin. Hopefully target maintainers will have a look and take advantage of this new piece of infrastructure to remove such (apparent?) inconsistencies. Not rs6000 and other that call asm-coded trampoline setup instructions, for sure, but they might wish to introduce a CLEAR_INSN_CACHE macro or a clear_cache expander if they don't have one. for gcc/ChangeLog * builtins.c (default_emit_call_builtin___clear_cache): New. (maybe_emit_call_builtin___clear_cache): New. (expand_builtin___clear_cache): Split into the above. (expand_builtin): Do not issue clear_cache call any more. * builtins.h (maybe_emit_call_builtin___clear_cache): Declare. * config/aarch64/aarch64.c (aarch64_trampoline_init): Use maybe_emit_call_builtin___clear_cache. * config/arc/arc.c (arc_trampoline_init): Likewise. * config/arm/arm.c (arm_trampoline_init): Likewise. * config/c6x/c6x.c (c6x_initialize_trampoline): Likewise. * config/csky/csky.c (csky_trampoline_init): Likewise. * config/m68k/linux.h (FInALIZE_TRAMPOLINE): Likewise. * config/tilegx/tilegx.c (tilegx_trampoline_init): Likewise. * config/tilepro/tilepro.c (tilepro_trampoline_init): Ditto. * config/vxworks.c: Include rtl.h, memmodel.h, and optabs.h. (vxworks_emit_call_builtin___clear_cache): New. * config/vxworks.h (CLEAR_INSN_CACHE): Drop. (TARGET_EMIT_CALL_BUILTIN___CLEAR_CACHE): Define. * target.def (trampoline_init): In the documentation, refer to maybe_emit_call_builtin___clear_cache. (emit_call_builtin___clear_cache): New. * doc/tm.texi.in: Add new hook point. (CLEAR_CACHE_INSN): Remove duplicate 'both'. * doc/tm.texi: Rebuilt. * targhooks.h (default_meit_call_builtin___clear_cache): Declare. * tree.h (BUILTIN_ASM_NAME_PTR): New. for libgcc/ChangeLog * config/t-vxworks (LIB2ADD): Drop. * config/t-vxworks7 (LIB2ADD): Likewise. * config/vxcache.c: Remove.
2020-12-01Daily bump.GCC Administrator1-0/+4
2020-11-29fixed _bswapsi2 functionStefan Kanthak1-4/+4
libgcc * libgcc2.c (bswapsi2): Make constants unsigned.
2020-11-26Daily bump.GCC Administrator1-0/+6
2020-11-25Improve abs with overflow implementationsStefan Kanthak1-30/+12
libgcc/ * libgcc2.c (absvSI2): Simplify/improve implementation by using builtin_add_overflow. (absvsi2, absvDI2): Likewise.
2020-11-21Daily bump.GCC Administrator1-0/+5
2020-11-20NetBSD/libgcc: Check for TARGET_DL_ITERATE_PHDR in the unwinderMaciej W. Rozycki1-0/+1
Disable USE_PT_GNU_EH_FRAME frame unwinder support for old OS versions, fixing compilation errors: .../libgcc/unwind-dw2-fde-dip.c:75:21: error: unknown type name 'Elf_Phdr' 75 | # define ElfW(type) Elf_##type | ^~~~ .../libgcc/unwind-dw2-fde-dip.c:132:9: note: in expansion of macro 'ElfW' 132 | const ElfW(Phdr) *p_eh_frame_hdr; | ^~~~ .../libgcc/unwind-dw2-fde-dip.c:75:21: error: unknown type name 'Elf_Phdr' 75 | # define ElfW(type) Elf_##type | ^~~~ .../libgcc/unwind-dw2-fde-dip.c:133:9: note: in expansion of macro 'ElfW' 133 | const ElfW(Phdr) *p_dynamic; | ^~~~ .../libgcc/unwind-dw2-fde-dip.c:165:37: warning: 'struct dl_phdr_info' declared inside parameter list will not be visible outside of this definition or declaration 165 | _Unwind_IteratePhdrCallback (struct dl_phdr_info *info, size_t size, void *ptr) | ^~~~~~~~~~~~ [...] and producing a working cross-compiler at least with VAX/NetBSD 1.6.2. libgcc/ * unwind-dw2-fde-dip.c [__OpenBSD__ || __NetBSD__] (USE_PT_GNU_EH_FRAME): Do not define if !TARGET_DL_ITERATE_PHDR.
2020-11-19Daily bump.GCC Administrator1-0/+8
2020-11-18MSP430: Add 64-bit hardware multiply supportJozef Lawrynowicz3-4/+130
Hardware multipliers that support widening 32-bit multiplication can be used to perform a 64-bit * 64-bit multiplication more efficiently than a software implementation. The following equation is used to perform 64-bit multiplication for devices with "32bit" or "f5series" hardware multiply versions: 64bit_result = (low32_op0 * lop32_op1) + ((low32_op0 * high32_op1) << 32) + ((high32_op0 * low32_op1) << 32) libgcc/ChangeLog: * config/msp430/lib2hw_mul.S (mult64_hw): New. (if MUL_32): Use mult64_hw for __muldi3. (if MUL_F5): Use mult64_hw for __muldi3. * config/msp430/lib2mul.c (__muldi3): New. * config/msp430/t-msp430 (LIB2FUNCS_EXCLUDE): Define.
2020-11-17Daily bump.GCC Administrator1-0/+6
2020-11-17[RS6000] Use LIB2_SIDITI_CONV_FUNCS in place of ppc64-fp.cAlan Modra2-239/+1
This patch retires ppc64-fp.c in favour of using "LIB2_SIDITI_CONV_FUNCS = yes", which is a lot better solution than having a copy of selected libgcc2.c functions. * config/rs6000/t-ppc64-fp (LIB2ADD): Delete. (LIB2_SIDITI_CONV_FUNCS): Define. * config/rs6000/ppc64-fp.c: Delete file.
2020-11-16Daily bump.GCC Administrator1-0/+5
2020-11-15MSP430: Fix inconsistent naming of hwmult libfuncsJozef Lawrynowicz1-6/+6
The naming scheme used by GCC to reference MSP430 hardware multiply library functions is inconsistent. Sometimes the "GCC" names (e.g. mulsi2) are used, other times the "MSPABI" names (e.g. __mspabi_mpyl) are used. Also, sometimes an identifier for the hardware multiply support is appended to the GCC name, when the functions are defined, but this is not required. This patch fixes those issues, so the names used to refer to the hardware multiply library functions follow a consistent pattern. gcc/ChangeLog: * config/msp430/msp430.c (msp430_output_labelref): Don't process mspabi hwmult library function names into GCC-style names. libgcc/ChangeLog: * config/msp430/lib2hw_mul.S: Omit _hw* suffix from GCC names for hwmult library functions. gcc/testsuite/ChangeLog: * gcc.target/msp430/rtx-cost-Os-f5series.c: Adjust test to use new hwmult library function name.
2020-11-11Daily bump.GCC Administrator1-0/+14
2020-11-10Fix minor whitespace issuesJeff Law1-11/+11
libgcc/ * libgcc2.c: Fix whitespace issues in most recent change.
2020-11-10Improve generated code for various libgcc2.c routinesStefan Kanthak2-54/+30
libgcc/ * libgcc2.c (__addvSI3): Use overflow builtins. (__addvsi3, __addvDI3 ,__subvSI3, __subvsi3): Likewise. (__subvDI3 __mulvSI3, __mulvsi3, __negvSI2): Likewise. (__negvsi2, __negvDI2): Likewise. (__cmpdi2, __ucmpdi2): Adjust implementation to improve generated code. * libgcc2.h (__ucmpdi2): Adjust prototype.
2020-11-04Daily bump.GCC Administrator1-0/+11
2020-11-03Sync the aarch64-vx7r2 libgcc config with that of LinuxPat Bernardi1-0/+1
This adds ${cpu_type}/t-lse and t-slibgcc-libgcc to the tmake_file list for aarch64-vxworks7* configurations, as the Linux port does. t-lse is needed by all triplets now anyway and the standard setting for slibgcc makes sense as we are working on reintroducing PIC support for RTPs on various targets. The VxWorks7 system environments are leaning towards more and more similarilties with Linux in general, so the closer configurations the better. 2020-11-02 Pat Bernardi <bernardi@adacore.com> libgcc/ * config.host (aarch64-vxworks7*, tmake_file): Add ${cpu_type}/t-lse and t-slibgcc-libgcc. Co-authored-by: Olivier Hainque <hainque@adacore.com>
2020-11-03libgcc: Expose the instruction pointer and stack pointer in SEH ↵Martin Storsjö1-0/+5
_Unwind_Backtrace Previously, the SEH version of _Unwind_Backtrace did unwind the stack and call the provided callback function as intended, but there was little the caller could do within the callback to actually get any info about that particular level in the unwind. Set the ra and cfa pointers, which are used by _Unwind_GetIP and _Unwind_GetCFA, to allow using these functions from the callacb to inspect the state at each stack frame. 2020-09-08 Martin Storsjö <martin@martin.st> libgcc/ * unwind-seh.c (_Unwind_Backtrace): Set the ra and cfa pointers before calling the callback.
2020-11-02Daily bump.GCC Administrator1-0/+7
2020-10-30Introduce support for vxworks7r2 on x86 and x86_64Olivier Hainque1-1/+1
This change extends the VxWorks support on intel CPUs to VxWorks7r2 for x86_64 as well as x86, with a "mcmodel=large" additional multilib for the 64bit configuration. The support for fPIC is not functional yet for this model, so we just don't add the corresponding multilib. We extend the range of CPU families handled by TARGET_OS_CPP_BUILTINS, accounting for the fact that archs older than PENTIUM4 are not supported (any more) by VxWorks 7. As we did for powerpc, we leverage VX_CPU_PREFIX to emit different forms of definitions for different families of VxWorks as the system headers's expectations has evolved between Vx 5, 6 and 7. 2020-10-27 Olivier Hainque <hainque@adacore.com> gcc/ * config.gcc: Adjust the ix86/x86_64-wrs-vxworks filters to apply to VxWorks 7 as well. * config/i386/t-vxworks (MULTILIB_OPTIONS, MULTILIB_DIRNAMES): Remove the fPIC multilib and add one for the large code model on x86_64. * config/i386/vxworks.h: Separate sections for TARGET_VXWORKS7, other variants and common bits. (TARGET_OS_CPP_BUILTINS): Augment to support a range of CPU families. Leverage VX_CPU_PREFIX. (CC1_SPEC): Add definition. (STACK_CHECK_PROTECT): Use conditional expression instead of heavier to read conditioned macro definitions. libgcc/ * config.host: Adjust the ix86/x86_64-wrs-vxworks filters to apply to VxWorks 7 as well. Co-authored-by: Douglas Rupp <rupp@adacore.com> Co-authored-by: Pat Bernardi <bernardi@adacore.com>
2020-10-30Daily bump.GCC Administrator1-0/+11
2020-10-29Fix the logic conditioning VX_ENTER/LEAVE_TLS_DTOROlivier Hainque1-1/+1
Fix a basic #if/#ifdef confusion which leads to improper choices in some configurations. 2020-10-28 Olivier Hainque <hainque@adacore.com> libgcc/ * config/gthr-vxworks-tls.c: Fix preprocessor logic controlling the definition of VX_ENTER_TLS_DTOR and VX_LEAVE_TLS_DTOR based on a version major check.
2020-10-29Fix conditional inclusion guard in gthr-vxworks-thread.cOlivier Hainque1-1/+1
This fixes the name of the macro used to condition the inclusion of an actual implementation of some of the gthread support services for VxWorks, to agree with the side defining that macro based on tests against the targetted VxWorks version major. 2020-10-28 Olivier Hainque <hainque@adacore.com> libgcc/ * config/gthr-vxworks-thread.c: Fix name of macro used to condition the inclusion of an actual implementation.
2020-10-28Daily bump.GCC Administrator1-0/+6
2020-10-27gcov-profile: use static pool for TOPN firstMartin Liska1-18/+6
gcc/ChangeLog: PR gcov-profile/97461 * gcov-io.h (GCOV_PREALLOCATED_KVP): Pre-allocate 64 static counters. libgcc/ChangeLog: PR gcov-profile/97461 * libgcov.h (gcov_counter_add): Use first static counters as it should help to have malloc wrappers set up. gcc/testsuite/ChangeLog: PR gcov-profile/97461 * gcc.dg/tree-prof/pr97461.c: New test.
2020-10-24Daily bump.GCC Administrator2-0/+11
2020-10-23Fix overzealous gthread support inhibition for vxworksRasmus Villemoes2-2/+4
The tests for macros possibly defined in gthr.h needs to be performed after the corresponding #include. This was tested together with the previous updates to gthr-vxworks-thread.c and gthr-vxworks-cond.c and was meant to be squashed with them. 2010-10-23 Rasmus Villemoes <rv@rasmusvillemoes.dk> libgcc/ * config/gthr-vxworks-thread.c: #include gthr.h before testing the guard defined there. * config/gthr-vxworks-cond.c: Likewise.
2020-10-23stor-layout: Reject forming arrays with elt sizes not divisible by elt ↵Jakub Jelinek1-1/+1
alignment [PR97164] As mentioned in the PR, since 2005 we reject if array elements are smaller than their alignment (i.e. overaligned elements), because such arrays don't make much sense, only their first element is guaranteed to be aligned as user requested, but the next element can't be. The following testcases show something we've been silent about but is equally bad, the 2005 case is just the most common special case of that the array element size is not divisible by the alignment. In those arrays too only the first element is guaranteed to be properly aligned and the second one can't be. This patch rejects those cases too, but keeps the existing wording for the old common case. Unfortunately, the patch breaks bootstrap, because libbid uses this mess (forms arrays with 24 byte long elements with 16 byte element alignment). I don't really see justification for that, so I've decreased the alignment to 8 bytes instead. 2020-10-23 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/97164 gcc/ * stor-layout.c (layout_type): Also reject arrays where element size is constant, but not a multiple of element alignment. gcc/testsuite/ * c-c++-common/pr97164.c: New test. * gcc.c-torture/execute/pr36093.c: Move ... * gcc.dg/pr36093.c: ... here. Add dg-do compile and dg-error directives. * gcc.c-torture/execute/pr43783.c: Move ... * gcc.dg/pr43783.c: ... here. Add dg-do compile, dg-options and dg-error directives. libgcc/config/libbid/ * bid_functions.h (UINT192): Decrease alignment to 8 bytes.
2020-10-22Daily bump.GCC Administrator1-0/+8
2020-10-21Introduce vxworks7r2 support for ppc and ppc64Douglas Rupp3-4/+21
This change introduces support for the most recent versions of VxWorks on PowerPC targets, for both 32 and 64 bit thanks to a bi-arch setup. The system compilers are essentially configured as Linux toolchains with only a few specificities and we replicate that model here. The most visible specificities are the use of secureplt by default, the pre-definition of some macros that the system headers still rely on (_VX_CPU and _VX_CPU_FAMILY, for example), and of course some variations related to the so VxWorks typical kernel vs RTP mode distinction. In addition to the introduction of config.gcc and libgcc configuration chunks, much inspired by the linux ones, the change - Reworks rs6000/vxworks.h file to feature bits common to the Vx6 and Vx7 port then a separate section for each, where the Vx7 part is very short as we rely on the Linux definitions for most things. - Adjusts the CPU macro predefinitions in CPP_SPEC to resort to "_VX_CPU" instead of "CPU" for Vx7, to better match the more recent system headers expectations, - Adds a cpu definition case for e6500. - Changes to the use SUB3TARGET_OVERRIDE_OPTIONS instead of SUBSUBTARGET_OVERRIDE_OPTIONS for specifics, so we don't override the Linux's version of the latter for vx7. 2020-10-20 Douglas Rupp <rupp@adacore.com> gcc/ * config.gcc (powerpc*-wrs-vxworks7r*): New case. * config/rs6000/vxworks.h: Rework to handle VxWorks7. Refactor as common bits + vx6 vs vx7 ones. For the latter, rely essentially on the Linux configuration and adjust CPU to _VX_CPU in CPP_SPEC. Add a case for e6500. Use SUB3TARGET_OVERRIDE_OPTIONS for specifics to preserve the Linux SUBSUBTARGET_OVERRIDE_OPTIONS for vx7. libgcc/ * config.host (powerpc*-wrs-vxworks7*): New case. * configure.ac: Handle powerpc*-*-vxworks7* as powerpc*-*-linux* for ppc-fp_type. * configure: Regenerate. Co-authored-by: Olivier Hainque <hainque@adacore.com>
2020-10-17Daily bump.GCC Administrator1-0/+33
2020-10-16Inhibit support for C++0x threads on VxWorks < 6Rasmus Villemoes2-2/+6
As for condition variables, the C++0x threads support relies on VxWorks entry points not available in VxWorks versions prior to 6. We just expose absence of support for C++0x threads on such systems. 2020-10-15 Rasmus Villemoes <rv@rasmusvillemoes.dk> libgcc/ * config/gthr-vxworks.h: Condition the ___GTHREADS_CXX0X section on VxWorks >= 6. * config/gthr-vxworks-thread.c: Condition the entire implementation on __GTHREAD_CXX0X.
2020-10-16Inhibit support for gthread condvars on VxWorks < 6Rasmus Villemoes2-0/+12
The condition variables support relies on kernel entry points to enforce critical aspects of it's expected behavior. Some of these entry points are not available prior to VxWorks 6, so we just expose absence of support for condition variables on such systems. 2020-10-15 Rasmus Villemoes <rv@rasmusvillemoes.dk> libgcc/ * config/gthr-vxworks.h: Condition the __GTHREAD_HAS_COND section on VxWorks >= 6. * config/gthr-vxworks-cond.c: Condition the entire implementation on __GTHREAD_HAS_COND.
2020-10-16Add missing #include <taskLib.h> in gthr-vxworks.cRasmus Villemoes1-0/+1
This fixes an oversight and addresses a few build time warnings. 2020-10-15 Rasmus Villemoes <rv@rasmusvillemoes.dk> libgcc/ * config/gthr-vxworks.c: #include <taskLib.h>.
2020-10-16Fix leftover _VXW_PRE_69 in gthr-vxworks.hRasmus Villemoes1-1/+1
2020-10-15 Rasmus Villemoes <rv@rasmusvillemoes.dk> libgcc/ * config/gthr-vxworks.h: Rewrite remaining occurrence of _VXW_PRE_69 as _VXWORKS_PRE(6,9).
2020-10-16Stub out VX_ENTER_TLS_DTOR for VxWorks != 6Rasmus Villemoes1-7/+15
As of today, the __gthread_enter/leave entry points are only meaningful on VxWorks 6. Refactor the VX_ENTER_TLS_DTOR macros accordingly. 2020-10-15 Rasmus Villemoes <rv@rasmusvillemoes.dk> libgcc/ * config/gthr-vxworks-tls.c (VX_ENTER_TLS_DTOR): Nil except on VxWorks 6. Co-authored-by: Olivier Hainque <hainque@adacore.com>
2020-10-16Fix the vxworks crtstuff handling of kernel/rtp variationsOlivier Hainque1-6/+6
The ports that support RTPs achieve the kernel/rtp compilation and link distinction through the multilib mechanism. This patch just removes the bogus explicit extraneous materialization of this distinction in the common VxWorks configuration files and leaves the rtp specialization all to the multilib machinery. 2020-10-15 Olivier Hainque <hainque@adacore.com> libgcc/ * config/t-vxcrtstuff: Remove the -kernel/-rtp specialization. gcc/ * config/vxworks.h (VX_CRTBEGIN_SPEC): Likewise.
2020-10-15Daily bump.GCC Administrator1-0/+25
2020-10-14Rework the condition variables support for VxWorksAlexandre Oliva2-12/+47
This change reworks the condition variables support for VxWorks to address the very legit points raised by Rasmus in https://gcc.gnu.org/pipermail/gcc/2020-May/232524.html While some of the issues were taken care of by the use of semFlush, a few others were indeed calling for adjustments. We first considered resorting to the condvarLib library available in VxWorks7. Unfortunately, it is vx7 only and we wanted something working for at least vx 6.9 as well. It also turned out requiring the use of recursive mutexes for condVarWait, which seemed unnecessarily constraining. Instead, this change corrects the sequencing logic in a few places and leverages the semExchange API to ensure the key atomicity requirement on cond_wait operations. 2020-10-14 Alexandre Oliva <oliva@adacore.com> libgcc/ * config/gthr-vxworks-thread.c: Include stdlib.h. (tls_delete_hook): Prototype it. (__gthread_cond_signal): Return early if no waiters. Consume signal in case the semaphore got full. Use semInfoGet instead of kernel-mode-only semInfo. (__gthread_cond_timedwait): Use semExchange. Always take the mutex again before returning. * config/gthr-vxworks-cond.c (__ghtread_cond_wait): Likewise.
2020-10-14Honor $(MULTISUBDIR) in -I directives for libgcc on VxWorksOlivier Hainque2-2/+2
This is useful to handle ports where we might arrange to use different sets of fixed headers for different multilibs, typically for kernel vs rtp modes. 2020-10-14 Olivier Hainque <hainque@adacore.com> libgcc/ * config/t-vxworks (LIBGCC2_INCLUDES): Append $(MULTISUBDIR) to the -I path for fixed headers, as we arrange to have different sets of such headers for different multilibs when they are activated. * config/t-vxworks7: Likewise.
2020-10-14Add include-fixed to include search paths for libgcc on VxWorksOlivier Hainque2-0/+2
The special vxworks rules for the compilation of libgcc had -I.../gcc/include and not .../gcc/include-fixed, causing build failure of our arm-vxworks7r2 port because of indirect dependencies on limits.h. The omission was just an oversight and this change just adds the missing -I. 2020-10-14 Olivier Hainque <hainque@adacore.com> libgcc/ * config/t-vxworks: Add include-fixed to include search paths for libgcc on VxWorks. * config/t-vxworks7: Likewise.
generated by cgit v1.1 at 2025-02-28 12:31:36 +0000