Binaries page modifications

[CHIGOT, CLEMENT]

Hi everyone,

I'm one of the owner of the BullFreeware website and I'm seeing that, in 
https://gcc.gnu.org/install/binaries.html, our website is described for "Bull’s 
Open Source Software Archive for for AIX 5L and AIX 6;". Would it be possible 
to change it for "Bull’s Open Source Software Archive for AIX 6 and AIX 7;", as 
we're no longer working on AIX5 ?


Thanks in advance


Clément Chigot
ATOS Bull SAS
1 rue de Provence - 38432 Échirolles - France

Re: Binaries page modifications

[Jonathan Wakely]

On 27/02/20 08:23 +, CHIGOT, CLEMENT wrote:

Hi everyone,

I'm one of the owner of the BullFreeware website and I'm seeing that, in 
https://gcc.gnu.org/install/binaries.html, our website is described for "Bull’s Open Source 
Software Archive for for AIX 5L and AIX 6;". Would it be possible to change it for 
"Bull’s Open Source Software Archive for AIX 6 and AIX 7;", as we're no longer working on 
AIX5 ?


Thanks for the mail. I've made that change with this patch, committed
to master as obvious.

By the way, I noticed that the "About" text on the front page of
bullfreeware.com says "appplication".


commit 4fd9efc8877814e8cda506563d0282a267c562c8
Author: Jonathan Wakely 
Date:   Thu Feb 27 08:42:05 2020 +

doc: Update description of BullFreeware

* doc/install.texi (Binaries): Update description of BullFreeware.

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 9b24a06d961..92961833ef6 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -3274,7 +3274,7 @@ AIX:
 @itemize
 @item
 @uref{http://www.bullfreeware.com,,Bull's Open Source Software Archive for
-for AIX 5L and AIX 6};
+for AIX 6 and AIX 7};
 
 @item
 @uref{http://www.perzl.org/aix/,,AIX Open Source Packages (AIX5L AIX 6.1

Re: Make LTO Patch for Job Server Thread Detection Agnostic

[Jonathan Wakely]

On Thu, 27 Feb 2020 at 06:50, Nicholas Krause  wrote:
>
> Greetings Martin,
>
> This patch:
> https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/lto-wrapper.c;h=353187c60434f43a445e708dcfbf53c857f8cdc1;hp=946897726d03716f7c93f955c438ee4f8190044c;hb=f12fbeb535f192f742025cc4f9b69a48136730f1;hpb=80c7cb9d2c8090f8d165ee2ca5f8d401090c1d06
>
> May have a small problem with the lines:
> +  const char *makeflags = getenv ("MAKEFLAGS");
> +  if (makeflags == NULL)
> +return false; I'm not sure if ninja or other build systems use that
> for detection or have it as a variable you can use. This may be an issue
> with ninja, cmake and other build systems that may not have it. Maybe
> I'm wrong but it may be good to check that, Nick

The patch is to use Make's jobserver, it's not expected to work with
arbitrary build systems.

Martin, the comment in your patch says "-std=c11" which should be c++11.

what is the post price of this sites?https://gcc.gnu.org/

[Alfie blake]

*Hi Sir,What is the post price of this site?* https://gcc.gnu.org/

*Tell me price of,*
*Existing Post Link?*


*Normal Post?Casino Post?waiting for your reply.*

Re: what is the post price of this sites?https://gcc.gnu.org/

[Alfie blake]

Hi sir,
Please tell me price,
I need the post on this site https://gcc.gnu.org/


On Thu, 27 Feb 2020 at 14:22, Alfie blake  wrote:

>
> *Hi Sir,What is the post price of this site?* https://gcc.gnu.org/
> 
> *Tell me price of,*
> *Existing Post Link?*
>
>
> *Normal Post?Casino Post?waiting for your reply.*
>

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

[Nathan Sidwell]

On 2/3/20 6:41 AM, Richard Earnshaw (lists) wrote:

On 22/01/2020 17:45, Richard Earnshaw (lists) wrote:


[updated based on v2 discussions]

This patch proposes some new (additional) rules for email subject lines
when contributing to GCC.  The goal is to make sure that, as far as
possible, the subject for a patch will form a good summary when the
message is committed to the repository if applied with 'git am'.  Where
possible, I've tried to align these rules with those already in
use for glibc, so that the differences are minimal and only where
necessary.

Some things that differ from existing practice (at least by some people)
are:

- Use ':' rather than '[]'
   - This is more git friendly and works with 'git am'.
- Put bug numbers at the end of the line rather than the beginning.
   - The bug number is useful, but not as useful as the brief summary.
 Also, use the shortened form, as the topic part is more usefully
 conveyed in the proper topic field (see above).


I've not seen any follow-up to this version.  Should we go ahead and 
adopt this?


do it!

do it! do it! do it!

nathan
--
Nathan Sidwell

Re: Make LTO Patch for Job Server Thread Detection Agnostic

[Nicholas Krause]

On 2/27/20 3:44 AM, Jonathan Wakely wrote:

On Thu, 27 Feb 2020 at 06:50, Nicholas Krause  wrote:

Greetings Martin,

This patch:
https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/lto-wrapper.c;h=353187c60434f43a445e708dcfbf53c857f8cdc1;hp=946897726d03716f7c93f955c438ee4f8190044c;hb=f12fbeb535f192f742025cc4f9b69a48136730f1;hpb=80c7cb9d2c8090f8d165ee2ca5f8d401090c1d06

May have a small problem with the lines:
+  const char *makeflags = getenv ("MAKEFLAGS");
+  if (makeflags == NULL)
+return false; I'm not sure if ninja or other build systems use that
for detection or have it as a variable you can use. This may be an issue
with ninja, cmake and other build systems that may not have it. Maybe
I'm wrong but it may be good to check that, Nick

The patch is to use Make's jobserver, it's not expected to work with
arbitrary build systems.

Martin, the comment in your patch says "-std=c11" which should be c++11.


Jonathan,

That's a problem then as were assuming a user's build system for this to 
work. I mean
for now its fine but in the future wouldn't it de a good ideal to not 
assume this?


Nick

Re: Make LTO Patch for Job Server Thread Detection Agnostic

[Jonathan Wakely]

On Thu, 27 Feb 2020 at 16:18, Nicholas Krause  wrote:
>
>
>
> On 2/27/20 3:44 AM, Jonathan Wakely wrote:
> > On Thu, 27 Feb 2020 at 06:50, Nicholas Krause  wrote:
> >> Greetings Martin,
> >>
> >> This patch:
> >> https://gcc.gnu.org/git/?p=gcc.git;a=blobdiff;f=gcc/lto-wrapper.c;h=353187c60434f43a445e708dcfbf53c857f8cdc1;hp=946897726d03716f7c93f955c438ee4f8190044c;hb=f12fbeb535f192f742025cc4f9b69a48136730f1;hpb=80c7cb9d2c8090f8d165ee2ca5f8d401090c1d06
> >>
> >> May have a small problem with the lines:
> >> +  const char *makeflags = getenv ("MAKEFLAGS");
> >> +  if (makeflags == NULL)
> >> +return false; I'm not sure if ninja or other build systems use that
> >> for detection or have it as a variable you can use. This may be an issue
> >> with ninja, cmake and other build systems that may not have it. Maybe
> >> I'm wrong but it may be good to check that, Nick
> > The patch is to use Make's jobserver, it's not expected to work with
> > arbitrary build systems.
> >
> > Martin, the comment in your patch says "-std=c11" which should be c++11.
>
> Jonathan,
>
> That's a problem then as were assuming a user's build system for this to
> work. I mean
> for now its fine but in the future wouldn't it de a good ideal to not
> assume this?

It works fine for everybody. There's just an optimisation for people
with a GNU make jobserver available. I don't see a problem.

If somebody wants to add an optimisation for their preferred build
system they can propose a patch.

Re: Make LTO Patch for Job Server Thread Detection Agnostic

[Paul Smith]

On Thu, 2020-02-27 at 16:58 +, Jonathan Wakely wrote:
> > That's a problem then as were assuming a user's build system for this
> > to work. I mean for now its fine but in the future wouldn't it de a
> > good ideal to not assume this?
> 
> It works fine for everybody. There's just an optimisation for people
> with a GNU make jobserver available. I don't see a problem.
> 
> If somebody wants to add an optimisation for their preferred build
> system they can propose a patch.

And/or they can suggest to other build systems that they also add support
for this service.

I'm not aware of any service like this which is supported by all build
tools, so it's not like we're choosing this over something else that's more
widely available.  Actually as far as I know other build tools don't
provide anything like it, portable or not.

[AArch64] Backporting -moutline-atomics to gcc 9.x and 8.x

[Pop, Sebastian]

Hi,
is somebody already working on backporting -moutline-atomics to gcc 8.x and 9.x 
branches?

Thanks,
Sebastian

Help implementing support for vec in gengtype

[Giuliano Belinassi]

Hi, all.

I am tying to fix an issue with a global variable in the parallel gcc
project. For this, I am trying to move some global variables from
tree-ssa-operands to struct function. One of this variable is a
vec type, and gengtype doesn't look so happy with it.

In this context, I am trying to add support to vec to gengtype.
Therefore, I first fixed a problem where gengtype couldn't find the
tree union by:

diff --git a/gcc/gengtype.c b/gcc/gengtype.c
index 53317337cf8..6f4c77020ea 100644
--- a/gcc/gengtype.c
+++ b/gcc/gengtype.c
@@ -638,7 +638,10 @@ create_user_defined_type (const char *type_name, struct fil
eloc *pos)
  /* Strip off the first '*' character (and any subsequent text). */
  *(field_name + offset_to_star) = '\0';
 
- arg_type = find_structure (field_name, TYPE_STRUCT);
+ arg_type = resolve_typedef (field_name, pos);
+ if (!arg_type)
+   arg_type = find_structure (field_name, TYPE_STRUCT);
+
  arg_type = create_pointer (arg_type);
}
  else

After this patch, gengtype seems to correctly detect vec types,
but then I face linking issues. At first, the compiler could not find
gt_ggc_mx (vec *v) and gt_pch_mx (vec *v), therefore I implemented
them both in gcc/vec.h:

diff --git a/gcc/vec.h b/gcc/vec.h
index 091056b37bc..dfa744b684e 100644
--- a/gcc/vec.h
+++ b/gcc/vec.h
@@ -1306,6 +1306,15 @@ vec::quick_grow_cleared (unsigned len)
 vec_default_construct (address () + oldlen, growby);
 }
 
+template
+void
+gt_ggc_mx (vec *v)
+{
+  extern void gt_ggc_mx (T &);
+  for (unsigned i = 0; i < v->length (); i++)
+gt_ggc_mx ((*v)[i]);
+}
+
 /* Garbage collection support for vec.  */
 
 template
@@ -1328,6 +1337,15 @@ gt_ggc_mx (vec *v 
ATTRIBUTE_UNUSED)
 
 /* PCH support for vec.  */
 
+template
+void
+gt_pch_nx (vec *v)
+{
+  extern void gt_pch_nx (T &);
+  for (unsigned i = 0; i < v->length (); i++)
+gt_pch_nx ((*v)[i]);
+}
+
 template
 void
 gt_pch_nx (vec *v)
@@ -1337,6 +1355,14 @@ gt_pch_nx (vec *v)
 gt_pch_nx ((*v)[i]);
 }
 
+template
+void
+gt_pch_nx (vec *v, gt_pointer_operator op, void *cookie)
+{
+  for (unsigned i = 0; i < v->length (); i++)
+op (&((*v)[i]), cookie);
+}
+
template
 void
 gt_pch_nx (vec *v, gt_pointer_operator op, void *cookie)
@@ -1354,6 +1380,15 @@ gt_pch_nx (vec *v, gt_pointer_operator 
op, void *cookie)
 gt_pch_nx (&((*v)[i]), op, cookie);
 }
 
+template
+void
+gt_pch_nx (vec *v, gt_pointer_operator op, void *cookie)
+{
+  extern void gt_pch_nx (T *, gt_pointer_operator, void *);
+  for (unsigned i = 0; i < v->length (); i++)
+gt_pch_nx (&((*v)[i]), op, cookie);
+}
+

After that, I get linking errors because the linker can not find
gt_ggc_mx (tree *&x) nor void gt_pch_nx (tree *&x). The thing
is: it doesn't matter where I implement them, or if I declare
them inline. I always get a linking error one way or another.

Therefore, what should I do to correctly implement the support
for vec types?

Thank you,
Giuliano.

Re: [AArch64] Backporting -moutline-atomics to gcc 9.x and 8.x

[Kyrill Tkachov]

Hi Sebastian,

On 2/27/20 4:53 PM, Pop, Sebastian wrote:


Hi,

is somebody already working on backporting -moutline-atomics to gcc 
8.x and 9.x branches?



I'm not aware of such work going on.

Thanks,

Kyrill


Thanks,

Sebastian

Re: Help implementing support for vec in gengtype

[Nicholas Krause]

On 2/27/20 12:56 PM, Giuliano Belinassi wrote:

Hi, all.

I am tying to fix an issue with a global variable in the parallel gcc
project. For this, I am trying to move some global variables from
tree-ssa-operands to struct function. One of this variable is a
vec type, and gengtype doesn't look so happy with it.

In this context, I am trying to add support to vec to gengtype.
Therefore, I first fixed a problem where gengtype couldn't find the
tree union by:

diff --git a/gcc/gengtype.c b/gcc/gengtype.c
index 53317337cf8..6f4c77020ea 100644
--- a/gcc/gengtype.c
+++ b/gcc/gengtype.c
@@ -638,7 +638,10 @@ create_user_defined_type (const char *type_name, struct fil
eloc *pos)
   /* Strip off the first '*' character (and any subsequent text). 
*/
   *(field_name + offset_to_star) = '\0';
  
- arg_type = find_structure (field_name, TYPE_STRUCT);

+ arg_type = resolve_typedef (field_name, pos);
+ if (!arg_type)
+   arg_type = find_structure (field_name, TYPE_STRUCT);
+
   arg_type = create_pointer (arg_type);
 }
   else

After this patch, gengtype seems to correctly detect vec types,
but then I face linking issues. At first, the compiler could not find
gt_ggc_mx (vec *v) and gt_pch_mx (vec *v), therefore I implemented
them both in gcc/vec.h:

diff --git a/gcc/vec.h b/gcc/vec.h
index 091056b37bc..dfa744b684e 100644
--- a/gcc/vec.h
+++ b/gcc/vec.h
@@ -1306,6 +1306,15 @@ vec::quick_grow_cleared (unsigned len)
  vec_default_construct (address () + oldlen, growby);
  }
  
+template

+void
+gt_ggc_mx (vec *v)
+{
+  extern void gt_ggc_mx (T &);
+  for (unsigned i = 0; i < v->length (); i++)
+gt_ggc_mx ((*v)[i]);
+}
+
  /* Garbage collection support for vec.  */
  
  template

@@ -1328,6 +1337,15 @@ gt_ggc_mx (vec *v 
ATTRIBUTE_UNUSED)
  
  /* PCH support for vec.  */
  
+template

+void
+gt_pch_nx (vec *v)
+{
+  extern void gt_pch_nx (T &);
+  for (unsigned i = 0; i < v->length (); i++)
+gt_pch_nx ((*v)[i]);
+}
+
  template
  void
  gt_pch_nx (vec *v)
@@ -1337,6 +1355,14 @@ gt_pch_nx (vec *v)
  gt_pch_nx ((*v)[i]);
  }
  
+template

+void
+gt_pch_nx (vec *v, gt_pointer_operator op, void *cookie)
+{
+  for (unsigned i = 0; i < v->length (); i++)
+op (&((*v)[i]), cookie);
+}
+
template
  void
  gt_pch_nx (vec *v, gt_pointer_operator op, void *cookie)
@@ -1354,6 +1380,15 @@ gt_pch_nx (vec *v, gt_pointer_operator 
op, void *cookie)
  gt_pch_nx (&((*v)[i]), op, cookie);
  }
  
+template

+void
+gt_pch_nx (vec *v, gt_pointer_operator op, void *cookie)
+{
+  extern void gt_pch_nx (T *, gt_pointer_operator, void *);
+  for (unsigned i = 0; i < v->length (); i++)
+gt_pch_nx (&((*v)[i]), op, cookie);
+}
+

After that, I get linking errors because the linker can not find
gt_ggc_mx (tree *&x) nor void gt_pch_nx (tree *&x). The thing
is: it doesn't matter where I implement them, or if I declare
them inline. I always get a linking error one way or another.

Therefore, what should I do to correctly implement the support
for vec types?

Thank you,
Giuliano.


Giuliano,
If your talking about gcc/vec.h there seems to be versions of them 
defined starting
on line 1304 of the mainline tree after grepping the source code. Not 
sure if the

linker is complaining about that as I don't have your errors.

Maybe that helps you out,

Nick

Discussion on Removal of Garbage Collector and other GCC Multi threaded Work

[Nicholas Krause]

Greetings All,

After doing some more research it seems that it may be time to remove 
the garbage collector. I'm
aware of the linkage to precompiled headers but even them I think its 
time due to two reasons:


1. The work related to multithreading gcc is working around the global 
state of the collector which
makes scaling less likely in terms of threads. In addition it is 
causing   unnecessary compilations

in terms of workarounds in this project.

2. Memory usage may be decreased in certain passes due to being able to 
implement memory allocation
at a pass or per pass type level with more knowledge than a generic 
garbage collector. I'm aware this
is done for a lot of passes. However it  could be done for the other 
passes that are linked currently to the

garbage collector.

I'm not sure what memory allocation strategies we want to implement in 
terms of replacing the garbage

collector but I think its time.

On another I'm looking into the issues with PHI nodes and operators as 
to how to lock or decrease global
state there as this seems to be the biggest complication when I've time. 
In addition as Jeff stated we
will also want to encapsulate SSA operands and other SSA related things 
in a series of classes as part of

this.


Regards,
Nick

Re: Discussion on Removal of Garbage Collector and other GCC Multi threaded Work

[David Malcolm]

On Thu, 2020-02-27 at 14:07 -0500, Nicholas Krause wrote:
> Greetings All,
> 
> After doing some more research it seems that it may be time to
> remove 
> the garbage collector. I'm
> aware of the linkage to precompiled headers but even them I think
> its 
> time due to two reasons:
> 
> 1. The work related to multithreading gcc is working around the
> global 
> state of the collector which
> makes scaling less likely in terms of threads. In addition it is 
> causing   unnecessary compilations
> in terms of workarounds in this project.
> 
> 2. Memory usage may be decreased in certain passes due to being able
> to 
> implement memory allocation
> at a pass or per pass type level with more knowledge than a generic 
> garbage collector. I'm aware this
> is done for a lot of passes. However it  could be done for the other 
> passes that are linked currently to the
> garbage collector.
> 
> I'm not sure what memory allocation strategies we want to implement
> in 
> terms of replacing the garbage
> collector but I think its time.

Nick, you've sent various emails to this list suggesting big changes to
GCC's codebase (updating from C++98 to C++11 is another one that
springs to mind), but I believe you've yet to send the project an
actual patch for anything.

It's great that you want to help, and that you have ideas about the
high-level architecture of the project, but may I respectfully suggest
you start with something *much* smaller and more concrete?   There are
plenty of bugs in BZ that could use attention.

Hope this is constructive
David

> On another I'm looking into the issues with PHI nodes and operators
> as 
> to how to lock or decrease global
> state there as this seems to be the biggest complication when I've
> time. 
> In addition as Jeff stated we
> will also want to encapsulate SSA operands and other SSA related
> things 
> in a series of classes as part of
> this.
> 
> 
> Regards,
> Nick
> 

Re: GCC 8.4 Release Candidate available from gcc.gnu.org

[William Seurer]

I bootstrapped and tested on power 7 and power 8 BE and on power 8 and 
power 9 LE and saw nothing untoward.


On 2/26/20 4:18 PM, Jakub Jelinek wrote:

The first release candidate for GCC 8.4 is available from

  https://gcc.gnu.org/pub/gcc/snapshots/8.4.0-RC-20200226/
  ftp://gcc.gnu.org/pub/gcc/snapshots/8.4.0-RC-20200226/

and shortly its mirrors.  It has been generated from git commit
r8-10091-gf80c40f93f9e8781b14f1a8301467f117fd24051.

I have so far bootstrapped and tested the release candidate on
x86_64-linux and i686-linux.  Please test it and report any issues to
bugzilla.

If all goes well, I'd like to release 8.4 on Wednesday, March 4th.

Re: Discussion on Removal of Garbage Collector and other GCC Multi threaded Work

[Nicholas Krause]

On 2/27/20 3:02 PM, David Malcolm wrote:

On Thu, 2020-02-27 at 14:07 -0500, Nicholas Krause wrote:

Greetings All,

After doing some more research it seems that it may be time to
remove
the garbage collector. I'm
aware of the linkage to precompiled headers but even them I think
its
time due to two reasons:

1. The work related to multithreading gcc is working around the
global
state of the collector which
makes scaling less likely in terms of threads. In addition it is
causing   unnecessary compilations
in terms of workarounds in this project.

2. Memory usage may be decreased in certain passes due to being able
to
implement memory allocation
at a pass or per pass type level with more knowledge than a generic
garbage collector. I'm aware this
is done for a lot of passes. However it  could be done for the other
passes that are linked currently to the
garbage collector.

I'm not sure what memory allocation strategies we want to implement
in
terms of replacing the garbage
collector but I think its time.

Nick, you've sent various emails to this list suggesting big changes to
GCC's codebase (updating from C++98 to C++11 is another one that
springs to mind), but I believe you've yet to send the project an
actual patch for anything.

 I did awhile but most of them were bug fixes on bugzilla. Not
sure if any got merged. Most of these days I doing research so
sorry about that. If your not familiar with it my work is here:
https://docs.google.com/document/d/1po_RRgSCtRyYgMHjV0itW8iOzJXpTdHYIpC9gUMjOxk/edit 



It's great that you want to help, and that you have ideas about the
high-level architecture of the project, but may I respectfully suggest
you start with something *much* smaller and more concrete?   There are
plenty of bugs in BZ that could use attention.

Of course this was to be long term :). Like the C++11 its more to
get others involved in planning for it. The change patch was
small for C++11. The problem really was testing and figuring out
language support which I helped out with.

Very sorry if your misunderstanding me or my work,
Nick


Hope this is constructive
David


On another I'm looking into the issues with PHI nodes and operators
as
to how to lock or decrease global
state there as this seems to be the biggest complication when I've
time.
In addition as Jeff stated we
will also want to encapsulate SSA operands and other SSA related
things
in a series of classes as part of
this.


Regards,
Nick

GSoC: some questions about the static analyzer pass

[y...@bupt.edu.cn]

Hello everybody! I've learned about the projects in Google summer of code, and 
I'm so interested in the static analyzer pass. I wonder that where I can read 
the code of the static analyzer pass and how to contact with the mental David 
Malcolm. Can anyone help me please? Thank you so much.



y...@bupt.edu.cn

Re: GSoC: some questions about the static analyzer pass

[David Malcolm]

On Fri, 2020-02-28 at 09:31 +0800, y...@bupt.edu.cn wrote:
> Hello everybody! I've learned about the projects in Google summer of
> code, and I'm so interested in the static analyzer pass. I wonder
> that where I can read the code of the static analyzer pass and how to
> contact with the mental David Malcolm. Can anyone help me please?
> Thank you so much.

Hi!

The code is in the gcc/analyzer subdirectory of the GCC source tree:
  https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=gcc/analyzer

Internal documentation is here:
  https://gcc.gnu.org/onlinedocs/gccint/Static-Analyzer.html

Some other notes can be seen at:
  https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer


Hope this is helpful
David

Re: what is the post price of this sites?https://gcc.gnu.org/

[Alfie blake]

Hi any update

On Thu, 27 Feb 2020 at 14:30, Alfie blake  wrote:

> Hi sir,
> Please tell me price,
> I need the post on this site https://gcc.gnu.org/
> 
>
> On Thu, 27 Feb 2020 at 14:22, Alfie blake 
> wrote:
>
>>
>> *Hi Sir,What is the post price of this site?* https://gcc.gnu.org/
>> 
>> *Tell me price of,*
>> *Existing Post Link?*
>>
>>
>> *Normal Post?Casino Post?waiting for your reply.*
>>
>

MLIR Dialects for Multi-Threading GCC

[Nicholas Krause]

Greetings All,

Seems the LLVM side has made a multi threaded pass manager in MLIR:
https://mlir.llvm.org/docs/WritingAPass/

It also seems to have fixed a lot of the issues around my research in
SSA. There are two ways to look into using MLIR either:

a) Write a dialect of it for GIMPLE
b) Use the ideas but implement them internally in GCC rewriting passes
into the core infrastructure as need be

Not sure if other people think its a good idea or there are license issues,
Nick

Re: what is the post price of this sites?https://gcc.gnu.org/

[maticulous]

I can assure you that the website @gnu.org or any domains associated with
gnu.org are not for sale.
If you want to negotiate you should probably contact GNU directly.

Good luck.

On Fri, Feb 28, 2020 at 7:00 PM Alfie blake 
wrote:

> Hi any update
>
> On Thu, 27 Feb 2020 at 14:30, Alfie blake 
> wrote:
>
> > Hi sir,
> > Please tell me price,
> > I need the post on this site https://gcc.gnu.org/
> > <
> https://signtr.info/tracker/click?redirect=https%3A%2F%2Fgcc.gnu.org%2F&dID=1582795373536&linkName=https://gcc.gnu.org/
> >
> >
> > On Thu, 27 Feb 2020 at 14:22, Alfie blake 
> > wrote:
> >
> >>
> >> *Hi Sir,What is the post price of this site?* https://gcc.gnu.org/
> >> <
> https://signtr.info/tracker/click?redirect=https%3A%2F%2Fgcc.gnu.org%2F&dID=1582795373536&linkName=https://gcc.gnu.org/
> >
> >> *Tell me price of,*
> >> *Existing Post Link?*
> >>
> >>
> >> *Normal Post?Casino Post?waiting for your reply.*
> >>
> >
>