Re: wishlist: support for shorter pointers

[Rafał Pietrak via Gcc]

Hi,

W dniu 5.07.2023 o 19:39, David Brown pisze:
[--]
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 


const --> created by a literal.

calls using compile-time constant data.  You can do a great deal more of 


"compile time constant data" -> literal

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.


OK. We are talking of convenience syntax that allows for using any 
"name" in c-sources as "const-literal" if only its rooted in literals 
only. That's useful.


+2. :)



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 


+1

microcontroller with multiple timers, and several sources that all need 
to use timers.  A module that uses timer 1 could define a 

[--]


 __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.


section flags reflect "semantic" of the section (ro v.s. rw is different 
semantics at that level). So, how do you "merge" RAM (a section called 
".data"), one with "!x" flag, and the other with "x" flag?


conflicting flags of sections with the same name have to be taken into 
consideration.






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.


At startup? Really? Personally I wouldn't care if I waste those cycles.

And having that explicitly "vocalized" in sources, I think it'll just 
make them harder to read by a maintainer.


Otherwise, from my personal experience, it may or may not be desirable.




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.


These are ugly and hard to maintain in practice - the most common way to 
give fixed addresses is to use macros that cast the fixed address to 
pointers to volatile objects and structs.


Yes, I know that macros are traditionally used here, but personally I 
think using them is just hideous. I'm using the above section 
definitions for years and they keep my c-sources nice and clean. And (in 
particular with stm32) if I change the target device, I just change the 
linker script and don't usually have to change the sources. That's 
really nice. It's like efortless porting.


Having said that. I'm opened to suggestion how to get this better - like 
having a compiler "talk to linker" about those locations.




But sometimes it is nice to have sections at specific addresses, and it 
would be a significant gain for most people if these could be defined 
entirely in C (or C++), without editing linker files.  Many embedded 
toolchains support such features - "int reg @ 0x1234;", or similar 
syntax.  gcc has an "address" attribute for the AVR, but not as a common 
a

Re: [RFC] Exposing complex numbers to target backends

[Richard Biener via Gcc]

On Wed, Jul 5, 2023 at 5:14 PM 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.
>
> 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.

I'll note that complex lowering takes advantage of complex numbers
without real/imag parts, I suppose you are preseving some
of these optimizations and only prevent lowering of ops we natively
support.  I think that's a reasonable thing and I agree the
standard optabs should be used with complex modes.

> 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 don't quite understand whether you end up with vectors with complex
components or vectors with twice the number of
scalar elements, implicitely representing real/imag parts interleaved.
Can you clarify?  We've recently had discussions
around this and agreed we don't want vector modes with complex component modes.

> 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, _Co

Re: wishlist: support for shorter pointers

[David Brown via Gcc]

On 06/07/2023 09:00, Rafał Pietrak via Gcc wrote:

Hi,

W dniu 5.07.2023 o 19:39, David Brown pisze:
[--]
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 


const --> created by a literal.


Technically in C, the only "literals" are "string literals".  Something 
like 1234 is an integer constant, not a literal.  But I don't want to 
get too deep into such standardese - especially not for C++ !


Even in C, there are lots of things that are known at compile time 
without being literals (or explicit constants).  In many situations you 
can use "constant expressions", which includes basic arithmetic on 
constants, enumeration constants, etc.  The restrictions on what can be 
used in different circumstances is not always obvious (if you have 
"static const N = 10;", then "static const M = N + 1;" is valid but "int 
xs[N];" is not).


C++ has a very much wider concept of constant expressions at compile 
time - many more ways to make constant expressions, and many more ways 
to use them.  But even there, the compiler will know things at compile 
time that are not syntactically constant in the language.  (If you have 
code in a function "if (x < 0) return; bool b = (x >= 0);" then the 
compiler can optimise in the knowledge that "b" is a compile-time 
constant of "true".)





calls using compile-time constant data.  You can do a great deal more of 


"compile time constant data" -> literal

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.


OK. We are talking of convenience syntax that allows for using any 
"name" in c-sources as "const-literal" if only its rooted in literals 
only. That's useful.


+2. :)



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 


+1

microcontroller with multiple timers, and several sources that all 
need to use timers.  A module that uses timer 1 could define a 

[--]


 __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.


section flags reflect "semantic" of the section (ro v.s. rw is different 
semantics at that level). So, how do you "merge" RAM (a section called 
".data"), one with "!x" flag, and the other with "x" flag?


conflicting flags of sections with the same name have to be taken into 
consideration.




It doesn't make sense to merge linker input sections with conflicting 
flags - this is (and should be) an error at link time.  So I am not 
asking for a way to make a piece of ".data" section with different flags 
from the standard ".data" section - I am asking about nicer ways to make 
different sections with different selections of flags.  (Input sections 
with different flags can be merged into one output section, as the 
semantic information is lost there.)






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.


At startup? Really? Personally I wouldn't care if I waste those cycles.



Usually it is not an issue, but it can be for some systems.  I've seen 
systems where a hardware watchdog has timed out while the startup code 
is clearing large buffers unnecessarily.  There are also some low-power 
systems that a

Regarding bypass-asm patch and help in an error during bootstrapped build

[Rishi Raj via Gcc]

Hi,

I have added the patch (
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623379.html ) on the
devel/bypass-asm branch.
Although I am able to build using the --disable-bootstrap option but while
doing a bootstrapped build, I am getting these errors ( as warnings while
doing the non-bootstrapped build.)

In file included from ../../gcc/gcc/lto-object.cc:23:0:
../../gcc/gcc/is-a.h:196:22: error: inline function ‘static bool
is_a_helper::test(U*) [with U = symtab_node; T = cgraph_node*]’ used but
never defined [enabled by default]
   static inline bool test (U *p);

  ^
../../gcc/gcc/is-a.h:196:22: error: inline function ‘static bool
is_a_helper::test(U*) [with U = symtab_node; T = varpool_node*]’ used
but never defined [enabled by default]


In file included from ../../gcc/gcc/coretypes.h:489:0,
 from ../../gcc/gcc/lto/lto-lang.cc:23:
../../gcc/gcc/is-a.h:196:22: error inline function ‘static bool
is_a_helper::test(U*) [with U = symtab_node; T = cgraph_node*]’ used but
never defined [enabled by default]
   static inline bool test (U *p);
  ^
../../gcc/gcc/is-a.h:196:22: error inline function ‘static bool
is_a_helper::test(U*) [with U = symtab_node; T = varpool_node*]’ used
but never defined [enabled by default]

I have tested the .symtab and dummy symbols addition on the
non-bootstrapped build, and they are working fine. I also ran the lto test
suite, and it passed as expected. I am looking into the error produced
during bootstrapped build currently. I would appreciate any help/guidance
regarding this.

--
Regards
Rishi

Re: [RFC] Exposing complex numbers to target backends

[Sylvain Noiry via Gcc]

From: Richard Biener 
Sent: Thursday, July 6, 2023 1:02 PM
To: Sylvain Noiry 
Cc: gcc@gcc.gnu.org ; Paul Iannetta ; 
Benoit Dinechin 
Subject: Re: [RFC] Exposing complex numbers to target backends

On Wed, Jul 5, 2023 at 5:14 PM 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.
>>
>> 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.

>I'll note that complex lowering takes advantage of complex numbers
>without real/imag parts, I suppose you are preseving some
>of these optimizations and only prevent lowering of ops we natively
>support.  I think that's a reasonable thing and I agree the
>standard optabs should be used with complex modes.

Native complex operations are kept only if there is an optab for it,
otherwise, it will be lowered. In addition, we keep the three components
of each constant and SSA variables at any time during this pass (real, imag, 
both),
so that it's now easy to mix lowered and non-lowered operations. Later dead code
elimination passes remove the unused components.

Thus, complex handling remains exactly the same for backend without complex
patterns and the target hooks redefined (READ_COMPLEX_PART, WRITE_COMPLEX_PART,
 GEN_RTX_COMPLEX).

>> 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 don't quite understand whether you end up with vectors with complex
>components or vectors with twice the number of
>scalar elements, implicitely representing real/imag parts interleaved.
>Can you clarify?  We've recently had discussions
>around this and agreed we don't want vector modes with complex component modes.

Yes, I end up with vectors of complex inner types (like V2SC or V4CHI).
Except for the few functions that I've adapted, the vectorization pass works 
fine.
For example, if both mulsc and mulv2sc patterns are present in the backend,
a complex multiplication can be vectorized without any effort. But of course
this approach is in conflict with Arm's previous work, where my V2SC is a V4SF
for them.

>> 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 need

Re: Regarding bypass-asm patch and help in an error during bootstrapped build

[Jan Hubicka via Gcc]

> Hi,
> 
> I have added the patch (
> https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623379.html ) on the
> devel/bypass-asm branch.
> Although I am able to build using the --disable-bootstrap option but while
> doing a bootstrapped build, I am getting these errors ( as warnings while
> doing the non-bootstrapped build.)
> 
> In file included from ../../gcc/gcc/lto-object.cc:23:0:
> ../../gcc/gcc/is-a.h:196:22: error: inline function ‘static bool
> is_a_helper::test(U*) [with U = symtab_node; T = cgraph_node*]’ used but
> never defined [enabled by default]
>static inline bool test (U *p);
> 
>   ^
> ../../gcc/gcc/is-a.h:196:22: error: inline function ‘static bool
> is_a_helper::test(U*) [with U = symtab_node; T = varpool_node*]’ used
> but never defined [enabled by default]
> 
> 
> In file included from ../../gcc/gcc/coretypes.h:489:0,
>  from ../../gcc/gcc/lto/lto-lang.cc:23:
> ../../gcc/gcc/is-a.h:196:22: error inline function ‘static bool
> is_a_helper::test(U*) [with U = symtab_node; T = cgraph_node*]’ used but
> never defined [enabled by default]
>static inline bool test (U *p);
>   ^
> ../../gcc/gcc/is-a.h:196:22: error inline function ‘static bool
> is_a_helper::test(U*) [with U = symtab_node; T = varpool_node*]’ used
> but never defined [enabled by default]
> 
> I have tested the .symtab and dummy symbols addition on the
> non-bootstrapped build, and they are working fine. I also ran the lto test
> suite, and it passed as expected. I am looking into the error produced
> during bootstrapped build currently. I would appreciate any help/guidance
> regarding this.
This is because you miss some #inline or you do these in wrong order
(at some point it was decided to drop most #inlines inside header files,
so one needs to always do the transitive closure by  hand which is quite
anoying).

This is a conversion helper from cgraph_node to symtab_node, so pehraps
you need to include cgraph.h?

Honza
> 
> --
> Regards
> Rishi

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

[Olivier Dion via Gcc]

On Tue, 04 Jul 2023, Alan Stern  wrote:
> 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:
[...]
> Oh, is that it?  Then I misunderstood entirely; I thought you were 
> talking about augmenting the set of functions or macros made available 
> in liburcu.  I did not realize you intended to change the compilers.

Yes.  We want to extend the atomic builtins API of the toolchains.

>> Indeed, our intent is to discuss the Userspace RCU uatomic API by extending
>> the toolchain's atomic builtins and not the LKMM itself.  The reason why
>> we've reached out to the Linux kernel developers is because the
>> original Userspace RCU uatomic API is based on the LKMM.
>
> But why do you want to change the compilers to better support urcu?  
> That seems like going about things backward; wouldn't it make more sense 
> to change urcu to better match the facilities offered by the current 
> compilers?

The initial motivation for the migration of the Userspace RCU atomics
API from custom inline assembler (mimicking the LKMM) to the C11/C++11
memory model was for supporting userspace tools such as TSAN.

We did that by porting everything to the compiler's atomic builtins API.
However, because of the "fully-ordered" atomic semantic of the LKMM, we
had no other choices than to add memory fences which are redundant on
some strongly ordered architectures.

> What if everybody started to do this: modifying the compilers to better 
> support their pet projects?  The end result would be chaos!

This is why we are starting this discussion which involves members of
the Kernel and toolchains communities.  We have prior experience, e.g. with
asm gotos which were implemented in GCC, and Clang afterward, in
response to Linux Kernel tracepoint's requirements.

Note that the motivation for supporting TSAN in Userspace RCU is coming
from the requirements of the ISC for the BIND 9 project.

[...]
>> If we go for the grouping in a), we have to take into account that the
>> barriers emitted need to cover the worse case scenario.  As an example,
>> Clang can emit a store for a exchange with SEQ_CST on x86-64, if the
>> returned value is not used.
>> 
>> Therefore, for the grouping in a), all RMW would need to emit a memory
>> barrier (with Clang on x86-64).  But with the scheme in b), we can emit
>> the barrier explicitly for the exchange operation.  We however question
>> the usefulness of this kind of optimization made by the compiler, since
>> a user should use a store operation instead.
>
> So in the end you settled on a compromise?

We have not settled on anything yet.  Choosing between options a) and b)
is open to discussion.

[...]


Thanks,
Olivier
-- 
Olivier Dion
EfficiOS Inc.
https://www.efficios.com

Inquiry about SME support for gcov modifications

[Daria Shatalinska via Gcc]

Hello,

My name is Daria Shatalinska and I am a Project Manager at Freelancer. I am
contacting you to see if you might be interested in collaborating with us
on a project for NASA's Open Innovation Services program (NOIS2). As an
awardee of the $175 million NOIS2 contract ,
we are one of a few approved vendors by NASA Tournament Labs to work on
this opportunity.


We received a new project from NASA's Orion Avionics, Power, and Software
(APS) Office that seeks to modify the open source GNU Coverage (gcov)
project to explicitly measure and report Modified Condition/Decision
Coverage (MC/DC). Many different NASA projects, including the Orion
Multipurpose Crew Vehicle (MPCV), use the gcc compiler and the gcov
profiling tool to provide coverage metrics for Unit Tests. NPR 7150.2
standards now require full MC/DC analysis and 100% coverage. Adding MC/DC
capability to gcov will benefit software development on many NASA programs
and projects across all mission directorates.


We are looking for someone from the GCC team to serve as a subject matter
expert for the software developer that will be executing this project. The
role as the subject matter expert (SME) would be to provide your knowledge
and expertise to help us and NASA develop the necessary modifications
that will meet the standards of contribution to the gcov project.


Is there anyone from the team who would be interested to partner with us on
this project? If this is something you are unable to assist with, is there
anyone you could recommend that might be suited to this project?

Thank you and best regards,

*Daria Shatalinska*
Project Manager, Freelancer Enterprise
Freelancer.com
[image: Freelancer logo] 

abi

[André Albergaria Coelho via Gcc]

Could gcc have an option to specify ABI?

say


gcc something.c -g -abi 1 -o something


thanks


andre

Re: abi

[Paul Koning via Gcc]

It does, for machine architectures that have multiple ABIs.  MIPS is an example 
where GCC has supported this for at least 20 years.

paul

> On Jul 6, 2023, at 5:19 PM, André Albergaria Coelho via Gcc  
> wrote:
> 
> Could gcc have an option to specify ABI?
> 
> say
> 
> 
> gcc something.c -g -abi 1 -o something
> 
> 
> thanks
> 
> 
> andre
> 

Re: abi

[Jonathan Wakely via Gcc]

On Thu, 6 Jul 2023, 22:20 André Albergaria Coelho via Gcc, 
wrote:

> Could gcc have an option to specify ABI?
>
> say
>
>
> gcc something.c -g -abi 1 -o something
>

Sure, it could do, but what would it do? What would "-abi 1" mean? Which
ABI would it relate to?

What are you actually asking about?

user sets ABI

[André Albergaria Coelho via Gcc]

What if the user chooses in own ABI, say specifying a config file like

My abi

" Parameters = pushed in stack"


say

gcc -abi "My abi" some.c -o some

what would be the problems of specifying an ABI?? would that improve the 
usage of user? less complex / more


simpler for user (say user is used to code asm in a way)


thanks

later


andre

gcc-11-20230706 is now available

[GCC Administrator via Gcc]

Snapshot gcc-11-20230706 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20230706/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-11 revision 25ad73ecf3976abe4a2c36c337e4185d1beb1624

You'll find:

 gcc-11-20230706.tar.xz   Complete GCC

  SHA256=5bf70423620934e90a5cd69d1a5458f59ee7f6e8b8e63e0effcbdbe2022db1d2
  SHA1=cdab10e96c10feb2b97956ce55e6649dcdcff960

Diffs from 11-20230629 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-11
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

semantics of uninitialized values in GIMPLE

[Krister Walfridsson via Gcc]

I have implemented support for uninitialized memory in my translation 
validator. But I am not sure how well this corresponds to the GIMPLE 
semantics, so I have some questions...


My implementation tracks uninitialized bits. Use of uninitialized bits is 
in general treated as UB (for example, `x + y` is UB if `x` or `y` has any 
uninitialized bits), but there are a few exceptions:


 * load/store: It is always OK to load/store values having uninitialized
   bits.
 * Phi nodes: Phi nodes propagates uninitialized bits.
 * selection: Instructions that are selecting an element (COND_EXPR,
   VEC_PERM_EXPR, etc.) may select between values having uninitialized
   bits, and the resulting value may have uninitialized bits. But the
   condition/mask must not have uninitialized bits.
 * Extraction: Instructions that are extracting bits (BIT_FIELD_REF etc.)
   may have uninitialized bits in both the input/output.
 * Insertion: Instructions that are constructing/inserting values
   (COMPLEX_EXPR, etc.) may have uninitialized bits in both the
   input/output.

All other use of values having uninitialized bits are considered UB.

Does this behavior make sense?

The above seems to work fine so far, with one exception that can be seen 
in gcc.c-torture/execute/pr108498-1.c. The test has an uninitialized bit 
field


  unsigned char c6:1, c7:1, c8:1, c9:3, c10:1;

which is written to as

  x.c6 = 0;
  x.c7 = 0;
  x.c8 = 0;
  x.c9 = 7;

The store merging pass changes this to

  _71 = MEM  [(struct C *)&x + 8B];
  _42 = _71 & 128;
  _45 = _42 | 56;

and the translation validator is now complaining that the pass has 
introduced UB that was not in the original IR (because the most 
significant bit in _71 is uninitialized when passed to BIT_AND_EXPR).


I could solve this by allowing uninitialized bits in BIT_AND_EXPR and 
BIT_OR_EXP, and propagating each bit according to


  * `0 & uninit` is an initialized `0`
  * `1 & uninit` is uninitialized
  * `0 | uninit` is uninitialized
  * `1 | uninit` is an initialized `1`

Is that the correct GIMPLE semantics?

   /Krister

Re: Stepping down as maintainer for ARC and Epiphany

[Jeff Law via Gcc]

On 7/5/23 12:43, 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.
I've suggested deprecating Epiphany in the past as it would fault in 
reload after seemingly innocuous changes in the IL making run to run 
comparisons of the testsuite virtually impossible.


I did convert to LRA.  But I didn't check to see if that brought 
stability to the testsuite though.


jeff

Re: Regarding bypass-asm patch and help in an error during bootstrapped build

[Rishi Raj via Gcc]

Yup,  I somehow missed it. Thanks, it is fixed now. Now we can test the
addition of.symtab and symbols in both builds.
Now I am moving toward the second part of the project, adding debugging
information. Right now, I am going through the documentation.
Will you recommend any other resources?

--
Rishi

On Thu, 6 Jul 2023 at 20:40, Jan Hubicka  wrote:

> > Hi,
> >
> > I have added the patch (
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623379.html ) on the
> > devel/bypass-asm branch.
> > Although I am able to build using the --disable-bootstrap option but
> while
> > doing a bootstrapped build, I am getting these errors ( as warnings while
> > doing the non-bootstrapped build.)
> >
> > In file included from ../../gcc/gcc/lto-object.cc:23:0:
> > ../../gcc/gcc/is-a.h:196:22: error: inline function ‘static bool
> > is_a_helper::test(U*) [with U = symtab_node; T = cgraph_node*]’ used
> but
> > never defined [enabled by default]
> >static inline bool test (U *p);
> >
> >   ^
> > ../../gcc/gcc/is-a.h:196:22: error: inline function ‘static bool
> > is_a_helper::test(U*) [with U = symtab_node; T = varpool_node*]’ used
> > but never defined [enabled by default]
> >
> >
> > In file included from ../../gcc/gcc/coretypes.h:489:0,
> >  from ../../gcc/gcc/lto/lto-lang.cc:23:
> > ../../gcc/gcc/is-a.h:196:22: error inline function ‘static bool
> > is_a_helper::test(U*) [with U = symtab_node; T = cgraph_node*]’ used
> but
> > never defined [enabled by default]
> >static inline bool test (U *p);
> >   ^
> > ../../gcc/gcc/is-a.h:196:22: error inline function ‘static bool
> > is_a_helper::test(U*) [with U = symtab_node; T = varpool_node*]’ used
> > but never defined [enabled by default]
> >
> > I have tested the .symtab and dummy symbols addition on the
> > non-bootstrapped build, and they are working fine. I also ran the lto
> test
> > suite, and it passed as expected. I am looking into the error produced
> > during bootstrapped build currently. I would appreciate any help/guidance
> > regarding this.
> This is because you miss some #inline or you do these in wrong order
> (at some point it was decided to drop most #inlines inside header files,
> so one needs to always do the transitive closure by  hand which is quite
> anoying).
>
> This is a conversion helper from cgraph_node to symtab_node, so pehraps
> you need to include cgraph.h?
>
> Honza
> >
> > --
> > Regards
> > Rishi
>

Re: semantics of uninitialized values in GIMPLE

[Richard Biener via Gcc]

On Fri, Jul 7, 2023 at 1:23 AM Krister Walfridsson via Gcc
 wrote:
>
> I have implemented support for uninitialized memory in my translation
> validator. But I am not sure how well this corresponds to the GIMPLE
> semantics, so I have some questions...
>
> My implementation tracks uninitialized bits. Use of uninitialized bits is
> in general treated as UB (for example, `x + y` is UB if `x` or `y` has any
> uninitialized bits), but there are a few exceptions:
>
>   * load/store: It is always OK to load/store values having uninitialized
> bits.
>   * Phi nodes: Phi nodes propagates uninitialized bits.

definitely, I think plain copies would be OK as well

>   * selection: Instructions that are selecting an element (COND_EXPR,
> VEC_PERM_EXPR, etc.) may select between values having uninitialized
> bits, and the resulting value may have uninitialized bits. But the
> condition/mask must not have uninitialized bits.
>   * Extraction: Instructions that are extracting bits (BIT_FIELD_REF etc.)
> may have uninitialized bits in both the input/output.
>   * Insertion: Instructions that are constructing/inserting values
> (COMPLEX_EXPR, etc.) may have uninitialized bits in both the
> input/output.

Generally I think "moving" uninitialized bits in full or in part is OK.
Operating on them, including comparing them (with themselves)
is eventually asking for troubles.

> All other use of values having uninitialized bits are considered UB.
>
> Does this behavior make sense?
>
> The above seems to work fine so far, with one exception that can be seen
> in gcc.c-torture/execute/pr108498-1.c. The test has an uninitialized bit
> field
>
>unsigned char c6:1, c7:1, c8:1, c9:3, c10:1;
>
> which is written to as
>
>x.c6 = 0;
>x.c7 = 0;
>x.c8 = 0;
>x.c9 = 7;
>
> The store merging pass changes this to
>
>_71 = MEM  [(struct C *)&x + 8B];
>_42 = _71 & 128;
>_45 = _42 | 56;
>
> and the translation validator is now complaining that the pass has
> introduced UB that was not in the original IR (because the most
> significant bit in _71 is uninitialized when passed to BIT_AND_EXPR).
>
> I could solve this by allowing uninitialized bits in BIT_AND_EXPR and
> BIT_OR_EXP, and propagating each bit according to
>
>* `0 & uninit` is an initialized `0`
>* `1 & uninit` is uninitialized
>* `0 | uninit` is uninitialized
>* `1 | uninit` is an initialized `1`
>
> Is that the correct GIMPLE semantics?

I think the above "moves" the uninitialized MSB from memory to _45 so
that's OK.

Some "operations" like & 0 or & 1 give either defined values or
take the uninitialized bit unmodified (thus "move").  I think both
kinds are OK.  Likewise + 0 or * 0/1 would be OK.  What's not
OK is operations that use an (fully?) uninitialized value twice,
like x - x when x is uninitialized.

I think we want that, as soon as the uninitialized value becomes
"part" of a then partly initialized value, it's value is "fixed".
With things like _Complex or vector the situation is a bit
of a grey area since we have ways to operate on elements.

Note that when we for example use a BIT_FIELD_REF to extract
the MSB from _42 above the value would be again fully undefined.

I hope this makes some sense, it's a tricky area.

Richard.

>
> /Krister