Re: GCC 10.5 Released

[Richard Stallman via Gcc]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Congratulations on the new release.  May it be as boring as we hope.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

gcc-12-20230707 is now available

[GCC Administrator via Gcc]

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

This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-12 revision 0444c2065aef569aa16e43cffc564c202a59af33

You'll find:

 gcc-12-20230707.tar.xz   Complete GCC

  SHA256=6932b40b20499d9912fe0c0703f2bb581581482ec23e4e3d2981a6184bcafd54
  SHA1=813fa6f0fd3198d3e12b7e1eae807a4a3a2e2b8c

Diffs from 12-20230630 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-12
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.

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

[Olivier Dion via Gcc]

On Fri, 07 Jul 2023, Jonas Oberhauser  wrote:
[...]
>> This is a request for comments on extending the atomic builtins API to
>> help avoiding redundant memory barriers.  Indeed, there are
>> discrepancies between the Linux kernel consistency memory model (LKMM)
>> and the C11/C++11 memory consistency model [0].  For example,
>> fully-ordered atomic operations like xchg and cmpxchg success in LKMM
>> have implicit memory barriers before/after the operations [1-2], while
>> atomic operations using the __ATOMIC_SEQ_CST memory order in C11/C++11
>> do not have any ordering guarantees of an atomic thread fence
>> __ATOMIC_SEQ_CST with respect to other non-SEQ_CST operations [3].
>
>
> The issues run quite a bit deeper than this. The two models have two
> completely different perspectives that are quite much incompatible.

Agreed.  Our intent is not to close the gap completely, but to reduce
the gap between the two models, by supporting the "full barrier
before/after" semantic of LKMM in the C11/C++11 memory model.

> I think all you can really do is bridge the gap at the level of the
> generated assembly.  I.e., don't bridge the gap between LKMM and the
> C11 MCM. Bridge the gap between the assembly code generated by C11
> atomics and the one generated by LKMM. But I'm not sure that's really
> the task here.

We have considered analyzing the assembler output of different
toolchain's versions to generate manually our own before/after fences.
However, nothing prevents a toolchain from changing the emitted
assembler in the future, which would make things fragile.  The only
thing that is guaranteed to not change is the definitions in the
standard (C11/C++11).  Anything else is fair game for optimizations.

>> [...] For example, to make Read-Modify-Write (RMW) operations match
>> the Linux kernel "full barrier before/after" semantics, the liburcu's
>> uatomic API has to emit both a SEQ_CST RMW operation and a subsequent
>> thread fence SEQ_CST, which leads to duplicated barriers in some cases.
>
> Does it have to though? Can't you just do e.g. an release RMW
> operation followed by an after_atomic  fence?  And for loads, a
> SEQ_CST fence followed by an acquire load? Analogously (but: mirrored)
> for stores.

That would not improve anything for RMW.  Consider the following example
and its resulting assembler on x86-64 gcc 13.1 -O2:

int exchange(int *x, int y)
{
int r = __atomic_exchange_n(x, y, __ATOMIC_RELEASE);
__atomic_thread_fence(__ATOMIC_SEQ_CST);

return r;
}

exchange:
movl%esi, %eax
xchgl   (%rdi), %eax
lock orq $0, (%rsp) ;; Redundant with previous exchange
ret

also that would make the exchange weaker, in the sense of the C11/C++11
memory model, by losing its acquire and its sequential consistency
semantics.

[...]
>> // Always NOP.
>>__atomic_thread_fence_{before,after}_rmw(int rmw_memorder,
>> int fence_memorder)
>
>
> I currently don't feel comfortable adding such extensions to LKMM (or a 
> compiler API for that matter).

There's no plan to add such extensions to LKMM but only to extend the
current atomic builtins API of toolchains.

> You mentioned that the goal is to check some code written using LKMM
> primitives with TSAN due to some formal requirements. What exactly do
> these requirements entail? Do you need to check the code exactly as it
> will be executed (modulo the TSAN instrumentation)? Is it an option to
> map to normal builtins with suboptimal performance just for the
> verification purpose, but then run the slightly more optimized
> original code later?

We aim to validate with TSAN the code that will run during production,
minus TSAN itself.

> Specifically for TSAN's ordering requirements, you may need to make
> LKMM's RMWs into acq+rel with an extra mb, even if all that extra
> ordering isn't necessary at the assembler level.
>
>
> Also note that no matter what you do, due to the two different
> perspectives, TSAN's hb relation may introduce false positive data
> races w.r.t. LKMM.  For example, if the happens-before ordering is
> guaranteed through pb starting with coe/fre.

This is why we have implemented our primitives and changed our
algorithms so that they use the acquire/release semantics of the
C11/C++11 memory model.

> Without thinking too hard, it seems to me no matter what fences and
> barriers you introduce, TSAN will not see this kind of ordering and
> consider the situation a data race.

We have come to the same conclusion, mainly because TSAN does not
support thread fence in its verifications.  This is why we have
implemented an annotation layer that group relaxed memory accesses into
a single acquire/release event.  This layer, makes TSAN aware of the
happen-before relations of the RCU implementations -- and lock-free data
structures -- in Userspace RCU.

This came with

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

[Peter Zijlstra]

On Fri, Jul 07, 2023 at 10:04:06AM -0400, Olivier Dion wrote:
> On Tue, 04 Jul 2023, Peter Zijlstra  wrote:
> > On Mon, Jul 03, 2023 at 03:20:31PM -0400, Olivier Dion wrote:
> [...]
> >> On x86-64 (gcc 13.1 -O2) we get:
> >> 
> >>   t0():
> >>   movl$1, x(%rip)
> >>   movl$1, %eax
> >>   xchgl   dummy(%rip), %eax
> >>   lock orq $0, (%rsp)   ;; Redundant with previous exchange.
> >>   movly(%rip), %eax
> >>   movl%eax, r0(%rip)
> >>   ret
> >>   t1():
> >>   movl$1, y(%rip)
> >>   lock orq $0, (%rsp)
> >>   movlx(%rip), %eax
> >>   movl%eax, r1(%rip)
> >>   ret
> >
> > So I would expect the compilers to do better here. It should know those
> > __atomic_thread_fence() thingies are superfluous and simply not emit
> > them. This could even be done as a peephole pass later, where it sees
> > consecutive atomic ops and the second being a no-op.
> 
> Indeed, a peephole optimization could work for this Dekker, if the
> compiler adds the pattern for it.  However, AFAIK, a peephole can not be
> applied when the two fences are in different basic blocks.  For example,
> only emitting a fence on a compare_exchange success.  This limitation
> implies that the optimization can not be done across functions/modules
> (shared libraries).

LTO FTW :-)

> For example, it would be interesting to be able to
> promote an acquire fence of a pthread_mutex_lock() to a full fence on
> weakly ordered architectures while preventing a redundant fence on
> strongly ordered architectures.

That's a very non-trivial thing to do. I know Linux has
smp_mb__after_spinlock() and that x86 has it a no-op, but even on x86
adding a full fence after a lock has observable differences IIRC.

Specifically, the actual store that acquires the lock is not well
ordered vs the critical section itself for non-trivial spinlock
implementations (notably qspinlock).

For RCU you mostly care about RCsc locks (IIRC), and upgrading unlock is
a 'simpler' (IMO) approach to achieve that (which is what RCU does with
smp_mb_after_unlock_lock()).

> We know that at least Clang has such peephole optimizations for some
> architecture backends.  It seems however that they do not recognize
> lock-prefixed instructions as fence.

They seem confused in general for emitting MFENCE.

> AFAIK, GCC does not have that kind
> of optimization.

> We are also aware that some research has been done on this topic [0].
> The idea is to use PRE for elimiation of redundant fences.  This would
> work across multiple basic blocks, although the paper focus on
> intra-procedural eliminations.  However, it seems that the latest work
> on that [1] has never been completed [2].
> 
> Our proposed approach provides a mean for the user to express -- and
> document -- the wanted semantic in the source code.  This allows the
> compiler to only emit wanted fences, therefore not relying on
> architecture specific backend optimizations.  In other words, this
> applies even on unoptimized binaries.

I'm not a tool person, but if I were, I'd be very hesitant to add
__builtin functions that 'conflict'/'overlap' with what an optimizer
should be able to do.

Either way around you need work done on the compilers, and I'm thinking
'fixing' the optimizer will benefit far more people than adding
__builtin's.

Then again, I'm not a tools person, so you don't need to convince me.
But one of the selling points of the whole Atomics as a language feature
was that whole optimizer angle. Otherwise you might as well do as we do,
inline asm the world.

I'll shut up now, thanks for that PRE reference [0], that seems a fun
read for when I'm bored.

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

[Mathieu Desnoyers via Gcc]

On 7/4/23 06:23, Jonathan Wakely wrote:

On Tue, 4 Jul 2023 at 10:47, Peter Zijlstra wrote:


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


   int x = 0;
   int y = 0;
   int r0, r1;

   int dummy;

   void t0(void)
   {
   __atomic_store_n(&x, 1, __ATOMIC_RELAXED);

   __atomic_exchange_n(&dummy, 1, __ATOMIC_SEQ_CST);
   __atomic_thread_fence(__ATOMIC_SEQ_CST);

   r0 = __atomic_load_n(&y, __ATOMIC_RELAXED);
   }

   void t1(void)
   {
   __atomic_store_n(&y, 1, __ATOMIC_RELAXED);
   __atomic_thread_fence(__ATOMIC_SEQ_CST);
   r1 = __atomic_load_n(&x, __ATOMIC_RELAXED);
   }

   // BUG_ON(r0 == 0 && r1 == 0)

On x86-64 (gcc 13.1 -O2) we get:

   t0():
   movl$1, x(%rip)
   movl$1, %eax
   xchgl   dummy(%rip), %eax
   lock orq $0, (%rsp)   ;; Redundant with previous exchange.
   movly(%rip), %eax
   movl%eax, r0(%rip)
   ret
   t1():
   movl$1, y(%rip)
   lock orq $0, (%rsp)
   movlx(%rip), %eax
   movl%eax, r1(%rip)
   ret


So I would expect the compilers to do better here. It should know those
__atomic_thread_fence() thingies are superfluous and simply not emit
them. This could even be done as a peephole pass later, where it sees
consecutive atomic ops and the second being a no-op.


Right, I don't see why we need a whole set of new built-ins that say
"this fence isn't needed if the adjacent atomic op already implies a
fence". If the adjacent atomic op already implies a fence for a given
ISA, then the compiler should already be able to elide the explicit
fence.

So just write your code with the explicit fence, and rely on the
compiler to optimize it properly. Admittedly, today's compilers don't
do that optimization well, but they also don't support your proposed
built-ins, so you're going to have to wait for compilers to make
improvements either way.


Emitting the redundant fences is the plan we have for liburcu.  The
current situation unfortunately requires users to choose between
generation of inefficient code with C11 or implement their own inline
assembler until the compilers catch up.



https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4455.html
discusses that compilers could (and should) optimize around atomics
better.


Our understanding of the C11/C++11 memory model is that it aims at
defining the weakest possible guarantees for each ordering to be as
efficient as possible on weakly ordered architectures.  However, when
writing portable code in practice, the C11/C++11 memory model force the
programmer to insert memory fences which are redundant on strongly
ordered architectures.

We want something that can apply across procedures from different
modules: e.g. a mutex lock operation (glibc) has an acquire semantic
using a RMW operation that the caller could promote to a full fence.
The peephole optimizations cannot do this because they focus on a single
basic block.  PRE can apply across procedures, but would rely on LTO and
possibly function annotation across modules.  I am not aware of any
progress in that research field in the past 6 years. [1-2]

The new atomic builtins we propose allow the user to better express its
intent to the compiler, allowing for better code generation.  Therefore,
reducing the number of emitted redundant fences, without having to rely on
optimizations.

It should be noted that the builtins extensions we propose are not
entirely free.  Here are our perceived downsides of introducing those
APIs:

- They add complexity to the atomic builtins API.

- They add constraints which need to be taken into account for future
  architecture-specific backend optimizations, as an example the (broken)
  xchg RELEASE | RELAXED -> store on x86 (Clang) [3].

  If an atomic op class (e.g. rmw) can be optimized to a weaker
  instruction by the architecture backend, then the emission of a
  before/after-fence associated with this class of atomic op, must be
  pessimistic and assume the weakest instruction pattern which can
  be generated.

There are optimizations of atomics and redundant fences in Clang.  The
redundant fences optimizations appear to be limited to a peephole, which
does not appear to leverage the fact that lock-prefixed atomic
operations act as implicit fences on x86.  Perhaps this could be a
low-hanging fruit for optimization.

We have not observed any similar optimizations in gcc as of today, which
appears to be a concern for many users. [4-7]

Thanks,

Mathieu

[1] https://dl.acm.org/doi/10.1145/3033019.3033021
[2] https://reviews.llvm.org/D5758
[3] https://github.com/llvm/llvm-project/issues/60418
[4] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86056
[5] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68622
[6] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86072
[7] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63273

--
Mathieu Desnoyers
EfficiOS Inc.
https://www.e

Policy about optimization of atomics

[Olivier Dion via Gcc]

Hi,

I would like to know what is the official stand of GCC on optimization
of atomic builtins?  More precisely, optimization of redundant memory
fences.

I am aware that Clang does some peephole optimization on redundant
fences, but this seem to be limited to a single basic block and does not
recognize lock-prefixed instructions as implicit memory fences on x86.

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

Re: Inquiry about SME support for gcov modifications

[Joel Sherrill]

Another related tool is mcdc-checker. This tool analyses code for
conditions that require mcdc analysis based on some research
that proves it isn't needed if the logic is properly structured. It can
suggest alternatives that avoid the need for mcdc analysis.
Research papers are linked there also.

https://gtd-gmbh.gitlab.io/mcdc-checker/mcdc-checker/index.html

For RTEMS, I've tried to encourage us to just avoid the need for
MCDC analysis for years. The tools to do the analysis were proprietary
and expensive.

All that said, I'm looking forward to gcov supporting mcdc. :)

--joel

On Fri, Jul 7, 2023 at 5:37 AM Richard Biener via Gcc 
wrote:

> On Thu, Jul 6, 2023 at 11:15 PM Daria Shatalinska via Gcc
>  wrote:
> >
> > 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 <
> https://www.freelancer.com/nasa>,
> > 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?
>
> I think Jørgen Kvalsvik  was working on
> this,
> you might want to get in touch with him (CCed).
>
> Richard.
>
> > Thank you and best regards,
> >
> > *Daria Shatalinska*
> > Project Manager, Freelancer Enterprise
> > Freelancer.com
> > [image: Freelancer logo] 
>

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, Peter Zijlstra  wrote:
> On Mon, Jul 03, 2023 at 03:20:31PM -0400, Olivier Dion wrote:
[...]
>> On x86-64 (gcc 13.1 -O2) we get:
>> 
>>   t0():
>>   movl$1, x(%rip)
>>   movl$1, %eax
>>   xchgl   dummy(%rip), %eax
>>   lock orq $0, (%rsp)   ;; Redundant with previous exchange.
>>   movly(%rip), %eax
>>   movl%eax, r0(%rip)
>>   ret
>>   t1():
>>   movl$1, y(%rip)
>>   lock orq $0, (%rsp)
>>   movlx(%rip), %eax
>>   movl%eax, r1(%rip)
>>   ret
>
> So I would expect the compilers to do better here. It should know those
> __atomic_thread_fence() thingies are superfluous and simply not emit
> them. This could even be done as a peephole pass later, where it sees
> consecutive atomic ops and the second being a no-op.

Indeed, a peephole optimization could work for this Dekker, if the
compiler adds the pattern for it.  However, AFAIK, a peephole can not be
applied when the two fences are in different basic blocks.  For example,
only emitting a fence on a compare_exchange success.  This limitation
implies that the optimization can not be done across functions/modules
(shared libraries).  For example, it would be interesting to be able to
promote an acquire fence of a pthread_mutex_lock() to a full fence on
weakly ordered architectures while preventing a redundant fence on
strongly ordered architectures.

We know that at least Clang has such peephole optimizations for some
architecture backends.  It seems however that they do not recognize
lock-prefixed instructions as fence.  AFAIK, GCC does not have that kind
of optimization.

We are also aware that some research has been done on this topic [0].
The idea is to use PRE for elimiation of redundant fences.  This would
work across multiple basic blocks, although the paper focus on
intra-procedural eliminations.  However, it seems that the latest work
on that [1] has never been completed [2].

Our proposed approach provides a mean for the user to express -- and
document -- the wanted semantic in the source code.  This allows the
compiler to only emit wanted fences, therefore not relying on
architecture specific backend optimizations.  In other words, this
applies even on unoptimized binaries.

[...]

Thanks,
Olivier

  [0] https://dl.acm.org/doi/10.1145/3033019.3033021

  [1] https://discourse.llvm.org/t/fence-elimination-pass-proposal/33679

  [2] https://reviews.llvm.org/D5758
-- 
Olivier Dion
EfficiOS Inc.
https://www.efficios.com

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

[Jonas Oberhauser]

Hi all,


Am 7/3/2023 um 9:20 PM schrieb Olivier Dion:

Hi all,

This is a request for comments on extending the atomic builtins API to
help avoiding redundant memory barriers.  Indeed, there are
discrepancies between the Linux kernel consistency memory model (LKMM)
and the C11/C++11 memory consistency model [0].  For example,
fully-ordered atomic operations like xchg and cmpxchg success in LKMM
have implicit memory barriers before/after the operations [1-2], while
atomic operations using the __ATOMIC_SEQ_CST memory order in C11/C++11
do not have any ordering guarantees of an atomic thread fence
__ATOMIC_SEQ_CST with respect to other non-SEQ_CST operations [3].



The issues run quite a bit deeper than this. The two models have two 
completely different perspectives that are quite much incompatible.
I think all you can really do is bridge the gap at the level of the 
generated assembly.
I.e., don't bridge the gap between LKMM and the C11 MCM. Bridge the gap 
between the assembly code generated by C11 atomics and the one generated 
by LKMM. But I'm not sure that's really the task here.





[...] For example, to make Read-Modify-Write (RMW) operations match
the Linux kernel "full barrier before/after" semantics, the liburcu's
uatomic API has to emit both a SEQ_CST RMW operation and a subsequent
thread fence SEQ_CST, which leads to duplicated barriers in some cases.



Does it have to though? Can't you just do e.g. an release RMW operation 
followed by an after_atomic  fence?
And for loads, a SEQ_CST fence followed by an acquire load? Analogously 
(but: mirrored) for stores.





   // Always emit thread fence.
   __atomic_thread_fence_{before,after}_load(int load_memorder,
 int fence_memorder)

   // NOP for store_memorder == SEQ_CST.
   // Otherwise, emit thread fence.
   __atomic_thread_fence_{before,after}_store(int store_memorder,
  int fence_memorder)

// NOP for clear_memorder == SEQ_CST.
// Otherwise, emit thread fence.
   __atomic_thread_fence_{before,after}_clear(int clear_memorder,
  int fence_memorder)

// Always NOP.
   __atomic_thread_fence_{before,after}_rmw(int rmw_memorder,
int fence_memorder)



I currently don't feel comfortable adding such extensions to LKMM (or a 
compiler API for that matter).



You mentioned that the goal is to check some code written using LKMM 
primitives with TSAN due to some formal requirements. What exactly do 
these requirements entail? Do you need to check the code exactly as it 
will be executed (modulo the TSAN instrumentation)? Is it an option to 
map to normal builtins with suboptimal performance just for the 
verification purpose, but then run the slightly more optimized original 
code later?


Specifically for TSAN's ordering requirements, you may need to make 
LKMM's RMWs into acq+rel with an extra mb, even if all that extra 
ordering isn't necessary at the assembler level.



Also note that no matter what you do, due to the two different 
perspectives, TSAN's hb relation may introduce false positive data races 
w.r.t. LKMM.  For example, if the happens-before ordering is guaranteed 
through pb starting with coe/fre.


Without thinking too hard, it seems to me no matter what fences and 
barriers you introduce, TSAN will not see this kind of ordering and 
consider the situation a data race.


(And at least in our own verification methodology for rcu/smr, ordering 
through fre appears when the rscs reads something that is later 
overwritten by the writer. Not sure off the top of my head if this fre 
ordering is what prevents the data race though, or there's some 
additional ordering that TSAN may also detect.


As a side note, according to LKMM we would also have data races in our 
critical sections, but I believe use of rcu_dereference would fix that, 
so you may not experience such data races in your code).



best wishes,
jonas

Re: Inquiry about SME support for gcov modifications

[Richard Biener via Gcc]

On Thu, Jul 6, 2023 at 11:15 PM Daria Shatalinska via Gcc
 wrote:
>
> 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?

I think Jørgen Kvalsvik  was working on this,
you might want to get in touch with him (CCed).

Richard.

> Thank you and best regards,
>
> *Daria Shatalinska*
> Project Manager, Freelancer Enterprise
> Freelancer.com
> [image: Freelancer logo] 

Re: user sets ABI

[David Brown via Gcc]

On 07/07/2023 00:27, André Albergaria Coelho via Gcc wrote:

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)




You can fiddle things a bit, using the -ffixed-reg, -fcall-used-reg and 
-fcall-saved-reg flags:




This is almost certainly a bad idea for most situations - you really 
have to have a special niche case to make it worth doing.  The register 
allocation algorithms in GCC are complex, and I would expect changing 
these settings would give you less efficient results.  And of course it 
will mess up all calls to any code compiled with different settings - 
such as library code.


A far better solution is for the user who is used to coding in assembly, 
to get used to coding in C, C++, or other languages supported by GCC. 
If you really need some assembly, as happens occasionally, then learn 
about GCC's extended syntax inline assembly.  That lets GCC worry about 
details such as register allocation and operands, so that your assembly 
is minimal, and allows the assembly to work well along with the compiler 
optimisation.


If you have legacy assembly functions that are written to a non-standard 
calling convention, write a thunk to translate as necessary.

GCC 10 branch is now closed

[Richard Biener via Gcc]

After the GCC 10.5 release the GCC 10 branch is now closed.

Thanks,
Richard.

GCC 10.5 Released

[Richard Biener via Gcc]

The GNU Compiler Collection version 10.5 has been released.

GCC 10.5 is a bug-fix release from the GCC 10 branch
containing important fixes for regressions and serious bugs in
GCC 10.4 with more than 155 bugs fixed since the previous release.

This is also the last release from the GCC 10 branch, GCC continues
to be maintained on the GCC 11, GCC 12 and GCC 13 branches and the
development trunk.

This release is available from the FTP servers listed here:

  https://sourceware.org/pub/gcc/releases/gcc-10.5.0/
  https://gcc.gnu.org/mirrors.html

Please do not contact me directly regarding questions or comments
about this release.  Instead, use the resources available from
http://gcc.gnu.org.

As always, a vast number of people contributed to this GCC release
-- far too many to thank them individually!