Re: GCC association with the FSF

2021-04-07 Thread John Darrington
On Wed, Apr 07, 2021 at 11:15:14AM -0400, David Malcolm via Gcc wrote: > It reflects the same message that has been sent to new GNU > maintainers > for the decades. The GNU structure and organization document > (https://www.gnu.org/gnu/gnu-structure.en.html) is basically a

Re: GCC association with the FSF

2021-04-07 Thread John Darrington
On Wed, Apr 07, 2021 at 06:34:12PM -0400, David Malcolm wrote: > > What you're describing sounds like a dictatorship to me. > > I cannot see how you reach that conclusion. Having one guy at the top from whom all power flows. Power does not "flow" fro

Re: GCC association with the FSF

2021-04-08 Thread John Darrington
On Thu, Apr 08, 2021 at 07:56:14AM -0400, Richard Kenner wrote: > Having one guy at the top from whom all power flows. > > Power does not "flow" from RMS. Since you have used a political analogy: > I think it is more akin to a constitutional monarchy. I think i

Re: GCC association with the FSF

2021-04-08 Thread John Darrington
On Thu, Apr 08, 2021 at 10:54:25AM -0400, David Malcolm wrote: I think it's important to distinguish between the figurative and literal here. No one is literally calling for anyone's head. Nobody has explicitly done so. However in the last 2 or 3 years there has been a

Re: GCC association with the FSF

2021-04-08 Thread John Darrington
On Thu, Apr 08, 2021 at 09:35:23PM -0400, David Malcolm wrote: > RMS was the first person to be involved in GNU and GCC.  Others > became > involved later (under his leadership).  Their contribution was and > continues to be welcome.  They are also free to stop contributin

Re: GCC association with the FSF

2021-04-09 Thread John Darrington
On Fri, Apr 09, 2021 at 07:01:07PM +0200, David Brown wrote: Different opinions are fine. Bringing national or international politics into the discussion (presumably meant to be as an insult) is not fine. This is not a political discussion - please stop trying to make it

Re: GCC association with the FSF

2021-04-10 Thread John Darrington
On Sat, Apr 10, 2021 at 01:50:42PM +0100, Bronek Kozicki via Gcc wrote: 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. It does not matter to me

Re: GCC association with the FSF

2021-04-11 Thread John Darrington
On Sun, Apr 11, 2021 at 12:30:41AM +0200, Gerald Pfeifer wrote: There are a number of people arguing here who have contributed little to nothing to GCC, whose names even did not trigger memories - unlike David M. or Jonathan, for example, or Nathan or Alexandre. For myself, I hav

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

Re: GCC association with the FSF

2021-04-12 Thread John Darrington
41;344;0cOn Sun, Apr 11, 2021 at 07:30:13PM -0300, Adhemerval Zanella via Gcc wrote: 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. I

Indirect memory addresses vs. lra

2019-08-04 Thread John Darrington
I'm trying to write a back-end for an architecture (s12z - the ISA you can download from [1]). This arch accepts indirect memory addresses. That is to say, those of the form (mem (mem (...))) and although my TARGET_LEGITIMATE_ADDRESS function returns true for such addresses, LRA insists on

Re: Indirect memory addresses vs. lra

2019-08-09 Thread John Darrington
On Thu, Aug 08, 2019 at 01:57:41PM -0600, Jeff Law wrote: Yea, it's certainly designed with the more mainstream architectures in mind. THe double-indirect case that's being talked about here is well out of the mainstream and not a feature of anything LRA has targetted to date.

Re: Indirect memory addresses vs. lra

2019-08-09 Thread John Darrington
On Fri, Aug 09, 2019 at 01:34:36PM -0400, Vladimir Makarov wrote: If you provide LRA dump for such test (it is better to use -fira-verbose=15 to output full RA info into stderr), I probably could say more. I've attached such a dump (generated from gcc/testsuite/gcc.c-torture/

Re: Indirect memory addresses vs. lra

2019-08-09 Thread John Darrington
On Fri, Aug 09, 2019 at 09:16:44AM -0500, Segher Boessenkool wrote: Is your code in some branch in our git? No. But it could be pushed there if people think it would be appropriate to do so, and if I'm given the permissions to do so. Or in some other public git? It's in my rep

Re: Indirect memory addresses vs. lra

2019-08-11 Thread John Darrington
On Sat, Aug 10, 2019 at 11:12:18AM -0500, Segher Boessenkool wrote: Hi! On Sat, Aug 10, 2019 at 08:05:53AM +0200, John Darrington wrote: > Choosing alt 5 in insn 14: (0) m (1) m {*movsi} >14: [r40:PSI+0x20]=[r41:PSI] > Inserting insn relo

Re: Indirect memory addresses vs. lra

2019-08-15 Thread John Darrington
On Thu, Aug 15, 2019 at 12:29:13PM -0400, Vladimir Makarov wrote: Thank you for providing the sources.?? It helped me to understand what is going on.?? So the test crashes on /home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c: In function ???f1???: /

Re: Indirect memory addresses vs. lra

2019-08-15 Thread John Darrington
On Thu, Aug 15, 2019 at 06:38:30PM +0200, Richard Biener wrote: Couldn't we spill the frame pointer? Basically we should be able to compute the first address into a reg, spill that, do the second (both could require the frame pointer), spill the frame pointer, reload the first computed

Special Memory Constraint [was Re: Indirect memory addresses vs. lra]

2019-08-16 Thread John Darrington
On Thu, Aug 15, 2019 at 02:23:45PM -0400, Vladimir Makarov wrote: > I tried this solution earlier. But unfortunately it makes things worse. What happens is it libgcc cannot > even be built -- ICEs occur on a memory from address reg insn such as: > (insn 117 2981 3697 5 (set (mem

Re: Special Memory Constraint [was Re: Indirect memory addresses vs. lra]

2019-08-19 Thread John Darrington
On Fri, Aug 16, 2019 at 10:50:13AM -0400, Vladimir Makarov wrote: No I meant something like that (define_special_memory_constraint "a" ...) (define_predicate "my_special_predicate" ... { if (lra_in_progress_p) return REG_P (o

Re: Special Memory Constraint [was Re: Indirect memory addresses vs. lra]

2019-08-19 Thread John Darrington
On Mon, Aug 19, 2019 at 10:07:11AM -0500, Segher Boessenkool wrote: > ? As I remember there were a few other ideas from Richard Biener and > Segher Boessenkool.? I also proposed to add a new address register which > will be always a fixed stack memory slot at the end. Unfortunatel

Re: Special Memory Constraint [was Re: Indirect memory addresses vs. lra]

2019-08-20 Thread John Darrington
On Tue, Aug 20, 2019 at 08:56:39AM +0200, Richard Biener wrote: > Most of these suggestions involve adding some sort of virtual registers > So I hacked the machine description to add two new registers Z1 and Z2 > with the same mode as X and Y. > > Obviously the assembler b