Re: [PATCH v3] workqueue: Wrap flush_workqueue() using a macro

On 16/05/2022 09.18, Joe Perches wrote: > On Mon, 2022-05-16 at 14:00 +0900, Tetsuo Handa wrote: > [] >> Changes in v3: >> Revert suggested change in v2, for kernel test robot found >> >> warning: Function parameter or member 'flush_workqueue' not described in >> 'void' >> warning: expe

why the asymmetry in VX_CRT{BEGIN,END}_SPEC?

Hi Olivier One thing I've been meaning to ask: Is there a reason VX_CRTBEGIN_SPEC and VX_CRTEND_SPEC are given as #define VX_CRTBEGIN_SPEC "vx_crtbegin.o%s" #define VX_CRTEND_SPEC "-l:vx_crtend.o" so for vx_crtbegin.o, it is gcc itself which expands the full path to the vx_crtbegin.o file, while

ctor/dtor priorities ignored when function is pre-declared

Hi I was wondering why the vx_crtbegin.o file had a .init_array section and not a .init_array.00101, when the function is defined with __attribute__((constructor (101))) (see libgcc/config/vxcrtstuff.c). After a lot of digging, including making sure that EH_CTOR_ATTRIBUTE actually gets defined as

mutex destruction in libgcc/unwind-dw2-fde.c

Hi The unwind code initializes an object_mutex, but it is never destroyed. On VxWorks 5 at least, that's a problem, because it means that module load+unload leaks a resource. I don't know about other VxWorks versions. I'm wondering what the best fix is (insofar as upstream gcc wants to fix it, we

side-effect-free function

Hi, Consider some function now() which returns some kind of "current timestamp" as a simple scalar. It could be a wrapper for clock_gettime(CLOCK_MONOTONIC) which converts the timespec value to nanoseconds, or in the linux kernel one of the ktime_get* family. Then consider code like start = now(

Re: [PATCH 0/5] some vxworks patches

On 03/06/2020 19.41, Olivier Hainque wrote: > Hi Rasmus, > >> On 26 May 2020, at 16:52, Rasmus Villemoes wrote: >> >> libstdc++, but I'd like some feedback on whether vxworks 5 is even >> supposed to be (still) supported before digging further. > > Unfo

[PATCH 5/5] libgcc: vxworks: don't set __GTHREAD_CXX0X for vxworks 5.x

gthr-vxworks-thread.c fails to compile for vxworks 5.x: libgcc/config/gthr-vxworks-thread.c:268:14: error: 'VX_USR_TASK_OPTIONS' undeclared (first use in this function) 268 | options &= VX_USR_TASK_OPTIONS; | ^~~ libgcc/config/gthr-vxworks-thread.c:282:3: e

[PATCH 1/5] libgcc: vxwors: stub out VX_ENTER_TLS_DTOR for vxworks 5

Commit 806dd0472f56 (Improve the thread support for VxWorks) introduced calls of (on vxworks 5 at least) non-existing __gthread_enter_tls_dtor_context/__gthread_leave_tls_dtor_context ; the code used to call __gthread_enter_tsd_dtor_context/__gthread_leave_tsd_dtor_context. Those are simply no-ops

[PATCH 2/5] gthr-vxworks.h: fix leftover _VXW_PRE_69

_VXW_PRE_69 was introduced in 806dd0472f, then replaced by _VXWORKS_PRE(6,9) in abb6c3eecf, but this one was missed. Fixes: abb6c3eecf (Introduce an internal API for VxWorks version checks) --- libgcc/config/gthr-vxworks.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libgcc

[PATCH 3/5] gthr-vxworks.c: add include of taskLib.h

Fix gcc-src/libgcc/config/gthr-vxworks.c:65:7: warning: implicit declaration of function 'taskDelay'; did you mean 'sysDelay'? [-Wimplicit-function-declaration] 65 | taskDelay (1); --- libgcc/config/gthr-vxworks.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libgcc/config/gthr-vx

[PATCH 4/5] libgcc: vxworks: don't set __GTHREAD_HAS_COND for vxworks 5.x

The vxworks-cond.c file fails to compile for vxworks 5.x: libgcc/config/gthr-vxworks-cond.c:29: ./gthr-default.h:274:3: error: unknown type name 'TASK_ID' 274 | TASK_ID task_id; | ^~~ There is a TASK_ID typedef in our system headers, but (1) is is commented out, (2) lives in some

[PATCH 0/5] some vxworks patches

to build libstdc++, but I'd like some feedback on whether vxworks 5 is even supposed to be (still) supported before digging further. Rasmus Villemoes (5): libgcc: vxwors: stub out VX_ENTER_TLS_DTOR for vxworks 5 gthr-vxworks.h: fix leftover _VXW_PRE_69 gthr-vxworks.c: add include of t

condition variables on vxworks

Hi The condition variable implementation added in commit 806dd0472f56fd seems to fall into the trap(s) pointed out in the paper http://birrell.org/andrew/papers/ImplementingCVs.pdf in particular, the "if no thread is currently waiting, signal should not leave a full semaphore so a following _w

Re: git tag for gcc 7.4

On 08/01/2019 14.28, Jonathan Wakely wrote: > On Tue, 8 Jan 2019 at 13:16, Rasmus Villemoes wrote: >> >> I don't see a gcc-7_4_0-release tag in the git mirror. Is that intentional? > > Tags have to be manually added to the git mirror, they don't happen as > part

git tag for gcc 7.4

I don't see a gcc-7_4_0-release tag in the git mirror. Is that intentional? Rasmus

Re: [wwwdocs] Typo in description of __builtin_expect_with_probability

On 2018-10-30 10:54, Jonathan Wakely wrote: > On Tue, 30 Oct 2018 at 09:18, Rasmus Villemoes > wrote: >> >> On 2018-10-30 09:29, Martin Liška wrote: >>> On 10/30/18 3:56 AM, Alexander Oblovatniy wrote: >>>> Hello, >>>&g

Re: [wwwdocs] Typo in description of __builtin_expect_with_probability

On 2018-10-30 09:29, Martin Liška wrote: > On 10/30/18 3:56 AM, Alexander Oblovatniy wrote: >> Hello, >> >> I'd like to report a typo in description of >> «__builtin_expect_with_probability»: >> https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other-Builtins >> >> The description starts with

RFC: allowing compound assignment operators with designated initializers

This is something I've sometimes found myself wishing was supported. The idea being that one can say unsigned a[] = { [0] = 1, [1] = 3, [0] |= 4, ...} which would end up initializing a[0] to 5. As a somewhat realistic example, suppose one is trying to build a bitmap at compile time, but the bits