[Bug middle-end/41639] __sync synchronisation primitives take unsigned as input and output values.

2024-03-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41639

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Andrew Pinski  ---
>(tested on SH with a non-linux, in house runtime, implementation)


The bug is in your runtime implementation I think.

Which has a mismatch in the return type vs what GCC internals think these
should be.

Note libgcc/sync.c does:
```
#if SIZE == 1 && __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1

typedef unsigned int UQItype __attribute__((mode (QI)));
DEFINE (FN, 1, UQItype)

#elif SIZE == 2 && __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2

typedef unsigned int UHItype __attribute__((mode (HI)));
DEFINE (FN, 2, UHItype)

#elif SIZE == 4 && __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4

typedef unsigned int USItype __attribute__((mode (SI)));
DEFINE (FN, 4, USItype)

#elif SIZE == 8 && __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8

typedef unsigned int UDItype __attribute__((mode (DI)));
DEFINE (FN, 8, UDItype)

#elif SIZE == 16 && __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16

typedef unsigned int UOItype __attribute__((mode (OI)));
DEFINE (FN, 8, UOItype)


```

Which matches the internals of GCC.

[Bug middle-end/41639] __sync synchronisation primitives take unsigned as input and output values.

2024-03-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41639

Andrew Pinski  changed:

   What|Removed |Added

 Target||sh*-*

--- Comment #3 from Andrew Pinski  ---
So I looked into the history here and the code was correct even when this bug
was fixed.

Basically resolve_overloaded_builtin will resolve __sync_sub_and_fetch into
__sync_sub_and_fetch_1 and add a cast for the return value to the same type as
the first argument this is done in sync_resolve_return.


48ae6c138ca3 (Richard Henderson 2005-04-14 16:37:47 -0700 8801)
result = build_function_call (new_function, params);
48ae6c138ca3 (Richard Henderson 2005-04-14 16:37:47 -0700 8802)
if (orig_code != BUILT_IN_BOOL_COMPARE_AND_SWAP_N
48ae6c138ca3 (Richard Henderson 2005-04-14 16:37:47 -0700 8803)
&& orig_code != BUILT_IN_LOCK_RELEASE_N)
48ae6c138ca3 (Richard Henderson 2005-04-14 16:37:47 -0700 8804)
  result = sync_resolve_return (params, result);


So unless there is something wrong with the way sh implements these functions
in libgcc there is no issue in the middle-end.