Re: rust non-free-compatible trademark

[Gabriel Ravier via Gcc]

On 7/19/22 01:09, lkcl via Gcc wrote:

On Mon, Jul 18, 2022 at 10:01 PM David Malcolm  wrote:


Luke: you appear to me to be the one who is telling people what patches
they can and cannot apply, and it's pissing me off.

1) please don't you dare put words into my mouth that i did not state.
 first and only warning.
2) i'm sorry you're annoyed. Asperger's interactions with neuro-typical
 individuals who are not used to the same typically do not go well:
 this conversation has all the hallmarks i'm used to being subjected
 to (and, frankly, shouldn't have to put up with).
 as you can probably imagine in 25 years it's pretty tiresome
 for me to be constantly subjected to abuse based solely on
 misunderstandings that, with the tiniest bit of tolerance, could
 easily have been avoided.
   3) as you work for redhat, you should be able to speak to HR and
   request Diversity training for how to interact with people with
   Asperger's.  [or, at least, how to recognise them and not get
   pissed off by how they speak].  given that it was "neurodiversity month"
   only a few weeks ago you should be able to find references on linkedin.


Hello there. For a while I've been watching this conversation and seeing 
how
inflammatory it has become, and this seems like the right place to 
intervene,
as I myself have Asperger. I would like to say that from my perspective 
it is

you, not everyone else, who is subjecting people to abuse based on a
misunderstanding with what seems to me like a constant stream of "OMGWTF
THE RUST TRADEMARK WILL DESTROY ALL GCC DEVELOPERS, REMOVE RUST
NOW" (note: this is hyperbole, and I am not claiming it is literally 
what you
have said, it is simply the general feeling that I have been left off 
with after

reading your messages throughout this thread).

David is simply telling you one of the most basic implications of what you
have been claiming, i.e. that if the GCC Rust frontend was to be added to
GCC then it would apparently expose everyone involved in distribution of
GCC (which as we know is a very wide definition) to trademark infringement
lawsuits and even potential criminal liability as you have claimed in a 
previous
message. The hopefully obvious implication is that the patches to add 
the Rust
frontend should thus not be applied. You have answered to this by 
telling him

that this simple statement is somehow abuse, which seems ridiculously
confrontational to me and almost like you are accusing him of deliberately
acting in bad faith, even though I have been doing my best to assume the
assumption of good faith so far. Just as you have cited the Conflict 
Resolution
Kit in one of your previous messages, I too know of similar sources. 
Here is one
that might help you with this: 
https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith



Are you a lawyer?  If so please consider volunteering your time to the
GCC Steering Committee *privately*.  If not, it seems to me to be a
terrible idea to try to get the developers to pontificate in public
about alleged legal issues with the project, their implications, and
supposed workarounds.

i'm a Libre Ethical Technology Specialist.  i expect a project such as
gcc to be held accountable publicly for its decisions and actions,
and to act responsibly.  this conversation will be watched by a hell
of a lot of people and if there are private conversations on this topic
being held behind closed doors then how the hell can anyone have
any confidence and trust in gcc?

i'm publicly and fully accountable in the FOSS projects that *i* manage,
including the full financial records, and given how massively high-profile
gcc is, i expect it to be held publicly accountable to a far greater degree.


While public accountability is a very good thing, I would hope you 
understand

that some topics are best kept private to some degree, at least for a short
duration so as to discourage impulsive or defensive reactions. Security
vulnerabilities should be a rather obvious example of this, but sensible 
issues
such as legal ones (as the one you are raising here) are also the kind 
of things

that seem to me like they should be kept private in the very short term.

Coming on the GCC mailing list, which hundreds of people regularly read,
and making such a statement as "has it been taken into consideration 
that the

draconian (non-free-compatible) requirements of the rust Trademark make the
distribution of the gcc compiler Unlawful?" will instinctively put 
essentially

everyone directly involved with the project on the defensive for hopefully
obvious reasons. By being publicly confrontational on this issue, you 
make it
much, much more likely, regardless of the accuracy of your statements, 
that the
people involved will not want to admit any potential mistake they might 
have
made, and will encourage them to be equally confrontational in 
responding to

you.

Making private contact instead is very useful for establishin

Re: rust non-free-compatible trademark

[Florian Weimer via Gcc]

* Arthur Cohen:

> Hi Florian,
>
> On Mon, Jul 18, 2022, 20:33 Florian Weimer via Gcc  wrote:

>  No.  It would actually make matters worse for GCC in this case because
>  the stated intent is to ship without a borrow checker (“There are no
>  immediate plans for a borrow checker as this is not required to compile
>  rust code”, , retrieved 2022-07-18). 
>
> The website is not up to date and we do have to change that. We do
> have plans for borrow-checking, which revolve around using and
> contributing to the Polonius project.

Ahh, I was wondering about that, but I couldn't find a clear indicator
that Polonius is still being developed in upstream Rust.

Thanks,
Florian

Re: [RFC] Function Multi Versioning on Arm

[Martin Liška]

On 7/18/22 12:36, Daniel Kiss via Gcc wrote:
> Hello,
> 
> We are going to add Function Multiversioning [1] support to Arm architectures.
> The specification is made public as beta[2] to ensure toolchain that follows 
> Arm
> C Language Extension will implement it in the same way.
> 
> A few tweaks considered to make the developers' life easier.
> Since the `target` attribute is used widely on Arm, we would like to 
> introduce a
> new attribute `target_version` to avoid confusion and possible deployment
> problems. The `target_clones` attribute will be supported too. Also the 
> “default”
> version to be made optional.
> 
> We are looking for feedback on the specification (reply, github works too).
> 
> Thanks so much,
> Daniel
> 
> [1] https://gcc.gnu.org/onlinedocs/gcc/Function-Multiversioning.html 
> [2] 
> https://github.com/ARM-software/acle/blob/main/main/acle.md#function-multi-versioning
> 

Hello.

Thanks for working on the feature, it will be nice to cover the gap in between 
x86_64 and powerpc,
which implement the FMV feature.

As the person who's been involved with the current MVC code in the GCC, I have 
a few comments/questions
about it:

1) both i386 and Powerpc also allow specifying an equivalent to -march (like 
`arch=bdver2`),
   in Arm case it seems to me only individual features are considered

2) about 'target_version' attribute - I like the idea as one can have a 
completely independent
   function implementation optimized for an ISA;
   note it's very close to 'target' attribute (supported in C++), where one 
needs to provide
   a resolver and have the pretty same functionality (see e.g. 
gcc/testsuite/g++.target/i386/mv1.C).
   However, the feature does not work in C and you will have the very same 
problem with target_version
   attribute (multiple functions with the same declaration):
  
  mv1.c:76:1: error: redefinition of ‘foo’
 76 | foo ()
| ^~~

3) If you will implement 'target_version' attribute, I would like to see it 
available also for the
   existing targets supporting MVC

4) A small note about the mangling, the existing i386 naming scheme looks like:

...
_Z3foov.avx2_ssse3
...

5) Can you please define how will you evaluate priorities for a situation where 
multiple features
   are used (e.g. dotprod+sm)?

   Note we face the very same problem on i386, where it's very hard to specify 
a priority
   for the family of avx512 features. That said, an optional priority specifier 
might be possible.

6) Note that as opposed to i385 and Powerpc, we don't allow a combination of 
ISA flags for target_clone
   attribute (like sse2+avx512f).

7) FMV may be disabled in compile time by a compiler flag. In this case the 
default version shall be used.

   I would like to see the functionality also target agnostic.

Anyway, looking forward to the Arm implementation.
Hope the comments are constructive.

Cheers,
Martin

Re: rust non-free-compatible trademark

[lkcl via Gcc]

On Tue, Jul 19, 2022 at 12:41 AM David Edelsohn  wrote:
>
> Luke,
>
> The GCC Community will give the issues that you raised due
> consideration and resolve any problems through appropriate channels.

David: although this was a private reply I am assuming that is in
error, and i feel it is appropriate to make public, and wrap up this
thread.

thank you for being literally the first person to very kindly give an explicit
indication that i've been heard.  that's all that any of you had to do, and
now that i feel i've been heard i am no longer deeply frustrated and angry.

https://www.crnhq.org/cr-kit/#empathy

Gabriel i very much appreciate your efforts to tell me that "i am
the problem" (see #empathy above) and i acknowledge those efforts.
let's not reduce the S/N ratio any further, eh?

perhaps everyone can learn from this experience, and some point
down the line appreciate that, as an outsider with no vested interest,
i was the only member in this community that could safely raise that
"The Rust Foundation Emperor has no Clothes" without damage to
their tenure, client base, or career, in what is one of the highest-paying
most strategically critical FOSS Projects in the world.

in summary i look forward to seeing the public results of the consideration of
conversion of the Rust Trademark to a Certification Mark and the clear benefits
and natural fit with existing FOSS development practices that entails.

http://archive.adaic.com/pol-hist/policy/trademrk.txt

l.


l.

Re: rust non-free-compatible trademark

[Jonathan Wakely via Gcc]

On Tue, 19 Jul 2022 at 11:27, lkcl via Gcc  wrote:
>
> On Tue, Jul 19, 2022 at 12:41 AM David Edelsohn  wrote:
> >
> > Luke,
> >
> > The GCC Community will give the issues that you raised due
> > consideration and resolve any problems through appropriate channels.
>
> David: although this was a private reply I am assuming that is in
> error, and i feel it is appropriate to make public, and wrap up this
> thread.
>
> thank you for being literally the first person to very kindly give an explicit
> indication that i've been heard.  that's all that any of you had to do, and
> now that i feel i've been heard i am no longer deeply frustrated and angry.

I already said you were not being ignored, but you chose to interpret
it as a dismissal of your feelings. Telling people to have more
empathy and then reacting negatively when people have responses you
don't like comes across as hypocritical. Your communication affects
others too.

>
> https://www.crnhq.org/cr-kit/#empathy

This should apply to all parties, not just the ones that aren't you.

"Empathy is about building rapport, openness and trust between people.
When it is absent, people are less likely to consider your needs and
feelings."

You started this thread with strong words like "draconian", "Unlawful"
and immediately insisted on absolutes like "completely removed". No
attempt to build rapport, or consider the feelings of the gccrs
developers. It's no wonder it went downhill!

>
> Gabriel i very much appreciate your efforts to tell me that "i am
> the problem" (see #empathy above) and i acknowledge those efforts.
> let's not reduce the S/N ratio any further, eh?
>
> perhaps everyone can learn from this experience, and some point
> down the line appreciate that, as an outsider with no vested interest,
> i was the only member in this community that could safely raise that
> "The Rust Foundation Emperor has no Clothes" without damage to
> their tenure, client base, or career, in what is one of the highest-paying
> most strategically critical FOSS Projects in the world.

Nobody who has replied to you was trying to preserve their career or
tenure, they just didn't agree with you. That's allowed.

> in summary i look forward to seeing the public results of the consideration of
> conversion of the Rust Trademark to a Certification Mark and the clear 
> benefits
> and natural fit with existing FOSS development practices that entails.
>
> http://archive.adaic.com/pol-hist/policy/trademrk.txt
>
> l.
>
>
> l.