Re: [RFC] Bridging the gap between the Linux Kernel Memory Consistency Model (LKMM) and C11/C++11 atomics

[Boqun Feng via Gcc]

On Mon, Jul 03, 2023 at 03:20:31PM -0400, Olivier Dion wrote:
[...]
> NOTE: On x86-64, we found at least one corner case [7] with Clang where
> a RELEASE exchange is optimized to a RELEASE store, when the returned
> value of the exchange is unused, breaking the above expectations.
> Although this type of optimization respect the standard "as-if"
> statement, we question its pertinence since a user should simply do a
> RELEASE store instead of an exchange in that case.  With the
> introduction of these new primitives, these type of optimizations should
> be revisited.
> 

FWIW, this is actually a LLVM bug:

https://github.com/llvm/llvm-project/issues/60418

Regards,
Boqun

Re: wishlist: support for shorter pointers

[Martin Uecker]

Am Mittwoch, dem 05.07.2023 um 07:26 +0200 schrieb Rafał Pietrak:
> 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 seem to be
> > terrible at first glance:
> > 
> > https://gcc.gnu.org/onlinedocs/gccint/target-macros/adding-support-for-named-address-spaces.html
> 
> Oh! I see. this is good news. Although that internals documentation is 
> complete black magic to me and I cannot tell heads from tails in it, the 
> surrounding comments sound promising... like GCC-13 actually had the 
> internal "machinery" supporting named address spaces and just 
> cpu-platform specific code is missing (for all but "SPU port"). Is that 
> right?

It seems like this. I would need to do more research.

> 
> And if it's so ... there is no mention of how does it show up for 
> "simple user" of the GCC (instead of the use of that "machinery" by 
> creators of particular GCC port). In other words: how the sources should 
> look like for the compiler to do "the thing"?
> 

Not sure I understand the question.  You would add a name space
to an object as a qualifier and then the object would be allocated
in a special (small) region of memory.  Pointers known to point
into that special region of memory (which is encoded into the
type) would then be smaller.  At least, this is my understanding 
of how it could work.

Martin

Re: wishlist: support for shorter pointers

[Rafał Pietrak via Gcc]

Hi,

W dniu 5.07.2023 o 09:29, Martin Uecker pisze:

Am Mittwoch, dem 05.07.2023 um 07:26 +0200 schrieb Rafał Pietrak:

[---]

And if it's so ... there is no mention of how does it show up for
"simple user" of the GCC (instead of the use of that "machinery" by
creators of particular GCC port). In other words: how the sources should
look like for the compiler to do "the thing"?



Not sure I understand the question.  You would add a name space
to an object as a qualifier and then the object would be allocated
in a special (small) region of memory.  Pointers known to point
into that special region of memory (which is encoded into the
type) would then be smaller.  At least, this is my understanding
of how it could work.


Apparently you do understand my question.

Then again ... apparently you are guessing the answer. Incidentally, 
that would be my guess, too. And while such "syntax" is not really 
desirable (since such attribution at every declaration of every "short 
pointer" variable would significantly obfuscate the sources and a thing 
like "#pragma" at the top of a file would do a better job), better 
something then nothing. Then again, should you happen to fall onto an 
actual documentation of syntax to use this feature with, I'd appreciate 
you sharing it :)


-R

Re: wishlist: support for shorter pointers

[David Brown via Gcc]

On 05/07/2023 10:05, Rafał Pietrak via Gcc wrote:

Hi,

W dniu 5.07.2023 o 09:29, Martin Uecker pisze:

Am Mittwoch, dem 05.07.2023 um 07:26 +0200 schrieb Rafał Pietrak:

[---]

And if it's so ... there is no mention of how does it show up for
"simple user" of the GCC (instead of the use of that "machinery" by
creators of particular GCC port). In other words: how the sources should
look like for the compiler to do "the thing"?



Not sure I understand the question.  You would add a name space
to an object as a qualifier and then the object would be allocated
in a special (small) region of memory.  Pointers known to point
into that special region of memory (which is encoded into the
type) would then be smaller.  At least, this is my understanding
of how it could work.


Note that this only applies to pointers declared to be of the address 
space specific type.  If you have "__smalldata int x;" using a 
hypothetical new address space, then "&x" is of type "__smalldata int *" 
and you need to specify the address space specific pointer type to get 
the size advantages.  (Since the __smalldata address space is a subset 
of the generic space, conversions between pointer types are required to 
work correctly.)




Apparently you do understand my question.

Then again ... apparently you are guessing the answer. Incidentally, 
that would be my guess, too. And while such "syntax" is not really 
desirable (since such attribution at every declaration of every "short 
pointer" variable would significantly obfuscate the sources and a thing 
like "#pragma" at the top of a file would do a better job), better 
something then nothing. Then again, should you happen to fall onto an 
actual documentation of syntax to use this feature with, I'd appreciate 
you sharing it :)




I am not sure if you are clear about this, but the address space 
definition macros here are for use in the source code for the compiler, 
not in user code.  There is (AFAIK) no way for user code to create 
address spaces - you need to check out the source code for GCC, modify 
it to support your new address space, and build your own compiler.  This 
is perfectly possible (it's all free and open source, after all), but it 
is not a minor undertaking - especially if you don't like C++ !


In my personal opinion (which you are all free to disregard), named 
address spaces were an interesting idea that failed.  I was enthusiastic 
about a number of the extensions in TR 18307 "C Extensions to support 
embedded processors" when the paper was first published.  As I learned 
more, however, I saw it was a dead-end.  The features are too 
under-specified to be useful or portable, gave very little of use to 
embedded programmers, and fit badly with C.  It was an attempt to 
standardise and generalise some of the mess of different extensions that 
proprietary toolchain developers had for a variety of 8-bit CISC 
microcontrollers that could not use standard C very effectively.  But it 
was all too little, too late - and AFAIK none of these proprietary 
toolchains support it.  GCC supports some of the features to some extent 
- a few named address spaces on a few devices, for "gnuc" only (not 
standard C, and not C++), and has some fixed point support for some 
targets (with inefficient generated code - it appears to be little more 
than an initial "proof of concept" implementation).


I do not think named address spaces have a future - in GCC or anywhere 
else.  The only real use of them at the moment is for the AVR for 
accessing data in flash, and even then it is of limited success since it 
does not work in C++.



I realise that learning at least some C++ is a significant step beyond 
learning C - but /using/ C++ classes or templates is no harder than C 
coding.  And it is far easier, faster and less disruptive to make a C++ 
header library implementing such features than adding new named address 
spaces into the compiler itself.


The one key feature that is missing is that named address spaces can 
affect the allocation details of data, which cannot be done with C++ 
classes.  You could make a "small_data" class template, but variables 
would still need to be marked __attribute__((section(".smalldata"))) 
when used.  I think this could be handled very neatly with one single 
additional feature in GCC - allow arbitrary GCC variable attributes to 
be specified for types, which would then be applied to any variables 
declared for that type.


David

GCC support addition for Safety compliances

[Vishal B Patil via Gcc]

Hi Team,

Need support from the GCC GNU for the some safety compliances. Can you please 
guide or check which GCC support the safety compliances.

Regards,
Vishal B Patil

vishal.b.pa...@cummins.com

Dahanukar Colony, Kothrud
Pune
Maharashtra
411038
India

Re: wishlist: support for shorter pointers

[Martin Uecker]

Am Mittwoch, dem 05.07.2023 um 11:11 +0200 schrieb David Brown:
> On 05/07/2023 10:05, Rafał Pietrak via Gcc wrote:

...
> 
> In my personal opinion (which you are all free to disregard), named 
> address spaces were an interesting idea that failed.  I was
> enthusiastic 
> about a number of the extensions in TR 18307 "C Extensions to support
> embedded processors" when the paper was first published.  As I
> learned 
> more, however, I saw it was a dead-end.  The features are too 
> under-specified to be useful or portable, gave very little of use to 
> embedded programmers, and fit badly with C.  It was an attempt to 
> standardise and generalise some of the mess of different extensions
> that 
> proprietary toolchain developers had for a variety of 8-bit CISC 
> microcontrollers that could not use standard C very effectively.  But
> it 
> was all too little, too late - and AFAIK none of these proprietary 
> toolchains support it.  GCC supports some of the features to some
> extent 
> - a few named address spaces on a few devices, for "gnuc" only (not 
> standard C, and not C++), and has some fixed point support for some 
> targets (with inefficient generated code - it appears to be little
> more 
> than an initial "proof of concept" implementation).
> 
> I do not think named address spaces have a future - in GCC or
> anywhere 
> else.  The only real use of them at the moment is for the AVR for 
> accessing data in flash, and even then it is of limited success since
> it 
> does not work in C++.

Can you explain a little bit why you think it is a dead-end?  It
seems an elegant solution to a range of problems to me.

I have no idea how much the GCC features are actually used,
but other compilers for  embedded systems such as SDCC also 
support named address spaces.  


Martin

Re: wishlist: support for shorter pointers

[Martin Uecker]

Am Mittwoch, dem 05.07.2023 um 10:05 +0200 schrieb Rafał Pietrak:
> Hi,
> 
> W dniu 5.07.2023 o 09:29, Martin Uecker pisze:
> > Am Mittwoch, dem 05.07.2023 um 07:26 +0200 schrieb Rafał Pietrak:
> [---]
> > > And if it's so ... there is no mention of how does it show up for
> > > "simple user" of the GCC (instead of the use of that "machinery"
> > > by
> > > creators of particular GCC port). In other words: how the sources
> > > should
> > > look like for the compiler to do "the thing"?
> > > 
> > 
> > Not sure I understand the question.  You would add a name space
> > to an object as a qualifier and then the object would be allocated
> > in a special (small) region of memory.  Pointers known to point
> > into that special region of memory (which is encoded into the
> > type) would then be smaller.  At least, this is my understanding
> > of how it could work.
> 
> Apparently you do understand my question.
> 
> Then again ... apparently you are guessing the answer. Incidentally, 
> that would be my guess, too. And while such "syntax" is not really 
> desirable (since such attribution at every declaration of every
> "short 
> pointer" variable would significantly obfuscate the sources and a
> thing 
> like "#pragma" at the top of a file would do a better job), better 
> something then nothing. 

If you want to mix pointers I think it would make the code clearer
if the name space is explicit.  But yes, you would need to add
those annotations.

But maybe one could also consider a pragma that sets a default 
name space mode for some region of code in the source.   

> Then again, should you happen to fall onto an 
> actual documentation of syntax to use this feature with, I'd
> appreciate 
> you sharing it :)

Sorry, I thought I shared this before:

https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html

The draft specification mentioned there can be found herE:

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1275.pdf



Martin

Re: wishlist: support for shorter pointers

[Rafał Pietrak via Gcc]

Hi,

W dniu 5.07.2023 o 11:11, David Brown pisze:

On 05/07/2023 10:05, Rafał Pietrak via Gcc wrote:

[---]

type) would then be smaller.  At least, this is my understanding
of how it could work.


Note that this only applies to pointers declared to be of the address 
space specific type.  If you have "__smalldata int x;" using a 
hypothetical new address space, then "&x" is of type "__smalldata int *" 
and you need to specify the address space specific pointer type to get 
the size advantages.  (Since the __smalldata address space is a subset 
of the generic space, conversions between pointer types are required to 
work correctly.)


I see.

[]
thing like "#pragma" at the top of a file would do a better job), 
better something then nothing. Then again, should you happen to fall 
onto an actual documentation of syntax to use this feature with, I'd 
appreciate you sharing it :)




I am not sure if you are clear about this, but the address space 
definition macros here are for use in the source code for the compiler, 
not in user code.  There is (AFAIK) no way for user code to create 
address spaces - you need to check out the source code for GCC, modify 
it to support your new address space, and build your own compiler.  This 
is perfectly possible (it's all free and open source, after all), but it 
is not a minor undertaking - especially if you don't like C++ !


Hmmm.

Wouldn't it be easier and more natural to make the "named spaces" a 
synonym to specific linker sections (like section names, or section name 
prefix when instead of ".data.array.*" one gets ".mynamespace.array.*")?


[--]
I realise that learning at least some C++ is a significant step beyond 
learning C - but /using/ C++ classes or templates is no harder than C 
coding.  And it is far easier, faster and less disruptive to make a C++ 
header library implementing such features than adding new named address 
spaces into the compiler itself.


The one key feature that is missing is that named address spaces can 
affect the allocation details of data, which cannot be done with C++ 
classes.  You could make a "small_data" class template, but variables 
would still need to be marked __attribute__((section(".smalldata"))) 
when used.  I think this could be handled very neatly with one single 
additional feature in GCC - allow arbitrary GCC variable attributes to 
be specified for types, which would then be applied to any variables 
declared for that type.


OK. I see your point.

But let's have look at it. You say, that "names spaces affect allocation 
details, which cannot be done with C++". Pls consider:
1. for small embedded devices C++ is not a particularly "seller". We 
even turn to assembler occasionally.
2. affecting allocation details is usually the hole point of engineering 
skills when dealing with small embedded devices - the hole point is to 
have tools to do that.


So your current objections to named spaces ... are in fact in favor of 
them. Isn't it so?


-R

Re: wishlist: support for shorter pointers

[Rafał Pietrak via Gcc]

Hi

W dniu 5.07.2023 o 11:29, Martin Uecker pisze:

Am Mittwoch, dem 05.07.2023 um 10:05 +0200 schrieb Rafał Pietrak:

[--]

Then again ... apparently you are guessing the answer. Incidentally,
that would be my guess, too. And while such "syntax" is not really
desirable (since such attribution at every declaration of every
"short
pointer" variable would significantly obfuscate the sources and a
thing
like "#pragma" at the top of a file would do a better job), better
something then nothing.


If you want to mix pointers I think it would make the code clearer
if the name space is explicit.  But yes, you would need to add
those annotations.

But maybe one could also consider a pragma that sets a default
name space mode for some region of code in the source.


Yes. When there is a pragma to set a default for section of sources, one 
has to have another pragma, to "restore" compiler default.





Then again, should you happen to fall onto an
actual documentation of syntax to use this feature with, I'd
appreciate
you sharing it :)


Sorry, I thought I shared this before:

https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html


Thenx ... I've only scanned it (so I may be wrong with the following), 
but the example for AVR target looks ... strange. First example reads:

char my_read (const __flash char ** p)
{
/* p is a pointer to RAM that points to a pointer to flash.
   The first indirection of p reads that flash pointer
   from RAM and the second indirection reads a char from this
   flash address.  */

return **p;
}

now, how come a programmer (or a compiler) can possibly know, that it's 
not the other way around, meaning: first flash, then RAM) ... I know, 
that this is probably pointless here, but if the "named spaces" are to 
be fully generic, then "flash" does not necessarily mean "read only". 
There may be other "types" of memory, like "Close Coupled Memory", or 
some embedded device dedicated buffers. So something like:

const __flash struct test_s {
const __flash struct test_s *m,*n;
int a,b,c;
};
struct test_s *Z;   // struct is already know to be in __flash
	// no need to repeat that info. Still, the Z is naturally  in default 
namespace - in RAM

struct test_s * my_read (struct test_s ** p)
{
/* P being passed as argument in register is a pointer in RAM, that 
points to a structure in __flash ... because that's how struct test_s is 
originally declared  */


return *p;
}
is more readable to me :) and should I need to port the code to other 
devices I just take out the __flash from one/single place in the 
sources. Easy and painless.


then again. To understand what the code does, I really don't need the 
__flash notification every time the structures in question appear.




The draft specification mentioned there can be found herE:

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1275.pdf


OK. Thenx,

-R

Re: wishlist: support for shorter pointers

[Martin Uecker]

Am Mittwoch, dem 05.07.2023 um 12:17 +0200 schrieb Rafał Pietrak:
> Hi
> 
> W dniu 5.07.2023 o 11:29, Martin Uecker pisze:
> > Am Mittwoch, dem 05.07.2023 um 10:05 +0200 schrieb Rafał Pietrak:
> 
...

> > 
> > > Then again, should you happen to fall onto an
> > > actual documentation of syntax to use this feature with, I'd
> > > appreciate
> > > you sharing it :)
> > 
> > Sorry, I thought I shared this before:
> > 
> > https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html
> 
> Thenx ... I've only scanned it (so I may be wrong with the
> following), 
> but the example for AVR target looks ... strange. First example
> reads:
> char my_read (const __flash char ** p)
> {
>  /* p is a pointer to RAM that points to a pointer to flash.
>     The first indirection of p reads that flash pointer
>     from RAM and the second indirection reads a char from this
>     flash address.  */
> 
>  return **p;
> }
> 
> now, how come a programmer (or a compiler) can possibly know, that
> it's not the other way around, meaning: first flash, then RAM) ... 

It should work exactly like qualifiers:

const __flash char **p;
// pointer to pointer to char in flash

const char * __flash *p; 
// pointers to pointer in flash to pointer in char

const char ** __flash p;
// pointer in flash to pointer in RAM to pointer to char


So the same rules as for 'const'.

> I know, that this is probably pointless here, but if the "named
> spaces" are to be fully generic, then "flash" does not necessarily
> mean "read only". There may be other "types" of memory, like "Close
> Coupled Memory", or some embedded device dedicated buffers. 

Yes. This would be device-specific. Although one could
consider more generic user-defined name spaces as well.
This was discussed before for security boundaries, e.g.
__kernel and __user.


> So something like:
> const __flash struct test_s {
> const __flash struct test_s *m,*n;
> int a,b,c;
> };
> struct test_s *Z;   // struct is already know to be in __flash
> // no need to repeat that info. Still, the Z is naturally  in
> default namespace - in RAM

The name space would not automatically become
part of the struct test_s type similar to how const
would not  become part of it.  But one should be
able to use a typedef:

typedef const __flash struct test_s { } test_s;
 


> struct test_s * my_read (struct test_s ** p)
> {
>  /* P being passed as argument in register is a pointer in RAM,
> that 
> points to a structure in __flash ... because that's how struct test_s
> is 
> originally declared  */
> 
>  return *p;
> }
> is more readable to me :) and should I need to port the code to other
> devices I just take out the __flash from one/single place in the 
> sources. Easy and painless.

You could do this with a typedef as above or also with a macro:

#ifdef ..
#define my_namespace __flash
##else
#define my_namespace
#endif

So I think portability is not a problem. 

> 
> then again. To understand what the code does, I really don't need the
> __flash notification every time the structures in question appear.

In general, I think ones does: The flash pointers can not 
store pointers to arbitrary objects in ram so one needs 
to keep them appart to avoid mistakes.

If one has types which are only used for objects in flash, one 
can use a typedef and then one does not need the annotation 
every time.


Martin

Re: Warning specifically for a returning noreturn

[Julian Waters via Gcc]

I see, thanks Andrew.

Anyone else have opinions on this besides Liu or Andrew? The responses have
been surprisingly quiet thus far

best regards,
Julian

On Wed, 5 Jul 2023, 09:40 Andrew Pinski,  wrote:

> 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 unreachable
> code path. Does the unreachable builtin cover that case too?
>
> 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 function to have a return type
> other than void.
> ```
>
> Thanks,
> Andrew Pinski
>
>
> >
> > best regards.
> > Julian
> >
> > On Wed, Jul 5, 2023 at 9:07 AM Andrew Pinski  wrote:
> >>
> >> 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
> calling
> >> > something like std::abort() at the end, when one wants all other
> -Wall and
> >> > -Wextra warnings to be reported, for instance in the Java HotSpot VM
> (which
> >> > I'm currently adapting to compile with gcc on all supported
> platforms). Is
> >> > there a possibility we can add a disable warning option specifically
> for
> >> > this case? Something like -Wno-returning-noreturn. I'm interested in
> adding
> >> > this myself if it's not convenient for gcc's maintainers to do so at
> the
> >> > moment, but I'd need some guidance on where to look and what the
> relevant
> >> > code is
> >>
> >> You could just add
> >> __builtin_unreachable(); (or std::unreachable(); if you are C++23 or
> >> unreachable() if you are using C23).
> >> Or even add while(true) ;
> >>
> >> I am pretty sure not having an option is on purpose and not really
> >> interested in adding an option here because of the above workarounds.
> >>
> >> Thanks,
> >> Andrew Pinski
> >>
> >> >
> >> > best regards,
> >> > Julian
>

Re: Warning specifically for a returning noreturn

[Jonathan Wakely via Gcc]

On Wed, 5 Jul 2023 at 12:01, Julian Waters via Gcc  wrote:
>
> I see, thanks Andrew.
>
> Anyone else have opinions on this besides Liu or Andrew? The responses have
> been surprisingly quiet thus far

IMHO all warnings should have an option controlling them, so that you
can disable them via pragmas.

But I agree that you shouldn't need to return from a noreturn
function, it can either throw or use __builtin_unreachable() on the
line where you currently return.


>
> best regards,
> Julian
>
> On Wed, 5 Jul 2023, 09:40 Andrew Pinski,  wrote:
>
> > 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 unreachable
> > code path. Does the unreachable builtin cover that case too?
> >
> > 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 function to have a return type
> > other than void.
> > ```
> >
> > Thanks,
> > Andrew Pinski
> >
> >
> > >
> > > best regards.
> > > Julian
> > >
> > > On Wed, Jul 5, 2023 at 9:07 AM Andrew Pinski  wrote:
> > >>
> > >> 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
> > calling
> > >> > something like std::abort() at the end, when one wants all other
> > -Wall and
> > >> > -Wextra warnings to be reported, for instance in the Java HotSpot VM
> > (which
> > >> > I'm currently adapting to compile with gcc on all supported
> > platforms). Is
> > >> > there a possibility we can add a disable warning option specifically
> > for
> > >> > this case? Something like -Wno-returning-noreturn. I'm interested in
> > adding
> > >> > this myself if it's not convenient for gcc's maintainers to do so at
> > the
> > >> > moment, but I'd need some guidance on where to look and what the
> > relevant
> > >> > code is
> > >>
> > >> You could just add
> > >> __builtin_unreachable(); (or std::unreachable(); if you are C++23 or
> > >> unreachable() if you are using C23).
> > >> Or even add while(true) ;
> > >>
> > >> I am pretty sure not having an option is on purpose and not really
> > >> interested in adding an option here because of the above workarounds.
> > >>
> > >> Thanks,
> > >> Andrew Pinski
> > >>
> > >> >
> > >> > best regards,
> > >> > Julian
> >

Re: wishlist: support for shorter pointers

[David Brown via Gcc]

On 05/07/2023 11:25, Martin Uecker wrote:

Am Mittwoch, dem 05.07.2023 um 11:11 +0200 schrieb David Brown:

On 05/07/2023 10:05, Rafał Pietrak via Gcc wrote:


...


In my personal opinion (which you are all free to disregard), named
address spaces were an interesting idea that failed.  I was
enthusiastic
about a number of the extensions in TR 18307 "C Extensions to support
embedded processors" when the paper was first published.  As I
learned
more, however, I saw it was a dead-end.  The features are too
under-specified to be useful or portable, gave very little of use to
embedded programmers, and fit badly with C.  It was an attempt to
standardise and generalise some of the mess of different extensions
that
proprietary toolchain developers had for a variety of 8-bit CISC
microcontrollers that could not use standard C very effectively.  But
it
was all too little, too late - and AFAIK none of these proprietary
toolchains support it.  GCC supports some of the features to some
extent
- a few named address spaces on a few devices, for "gnuc" only (not
standard C, and not C++), and has some fixed point support for some
targets (with inefficient generated code - it appears to be little
more
than an initial "proof of concept" implementation).

I do not think named address spaces have a future - in GCC or
anywhere
else.  The only real use of them at the moment is for the AVR for
accessing data in flash, and even then it is of limited success since
it
does not work in C++.


Can you explain a little bit why you think it is a dead-end?  It
seems an elegant solution to a range of problems to me.


Named address spaces are not standardised in C, and I do not expect they 
ever will be.  The TR18307 document is not anywhere close to being of a 
quality that could be integrated with the C standards, even as optional 
features, and much of it makes no sense in practice (I have never heard 
of the IO stuff being implemented or used).


The few compilers that implement any of it do so in different ways - the 
"__flash" address space in AVR GCC is slightly different from the same 
extension in IAR's AVR compiler.  For existing compilers, there is a 
strong inconsistency as to whether such things are "named address 
spaces", "extension keywords", "type qualifiers", "attributes", or other 
terms, all with subtly (or not so subtly) different effects on how they 
are used, what restrictions exist, conversions between types, and how 
errors can be diagnosed.  Sometimes these features are considered part 
of the data type, sometimes of pointer types, sometimes they are just 
about data placement.


Since every compiler targeting these small awkward microcontrollers has 
a different idea of what something like "const __flash int x = 123;" 
means, and has been implementing their own ideas for a decade or two 
before TR18307 ever proposed "named address spaces", the TR hasn't a 
hope of being a real standard.


Named address spaces are not implemented at all, anywhere (AFAIK), for 
C++.  (Some embedded toolchains have limited support for C++ on such 
microcontrollers, but these are again not really named address spaces.) 
Since C++ usage is heavily increasing in the small embedded system 
world, this is important.  (GCC has much of the honour for that - as ARM 
took a bigger share of the market and GCC for ARM improved, the 
toolchain market was no longer at the mercy of big commercial vendors 
who charged absurd amounts for their C++ toolchains.)  A feature which 
is only for C, and not supported by C++, is almost guaranteed to be 
dead-end.


And of course the type of processor for which named address spaces or 
other related extensions are essential, are a dying breed.  The AVR is 
probably the only one with a significant future.  Part of the appeal of 
ARM in the embedded world is it frees you from the pains of 
target-specific coding with some of your data in "near" memory, some in 
"extended" memory, some in "flash" address spaces or "IO" address 
spaces.  It all works with standard C or C++.  The same applies to 
challengers like RISC-V, MIPS, PPC, and any other core - you have a 
single flat address space for normal data.




I have no idea how much the GCC features are actually used,
but other compilers for  embedded systems such as SDCC also
support named address spaces.



And the targets supported by SDCC are also dead-end devices - there is 
not a single one of them that I would consider for a new project.  These 
microcontrollers are now used almost exclusively for legacy projects - 
updates to existing hardware or software, and rely on compatibility with 
existing C extensions (whether they are called "named address spaces", 
"extension keywords", or anything else).



Now, there are things that I would like to be able to write in my code 
that could appear to be candidates for some kind of named address space. 
 For example, I might want data that is placed in an external eeprom - 
it could be nice to be able to d

Re: wishlist: support for shorter pointers

[David Brown via Gcc]

On 05/07/2023 11:42, Rafał Pietrak via Gcc wrote:

Hi,

W dniu 5.07.2023 o 11:11, David Brown pisze:

On 05/07/2023 10:05, Rafał Pietrak via Gcc wrote:

[---]


I am not sure if you are clear about this, but the address space 
definition macros here are for use in the source code for the 
compiler, not in user code.  There is (AFAIK) no way for user code to 
create address spaces - you need to check out the source code for GCC, 
modify it to support your new address space, and build your own 
compiler.  This is perfectly possible (it's all free and open source, 
after all), but it is not a minor undertaking - especially if you 
don't like C++ !


Hmmm.

Wouldn't it be easier and more natural to make the "named spaces" a 
synonym to specific linker sections (like section names, or section name 
prefix when instead of ".data.array.*" one gets ".mynamespace.array.*")?


You can, of course, write :

#define __smalldata __attribute__((section(".smalldata)))

I'd rather see the "section" attribute extended to allow it to specify a 
prefix or suffix (to make subsections) than more named address spaces.


I'm a big fan of only putting things in the compiler if they have to be 
there - if a feature can be expressed in code (whether it be C, C++, or 
preprocessor macros), then I see that as the best choice.




[--]
I realise that learning at least some C++ is a significant step beyond 
learning C - but /using/ C++ classes or templates is no harder than C 
coding.  And it is far easier, faster and less disruptive to make a 
C++ header library implementing such features than adding new named 
address spaces into the compiler itself.


The one key feature that is missing is that named address spaces can 
affect the allocation details of data, which cannot be done with C++ 
classes.  You could make a "small_data" class template, but variables 
would still need to be marked __attribute__((section(".smalldata"))) 
when used.  I think this could be handled very neatly with one single 
additional feature in GCC - allow arbitrary GCC variable attributes to 
be specified for types, which would then be applied to any variables 
declared for that type.


OK. I see your point.

But let's have look at it. You say, that "names spaces affect allocation 
details, which cannot be done with C++". Pls consider:
1. for small embedded devices C++ is not a particularly "seller". We 
even turn to assembler occasionally.


I have been writing code for small embedded systems for about 30 years. 
I used to write a lot in assembly, but it is very rare now.  Almost all 
of the assembly I write these days is inline assembly in gcc format - 
and a lot of that actually contains no assembly at all, but is for 
careful control of dependencies or code re-arrangements.  The smallest 
device I have ever used was an AVR Tiny with no ram at all - just 2K 
flash, a 3-level return stack and its 32 8-bit registers.  I programmed 
that in C (with gcc).


C++ /is/ a big "seller" in this market.  It is definitely growing, just 
as the market for commercial toolchains with non-portable extensions is 
dropping and 8-bit CISC devices are being replaced by Cortex-M0 cores. 
There is certainly plenty of C-only coding going on, but C++ is growing.


2. affecting allocation details is usually the hole point of engineering 
skills when dealing with small embedded devices - the hole point is to 
have tools to do that.




When you are dealing with 8-bit CISC devices like the 8051 or the COP8, 
then allocation strategies are critical, and good tools are essential.


But for current microcontrollers, they are not nearly as important 
because you have a single flat address space - pointers to read-only 
data in flash and pointers to data in ram are fully compatible.  You do 
sometimes need to place particular bits of data in particular places, 
but that is usually for individual large data blocks such as putting 
certain buffers in non-cached memory, or a large array in external 
memory.  Section attributes suffice for that.


Allocation control is certainly important at times, but it's far from 
being as commonly needed as you suggest.


(Dynamic allocation is a different matter, but I don't believe we are 
talking about that here.)


So your current objections to named spaces ... are in fact in favor of 
them. Isn't it so?




Not really, no - I would rather see better ways to handle allocation and 
section control than more named address spaces.


David

Re: wishlist: support for shorter pointers

[Martin Uecker]

Thanks David!

I do not think I agree with all of it (e.g. sdcc is
actively developed with regular releases and supports 
tiny devices which are used for extreme low-power 
applications) and I do not personally think that only 
C++ counts nowadays, especially in the embedded world, 
but we do not need to discuss this now. I still very
much appreciate your input!

Note that I am involved with C standardization, but
TR 18307 precedes this.

Martin


Am Mittwoch, dem 05.07.2023 um 13:34 +0200 schrieb David Brown:
> 
> 
> On 05/07/2023 11:25, Martin Uecker wrote:
> > Am Mittwoch, dem 05.07.2023 um 11:11 +0200 schrieb David Brown:
> > > On 05/07/2023 10:05, Rafał Pietrak via Gcc wrote:
> > 
> > ...
> > > 
> > > In my personal opinion (which you are all free to disregard),
> > > named
> > > address spaces were an interesting idea that failed.  I was
> > > enthusiastic
> > > about a number of the extensions in TR 18307 "C Extensions to
> > > support
> > > embedded processors" when the paper was first published.  As I
> > > learned
> > > more, however, I saw it was a dead-end.  The features are too
> > > under-specified to be useful or portable, gave very little of use
> > > to
> > > embedded programmers, and fit badly with C.  It was an attempt to
> > > standardise and generalise some of the mess of different
> > > extensions
> > > that
> > > proprietary toolchain developers had for a variety of 8-bit CISC
> > > microcontrollers that could not use standard C very effectively. 
> > > But
> > > it
> > > was all too little, too late - and AFAIK none of these
> > > proprietary
> > > toolchains support it.  GCC supports some of the features to some
> > > extent
> > > - a few named address spaces on a few devices, for "gnuc" only
> > > (not
> > > standard C, and not C++), and has some fixed point support for
> > > some
> > > targets (with inefficient generated code - it appears to be
> > > little
> > > more
> > > than an initial "proof of concept" implementation).
> > > 
> > > I do not think named address spaces have a future - in GCC or
> > > anywhere
> > > else.  The only real use of them at the moment is for the AVR for
> > > accessing data in flash, and even then it is of limited success
> > > since
> > > it
> > > does not work in C++.
> > 
> > Can you explain a little bit why you think it is a dead-end?  It
> > seems an elegant solution to a range of problems to me.
> 
> Named address spaces are not standardised in C, and I do not expect
> they 
> ever will be.  The TR18307 document is not anywhere close to being of
> a 
> quality that could be integrated with the C standards, even as
> optional 
> features, and much of it makes no sense in practice (I have never
> heard 
> of the IO stuff being implemented or used).
> 
> The few compilers that implement any of it do so in different ways -
> the 
> "__flash" address space in AVR GCC is slightly different from the
> same 
> extension in IAR's AVR compiler.  For existing compilers, there is a 
> strong inconsistency as to whether such things are "named address 
> spaces", "extension keywords", "type qualifiers", "attributes", or
> other 
> terms, all with subtly (or not so subtly) different effects on how
> they 
> are used, what restrictions exist, conversions between types, and how
> errors can be diagnosed.  Sometimes these features are considered
> part 
> of the data type, sometimes of pointer types, sometimes they are just
> about data placement.
> 
> Since every compiler targeting these small awkward microcontrollers
> has 
> a different idea of what something like "const __flash int x = 123;" 
> means, and has been implementing their own ideas for a decade or two 
> before TR18307 ever proposed "named address spaces", the TR hasn't a 
> hope of being a real standard.
> 
> Named address spaces are not implemented at all, anywhere (AFAIK),
> for 
> C++.  (Some embedded toolchains have limited support for C++ on such 
> microcontrollers, but these are again not really named address
> spaces.) 
> Since C++ usage is heavily increasing in the small embedded system 
> world, this is important.  (GCC has much of the honour for that - as
> ARM 
> took a bigger share of the market and GCC for ARM improved, the 
> toolchain market was no longer at the mercy of big commercial vendors
> who charged absurd amounts for their C++ toolchains.)  A feature
> which 
> is only for C, and not supported by C++, is almost guaranteed to be 
> dead-end.
> 
> And of course the type of processor for which named address spaces or
> other related extensions are essential, are a dying breed.  The AVR
> is 
> probably the only one with a significant future.  Part of the appeal
> of 
> ARM in the embedded world is it frees you from the pains of 
> target-specific coding with some of your data in "near" memory, some
> in 
> "extended" memory, some in "flash" address spaces or "IO" address 
> spaces.  It all works with standard C or C++.  The same applies to 
> challengers like RISC-V, MIP

Re: wishlist: support for shorter pointers

[Rafał Pietrak via Gcc]

Hi,

W dniu 5.07.2023 o 13:55, David Brown pisze:

On 05/07/2023 11:42, Rafał Pietrak via Gcc wrote:

[--]
Wouldn't it be easier and more natural to make the "named spaces" a 
synonym to specific linker sections (like section names, or section 
name prefix when instead of ".data.array.*" one gets 
".mynamespace.array.*")?


You can, of course, write :

#define __smalldata __attribute__((section(".smalldata)))

I'd rather see the "section" attribute extended to allow it to specify a 
prefix or suffix (to make subsections) than more named address spaces.


me to. (pun not intended :)

I'm a big fan of only putting things in the compiler if they have to be 
there - if a feature can be expressed in code (whether it be C, C++, or 
preprocessor macros), then I see that as the best choice.


Fully agree. ... almost fully.

I'd rather say: "I'm a big fun of being able to tell the compiler what I 
mean, but leave functionality/algorithms in libs".


And I think this has some resonance to our discussion. I think, that as 
of today, C-sources (though the compiler) don't have enough "vocabulary" 
to tell the linker "what we mean", and so the ability to "select flash 
vs RAM" or "one RAM vs another" is limited. The compiler/linker language 
is pretty much limited to resolved/unresolved names and their binding to 
linker segments like you've pointed above.


[]
But let's have look at it. You say, that "names spaces affect 
allocation details, which cannot be done with C++". Pls consider:
1. for small embedded devices C++ is not a particularly "seller". We 
even turn to assembler occasionally.


I have been writing code for small embedded systems for about 30 years. 
I used to write a lot in assembly, but it is very rare now.  Almost all 
of the assembly I write these days is inline assembly in gcc format - 
and a lot of that actually contains no assembly at all, but is for 
careful control of dependencies or code re-arrangements.  The smallest 
device I have ever used was an AVR Tiny with no ram at all - just 2K 
flash, a 3-level return stack and its 32 8-bit registers.  I programmed 
that in C (with gcc).


Well, similar here, although not that intensive (hobby, not profession). 
Still, I've never touched the Tiny, as I wasn't able to wrap my head 
around those limited resources for anything more then a blinker.


[--]
Allocation control is certainly important at times, but it's far from 
being as commonly needed as you suggest.


(Dynamic allocation is a different matter, but I don't believe we are 
talking about that here.)


yes, not about that.



So your current objections to named spaces ... are in fact in favor of 
them. Isn't it so?




Not really, no - I would rather see better ways to handle allocation and 
section control than more named address spaces.


Doesn't it call for "something" that a c-source (through the compiler) 
can express to the linker programmers' intention?


-R

Re: wishlist: support for shorter pointers

[David Brown via Gcc]

On 05/07/2023 14:25, Rafał Pietrak wrote:

Hi,

W dniu 5.07.2023 o 13:55, David Brown pisze:

On 05/07/2023 11:42, Rafał Pietrak via Gcc wrote:

[--]

So your current objections to named spaces ... are in fact in favor 
of them. Isn't it so?




Not really, no - I would rather see better ways to handle allocation 
and section control than more named address spaces.


Doesn't it call for "something" that a c-source (through the compiler) 
can express to the linker programmers' intention?




Yes, I think that is fair to say.  And that "something" should be more 
advanced and flexible than the limited "section" attribute we have 
today.  But I don't think it should be "named address spaces".


My objection to named address spaces stem from two points:

1. They are compiler implementations, not user code (or library code), 
which means development is inevitably much slower and less flexible.


2. They mix two concepts that are actually quite separate - how objects 
are allocated, and how they are accessed.


Access to different types of object in different sorts of memory can be 
done today.  In C, you can use inline functions or macros.  For 
target-specific stuff you can use inline assembly, and GCC might have 
builtins for some target-specific features.  In C++, you can also wrap 
things in classes if that makes more sense.


Allocation is currently controlled by "section" attributes.  This is 
where we I believe GCC could do better, and give the user more control. 
(It may be possible to develop a compiler-independent syntax here that 
could become part of future C and C++ standards, but I think it will 
unavoidably be heavily implementation dependent.)


All we really need is a way to combine these with types to improve user 
convenience and reduce the risk of mistakes.  And I believe that 
allowing allocation control attributes to be attached to types would 
give us that in GCC.  Then it would all be user code - typedefs, macros, 
functions, classes, whatever suits.


David

Re: Warning specifically for a returning noreturn

[Julian Waters via Gcc]

Hi Jonathan,

Thanks for the reply, is there a place in gcc's source code I could look at
for this? As for the returning an explicit value from noreturn, I'm
unfortunately not the one who wrote the code that way; I'm merely a build
systems developer trying to get it to work with gcc :/

best regards,
Julian

On Wed, 5 Jul 2023, 19:26 Jonathan Wakely,  wrote:

> On Wed, 5 Jul 2023 at 12:01, Julian Waters via Gcc 
> wrote:
> >
> > I see, thanks Andrew.
> >
> > Anyone else have opinions on this besides Liu or Andrew? The responses
> have
> > been surprisingly quiet thus far
>
> IMHO all warnings should have an option controlling them, so that you
> can disable them via pragmas.
>
> But I agree that you shouldn't need to return from a noreturn
> function, it can either throw or use __builtin_unreachable() on the
> line where you currently return.
>
>
> >
> > best regards,
> > Julian
> >
> > On Wed, 5 Jul 2023, 09:40 Andrew Pinski,  wrote:
> >
> > > 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
> unreachable
> > > code path. Does the unreachable builtin cover that case too?
> > >
> > > 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 function to have a return type
> > > other than void.
> > > ```
> > >
> > > Thanks,
> > > Andrew Pinski
> > >
> > >
> > > >
> > > > best regards.
> > > > Julian
> > > >
> > > > On Wed, Jul 5, 2023 at 9:07 AM Andrew Pinski 
> wrote:
> > > >>
> > > >> On Tue, Jul 4, 2023 at 5:54 PM Julian Waters via Gcc <
> gcc@gcc.gnu.org>
> > > 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
> > > calling
> > > >> > something like std::abort() at the end, when one wants all other
> > > -Wall and
> > > >> > -Wextra warnings to be reported, for instance in the Java HotSpot
> VM
> > > (which
> > > >> > I'm currently adapting to compile with gcc on all supported
> > > platforms). Is
> > > >> > there a possibility we can add a disable warning option
> specifically
> > > for
> > > >> > this case? Something like -Wno-returning-noreturn. I'm interested
> in
> > > adding
> > > >> > this myself if it's not convenient for gcc's maintainers to do so
> at
> > > the
> > > >> > moment, but I'd need some guidance on where to look and what the
> > > relevant
> > > >> > code is
> > > >>
> > > >> You could just add
> > > >> __builtin_unreachable(); (or std::unreachable(); if you are C++23 or
> > > >> unreachable() if you are using C23).
> > > >> Or even add while(true) ;
> > > >>
> > > >> I am pretty sure not having an option is on purpose and not really
> > > >> interested in adding an option here because of the above
> workarounds.
> > > >>
> > > >> Thanks,
> > > >> Andrew Pinski
> > > >>
> > > >> >
> > > >> > best regards,
> > > >> > Julian
> > >
>

Re: [RFC] Bridging the gap between the Linux Kernel Memory Consistency Model (LKMM) and C11/C++11 atomics

[Mathieu Desnoyers via Gcc]

On 7/5/23 03:05, Boqun Feng wrote:

On Mon, Jul 03, 2023 at 03:20:31PM -0400, Olivier Dion wrote:
[...]

NOTE: On x86-64, we found at least one corner case [7] with Clang where
a RELEASE exchange is optimized to a RELEASE store, when the returned
value of the exchange is unused, breaking the above expectations.
Although this type of optimization respect the standard "as-if"
statement, we question its pertinence since a user should simply do a
RELEASE store instead of an exchange in that case.  With the
introduction of these new primitives, these type of optimizations should
be revisited.



FWIW, this is actually a LLVM bug:

https://github.com/llvm/llvm-project/issues/60418


So it was more than a dubious optimization, it's actually broken as well.

I am worried about adding to the compiler's ability to optimize those 
atomics because of the subtle corner-cases/bugs that can creep up.


Thanks,

Mathieu


--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com

Re: Warning specifically for a returning noreturn

[Jonathan Wakely via Gcc]

On Wed, 5 Jul 2023, 14:13 Julian Waters,  wrote:

> Hi Jonathan,
>
> Thanks for the reply, is there a place in gcc's source code I could look
> at for this?
>

This is a commit where I added four new warnings, and then changed the code
that issues those warnings to use the new OPT_Wxxx variables:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ee336ecb2a7161bc28f6c5343d97870a8d15e177
You would want you do something similar. Define a warning in c.opt, then
find where that warning is printed and change the 0 to
OPT_Wreturn_in_noreturn (or whatever you call the new flag).

More generally, new options go in gcc/c-fsmily/c.opt so there are several
examples of adding new warnings in the history for that file:
https://gcc.gnu.org/git/?p=gcc.git;a=history;f=gcc/c-family/c.opt;h=4abdc8d0e77c6bded20829e35ac550c3a1b994dd;hb=refs/heads/master


As for the returning an explicit value from noreturn, I'm unfortunately not
> the one who wrote the code that way; I'm merely a build systems developer
> trying to get it to work with gcc :/
>
> best regards,
> Julian
>
> On Wed, 5 Jul 2023, 19:26 Jonathan Wakely,  wrote:
>
>> On Wed, 5 Jul 2023 at 12:01, Julian Waters via Gcc 
>> wrote:
>> >
>> > I see, thanks Andrew.
>> >
>> > Anyone else have opinions on this besides Liu or Andrew? The responses
>> have
>> > been surprisingly quiet thus far
>>
>> IMHO all warnings should have an option controlling them, so that you
>> can disable them via pragmas.
>>
>> But I agree that you shouldn't need to return from a noreturn
>> function, it can either throw or use __builtin_unreachable() on the
>> line where you currently return.
>>
>>
>> >
>> > best regards,
>> > Julian
>> >
>> > On Wed, 5 Jul 2023, 09:40 Andrew Pinski,  wrote:
>> >
>> > > 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
>> unreachable
>> > > code path. Does the unreachable builtin cover that case too?
>> > >
>> > > 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 function to have a return type
>> > > other than void.
>> > > ```
>> > >
>> > > Thanks,
>> > > Andrew Pinski
>> > >
>> > >
>> > > >
>> > > > best regards.
>> > > > Julian
>> > > >
>> > > > On Wed, Jul 5, 2023 at 9:07 AM Andrew Pinski 
>> wrote:
>> > > >>
>> > > >> On Tue, Jul 4, 2023 at 5:54 PM Julian Waters via Gcc <
>> gcc@gcc.gnu.org>
>> > > 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
>> > > calling
>> > > >> > something like std::abort() at the end, when one wants all other
>> > > -Wall and
>> > > >> > -Wextra warnings to be reported, for instance in the Java
>> HotSpot VM
>> > > (which
>> > > >> > I'm currently adapting to compile with gcc on all supported
>> > > platforms). Is
>> > > >> > there a possibility we can add a disable warning option
>> specifically
>> > > for
>> > > >> > this case? Something like -Wno-returning-noreturn. I'm
>> interested in
>> > > adding
>> > > >> > this myself if it's not convenient for gcc's maintainers to do
>> so at
>> > > the
>> > > >> > moment, but I'd need some guidance on where to look and what the
>> > > relevant
>> > > >> > code is
>> > > >>
>> > > >> You could just add
>> > > >> __builtin_unreachable(); (or std::unreachable(); if you are C++23
>> or
>> > > >> unreachable() if you are using C23).
>> > > >> Or even add while(true) ;
>> > > >>
>> > > >> I am pretty sure not having an option is on purpose and not really
>> > > >> interested in adding an option here because of the above
>> workarounds.
>> > > >>
>> > > >> Thanks,
>> > > >> Andrew Pinski
>> > > >>
>> > > >> >
>> > > >> > best regards,
>> > > >> > Julian
>> > >
>>
>

Re: wishlist: support for shorter pointers

[Rafał Pietrak via Gcc]

Hi,


W dniu 5.07.2023 o 14:57, David Brown pisze:
[]


My objection to named address spaces stem from two points:

1. They are compiler implementations, not user code (or library code), 
which means development is inevitably much slower and less flexible.


2. They mix two concepts that are actually quite separate - how objects 
are allocated, and how they are accessed.


OK. I don't see a problem here, but I admit that mixing semantics often 
lead to problems.


Access to different types of object in different sorts of memory can be 
done today.  In C, you can use inline functions or macros.  For 
target-specific stuff you can use inline assembly, and GCC might have 
builtins for some target-specific features.  In C++, you can also wrap 
things in classes if that makes more sense.


Personally, I'd avoid inline assembly whenever possible. It does a very 
good job of obfuscating programmers' intentions. From my experience, I'd 
rather put the entire functions into assembler if compiler makes obstacles.


But that's not an issue here.

Allocation is currently controlled by "section" attributes.  This is 
where we I believe GCC could do better, and give the user more control. 
(It may be possible to develop a compiler-independent syntax here that 
could become part of future C and C++ standards, but I think it will 
unavoidably be heavily implementation dependent.)


I agree.



All we really need is a way to combine these with types to improve user 
convenience and reduce the risk of mistakes.  And I believe that 
allowing allocation control attributes to be attached to types would 
give us that in GCC.  Then it would all be user code - typedefs, macros, 
functions, classes, whatever suits.


OK. Sounds good.

Naturally I have my "wishlist": the "small pointers" segment/attribute :)

But how (and to what extend) would you do that? I mean, the convenient 
syntax is desirable, but IMHO at this point there is also a question of 
semantics: what exactly compiler is supposed to tell linker? I think it 
would be good to list here the use scenarios that we now of. Scenarios 
that would benefit from compiler communicating to linker more then 
names@sections. (even if such list wouldn't evolve into any 
implementation effort at this point I think that would nicely conclude 
this thread.)


-R

Re: wishlist: support for shorter pointers

[David Brown via Gcc]

On 05/07/2023 15:29, Rafał Pietrak wrote:

Hi,


W dniu 5.07.2023 o 14:57, David Brown pisze:
[]


My objection to named address spaces stem from two points:

1. They are compiler implementations, not user code (or library code), 
which means development is inevitably much slower and less flexible.


2. They mix two concepts that are actually quite separate - how 
objects are allocated, and how they are accessed.


OK. I don't see a problem here, but I admit that mixing semantics often 
lead to problems.




I think it also allows better generalisation and flexibility if they are 
separate.  You might want careful control over where something is 
allocated, but the access would be using normal instructions. 
Conversely, you might not be bothered about where the data is allocated, 
but want control of access (maybe you want interrupts disabled around 
accesses to make it atomic).


Access to different types of object in different sorts of memory can 
be done today.  In C, you can use inline functions or macros.  For 
target-specific stuff you can use inline assembly, and GCC might have 
builtins for some target-specific features.  In C++, you can also wrap 
things in classes if that makes more sense.


Personally, I'd avoid inline assembly whenever possible. It does a very 
good job of obfuscating programmers' intentions. From my experience, I'd 
rather put the entire functions into assembler if compiler makes obstacles.




I'd rather keep the assembly to a minimum, and let the compiler do what 
it is good at - such as register allocation.  That means extended syntax 
inline assembly (but typically wrapped inside a small inline function).



But that's not an issue here.


Agreed.



Allocation is currently controlled by "section" attributes.  This is 
where we I believe GCC could do better, and give the user more 
control. (It may be possible to develop a compiler-independent syntax 
here that could become part of future C and C++ standards, but I think 
it will unavoidably be heavily implementation dependent.)


I agree.



All we really need is a way to combine these with types to improve 
user convenience and reduce the risk of mistakes.  And I believe that 
allowing allocation control attributes to be attached to types would 
give us that in GCC.  Then it would all be user code - typedefs, 
macros, functions, classes, whatever suits.


OK. Sounds good.

Naturally I have my "wishlist": the "small pointers" segment/attribute :)

But how (and to what extend) would you do that? I mean, the convenient 
syntax is desirable, but IMHO at this point there is also a question of 
semantics: what exactly compiler is supposed to tell linker? I think it 
would be good to list here the use scenarios that we now of. Scenarios 
that would benefit from compiler communicating to linker more then 
names@sections. (even if such list wouldn't evolve into any 
implementation effort at this point I think that would nicely conclude 
this thread.)




Let me try to list some things I think might be useful (there may be 
some overlap).  I am not giving any particular order here.


1. Adding a prefix to section names rather than replacing them.

2. Adding a suffix to section names.

3. Constructing section names at compile time, rather that just using a 
string literal.  (String literals can be constructed using the 
pre-processor, but that has its limitations.)


4. Pragmas to apply section names (or prefixes or suffixes) to a block 
of definitions, changing the defaults.


5. Control of section flags (such as read-only, executable, etc.).  At 
the moment, flags are added automatically depending on what you put into 
the section (code, data, read-only data).  So if you want to override 
these, such as to make a data section in ram that is executable (for 
your JIT compiler :-) ), you need something like :


__attribute__((section("jit_buffer,\"ax\"\n@")))

to add the flags manually, then a newline, then a line comment character 
(@ for ARM, but this varies according to target.)


6. Convenient support for non-initialised non-zeroed data sections in a 
standardised way, without having to specify sections manually in the 
source and linker setup.


7. Convenient support for sections (or variables) placed at specific 
addresses, in a standardised way.


8. Convenient support for sections that are not allocated space by the 
linker in the target memory, but where the contents are still included 
in the elf file and map files, where they can be read by other tools. 
(This could be used for external analysis tools.)


9. Support for getting data from the linker to the code, such as section 
sizes and start addresses, without having to manually add the symbols to 
the linker file and declare extern symbols in the C or C++ code.


10. Support for structs (or C++ classes) where different parts of the 
struct are in different sections.  This would mean the struct could only 
be statically allocated (no stack allocati

[RFC] Exposing complex numbers to target backends

[Sylvain Noiry via Gcc]

Hi,

My name is Sylvain, I am an intern at Kalray and I work on improving the GCC 
backend for the KVX target.  The KVX ISA has dedicated instructions for the 
handling of complex numbers, which cannot be selected by GCC due to how complex 
numbers are handled internally.  My goal is to make GCC able to expose to 
machine description files new patterns dealing with complex numbers.  I already 
have a proof of concept which can increase performance even on other backends 
like x86 if the new patterns are implemented.

My approach is to prevent the lowering of complex operations when the backend 
can handle it natively and work directly on complex modes (SC, DC, CDI, CSI, 
CHI, CQI).  The cplxlower pass looks for supported optabs related to complex 
numbers and use them directly.  Another advantage is that native operations can 
now go through all GIMPLE passes and preserve most optimisations like FMA 
generation.

Vectorization is also preserved with native complex operands, although some 
functions were updated. Because vectorization assumes that inner elements are 
scalar and complex cannot be considered as scalar, some functions which only 
take scalars have been adapted or duplicated to handle complex elements.

I've also changed the representation of complex numbers during the expand pass. 
 READ_COMPLEX_PART and WRITE_COMPLEX_PART have been transformed into target 
hooks, and a new hook GEN_RTX_COMPLEX allows each backend to choose its 
preferred complex representation in RTL.  The default one uses CONCAT like 
before, but the KVX backend uses registers with complex mode containing both 
real and imaginary parts.

Now each backend can add its own native complex operations with patterns in its 
machine description. The following example implements a complex multiplication 
with mode SC on the KVX backend:
(define_insn "mulsc3"
  [(set (match_operand:SC 0 "register_operand" "=r")
        (mult:SC (match_operand:SC 1 "register_operand" "r")
                 (match_operand:SC 2 "register_operand" "r")))]
  ""
  "fmulwc %0 = %1, %2"
  [(set_attr "type" "mau_fpu")]
)

The main patch affects around 1400 lines of generic code, mostly located in 
expr.cc and tree-complex.cc. These are mainly additions or the result of the 
move of READ_COMPLEX_PART and WRITE_COMPLEX_PART from expr.cc to target hooks.

I know that ARM developers have added partial support of complex instructions.  
However, since they are operating during the vectorization, and are promoting 
operations on vectors of floating point numbers that looks like operations on 
(vectors of) complex numbers, their approach misses simple cases.  At this 
point they create operations working on vector of floating point numbers which 
will be caught by dedicated define_expand later.  On the other hand, our 
approach propagates complex numbers through all the middle-end and we have an 
easier time to recombine the operations and recognize what ARM does.  Some 
choices will be needed to merge our two approaches, although I've already 
reused their work on complex rotations in my implementation.

Results:

I have tested my implementation on multiple code samples, as well as a few 
FFTs.  On a simple in-place radix-2 with precomputed twiddle seeds (2 complex 
mult, 1 add, and 1 sub per loop), the compute time has been divided by 3 when 
compiling with -O3 (because calls to __mulsc3 are replaced by native 
instructions) and shortened by 20% with -ffast-math.  In both cases, the 
achieved performance level is now on par with another version coded using 
intrinsics.  These improvements do not come exclusively from the new generated 
hardware instructions, the replacement of CONCATs to registers prevents GCC 
from generating instructions to extract the real and imaginary part into their 
own registers and recombine them later.

This new approach can also brings a performance uplift to other backends.  I 
have tried to reuse the same complex representation in rtl as KVX for x86, and 
a few patterns.  Although I still have useless moves on large programs, simple 
examples like below already show performance uplift.

_Complex float add(_Complex float a, _Complex float b)
{
  return a + b;
}

Using "-O2" the assembly produced is now on paar with llvm and looks like :

add:
        addps  %xmm1, %xmm0
        ret

Choices to be done:
  - Currently, ARM uses optab which start with "c" like "cmul" to distinguish 
between a real floating point numbers and complex numbers.  Since we keep 
complex mode, this could be simply done with mul.
  - Currently the parser does some early optimizations and lowering that could 
be moved into the cplxlower pass.  For example, i've changed a bit how complex 
rotations by 90° and 270° are processed, which are recognized in fold-const.cc. 
 A call to a new COMPLEX_ROT90/270 internal function is now inserted, which is 
then lowered or kept in the cplxlower pass.  Finally the widening_mul pass can 
generate COMPLEX_ADD_ROT90/270 internal fu

Re: wishlist: support for shorter pointers

[Rafał Pietrak via Gcc]

Hi,

W dniu 5.07.2023 o 16:45, David Brown pisze:

On 05/07/2023 15:29, Rafał Pietrak wrote:

[---]
OK. I don't see a problem here, but I admit that mixing semantics 
often lead to problems.




I think it also allows better generalisation and flexibility if they are 
separate.  You might want careful control over where something is 
allocated, but the access would be using normal instructions. 
Conversely, you might not be bothered about where the data is allocated, 
but want control of access (maybe you want interrupts disabled around 
accesses to make it atomic).


that would require compiler to know the "semantics" of such section. I 
don't think you've listed it below, worth adding. If I understand you 
correctly, that means the code generated varies depending on target 
section selected. This is linker "talking" to compiler if I'm not mistaken.


but OK. I see your point.

[--]
Let me try to list some things I think might be useful (there may be 
some overlap).  I am not giving any particular order here.


1. Adding a prefix to section names rather than replacing them.


OK. +1


2. Adding a suffix to section names.


+1

3. Constructing section names at compile time, rather that just using a 
string literal.  (String literals can be constructed using the 
pre-processor, but that has its limitations.)


I'm not sure what this means? At compile time, you only have literals, 
so what's missing?


4. Pragmas to apply section names (or prefixes or suffixes) to a block 
of definitions, changing the defaults.


+1

5. Control of section flags (such as read-only, executable, etc.).  At 
the moment, flags are added automatically depending on what you put into 
the section (code, data, read-only data).  So if you want to override 
these, such as to make a data section in ram that is executable (for 
your JIT compiler :-) ), you need something like :


 __attribute__((section("jit_buffer,\"ax\"\n@")))


I assume, that adding an attribute should split a particular section 
into "an old one" and "the new one with new attribute", right?


One would need to have linker logic (and linker script definitions) 
altered, to follow that (other features so far wouldn't require any 
changes to linkers, I think).


to add the flags manually, then a newline, then a line comment character 
(@ for ARM, but this varies according to target.)


6. Convenient support for non-initialised non-zeroed data sections in a 
standardised way, without having to specify sections manually in the 
source and linker setup.


What gain and under which circumstances you get with this? I mean, why 
enforce keeping uninitialized memory fragment, while that is just a one 
shot action at load time?


7. Convenient support for sections (or variables) placed at specific 
addresses, in a standardised way.


Hmm... Frankly, I'm quite comfortable with current features of linker 
script, and I do it like this:

SECTIONS
{
sfr_devices 0x4000 (NOLOAD): {
. = ALIGN(1K);  PROVIDE(TIM2 =  .);
. = 0x00400;PROVIDE(TIM3 =  .);
. = 0x00800;PROVIDE(TIM4 =  .);
}
}

The only problem is that so far I'm not aware of command line options to 
"supplement" default linker script with such fragment. Option "-T" 
replaces it, which is a nuisance.


8. Convenient support for sections that are not allocated space by the 
linker in the target memory, but where the contents are still included 
in the elf file and map files, where they can be read by other tools. 
(This could be used for external analysis tools.)


Isn't it so, that current debugger sections are just that?

Extrapolating your words: Do you think of sections that you would have 
full control on it's content at compilation, and it isn't sufficient to 
do it like this:

char private[] __attribute__((section("something"))) = {
 0xFF, 0x01, 0x02, 
};

9. Support for getting data from the linker to the code, such as section 
sizes and start addresses, without having to manually add the symbols to 
the linker file and declare extern symbols in the C or C++ code.


+1

10. Support for structs (or C++ classes) where different parts of the 
struct are in different sections.  This would mean the struct could only 
be statically allocated (no stack allocation - just global or static), 
and it would have no accessible address or size (you could have pointers 
to fields, but not to the struct objects themselves).  This would let 
you tie together objects made of multiple parts such as constant data in 
flash and writeable data in ram.


+1

11. Convenient support for building up tables where the contents are 
scattered across different source files, without having to manually edit 
the linker files.


do you have an example where that is useful?

12. I'd supplement the list with a better control on code section names 
towards something like code namespaces.


13. and data sections "growing downwords" like stack does. This

Re: Warning specifically for a returning noreturn

[Eric Gallager via Gcc]

On Wed, Jul 5, 2023 at 7:28 AM Jonathan Wakely via Gcc  wrote:
>
> On Wed, 5 Jul 2023 at 12:01, Julian Waters via Gcc  wrote:
> >
> > I see, thanks Andrew.
> >
> > Anyone else have opinions on this besides Liu or Andrew? The responses have
> > been surprisingly quiet thus far
>
> IMHO all warnings should have an option controlling them, so that you
> can disable them via pragmas.
>

This is bug 44209, for reference:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209

> But I agree that you shouldn't need to return from a noreturn
> function, it can either throw or use __builtin_unreachable() on the
> line where you currently return.
>
>
> >
> > best regards,
> > Julian
> >
> > On Wed, 5 Jul 2023, 09:40 Andrew Pinski,  wrote:
> >
> > > 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 
> > > unreachable
> > > code path. Does the unreachable builtin cover that case too?
> > >
> > > 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 function to have a return type
> > > other than void.
> > > ```
> > >
> > > Thanks,
> > > Andrew Pinski
> > >
> > >
> > > >
> > > > best regards.
> > > > Julian
> > > >
> > > > On Wed, Jul 5, 2023 at 9:07 AM Andrew Pinski  wrote:
> > > >>
> > > >> 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
> > > calling
> > > >> > something like std::abort() at the end, when one wants all other
> > > -Wall and
> > > >> > -Wextra warnings to be reported, for instance in the Java HotSpot VM
> > > (which
> > > >> > I'm currently adapting to compile with gcc on all supported
> > > platforms). Is
> > > >> > there a possibility we can add a disable warning option specifically
> > > for
> > > >> > this case? Something like -Wno-returning-noreturn. I'm interested in
> > > adding
> > > >> > this myself if it's not convenient for gcc's maintainers to do so at
> > > the
> > > >> > moment, but I'd need some guidance on where to look and what the
> > > relevant
> > > >> > code is
> > > >>
> > > >> You could just add
> > > >> __builtin_unreachable(); (or std::unreachable(); if you are C++23 or
> > > >> unreachable() if you are using C23).
> > > >> Or even add while(true) ;
> > > >>
> > > >> I am pretty sure not having an option is on purpose and not really
> > > >> interested in adding an option here because of the above workarounds.
> > > >>
> > > >> Thanks,
> > > >> Andrew Pinski
> > > >>
> > > >> >
> > > >> > best regards,
> > > >> > Julian
> > >

Re: wishlist: support for shorter pointers

[David Brown via Gcc]

On 05/07/2023 18:13, Rafał Pietrak via Gcc wrote:

Hi,

W dniu 5.07.2023 o 16:45, David Brown pisze:

On 05/07/2023 15:29, Rafał Pietrak wrote:

[---]
OK. I don't see a problem here, but I admit that mixing semantics 
often lead to problems.




I think it also allows better generalisation and flexibility if they 
are separate.  You might want careful control over where something is 
allocated, but the access would be using normal instructions. 
Conversely, you might not be bothered about where the data is 
allocated, but want control of access (maybe you want interrupts 
disabled around accesses to make it atomic).


that would require compiler to know the "semantics" of such section. I 
don't think you've listed it below, worth adding. If I understand you 
correctly, that means the code generated varies depending on target 
section selected. This is linker "talking" to compiler if I'm not mistaken.




No, it's about the access - not the allocation (or section).  Access 
boils down to a "read" function and a "write" function (or possibly 
several, optimised for different sizes - C11 _Generic can make this 
neater, though C++ handles it better).




[--]
Let me try to list some things I think might be useful (there may be 
some overlap).  I am not giving any particular order here.


1. Adding a prefix to section names rather than replacing them.


OK. +1


2. Adding a suffix to section names.


+1

3. Constructing section names at compile time, rather that just using 
a string literal.  (String literals can be constructed using the 
pre-processor, but that has its limitations.)


I'm not sure what this means? At compile time, you only have literals, 
so what's missing?


The compiler knows a lot more than just literal values at compile time - 
lots of things are "compile-time constants" without being literals that 
can be used in string literals.  That includes the value of static 
"const" variables, and the results of calculations or "pure" function 
calls using compile-time constant data.  You can do a great deal more of 
this in C++ than in C ("static const int N = 10; int arr[N];" is valid 
in C++, but not in C).  Calculated section names might be useful for 
sections that later need to be sorted.


To be fair, you can construct string literals by the preprocessor that 
would cover many cases.


I can also add that generating linker symbols from compile-time 
constructed names could be useful, to use (abuse?) the linker to find 
issues across different source files.  Imagine you have a 
microcontroller with multiple timers, and several sources that all need 
to use timers.  A module that uses timer 1 could define a 
"using_timer_1" symbol for link time (but with no allocation to real 
memory).  Another module might use timer 2 and define "using_timer_2". 
If a third module uses timer 1 again, then you'd get a link-time error 
with two conflicting definitions of "use_timer_1" and you'd know you 
have to change one of the modules.




4. Pragmas to apply section names (or prefixes or suffixes) to a block 
of definitions, changing the defaults.


+1

5. Control of section flags (such as read-only, executable, etc.).  At 
the moment, flags are added automatically depending on what you put 
into the section (code, data, read-only data).  So if you want to 
override these, such as to make a data section in ram that is 
executable (for your JIT compiler :-) ), you need something like :


 __attribute__((section("jit_buffer,\"ax\"\n@")))


I assume, that adding an attribute should split a particular section 
into "an old one" and "the new one with new attribute", right?


You can't have the same section name and multiple flags.  But you 
sometimes want to have unusual flag combinations, such as executable ram 
sections for "run from ram" functions.




One would need to have linker logic (and linker script definitions) 
altered, to follow that (other features so far wouldn't require any 
changes to linkers, I think).


to add the flags manually, then a newline, then a line comment 
character (@ for ARM, but this varies according to target.)


6. Convenient support for non-initialised non-zeroed data sections in 
a standardised way, without having to specify sections manually in the 
source and linker setup.


What gain and under which circumstances you get with this? I mean, why 
enforce keeping uninitialized memory fragment, while that is just a one 
shot action at load time?




Very often you have buffers in your programs, which you want to have 
statically allocated in ram (so they have a fixed address, perhaps 
specially aligned, and so you have a full overview of your memory usage 
in your map files), but you don't care about the contents at startup. 
Clearing these to 0 is just a waste of processor time.



7. Convenient support for sections (or variables) placed at specific 
addresses, in a standardised way.


Hmm... Frankly, I'm quite comfortable with current features of link

Re: [RFC] Exposing complex numbers to target backends

[Toon Moene]

On 7/5/23 17:12, Sylvain Noiry via Gcc wrote:


Hi,

My name is Sylvain, I am an intern at Kalray and I work on improving the GCC 
backend for the KVX target.  The KVX ISA has dedicated instructions for the 
handling of complex numbers, which cannot be selected by GCC due to how complex 
numbers are handled internally.  My goal is to make GCC able to expose to 
machine description files new patterns dealing with complex numbers.  I already 
have a proof of concept which can increase performance even on other backends 
like x86 if the new patterns are implemented.


I do not have the expertise to evaluate if your approach is the way we 
want to go forward with the handling of complex numbers in the 
middle-/back-end(s) of GCC.


However, I *do* have a sizable amount of (Fortran) code over here that 
uses complex numbers in a day to day operation that I am willing to test 
(obviously, "day to day operation" is to be interpreted loosely here - 
what I do is following the *real* operation at my employer (KNMI) with 
my own weather forecasting computations at home, compiled with GCC).


I suppose that your patch is against the master branch of GCC's 
repository - so I'll have to test that first, cleanly.


Kind regards,

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands

Stepping down as maintainer for ARC and Epiphany

[Joern Rennecke]

I haven't worked with these targets in years and can't really do sensible 
maintenance or reviews of patches for them.
I am currently working on optimizations for other ports like RISC-V.

ARC has still an active maintainer in Claudiu Zissulescu, so is basically 
unaffected.
I am not aware of any ongoing development of or for Epiphany. We might consider 
depreciating it unless there are other takers.

I would like to downgrade my status to general write-after-approval for now.

I tried to do this myself, but there seems to be a problem with my 
authenticated git access; I've already sent an email to overseers.

Re: Stepping down as maintainer for ARC and Epiphany

[Richard Biener via Gcc]

On Wed, Jul 5, 2023 at 8:44 PM Joern Rennecke  wrote:
>
> I haven't worked with these targets in years and can't really do sensible 
> maintenance or reviews of patches for them.
> I am currently working on optimizations for other ports like RISC-V.
>
> ARC has still an active maintainer in Claudiu Zissulescu, so is basically 
> unaffected.
> I am not aware of any ongoing development of or for Epiphany. We might 
> consider depreciating it unless there are other takers.

Thanks for your work on these targets in the past.  It looks like
epiphany is using LRA already so
it wouldn't be on the chopping block immediately unless it is broken
for other reasons.

Richard.

> I would like to downgrade my status to general write-after-approval for now.
>
> I tried to do this myself, but there seems to be a problem with my 
> authenticated git access; I've already sent an email to overseers.
>
>