date:20210411

On Apr 11, 2021, Jonathan Wakely  wrote:

> Here you go:
> https://gcc.gnu.org/pipermail/gcc/2021-March/235218.html

Thanks

> - this is unfair, RMS is being subjected to a witch hunt (irrelevant to my
> question, it doesn't tell me what benefit GCC gets from being linked to GNU
> or FSF)

Fair enough, even though your message starts by making it personal.

That said, even if the answer to the question about benefits turned out
to be "none whatsoever, as usual", that wouldn't be a motivator for
change to the status quo.  It would be as much of a reason to "why" as
for "why not".  So there would have to be something *else* that was
sensible to drive this pursuit, and to drive it right now.

Like, some other expected or perceived benefit that for whatever reason
wasn't viable before, and that seems more appealing than the current
situation.  No such motivating factor has been mentioned, and though GNU
is hardly a social GNUtopia, I expect you to find that the pastures are
greener on the other side of the fence, regardless of which side you're
on ;-)

> - RMS ensures GCC stays honest (implying the rest of us can't be trusted or
> don't *really* believe in FOSS, I don't think it's true and don't see this
> as an advantage)

Trust is not rational indeed, but a lot of people trust RMS to be
committed to FS values, and have little reason to trust people they
don't know, even if we're just as trustworthy.

That trust is probably most relevant in connection with FSF's
responsibilities of copyright enforcement, publishing new versions of
GNU licenses, and licensing GNU software assigned to it.  As various
organizations in the FLOSS space have been steered away from their
original purposes, I find legitimacy in people's preferences for someone
credibly committed, unbudging and incorruptible sharing in these
responsibilities.

FSF's historically credible commitment to the cause, reinforced by RMS's
presence, appears to offer a significant deterrent to copyright
infringement, whereas other popular projects that have dispersed their
copyrights, such as Linux, are frequent victims of legal neglect (and
occasionally malice) that leaves users unable to enjoy the freedoms they
deserve, despite laudable efforts of enforcement and of reaggregation of
representation, to try to make enforcement more viable and effective.

The reaggregation efforts suggest that dispersal does make enforcement
more difficult, so unless you wish to make the project more vulnerable
to infringement, I'd strongly advise some aggregation plan in place.

> - RMS doesn't get involved in GCC anyway, there's no reason to disassociate
> from him (still doesnt tell me what benefit there is, and ignores
> perception problems caused by that association)

No change to motivate change either, and ignores perception problems
caused by the poorly-justified and -timed termination of that
association.

> - it is not wise to disrespect the GNU Father (rambling troll who is listed
> as a GNU maintainer despite contributing no code, further devaluing the
> whole project)

That was unkind of you.  You're also leaping to conclusions based on
incorrect premises, as has happened so often in this conversation :-/

Sorting out some copyright issues sometimes takes longer than everyone
would like.  That who was never sloppy with copyrights gets to throw the
first stone.

> But lots of cult-like behaviour that helped me make up my mind.

You know what's funny?  Some cults are in favor of something, and some
are against something.  While what you label a cult is based on
philosophical and ethical foundations for the common good, the hate cult
you chose is built upon intolerance, half truths, false accusations,
repeated lies, significant influxes of freedom-denying capital, and
opportunistic timing.

Yeah, it's not really funny :-(

> If the GNU project and the FSF want to keep RMS, fine, they can have him

Thank you very much :-)

> But they can't tell me to be happy about it and they can't tell me
> where to contribute my code.

*nod*

> If the GNU project wants to pull my code from a fork, without my copyright
> assignment, I will consider that a small victory because it will mean
> they're willing to accept the contributions without owning the copyright.
> I'd like that.

Please talk to a lawyer you trust about this.  I don't know what you're
trying to accomplish, but if you value copyleft and would rather not
weaken it, I believe a competent lawyer will tell you why that's not
such a wise thing to like, and how to mitigate the downsides if you,
erhm, insist on liking it ;-)

> and w.r.t what you said to Dave about "selling our services" ...

I see nothing wrong about selling services of Free Software development.

> a cheap shot which assumes we aren't contributing under
> personal assignments to the FSF

Without a personal assignment on file?!?

> and assumes we have no choice to work
> elsewhere if we don't like the terms).

I don't know where you got that

Re: GCC association with the FSF

2021-04-11 Thread Siddhesh Poyarekar


On 4/12/21 7:13 AM, Alexandre Oliva via Gcc wrote:

On Apr 11, 2021, Adhemerval Zanella  wrote:


All the other active maintainers suggested you shouldn't have done that, but you
ignored it anyway.


How could I possibly have ignored something that hadn't happened yet?


There are irreconcilable differences in perceptions over the events that 
unfolded then and your comments and Adhemerval's (that, FWIW, I echo as 
glibc not-a-gnu-maintainer-just-a-contributor) are sufficient to signal 
that.  The discussion of the events itself is irrelevant to this thread 
and this mailing list so I suggest we stop this subthread.


Siddhesh

Re: GCC association with the FSF

2021-04-11 Thread José Rui Faustino de Sousa via Gcc-patches

On Apr 11, 2021, Adhemerval Zanella  wrote:

> All the other active maintainers suggested you shouldn't have done that, but 
> you
> ignored it anyway.

How could I possibly have ignored something that hadn't happened yet?

> *we* glibc maintainers were fully aware that it was *you* that decided
> to act in that way

There have been plenty of insinuations that contradict that assumption
and attempted to somehow blame it on RMS, but whether the record has
been set straight on this point now, or if it was straight already, the
point stands.

As recently as a couple of weeks ago someone referred, in this list, to
RMS's voicing his objection to the removal of one of the many pieces he
wrote for the glibc manual, and then setting out to propose and discuss
policies that incided on the matter, as if those were horrible actions.

That was almost as abhorrent as his asking a GNU developer a question
that he could have answered by just downloading the subproject's source
code and looking for the answer himself!  Oh, the horror!

If that's not hatred, I don't really wish to know what is :-/

-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

Re: GCC association with the FSF

2021-04-11 Thread Chris Punches via Gcc

Hello,

I've been reading quietly on how the GCC SC handles this and generally
only lurk here so that I can stay informed on GCC changes.  I am nobody
you would probably care about, but, maybe I will be one day.  No one
ever really knows.

I thought you'd like to know what "nobody" thinks, because, if I am
paying enough attention to know that some here are not, perhaps people
who are not "nobody" will have similar observations.

It is not appropriate to discuss the removal of someone based on
innuendo, provenly false smearing, and other types of political
maneuvering at the behest of corporations desiring the destruction of
the very projects they are sponsoring.

It is not appropriate to even suggest to blackmail sponsor or non-
sponsor organizations by cutting ties with them to force someone that a
couple corporates in your group don't like out of their organization.
 I call on those of you who argued this to restore credibility and
integrity to this discussion.

This kind of thinking has defaced this project.  What are you thinking?
 We don't care about your political views.  We don't care about GCC's
participation in activism-- in fact, many would view it as a marker of
instability of the project.  We care about the stable maintenance of
GCC into perpetuity.

No one who cares about these projects wants these kinds of politics
driving such a technical and fundamental project.  You have been
infected.  Please restore the compasses and carry on.

I salute you,

-C

On Sun, 2021-04-11 at 21:03 -0400, David Edelsohn via Gcc wrote:
> On Sun, Apr 11, 2021 at 8:40 PM Ian Lance Taylor via Gcc
>  wrote:
> > On Sat, Apr 10, 2021 at 4:36 AM Pankaj Jangid <
> > pan...@codeisgreat.org> wrote:
> > > I think, it would be great help if someone can document what the
> > > SC
> > > does.
> > 
> > I don't know whether anybody actually tried to answer this.
> > 
> > The main job of the GCC steering committee is to confirm GCC
> > maintainers: the people who have the right to approve changes to
> > specific parts of GCC, and the people who have the right to make
> > changes to specific parts of GCC without requiring approval from
> > anybody else.  These people are listed in the MAINTAINERS file in
> > the
> > gcc repository (currently
> > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=MAINTAINERS;h=db25583b37b917102b001c0025d90ee0bc12800f;hb=HEAD),
> > from the start of the file down to the list of "Write After
> > Approval"
> > people.
> > 
> > A secondary job of the GCC steering committee is to approve new
> > additions to GCC that are not under the GPL for one reason or
> > another.
> > This happens rarely.
> > 
> > A tertiary job of the GCC steering committee is to decide disputes
> > between maintainers that the maintainers are unable to resolve.  I
> > can't recall this ever happening.
> > 
> > The GCC steering committee is in principle a place to make
> > decisions
> > that affect the entire project.  There are very few such decisions.
> > One was the decision to change the implementation language of GCC
> > from
> > C to C++, a decision made in 2010.  Another was the decision to
> > allow
> > GCC plugins.  As a counter-example, moving GCC from Subversion to
> > git
> > was supported by the steering committee members, but there was no
> > formal decision by the steering committee to approve the move.
> > 
> > More generally, the GCC steering committee has historically served
> > as
> > a point of contact between the FSF and the GCC developers.  In my
> > opinion this has not amounted to much over the years that I've been
> > on
> > the committee (since 2014).
> 
> Also, because the FSF considers the GCC SC the "package maintainers"
> of GCC, the Steering Committee also receives and answers questions
> and
> requests from RMS and the FSF.
> 
> And, as I mentioned in another thread, I believe that the role of the
> GCC SC is to perform some of the duties of a good technical manager:
> remove real or potential roadblocks so that the developers can focus
> on being productive.
> 
> Some of us have initiated other activities and alliances to support
> and promote GCC and the GNU Toolchain, although it is not an official
> responsibility of the GCC SC.
> 
> Thanks, David

[Patch, fortran] PR fortran/100029 - ICE on storage_size with polymorphic argument, PR fortran/100040 - Wrong code with intent out assumed-rank allocatable


Hi All!

Proposed patch to:

PR100040 - Wrong code with intent out assumed-rank allocatable
PR100029 - ICE on subroutine call with allocatable polymorphic 
assumed-rank argument


Patch tested only on x86_64-pc-linux-gnu.

Made sure the code also recognized assumed-rank arrays as full arrays.

Changed the order of free and class to class conversion so that the free 
occurs first so that there are no problems with freeing an unexpected 
type of transformed class.


Thank you very much.

Best regards,
José Rui

Fortran: Fix ICE and wrong code emission [PR100029, PR100040]

gcc/fortran/ChangeLog:

PR fortran/100040
* trans-expr.c (gfc_conv_class_to_class): add code to have
assumed-rank arrays recognized as full arrays and fix the type
of the array assignment.

PR fortran/100029
* trans-expr.c (gfc_conv_procedure_call): change order of code
blocks, such that the free occurs first.

gcc/testsuite/ChangeLog:

PR fortran/100029
* gfortran.dg/PR100029.f90: New test.

PR fortran/100040
* gfortran.dg/PR100040.f90: New test.

diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 2fa17b36c03..35b784ab782 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -1099,8 +1099,10 @@ gfc_conv_class_to_class (gfc_se *parmse, gfc_expr *e, gfc_typespec class_ts,
 return;
 
   /* Test for FULL_ARRAY.  */
-  if (e->rank == 0 && gfc_expr_attr (e).codimension
-  && gfc_expr_attr (e).dimension)
+  if (e->rank == 0
+  && ((gfc_expr_attr (e).codimension && gfc_expr_attr (e).dimension)
+	  || (class_ts.u.derived->components->as
+	  && class_ts.u.derived->components->as->type == AS_ASSUMED_RANK)))
 full_array = true;
   else
 gfc_is_class_array_ref (e, _array);
@@ -1148,8 +1150,12 @@ gfc_conv_class_to_class (gfc_se *parmse, gfc_expr *e, gfc_typespec class_ts,
 	  && e->rank != class_ts.u.derived->components->as->rank)
 	{
 	  if (e->rank == 0)
-	gfc_add_modify (>post, gfc_class_data_get (parmse->expr),
-			gfc_conv_descriptor_data_get (ctree));
+	{
+	  tmp = gfc_class_data_get (parmse->expr);
+	  gfc_add_modify (>post, tmp,
+			  fold_convert (TREE_TYPE (tmp),
+	 gfc_conv_descriptor_data_get (ctree)));
+	}
 	  else
 	class_array_data_assign (>post, parmse->expr, ctree, true);
 	}
@@ -6111,23 +6117,6 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 		base_object = build_fold_indirect_ref_loc (input_location,
 			   parmse.expr);
 
-		  /* A class array element needs converting back to be a
-		 class object, if the formal argument is a class object.  */
-		  if (fsym && fsym->ts.type == BT_CLASS
-			&& e->ts.type == BT_CLASS
-			&& ((CLASS_DATA (fsym)->as
-			 && CLASS_DATA (fsym)->as->type == AS_ASSUMED_RANK)
-			|| CLASS_DATA (e)->attr.dimension))
-		gfc_conv_class_to_class (, e, fsym->ts, false,
- fsym->attr.intent != INTENT_IN
- && (CLASS_DATA (fsym)->attr.class_pointer
-	 || CLASS_DATA (fsym)->attr.allocatable),
- fsym->attr.optional
- && e->expr_type == EXPR_VARIABLE
- && e->symtree->n.sym->attr.optional,
- CLASS_DATA (fsym)->attr.class_pointer
- || CLASS_DATA (fsym)->attr.allocatable);
-
 		  /* If an ALLOCATABLE dummy argument has INTENT(OUT) and is
 		 allocated on entry, it must be deallocated.  */
 		  if (fsym && fsym->attr.intent == INTENT_OUT
@@ -6186,6 +6175,22 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 
 		  gfc_add_expr_to_block (>pre, tmp);
 		}
+		  /* A class array element needs converting back to be a
+		 class object, if the formal argument is a class object.  */
+		  if (fsym && fsym->ts.type == BT_CLASS
+			&& e->ts.type == BT_CLASS
+			&& ((CLASS_DATA (fsym)->as
+			 && CLASS_DATA (fsym)->as->type == AS_ASSUMED_RANK)
+			|| CLASS_DATA (e)->attr.dimension))
+		gfc_conv_class_to_class (, e, fsym->ts, false,
+ fsym->attr.intent != INTENT_IN
+ && (CLASS_DATA (fsym)->attr.class_pointer
+	 || CLASS_DATA (fsym)->attr.allocatable),
+ fsym->attr.optional
+ && e->expr_type == EXPR_VARIABLE
+ && e->symtree->n.sym->attr.optional,
+ CLASS_DATA (fsym)->attr.class_pointer
+ || CLASS_DATA (fsym)->attr.allocatable);
 
 		  if (fsym && (fsym->ts.type == BT_DERIVED
 			   || fsym->ts.type == BT_ASSUMED)
diff --git a/gcc/testsuite/gfortran.dg/PR100029.f90 b/gcc/testsuite/gfortran.dg/PR100029.f90
new file mode 100644
index 000..1fef06fd2d3
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/PR100029.f90
@@ -0,0 +1,26 @@
+! { dg-do run }
+!
+! Test the fix for PR100029
+!
+
+program foo_p
+
+  implicit none
+
+  type :: foo_t
+  end type foo_t
+  
+  class(foo_t), allocatable :: pout
+
+  call foo_s(pout)
+  stop
+
+contains
+
+  subroutine foo_s(that)
+class(foo_t), allocatable, intent(out) :: that(..)
+
+return
+  end subroutine foo_s
+

Re: GCC association with the FSF

2021-04-11 Thread David Edelsohn via Gcc

On Sun, Apr 11, 2021 at 8:40 PM Ian Lance Taylor via Gcc
 wrote:
>
> On Sat, Apr 10, 2021 at 4:36 AM Pankaj Jangid  wrote:
> >
> > I think, it would be great help if someone can document what the SC
> > does.
>
> I don't know whether anybody actually tried to answer this.
>
> The main job of the GCC steering committee is to confirm GCC
> maintainers: the people who have the right to approve changes to
> specific parts of GCC, and the people who have the right to make
> changes to specific parts of GCC without requiring approval from
> anybody else.  These people are listed in the MAINTAINERS file in the
> gcc repository (currently
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=MAINTAINERS;h=db25583b37b917102b001c0025d90ee0bc12800f;hb=HEAD),
> from the start of the file down to the list of "Write After Approval"
> people.
>
> A secondary job of the GCC steering committee is to approve new
> additions to GCC that are not under the GPL for one reason or another.
> This happens rarely.
>
> A tertiary job of the GCC steering committee is to decide disputes
> between maintainers that the maintainers are unable to resolve.  I
> can't recall this ever happening.
>
> The GCC steering committee is in principle a place to make decisions
> that affect the entire project.  There are very few such decisions.
> One was the decision to change the implementation language of GCC from
> C to C++, a decision made in 2010.  Another was the decision to allow
> GCC plugins.  As a counter-example, moving GCC from Subversion to git
> was supported by the steering committee members, but there was no
> formal decision by the steering committee to approve the move.
>
> More generally, the GCC steering committee has historically served as
> a point of contact between the FSF and the GCC developers.  In my
> opinion this has not amounted to much over the years that I've been on
> the committee (since 2014).

Also, because the FSF considers the GCC SC the "package maintainers"
of GCC, the Steering Committee also receives and answers questions and
requests from RMS and the FSF.

And, as I mentioned in another thread, I believe that the role of the
GCC SC is to perform some of the duties of a good technical manager:
remove real or potential roadblocks so that the developers can focus
on being productive.

Some of us have initiated other activities and alliances to support
and promote GCC and the GNU Toolchain, although it is not an official
responsibility of the GCC SC.

Thanks, David

[Bug fortran/100040] New: Wrong code with intent out assumed-rank allocatable

2021-04-11 Thread jrfsousa at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100040

Bug ID: 100040
   Summary: Wrong code with intent out assumed-rank allocatable
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jrfsousa at gmail dot com
  Target Milestone: ---

Created attachment 50562
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50562=edit
Fortran code showing problem

Hi All!

With intent out assumed-rank allocatable argument the generated code is missing
is missing the descriptor copy out.

Seen in:

GNU Fortran (GCC) 11.0.1 20210411 (experimental)
GNU Fortran (GCC) 10.3.1 20210411

Thank you very much.

Best regards,
José Rui

Re: GCC association with the FSF

2021-04-11 Thread Ian Lance Taylor via Gcc

On Sun, Apr 11, 2021 at 8:04 AM David Brown  wrote:
>
> On 11/04/2021 16:37, Richard Kenner via Gcc wrote:
> >> I guess my point is that the direction in which a project *does* go is not
> >> always the direction in which it *should* go.
> >
> > I agree.  And depending on people's "political" views, that can either be
> > an advantage or disadvantage of the free software development model.
> >
> >> To give just one small practical example, I'm told (by people who are more
> >> familiar with GCC internals than I) that it is not feasible with today's
> >> GCC to port to backends which have a small number of registers.
> >
> > [Finally, a technical discussion in this thread!]
> >
> > It never really has been.  Maybe it's not even possible now (I don't
> > know), but if you tried it in the past the results would never have
> > been very good.  Almost all multi-backend systems operate by having
> > very large numbers of expressions at all levels, which you gradually
> > lower to actual registers.  This works quite well if you have enough
> > registers to hold the high-usage expressions in them, but when you
> > have high register pressure, the model breaks down completely.
> > Although the situation may well have gotten worse in recent versions
> > that I'm not familiar with, I'd say that GCC was probably doing a
> > *better* job with a small number of registers in more recent versions
> > than in older ones: "reload" was particularly bad when there was high
> > register pressure.
> >
> > When your main constraint is register pressure, in order to get
> > high-quality results, I think you almost have to change the entire
> > philosophy of compilation, to the point I think where you have an
> > almost entirely different compilation chain for such machines.
> >
>
> Low register count cpu designs have been out of fashion for quite some
> time now (perhaps precisely because they are not a good fit for common
> compiler strategies).  They are mostly found in older families, such as
> the 8-bit CISC designs in older microcontrollers (8051, PIC, COP8, 6502,
> etc.).  And you are absolutely right that you need a different way of
> thinking in order to get the best out of such chips - low register count
> is only one aspect.  Other issues are few or no flexible pointer
> registers, no "SP + offset" addressing modes for efficient parameters or
> stack frames, banked ram and code blocks, and multiple separate address
> spaces.  Good toolchains for such devices need to work in a very
> different way, and typically encompass compilation, assembling and
> linking in one "omniscient" build so that variables, parameters, etc.,
> can be placed statically in ways that minimise banking and maximise
> reuse, based on lifetime analysis of the whole program.
>
> This would be a massively different way of working from how gcc does
> things now, and given that such devices are very much on the decline
> (when 32-bit ARM microcontrollers can be bought for 30 cents, smaller
> and cheaper cpu cores are rarely the right choice for a new design), it
> would not make sense to spend the effort supporting them in gcc.  There
> is, after all, quite a solid GPL'ed compiler toolchain for such devices
> at .

I think it depends on your goals.  In the past I've ported GCC to a
Harvard architecture system with six registers.  I agree that the code
quality was not the highest possible.  But the port worked fine, and
for this process performance was not an issue.  (As you suggest, I
tend to think that for most people who choose a processor with a small
number of registers, performance is not an issue.  Where performance
matters a lot, spend the money for a real processor, or at least use a
RISC/V.)

Ian

[Bug c++/100039] GCC can not bind lvalue to lvalue reference in brace-initialized-temporary expression

2021-04-11 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100039

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2021-04-12
   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.  Not a regression.

Re: GCC association with the FSF

2021-04-11 Thread Ian Lance Taylor via Gcc

On Sat, Apr 10, 2021 at 4:36 AM Pankaj Jangid wrote:
>
> I think, it would be great help if someone can document what the SC
> does.

I don't know whether anybody actually tried to answer this.

The main job of the GCC steering committee is to confirm GCC
maintainers: the people who have the right to approve changes to
specific parts of GCC, and the people who have the right to make
changes to specific parts of GCC without requiring approval from
anybody else. These people are listed in the MAINTAINERS file in the
gcc repository (currently
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=MAINTAINERS;h=db25583b37b917102b001c0025d90ee0bc12800f;hb=HEAD),
from the start of the file down to the list of "Write After Approval"
people.

A secondary job of the GCC steering committee is to approve new
additions to GCC that are not under the GPL for one reason or another.
This happens rarely.

A tertiary job of the GCC steering committee is to decide disputes
between maintainers that the maintainers are unable to resolve. I
can't recall this ever happening.

The GCC steering committee is in principle a place to make decisions
that affect the entire project. There are very few such decisions.
One was the decision to change the implementation language of GCC from
C to C++, a decision made in 2010. Another was the decision to allow
GCC plugins. As a counter-example, moving GCC from Subversion to git
was supported by the steering committee members, but there was no
formal decision by the steering committee to approve the move.

More generally, the GCC steering committee has historically served as
a point of contact between the FSF and the GCC developers. In my
opinion this has not amounted to much over the years that I've been on
the committee (since 2014).

Ian

Re: GCC association with the FSF

> Sent: Monday, April 12, 2021 at 11:30 AM
> From: "Jonathan Wakely via Gcc" 
> To: "Alexandre Oliva" 
> Cc: "David Malcolm via Gcc" 
> Subject: Re: GCC association with the FSF
>
> On Sun, 11 Apr 2021, 23:17 Alexandre Oliva wrote:
>
> >
> > Now, IIRC you and others have already disclaimed those reasons.  What I
> > don't recall seeing is the actual issue.  Pardon me if I missed it; I
> > gather I didn't, because you wrote something to the effect that I've
> > sidestepped it, which tells me I don't really know what it is.  If you
> > could point to it in the archives, or restate it, I'd appreciate it.
> >
>
> Here you go:
> https://gcc.gnu.org/pipermail/gcc/2021-March/235218.html
>
> GNU seems to have become a cult of personality. FSF seems to be a sinking
> ship.
>
> I don't think it benefits GCC to be linked to them. I think GCC would do
> better without those links.
>
> The mail linked above was quoted in the first mail in this sub-thread, when
> Mark changed the Subject:
> https://gcc.gnu.org/pipermail/gcc/2021-April/235340.html
>
> I also agree with the sentiments in
> https://wingolog.org/archives/2021/03/25/here-we-go-again
>
> I said that the only benefit I see for GCC is the DNS records for
> gcc.gnu.org and apart from Mark suggesting that a single copyright holder
> is an advantage (which I am not convinced about) the only arguments put
> forward have been variations on:
>
> - this is unfair, RMS is being subjected to a witch hunt (irrelevant to my
> question, it doesn't tell me what benefit GCC gets from being linked to GNU
> or FSF)
>
> - RMS ensures GCC stays honest (implying the rest of us can't be trusted or
> don't *really* believe in FOSS, I don't think it's true and don't see this
> as an advantage)
>
> - RMS doesn't get involved in GCC anyway, there's no reason to disassociate
> from him (still doesnt tell me what benefit there is, and ignores
> perception problems caused by that association)
>
> - it is not wise to disrespect the GNU Father (rambling troll who is listed
> as a GNU maintainer despite contributing no code, further devaluing the
> whole project)

You devalue him, I value him.  That's all.

I am a Official GNU Maintainer because the work is considered valuable because 
it
does not overlap with existing packages.  Besides needing capable people to help
there are legal reasons behind there being no code yet.  Those will be resolved.

I am recognised in various nations, and because I am in it the whole gnu project
is further valued.

> So no benefits that I can see. But lots of cult-like behaviour that helped
> me make up my mind.
>
> If the GNU project and the FSF want to keep RMS, fine, they can have him
> (if you check you'll find I haven't signed the GitHub letter). But they
> can't tell me to be happy about it and they can't tell me where to
> contribute my code.
>
> If the GNU project wants to pull my code from a fork, without my copyright
> assignment, I will consider that a small victory because it will mean
> they're willing to accept the contributions without owning the copyright.
> I'd like that.
>
> Anybody is welcome to use my code subject to its licence terms. But that
> doesn't mean they're welcome to own it or call it theirs. Assigning my
> copyright is my choice (and w.r.t what you said to Dave about "selling our
> services" ... a cheap shot which assumes we aren't contributing under
> personal assignments to the FSF, and assumes we have no choice to work
> elsewhere if we don't like the terms).
>

Re: GCC association with the FSF

2021-04-11 Thread vanyacpp at gmail dot com via Gcc-bugs

On Apr 11, 2021, Nathan Sidwell  wrote:

>> Can anyone come up with any rational motivation for this move right now?

> I gave them in my initial email.  You can go find them in the archive.

Err, I've been repeatedly told (not by you) that that was a separate
discussion.

The reasons you pointed out, for removing RMS from where he wasn't, were
present in the hate letter.  Other posters who supported that non-move
disclaimed them as motivations, once the accusations got debunked and
people started withdrawing their signatures from the hate letter.

I expected that reasoning applied to you as well.

And now you surprise me by presenting the same reasons to support this
other move!

But hey, they're your reasons.

Thanks,

-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

[Bug c++/100039] New: GCC can not bind lvalue to lvalue reference in brace-initialized-temporary expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100039

Bug ID: 100039
   Summary: GCC can not bind lvalue to lvalue reference in
brace-initialized-temporary expression
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vanyacpp at gmail dot com
  Target Milestone: ---

Consider this program:

typedef int& ref;

int main()
{
int a;
ref{a};
}

This is accepted by clang, msvc and icc. GCC 10.3 rejects this code with a
message:

error: cannot bind non-const lvalue reference of type 'ref' {aka 'int&'} to an
rvalue of type 'int'

I believe the error message is incorrect, because "a" is not an rvalue here. It
is lvalue, therefore it should be allowed to bind to lvalue reference.

https://godbolt.org/z/TWY9GPq3E

Re: GCC association with the FSF

2021-04-11 Thread Thomas Rodgers


On 2021-04-11 16:29, Thomas Rodgers wrote:


On 2021-04-11 15:23, Alexandre Oliva wrote:

On Apr 11, 2021, Thomas Rodgers  wrote:

On 2021-04-11 12:30, Alexandre Oliva via Gcc wrote:

AFAIK, you actually have no real say on who the company to whom you
sold your services assigns *their* copyrights to.



That statement is certainly not true with me and my employer. It is
very much *my* decision.



Interesting...  I made my statement above because I couldn't find
David's assignment on file.  This told me he's covered by Red Hat's
assignment, which supported my statement.



Now, I can't find an assignment on file for you either.
What gives?


1) I *should* have an assignment on file with the FSF (I certainly have 
an email trail in my archives on the matter that indicated such, 
however..). The paperwork was initiated before I started at Red Hat, my 
sense of the process was it's a disorganized shit show at the FSF for 
processing these things (or was at the time so who knows, maybe it's 
better now?, but I suspect not...for fairly obvious reasons) and I 
didn't actively pursue confirmation that everything was fully set, 
because I had RH's blanket assignment to operate under and I didn't have 
any expectation I'd need to deal with a separate assignment any time 
soon at that point for work on libstdc++.


2) So, I have done my libstdc++ work to date under RH's assignment to 
the FSF. Before that happened, however, I did work as a Red Hat employee 
to bring what was a the time, Intel's standalone C++ parallel algorithms 
implementation into a state where it could be contributed to libstdc++ 
as Intel had offered. Intel *also* offered the implementation to libc++. 
The work I did to bring the implementation in line with the requirements 
for being part of the standard library is largely the same between 
libstdc++ and libc++, and it was decided that we'd contribute the work 
to the LLVM project and relicense under those terms. Then I'd contribute 
*that* relicensed work to libstdc++. So, to this point, no work had been 
done in the libstdc++ codebase, just Intel's upstream repo.


This required Intel's lawyers to get a copyright assignment from me. 
This in turn required me to talk to Red Hat's lawyers. Where upon I 
learned, as long as Red Hat employees' work is done under an approved 
open source/free software license, Red Hat does not assert ownership 
over the work. As a result, Red Hat confirmed they had no involvement in 
relicensing the work that they had paid for.


This is not a common situation with corporate work, I grant you. But it 
is very much the case with Red Hat's employee contributions that Red Hat 
does not itself assert ownership of the work they do. This means, in 
particular, that it is the decision of the Red Hat folks who work on GCC 
to continue doing so under the current terms, or, as Jonathan has 
indicated, to not do it under those terms.


I'd add that, while uncommon, it does make a lot of sense for a company 
like Red Hat, whose default stance is to open source everything that can 
be open sourced. If Red Hat has the same rights to the work that Red Hat 
is making available to everyone else by funding that work to be done in 
the first place, there isn't much need to assert additional copyright 
ownership over the work.


Obligatory disclaimer - This was based on my experience with Red Hat 
legal, and what I was told by them during this particular process. It is 
not to be construed as any public statement of policy.

Re: GCC association with the FSF

2021-04-11 Thread Adhemerval Zanella via Gcc

On Sun, Apr 11, 2021 at 8:06 PM Alexandre Oliva  wrote:
>
> On Apr 11, 2021, Adhemerval Zanella  wrote:
>
> > It was clear to me and others glibc maintainers that it was *you* who
> > bypass the consensus to *not* reinstate the “joke”.
>
> I think you wrote it backwards: what I did was to revert the commit that
> the person who put it in agreed shouldn't have been made at that point,
> so that the debate about whether or not to install the patch could be
> carried out without the fait accompli.  To my surprise, it stopped.
>
> Then, a year or so later, when most of the GNU policies that incided on
> that matter had already been discussed and approved, and they suggested
> (at least to me) that the conclusion was likely that the patch was in
> line with them, some other situation came up that reminded people of the
> patch, it was discussed under the heat of the unrelated situation (which
> I also found inappropriate), but it got applied AFAICT in accordance
> with GNU and GLIBC policies.

RMS briefly stated that he did not want the change to be applied, we
considered his
input back then but we decided to remove the joke *regardless* of what
he thought
about the subject. And you used this to state the change had no consensus to
reinstate it in a way that we haven't done in the project for a couple
of years and which
caused a lot of disarray. The problem was not that you did it, but how
you did it.

You then spent a lot of days trying to convince other glibc
maintainers about your
actions to the point that Torvald and Siddhesh were fed up with your rhetoric.

>
> > maintainers said explicitly you shouldn’t do it.
>
> I do not see nor recall any such responses or reactions to my offer to
> revert the patch in case the installer wouldn't do it, except the
> installer saying they wouldn't do the reversal.  Eventually I did it.
> After the fact, some said I shouldn't have done it.
>
>
> That's my recollection of the events.

All the other active maintainers suggested you shouldn't have done that, but you
ignored it anyway. And we did not want to start a potential contention of patch
applying and reversion from that petty discussion.

But this is done and I don't want to dig into this. My point is *we*
glibc maintainers
were fully aware that it was *you* that decided to act in that way and
it was not my
feelings that it was *hate* the dominant response, but rather a lot of
frustration and
disappointment from how you acted.

Re: GCC association with the FSF

On Sun, 11 Apr 2021, 23:17 Alexandre Oliva wrote:

>
> Now, IIRC you and others have already disclaimed those reasons.  What I
> don't recall seeing is the actual issue.  Pardon me if I missed it; I
> gather I didn't, because you wrote something to the effect that I've
> sidestepped it, which tells me I don't really know what it is.  If you
> could point to it in the archives, or restate it, I'd appreciate it.
>

Here you go:
https://gcc.gnu.org/pipermail/gcc/2021-March/235218.html

GNU seems to have become a cult of personality. FSF seems to be a sinking
ship.

I don't think it benefits GCC to be linked to them. I think GCC would do
better without those links.

The mail linked above was quoted in the first mail in this sub-thread, when
Mark changed the Subject:
https://gcc.gnu.org/pipermail/gcc/2021-April/235340.html

I also agree with the sentiments in
https://wingolog.org/archives/2021/03/25/here-we-go-again

I said that the only benefit I see for GCC is the DNS records for
gcc.gnu.org and apart from Mark suggesting that a single copyright holder
is an advantage (which I am not convinced about) the only arguments put
forward have been variations on:

- this is unfair, RMS is being subjected to a witch hunt (irrelevant to my
question, it doesn't tell me what benefit GCC gets from being linked to GNU
or FSF)

- RMS ensures GCC stays honest (implying the rest of us can't be trusted or
don't *really* believe in FOSS, I don't think it's true and don't see this
as an advantage)

- RMS doesn't get involved in GCC anyway, there's no reason to disassociate
from him (still doesnt tell me what benefit there is, and ignores
perception problems caused by that association)

- it is not wise to disrespect the GNU Father (rambling troll who is listed
as a GNU maintainer despite contributing no code, further devaluing the
whole project)

So no benefits that I can see. But lots of cult-like behaviour that helped
me make up my mind.

If the GNU project and the FSF want to keep RMS, fine, they can have him
(if you check you'll find I haven't signed the GitHub letter). But they
can't tell me to be happy about it and they can't tell me where to
contribute my code.

If the GNU project wants to pull my code from a fork, without my copyright
assignment, I will consider that a small victory because it will mean
they're willing to accept the contributions without owning the copyright.
I'd like that.

Anybody is welcome to use my code subject to its licence terms. But that
doesn't mean they're welcome to own it or call it theirs. Assigning my
copyright is my choice (and w.r.t what you said to Dave about "selling our
services" ... a cheap shot which assumes we aren't contributing under
personal assignments to the FSF, and assumes we have no choice to work
elsewhere if we don't like the terms).

Re: GCC association with the FSF

2021-04-11 Thread Thomas Rodgers


On 2021-04-11 15:23, Alexandre Oliva wrote:


On Apr 11, 2021, Thomas Rodgers  wrote:

On 2021-04-11 12:30, Alexandre Oliva via Gcc wrote:

AFAIK, you actually have no real say on who the company to whom you
sold your services assigns *their* copyrights to.



That statement is certainly not true with me and my employer. It is
very much *my* decision.



Interesting...  I made my statement above because I couldn't find
David's assignment on file.  This told me he's covered by Red Hat's
assignment, which supported my statement.



Now, I can't find an assignment on file for you either.
What gives?


1) I *should* have an assignment on file with the FSF (I certainly have 
an email trail in my archives on the matter that indicated such, 
however..). The paperwork was initiated before I started at Red Hat, my 
sense of the process was it's a disorganized shit show at the FSF for 
processing these things (or was at the time so who knows, maybe it's 
better now?, but I suspect not...for fairly obvious reasons) and I 
didn't actively pursue confirmation that everything was fully set, 
because I had RH's blanket assignment to operate under and I didn't have 
any expectation I'd need to deal with a separate assignment any time 
soon at that point for work on libstdc++.


2) So, I have done my libstdc++ work to date under RH's assignment to 
the FSF. Before that happened, however, I did work as a Red Hat employee 
to bring what was a the time, Intel's standalone C++ parallel algorithms 
implementation into a state where it could be contributed to libstdc++ 
as Intel had offered. Intel *also* offered the implementation to libc++. 
The work I did to bring the implementation in line with the requirements 
for being part of the standard library is largely the same between 
libstdc++ and libc++, and it was decided that we'd contribute the work 
to the LLVM project and relicense under those terms. Then I'd contribute 
*that* relicensed work to libstdc++. So, to this point, no work had been 
done in the libstdc++ codebase, just Intel's upstream repo.


This required Intel's lawyers to get a copyright assignment from me. 
This in turn required me to talk to Red Hat's lawyers. Where upon I 
learned, as long as Red Hat employees' work is done under an approved 
open source/free software license, Red Hat does not assert ownership 
over the work. As a result, Red Hat confirmed they had no involvement in 
relicensing the work that they had paid for.


This is not a common situation with corporate work, I grant you. But it 
is very much the case with Red Hat's employee contributions that Red Hat 
does not itself assert ownership of the work they do. This means, in 
particular, that it is the decision of the Red Hat folks who work on GCC 
to continue doing so under the current terms, or, as Jonathan has 
indicated, to not do it under those terms.

Re: GCC association with the FSF



> Sent: Monday, April 12, 2021 at 8:04 AM
> From: "Jonathan Wakely via Gcc" 
> To: "Alexandre Oliva" 
> Cc: g...@gnu.org
> Subject: Re: GCC association with the FSF
>
> On Sun, 11 Apr 2021, 19:28 Alexandre Oliva,  wrote:
>
> > Jonathan,
> >
> > It's very offensive for you to misattribute a disagreeing position as
> > veneration.
> >
>
> There have been many posts over the past two weeks suggesting that without
> RMS to guide us, GCC will become a pawn of the NSA, or that nobody has any
> authority to decide on the future of GNU projects except RMS (a view also
> stated on GNU mailing lists by moderators of those very lists), or other
> silly claims that are based on little but veneration. They're not really
> based on anything about GCC, just "y u no like RMS?"

I have disagreed that GCC will become a pawn of the NSA, or that the only
person to decide is RMS.

> > I could name many reasons for me to disagree with yours, including
> > justice, truth, honesty, tolerance, freedom of speech and unity of the
> > movement.
> >
> > If anything, it's threatening to abandon a project over false
> > allegations about a person, on occasion of that person rejoining the
> > board of an organization that was founded and has always supported the
> > project who's still led by that person, that makes the issue personal
> > and based on blind faith, though in the opposite sense of veneration.
> >
>
> Oh I have other reasons to consider the FSF a dead end too.
>
>
> > If you find any offense in the previous paragraph, you understand
> > exactly why I feel offended by your retort, so please try to take that
> > into account in your attempts to participate in a kind debate.
> >
>
> Kind debate. Right.
>
> Maybe somebody from the GNU project or the FSF could tell one of their GNU
> Maintainers (apparently part of the governance structure of the GNU
> project) to stop calling people mad, or rats, or to stop endless off-topic
> trolling about communism. There is no kind debate when every other post is
> an attack from a troll.

Things can be said directly as customary.  You are certainly willing offending
me in your pursuit.  There have been instances where my post followed a number
of posts, but not on the entire thread.

> Your own emails are always carefully considered (and carefully skate around
> the actual issues people raised) but most of the other voices objecting to
> the requests to make changes to GCC are coming from outsiders who are only
> too happy to insult GCC devs and derail any "debate".

I am not an outsider.  Or have a plan to derail any debate or insult every
developer.  But the debate is in the gcc mailing list to which I was not an
outsider.  Changes can be done, and even if I would not agree with some
aspects, will respect the final choice.  There is no prerogative to praise
developers, including myself.

Re: GCC association with the FSF

2021-04-11 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

On Apr 11, 2021, Adhemerval Zanella  wrote:

> It was clear to me and others glibc maintainers that it was *you* who
> bypass the consensus to *not* reinstate the “joke”.

I think you wrote it backwards: what I did was to revert the commit that
the person who put it in agreed shouldn't have been made at that point,
so that the debate about whether or not to install the patch could be
carried out without the fait accompli.  To my surprise, it stopped.

Then, a year or so later, when most of the GNU policies that incided on
that matter had already been discussed and approved, and they suggested
(at least to me) that the conclusion was likely that the patch was in
line with them, some other situation came up that reminded people of the
patch, it was discussed under the heat of the unrelated situation (which
I also found inappropriate), but it got applied AFAICT in accordance
with GNU and GLIBC policies.

> maintainers said explicitly you shouldn’t do it.

I do not see nor recall any such responses or reactions to my offer to
revert the patch in case the installer wouldn't do it, except the
installer saying they wouldn't do the reversal.  Eventually I did it.
After the fact, some said I shouldn't have done it.

That's my recollection of the events.

-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

[Bug c++/97966] [10 Regression] maybe_instantiate_noexcept

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97966

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #12 from Marek Polacek  ---
Should be fixed, sorry again for the breakage.

[Bug c++/97966] [10 Regression] maybe_instantiate_noexcept

2021-04-11 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97966

--- Comment #11 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Marek Polacek
:

https://gcc.gnu.org/g:1004d3bb5e590a2cc3d22bc9fb11d3bf4978a982

commit r10-9695-g1004d3bb5e590a2cc3d22bc9fb11d3bf4978a982
Author: Marek Polacek 
Date:   Sun Apr 11 16:58:09 2021 -0400

c++: Use FOR_EACH_VEC_ELT instead of range-based for loop.

gcc/cp/ChangeLog:

PR c++/97966
* pt.c (instantiate_class_template_1): Use FOR_EACH_VEC_ELT instead
of range-based for loop.

Re: GCC association with the FSF

2021-04-11 Thread Nathan Sidwell


On 4/11/21 5:23 PM, Alexandre Oliva via Gcc wrote:

On Apr  8, 2021, David Brown  wrote:


I believe (but do not claim to be able to prove) that some of his past
actions would fall foul of laws against sexual harassment.


If you have any evidence whatsoever to support this belief, would you
please report it to the FSF board of directors, copying me?


Nice bit of deflection there.  I see what you're doing.

nathan

--
Nathan Sidwell

Re: GCC association with the FSF

2021-04-11 Thread Nathan Sidwell


On 4/11/21 2:51 PM, Alexandre Oliva via Gcc wrote:

There's something very confusing about this entire debate, that signals
some clear confusion about the role of the FSF.

GCC is part of the GNU project.

RMS is founder and leader of the GNU project.

RMS is also founder of the FSF.

The FSF was initially founded to support the GNU project.

The FSF later expanded its activities to other campaigns, but supporting
the GNU project remains a very important focus of FSF's activities.

However, the FSF does NOT control nor own the GNU project.  That appears
to be a very common misperception.

The FSF offers various pro-bono services to the GNU project, among them
guarding some GNU assets for the GNU project, but the GNU project is an
independent (unincorporated) organization, with its own separate and
independent governance structure.


The conversation has supposedly moved on from being centered on the
(very indirect) relationship with RMS to being centered around the
(even more indirect) relationship with the FSF.

The trigger for the present movements seems to be RMS's reappointment to
the board of directors of the FSF.

That makes no sense to me

RMS's closest roles regarding GCC have been of initial developer, leader
of the project that GCC belongs in, and occasional participant in
discussions among the GCC SC, and none of this has changed recently.

What is the relevance of his reappointment to the board of a separate
organization he's founded, long participated in, and presided for most
of its history, and that has supported both the GNU project at large and
the GNU toolchain specifically, in ways that haven't changed at all, not
when he resigned from the board, not when he was reappointed?!?

Can anyone come up with any rational motivation for this move right now?


I gave them in my initial email.  You can go find them in the archive.

nathan

--
Nathan Sidwell

gcc-11-20210411 is now available

2021-04-11 Thread GCC Administrator via Gcc

Snapshot gcc-11-20210411 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20210411/
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 master 
revision ac200799acb5cd2fb9e1758f6bf5fff1978daaeb

You'll find:

 gcc-11-20210411.tar.xz   Complete GCC

  SHA256=0926c51692b84741aa124d33c23d6475f4f1488c9cdb710513882d1f3b886efc
  SHA1=22bfd61515e2f7f2044eea291e33b9074636d569

Diffs from 11-20210404 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.

Re: GCC association with the FSF

2021-04-11 Thread Adhemerval Zanella via Gcc




> Il giorno 11 apr 2021, alle ore 17:45, Alexandre Oliva via Gcc 
>  ha scritto:
> 
> Remember how much hate RMS got in glibc land for something I did?  I
> said I did it out of my own volition, I explained my why I did it, but
> people wouldn't believe he had nothing to do with it! 

It was clear to me and others glibc maintainers that it was *you* who bypass 
the consensus to *not* reinstate the “joke”. And there was no hate (at least 
not from my side) only *disappointment* that you used your status to do it even 
though most of senior developers and maintainers said explicitly you shouldn’t 
do it.

Re: GCC association with the FSF

On Apr 11, 2021, Thomas Rodgers  wrote:

> On 2021-04-11 12:30, Alexandre Oliva via Gcc wrote:

>> AFAIK, you actually have no real say on who the company to whom you
>> sold your services assigns *their* copyrights to.

> That statement is certainly not true with me and my employer. It is
> very much *my* decision.

Interesting...  I made my statement above because I couldn't find
David's assignment on file.  This told me he's covered by Red Hat's
assignment, which supported my statement.

Now, I can't find an assignment on file for you either.
What gives?

-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

Re: GCC association with the FSF

On Apr 11, 2021, Jonathan Wakely  wrote:

> It's pretty confusing to outsiders.

It is indeed.  Up to 2004 or so, I'm told, the FSF didn't even have its
own separate web site.  Before 2019, it never seemed terribly important
to clear that up, but the confusion of concerns has always bugged me.

> The governance structure of the FSF is pretty opaque to me

The bylaws have always been public.

> Who are the "voting members" of the FSF?

Why are the couple of former directors who retained voting rights so
relevant now?  If you actually look at the governance structure in the
bylaws, you'll see that it's Directors and the Executive Director who
really run the show, and they can take pretty much any action that
voting members can.

> There is a perception that GCC's link to both GNU and the FSF is harmful to
> GCC's reputation.

But nothing changed in GNU recently, right?

FSF is one of the organizations that supports GNU, and the subject is
about separating from the FSF alone.

That makes zero sense to me, unless I factor in the common confusion
between FSF and GNU.

To me, GCC (GNU Toolchain) separating from the FSF would imply
terminating the fiscal sponsorship agreement that's in place as part of
the "Working Together for Free Software" program, that encompasses the
GNU Toolchain fund.

I could imagine that some convoluted reasoning might connect RMS's
reappointment to the FSF board to a wish to terminate that relationship,
that's the only one that exists between the FSF and (some
representatives of) the GNU Toolchain.  But I don't think that's what
you're getting at; I don't even know whether you knew about this
relationship.

As for GNU, the most relevant relationship for GCC, the recent FSF board
membership change doesn't change GNU at all, so any attempt to connect
this relationship with the FSF board appointment is confused at best.

As for public perception, we've seen how most people have seen through
the lies in the hate letter, so that motivation has become pretty weak,
and promoting those lies doesn't seem to be doing the movement or the
people propagating them any good.

I can get that some people, yourself included, may have legitimate
issues with RMS's leadership of the movement and of the project, that
are separate from the lies that some have come to believe, and are
mistaking as reasons for a split, and that are even more unrelated with
his reappointment to the FSF board.

Of course, nobody's trying to force you to keep on contributing to a
project you don't wish to contribute to any more.  Now, if your
intentions are honest, it would be kind of you to spell out your own
personal reasons to wish to fork GCC away from all things RMS, even
while you don't mind if GCC were to keep on merging your contributions
to the fork.

I don't expect to be able to overcome your, erhm, reverse veneration, so
to speak, but I trust you wish to do what you believe to be best for the
Free Software movement.

Alas, the timing and the motivations of other participants in this
conversation suggest your reasons have something to do with the false
accusations that coincided with these separation movements, and those
false accusations aren't doing good, not for the movement, not for those
pushing them; seeming to endorse them would color you intolerant for
some, and vindictive for others.

Now, IIRC you and others have already disclaimed those reasons.  What I
don't recall seeing is the actual issue.  Pardon me if I missed it; I
gather I didn't, because you wrote something to the effect that I've
sidestepped it, which tells me I don't really know what it is.  If you
could point to it in the archives, or restate it, I'd appreciate it.

Thanks,

-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

Re: GCC association with the FSF

2021-04-11 Thread Giacomo Tesio

Hi Ville,

On April 11, 2021 8:04:07 PM UTC, Ville Voutilainen via Gcc  
wrote:
> I don't love Jonathan Wakely's idea of forking libstdc++. I would much
> rather not have that fork happen. But I will follow that fork. I know
> him well enough that trying to talk him out of doing the fork is
> unlikely to succeed, we're far beyond the stage where such
> talking-out is on the table.
> [...]
> Bring on the forks. 

I know I'm depicted here as a "concern troll" or as a "RMS fanboy", but I have 
to admit that
I really appreciate the fork solution proposed by Jonathan.

I agree that calling the fork GCC would be a mess for everybody, but I would 
appreciate a 
proper fork with a new name because of the clarity it would bring on the table.

You could call it Open Compiler Collection, OCC, or someting like that.

Personally I would consider to keep using GCC and I could contribute my port to 
the 
GNU project as I planned to do since its beginning.

But I'd expect a more, varied, international and indipendent leadership on the
GNU Compiler Collection.

One more focused with freedom and less with marketing and US-interest and 
moralism, be it economically viable or not.

I even think that in the long run, the two projects could explore different and 
interesting technical paths, and even cooperate as peers.

Or maybe not.

But for what it matters, I would welcome the clarity a fork would bring to the 
ecosystem.

Sincerely,
the "new talent" you'd never want to attract! :-D

Giacomo

Re: GCC association with the FSF

On Apr  8, 2021, David Brown  wrote:

> I believe (but do not claim to be able to prove) that some of his past
> actions would fall foul of laws against sexual harassment.

If you have any evidence whatsoever to support this belief, would you
please report it to the FSF board of directors, copying me?

-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

[Bug middle-end/100038] -Warray-bound triggers false positives

2021-04-11 Thread nicholas.stranchfield--- via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100038

--- Comment #6 from Nicholas Stranchfield  
---
Created attachment 50561
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50561=edit
Output for only the SparseBitVector example

Here the output for only the SparseBitVector.h test case.

[Bug middle-end/100038] -Warray-bound triggers false positives

2021-04-11 Thread nicholas.stranchfield--- via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100038

--- Comment #5 from Nicholas Stranchfield  
---
Created attachment 50560
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50560=edit
Output for only the SmallVector example

Here the output for only the SmallVector.h test case.

P.S.: Sorry for the nose, mistook the attachment text area for the comment
field...

[Bug middle-end/100038] -Warray-bound triggers false positives

2021-04-11 Thread nicholas.stranchfield--- via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100038

--- Comment #4 from Nicholas Stranchfield  
---
Created attachment 50559
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50559=edit
gzipped output for SmallVector example

[Bug middle-end/100038] -Warray-bound triggers false positives

2021-04-11 Thread nicholas.stranchfield--- via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100038

--- Comment #3 from Nicholas Stranchfield  
---
Created attachment 50558
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50558=edit
gzipped output for SparseBitVector example

[Bug middle-end/100038] -Warray-bound triggers false positives

2021-04-11 Thread nicholas.stranchfield--- via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100038

--- Comment #2 from Nicholas Stranchfield  
---
Created attachment 50557
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50557=edit
gzipped output of g++-10.2.0

Sure, here you go.

Re: GCC association with the FSF

On Apr 11, 2021, Jonathan Wakely  wrote:

> There have been many posts over the past two weeks [...] based on
> little but veneration.

> Your own emails are always carefully considered

Thanks for confirming it.

Now, you were responding to me, not to the other posters.

As usual among RMS critics (see?, I've made an effort to resist the
unkindness of de-venerators), he, and apparently now me too, are somehow
held responsible for actions of others, just because they seem to
support some position you disagree with.  That's not right.

I wouldn't say people who undersigned a hate letter full of lies have
lied themselves.  Those who have been misled did not lie, even if the
words they honestly believed in were false, whatever it was that got
them to believe them.

Similarly, people who support a position you disagree with are not pawns
in an army of brainless creatures guided by your favorite monster.  They
are independent individuals with very different beliefs and motivations
who, for their own reasons, formulated their own theories as to why
people have fallen for such lies, or used them as levers to promote
actions where other not-so-shocking truths failed before.

Remember how much hate RMS got in glibc land for something I did?  I
said I did it out of my own volition, I explained my why I did it, but
people wouldn't believe he had nothing to do with it!  That's what I'm
talking about.  It's the same undeserved hatred that he got from Nathan
for his assumption that delays had something to do with RMS's
interference.  Even when he explicitly disapproves actions by misguided
supporters, he still gets hate over their actions.

Does that sound reasonable to you?

As in, do you agree to be held responsible for any speech or action by
anyone who happens to be favorable to the libstdc++ fork you are
proposing right now?

I didn't think so.

I hereby invoke the golden rule.

>> If you find any offense in the previous paragraph, you understand
>> exactly why I feel offended by your retort, so please try to take that
>> into account in your attempts to participate in a kind debate.

> Kind debate. Right.

You were addressing me, and I responded to that.

Have *I* been unkind in the debate I'm carrying out with you?

If you wish to lump me together with everyone else to whom you attribute
the same position that I hold, do you acknowledge that I'd be entitled
to hold you to a similar standard, and lump you with the shills and
liars behind a hate letter that failed a decapitation attack, but may
have partially succeeded at a divide-and-conquer attack on our movement?

> the requests to make changes to GCC are coming from outsiders who are only
> too happy to insult GCC devs and derail any "debate".

Some of the voices in favor of making changes have also come from
outsiders to GCC.

Did I miss your objections to their contributing their outsiders'
thoughts, or to their unkindness?

-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

Re: GCC association with the FSF

On Sun, 11 Apr 2021, 19:28 Alexandre Oliva,  wrote:

> Jonathan,
>
> It's very offensive for you to misattribute a disagreeing position as
> veneration.
>

There have been many posts over the past two weeks suggesting that without
RMS to guide us, GCC will become a pawn of the NSA, or that nobody has any
authority to decide on the future of GNU projects except RMS (a view also
stated on GNU mailing lists by moderators of those very lists), or other
silly claims that are based on little but veneration. They're not really
based on anything about GCC, just "y u no like RMS?"

> I could name many reasons for me to disagree with yours, including
> justice, truth, honesty, tolerance, freedom of speech and unity of the
> movement.
>
> If anything, it's threatening to abandon a project over false
> allegations about a person, on occasion of that person rejoining the
> board of an organization that was founded and has always supported the
> project who's still led by that person, that makes the issue personal
> and based on blind faith, though in the opposite sense of veneration.
>

Oh I have other reasons to consider the FSF a dead end too.

> If you find any offense in the previous paragraph, you understand
> exactly why I feel offended by your retort, so please try to take that
> into account in your attempts to participate in a kind debate.
>

Kind debate. Right.

Maybe somebody from the GNU project or the FSF could tell one of their GNU
Maintainers (apparently part of the governance structure of the GNU
project) to stop calling people mad, or rats, or to stop endless off-topic
trolling about communism. There is no kind debate when every other post is
an attack from a troll.

Your own emails are always carefully considered (and carefully skate around
the actual issues people raised) but most of the other voices objecting to
the requests to make changes to GCC are coming from outsiders who are only
too happy to insult GCC devs and derail any "debate".

GCC association with the FSF

2021-04-11 Thread Ville Voutilainen via Gcc

>However, the FSF does NOT control nor own the GNU project.  That appears
to be a very common misperception.

>The FSF offers various pro-bono services to the GNU project, among them
guarding some GNU assets for the GNU project, but the GNU project is an
independent (unincorporated) organization, with its own separate and
independent governance structure.


>The conversation has supposedly moved on from being centered on the
(very indirect) relationship with RMS to being centered around the
(even more indirect) relationship with the FSF.

>The trigger for the present movements seems to be RMS's reappointment to
the board of directors of the FSF.

>That makes no sense to me.

Really? Well, it makes some amounts of sense to me. See below.


>RMS's closest roles regarding GCC have been of initial developer, leader
of the project that GCC belongs in, and occasional participant in
discussions among the GCC SC, and none of this has changed recently.

>What is the relevance of his reappointment to the board of a separate
organization he's founded, long participated in, and presided for most
of its history, and that has supported both the GNU project at large and
the GNU toolchain specifically, in ways that haven't changed at all, not
when he resigned from the board, not when he was reappointed?!?

>Can anyone come up with any rational motivation for this move right now?

This is fairly straightforward. FSF is not as separate an organization
as you wish to depict it. It owns the copyright to GCC, and
people associated with it have decided to act as the PR department
of GCC developers.

Multiple maintainers would rather not have that PR department,
as they consider it a PR disaster. They'd rather improve
the PR department, but if that can't be accomplished, another
solution is to disassociate their work from FSF and the PR department.

I don't love Jonathan Wakely's idea of forking libstdc++. I would much
rather not have that fork happen. But I will follow that fork. I know
him well enough that trying to talk him out of doing the fork is
unlikely to succeed, we're far beyond the stage where such
talking-out is on the table.

This, of course, allows us to actually _see_ whether the predictions
of doom and gloom will materialize if FSF and RMS are no longer
associated with the work of various GCC developers.

It also allows us to see how viable the origin of the fork is, when
there sure are people suggesting that it can be lead by non-developers,
but fair amounts of developers will just go elsewhere.

If you wish to hear my wild guesses on those, they are
a) that the doom and gloom will not materialize
b) the origin of the fork will not remain viable.

Bring on the forks. We have ruminated on this long enough,
and that seems like a waste of bandwidth. The messages
the various developers are conveying are not getting through,
or are sinking into an abyss of neverending discussions about
something completely different from what the developers
are saying.

Re: GCC association with the FSF

2021-04-11 Thread pinskia at gcc dot gnu.org via Gcc-bugs

On Sun, 11 Apr 2021, 20:19 Alexandre Oliva via Gcc,  wrote:

>
> However, the FSF does NOT control nor own the GNU project.  That appears
> to be a very common misperception.
>

> The FSF offers various pro-bono services to the GNU project, among them
> guarding some GNU assets for the GNU project, but the GNU project is an
> independent (unincorporated) organization, with its own separate and
> independent governance structure.
>

"Please send general FSF & GNU inquiries to  .
There are also other ways to contact  the
FSF."

That's the footer of ... www.gnu.org and the "other ways to contact" link
goes to www.gnu.org/contact

The page header has a "Join the FSF" button, and the page's subtitle is
"Supported by the Free Software Foundation
"  where the link goes to
www.gnu.org again (not to fsf.org).

It's pretty confusing to outsiders.

The governance structure of the FSF is pretty opaque to me, and I've been
involved for close to 20 years. Who are the "voting members" of the FSF?
The governance structure of GNU is described at
https://www.gnu.org/gnu/gnu-structure.html but apart from the names of the
authors, only one individual is named on the page (you know who).

>
> Can anyone come up with any rational motivation for this move right now?
>

So "you didn't complain about the FSF in 2019, why do you have a problem
with them now?" Really? OK ...

There is a perception that GCC's link to both GNU and the FSF is harmful to
GCC's reputation. The unclear (to outsiders) relationship between GCC, GNU
and FSF may be to blame, but telling somebody that their perception is just
because they are confused doesn't necessarily help.

Would GCC leaving the GNU project but not removing links to the FSF really
mean much, when the FSF has just welcomed RMS back? And when the FSF still
sponsors the GNU project, which RMS has been clear he still leads whether
or not he's in the FSF? Can you really not see why people who want to
remove links to RMS/GNU might also think that remaining linked to the FSF
is a problem, given the FSF's strong links to GNU and renewed link to RMS?
And if somebody didn't think being linked to the FSF was a problem a month
ago, can you really not see why they might think it is a problem now, after
RMS rejoined the FSF?

Finally, the FSF seems to be imploding. I don't want GCC to suffer as a
result of that.

[Bug middle-end/100038] -Warray-bound triggers false positives

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100038

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-04-11
 Status|UNCONFIRMED |WAITING
   Keywords||diagnostic
  Component|c++ |middle-end

--- Comment #1 from Andrew Pinski  ---
Can you attach the preprocessor source?

Re: GCC association with the FSF

2021-04-11 Thread Thomas Rodgers


On 2021-04-11 12:30, Alexandre Oliva via Gcc wrote:


On Apr 11, 2021, David Malcolm via Gcc  wrote:

I don't want to be in an environment where, it turns out, the leader 
of

the non-profit that owns copyright on the bulk of the last 8 years of
my work, and controls the license on the bulk of my work for the last
20 years, has to be patiently coached in why pedophilia is bad.


AFAIK, you actually have no real say on who the company to whom you 
sold

your services assigns *their* copyrights to.



That statement is certainly not true with me and my employer. It is very 
much *my* decision.

Re: GCC association with the FSF

2021-04-11 Thread marxin at gcc dot gnu.org via Gcc-bugs

On Apr 11, 2021, David Malcolm via Gcc  wrote:

> I don't want to be in an environment where, it turns out, the leader of
> the non-profit that owns copyright on the bulk of the last 8 years of
> my work, and controls the license on the bulk of my work for the last
> 20 years, has to be patiently coached in why pedophilia is bad.

AFAIK, you actually have no real say on who the company to whom you sold
your services assigns *their* copyrights to.

As to the loaded claims you make, that's completely off topic IMHO, but
since you brought it up, I'll assume you won't mind if I point out that
pedophilia is a misnomer, and mostly unrelated with things RMS actually
wrote and wondered about.

There's a different term that applies to sexually mature non-adults, and
when it comes to them, issues are a lot less clear-cut than you imply.
Treating conversations about them as taboos or unquestionable truths
contribute to keeping things nebulous, problematic, and distant from
what science actually has to say about teen sexuality.

Think of burning people at the stake over disputing then-prevalent
flat-earth beliefs, think of the efforts to "cure" Alan Turing, and
realize how questioning prevalent but unfounded beliefs can both imperil
the person who does the questioning, and matter for the advancement of
science and of civilization.

As to the tiny bit of speculation that may have had to do with actual
sexually-immature children, I wonder what science you could share with
us in support of what you seem to believe anyone ought to just accept
unquestioningly, and how it was that you came to believe it yourself.

At the risk of having my words twisted and of being mislabeled like RMS,
I, as a caring parent who had to wonder and think these issues through
long ago, wonder how you went or would go about explaining to e.g. an
inquisitive and curious 4 year-old that hugging, kissing, caressing hair
and such pleasant things are good and desirable, as long as the people
engaging in it welcome it, but that certain other pleasant contacts,
that they are not mature enough to distinguish from the acceptable ones,
are intolerable and harmful, even when everyone involved welcomes it.

Note I'm not disputing the difference nor the harm, though I haven't
seen the science that supports it.  But I'd welcome it, and I wonder how
to do that without (i) forcing the child to accept an argument of
authority (that tends to kill curiosity and scientific pursuit), (ii)
getting the child too interested too early (prohibited stuff tends to
draw attention :-), nor (iii) instilling feelings of inappropriateness
or inadequacy that could harm their future sexual life.

This is way off topic, so feel free to respond without copying the list.
I did copy the list because, once the belief that some positions should
be held by default and unquestionably is presented as an argument to
condemn someone, it's just fair to present an opposite argument
involving questioning and pondering on the same issue.

-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

Chat about a possible working agreement with gcc.gnu.org

2021-04-11 Thread John Hamlin

Hey there,  
 I wanted to contact you about how we can work together linkbuilding.  
 Would you be open to the idea?  
 - John

[Bug lto/100010] [8/9/10/11 Regression] ICE in lto_output_node, at lto-cgraph.c:447 (-fdevirtualize-at-ltrans) since r6-6384-gceda2c69d5219719

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100010

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |8.5
 CC||hubicka at gcc dot gnu.org
Summary|ICE in lto_output_node, at  |[8/9/10/11 Regression] ICE
   |lto-cgraph.c:447|in lto_output_node, at
   |(-fdevirtualize-at-ltrans)  |lto-cgraph.c:447
   ||(-fdevirtualize-at-ltrans)
   ||since
   ||r6-6384-gceda2c69d5219719
   Last reconfirmed||2021-04-11
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Confirmed, started with r6-6384-gceda2c69d5219719.

Re: GCC association with the FSF

There's something very confusing about this entire debate, that signals
some clear confusion about the role of the FSF.

GCC is part of the GNU project.

RMS is founder and leader of the GNU project.

RMS is also founder of the FSF.

The FSF was initially founded to support the GNU project.

The FSF later expanded its activities to other campaigns, but supporting
the GNU project remains a very important focus of FSF's activities.

However, the FSF does NOT control nor own the GNU project.  That appears
to be a very common misperception.

The FSF offers various pro-bono services to the GNU project, among them
guarding some GNU assets for the GNU project, but the GNU project is an
independent (unincorporated) organization, with its own separate and
independent governance structure.


The conversation has supposedly moved on from being centered on the
(very indirect) relationship with RMS to being centered around the
(even more indirect) relationship with the FSF.

The trigger for the present movements seems to be RMS's reappointment to
the board of directors of the FSF.

That makes no sense to me.

RMS's closest roles regarding GCC have been of initial developer, leader
of the project that GCC belongs in, and occasional participant in
discussions among the GCC SC, and none of this has changed recently.

What is the relevance of his reappointment to the board of a separate
organization he's founded, long participated in, and presided for most
of its history, and that has supported both the GNU project at large and
the GNU toolchain specifically, in ways that haven't changed at all, not
when he resigned from the board, not when he was reappointed?!?

Can anyone come up with any rational motivation for this move right now?

-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

Re: GCC association with the FSF

2021-04-11 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

Jonathan,

It's very offensive for you to misattribute a disagreeing position as
veneration.

I could name many reasons for me to disagree with yours, including
justice, truth, honesty, tolerance, freedom of speech and unity of the
movement.

If anything, it's threatening to abandon a project over false
allegations about a person, on occasion of that person rejoining the
board of an organization that was founded and has always supported the
project who's still led by that person, that makes the issue personal
and based on blind faith, though in the opposite sense of veneration.

If you find any offense in the previous paragraph, you understand
exactly why I feel offended by your retort, so please try to take that
into account in your attempts to participate in a kind debate.

-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

[Bug c++/100038] New: -Warray-bound triggers false positives

2021-04-11 Thread nicholas.stranchfield--- via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100038

Bug ID: 100038
   Summary: -Warray-bound triggers false positives
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nicholas.stranchfi...@you-spam.com
  Target Milestone: ---

When compiling LLVM, I noticed that GCC produces some -Warray-bounds warnings,
namely

In file included from mwe.cpp:4:
SparseBitVector.h: In function ‘int main()’:
SparseBitVector.h:129:15: warning: array subscript 2 is above array bounds of
‘const BitWord [2]’ {aka ‘const long unsigned int [2]’} [-Warray-bounds]
  129 |   if (Bits[i] != 0)
  |   ^
SparseBitVector.h:54:11: note: while referencing
‘llvm::SparseBitVectorElement<128>::Bits’
   54 |   BitWord Bits[BITWORDS_PER_ELEMENT];
  |   ^~~~
SparseBitVector.h:138:15: warning: array subscript 4294967295 is above array
bounds of ‘const BitWord [2]’ {aka ‘const long unsigned int [2]’}
[-Warray-bounds]
  138 |   if (Bits[Idx] != 0)
  |   ^
SparseBitVector.h:54:11: note: while referencing
‘llvm::SparseBitVectorElement<128>::Bits’
   54 |   BitWord Bits[BITWORDS_PER_ELEMENT];
  |   ^~~~
In file included from mwe.cpp:3:
SmallVector.h:537:7: warning: array subscript 1 is outside array bounds of ‘int
[1]’ [-Warray-bounds]
  537 |   ++EltPtr;
  |   ^~
mwe.cpp:21:29: note: while referencing ‘’
   21 |  VS.insert(VS.begin() + 1, 5);
  | ^
In file included from mwe.cpp:3:
SmallVector.h:566:7: warning: array subscript 1 is outside array bounds of ‘int
[1]’ [-Warray-bounds]
  566 |   ++EltPtr;
  |   ^~
mwe.cpp:22:6: note: while referencing ‘val’
   22 |  int val = 6;
  |  ^~~

On inspection of the source, it seems these are false positives OR some
optimization went havoc (hopefully it did not), e.g. for SparseBitVector.h we
have

struct SparseBitVectorElement {
  // ...
  BitWord Bits[BITWORDS_PER_ELEMENT]; // line 54
  // ...
  int find_first() const {
for (unsigned i = 0; i < BITWORDS_PER_ELEMENT; ++i)
  if (Bits[i] != 0) // line 129
// ...
  }
}

which looks pretty sound to me.  Searching around the internet, I'm not the
only one with these warnings, e.g. they show up in Fedora's LLVM build [0,1]
and Debian's [2].
In particular, this case looks very simple and a common theme which should not
trigger such warning.

[0]
https://kojipkgs.fedoraproject.org/packages/llvm/10.0.0/0.6.rc6.fc33/data/logs/ppc64le/build.log
[1]
https://kojipkgs.fedoraproject.org/packages/llvm/11.0.0/0.2.rc3.fc34/data/logs/s390x/build.log
[2]
https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-11=amd64=1%3A11.0.1-2=1609987721=0

The SmallVector related warning appeared first with GCC 9.x, while the
SparseBitVector related warnings appeared with GCC 10 (tested GCC 10.2.0) and
are absent in GCC-9.3.0.
The warnings trigger with -O2 but not with -O1 and -DNDEBUG is needed for the
SparseBitVector one.

If LLVM headers (version 10 or 11) are installed, then the following minimal
working example triggers the warnings:

g++ -I/usr/lib/llvm/11/include -DNDEBUG -O2 -Warray-bounds -o mwe.cpp.o -c
mwe.cpp
cat mwe.cpp

#include "llvm/ADT/SmallVector.h"
#include "llvm/ADT/SparseBitVector.h"

#include 

using namespace llvm;

int main()
{
// Trigger: SparseBitVector (lines 138, 129)
SparseBitVector<> Vec;
Vec.set(5);
// force the vector
printf("%d\n", Vec.find_first());
printf("%d\n", Vec.find_last());

// Trigger: SmallVector (lines 537, 566)
SmallVector VS = {1, 2, 3, 4};
VS.insert(VS.begin() + 1, 5);
int val = 6;
VS.insert(VS.begin() + 2, val);
// force the vector
for (int i : VS) {
printf("%d\n", i);
}
}

[Bug c++/100037] lookup doesn't find class template parameter in default member initializer of forward declared nested class template

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100037

--- Comment #2 from Marek Polacek  ---
(Not a regression AFAICT.)

[Bug c++/100037] lookup doesn't find class template parameter in default member initializer of forward declared nested class template

2021-04-11 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100037

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2021-04-11
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW

--- Comment #1 from Marek Polacek  ---
Interesting.  Confirmed, thanks for the report.

[Bug c++/100037] New: lookup doesn't find class template parameter in default member initializer of forward declared nested class template

2021-04-11 Thread barry.revzin at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100037

Bug ID: 100037
   Summary: lookup doesn't find class template parameter in
default member initializer of forward declared nested
class template
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Issue title is a mouthful, but it's a very narrow case:

template  using always_int = int;

struct view {
template  struct iterator;

template 
struct iterator {
always_int inner = always_int();
};
};

This is rejected with:

:8:46: error: 'Const' was not declared in this scope
8 | always_int inner = always_int();
  |  ^
:8:51: error: template argument 1 is invalid
8 | always_int inner = always_int();
  |   ^

This compiles if we also name the template parameter in the forward
declaration. This fails only in the case of a nested class - if you change it
to namespace view from struct view, the example compiles fine.

[Bug c++/97966] [10 Regression] maybe_instantiate_noexcept

2021-04-11 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97966

--- Comment #10 from Marek Polacek  ---
Argh!  Sorry about that, will fix.

Re: GCC association with the FSF

2021-04-11 Thread zhendong.su at inf dot ethz.ch via Gcc-bugs

On Sun, 11 Apr 2021, 16:56 David Brown, wrote:

>
> The big problem with a fork, rather than an amiable split (where FSF/GNU
> accepts that gcc wants to be a separate project) is the name.  If the
> FSF keep their own "gcc" project, then calling the new fork "gcc" as
> well would cause confusion.

Packagers for Linux distros and BSD ports collections (and similar like
MinGW distros) are unlikely to be confused for long.

The GNU project can have the "GNU C Compiler" name, as far as I'm
concerned. The "GNU Compiler Collection" name dates from the time when EGCS
replaced the original GCC so I would argue that the FSF couldn't claim
ownership of a new twist on it like "GCC Compiler Collection".

And Apple already got away with shipping clang as the "gcc" and "g++"
executables (albeit causing much confusion) so even if the project changed
name, the shipped products wouldn't need to.

Your point is valid, but I've been thinking about the practicalities a lot.
I still think losing the gcc.gnu.org DNS records would be the biggest
drawback.

  And calling it something else would also
> confuse people - many would use the FSF gcc because of its name, not
> realising that there is a better fork.  You can see that in the
> OpenOffice / LibreOffice split - I think a large proportion of people
> downloading OpenOffice do so without realising that LibreOffice exists
> and is way ahead of it on features.
>

Only a small minority download GCC (we don't provide binaries for a start,
so most people use the binary package from their OS, or a semi-automated
build like portage or MacPorts).

So I'm not terribly concerned about that problem.

> A fork may be unavoidable in the end, but a more diplomatic change of
> structure would have many advantages if it can be achieved.
>

I would be very happy if the FSF took that view and let us walk away. If
not, I don't think it's a huge problem.

Re: [committed] ada: Avoid invalid "up" link in manual

2021-04-11 Thread Arnaud Charlet

> >> With this patch the bottom navigation of the page at
> >>  https://gcc.gnu.org/onlinedocs/gnat_ugn/index.html
> >> changes from
> >>   Next: About This Guide, Up: (dir)   [Contents][Index]
> >> to 
> >>  Next: About This Guide   [Contents][Index]
> >> and the invalid "(dir)" link that pointed to
> >>  http://gcc.gnu.org/onlinedocs/dir/index.html
> >> which does not exist is gone.
> > Well the master is the rest/sphinx files in doc, the texi file is auto 
> > generated, so your change will dispapear at the next generation.
> 
> You're right, good catch, Arnaud!
> 
> How can we fix this at the root, then? I'm not sufficiently familiar
> with Sphinx and did not find where we might change that.

You can always do some postprocessing, see gcc/ada/doc/Makefile line 66 for
an existing kludge^Wpostprocessing.

Arno

Re: GCC association with the FSF

2021-04-11 Thread David Brown

On 11/04/2021 17:06, Jonathan Wakely via Gcc wrote:
> On Sun, 11 Apr 2021, 15:26 Richard Sandiford via Gcc, 

>>
>> FWIW, again speaking personally, I would be in favour of joining a fork.[*]
>>
> 
> Glad to hear it :-)
> 
> I will be forking, alone if necessary, but I've already been told by a few
> people I won't be alone.
> 

The big problem with a fork, rather than an amiable split (where FSF/GNU
accepts that gcc wants to be a separate project) is the name.  If the
FSF keep their own "gcc" project, then calling the new fork "gcc" as
well would cause confusion.  And calling it something else would also
confuse people - many would use the FSF gcc because of its name, not
realising that there is a better fork.  You can see that in the
OpenOffice / LibreOffice split - I think a large proportion of people
downloading OpenOffice do so without realising that LibreOffice exists
and is way ahead of it on features.

A fork may be unavoidable in the end, but a more diplomatic change of
structure would have many advantages if it can be achieved.

[Bug ipa/100036] New: missed optimization for dead code elimination at -Os, -O2 and -O3 (vs. -O1)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100036

Bug ID: 100036
   Summary: missed optimization for dead code elimination at -Os,
-O2 and -O3 (vs. -O1)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

[562] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210411 (experimental) [master revision
1d54b138417:e83b9cf4549:936d500dfc17f58f2507ecd0f7f26e4f197052ee] (GCC) 
[563] % 
[563] % gcctk -O1 -S -o O1.s small.c
[564] % gcctk -O3 -S -o O3.s small.c
[565] % 
[565] % wc O1.s O3.s
  27   58  454 O1.s
  38   77  665 O3.s
  65  135 1119 total
[566] % 
[566] % grep foo O1.s
[567] % grep foo O3.s
jmp foo
[568] % 
[568] % cat small.c
extern void foo(void);
int a, *b;
static int c, f;
inline int *d() {
  int g[100] = {0};
  if (a) {
int h = g[0];
foo();
return b;
  }
}
int main() {
  while (1) {
if (!c)
  return f;
d();
  }
  return 0;
}

[Bug c++/100035] New: Parameter packs not expanded with local variable in lambda

2021-04-11 Thread hewillk at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100035

Bug ID: 100035
   Summary: Parameter packs not expanded with local variable in
lambda
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/ss9bjYvc1

template 
auto f(Ts...) {
  ([] { Ts x = 0; }, ...);
}

gcc rejects with:

: In function 'auto f(Ts ...)':
:3:4: error: operand of fold expression has no unexpanded parameter
packs
3 |   ([] { Ts x = 0; }, ...);
  |^~~~

[PATCH] c++: constraints are unevaluated operands [PR99961]

2021-04-11 Thread Patrick Palka via Gcc-patches

According to [temp.concept]/6 and [temp.pre]/9, a concept definition and
a requires clause are both unevaluated contexts, and hence satisfaction
deals only with unevaluated operands, so we should set cp_unevaluated
in these three situations.

(I guess we should set cp_unevaluated during normalization too, but I
wasn't able to construct a testcase for which it makes a difference.)

Bootstrapped and regtested on x86_64-pc-linux-gnu, and also tested on
cmcstl2 and range-v3, does this look OK for trunk?

gcc/cp/ChangeLog:

PR c++/99961
* constraint.cc (satisfy_normalized_constraints): Set
cp_unevaluated.
* parser.c (cp_parser_concept_definition): Likewise.
(cp_parser_requires_clause_opt): Likewise.

gcc/testsuite/ChangeLog:

PR c++/99961
* g++.dg/cpp2a/concepts-uneval1.C: New test.
---
 gcc/cp/constraint.cc  |  3 +++
 gcc/cp/parser.c   |  6 ++
 gcc/testsuite/g++.dg/cpp2a/concepts-uneval1.C | 10 ++
 3 files changed, 19 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-uneval1.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 0ddb2990dd9..6c8e29d809f 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -3066,6 +3066,9 @@ satisfy_normalized_constraints (tree t, tree args, 
sat_info info)
   /* We need to check access during satisfaction.  */
   deferring_access_check_sentinel acs (dk_no_deferred);
 
+  /* Constraints are an unevaluated operands.  */
+  cp_unevaluated u;
+
   return satisfy_constraint_r (t, args, info);
 }
 
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index b6f94bdda23..8b7801b2be7 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -28353,6 +28353,9 @@ cp_parser_label_declaration (cp_parser* parser)
 static tree
 cp_parser_concept_definition (cp_parser *parser)
 {
+  /* A concept definition is an unevaluated context.  */
+  cp_unevaluated u;
+
   gcc_assert (cp_lexer_next_token_is_keyword (parser->lexer, RID_CONCEPT));
   cp_lexer_consume_token (parser->lexer);
 
@@ -28714,6 +28717,9 @@ cp_parser_constraint_expression (cp_parser *parser)
 static tree
 cp_parser_requires_clause_opt (cp_parser *parser, bool lambda_p)
 {
+  /* A requires clause is an unevaluated context.  */
+  cp_unevaluated u;
+
   cp_token *tok = cp_lexer_peek_token (parser->lexer);
   if (tok->keyword != RID_REQUIRES)
 {
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-uneval1.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-uneval1.C
new file mode 100644
index 000..4c5f1b5c019
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-uneval1.C
@@ -0,0 +1,10 @@
+// PR c++/99961
+// { dg-do compile { target c++20 } }
+
+struct A { static const int x = 42; bool y; };
+
+void f(auto a) requires (a.x == 42) { }
+template void f(A);
+
+template  concept C = V || A::y;
+static_assert(C);
-- 
2.31.1.272.g89b43f80a5

[Bug c++/99961] requires clause rejects mentioning of function parameters too early

2021-04-11 Thread ppalka at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99961

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 CC||ppalka at gcc dot gnu.org
 Status|NEW |ASSIGNED

About porting GCC to backends which have a small number of registers. ....

2021-04-11 Thread Basile Starynkevitch


To give just one small practical example, I'm told (by people who are more
familiar with GCC internals than I) that it is not feasible with today's
GCC to port to backends which have a small number of registers.


I think (not sure) that could be attributed to 
j...@darrington.wattle.id.au - apologies if I am wrong.



Why?


GCC is doing many optimisations at the GIMPLE level.

Why won't it be possible (even if very painful) to transform GIMPLE to 
some architecture with very few registers.


IIRC, the TMS9900 (a microprocessor from texas instruments, in 1976) had 
very few hardware registers. One of them being a "pointer" to some 
"virtual register bank" on the call stack.


http://www.bitsavers.org/components/ti/TMS9900/TMS_9900_Microprocessor_Data_Manual_May76.pdf

I don't seen any impossibility in generating such instructions from GIMPLE.

Of course, I am not candidate to do so...

Cheers


--
Basile Starynkevitch  
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Re: GCC association with the FSF

2021-04-11 Thread zhendong.su at inf dot ethz.ch via Gcc-bugs

On Sun, 11 Apr 2021, 15:26 Richard Sandiford via Gcc, 
wrote:

>
>
> I think it's misleading to talk about GCC “leaving” or “disassociating
> itself” from the FSF or from the GNU project.  No-one can force the FSF or
> the GNU project to drop GCC (and I don't think anyone's trying to make it
> do that).  I think what we're really talking about is whether there should
> be a fork.

There doesn't *have* to be a fork. If GCC walked away from GNU, the GNU
system could continue to use GCC with no actual input to it, just like it
uses the Linux kernel (except for a statistically insignificant number of
GNU/Hurd systems). I have no objection to the FSF using my GCC work (they
are free to do so, like all users are, thanks to the excellent GPL). But I
no longer want to be required to give them the copyright or ownership of
that work.

But for various reasons being passive consumers of a non-FSF GCC probably
wouldn't be popular, so a fork may be for the best.

>
> FWIW, again speaking personally, I would be in favour of joining a fork.[*]
>

Glad to hear it :-)

I will be forking, alone if necessary, but I've already been told by a few
people I won't be alone.

Re: GCC association with the FSF

2021-04-11 Thread David Brown

On 11/04/2021 16:37, Richard Kenner via Gcc wrote:
>> I guess my point is that the direction in which a project *does* go is not
>> always the direction in which it *should* go.  
> 
> I agree.  And depending on people's "political" views, that can either be
> an advantage or disadvantage of the free software development model.
> 
>> To give just one small practical example, I'm told (by people who are more
>> familiar with GCC internals than I) that it is not feasible with today's
>> GCC to port to backends which have a small number of registers.
> 
> [Finally, a technical discussion in this thread!]
> 
> It never really has been.  Maybe it's not even possible now (I don't
> know), but if you tried it in the past the results would never have
> been very good.  Almost all multi-backend systems operate by having
> very large numbers of expressions at all levels, which you gradually
> lower to actual registers.  This works quite well if you have enough
> registers to hold the high-usage expressions in them, but when you
> have high register pressure, the model breaks down completely.
> Although the situation may well have gotten worse in recent versions
> that I'm not familiar with, I'd say that GCC was probably doing a
> *better* job with a small number of registers in more recent versions
> than in older ones: "reload" was particularly bad when there was high
> register pressure.
> 
> When your main constraint is register pressure, in order to get
> high-quality results, I think you almost have to change the entire
> philosophy of compilation, to the point I think where you have an
> almost entirely different compilation chain for such machines.
> 

Low register count cpu designs have been out of fashion for quite some
time now (perhaps precisely because they are not a good fit for common
compiler strategies).  They are mostly found in older families, such as
the 8-bit CISC designs in older microcontrollers (8051, PIC, COP8, 6502,
etc.).  And you are absolutely right that you need a different way of
thinking in order to get the best out of such chips - low register count
is only one aspect.  Other issues are few or no flexible pointer
registers, no "SP + offset" addressing modes for efficient parameters or
stack frames, banked ram and code blocks, and multiple separate address
spaces.  Good toolchains for such devices need to work in a very
different way, and typically encompass compilation, assembling and
linking in one "omniscient" build so that variables, parameters, etc.,
can be placed statically in ways that minimise banking and maximise
reuse, based on lifetime analysis of the whole program.

This would be a massively different way of working from how gcc does
things now, and given that such devices are very much on the decline
(when 32-bit ARM microcontrollers can be bought for 30 cents, smaller
and cheaper cpu cores are rarely the right choice for a new design), it
would not make sense to spend the effort supporting them in gcc.  There
is, after all, quite a solid GPL'ed compiler toolchain for such devices
at .

Re: [committed] ada: Avoid invalid "up" link in manual

2021-04-11 Thread Gerald Pfeifer

On Sun, 11 Apr 2021, Arnaud Charlet wrote:
>> With this patch the bottom navigation of the page at
>>  https://gcc.gnu.org/onlinedocs/gnat_ugn/index.html
>> changes from
>>   Next: About This Guide, Up: (dir)   [Contents][Index]
>> to 
>>  Next: About This Guide   [Contents][Index]
>> and the invalid "(dir)" link that pointed to
>>  http://gcc.gnu.org/onlinedocs/dir/index.html
>> which does not exist is gone.
> Well the master is the rest/sphinx files in doc, the texi file is auto 
> generated, so your change will dispapear at the next generation.

You're right, good catch, Arnaud!

How can we fix this at the root, then? I'm not sufficiently familiar
with Sphinx and did not find where we might change that.

Is there a newer version of Sphinx available to avoid this?

Gerald

Re: GCC association with the FSF

2021-04-11 Thread David Malcolm via Gcc

On Sun, 2021-04-11 at 14:07 +0100, Frosku wrote:
> On Sun Apr 11, 2021 at 11:08 AM BST, Didier Kryn wrote:
> > Le 08/04/2021 à 17:00, David Brown a écrit :
> > > At some point, someone in the public relations
> > > department at IBM, Google, Facebook, ARM, or other big supporters
> > > of the
> > > project will get the impression that the FSF and GNU are lead by
> > > a
> > > misogynist who thinks child abuse is fine if the child consents,
> > > and
> > > will cut off all support from the top down.  The other companies
> > > will
> > > immediately follow. 
> > 
> > Here we are. The liberty of expressing opinions is too much of a
> > liberty. This is ironical to read in a mailing list dedicated in
> > some to
> > a free software project.
> 
> He's actually recanted his views about 'consensual pedophilia', which
> is
> testament to the benefits of open dialogue. 

Wow.  Just... wow.

I've been trying to ignore this thread for the sake of my mental health
- it's been going on for 2 weeks now - but I feel I have to speak up
about how wrong-headed the above seems to me.

I don't want to be in an environment where, it turns out, the leader of
the non-profit that owns copyright on the bulk of the last 8 years of
my work, and controls the license on the bulk of my work for the last
20 years, has to be patiently coached in why pedophilia is bad.  Most
reasonable people would run a mile from such an environment.  Think of
what the FSF could have achieved if RMS hadn't driven away all but the
most patient and dedicated people, and the effort exhausted by those
that remain on enabling [1] him to continue in his "leadership" role.

At one time, RMS was a hero and inspiration to me; I remember cutting
out newspaper articles about him when I was in school, and I own a copy
of his book, which he signed for me.  However, that book has been in my
attic for a while now, gathering dust, which seems symbolic to me.

I hope that the FSF can be saved; it would be deeply damaging to
software freedom for it to finish imploding.  It would also be very
inconvenient for those of us trying to improve GCC.

For those with ears to listen, Luis Villa posted this excellent
article, with plenty of ideas on how to save the FSF:
  https://lu.is/blog/2021/04/07/values-centered-npos-with-kmaher/
which I'll quote part of here:

"Many in the GNU and FSF communities seem to worry that moving past RMS
somehow means abandoning software freedom, which should not be the
case. If anything, this should be an opportunity to re-commit to
software freedom - in a way that is relevant and actionable given the
state of the software industry in 2021."

In the meantime, I don't know what GCC should do, but I feel like I
need to go for a walk in the woods to clear my head, away from a
keyboard, rather than spending any more of my weekend stressing about
the project.

I hope this is constructive.  These are my opinions, and not
necessarily those of my employer - though Red Hat has stated that it is
"appalled" at RMS's return to the FSF board [2], and part of my job is
to care about the future of GCC.

Dave

[1] see e.g. https://www.healthline.com/health/enabler
[2] 
https://www.redhat.com/en/blog/red-hat-statement-about-richard-stallmans-return-free-software-foundation-board

[Bug ipa/100034] New: missed optimization for dead code elimination at -O3 (vs. -O1, -Os, -O2)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100034

Bug ID: 100034
   Summary: missed optimization for dead code elimination at -O3
(vs. -O1, -Os, -O2)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

[641] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210411 (experimental) [master revision
1d54b138417:e83b9cf4549:936d500dfc17f58f2507ecd0f7f26e4f197052ee] (GCC) 
[642] % 
[642] % gcctk -O1 -S -o O1.s small.c
[643] % gcctk -O3 -S -o O3.s small.c
[644] % 
[644] % wc O1.s O3.s
  23   45  420 O1.s
  41   78  697 O3.s
  64  123 1117 total
[645] % 
[645] % grep foo O1.s
[646] % grep foo O3.s
callfoo
[647] % 
[647] % cat small.c
extern void foo(void);
static int a, b, f, g;
static int d() {
  while (g)
f = 0;
  while (1)
foo();
}
static void c() { d (); }
void e() {
  while (b) {
if (!a)
  continue;
c();
  }
}
int main() {
  e();
  return 0;
}

Re: GCC association with the FSF



> Sent: Monday, April 12, 2021 at 2:03 AM
> From: "David Brown" 
> To: "Alfred M. Szmidt" , gcc@gcc.gnu.org
> Subject: Re: GCC association with the FSF
>
> On 11/04/2021 15:39, Alfred M. Szmidt wrote:
> >It should remain an acronym, but it should now stand for "GCC Compiler
> >Collection".  That allows the project to be disassociated from the GNU
> >name while still subtly acknowledging its heritage.
> >
> > Then it would not longer be GCC.  It would be something different.
> > The whole point of GCC is to provide a free software compiler for the
> > GNU system and systems based on GNU, and not to be pragmatic at the
> > cost of software freedom.  Commercial interessts are often at odds
> > with software freedom as well.  This is one of the many reasons why
> > the GNU project is entierly volunteer based.
> >
>
> It is decades since gcc has been /just/ a free compiler for the GNU
> system.  That is still an important role, of course, but the compiler's
> use has vastly outgrown that area.  The same applies to most of the GNU
> projects.
>
> And while I agree that commercial interests are /sometimes/ at odds with
> free software, they are also essential for it - GNU would never have
> existed without commercial software, and most or all of its projects
> would have languished without commercial interest.

Commercial interests are not at odds, provided some rules are followed

> (Look, for example,
> at the Hurd project - it is absolutely critical to the concept of having
> a complete software system using only free software, but it is of almost
> no commercial interest to anyone.  And thus it has had negligible
> progress.)
>
> Like it or not, money is essential to the way the world works, and
> commercial interests are unavoidable.  You can make them work for you
> while keeping the values and ideals you hold dear (such as by having
> volunteers for development, with contributions and leadership
> appointments being personal, while letting a commercial organisation pay
> your wages).  Commercial interests are generally only a problem if you
> let them be a problem.

As aspirations grow, money is an enabling process.  A tool created to simplify 
transactions.  And things are evolving so that transactions become digital,
where money in the traditional sense does not exist.  The problem is when money
becomes a goal by itself.

To be successful, we need the cooperation of many forces present in our
surroundings, including our employers or people who do business with us.

> > But I'd hope that we can avoid words like "fanaticism", "childish",
> > "cultish" simply because of disagreement in philosophies or continuing
> > to spread obvious misunderstandings of what someone wrote, it is not
> > constructive and only causes unnsesescary agitation.

Re: GCC association with the FSF

2021-04-11 Thread zhendong.su at inf dot ethz.ch via Gcc-bugs

> I guess my point is that the direction in which a project *does* go is not
> always the direction in which it *should* go.  

I agree.  And depending on people's "political" views, that can either be
an advantage or disadvantage of the free software development model.

> To give just one small practical example, I'm told (by people who are more
> familiar with GCC internals than I) that it is not feasible with today's
> GCC to port to backends which have a small number of registers.

[Finally, a technical discussion in this thread!]

It never really has been.  Maybe it's not even possible now (I don't
know), but if you tried it in the past the results would never have
been very good.  Almost all multi-backend systems operate by having
very large numbers of expressions at all levels, which you gradually
lower to actual registers.  This works quite well if you have enough
registers to hold the high-usage expressions in them, but when you
have high register pressure, the model breaks down completely.
Although the situation may well have gotten worse in recent versions
that I'm not familiar with, I'd say that GCC was probably doing a
*better* job with a small number of registers in more recent versions
than in older ones: "reload" was particularly bad when there was high
register pressure.

When your main constraint is register pressure, in order to get
high-quality results, I think you almost have to change the entire
philosophy of compilation, to the point I think where you have an
almost entirely different compilation chain for such machines.

[Bug tree-optimization/100033] New: missed optimization for dead code elimination at -O3 (vs. -O2)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100033

Bug ID: 100033
   Summary: missed optimization for dead code elimination at -O3
(vs. -O2)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

[583] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210411 (experimental) [master revision
1d54b138417:e83b9cf4549:936d500dfc17f58f2507ecd0f7f26e4f197052ee] (GCC) 
[584] % 
[584] % gcctk -O2 -S -o O2.s small.c
[585] % gcctk -O3 -S -o O3.s small.c
[586] % 
[586] % wc O2.s O3.s
  52  112  797 O2.s
  56  119  850 O3.s
 108  231 1647 total
[587] % 
[587] % grep foo O2.s
[588] % grep foo O3.s
callfoo
[589] % 
[589] % cat small.c
extern void foo(void);
static volatile int a;
int b, i;
static void c() {
  unsigned d = i;
  a = d && a;
  if (d) {
int e;
while (b) {
  int *f, *g = , **h = 
  *h = g;
  *f = d;
}
if (!e)
  foo();
  }
}
int main() {
  c();
  return 0;
}

Re: GCC association with the FSF

2021-04-11 Thread John Darrington

On Sun, Apr 11, 2021 at 09:30:48AM -0400, Richard Kenner via Gcc wrote:
 > > When it comes to deciding the direction of a project like GCC - 
technical 
 > > and otherwise - in my mind it primarily should be those actually 
involved 
 > > and contributing.
 > 
 > GNU follows the general principle of the Free Software movement, that
 > freedom for *users* is the priority.  Assigning *higher* importance to
 > developers' preferences is *not* a position I share.

 I think there's a difference between philosophy and practicality here.
 Sure, the importance of work done by different developers, measured on
 the scale of advancing the goals of the Free Software movement, is
 different for each.  But what actually advances a project (which can
 be viewed as "deciding [its] direction") is what work developers
 choose to do, not the importance of each piece of work on that metric.

I guess my point is that the direction in which a project *does* go is not
always the direction in which it *should* go.  I conceed that the converse
is also true:  Technical experts are very useful for putting the brakes on
Joe Average User's crazy ideas when they are doomed to failure from the outset.

 So I certainly agree with what you said above, but don't think that
 changes the reality that it's ultimately what developers choose to
 work on that most affects the direction of a project.

That indeed is often the reality, but equally as often *not* what is desired.
To give just one small practical example, I'm told (by people who are more
familiar with GCC internals than I) that it is not feasible with today's
GCC to port to backends which have a small number of registers.   This has
meant that whole familys of CPUs work only with proprietary compilers.

J'

Re: GCC association with the FSF

> Then it would not longer be GCC.  It would be something different.
> The whole point of GCC is to provide a free software compiler for the
> GNU system and systems based on GNU, and not to be pragmatic at the
> cost of software freedom.

Certainly that was its initial intent, but I'd argue that at this
point, the main value of GCC to the Free Software movement is that its
extensive use outside of the GNU system makes people aware of the
movement and of the quality of its software.

> Commercial interessts are often at odds with software freedom as
> well.  This is one of the many reasons why the GNU project is
> entierly volunteer based.

Although that's true, I strongly suspect that the majority of actual
work done on GCC is commercially funded.

> But I'd hope that we can avoid words like "fanaticism", "childish",
> "cultish" simply because of disagreement in philosophies or continuing
> to spread obvious misunderstandings of what someone wrote, it is not
> constructive and only causes unnsesescary agitation.

Agreed!

Re: GCC association with the FSF

On Sun, 11 Apr 2021, 15:15 Christopher Dimech via Gcc, 
wrote:

>
> The free software community is much similar to India.  A conscious chaos
> where you can't teach discipline.  People will feel home sick if there is
> too much order.
>
> People are trying to put a western template, but the first freedom is to be
> able to work for any purpose.  Using free software even for genocide if you
> want.  We should not demand people  to fit into another format which is not
> theirs.  The free software movement is too complex and too
> multi-dimensional
> multi-ethnical - everything multi-.
>
> The free software movement needs a very organic leadership, and not a
> synthetic
> leadership that drops there because they have won some argument with
> somebody
> else.  People have to understand that nation is just an idea, not some god
> giving
> thing.  Even the poorest and in the remotest place in the world, even there
> one can get to use and adapt free software as he wishes.
>


Would you PLEASE take these abstract musings about Free Software somewhere
else, like gnu-misc-discuss, so we can discuss GCC, not your bullshit?

Re: GCC association with the FSF

On Sun, 11 Apr 2021, 14:59 Alexandre Oliva via Gcc,  wrote:

> On Apr 10, 2021, Gerald Pfeifer  wrote:
>
> > When it comes to deciding the direction of a project like GCC -
> technical
> > and otherwise - in my mind it primarily should be those actually
> involved
> > and contributing.
>
> GNU follows the general principle of the Free Software movement, that
> freedom for *users* is the priority.  Assigning *higher* importance to
> developers' preferences is *not* a position I share.
>

Freedom for users is provided by the licences of the GCC code. Any
particular form of leadership or veneration of the project founder is not
required for that be true. Unless maybe I'm still misreading the four
freedoms, or maybe they are not a proper description of the principles.
Maybe the four freedoms need to be corrected to add this implicit
requirement that association with a particular group is necessary. Could
you look into that please, Alex?

Re: GCC association with the FSF

2021-04-11 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

> Sent: Monday, April 12, 2021 at 1:11 AM
> From: "Richard Kenner" 
> To: dim...@gmx.com
> Cc: david.br...@hesbynett.no, g...@gnu.org, rodg...@appliantology.com
> Subject: Re: GCC association with the FSF
>
> > > > So, that's a solid 'no' on the likelihood of you contributing
> > > > anything of value to the discussion of GCC governance then?
> > >
> > > I really think that most of the people replying on this thread have a
> > > much more encompassing view of "GCC governance" than actually exists.
> >
> > If the community makes it too hard by demanding too much (which
> > seems to me that it is bending towards the merely bureaucratic),
> > people would be discouraged to serve on it.
>
> I'm sorry, what is it that you think that the "community" (whatever
> that is) is demanding too much of?

Some have been saying that leaders are representatives of the whole
free software users, and if mistakes happen, they would tarnish everybody.
And then a situation similar to this one starts all over again.

I would say that it is the organisers of events that have such responsibility.

Re: GCC association with the FSF

2021-04-11 Thread David Brown

On 11/04/2021 15:39, Alfred M. Szmidt wrote:
>It should remain an acronym, but it should now stand for "GCC Compiler
>Collection".  That allows the project to be disassociated from the GNU
>name while still subtly acknowledging its heritage.
> 
> Then it would not longer be GCC.  It would be something different.
> The whole point of GCC is to provide a free software compiler for the
> GNU system and systems based on GNU, and not to be pragmatic at the
> cost of software freedom.  Commercial interessts are often at odds
> with software freedom as well.  This is one of the many reasons why
> the GNU project is entierly volunteer based.
> 

It is decades since gcc has been /just/ a free compiler for the GNU
system.  That is still an important role, of course, but the compiler's
use has vastly outgrown that area.  The same applies to most of the GNU
projects.

And while I agree that commercial interests are /sometimes/ at odds with
free software, they are also essential for it - GNU would never have
existed without commercial software, and most or all of its projects
would have languished without commercial interest.  (Look, for example,
at the Hurd project - it is absolutely critical to the concept of having
a complete software system using only free software, but it is of almost
no commercial interest to anyone.  And thus it has had negligible
progress.)

Like it or not, money is essential to the way the world works, and
commercial interests are unavoidable.  You can make them work for you
while keeping the values and ideals you hold dear (such as by having
volunteers for development, with contributions and leadership
appointments being personal, while letting a commercial organisation pay
your wages).  Commercial interests are generally only a problem if you
let them be a problem.

> But I'd hope that we can avoid words like "fanaticism", "childish",
> "cultish" simply because of disagreement in philosophies or continuing
> to spread obvious misunderstandings of what someone wrote, it is not
> constructive and only causes unnsesescary agitation.
>

[Bug middle-end/98088] [9/10/11 Regression] ICE in expand_oacc_collapse_init, at omp-expand.c:1533

2021-04-11 Thread abidh at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98088

Hafiz Abid qadeer  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #5 from Hafiz Abid qadeer  ---
Fixed in ac200799acb5cd2fb9e1758f6bf5fff1978daaeb.

[Bug middle-end/98088] [9/10/11 Regression] ICE in expand_oacc_collapse_init, at omp-expand.c:1533

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98088

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Hafiz Abid Qadeer :

https://gcc.gnu.org/g:ac200799acb5cd2fb9e1758f6bf5fff1978daaeb

commit r11-8123-gac200799acb5cd2fb9e1758f6bf5fff1978daaeb
Author: Hafiz Abid Qadeer 
Date:   Thu Apr 8 17:31:30 2021 +0100

[OpenACC] Fix an ICE where a loop with GT condition is collapsed.

We have seen an ICE both on trunk and devel/omp/gcc-10 branches which can
be reprodued with this simple testcase.  It occurs if an OpenACC loop has
a collapse clause and any of the loop being collapsed uses GT or GE
condition.  This issue is specific to OpenACC.

int main (void)
{
  int ix, iy;
  int dim_x = 16, dim_y = 16;
  {
   for (iy = dim_y - 1; iy > 0; --iy)
   for (ix = dim_x - 1; ix > 0; --ix)
;
  }
}

The problem is caused by a failing assertion in expand_oacc_collapse_init.
It checks that cond_code for fd->loop should be same as cond_code for all
the loops that are being collapsed.  As the cond_code for fd->loop is
LT_EXPR with collapse clause (set at the end of omp_extract_for_data),
this assertion forces that all the loop in collapse clause should use
< operator.

There does not seem to be anything in the code which demands this
condition as loop with > condition works ok otherwise.  I digged old
mailing list a bit but could not find any discussion on this change.
Looking at the code, expand_oacc_for checks that fd->loop->cond_code is
either LT_EXPR or GT_EXPR.  I guess the original intention was to have
similar checks on the loop which are being collapsed. But the way check
was written does not acheive that.

I have fixed it by modifying the check in the assertion to be same as
check on fd->loop->cond_code.

I tested goacc and libgomp (with nvptx offloading) and did not see any
regression.  I have added new tests to check collapse with GT/GE condition.

PR middle-end/98088
gcc/
* omp-expand.c (expand_oacc_collapse_init): Update condition in
a gcc_assert.

gcc/testsuite/
* c-c++-common/goacc/collapse-2.c: New.

libgomp/
* testsuite/libgomp.oacc-c-c++-common/collapse-2.c: Add check
for loop with GT/GE condition.
* testsuite/libgomp.oacc-c-c++-common/collapse-3.c: Likewise.

Re: GCC association with the FSF

On Sun, 11 Apr 2021, 13:31 John Darrington wrote:

>
> For myself, I have been a long term user/contributor to GCC albiet hardly
> in
> a major role.   I don't think I've ever posted to this list until a few
> days
> ago, when all of a sudden these messages started popping up in my inbox.
> So
> either I subscribed to this list many years ago and it has been dormant
> until
> recently or someone subscribed me just recently.
>

I don't know who changed the Cc from gcc@gcc.gnu.org to g...@gnu.org but I
think they're the same destination.
You can check the archives, the list has been highly active for decades.
Maybe somebody subscribed you to help brigade this list. If you don't want
the mails, the mail headers have unsubscribe instructions, and there's a
form at https://gcc.gnu.org/lists.html

Re: GCC association with the FSF

2021-04-11 Thread Richard Sandiford via Gcc

[ Like many others who have posted to this thread, I've contributed
  to GCC at various times as a hobby and at other times as a paid
  employee.  Here I'm speaking as a personal contributor, not on
  behalf of my current employer. ]

I think it's misleading to talk about GCC “leaving” or “disassociating
itself” from the FSF or from the GNU project.  No-one can force the FSF or
the GNU project to drop GCC (and I don't think anyone's trying to make it
do that).  I think what we're really talking about is whether there should
be a fork.  In some ways that would be like egcs, although perhaps this time
it would be a clean break, without intending the fork to “rejoin” GNU later.

If the fork takes the current gcc.gnu.org infrastructure with it,
the GNU project would have to maintain its version of GCC elsewhere.
But that would be a minor barrier at most.  The likelihood is that there
would be two versions of GCC, which for want of better terms I'll call
“FSF GCC” and “new GCC”.  If FSF GCC does continue as a project in any
meaningful sense, new GCC would be able to cherry-pick useful contributions
from FSF GCC.  Cherry-picking in the opposite direction would also be
technically and legally possible, but would presumably be rejected on
principle by whoever the new FSF GCC maintainers turn out to be (not least
because “new GCC” commits would not be FSF copyright).

This should also satisfy those who believe that only an FSF-copyright
GCC is trustworthy.  People who only trust the FSF can contribute to
and use “FSF GCC” and ignore “new GCC”.

So I think the question becomes: how many GCC developers and organisations
are willing to agree to follow the fork rather than stick with FSF GCC?
Does anyone have any suggestions for a good procedure for testing the
level of support?  I don't think this mailing list is it.

(It's ironic that the process of answering that question shows how
misplaced a lot of the comments about the SC were.  GCC is fundamentally
a developer/contributor-led project, so even an important decision like
this will be made by developers/contributors rather than the SC.)

FWIW, again speaking personally, I would be in favour of joining a fork.[*]

Mark Wielaard  writes:
> On Wed, Apr 07, 2021 at 10:04:21AM -0400, David Malcolm wrote:
> > Another, transitional approach might be to find another Free Software
> > non-profit and for contributors to start assigning copyright on ongoing
> > work to that other non-profit.  That way there would be only two
> > copyright holders on the code; if the FSF somehow survives its current
> > death-spiral then the other nonprofit could assign copyright back to
> > the FSF;  if it doesn't, well, we've already got bigger problems.
>
> Yes, having all new copyrights pooled together so we have just two
> copyright holders would provide most of the same benefits. And makes
> it easier to deal with the legacy FSF copyrights since there would be
> just one legal entity having to deal with them instead of each
> individual copyright holder on their own.

It sounds like it could be the worst of both worlds in some ways though.
There would no longer be a single entity that could relicense the code,
if that became necessary for any reason, yet we would still require all
contributors to go through the off-putting process of assigning copyright.

I think it would be better to have voluntary aggregation of copyright
(for those in a position to offer it) while also allowing contributors
to retain copyright if they prefer.  If enough regular contributors
agree to pool copyright then that should be enough.

> If it has to come to this then we could take a look at what the
> Conservancy already does for aggregating copyright for their member
> projects, the Linux kernel and Debian project:
> https://sfconservancy.org/copyleft-compliance/
>
> I like their idea of having a counsel of developers that gets involved
> in any action taken on behave of the collective:
> https://sfconservancy.org/docs/blank_linux-enforcement-agreement.pdf

I'm not familiar with this system, but yeah, I agree that it looks on the
face of it like a good approach, provided that it's strictly voluntary.

Thanks,
Richard

[*] Not that anyone should care or is likely to care, but for the record,
my reasons are:

The FSF and the GNU project have had a key historical role in developing
and promoting free software as a concept.  But history is one thing and
the future is another.  Due to the success of the early advocacy work,
free software now exists as a principle independently of the FSF and
the GNU project.  And the FSF has provided copyleft licenses that have
stood the test of time.  So like others have said, the question for
the future is: do we as contributors gain anything by having any new
work we do be owned by the FSF and associated with the GNU project?

I think the recent developments, as well as the messages in this
email thread that supposedly give reasons

Re: GCC association with the FSF

2021-04-11 Thread Alfred M. Szmidt via Gcc

   It should remain an acronym, but it should now stand for "GCC Compiler
   Collection".  That allows the project to be disassociated from the GNU
   name while still subtly acknowledging its heritage.

Then it would not longer be GCC.  It would be something different.
The whole point of GCC is to provide a free software compiler for the
GNU system and systems based on GNU, and not to be pragmatic at the
cost of software freedom.  Commercial interessts are often at odds
with software freedom as well.  This is one of the many reasons why
the GNU project is entierly volunteer based.

But I'd hope that we can avoid words like "fanaticism", "childish",
"cultish" simply because of disagreement in philosophies or continuing
to spread obvious misunderstandings of what someone wrote, it is not
constructive and only causes unnsesescary agitation.

Re: GCC association with the FSF





> Sent: Monday, April 12, 2021 at 1:07 AM
> From: "Frosku" 
> To: "Didier Kryn" , gcc@gcc.gnu.org
> Subject: Re: GCC association with the FSF
>
> On Sun Apr 11, 2021 at 11:08 AM BST, Didier Kryn wrote:
> > Le 08/04/2021 à 17:00, David Brown a écrit :
> > > At some point, someone in the public relations
> > > department at IBM, Google, Facebook, ARM, or other big supporters of the
> > > project will get the impression that the FSF and GNU are lead by a
> > > misogynist who thinks child abuse is fine if the child consents, and
> > > will cut off all support from the top down.  The other companies will
> > > immediately follow. 
> >
> > Here we are. The liberty of expressing opinions is too much of a
> > liberty. This is ironical to read in a mailing list dedicated in some to
> > a free software project.
> 
> He's actually recanted his views about 'consensual pedophilia', which is
> testament to the benefits of open dialogue. By having discussions and
> arguing points, we can convince people that they are wrong. By shunning them,
> we do nothing to change their views and everything to make them believe we
> don't have any real arguments.
> 
> As distasteful as I find such a view, I don't think that anybody should be
> banished for polite society for thoughtcrimes. We can judge people for their
> actions, but there's no evidence or even suggestion that he has ever harmed
> a child.
> 
> > But you are wrong on a point. The bannishment or RMS isn't being
> > called by big companies or their customers. In the same way that Donald
> > Trump's accounts on social networks have been closed on request of
> > employees of these networks, here the employees of the same social
> > networks and other companies call for the bannishment of RMS.
> >
> > "My opinion, not my employer's" is probably true. If the majority of
> > employees call for lynching someone, the employer let them do because
> > s(?)he is concerned by the cash flow first, not ideology.
> 
> I'm not 100% convinced by this. RMS has made some enemies in the corporate
> space who probably aren't too unhappy to see this division in our community
> over him.
> 
> > I agree that the constitution of FSF, GNU, and GCC would gain to be
> > clarified and cleared from some childich relics, but that doesn't mean
> > the banishment of anyone and doesn't justify the cabal we have seen on
> > this list.
> >
> > Social networks, besides their likely utility, are a place where
> > hatred builds up pretty easily by mutual excitation because people get
> > the illusion they're right when they're many. This has always existed
> > amongst humans but social networks ease and boost this trend. This is
> > one good reason to keep away.
> >
> > > ... no one can
> > > be in doubt that [RMS's] attitudes and behaviour are not acceptable by
> > > modern standards and are discouraging to developers and users in the
> > > FOSS community.
> >
> > It is obviously wrong that "no one can". Several persons have
> > expressed their disagreement whith these statements. Or do you mean "no
> > one is allowed to"?
> 
> I'm in doubt that anyone can claim to speak for the diaspora of ideas and
> principles that is the free software community. We have participants from
> all corners of the globe, all religions, all political stances. It would
> probably be hard to find unanimous agreement among us on anything, other
> than perhaps that free software is a desirable thing.

The free software community is much similar to India.  A conscious chaos
where you can't teach discipline.  People will feel home sick if there is
too much order.

People are trying to put a western template, but the first freedom is to be
able to work for any purpose.  Using free software even for genocide if you
want.  We should not demand people  to fit into another format which is not
theirs.  The free software movement is too complex and too multi-dimensional 
multi-ethnical - everything multi-.

The free software movement needs a very organic leadership, and not a synthetic
leadership that drops there because they have won some argument with somebody
else.  People have to understand that nation is just an idea, not some god 
giving
thing.  Even the poorest and in the remotest place in the world, even there
one can get to use and adapt free software as he wishes.   
 
> > What do you mean by "modern standards"? Do you realy think there are
> > standards for political correctness? Is it an ISO? POSIX? IEEE? Sorry
> > for the easy joke. Probably you could express better what you mean (~:
> >
> > Le 10/04/2021 à 14:50, Bronek Kozicki via Gcc a écrit :
> > > Hello there
> > >
> > > As a long time GCC user, who is also a father to teenage children, I would
> > > very much prefer if a person who openly expressed opinions, and also 
> > > openly
> > > exercised behaviours, which I consider abhorrent, was *not* associated 
> > > with
> > > the GCC project.
> >
> > I bet you would also prefer that this person doesn't live on the
>

Re: GCC association with the FSF

> I feel like this should be even more evident when dealing with
> something like a compiler toolchain. GCC's user is likely to be
> another free software project's contributor (as is my case).

I suspect that's not true.  It certainly wasn't true when more major
large companies used GCC to compile their products and I doubt it's even
true now when many have switched to other compilers.

Re: GCC association with the FSF

2021-04-11 Thread ppalka at gcc dot gnu.org via Gcc-bugs

> > When it comes to deciding the direction of a project like GCC - technical 
> > and otherwise - in my mind it primarily should be those actually involved 
> > and contributing.
> 
> GNU follows the general principle of the Free Software movement, that
> freedom for *users* is the priority.  Assigning *higher* importance to
> developers' preferences is *not* a position I share.

I think there's a difference between philosophy and practicality here.
Sure, the importance of work done by different developers, measured on
the scale of advancing the goals of the Free Software movement, is
different for each.  But what actually advances a project (which can
be viewed as "deciding [its] direction") is what work developers
choose to do, not the importance of each piece of work on that metric.
So I certainly agree with what you said above, but don't think that
changes the reality that it's ultimately what developers choose to
work on that most affects the direction of a project.

[Bug c++/100032] [8/9/10/11 Regression] renaming alias template that also adds cv-qualifiers is deemed equivalent to underlying template

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100032

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |8.5
 CC||jason at gcc dot gnu.org
Summary|renaming alias template |[8/9/10/11 Regression]
   |that also adds  |renaming alias template
   |cv-qualifiers is deemed |that also adds
   |equivalent to underlying|cv-qualifiers is deemed
   |template|equivalent to underlying
   ||template

--- Comment #1 from Patrick Palka  ---
We started accepting the testcase after r208152.

I tried making get_underlying_template look through an alias only if the
underlying type is unqualified:

--- a/gcc/cp/pt.c   
+++ b/gcc/cp/pt.c   
@@ -6574,6 +6574,8 @@ get_underlying_template (tree tmpl)   
   /* The underlying type may have been ill-formed. Don't proceed.  */  
   if (!orig_type)  
break;  
+  if (TYPE_QUALS (orig_type) != TYPE_UNQUALIFIED)  
+   break;  
   tree tinfo = TYPE_TEMPLATE_INFO_MAYBE_ALIAS (orig_type); 
   if (!tinfo)  
break;  

but this also makes us (incorrectly?) reject

template  class> struct X { };
template  struct Y { };
template  using Z = const Y;
template  using W = Z;
using U = X;
using U = X;

because the underlying type of W for some reason already has the const
qualifier, so get_underlying_template(W) yields W and we deem W not equivalent
to Z.

Re: GCC association with the FSF

2021-04-11 Thread Frosku

On Sun Apr 11, 2021 at 2:23 PM BST, Alexandre Oliva via Gcc wrote:
> On Apr 10, 2021, Gerald Pfeifer  wrote:
>
> > When it comes to deciding the direction of a project like GCC - technical 
> > and otherwise - in my mind it primarily should be those actually involved 
> > and contributing.
>
> GNU follows the general principle of the Free Software movement, that
> freedom for *users* is the priority. Assigning *higher* importance to
> developers' preferences is *not* a position I share.

I feel like this should be even more evident when dealing with something like
a compiler toolchain. GCC's user is likely to be another free software project's
contributor (as is my case).

Re: GCC association with the FSF

> The principle by which high level decisions in all GNU projects have
> always been made is how it best helps the GNU system as a whole.
> Contributors are exactly that.  They offer *contributions* - the
> very meaning of the word implies there is no expectation of anything
> in return.  Obviously I hope all contributors *do* get some
> satisfaction and maybe even some tangible benefit.  But
> contributions are not to be seen as a means to gain control of the
> project at a high level.

I agree with most of that, but all *actual* changes to a project are done
by contributors.  If somebody makes a "high level decision" to do a certain
thing to GCC, but no contributor steps up to do that thing, it won't get
done.  Conversely, if some contributor decided to do some thing (e.g., add
an optimization) that nobody made a "high level decision" to do, that
thing *will* get done, since it's unusual to reject such contributions,
assuming they're technically sound.

So I think that the bulk of the "power", from a practical standpoint, is
in the hands of the contributors, not some high-level group.

Re: GCC association with the FSF

2021-04-11 Thread david.bolvansky at gmail dot com via Gcc-bugs

On Apr 10, 2021, Gerald Pfeifer  wrote:

> When it comes to deciding the direction of a project like GCC - technical 
> and otherwise - in my mind it primarily should be those actually involved 
> and contributing.

GNU follows the general principle of the Free Software movement, that
freedom for *users* is the priority.  Assigning *higher* importance to
developers' preferences is *not* a position I share.

-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

[Bug target/98348] [10 Regression] GCC 10.2 AVX512 Mask regression from GCC 9

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98348

Dávid Bolvanský  changed:

   What|Removed |Added

 CC||david.bolvansky at gmail dot 
com

--- Comment #20 from Dávid Bolvanský  ---
Some small regression (missed opportunity to use vptestnmd):

Current trunk

compare(unsigned int __vector(16)):
  vpxor xmm1, xmm1, xmm1
  vpcmpd k0, zmm0, zmm1, 0
  vpmovm2d zmm0, k0
  ret

GCC 9.2

compare(unsigned int __vector(16)):
  vptestnmd k0, zmm0, zmm0
  vpmovm2d zmm0, k0
  ret


https://gcc.godbolt.org/z/5vK68jM3r

[Bug c++/100032] New: renaming alias template that also adds cv-qualifiers is deemed equivalent to underlying template

2021-04-11 Thread ppalka at gcc dot gnu.org via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100032

Bug ID: 100032
   Summary: renaming alias template that also adds cv-qualifiers
is deemed equivalent to underlying template
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppalka at gcc dot gnu.org
  Target Milestone: ---

DR 1286 allows alias templates to be equivalent to the underlying template if
the alias is just a renaming of the underlying template.  In the testcase
below, Z is arguably not equivalent to Y because of the added const qualifier,
but GCC still deems them equivalent, and accepts the testcase.

template  class> struct X { };
template  struct Y { };
template  using Z = const Y;
using T = X;
using T = X;

Re: GCC association with the FSF

> When it comes to deciding the direction of a project like GCC - technical 
> and otherwise - in my mind it primarily should be those actually involved 
> and contributing.

I agree, but I'm not clear if you're claiming that that is or is not
currently the case.  I believe it is.

Re: GCC association with the FSF

> > > So, that's a solid 'no' on the likelihood of you contributing
> > > anything of value to the discussion of GCC governance then?
> >
> > I really think that most of the people replying on this thread have a
> > much more encompassing view of "GCC governance" than actually exists.
> 
> If the community makes it too hard by demanding too much (which
> seems to me that it is bending towards the merely bureaucratic),
> people would be discouraged to serve on it.

I'm sorry, what is it that you think that the "community" (whatever
that is) is demanding too much of?

Re: GCC association with the FSF

2021-04-11 Thread Frosku

On Sun Apr 11, 2021 at 11:08 AM BST, Didier Kryn wrote:
> Le 08/04/2021 à 17:00, David Brown a écrit :
> > At some point, someone in the public relations
> > department at IBM, Google, Facebook, ARM, or other big supporters of the
> > project will get the impression that the FSF and GNU are lead by a
> > misogynist who thinks child abuse is fine if the child consents, and
> > will cut off all support from the top down.  The other companies will
> > immediately follow. 
>
> Here we are. The liberty of expressing opinions is too much of a
> liberty. This is ironical to read in a mailing list dedicated in some to
> a free software project.

He's actually recanted his views about 'consensual pedophilia', which is
testament to the benefits of open dialogue. By having discussions and
arguing points, we can convince people that they are wrong. By shunning them,
we do nothing to change their views and everything to make them believe we
don't have any real arguments.

As distasteful as I find such a view, I don't think that anybody should be
banished for polite society for thoughtcrimes. We can judge people for their
actions, but there's no evidence or even suggestion that he has ever harmed
a child.

> But you are wrong on a point. The bannishment or RMS isn't being
> called by big companies or their customers. In the same way that Donald
> Trump's accounts on social networks have been closed on request of
> employees of these networks, here the employees of the same social
> networks and other companies call for the bannishment of RMS.
>
> "My opinion, not my employer's" is probably true. If the majority of
> employees call for lynching someone, the employer let them do because
> s(?)he is concerned by the cash flow first, not ideology.

I'm not 100% convinced by this. RMS has made some enemies in the corporate
space who probably aren't too unhappy to see this division in our community
over him.

> I agree that the constitution of FSF, GNU, and GCC would gain to be
> clarified and cleared from some childich relics, but that doesn't mean
> the banishment of anyone and doesn't justify the cabal we have seen on
> this list.
>
> Social networks, besides their likely utility, are a place where
> hatred builds up pretty easily by mutual excitation because people get
> the illusion they're right when they're many. This has always existed
> amongst humans but social networks ease and boost this trend. This is
> one good reason to keep away.
>
> > ... no one can
> > be in doubt that [RMS's] attitudes and behaviour are not acceptable by
> > modern standards and are discouraging to developers and users in the
> > FOSS community.
>
> It is obviously wrong that "no one can". Several persons have
> expressed their disagreement whith these statements. Or do you mean "no
> one is allowed to"?

I'm in doubt that anyone can claim to speak for the diaspora of ideas and
principles that is the free software community. We have participants from
all corners of the globe, all religions, all political stances. It would
probably be hard to find unanimous agreement among us on anything, other
than perhaps that free software is a desirable thing.

> What do you mean by "modern standards"? Do you realy think there are
> standards for political correctness? Is it an ISO? POSIX? IEEE? Sorry
> for the easy joke. Probably you could express better what you mean (~:
>
> Le 10/04/2021 à 14:50, Bronek Kozicki via Gcc a écrit :
> > Hello there
> >
> > As a long time GCC user, who is also a father to teenage children, I would
> > very much prefer if a person who openly expressed opinions, and also openly
> > exercised behaviours, which I consider abhorrent, was *not* associated with
> > the GCC project.
>
> I bet you would also prefer that this person doesn't live on the
> same planet as you. Sorry but this is just plain intolerance.
>
> The root of the cabal is there: intolerance. The arguments about
> the behaviour of RMS or the mere fact that his name appears on the web
> page are mostly given (conciously or not) to hide the actual mobile.

Very well summarized, Didier. This is an authoritarian attempt to clamp down on
freedom of thought which is unfortunately being swallowed whole by people who
spend the rest of their time fighting for it. If it is not possible for us -- a
global community representing not only the entire spectrum of American politics
and values, but of global politics and values -- to agree to disagree, then we
are doomed to failure.

Re: GCC association with the FSF