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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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???:
/
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
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
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/
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.
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
21 matches
Mail list logo
