Re: How to get the data dependency of GIMPLE variables?
On Mon, 15 Jun 2020, Shuai Wang via Gcc wrote:
Dear Marc,
Thank you very much! Just another quick question.. Can I iterate the
operands of a GIMPLE statement, like how I iterate a LLVM instruction in
the following way?
Instruction* instr;
for (size_t i=0; i< instr->getNumOperands();i++) {
instr->getOperand(i))
}
Sorry for such naive questions.. I actually searched the documents and
GIMPLE pretty print for a while but couldn't find such a way of accessing
arbitrary numbers of operands...
https://gcc.gnu.org/onlinedocs/gccint/GIMPLE_005fASSIGN.html
or for lower level
https://gcc.gnu.org/onlinedocs/gccint/Logical-Operators.html#Operand-vector-allocation
But really you need to look at the code of gcc. Search for places that use
SSA_NAME_DEF_STMT and see what they do with the result.
--
Marc Glisse
Re: Write plugin for `sanopt` or `asan0` passes
On 6/14/20 4:15 PM, Shuai Wang via Gcc wrote: Hello, I am writing to inquire the procedure (or any tutorial) to write plugins for the `sanopt` pass. Basically I am doing some analysis of ASan/UBSan checks. I use the following command to dump all passes in IR format: gcc -fdump-tree-all -fsanitize=address test.c To me, I think the following two outputs: test.c.228t.asan0 test.c.230t.sanopt Seems both useful. I am relatively familiar with GIMPLE plugins; however, I note that in the GIMPLE code (e.g., test.c.005t.gimple), I just cannot find the corresponding ASAN check function calls, like .ASAN_CHECK. Hello. Can you please show how you iterate GIMPLE statements in basic blocks? You should find them with: gcall *call = dyn_cast (stmt) if (call) internal_fn fn = gimple_call_internal_fn (call); if (fn == IFN_ASAN_CHECK) ... Therefore, it seems that I cannot do GIMPLE-level plugin, although that seems easy for my tasks. Basically I will need to pinpoint either (in test.c.228t.asan0): : .ASAN_MARK (UNPOISON, &stack_array, 400); _10 = &stack_array[1]; * .ASAN_CHECK (7, _10, 4, 4); <--* stack_array[1] = 100; _1 = argc_5(D) + 12; _11 = &stack_array[_1]; * .ASAN_CHECK (6, _11, 4, 4); <--* c_6 = stack_array[_1]; Or (in test.c.230t.sanopt): _20 = _14 & 7; _21 = (signed char) _20; _22 = _21 + 3; _23 = _22 >= _18; _24 = _19 & _23; if (_24 != 0) goto ; [0.05%] else goto ; [99.95%] : * __builtin___asan_report_store4 (_14); <-* Could anyone shed some lights on how to write analysis passes/plugins for the outputs of either `sanopt` or `asan0`; I would prefer `sanopt` but any suggestion would be appreciated. Thank you very much. I would prefer modifying asan0 output rather then sanopt. What exactly do you want to change? Martin Best, Shuai
Re: Is it very hard to implement Zero-overhead deterministic exceptions: Throwing values??
On Sun, 14 Jun 2020 at 22:34, Andrew Pinski via Gcc wrote: > > On Sun, Jun 14, 2020 at 2:27 PM Andi Kleen via Gcc wrote: > > > > sotrdg sotrdg via Gcc writes: > > > > > http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0709r0.pdf > > > > > > I really want this feature. How, it looks like this requires changes > > > on RTL, gimple and C++ front-end. Is that very hard to implement it? > > > > If you're asking about setjmp/longjmp exceptions, you can already > > configure with --enable-sjlj-exceptions and then use -fsjlj-exceptions > > to enable them. > > > > It would be a new ABI and likely break some existing libraries. > > NOTE Setjmp/longjump is much much slower if exceptions are not used at > all. Because there will be many many setjump locations. This is nothing to do with SJLJ exceptions anyway.
SLP and dr_vec_info
I'm facing the issue that we have vector type dependent information stored in dr_vec_info (the misalignment at least) and that with BB vectorization (at least) we want to be able to access a DR group with two different vector types. I've run into this with https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547981.html and created the testcase https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547987.html in response to the fallout. I'm thinking of ways to circumvent this issue. In the end when we're SLP only my idea was that the stmt_vec_info (and thus the embedded dr_vec_info) only contain data that is valid in all possible SLP contexts. While we still have both SLP and non-SLP paths the approach of duplicating things on the SLP node becomes too complicated in most cases. So one possible "fix" is to put conservative values in dr_vec_info - for the misalignment this means consider the values of the vector type with the largest target alignment. Another possible fix is to not store anything vector type dependent there but compute such info in the places where we need it which then need to pass the actual vector type used. Now - do you have other options? Do you see obvious other pieces that need similar treatment? Thanks, Richard.
Push to my private branches is disallowed
Hi! $ git push -n fsf To git+ssh://gcc.gnu.org/git/gcc.git + 1db88c6...71e5e35 cc0 -> refs/users/segher/heads/cc0 (forced update) $ git push fsf Counting objects: 664, done. Delta compression using up to 64 threads. Compressing objects: 100% (239/239), done. Writing objects: 100% (504/504), 87.72 KiB | 0 bytes/s, done. Total 504 (delta 434), reused 321 (delta 265) remote: Resolving deltas: 100% (434/434), completed with 159 local objects. remote: *** !!! WARNING: This is *NOT* a fast-forward update. remote: *** !!! WARNING: You may have removed some important commits. remote: *** This update introduces too many new commits (2898), which would remote: *** trigger as many emails, exceeding the current limit (1000). remote: *** Contact your repository adminstrator if you really meant remote: *** to generate this many commit emails. remote: error: hook declined to update refs/users/segher/heads/cc0 To git+ssh://gcc.gnu.org/git/gcc.git ! [remote rejected] cc0 -> refs/users/segher/heads/cc0 (hook declined) error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc.git' What. Of course it is not a fast-forward. I rebase the branches I publish, what is the point of publishing them otherwise? This is so that people can see the stuff that will make its way into master *later*. The number of new commits is nonsense (it is just 13), and the number of emails that triggers should be 0. Please fix? Or, what else is wrong? Segher
Re: Push to my private branches is disallowed
On June 15, 2020 6:05:26 PM GMT+02:00, Segher Boessenkool wrote: >Hi! > >$ git push -n fsf >To git+ssh://gcc.gnu.org/git/gcc.git > + 1db88c6...71e5e35 cc0 -> refs/users/segher/heads/cc0 (forced update) > >$ git push fsf >Counting objects: 664, done. >Delta compression using up to 64 threads. >Compressing objects: 100% (239/239), done. >Writing objects: 100% (504/504), 87.72 KiB | 0 bytes/s, done. >Total 504 (delta 434), reused 321 (delta 265) >remote: Resolving deltas: 100% (434/434), completed with 159 local >objects. >remote: *** !!! WARNING: This is *NOT* a fast-forward update. >remote: *** !!! WARNING: You may have removed some important commits. >remote: *** This update introduces too many new commits (2898), which >would >remote: *** trigger as many emails, exceeding the current limit (1000). >remote: *** Contact your repository adminstrator if you really meant >remote: *** to generate this many commit emails. >remote: error: hook declined to update refs/users/segher/heads/cc0 >To git+ssh://gcc.gnu.org/git/gcc.git > ! [remote rejected] cc0 -> refs/users/segher/heads/cc0 (hook declined) >error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc.git' > >What. > >Of course it is not a fast-forward. I rebase the branches I publish, >what is the point of publishing them otherwise? This is so that people >can see the stuff that will make its way into master *later*. > >The number of new commits is nonsense (it is just 13), and the number >of >emails that triggers should be 0. > >Please fix? Or, what else is wrong? The number of commits is. From merges I suppose. Richard. > > >Segher
SSA_NAME_DEF_STMT or print_gimple_stmt for MEM_REF seems mal-functional
Hello,
Suppose given the following SSA statement generated by the `sanopt` pass:
_17 = (signed char *) _16;
_18 = *_17;
I am using the following code to identify that _17 depends on _16:
// def_stmt refers to _18 = &_17;
for (unsigned i = 1; i < gimple_num_ops(def_stmt); i++) {
op1 = gimple_assign_rhs1(def_stmt);
if (is_gimple_addressable(op1)) {
gimple* def_stmt = SSA_NAME_DEF_STMT(op1);
print_gimple_stmt(stderr, def_stmt, 0, TDF_SLIM); // crash at
this point
}
It crashes with the following call stack:
0xb5cd5f crash_signal
../../gcc-10.1.0/gcc/toplev.c:328
0x1452134 pp_format(pretty_printer*, text_info*)
../../gcc-10.1.0/gcc/pretty-print.c:1828
0x14533e4 pp_printf(pretty_printer*, char const*, ...)
../../gcc-10.1.0/gcc/pretty-print.c:1773
0x8dcc81 print_gimple_stmt(_IO_FILE*, gimple*, int, dump_flag)
../../gcc-10.1.0/gcc/gimple-pretty-print.c:157
I tried hard but just cannot understand why this would crash. Indeed, this
code works pretty well when printing out other dependency statements, but
just gets stuck in front of pointer dereference like _18 = *_17.
Any suggestion would be appreciated. Thank you!
Best,
Shuai
Re: Push to my private branches is disallowed
On Mon, Jun 15, 2020 at 06:28:39PM +0200, Richard Biener wrote: > On June 15, 2020 6:05:26 PM GMT+02:00, Segher Boessenkool > wrote: > >Of course it is not a fast-forward. I rebase the branches I publish, > >what is the point of publishing them otherwise? This is so that people > >can see the stuff that will make its way into master *later*. > > > >The number of new commits is nonsense (it is just 13), and the number > >of > >emails that triggers should be 0. > > > >Please fix? Or, what else is wrong? > > The number of commits is. From merges I suppose. It is just 13 new commits. It rebased though. There are no merges. Segher
Re: Push to my private branches is disallowed
On Jun 15 2020, Segher Boessenkool wrote: > On Mon, Jun 15, 2020 at 06:28:39PM +0200, Richard Biener wrote: >> On June 15, 2020 6:05:26 PM GMT+02:00, Segher Boessenkool >> wrote: >> >Of course it is not a fast-forward. I rebase the branches I publish, >> >what is the point of publishing them otherwise? This is so that people >> >can see the stuff that will make its way into master *later*. >> > >> >The number of new commits is nonsense (it is just 13), and the number >> >of >> >emails that triggers should be 0. >> > >> >Please fix? Or, what else is wrong? >> >> The number of commits is. From merges I suppose. > > It is just 13 new commits. It rebased though. There are no merges. What does git rev-list 1db88c6...71e5e35 | wc -l give? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: SSA_NAME_DEF_STMT or print_gimple_stmt for MEM_REF seems mal-functional
On June 15, 2020 6:31:38 PM GMT+02:00, Shuai Wang via Gcc
wrote:
>Hello,
>
>Suppose given the following SSA statement generated by the `sanopt`
>pass:
>
> _17 = (signed char *) _16;
> _18 = *_17;
>
>I am using the following code to identify that _17 depends on _16:
>
>// def_stmt refers to _18 = &_17;
>for (unsigned i = 1; i < gimple_num_ops(def_stmt); i++) {
> op1 = gimple_assign_rhs1(def_stmt);
> if (is_gimple_addressable(op1)) {
> gimple* def_stmt = SSA_NAME_DEF_STMT(op1);
> print_gimple_stmt(stderr, def_stmt, 0, TDF_SLIM); // crash at
>this point
> }
>
>It crashes with the following call stack:
>
>0xb5cd5f crash_signal
>../../gcc-10.1.0/gcc/toplev.c:328
>0x1452134 pp_format(pretty_printer*, text_info*)
>../../gcc-10.1.0/gcc/pretty-print.c:1828
>0x14533e4 pp_printf(pretty_printer*, char const*, ...)
>../../gcc-10.1.0/gcc/pretty-print.c:1773
>0x8dcc81 print_gimple_stmt(_IO_FILE*, gimple*, int, dump_flag)
>../../gcc-10.1.0/gcc/gimple-pretty-print.c:157
>
>I tried hard but just cannot understand why this would crash. Indeed,
>this
>code works pretty well when printing out other dependency statements,
>but
>just gets stuck in front of pointer dereference like _18 = *_17.
>
>Any suggestion would be appreciated. Thank you!
Build your compiler with - - enable-checking and you'll figure you reference
SSA_NAME_DEF_STMT of a NON-SSA_NAME. I suggest you learn to use a debugger.
Richard.
>Best,
>Shuai
Re: Push to my private branches is disallowed
On Mon, Jun 15, 2020 at 06:41:02PM +0200, Andreas Schwab wrote: > On Jun 15 2020, Segher Boessenkool wrote: > > > On Mon, Jun 15, 2020 at 06:28:39PM +0200, Richard Biener wrote: > >> On June 15, 2020 6:05:26 PM GMT+02:00, Segher Boessenkool > >> wrote: > >> >Of course it is not a fast-forward. I rebase the branches I publish, > >> >what is the point of publishing them otherwise? This is so that people > >> >can see the stuff that will make its way into master *later*. > >> > > >> >The number of new commits is nonsense (it is just 13), and the number > >> >of > >> >emails that triggers should be 0. > >> > > >> >Please fix? Or, what else is wrong? > >> > >> The number of commits is. From merges I suppose. > > > > It is just 13 new commits. It rebased though. There are no merges. > > What does git rev-list 1db88c6...71e5e35 | wc -l give? A lot, of course, all on master already (I hadn't rebased this branch for quite a while, it waited for stage 1). (2911 in fact). It should never send email for things that are on master (or any release branch) already. It should never send email for user branches *at all*. User branches are *allowed* to rebase. And that is the only sane development model anyway, IMNSHO. The mail script should just ignore all user branches, and this script shouldn't do these tests for user branches. Segher
Re: SSA_NAME_DEF_STMT or print_gimple_stmt for MEM_REF seems mal-functional
Thank you very much for your prompt response, Rchard. Sorry I was kinda
"learning by doing". I am familiar with LLVM stuff but newbie to GCC
specifications.
Just want to make sure I got it right; _17 and _16 in the IR code are SSA
variables. They are initialized for once and used once. Could you please
shed some light on where "non-ssa name" comes in this scenario, and how
exactly can I get _17 = (signed char *) _16 printed out? Thank you very
much.
Best,
Shuai
On Tue, Jun 16, 2020 at 12:52 AM Richard Biener
wrote:
> On June 15, 2020 6:31:38 PM GMT+02:00, Shuai Wang via Gcc
> wrote:
> >Hello,
> >
> >Suppose given the following SSA statement generated by the `sanopt`
> >pass:
> >
> > _17 = (signed char *) _16;
> > _18 = *_17;
> >
> >I am using the following code to identify that _17 depends on _16:
> >
> >// def_stmt refers to _18 = &_17;
> >for (unsigned i = 1; i < gimple_num_ops(def_stmt); i++) {
> > op1 = gimple_assign_rhs1(def_stmt);
> > if (is_gimple_addressable(op1)) {
> > gimple* def_stmt = SSA_NAME_DEF_STMT(op1);
> > print_gimple_stmt(stderr, def_stmt, 0, TDF_SLIM); // crash at
> >this point
> > }
> >
> >It crashes with the following call stack:
> >
> >0xb5cd5f crash_signal
> >../../gcc-10.1.0/gcc/toplev.c:328
> >0x1452134 pp_format(pretty_printer*, text_info*)
> >../../gcc-10.1.0/gcc/pretty-print.c:1828
> >0x14533e4 pp_printf(pretty_printer*, char const*, ...)
> >../../gcc-10.1.0/gcc/pretty-print.c:1773
> >0x8dcc81 print_gimple_stmt(_IO_FILE*, gimple*, int, dump_flag)
> >../../gcc-10.1.0/gcc/gimple-pretty-print.c:157
> >
> >I tried hard but just cannot understand why this would crash. Indeed,
> >this
> >code works pretty well when printing out other dependency statements,
> >but
> >just gets stuck in front of pointer dereference like _18 = *_17.
> >
> >Any suggestion would be appreciated. Thank you!
>
> Build your compiler with - - enable-checking and you'll figure you
> reference SSA_NAME_DEF_STMT of a NON-SSA_NAME. I suggest you learn to use a
> debugger.
>
> Richard.
>
> >Best,
> >Shuai
>
>
Re: Push to my private branches is disallowed
On Mon, 15 Jun 2020, Segher Boessenkool wrote: > It should never send email for things that are on master (or any release > branch) already. https://github.com/AdaCore/git-hooks/issues/9 https://github.com/AdaCore/git-hooks/pull/12 is marked "Approved". It certainly has fixes for some of the issues reported in the GCC context, but I'm not sure if it includes a fix for that particular one. And once "Approved" has turned into actually present in master, the upstream changes will need merging into the version used by GCC (replacing local changes where the features those implement have been implemented more generally upstream). > It should never send email for user branches *at all*. I think sending email for all branches showing the development taking place there (as opposed to commits that are already in the repository and are just being added to another ref) is entirely appropriate. I don't know if deleting and then recreating a user branch (in separate pushes) avoids the limit (and the excess mails) in the case where a user branch is being rebased, but I expect it should. -- Joseph S. Myers jos...@codesourcery.com
Re: Push to my private branches is disallowed
I think you can work around by deleting the branch before pushing. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Push to my private branches is disallowed
Hi Joseph, Thanks, good to hear things will get better. On Mon, Jun 15, 2020 at 05:19:13PM +, Joseph Myers wrote: > > It should never send email for user branches *at all*. > > I think sending email for all branches showing the development taking > place there (as opposed to commits that are already in the repository and > are just being added to another ref) is entirely appropriate. Not for these branches. All my user branches rebase. All diffs you mail have to be three-way diffs, and even then they won't be super useful (mostly showing conflict resolutions, and the few that are not are patch series refactorings, and much much fewer you finally get the actual patches). This shouldn't be archived at all, either, btw, IMNSHO; another reason why it should not be sent to a mailing list. > I don't know if deleting and then recreating a user branch (in separate > pushes) avoids the limit (and the excess mails) in the case where a user > branch is being rebased, but I expect it should. I suspect that will work fine -- pushing the branch originally didn't cause over a million emails, either. But that is much less convenient and MUCH more error-prone than just allowing all rebases on user branches in the first place -- and in fact it *does* seem to allow that, it's just some "let's send a gazillion emails" script that is misbehaving. Segher
Re: Push to my private branches is disallowed
On Mon, Jun 15, 2020 at 10:43 AM Segher Boessenkool wrote: > > Hi Joseph, > > Thanks, good to hear things will get better. > > On Mon, Jun 15, 2020 at 05:19:13PM +, Joseph Myers wrote: > > > It should never send email for user branches *at all*. > > > > I think sending email for all branches showing the development taking > > place there (as opposed to commits that are already in the repository and > > are just being added to another ref) is entirely appropriate. > > Not for these branches. All my user branches rebase. All diffs you mail > have to be three-way diffs, and even then they won't be super useful > (mostly showing conflict resolutions, and the few that are not are patch > series refactorings, and much much fewer you finally get the actual > patches). > > This shouldn't be archived at all, either, btw, IMNSHO; another reason > why it should not be sent to a mailing list. > > > I don't know if deleting and then recreating a user branch (in separate > > pushes) avoids the limit (and the excess mails) in the case where a user > > branch is being rebased, but I expect it should. > > I suspect that will work fine -- pushing the branch originally didn't > cause over a million emails, either. But that is much less convenient > and MUCH more error-prone than just allowing all rebases on user > branches in the first place -- and in fact it *does* seem to allow that, > it's just some "let's send a gazillion emails" script that is > misbehaving. > These are all the reasons why I don't use GCC repo for my personal branches. -- H.J.
Re: Push to my private branches is disallowed
On Mon, Jun 15, 2020 at 10:47:48AM -0700, H.J. Lu wrote: > These are all the reasons why I don't use GCC repo for my personal > branches. Yeah, but I thought a lot of different GCC people might be interested in my "nuke CC0" patches, so putting it in the official repo seemed like a good idea, for easy access to all interested parties. Oh well, back to my more private repos. Segher
Re: Push to my private branches is disallowed
On Mon, Jun 15, 2020 at 2:13 PM Segher Boessenkool wrote: > > On Mon, Jun 15, 2020 at 10:47:48AM -0700, H.J. Lu wrote: > > These are all the reasons why I don't use GCC repo for my personal > > branches. > > Yeah, but I thought a lot of different GCC people might be interested in > my "nuke CC0" patches, so putting it in the official repo seemed like a > good idea, for easy access to all interested parties. Oh well, back to > my more private repos. There is a difference between providing a service for the use of a wide variety of GCC Developers and providing a service that implements a workflow and automation preferred / desired by a subset of the community. The currently implemented rules and automation are not encouraging personal branches in the GCC repository. - David
Re: Push to my private branches is disallowed
David, The currently implemented rules and automation are not encouraging personal branches in the GCC repository. You are hereby awarded the prize for the understatement of the month.
Re: Push to my private branches is disallowed
On June 15, 2020 7:19:13 PM GMT+02:00, Joseph Myers wrote: >On Mon, 15 Jun 2020, Segher Boessenkool wrote: > >> It should never send email for things that are on master (or any >release >> branch) already. > >https://github.com/AdaCore/git-hooks/issues/9 > >https://github.com/AdaCore/git-hooks/pull/12 is marked "Approved". It >certainly has fixes for some of the issues reported in the GCC context, > >but I'm not sure if it includes a fix for that particular one. And >once >"Approved" has turned into actually present in master, the upstream >changes will need merging into the version used by GCC (replacing local > >changes where the features those implement have been implemented more >generally upstream). > >> It should never send email for user branches *at all*. > >I think sending email for all branches showing the development taking >place there (as opposed to commits that are already in the repository >and >are just being added to another ref) is entirely appropriate. > >I don't know if deleting and then recreating a user branch (in separate > >pushes) avoids the limit (and the excess mails) in the case where a >user >branch is being rebased, but I expect it should. Can you document this (and how to do it) in git.html?
Re: SSA_NAME_DEF_STMT or print_gimple_stmt for MEM_REF seems mal-functional
On June 15, 2020 6:58:27 PM GMT+02:00, Shuai Wang
wrote:
>Thank you very much for your prompt response, Rchard. Sorry I was kinda
>"learning by doing". I am familiar with LLVM stuff but newbie to GCC
>specifications.
>
>Just want to make sure I got it right; _17 and _16 in the IR code are
>SSA
>variables. They are initialized for once and used once. Could you
>please
>shed some light on where "non-ssa name" comes in this scenario, and how
>exactly can I get _17 = (signed char *) _16 printed out? Thank you
>very
>much.
>
>Best,
>Shuai
>
>On Tue, Jun 16, 2020 at 12:52 AM Richard Biener
>
>wrote:
>
>> On June 15, 2020 6:31:38 PM GMT+02:00, Shuai Wang via Gcc
>
>> wrote:
>> >Hello,
>> >
>> >Suppose given the following SSA statement generated by the `sanopt`
>> >pass:
>> >
>> > _17 = (signed char *) _16;
>> > _18 = *_17;
>> >
>> >I am using the following code to identify that _17 depends on _16:
>> >
>> >// def_stmt refers to _18 = &_17;
>> >for (unsigned i = 1; i < gimple_num_ops(def_stmt); i++) {
>> > op1 = gimple_assign_rhs1(def_stmt);
op1 is not an SSA name here.
>> > if (is_gimple_addressable(op1))
That predicate does not make sense on SSA names
{
>> > gimple* def_stmt = SSA_NAME_DEF_STMT(op1);
>> > print_gimple_stmt(stderr, def_stmt, 0, TDF_SLIM); // crash
>at
>> >this point
>> > }
>> >
>> >It crashes with the following call stack:
>> >
>> >0xb5cd5f crash_signal
>> >../../gcc-10.1.0/gcc/toplev.c:328
>> >0x1452134 pp_format(pretty_printer*, text_info*)
>> >../../gcc-10.1.0/gcc/pretty-print.c:1828
>> >0x14533e4 pp_printf(pretty_printer*, char const*, ...)
>> >../../gcc-10.1.0/gcc/pretty-print.c:1773
>> >0x8dcc81 print_gimple_stmt(_IO_FILE*, gimple*, int, dump_flag)
>> >../../gcc-10.1.0/gcc/gimple-pretty-print.c:157
>> >
>> >I tried hard but just cannot understand why this would crash.
>Indeed,
>> >this
>> >code works pretty well when printing out other dependency
>statements,
>> >but
>> >just gets stuck in front of pointer dereference like _18 = *_17.
>> >
>> >Any suggestion would be appreciated. Thank you!
>>
>> Build your compiler with - - enable-checking and you'll figure you
>> reference SSA_NAME_DEF_STMT of a NON-SSA_NAME. I suggest you learn to
>use a
>> debugger.
>>
>> Richard.
>>
>> >Best,
>> >Shuai
>>
>>
Re: Push to my private branches is disallowed
On Mon, Jun 15, 2020 at 09:17:43PM +0200, Richard Biener wrote: > On June 15, 2020 7:19:13 PM GMT+02:00, Joseph Myers > wrote: > >I don't know if deleting and then recreating a user branch (in separate > > > >pushes) avoids the limit (and the excess mails) in the case where a > >user > >branch is being rebased, but I expect it should. > > Can you document this (and how to do it) in git.html? For me it was just $ git push fsf :refs/users/segher/heads/cc0 $ git push fsf cc0:refs/users/segher/heads/cc0 (just like on any other git), but it is probably different if you used the customization stuff. Segher
Re: Push to my private branches is disallowed
On Jun 15 2020, Segher Boessenkool wrote: > $ git push fsf :refs/users/segher/heads/cc0 or git push --delete fsf refs/users/segher/heads/cc0 Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: SSA_NAME_DEF_STMT or print_gimple_stmt for MEM_REF seems mal-functional
Got it. But in that sense, given a `op1` satisfies the
"is_gimple_addressable" predicate (e.g., the _17 in my sample code), how
can I find its def statement? Thank you very much.
Shuai
On Tue, Jun 16, 2020 at 3:19 AM Richard Biener
wrote:
> On June 15, 2020 6:58:27 PM GMT+02:00, Shuai Wang
> wrote:
> >Thank you very much for your prompt response, Rchard. Sorry I was kinda
> >"learning by doing". I am familiar with LLVM stuff but newbie to GCC
> >specifications.
> >
> >Just want to make sure I got it right; _17 and _16 in the IR code are
> >SSA
> >variables. They are initialized for once and used once. Could you
> >please
> >shed some light on where "non-ssa name" comes in this scenario, and how
> >exactly can I get _17 = (signed char *) _16 printed out? Thank you
> >very
> >much.
> >
> >Best,
> >Shuai
> >
> >On Tue, Jun 16, 2020 at 12:52 AM Richard Biener
> >
> >wrote:
> >
> >> On June 15, 2020 6:31:38 PM GMT+02:00, Shuai Wang via Gcc
> >
> >> wrote:
> >> >Hello,
> >> >
> >> >Suppose given the following SSA statement generated by the `sanopt`
> >> >pass:
> >> >
> >> > _17 = (signed char *) _16;
> >> > _18 = *_17;
> >> >
> >> >I am using the following code to identify that _17 depends on _16:
> >> >
> >> >// def_stmt refers to _18 = &_17;
> >> >for (unsigned i = 1; i < gimple_num_ops(def_stmt); i++) {
> >> > op1 = gimple_assign_rhs1(def_stmt);
>
> op1 is not an SSA name here.
>
> >> > if (is_gimple_addressable(op1))
>
> That predicate does not make sense on SSA names
>
> {
> >> > gimple* def_stmt = SSA_NAME_DEF_STMT(op1);
> >> > print_gimple_stmt(stderr, def_stmt, 0, TDF_SLIM); // crash
> >at
> >> >this point
> >> > }
> >> >
> >> >It crashes with the following call stack:
> >> >
> >> >0xb5cd5f crash_signal
> >> >../../gcc-10.1.0/gcc/toplev.c:328
> >> >0x1452134 pp_format(pretty_printer*, text_info*)
> >> >../../gcc-10.1.0/gcc/pretty-print.c:1828
> >> >0x14533e4 pp_printf(pretty_printer*, char const*, ...)
> >> >../../gcc-10.1.0/gcc/pretty-print.c:1773
> >> >0x8dcc81 print_gimple_stmt(_IO_FILE*, gimple*, int, dump_flag)
> >> >../../gcc-10.1.0/gcc/gimple-pretty-print.c:157
> >> >
> >> >I tried hard but just cannot understand why this would crash.
> >Indeed,
> >> >this
> >> >code works pretty well when printing out other dependency
> >statements,
> >> >but
> >> >just gets stuck in front of pointer dereference like _18 = *_17.
> >> >
> >> >Any suggestion would be appreciated. Thank you!
> >>
> >> Build your compiler with - - enable-checking and you'll figure you
> >> reference SSA_NAME_DEF_STMT of a NON-SSA_NAME. I suggest you learn to
> >use a
> >> debugger.
> >>
> >> Richard.
> >>
> >> >Best,
> >> >Shuai
> >>
> >>
>
>
Re: SSA_NAME_DEF_STMT or print_gimple_stmt for MEM_REF seems mal-functional
Yes, TREE_CODE (op1) != SSA_NAME shows that op1 is by no means SSA names
(although I don't know why). But how can I backwardly identify its
initialization statement _17 = (signed char *) _16? Thanks!
Shuai
On Tue, Jun 16, 2020 at 10:32 AM Shuai Wang wrote:
> Got it. But in that sense, given a `op1` satisfies the
> "is_gimple_addressable" predicate (e.g., the _17 in my sample code), how
> can I find its def statement? Thank you very much.
>
> Shuai
>
> On Tue, Jun 16, 2020 at 3:19 AM Richard Biener
> wrote:
>
>> On June 15, 2020 6:58:27 PM GMT+02:00, Shuai Wang
>> wrote:
>> >Thank you very much for your prompt response, Rchard. Sorry I was kinda
>> >"learning by doing". I am familiar with LLVM stuff but newbie to GCC
>> >specifications.
>> >
>> >Just want to make sure I got it right; _17 and _16 in the IR code are
>> >SSA
>> >variables. They are initialized for once and used once. Could you
>> >please
>> >shed some light on where "non-ssa name" comes in this scenario, and how
>> >exactly can I get _17 = (signed char *) _16 printed out? Thank you
>> >very
>> >much.
>> >
>> >Best,
>> >Shuai
>> >
>> >On Tue, Jun 16, 2020 at 12:52 AM Richard Biener
>> >
>> >wrote:
>> >
>> >> On June 15, 2020 6:31:38 PM GMT+02:00, Shuai Wang via Gcc
>> >
>> >> wrote:
>> >> >Hello,
>> >> >
>> >> >Suppose given the following SSA statement generated by the `sanopt`
>> >> >pass:
>> >> >
>> >> > _17 = (signed char *) _16;
>> >> > _18 = *_17;
>> >> >
>> >> >I am using the following code to identify that _17 depends on _16:
>> >> >
>> >> >// def_stmt refers to _18 = &_17;
>> >> >for (unsigned i = 1; i < gimple_num_ops(def_stmt); i++) {
>> >> > op1 = gimple_assign_rhs1(def_stmt);
>>
>> op1 is not an SSA name here.
>>
>> >> > if (is_gimple_addressable(op1))
>>
>> That predicate does not make sense on SSA names
>>
>> {
>> >> > gimple* def_stmt = SSA_NAME_DEF_STMT(op1);
>> >> > print_gimple_stmt(stderr, def_stmt, 0, TDF_SLIM); // crash
>> >at
>> >> >this point
>> >> > }
>> >> >
>> >> >It crashes with the following call stack:
>> >> >
>> >> >0xb5cd5f crash_signal
>> >> >../../gcc-10.1.0/gcc/toplev.c:328
>> >> >0x1452134 pp_format(pretty_printer*, text_info*)
>> >> >../../gcc-10.1.0/gcc/pretty-print.c:1828
>> >> >0x14533e4 pp_printf(pretty_printer*, char const*, ...)
>> >> >../../gcc-10.1.0/gcc/pretty-print.c:1773
>> >> >0x8dcc81 print_gimple_stmt(_IO_FILE*, gimple*, int, dump_flag)
>> >> >../../gcc-10.1.0/gcc/gimple-pretty-print.c:157
>> >> >
>> >> >I tried hard but just cannot understand why this would crash.
>> >Indeed,
>> >> >this
>> >> >code works pretty well when printing out other dependency
>> >statements,
>> >> >but
>> >> >just gets stuck in front of pointer dereference like _18 = *_17.
>> >> >
>> >> >Any suggestion would be appreciated. Thank you!
>> >>
>> >> Build your compiler with - - enable-checking and you'll figure you
>> >> reference SSA_NAME_DEF_STMT of a NON-SSA_NAME. I suggest you learn to
>> >use a
>> >> debugger.
>> >>
>> >> Richard.
>> >>
>> >> >Best,
>> >> >Shuai
>> >>
>> >>
>>
>>
