Re: [PATCH] Weird Linker Error

[Nicholas Krause]

Please forget  this email seems it was a dumb typo.

Nick

On 2/28/20 5:44 PM, Nicholas Krause wrote:

From: Nicholas Krause 

Greetings,

Sorry if this is a dumb question but I'm not sure if this is a linker
error due to not linking pthreads or something else going on. I'm assuming
its something to do with enabling pthreads but what's weird is it
does not warn the types are not defined but gives me errors like:

/home/xerofoify/GCC/../gcc/gcc/tree.h:3763: multiple definition of 
`phi_stmt_iterator_mutex'
cfgexpand.o:/home/xerofoify/GCC/../gcc/gcc/dumpfile.h:215: first defined here
omp-grid.o:(.bss+0x0): multiple definition of `imm_iteration_mutex'
cfgexpand.o:/home/xerofoify/GCC/../gcc/gcc/hwint.h:214: first defined here
omp-grid.o: In function `bool need_finalization_p, tree_node*> >::hash_entry>()':

I've checked those lines and none of them seem to be dealing with
SSA iterators. Thanks in advance for the help.

Signed-off-by: Nicholas Krause 
---
  gcc/ssa-iterators.h | 28 
  1 file changed, 20 insertions(+), 8 deletions(-)

diff --git a/gcc/ssa-iterators.h b/gcc/ssa-iterators.h
index 98724da..65d8e3b 100644
--- a/gcc/ssa-iterators.h
+++ b/gcc/ssa-iterators.h
@@ -16,6 +16,7 @@ FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public 
License
  You should have received a copy of the GNU General Public License
  along with GCC; see the file COPYING3.  If not see
  .  */
+#include 
  
  #ifndef GCC_SSA_ITERATORS_H

  #define GCC_SSA_ITERATORS_H
@@ -68,6 +69,10 @@ struct imm_use_iterator
ssa_use_operand_t *next_imm_name;
  };
  
+/*IMM Iterator Mutex*/

+pthread_mutex_t imm_iteration_mutex;
+/*IMM_STMT Iterator Mutex*/
+pthread_mutex_t imm_stmt_iterator_mutex;
  
  /* Use this iterator when simply looking at stmts.  Adding, deleting or

 modifying stmts will cause this iterator to malfunction.  */
@@ -82,7 +87,7 @@ struct imm_use_iterator
  #define FOR_EACH_IMM_USE_STMT(STMT, ITER, SSAVAR) \
for ((STMT) = first_imm_use_stmt (&(ITER), (SSAVAR));   \
 !end_imm_use_stmt_p (&(ITER)); \
-   (void) ((STMT) = next_imm_use_stmt (&(ITER
+   (void) ((STMT) = next_imm_use_stmt (&(ITER   \
  
  /* Use this to terminate the FOR_EACH_IMM_USE_STMT loop early.  Failure to

 do so will result in leaving a iterator marker node in the immediate
@@ -116,7 +121,7 @@ struct imm_use_iterator
  #define FOR_EACH_IMM_USE_ON_STMT(DEST, ITER)  \
for ((DEST) = first_imm_use_on_stmt (&(ITER));  \
 !end_imm_use_on_stmt_p (&(ITER));  \
-   (void) ((DEST) = next_imm_use_on_stmt (&(ITER
+   (void) ((DEST) = next_imm_use_on_stmt (&(ITER\
  
  
  
@@ -147,6 +152,13 @@ struct ssa_op_iter

gimple *stmt;
  };
  
+/*SSA Iterator Mutex*/

+pthread_mutex_t ssa_iteration_mutex;
+/*PHI Iterator Mutex*/
+pthread_mutex_t phi_iteration_mutex;
+/*PHI_STMT Iterator Mutex*/
+pthread_mutex_t phi_stmt_iterator_mutex;
+
  /* NOTE: Keep these in sync with doc/tree-ssa.texi.  */
  /* These flags are used to determine which operands are returned during
 execution of the loop.  */
@@ -168,7 +180,7 @@ struct ssa_op_iter
  #define FOR_EACH_SSA_TREE_OPERAND(TREEVAR, STMT, ITER, FLAGS) \
for (TREEVAR = op_iter_init_tree (&(ITER), STMT, FLAGS);\
 !op_iter_done (&(ITER));   \
-   (void) (TREEVAR = op_iter_next_tree (&(ITER
+   (void) (TREEVAR = op_iter_next_tree (&(ITER  \
  
  /* This macro executes a loop over the operands of STMT specified in FLAG,

 returning each operand as a 'use_operand_p' in the variable USEVAR.
@@ -176,7 +188,7 @@ struct ssa_op_iter
  #define FOR_EACH_SSA_USE_OPERAND(USEVAR, STMT, ITER, FLAGS)   \
for (USEVAR = op_iter_init_use (&(ITER), STMT, FLAGS);  \
 !op_iter_done (&(ITER));   \
-   USEVAR = op_iter_next_use (&(ITER)))
+   USEVAR = op_iter_next_use (&(ITER))) \
  
  /* This macro executes a loop over the operands of STMT specified in FLAG,

 returning each operand as a 'def_operand_p' in the variable DEFVAR.
@@ -184,7 +196,7 @@ struct ssa_op_iter
  #define FOR_EACH_SSA_DEF_OPERAND(DEFVAR, STMT, ITER, FLAGS)   \
for (DEFVAR = op_iter_init_def (&(ITER), STMT, FLAGS);  \
 !op_iter_done (&(ITER));   \
-   DEFVAR = op_iter_next_def (&(ITER)))
+   DEFVAR = op_iter_next_def (&(ITER))) \
  
  /* This macro will execute a loop over all the arguments of a PHI which

 match FLAGS.   A use_operand_p is always returned via USEVAR.  FLAGS
@@ -192,7 +204,7 @@ struct ssa_op_iter
  #define FOR_EACH_PHI_ARG(USEVAR, STMT, ITER, FLAGS)   \
for ((USEVAR) = op_iter_init_phiuse (&(ITER), STMT, FLAGS); \
 !op_iter_done (&(ITER));   \
-

gcc-8-20200228 is now available

[gccadmin]

Snapshot gcc-8-20200228 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/8-20200228/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 8 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-8 
revision 5e7568f5a647738c6787667552ce1d5bcee0c108

You'll find:

 gcc-8-20200228.tar.xzComplete GCC

  SHA256=9f3921da173dc0a2e209bc8ee943ac0dd0caf6ad649829a0c2bec3e1623002b8
  SHA1=76d1c789c4302d9b8afe0c20bd4ed32c47120502

Diffs from 8-20200221 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-8
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.

SSA Operands Locking

[Nicholas Krause]

Greetings,

After looking through the manual there seem to be a number of for 
iterating marcos related to
PHI or SSA nodes. Since iterating through nodes is shared state I was 
wondering whether we
should lock internal to the marco itself around the iteration or around 
each caller of one of these
marcos and just update the manual to warn about that in terms of 
implementing Multi-Threading.
It doesn't really matter in terms of technical functionality but should 
we assume that developers
will remember to lock a mutex around these iteration marcos for SSA or 
PHI nodes.



Not sure about the status of C++11 but when it gets merged we can just 
lock this using std::mutex,


Nick

Re: Make LTO Patch for Job Server Thread Detection Agnostic

[Paul Smith]

On Fri, 2020-02-28 at 17:37 +0100, Martin Jambor wrote:
> > Recently Honza, me and others discussed LTO's interaction with
> > build systems, and that perhaps the module mapper could be
> > generalized for other purposes.  (Yes, still need to resurrect my
> > Make PoC)
> 
> see also the "Create a general jobserver client/server library"
> library suggested GSoC project at 
> https://gcc.gnu.org/wiki/SummerOfCode.

If you get someone to work on that please touch base with
bug-m...@gnu.org (or talk to me directly, at psm...@gnu.org) as it
would be great if the implementation could be used in GNU make itself,
as well.

One caveat: GNU make still requires C90.

Cheers!

Re: Make LTO Patch for Job Server Thread Detection Agnostic

[Martin Jambor]

Hi,

On Fri, Feb 28 2020, Nathan Sidwell wrote:
> On 2/27/20 12:04 PM, Paul Smith wrote:
>> 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.
>
> Recently Honza, me and others discussed LTO's interaction with build 
> systems, and that perhaps the module mapper could be generalized for 
> other purposes.  (Yes, still need to resurrect my Make PoC)

see also the "Create a general jobserver client/server library" library
suggested GSoC project at https://gcc.gnu.org/wiki/SummerOfCode.

Martin

Re: Make LTO Patch for Job Server Thread Detection Agnostic

[Nathan Sidwell]

On 2/27/20 12:04 PM, Paul Smith wrote:

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.


Recently Honza, me and others discussed LTO's interaction with build 
systems, and that perhaps the module mapper could be generalized for 
other purposes.  (Yes, still need to resurrect my Make PoC)


nathan

--
Nathan Sidwell

Re: GCC 9.3 Status Report (2020-02-28)

[H.J. Lu]

On Fri, Feb 28, 2020 at 5:42 AM Jakub Jelinek  wrote:
>
> Status
> ==
>
> GCC 9.2 has been released more than half a year ago and it is time
> for another release from the latest stable branch.  Many people have
> backported their fixes to 9 branch recently already, often together
> with backports for 8.4.  Now that 8.4-rc1 is out, I'd like to do
> a 9.3-rc1 on Thursday, March 5th and the release most likely a week
> after that.  Please get your remaining 9.3 fixes into the branch
> before that.
>
>
> Quality Data
> 
>
> Priority  #   Change from last report
> ---   ---
> P10
> P2  243   +  45
> P3   35   -  16
> P4  169   +  28
> P5   23   -   1
> ---   ---
> Total P1-P3 278   +  29
> Total   470   +  56
>
>
> Previous Report
> ===
>
> https://gcc.gnu.org/ml/gcc/2019-08/msg00093.html
>

handle_lto_debug_sections failed to copy .note.gnu.property section
which caused:

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

I am testing

diff --git a/libiberty/simple-object.c b/libiberty/simple-object.c
index d9c648af717..e6c466ab767 100644
--- a/libiberty/simple-object.c
+++ b/libiberty/simple-object.c
@@ -293,6 +293,9 @@ handle_lto_debug_sections (const char *name, int rename)
   /* Copy over .note.GNU-stack section under the same name if present.  */
   else if (strcmp (name, ".note.GNU-stack") == 0)
 return strcpy (newname, name);
+  /* Copy over .note.gnu.property section under the same name if present.  */
+  else if (strcmp (name, ".note.gnu.property") == 0)
+return strcpy (newname, name);
   /* Copy over .comment section under the same name if present.  Solaris
  ld uses them to relax its checking of ELF gABI access rules for
  COMDAT sections in objects produced by GCC.  */

I'd like to backport it to GCC 9 if possible.

-- 
H.J.

Effective and cheapest solution to prevent viro- and bacterial spreading

[Coronacover.com]

Effective and cheapest solution to prevent viro- and bacterial exposure

https://sendy.shieldingsystems.eu/l/ppJLEU0d9F0P763nlkvcZCsQ/P7qvK8922w0M8926QLLHGVF7763A/x763RAAptID1W4sz3nMR1X892w

Anti Microbial copper

You may change your email preferences or 
https://sendy.shieldingsystems.eu/unsubscribe/9kvSI7lpRywyqffDiKX763pw/5b8Gr8AWo6ZlnAzPHDPcFg/x763RAAptID1W4sz3nMR1X892w
 from this list, at any time.

GCC 9.3 Status Report (2020-02-28)

[Jakub Jelinek]

Status
==

GCC 9.2 has been released more than half a year ago and it is time
for another release from the latest stable branch.  Many people have
backported their fixes to 9 branch recently already, often together
with backports for 8.4.  Now that 8.4-rc1 is out, I'd like to do
a 9.3-rc1 on Thursday, March 5th and the release most likely a week
after that.  Please get your remaining 9.3 fixes into the branch
before that.


Quality Data


Priority  #   Change from last report
---   ---
P10
P2  243   +  45
P3   35   -  16
P4  169   +  28
P5   23   -   1
---   ---
Total P1-P3 278   +  29
Total   470   +  56


Previous Report
===

https://gcc.gnu.org/ml/gcc/2019-08/msg00093.html

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

[Jonathan Wakely]

On 28/02/20 19:34 +1300, maticulous wrote:

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.


They're not trying to buy the domain, they're asking what we charge
for somebody to post their stupid, spammy, SEO-junk articles on our
website.

Obviously we don't let idiot spammers post articles on our site, but
they're idiots and don't understand that.

You should read https://gcc.gnu.org/spam.html though.