Re: gcc 10.0.1 20200506 build fails to compile linux kernel
On 5/6/20 6:44 AM, Tetsuji Rai via Gcc wrote: I wonder how Fedora project built its own kernel. I can't build custom kernel with it. What's wrong with 10.1-RC or how can I report my problem? Hi. Is it possible that you reached https://lore.kernel.org/lkml/20200417190607.GY2424@tucnak/T/ ? I can try to reproduce that but please file a bug at or bugzilla and provide steps how to reproduce the issue. Can you also reproduce it within a qemu VM? Thanks, Martin
Re: Automatically generated ChangeLog files - script
On 04/05/2020 20:28, H.J. Lu via Gcc wrote: On Mon, May 4, 2020 at 12:24 PM Tobias Burnus wrote: On 5/4/20 9:05 PM, Jakub Jelinek via Gcc wrote: On Mon, May 04, 2020 at 08:56:16PM +0200, Martin Liška wrote: What's missing right now is how will we declare a Backport format. Can we just use something like: 'Backport from 6607bdd4c834f92fce924abdaea3405f62dc'? No. What we should allow is that people just git cherry-pick r11-1234-g123456 into a release branch and push it (of course after testing), so we don't want the user to change the commit log in that case. How does one handle partial backports? I mean those where only half of the original patch applies easily to the old branch and the other half is simply ignored? This happened a couple of times to me, especially when applying a patch to the last but one release branch. You need to resolve conflicts and update commit message with $ git cherry-pick --continue The resolution of conflicts is likely to affect the changes intended for the change log files. The commit message can be updated accordingly using: $ git commit --amend -- https://www.codethink.co.uk/privacy.html
Question about alias or points-to analysis
Hi,
I am trying to find out how to use the alias and/or points-to analysis
in GCC. Ideally, I would like to find a function that given an
allocation site, the return value is a set of pointers which may point
to memory allocated from that allocation site.
For example:
int
main(int argc, char** argv)
{
int a;
int *b = argc > 2 ? &a : NULL;
int *c = b;
}
Here, querying the allocation site corresponding to the declaration of
local variable "a", should return { "b", "c" }.
I've found the following documentation on Alias-Analysis [0] and two
source files[1][2] which seem to implement some (distinct?) alias analysis.
I am trying to keep the discussion a bit high level, otherwise I would
have a lot of questions, but given this C example, **how would someone
be able to use any of the alias analyses in GCC to determine that "b"
and "c" may-alias "a"?**
I compiled my example and placed an pass to experiment with alias
analysis at link time. (I include the patch at the end). This is the
gimple produced by the example above.
main (int argc, char * * argv)
{
int * c;
int * b;
int a;
int D.4170;
int * iftmp.0;
int * iftmp.0_1;
int * iftmp.0_3;
int * iftmp.0_4;
int _9;
:
if (argc_2(D) > 2)
goto ; [INV]
else
goto ; [INV]
:
iftmp.0_4 = &a;
goto ; [INV]
:
iftmp.0_3 = 0B;
:
# iftmp.0_1 = PHI
b_5 = iftmp.0_1;
c_6 = b_5;
a ={v} {CLOBBER};
_9 = 0;
:
:
return _9;
}
I include this example because looking at the Alias Analysis [0]
section, it mentions memory SSA form. But I do not see any #.MEM_n
assignments.
Furthermore, I made an equivalent code to the example of Memory SSA form
and I still don't see any Memory SSA forms:
```c
int i;
int foo()
{
i = 1;
return i;
}
```
```gimple
foo ()
{
int D.4164;
int _3;
:
i = 1;
_3 = i;
:
:
return _3;
}
```
So, I am not sure how the gimple shown on the Alias-analysis page is
produced. **Does anyone know why the gimple produced is not showing the
virtual SSA names?**
Afterwards, instead of looking at the virtual SSA names, I then focused
on finding out whether SSA_NAME_PTR_INFO but I found that it was not
set. **Do I need I need to run something to make sure that
SSA_NAME_PTR_INFO is set?** Maybe the example I chose for compilation
did not trigger the path for setting SSA_NAME_PTR_INFO. What would be an
example of some code that does set SSA_NAME_PTR_INFO?
Here is the patch, and in order to compile an example and dump the log:
/path/to/gcc -fdump-ipa-hello-world -fipa-hello-world a.c
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 543b477ff18..bc1af09cbf8 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1399,6 +1399,7 @@ OBJS = \
incpath.o \
init-regs.o \
internal-fn.o \
+ ipa-hello-world.o \
ipa-cp.o \
ipa-sra.o \
ipa-devirt.o \
diff --git a/gcc/common.opt b/gcc/common.opt
index d33383b523c..09cabeb114d 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -3408,4 +3408,8 @@ fipa-ra
Common Report Var(flag_ipa_ra) Optimization
Use caller save register across calls if possible.
+fipa-hello-world
+Common Report Var(flag_ipa_hello_world) Optimization
+TBD
+
; This comment is to ensure we retain the blank line above.
diff --git a/gcc/ipa-hello-world.c b/gcc/ipa-hello-world.c
new file mode 100644
index 000..00e276a4bd7
--- /dev/null
+++ b/gcc/ipa-hello-world.c
@@ -0,0 +1,126 @@
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "backend.h"
+#include "tree.h"
+#include "gimple-expr.h"
+#include "predict.h"
+#include "alloc-pool.h"
+#include "tree-pass.h"
+#include "cgraph.h"
+#include "diagnostic.h"
+#include "fold-const.h"
+#include "gimple-fold.h"
+#include "symbol-summary.h"
+#include "tree-vrp.h"
+#include "ipa-prop.h"
+#include "tree-pretty-print.h"
+#include "tree-inline.h"
+#include "ipa-fnsummary.h"
+#include "ipa-utils.h"
+#include "tree-ssa-ccp.h"
+#include "stringpool.h"
+#include "attribs.h"
+#include "tree-ssa-alias.h"
+#include "tree-ssanames.h"
+#include "gimple.h"
+#include "cfg.h"
+#include "gimple-iterator.h"
+#include "gimple-ssa.h"
+
+void inline
+log(const char* const fmt, ...)
+{
+ if (!dump_file) return;
+
+ va_list args;
+ va_start(args, fmt);
+ vfprintf(dump_file, fmt, args);
+ va_end(args);
+}
+
+static void
+alias_experiment_gimple_body(const cgraph_node *cnode)
+{
+ gcc_assert(cnode);
+
+ function *func = DECL_STRUCT_FUNCTION(cnode->decl);
+
+ // We are looking first into SSA becaues of
+ // this documentation...
+ // Points-to and escape analysis.
+ // Points-to analysis builds a set of constraints from the GIMPLE SSA IL
+ // representing all pointer operations and facts we do or do not know
+ // about pointers. Solving this set of constraints yields a
conservatively
+ // correct solution for each pointer variable in the program (though
we are
+ // only interested in SSA name pointers) as to what it may possibly
Re: gcc 10.0.1 20200506 build fails to compile linux kernel
Hi Martin, Thank you for your reply! Spot on! It was my kernel config problem associated with stronger stack protection of gcc-10, not a gcc problem. But I can't find this in kernel.org bugzilla or bugzilla.redhat.com (searched with "gcc 10" and "gcc-10".) It happens not in qemu or any VM, but on a native machine. As in https://bugzilla.redhat.com/show_bug.cgi?id=1796780 (this is the first url in the page you mentioned), turning CONFIG_STACKPROTECTOR_STRONG off, lo and behold, the kernel works perfectly!! And as a matter of course, it works for the latest kernel 5.6.11 also. My problem was that I brought my custom kernel config file from Fedora 31 with gcc-9. I should have started from the prototype config file /boot/config-5.6.8-300.fc32.x86_64, where CONFIG_STACKPROTECTOR_STRONG is off for its native gcc. Thank you very much!! -Tetsuji On 5/6/20 4:19 PM, Martin Liška wrote: > On 5/6/20 6:44 AM, Tetsuji Rai via Gcc wrote: >> I wonder how Fedora project built its own kernel. I can't build custom >> kernel with it. >> >> What's wrong with 10.1-RC or how can I report my problem? > > Hi. > > Is it possible that you reached > https://lore.kernel.org/lkml/20200417190607.GY2424@tucnak/T/ ? > > I can try to reproduce that but please file a bug at or bugzilla and > provide > steps how to reproduce the issue. Can you also reproduce it within a > qemu VM? > > Thanks, > Martin
Re: [libgomp] Ask for help on an improvement for synchronization overhead
On 30/04/2020 18:12, Jakub Jelinek wrote: > On Thu, Apr 30, 2020 at 05:37:26PM -0300, Adhemerval Zanella via Gcc wrote: >> Hi all, I would like to check if someone could help me figure out >> an issue I am chasing on a libgomp patch intended to partially >> address the issue described at BZ#79784. >> >> I have identified that one of the bottlenecks is the global barrier >> used on both thread pool and team which causes a lof of cache ping-pong >> in high-core count machines. And it seems not be an aarch64 specific >> issue as hinted by the bugzilla. > > This has been a topic of GSoC last year, but the student didn't deliver it > in usable form and disappeared. > See e.g. thread with "Work-stealing task scheduling" in subject from > last year on gcc-patches and other mails on the topic. In my understanding what I am working is not exactly related to OMP tasking, although I see that the global barrier is still an issue on omp task scheduling. What I am trying to optimize in this specific case is the barrier used on gomp_thread_pool used on constructs like parallel for and maybe a per-thread barrier could be extended to other libgomp places. > > So if you'd have time and motivation to do it properly, it would be greatly > appreciated. >
Re: Question about alias or points-to analysis
On Wed, May 6, 2020 at 12:26 PM Erick Ochoa
wrote:
>
> Hi,
>
> I am trying to find out how to use the alias and/or points-to analysis
> in GCC. Ideally, I would like to find a function that given an
> allocation site, the return value is a set of pointers which may point
> to memory allocated from that allocation site.
>
> For example:
>
> int
> main(int argc, char** argv)
> {
>int a;
>int *b = argc > 2 ? &a : NULL;
>int *c = b;
> }
>
> Here, querying the allocation site corresponding to the declaration of
> local variable "a", should return { "b", "c" }.
So that's a "reverse query" to that you are asking for below ...
> I've found the following documentation on Alias-Analysis [0] and two
> source files[1][2] which seem to implement some (distinct?) alias analysis.
>
> I am trying to keep the discussion a bit high level, otherwise I would
> have a lot of questions, but given this C example, **how would someone
> be able to use any of the alias analyses in GCC to determine that "b"
> and "c" may-alias "a"?**
... here? Otherwise for a pointer "b" you can query whether it may-alias
"a" by using ptr_deref_may_alias_decl_p (b, a) or of 'a' is not a decl
but a general reference there is ptr_deref_may_alias_ref_p_1
(not exported - there wasn't any need sofar).
> I compiled my example and placed an pass to experiment with alias
> analysis at link time. (I include the patch at the end). This is the
> gimple produced by the example above.
>
> main (int argc, char * * argv)
> {
>int * c;
>int * b;
>int a;
>int D.4170;
>int * iftmp.0;
>int * iftmp.0_1;
>int * iftmp.0_3;
>int * iftmp.0_4;
>int _9;
>
> :
>if (argc_2(D) > 2)
> goto ; [INV]
>else
> goto ; [INV]
>
> :
>iftmp.0_4 = &a;
>goto ; [INV]
>
> :
>iftmp.0_3 = 0B;
>
> :
># iftmp.0_1 = PHI
>b_5 = iftmp.0_1;
>c_6 = b_5;
>a ={v} {CLOBBER};
>_9 = 0;
>
> :
> :
>return _9;
>
> }
>
> I include this example because looking at the Alias Analysis [0]
> section, it mentions memory SSA form. But I do not see any #.MEM_n
> assignments.
You need to dump with the -vops modifier (to get virtual operands dumped).
And you can use the -alias modifier to dump points-to results.
> Furthermore, I made an equivalent code to the example of Memory SSA form
> and I still don't see any Memory SSA forms:
>
> ```c
> int i;
> int foo()
> {
>i = 1;
>return i;
> }
> ```
>
> ```gimple
> foo ()
> {
>int D.4164;
>int _3;
>
> :
>i = 1;
>_3 = i;
>
> :
> :
>return _3;
>
> }
> ```
>
> So, I am not sure how the gimple shown on the Alias-analysis page is
> produced. **Does anyone know why the gimple produced is not showing the
> virtual SSA names?**
>
> Afterwards, instead of looking at the virtual SSA names, I then focused
> on finding out whether SSA_NAME_PTR_INFO but I found that it was not
> set. **Do I need I need to run something to make sure that
> SSA_NAME_PTR_INFO is set?** Maybe the example I chose for compilation
> did not trigger the path for setting SSA_NAME_PTR_INFO. What would be an
> example of some code that does set SSA_NAME_PTR_INFO?
SSA_NAME_PTR_INFO is computed by points-to analysis, for a simple
IPA pass run at LTRANS time that will not be computed yet (it is not
streamed into the IL because it's not in a convenient form and it can be
and is re-computed early enough - just not for you ;)). Without LTO
the info should be still there from the early optimization pipeline computation.
Hope this helps,
Richard.
> Here is the patch, and in order to compile an example and dump the log:
>
> /path/to/gcc -fdump-ipa-hello-world -fipa-hello-world a.c
>
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index 543b477ff18..bc1af09cbf8 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -1399,6 +1399,7 @@ OBJS = \
> incpath.o \
> init-regs.o \
> internal-fn.o \
> + ipa-hello-world.o \
> ipa-cp.o \
> ipa-sra.o \
> ipa-devirt.o \
> diff --git a/gcc/common.opt b/gcc/common.opt
> index d33383b523c..09cabeb114d 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -3408,4 +3408,8 @@ fipa-ra
> Common Report Var(flag_ipa_ra) Optimization
> Use caller save register across calls if possible.
>
> +fipa-hello-world
> +Common Report Var(flag_ipa_hello_world) Optimization
> +TBD
> +
> ; This comment is to ensure we retain the blank line above.
> diff --git a/gcc/ipa-hello-world.c b/gcc/ipa-hello-world.c
> new file mode 100644
> index 000..00e276a4bd7
> --- /dev/null
> +++ b/gcc/ipa-hello-world.c
> @@ -0,0 +1,126 @@
> +#include "config.h"
> +#include "system.h"
> +#include "coretypes.h"
> +#include "backend.h"
> +#include "tree.h"
> +#include "gimple-expr.h"
> +#include "predict.h"
> +#include "alloc-pool.h"
> +#include "tree-pass.h"
> +#include "cgraph.h"
> +#include "diagnostic.h"
> +#include "fold-const.h"
> +#include "gimple-fold.h"
> +#include "symbol-summary.
Re: gcc 10.0.1 20200506 build fails to compile linux kernel
On 5/6/20 2:01 PM, Tetsuji Rai wrote: Hi Martin, Thank you for your reply! Spot on! It was my kernel config problem associated with stronger stack protection of gcc-10, not a gcc problem. But I can't find this in kernel.org bugzilla or bugzilla.redhat.com (searched with "gcc 10" and "gcc-10".) It was probably not reported to Linux bugzilla. It happens not in qemu or any VM, but on a native machine. As in https://bugzilla.redhat.com/show_bug.cgi?id=1796780 (this is the first url in the page you mentioned), turning CONFIG_STACKPROTECTOR_STRONG off, lo and behold, the kernel works perfectly!! And as a matter of course, it works for the latest kernel 5.6.11 also. My problem was that I brought my custom kernel config file from Fedora 31 with gcc-9. I should have started from the prototype config file /boot/config-5.6.8-300.fc32.x86_64, where CONFIG_STACKPROTECTOR_STRONG is off for its native gcc. Thank you very much!! Great it's a known issue. Martin -Tetsuji On 5/6/20 4:19 PM, Martin Liška wrote: On 5/6/20 6:44 AM, Tetsuji Rai via Gcc wrote: I wonder how Fedora project built its own kernel. I can't build custom kernel with it. What's wrong with 10.1-RC or how can I report my problem? Hi. Is it possible that you reached https://lore.kernel.org/lkml/20200417190607.GY2424@tucnak/T/ ? I can try to reproduce that but please file a bug at or bugzilla and provide steps how to reproduce the issue. Can you also reproduce it within a qemu VM? Thanks, Martin
Re: Question about alias or points-to analysis
On 06/05/2020 14:25, Richard Biener wrote:
On Wed, May 6, 2020 at 12:26 PM Erick Ochoa
wrote:
Hi,
I am trying to find out how to use the alias and/or points-to analysis
in GCC. Ideally, I would like to find a function that given an
allocation site, the return value is a set of pointers which may point
to memory allocated from that allocation site.
For example:
int
main(int argc, char** argv)
{
int a;
int *b = argc > 2 ? &a : NULL;
int *c = b;
}
Here, querying the allocation site corresponding to the declaration of
local variable "a", should return { "b", "c" }.
So that's a "reverse query" to that you are asking for below ...
I've found the following documentation on Alias-Analysis [0] and two
source files[1][2] which seem to implement some (distinct?) alias analysis.
I am trying to keep the discussion a bit high level, otherwise I would
have a lot of questions, but given this C example, **how would someone
be able to use any of the alias analyses in GCC to determine that "b"
and "c" may-alias "a"?**
... here? Otherwise for a pointer "b" you can query whether it may-alias
"a" by using ptr_deref_may_alias_decl_p (b, a) or of 'a' is not a decl
but a general reference there is ptr_deref_may_alias_ref_p_1
(not exported - there wasn't any need sofar).
Thanks Richard. I'll look into the Tree alias-oracle API.
I compiled my example and placed an pass to experiment with alias
analysis at link time. (I include the patch at the end). This is the
gimple produced by the example above.
main (int argc, char * * argv)
{
int * c;
int * b;
int a;
int D.4170;
int * iftmp.0;
int * iftmp.0_1;
int * iftmp.0_3;
int * iftmp.0_4;
int _9;
:
if (argc_2(D) > 2)
goto ; [INV]
else
goto ; [INV]
:
iftmp.0_4 = &a;
goto ; [INV]
:
iftmp.0_3 = 0B;
:
# iftmp.0_1 = PHI
b_5 = iftmp.0_1;
c_6 = b_5;
a ={v} {CLOBBER};
_9 = 0;
:
:
return _9;
}
I include this example because looking at the Alias Analysis [0]
section, it mentions memory SSA form. But I do not see any #.MEM_n
assignments.
You need to dump with the -vops modifier (to get virtual operands dumped).
And you can use the -alias modifier to dump points-to results.
>> Furthermore, I made an equivalent code to the example of Memory SSA form
and I still don't see any Memory SSA forms:
```c
int i;
int foo()
{
i = 1;
return i;
}
```
```gimple
foo ()
{
int D.4164;
int _3;
:
i = 1;
_3 = i;
:
:
return _3;
}
```
So, I am not sure how the gimple shown on the Alias-analysis page is
produced. **Does anyone know why the gimple produced is not showing the
virtual SSA names?**
Afterwards, instead of looking at the virtual SSA names, I then focused
on finding out whether SSA_NAME_PTR_INFO but I found that it was not
set. **Do I need I need to run something to make sure that
SSA_NAME_PTR_INFO is set?** Maybe the example I chose for compilation
did not trigger the path for setting SSA_NAME_PTR_INFO. What would be an
example of some code that does set SSA_NAME_PTR_INFO?
SSA_NAME_PTR_INFO is computed by points-to analysis, for a simple
IPA pass run at LTRANS time that will not be computed yet (it is not
streamed into the IL because it's not in a convenient form and it can be
and is re-computed early enough - just not for you ;)). Without LTO
the info should be still there from the early optimization pipeline computation.
So, does this mean that there's no alias information available at LTO?
Or are you saying that I should store alias information at LGEN time and
use it at WPA time to make my transformation plan and finally transform
at LTRANS time?
Hope this helps,
Richard.
Here is the patch, and in order to compile an example and dump the log:
/path/to/gcc -fdump-ipa-hello-world -fipa-hello-world a.c
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 543b477ff18..bc1af09cbf8 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1399,6 +1399,7 @@ OBJS = \
incpath.o \
init-regs.o \
internal-fn.o \
+ ipa-hello-world.o \
ipa-cp.o \
ipa-sra.o \
ipa-devirt.o \
diff --git a/gcc/common.opt b/gcc/common.opt
index d33383b523c..09cabeb114d 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -3408,4 +3408,8 @@ fipa-ra
Common Report Var(flag_ipa_ra) Optimization
Use caller save register across calls if possible.
+fipa-hello-world
+Common Report Var(flag_ipa_hello_world) Optimization
+TBD
+
; This comment is to ensure we retain the blank line above.
diff --git a/gcc/ipa-hello-world.c b/gcc/ipa-hello-world.c
new file mode 100644
index 000..00e276a4bd7
--- /dev/null
+++ b/gcc/ipa-hello-world.c
@@ -0,0 +1,126 @@
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "backend.h"
+#include "tree.h"
+#include "gimple-expr.h"
+#include "predict.h"
+#include "alloc-pool.h"
+#include "tree-pass.h"
+#include
Stability of pipermail ml archive URLs
Hi! Last week after sending status report mails to gcc mailing list, I've opened the web archive and copied the URLs of those status reports https://gcc.gnu.org/pipermail/gcc/2020-April/232267.html https://gcc.gnu.org/pipermail/gcc/2020-April/232268.html and checked them into gcc-wwwdocs git c3162d9e711d3e32935c17d1451c63839d702019 revision. But today people are complaining that those links don't work anymore and those mails have https://gcc.gnu.org/pipermail/gcc/2020-April/000504.html https://gcc.gnu.org/pipermail/gcc/2020-April/000505.html URLs instead. Martin Jambor also said he has posted a URL into the archive https://gcc.gnu.org/pipermail/gcc/2020-February/231851.html which is now instead https://gcc.gnu.org/pipermail/gcc/2020-February/232205.html Looking around, the last two months of gcc now have very small numbers, but e.g. on gcc-patches the mails have very high numbers like 545238.html. Can pipermail provide stable URLs at all? We really need those, we reference those in commit messages, other mails, bugzilla etc. Jakub
Re: Stability of pipermail ml archive URLs
Hi - > https://gcc.gnu.org/pipermail/gcc/2020-February/232205.html > Looking around, the last two months of gcc now have very small > numbers, but e.g. on gcc-patches the mails have very high numbers like > 545238.html. Can pipermail provide stable URLs at all? We really > need those, we reference those in commit messages, other mails, bugzilla > etc. Argh, that is a problem, sorry. We get mailman to regenerate web archives for example in the case of spam that has gone through. Our recipe has been to delete the spam from the apropriate .mbox, but this does renumber things. The big vs. little numbers are probably an accidental function of whether the email .mbox files were processed chronologically or not. I'll tweak the mrefresh script to make sure it's chronological; that should avoid gross jumps like that. I believe gcc-patches just wasn't regenerated for spam removal whereas others have. There should not be gross jumps in the future, except we'll have to regenerate everything one more time. :-( Small jumps though --- darn, we'd have to do something else with spam in the mbox, maybe replace it somehow in situ with something else. Or catch it so quickly that subsequent URLs aren't archived anywhere important. It would be good to have another way of making permanent URLs for individual messages in mailing list archives. - FChE
Re: Stability of pipermail ml archive URLs
Hi, >> https://gcc.gnu.org/pipermail/gcc/2020-February/232205.html >> Looking around, the last two months of gcc now have very small >> numbers, but e.g. on gcc-patches the mails have very high numbers like >> 545238.html. Can pipermail provide stable URLs at all? We really >> need those, we reference those in commit messages, other mails, bugzilla >> etc. > > Argh, that is a problem, sorry. We get mailman to regenerate web > archives for example in the case of spam that has gone through. Our > recipe has been to delete the spam from the apropriate .mbox, but this > does renumber things. > > The big vs. little numbers are probably an accidental function of > whether the email .mbox files were processed chronologically or not. > I'll tweak the mrefresh script to make sure it's chronological; that > should avoid gross jumps like that. I believe gcc-patches just wasn't > regenerated for spam removal whereas others have. There should not be > gross jumps in the future, except we'll have to regenerate everything > one more time. :-( > > Small jumps though --- darn, we'd have to do something else with spam > in the mbox, maybe replace it somehow in situ with something else. Or > catch it so quickly that subsequent URLs aren't archived anywhere > important. > > It would be good to have another way of making permanent URLs for > individual messages in mailing list archives. may I also chime in with a related (to some extent), even though a separate issue? It seems URL rewriting rules designed to replace old-style https://gcc.gnu.org/ml//current URLs pointing to monthly digests to current ones https://gcc.gnu.org/pipermail///date.html#end broke with onset of May. I mean, if I type https://gcc.gnu.org/ml/gcc/current I still get https://gcc.gnu.org/pipermail/gcc/2020-April/date.html#end (note 2020-April) instead.
Re: Stability of pipermail ml archive URLs
Hi, >> https://gcc.gnu.org/pipermail/gcc/2020-February/232205.html >> Looking around, the last two months of gcc now have very small >> numbers, but e.g. on gcc-patches the mails have very high numbers like >> 545238.html. Can pipermail provide stable URLs at all? We really >> need those, we reference those in commit messages, other mails, bugzilla >> etc. > > Argh, that is a problem, sorry. We get mailman to regenerate web > archives for example in the case of spam that has gone through. Our > recipe has been to delete the spam from the apropriate .mbox, but this > does renumber things. > > The big vs. little numbers are probably an accidental function of > whether the email .mbox files were processed chronologically or not. > I'll tweak the mrefresh script to make sure it's chronological; that > should avoid gross jumps like that. I believe gcc-patches just wasn't > regenerated for spam removal whereas others have. There should not be > gross jumps in the future, except we'll have to regenerate everything > one more time. :-( > > Small jumps though --- darn, we'd have to do something else with spam > in the mbox, maybe replace it somehow in situ with something else. Or > catch it so quickly that subsequent URLs aren't archived anywhere > important. > > It would be good to have another way of making permanent URLs for > individual messages in mailing list archives. may I also chime in with a related (to some extent), even though a separate issue? It seems URL rewriting rules designed to replace old-style https://gcc.gnu.org/ml//current URLs pointing to monthly digests to current ones https://gcc.gnu.org/pipermail///date.html#end broke with onset of May. I mean, if I type https://gcc.gnu.org/ml/gcc/current I still get https://gcc.gnu.org/pipermail/gcc/2020-April/date.html#end (note 2020-April) instead.
Re: Stability of pipermail ml archive URLs
On Wed, May 06, 2020 at 04:11:39PM +0200, Jakub Jelinek wrote: >Hi! > >Last week after sending status report mails to gcc mailing list, >I've opened the web archive and copied the URLs of those status reports >https://gcc.gnu.org/pipermail/gcc/2020-April/232267.html >https://gcc.gnu.org/pipermail/gcc/2020-April/232268.html >and checked them into gcc-wwwdocs git >c3162d9e711d3e32935c17d1451c63839d702019 revision. >But today people are complaining that those links don't work anymore >and those mails have >https://gcc.gnu.org/pipermail/gcc/2020-April/000504.html >https://gcc.gnu.org/pipermail/gcc/2020-April/000505.html >URLs instead. >Martin Jambor also said he has posted a URL into the archive >https://gcc.gnu.org/pipermail/gcc/2020-February/231851.html >which is now instead >https://gcc.gnu.org/pipermail/gcc/2020-February/232205.html >Looking around, the last two months of gcc now have very small >numbers, but e.g. on gcc-patches the mails have very high numbers like >545238.html. Can pipermail provide stable URLs at all? We really >need those, we reference those in commit messages, other mails, bugzilla >etc. I'll bet this is due to rebuilding the archive after removing spam. Maybe we need to revisit how that's done. cgf
Re: Stability of pipermail ml archive URLs
On Wed, May 06, 2020 at 09:54:06PM +0700, Arseny Solokha wrote: >may I also chime in with a related (to some extent), even though a separate >issue? It seems URL rewriting rules designed to replace old-style > > https://gcc.gnu.org/ml//current > >URLs pointing to monthly digests to current ones > > https://gcc.gnu.org/pipermail///date.html#end > >broke with onset of May. I mean, if I type > > https://gcc.gnu.org/ml/gcc/current > >I still get > > https://gcc.gnu.org/pipermail/gcc/2020-April/date.html#end > >(note 2020-April) instead. This is not related in any way. I'll fix this. Apparently my cron job didn't fire. cgf
Re: Question about alias or points-to analysis
On Wed, May 6, 2020 at 3:04 PM Erick Ochoa
wrote:
>
>
>
> On 06/05/2020 14:25, Richard Biener wrote:
> > On Wed, May 6, 2020 at 12:26 PM Erick Ochoa
> > wrote:
> >>
> >> Hi,
> >>
> >> I am trying to find out how to use the alias and/or points-to analysis
> >> in GCC. Ideally, I would like to find a function that given an
> >> allocation site, the return value is a set of pointers which may point
> >> to memory allocated from that allocation site.
> >>
> >> For example:
> >>
> >> int
> >> main(int argc, char** argv)
> >> {
> >> int a;
> >> int *b = argc > 2 ? &a : NULL;
> >> int *c = b;
> >> }
> >>
> >> Here, querying the allocation site corresponding to the declaration of
> >> local variable "a", should return { "b", "c" }.
> >
> > So that's a "reverse query" to that you are asking for below ...
> >
> >> I've found the following documentation on Alias-Analysis [0] and two
> >> source files[1][2] which seem to implement some (distinct?) alias analysis.
> >>
> >> I am trying to keep the discussion a bit high level, otherwise I would
> >> have a lot of questions, but given this C example, **how would someone
> >> be able to use any of the alias analyses in GCC to determine that "b"
> >> and "c" may-alias "a"?**
> >
> > ... here? Otherwise for a pointer "b" you can query whether it may-alias
> > "a" by using ptr_deref_may_alias_decl_p (b, a) or of 'a' is not a decl
> > but a general reference there is ptr_deref_may_alias_ref_p_1
> > (not exported - there wasn't any need sofar).
>
> Thanks Richard. I'll look into the Tree alias-oracle API.
>
> >
> >> I compiled my example and placed an pass to experiment with alias
> >> analysis at link time. (I include the patch at the end). This is the
> >> gimple produced by the example above.
> >>
> >> main (int argc, char * * argv)
> >> {
> >> int * c;
> >> int * b;
> >> int a;
> >> int D.4170;
> >> int * iftmp.0;
> >> int * iftmp.0_1;
> >> int * iftmp.0_3;
> >> int * iftmp.0_4;
> >> int _9;
> >>
> >> :
> >> if (argc_2(D) > 2)
> >> goto ; [INV]
> >> else
> >> goto ; [INV]
> >>
> >> :
> >> iftmp.0_4 = &a;
> >> goto ; [INV]
> >>
> >> :
> >> iftmp.0_3 = 0B;
> >>
> >> :
> >> # iftmp.0_1 = PHI
> >> b_5 = iftmp.0_1;
> >> c_6 = b_5;
> >> a ={v} {CLOBBER};
> >> _9 = 0;
> >>
> >> :
> >> :
> >> return _9;
> >>
> >> }
> >>
> >> I include this example because looking at the Alias Analysis [0]
> >> section, it mentions memory SSA form. But I do not see any #.MEM_n
> >> assignments.
> >
> > You need to dump with the -vops modifier (to get virtual operands dumped).
> > And you can use the -alias modifier to dump points-to results.
> > >> Furthermore, I made an equivalent code to the example of Memory SSA form
> >> and I still don't see any Memory SSA forms:
> >>
> >> ```c
> >> int i;
> >> int foo()
> >> {
> >> i = 1;
> >> return i;
> >> }
> >> ```
> >>
> >> ```gimple
> >> foo ()
> >> {
> >> int D.4164;
> >> int _3;
> >>
> >> :
> >> i = 1;
> >> _3 = i;
> >>
> >> :
> >> :
> >> return _3;
> >>
> >> }
> >> ```
> >>
> >> So, I am not sure how the gimple shown on the Alias-analysis page is
> >> produced. **Does anyone know why the gimple produced is not showing the
> >> virtual SSA names?**
> >>
> >> Afterwards, instead of looking at the virtual SSA names, I then focused
> >> on finding out whether SSA_NAME_PTR_INFO but I found that it was not
> >> set. **Do I need I need to run something to make sure that
> >> SSA_NAME_PTR_INFO is set?** Maybe the example I chose for compilation
> >> did not trigger the path for setting SSA_NAME_PTR_INFO. What would be an
> >> example of some code that does set SSA_NAME_PTR_INFO?
> >
> > SSA_NAME_PTR_INFO is computed by points-to analysis, for a simple
> > IPA pass run at LTRANS time that will not be computed yet (it is not
> > streamed into the IL because it's not in a convenient form and it can be
> > and is re-computed early enough - just not for you ;)). Without LTO
> > the info should be still there from the early optimization pipeline
> > computation.
> >
>
> So, does this mean that there's no alias information available at LTO?
> Or are you saying that I should store alias information at LGEN time and
> use it at WPA time to make my transformation plan and finally transform
> at LTRANS time?
There is no points-to information available during WPA. There is no
points-to information during LTRANS until pass_build_alias is run
which is before the first user (if you exclude your simple IPA pass).
If you need points-to information at WPA you either need to compute it
(it looks like you need to stream in function bodies anyway to use it,
so you could simply call compute_may_aliases on each function) or
what seems to be a better strathegy try to compute as much as
possible during IPA analysis and do final verification at LTRANS stage.
If that's possible of course depends on the exact t
Re: [Inline assembly] thought on the memory
Hi!
On Thu, Apr 30, 2020 at 02:48:18PM +0200, FRÉDÉRIC RECOULES wrote:
> I am looking for some clarification about how are working the memory
> operands, especially when the constraint allows memory only (eg. "m").
> Please note that in a lesser extent, I know (by looking the gcc sources) how
> the things are currently working but I wonder if it is a design choice or
> simply a serendipitous engineering consequence.
> Indeed, as far as I know, the documentation is not explicit on this.
>
> Only things related to memory I have found are:
> > A string constant specifying constraints on the placement of the operand;
> > See Constraints, for details.
> > ‘ m ’ A memory operand is allowed, with any kind of address that the
> > machine supports in general.
>
> When I read this, I think that "m" work exactly as "r" from a C point of
> view. But in fact, there are some conceptual corner cases where there are not
> equivalent.
>
> (1) It is said that an output must be an lvalue. However, it is said nowhere
> (except that compilation fails) that if the constraint allows only memory, an
> input expression must be an lvalue too.
But it has to. *Anything* in memory, inline asm or not, can have its
address taken. "Anything in memory is an lvalue".
> There are a lot of workarounds, but why the following code (actually not
> relevant) is rejected?
> __asm__ ("movl %1, %0" : "=r" (x) : "m" (1));
> I would think that the compiler could put the constant 1 in the stack or in
> a static address or even reuse any memory address known to hold the value 1.
It could, but it doesn't. GCC requires memory constraints to refer to
something that can have its address taken. Constants do not have an
address.
You can put the constant in a variable yourself.
> (2) If the constraint allows only memory, does the compiler allowed to make a
> copy? (if no, why?)
A memory constraint refers to *that* memory. Copies would not work in
general, considering atomics and the like.
> (2.1) Thus, if I declare an output and an input using the same lvalue, am I
> guaranteed that they both point to the same location? (as far as I know, it
> is not true for register constraint)
> __asm__ ("incl %0" : "=m" (x) : "m" (x));
This is correct. Registers should use "0" etc. Memory is like you say.
> (2.2) Moreover, in the following example of the doc, is edi guaranteed to
> point to the memory pointed by "m" (*(const char (*)[]) p) ?
>
> > asm("repne scasb"
> >: "=c" (count), "+D" (p)
> >: "m" (*(const char (*)[]) p), "0" (-1), "a" (0));
Why not? They are just two independent inputs? That one is the address
of the other doesn't really change anything?
Re: Question about alias or points-to analysis
On 06/05/2020 18:40, Richard Biener wrote:
On Wed, May 6, 2020 at 3:04 PM Erick Ochoa
wrote:
On 06/05/2020 14:25, Richard Biener wrote:
On Wed, May 6, 2020 at 12:26 PM Erick Ochoa
wrote:
Hi,
I am trying to find out how to use the alias and/or points-to analysis
in GCC. Ideally, I would like to find a function that given an
allocation site, the return value is a set of pointers which may point
to memory allocated from that allocation site.
For example:
int
main(int argc, char** argv)
{
int a;
int *b = argc > 2 ? &a : NULL;
int *c = b;
}
Here, querying the allocation site corresponding to the declaration of
local variable "a", should return { "b", "c" }.
So that's a "reverse query" to that you are asking for below ...
I've found the following documentation on Alias-Analysis [0] and two
source files[1][2] which seem to implement some (distinct?) alias analysis.
I am trying to keep the discussion a bit high level, otherwise I would
have a lot of questions, but given this C example, **how would someone
be able to use any of the alias analyses in GCC to determine that "b"
and "c" may-alias "a"?**
... here? Otherwise for a pointer "b" you can query whether it may-alias
"a" by using ptr_deref_may_alias_decl_p (b, a) or of 'a' is not a decl
but a general reference there is ptr_deref_may_alias_ref_p_1
(not exported - there wasn't any need sofar).
Thanks Richard. I'll look into the Tree alias-oracle API.
I compiled my example and placed an pass to experiment with alias
analysis at link time. (I include the patch at the end). This is the
gimple produced by the example above.
main (int argc, char * * argv)
{
int * c;
int * b;
int a;
int D.4170;
int * iftmp.0;
int * iftmp.0_1;
int * iftmp.0_3;
int * iftmp.0_4;
int _9;
:
if (argc_2(D) > 2)
goto ; [INV]
else
goto ; [INV]
:
iftmp.0_4 = &a;
goto ; [INV]
:
iftmp.0_3 = 0B;
:
# iftmp.0_1 = PHI
b_5 = iftmp.0_1;
c_6 = b_5;
a ={v} {CLOBBER};
_9 = 0;
:
:
return _9;
}
I include this example because looking at the Alias Analysis [0]
section, it mentions memory SSA form. But I do not see any #.MEM_n
assignments.
You need to dump with the -vops modifier (to get virtual operands dumped).
And you can use the -alias modifier to dump points-to results.
>> Furthermore, I made an equivalent code to the example of Memory SSA form
and I still don't see any Memory SSA forms:
```c
int i;
int foo()
{
i = 1;
return i;
}
```
```gimple
foo ()
{
int D.4164;
int _3;
:
i = 1;
_3 = i;
:
:
return _3;
}
```
So, I am not sure how the gimple shown on the Alias-analysis page is
produced. **Does anyone know why the gimple produced is not showing the
virtual SSA names?**
Afterwards, instead of looking at the virtual SSA names, I then focused
on finding out whether SSA_NAME_PTR_INFO but I found that it was not
set. **Do I need I need to run something to make sure that
SSA_NAME_PTR_INFO is set?** Maybe the example I chose for compilation
did not trigger the path for setting SSA_NAME_PTR_INFO. What would be an
example of some code that does set SSA_NAME_PTR_INFO?
SSA_NAME_PTR_INFO is computed by points-to analysis, for a simple
IPA pass run at LTRANS time that will not be computed yet (it is not
streamed into the IL because it's not in a convenient form and it can be
and is re-computed early enough - just not for you ;)). Without LTO
the info should be still there from the early optimization pipeline computation.
So, does this mean that there's no alias information available at LTO?
Or are you saying that I should store alias information at LGEN time and
use it at WPA time to make my transformation plan and finally transform
at LTRANS time?
There is no points-to information available during WPA. There is no
points-to information during LTRANS until pass_build_alias is run
which is before the first user (if you exclude your simple IPA pass).
If you need points-to information at WPA you either need to compute it
(it looks like you need to stream in function bodies anyway to use it,
so you could simply call compute_may_aliases on each function) or
what seems to be a better strathegy try to compute as much as
possible during IPA analysis and do final verification at LTRANS stage.
If that's possible of course depends on the exact things you need to do.
Richard.
Thanks Richard!
I understood one of the two approaches you discuss here. It is indeed
simple to call compute_may_aliases on each of the functions. However, I
do not understand what you mean by "compute as much as possible during
IPA analaysis". Can you please elaborate?
For "compute" do you mean computing the may-points to set on my own?
Perhaps using some of GCC's infrastructure as a foundation? Or do you
also mean calling compute_may_aliases on each function?
By "during IPA analys
Multilibs in stage-1
Hello! I wonder, if the build process really needs to build all multilibs in stage-1 bootstrap build. IIRC, stage-1 uses system compiler to build stage-1 gcc, so there is no need for multilibs, apart from library that will be used by stage-1 gcc during compilation of stage-2 compiler. Uros.
Re: [libgomp] Ask for help on an improvement for synchronization overhead
On Wed, 2020-05-06 at 09:08 -0300, Adhemerval Zanella via Gcc wrote: > > On 30/04/2020 18:12, Jakub Jelinek wrote: > > On Thu, Apr 30, 2020 at 05:37:26PM -0300, Adhemerval Zanella via Gcc wrote: > > > Hi all, I would like to check if someone could help me figure out > > > an issue I am chasing on a libgomp patch intended to partially > > > address the issue described at BZ#79784. > > > > > > I have identified that one of the bottlenecks is the global barrier > > > used on both thread pool and team which causes a lof of cache ping-pong > > > in high-core count machines. And it seems not be an aarch64 specific > > > issue as hinted by the bugzilla. > > > > This has been a topic of GSoC last year, but the student didn't deliver it > > in usable form and disappeared. > > See e.g. thread with "Work-stealing task scheduling" in subject from > > last year on gcc-patches and other mails on the topic. > > In my understanding what I am working is not exactly related to OMP tasking, > although I see that the global barrier is still an issue on omp task > scheduling. > What I am trying to optimize in this specific case is the barrier used > on gomp_thread_pool used on constructs like parallel for and maybe a > per-thread > barrier could be extended to other libgomp places. > > > So if you'd have time and motivation to do it properly, it would be greatly > > appreciated. > > Hi, Sorry for the disappearance, I've been working on my thesis. I'll come back to the work-stealing scheduler soon. Sorry for the inconvenience. Ray Kim
Re: Multilibs in stage-1
On May 6, 2020 11:15:08 PM GMT+02:00, Uros Bizjak via Gcc wrote: >Hello! > >I wonder, if the build process really needs to build all multilibs in >stage-1 bootstrap build. IIRC, stage-1 uses system compiler to build >stage-1 gcc, so there is no need for multilibs, apart from library >that will be used by stage-1 gcc during compilation of stage-2 >compiler. Correct. Only stage3 needs those. But IIRC we already avoid building them? Likewise we avoid building libsanitizer and friends in stage 1/2 unless ubsan bootstrap is enabled. >Uros.
Re: Multilibs in stage-1
On Thu, May 7, 2020 at 8:16 AM Richard Biener wrote: > > On May 6, 2020 11:15:08 PM GMT+02:00, Uros Bizjak via Gcc > wrote: > >Hello! > > > >I wonder, if the build process really needs to build all multilibs in > >stage-1 bootstrap build. IIRC, stage-1 uses system compiler to build > >stage-1 gcc, so there is no need for multilibs, apart from library > >that will be used by stage-1 gcc during compilation of stage-2 > >compiler. > > Correct. Only stage3 needs those. But IIRC we already avoid building them? > Likewise we avoid building libsanitizer and friends in stage 1/2 unless ubsan > bootstrap is enabled. Looking at: [gcc-build]$ ls stage1-x86_64-pc-linux-gnu/32/ libgcc libgomp libstdc++-v3 it seems that 32bit multilibs are built anyway, also in stage2: [gcc-build]$ ls prev-x86_64-pc-linux-gnu/32/ libgcc libgomp libstdc++-v3 Uros.
