在 2023/7/5 09:40, Andrew Pinski via Gcc 写道:
It is wrong to use noreturn on a function other than one which has a
return type of void as documented.
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-noreturn-function-attribute
:
```
It does not make sense for a noreturn func
Hi,
W dniu 5.07.2023 o 00:57, Martin Uecker pisze:
Am Dienstag, dem 04.07.2023 um 16:46 +0200 schrieb Rafał Pietrak:...
[]
Yes. named address spaces would be great. And for code, too.
While certainly some work, implementation effort for
new kinds of named address spaces does not s
On Tue, Jul 4, 2023 at 6:32 PM Julian Waters wrote:
>
> Hi Andrew, thanks for the quick response,
>
> What if the method has a return value? I know it sounds counterintuitive, but
> in some places HotSpot relies on the noreturn attribute being applied to
> methods that do return a value in an un
Hi Andrew, thanks for the quick response,
What if the method has a return value? I know it sounds counterintuitive,
but in some places HotSpot relies on the noreturn attribute being applied
to methods that do return a value in an unreachable code path. Does the
unreachable builtin cover that case
On Tue, Jul 4, 2023 at 5:54 PM Julian Waters via Gcc wrote:
>
> Hi all,
>
> Currently to disable the warning that a noreturn method does return, it's
> required to disable warnings entirely. This can be very inconvenient when
> -Werror is enabled with a noreturn method that isn't specifically call
Hi all,
Currently to disable the warning that a noreturn method does return, it's
required to disable warnings entirely. This can be very inconvenient when
-Werror is enabled with a noreturn method that isn't specifically calling
something like std::abort() at the end, when one wants all other -Wa
Am Dienstag, dem 04.07.2023 um 16:46 +0200 schrieb Rafał Pietrak:...
> >
> > I think a C++ class (or rather, class template) with inline functions is
> > the way to go here. gcc's optimiser will give good code, and the C++
> > class will let you get nice syntax to hide the messy details.
>
>
On Tue, Jul 04, 2023 at 04:25:45PM -0400, Alan Stern wrote:
> On Tue, Jul 04, 2023 at 01:19:23PM -0400, Olivier Dion wrote:
[ . . . ]
> > I am puzzled by this. Initialization of a shared variable does not need
> > to be atomic until its publication. Could you expand on this?
>
> In the kernel,
On Tue, Jul 04, 2023 at 01:19:23PM -0400, Olivier Dion wrote:
> On Mon, 03 Jul 2023, Alan Stern wrote:
> > On Mon, Jul 03, 2023 at 03:20:31PM -0400, Olivier Dion wrote:
> >> This is a request for comments on extending the atomic builtins API to
> >> help avoiding redundant memory barriers. Indeed
On Mon, 03 Jul 2023, Alan Stern wrote:
> On Mon, Jul 03, 2023 at 03:20:31PM -0400, Olivier Dion wrote:
>> This is a request for comments on extending the atomic builtins API to
>> help avoiding redundant memory barriers. Indeed, there are
>
> What atomic builtins API are you talking about? The k
W dniu 4.07.2023 o 17:55, David Brown pisze:
On 04/07/2023 16:46, Rafał Pietrak wrote:
[--]
Yes. named address spaces would be great. And for code, too.
It is good to have a wishlist (and you can file a wishlist "bug" in the
gcc bugzilla, so that it won't be forgotten). But it
W dniu 4.07.2023 o 17:13, David Brown pisze:
[]
If you have a circular buffer, it is vastly more efficient to have an
array with no pointers or indices, and use head and tail indices to
track the current position. But I'm not sure if that is what you are
looking for. And you
On 04/07/2023 16:46, Rafał Pietrak wrote:
Hi,
W dniu 4.07.2023 o 14:38, David Brown pisze:
[-]
A key difference is that using 32-bit pointers on an x86 is enough
address space for a large majority of use-cases, while even on the
smallest small ARM microcontroller, 16-bit is not enough.
On 04/07/2023 16:20, Rafał Pietrak wrote:
W dniu 3.07.2023 o 18:29, Rafał Pietrak pisze:
Hi David,
[--]
4. It is worth taking a step back, and thinking about how you would
like to use these pointers. It is likely that you would be better
thinking in terms of an array, rather t
Hi,
W dniu 4.07.2023 o 14:38, David Brown pisze:
[-]
A key difference is that using 32-bit pointers on an x86 is enough
address space for a large majority of use-cases, while even on the
smallest small ARM microcontroller, 16-bit is not enough. (It's not
even enough to access all memo
W dniu 3.07.2023 o 18:29, Rafał Pietrak pisze:
Hi David,
[--]
4. It is worth taking a step back, and thinking about how you would
like to use these pointers. It is likely that you would be better
thinking in terms of an array, rather than pointers - after all, you
don't want
> I think a C++ class (or rather, class template) with inline functions is
> the way to go here. gcc's optimiser will give good code, and the C++
> class will let you get nice syntax to hide the messy details.
>
> There is no good way to do this in C. Named address spaces would be a
> possibi
On 03/07/2023 18:42, Rafał Pietrak via Gcc wrote:
Hi Ian,
W dniu 3.07.2023 o 17:07, Ian Lance Taylor pisze:
On Wed, Jun 28, 2023 at 11:21 PM Rafał Pietrak via Gcc
wrote:
[]
I was thinking about that, and it doesn't look as requiring that deep
rewrites. ABI spec, that could accomodat
On Tue, 4 Jul 2023 at 10:47, Peter Zijlstra wrote:
>
> On Mon, Jul 03, 2023 at 03:20:31PM -0400, Olivier Dion wrote:
>
> > int x = 0;
> > int y = 0;
> > int r0, r1;
> >
> > int dummy;
> >
> > void t0(void)
> > {
> > __atomic_store_n(&x, 1, __ATOMIC_RELAXED);
> >
> >
On Mon, Jul 03, 2023 at 03:20:31PM -0400, Olivier Dion wrote:
> int x = 0;
> int y = 0;
> int r0, r1;
>
> int dummy;
>
> void t0(void)
> {
> __atomic_store_n(&x, 1, __ATOMIC_RELAXED);
>
> __atomic_exchange_n(&dummy, 1, __ATOMIC_SEQ_CST);
> __atomic_thre
20 matches
Mail list logo
