Question about comment in vect_prune_runtime_alias_test_list
Hi, In that function, we have below comments: /* Basically, for each pair of dependent data refs store_ptr_0 and load_ptr_0, we create an expression: ((store_ptr_0 + store_segment_length_0) <= load_ptr_0) || (load_ptr_0 + load_segment_length_0) <= store_ptr_0)) for aliasing checks. However, in some cases we can decrease the number of checks by combining two checks into one. For example, suppose we have another pair of data refs store_ptr_0 and load_ptr_1, and if the following condition is satisfied: load_ptr_0 < load_ptr_1 && load_ptr_1 - load_ptr_0 - load_segment_length_0 < store_segment_length_0 (this condition means, in each iteration of vectorized loop, the accessed memory of store_ptr_0 cannot be between the memory of load_ptr_0 and load_ptr_1.) we then can use only the following expression to finish the alising checks between store_ptr_0 & load_ptr_0 and store_ptr_0 & load_ptr_1: ((store_ptr_0 + store_segment_length_0) <= load_ptr_0) || (load_ptr_1 + load_segment_length_1 <= store_ptr_0)) Note that we only consider that load_ptr_0 and load_ptr_1 have the same basic address. */ I don't quite follow the example. If (load_ptr_0 < load_ptr_1) is true, IIUC store_ptr_0 & load_ptr_0 and store_ptr_0 & load_ptr_1 can be simplified to: ((store_ptr_0 + store_segment_length_0) <= load_ptr_0) || (load_ptr_1 + load_segment_length_1 <= store_ptr_0)) under conditions: load_ptr_0 + load_segment_length_0 < load_ptr_1 + load_segment_length_1 But I can't get this from: load_ptr_0 < load_ptr_1 && load_ptr_1 - load_ptr_0 - load_segment_length_0 < store_segment_length_0 Also it looks like the comment doesn't match code either. The code merges checks for store_ptr_0 & load_ptr_0 and store_ptr_0 & load_ptr_1, but the comment is more like mixed checks between the two pairs. Thanks, bin
Re: Help with rich_location and GIMPLE stmts
On 05/16/2017 09:14 PM, David Malcolm wrote:
> On Mon, 2017-05-15 at 15:36 +0200, Martin Liška wrote:
>> Hi.
>>
>> I sent this email to David some time ago, but it should be probably
>> answered
>> on gcc mailing list.
>
>> I have idea one to improve gcov tool and I'm interested in more
>> precise locations for gimple
>> statements. For gcov purpose, we dump location in ipa-profile pass,
>> which is an early IPA
>> pass and this data is used by gcov tool to map statements (blocks) to
>> lines of code.
>>
>> I did a small experiment on the place we emit the location data:
>>inform (gimple_location (stmt), "output_location");
>>
>> and it shows for:
>> $ cat m2.c
>> unsigned int
>> UuT (void)
>> { unsigned int true_var = 1; unsigned int false_var = 0; unsigned int
>> ret = 0; if (true_var) /* count(1) */ { if (false_var) /* count(1) */
>> ret = 111; /* count(#) */ } else ret = 999; /* count(#) */
>> return ret; }
>>
>> int
>> main (int argc, char **argv)
>> {
>> UuT ();
>> return 0;
>> }
>>
>> $ gcc --coverage m2.c
>> m2.c: In function ‘main’:
>> m2.c:8:3: note: output_location
>>UuT ();
>>^~
>> # .MEM_2 = VDEF <.MEM_1(D)>
>> UuT ();
>> m2.c:9:10: note: output_location
>>return 0;
>> ^
>> _3 = 0;
>> m2.c: In function ‘UuT’:
>> m2.c:3:16: note: output_location
>> { unsigned int true_var = 1; unsigned int false_var = 0; unsigned
>> int ret = 0; if (true_var) /* count(1) */ { if (false_var) /*
>> count(1) */ ret = 111; /* count(#) */ } else ret = 999; /*
>> count(#) */ return ret; }
>> ^~~~
>> true_var_3 = 1;
>> m2.c:3:43: note: output_location
>> { unsigned int true_var = 1; unsigned int false_var = 0; unsigned
>> int ret = 0; if (true_var) /* count(1) */ { if (false_var) /*
>> count(1) */ ret = 111; /* count(#) */ } else ret = 999; /*
>> count(#) */ return ret; }
>>^
>> false_var_4 = 0;
>> m2.c:3:71: note: output_location
>> { unsigned int true_var = 1; unsigned int false_var = 0; unsigned
>> int ret = 0; if (true_var) /* count(1) */ { if (false_var) /*
>> count(1) */ ret = 111; /* count(#) */ } else ret = 999; /*
>> count(#) */ return ret; }
>>
>> ^~~
>> ret_5 = 0;
>> m2.c:3:83: note: output_location
>> { unsigned int true_var = 1; unsigned int false_var = 0; unsigned
>> int ret = 0; if (true_var) /* count(1) */ { if (false_var) /*
>> count(1) */ ret = 111; /* count(#) */ } else ret = 999; /*
>> count(#) */ return ret; }
>>
>> ^
>> if (true_var_3 != 0)
>> m2.c:3:114: note: output_location
>> { unsigned int true_var = 1; unsigned int false_var = 0; unsigned
>> int ret = 0; if (true_var) /* count(1) */ { if (false_var) /*
>> count(1) */ ret = 111; /* count(#) */ } else ret = 999; /*
>> count(#) */ return ret; }
>>
>> ^
>> if (false_var_4 != 0)
>> m2.c:3:145: note: output_location
>> { unsigned int true_var = 1; unsigned int false_var = 0; unsigned
>> int ret = 0; if (true_var) /* count(1) */ { if (false_var) /*
>> count(1) */ ret = 111; /* count(#) */ } else ret = 999; /*
>> count(#) */ return ret; }
>>
>>
>>^
>> ret_7 = 111;
>> m2.c:3:182: note: output_location
>> { unsigned int true_var = 1; unsigned int false_var = 0; unsigned
>> int ret = 0; if (true_var) /* count(1) */ { if (false_var) /*
>> count(1) */ ret = 111; /* count(#) */ } else ret = 999; /*
>> count(#) */ return ret; }
>>
>>
>> ^
>> ret_6 = 999;
>> m2.c:3:215: note: output_location
>> { unsigned int true_var = 1; unsigned int false_var = 0; unsigned
>> int ret = 0; if (true_var) /* count(1) */ { if (false_var) /*
>> count(1) */ ret = 111; /* count(#) */ } else ret = 999; /*
>> count(#) */ return ret; }
>>
>>
>>
>> ^~~
>> _8 = ret_2;
>> m2.c:3:215: note: output_location
>> # VUSE <.MEM_9(D)>
>> return _8;
>>
>> Which is not optimal, for some assignments I see just LHS
>> (false_var_4 = 0),
>
> My first though was: are there assignments for which this isn't the
> case? The only one I see is the:
> ret = 999;
> ^
>
> Are the locations for these assignments coming through from the
> frontend?
Hi.
Actually not all, the defaul
Separate preprocess and compile: some performance numbers
Hi, I have implemented the separate preprocess and compile setup in build2. For GCC it is using -fdirectives-only (thanks to everyone's suggestions in the earlier thread). I've also done some benchmarking: https://build2.org/article/preprocess-compile-performance.xhtml TL;DR for GCC: Surprisingly, a separate preprocessor run is about 1% faster (probably because of the time-localization of filesystem access). Overall, a preprocessor run costs about 5% of a non-optimized C++ build. Boris
git-svn error due to out-of-sync changes?
I just tried to push a change and got the error below. git pull says my tree is up to date. I wonder if it's caused by my commit conflicting with another commit (in this case r248244) that git-svn doesn't see because it lags behind SVN. I brushed this (and other strange errors) off before, not bothering to try to understand it but it's happened enough times that I'd like to bring it up. I expect some (maybe even most) of these issues would not exist if we were using Git directly rather than the git-svn wrapper. Has any more progress been made on the Git integration project? Is there something I/we can do to help get it done? Thanks Martin ERROR from SVN: Transaction is out of date: File '/trunk/gcc/ChangeLog' is out of date W: 4a11229537e1323e4a738726de15f84b03b2eff8 and refs/remotes/svn/trunk differ, using rebase: :04 04 2fc7cb858d283680126b2f3926c164f66dddcce1 6181e5c83e49b93614e01ef41ff8c73b71a79784 M gcc Current branch master is up to date. ERROR: Not all changes have been committed into SVN, however the committed ones (if any) seem to be successfully integrated into the working tree. Please see the above messages for details.
Re: git-svn error due to out-of-sync changes?
On 05/18/2017 11:41 AM, Martin Sebor wrote: > I just tried to push a change and got the error below. git > pull says my tree is up to date. I wonder if it's caused by > my commit conflicting with another commit (in this case > r248244) that git-svn doesn't see because it lags behind SVN. > I brushed this (and other strange errors) off before, not > bothering to try to understand it but it's happened enough > times that I'd like to bring it up. I expect some (maybe > even most) of these issues would not exist if we were using > Git directly rather than the git-svn wrapper. Has any more > progress been made on the Git integration project? Is there > something I/we can do to help get it done? That just means something changed upstream betwen your last git svn rebase and your local commit. Just "git svn rebase", resolve conflicts (the ChangeLogs are the most common source of conflicts) and you should be good to go. jeff
Re: git-svn error due to out-of-sync changes?
On 05/18/2017 11:59 AM, Jeff Law wrote: On 05/18/2017 11:41 AM, Martin Sebor wrote: I just tried to push a change and got the error below. git pull says my tree is up to date. I wonder if it's caused by my commit conflicting with another commit (in this case r248244) that git-svn doesn't see because it lags behind SVN. I brushed this (and other strange errors) off before, not bothering to try to understand it but it's happened enough times that I'd like to bring it up. I expect some (maybe even most) of these issues would not exist if we were using Git directly rather than the git-svn wrapper. Has any more progress been made on the Git integration project? Is there something I/we can do to help get it done? That just means something changed upstream betwen your last git svn rebase and your local commit. Just "git svn rebase", resolve conflicts (the ChangeLogs are the most common source of conflicts) and you should be good to go. The main issue is that there tend to be errors that wouldn't happen without the extra layer between Git and SVN. The two are out of sync by minutes (I don't know exactly how many but it seems like at least 10), so clearing these things up takes time. Some (I'd say most) of the errors I've seen out of Git-svn are also not completely intuitive so it's not always clear what or where the problem is. So I'd like to see if there's something that can be done to move the migration forward. Martin
Re: git-svn error due to out-of-sync changes?
On Thu, May 18, 2017 at 2:41 PM, Martin Sebor wrote: > On 05/18/2017 11:59 AM, Jeff Law wrote: >> >> On 05/18/2017 11:41 AM, Martin Sebor wrote: >>> >>> I just tried to push a change and got the error below. git >>> pull says my tree is up to date. I wonder if it's caused by >>> my commit conflicting with another commit (in this case >>> r248244) that git-svn doesn't see because it lags behind SVN. >>> I brushed this (and other strange errors) off before, not >>> bothering to try to understand it but it's happened enough >>> times that I'd like to bring it up. I expect some (maybe >>> even most) of these issues would not exist if we were using >>> Git directly rather than the git-svn wrapper. Has any more >>> progress been made on the Git integration project? Is there >>> something I/we can do to help get it done? >> >> That just means something changed upstream betwen your last git svn >> rebase and your local commit. >> >> Just "git svn rebase", resolve conflicts (the ChangeLogs are the most >> common source of conflicts) and you should be good to go. > > > The main issue is that there tend to be errors that wouldn't > happen without the extra layer between Git and SVN. The two > are out of sync by minutes (I don't know exactly how many but > it seems like at least 10), so clearing these things up takes > time. Some (I'd say most) of the errors I've seen out of > Git-svn are also not completely intuitive so it's not always > clear what or where the problem is. > > So I'd like to see if there's something that can be done to > move the migration forward. I have been in contact with ESR. He wants to fix the bugs in repo surgeon and complete the migration as well. He is having difficulty carving out the necessary dedicated time to complete the work. - David
Re: git-svn error due to out-of-sync changes?
On 2017.05.18 at 12:41 -0600, Martin Sebor wrote: > On 05/18/2017 11:59 AM, Jeff Law wrote: > > On 05/18/2017 11:41 AM, Martin Sebor wrote: > > > I just tried to push a change and got the error below. git > > > pull says my tree is up to date. I wonder if it's caused by > > > my commit conflicting with another commit (in this case > > > r248244) that git-svn doesn't see because it lags behind SVN. > > > I brushed this (and other strange errors) off before, not > > > bothering to try to understand it but it's happened enough > > > times that I'd like to bring it up. I expect some (maybe > > > even most) of these issues would not exist if we were using > > > Git directly rather than the git-svn wrapper. Has any more > > > progress been made on the Git integration project? Is there > > > something I/we can do to help get it done? > > That just means something changed upstream betwen your last git svn > > rebase and your local commit. > > > > Just "git svn rebase", resolve conflicts (the ChangeLogs are the most > > common source of conflicts) and you should be good to go. > > The main issue is that there tend to be errors that wouldn't > happen without the extra layer between Git and SVN. The two > are out of sync by minutes (I don't know exactly how many but > it seems like at least 10), so clearing these things up takes > time. Some (I'd say most) of the errors I've seen out of > Git-svn are also not completely intuitive so it's not always > clear what or where the problem is. > > So I'd like to see if there's something that can be done to > move the migration forward. The same issue also happen with git when several people push at the same time. -- Markus
Re: git-svn error due to out-of-sync changes?
On 05/18/2017 12:55 PM, Markus Trippelsdorf wrote: On 2017.05.18 at 12:41 -0600, Martin Sebor wrote: On 05/18/2017 11:59 AM, Jeff Law wrote: On 05/18/2017 11:41 AM, Martin Sebor wrote: I just tried to push a change and got the error below. git pull says my tree is up to date. I wonder if it's caused by my commit conflicting with another commit (in this case r248244) that git-svn doesn't see because it lags behind SVN. I brushed this (and other strange errors) off before, not bothering to try to understand it but it's happened enough times that I'd like to bring it up. I expect some (maybe even most) of these issues would not exist if we were using Git directly rather than the git-svn wrapper. Has any more progress been made on the Git integration project? Is there something I/we can do to help get it done? That just means something changed upstream betwen your last git svn rebase and your local commit. Just "git svn rebase", resolve conflicts (the ChangeLogs are the most common source of conflicts) and you should be good to go. The main issue is that there tend to be errors that wouldn't happen without the extra layer between Git and SVN. The two are out of sync by minutes (I don't know exactly how many but it seems like at least 10), so clearing these things up takes time. Some (I'd say most) of the errors I've seen out of Git-svn are also not completely intuitive so it's not always clear what or where the problem is. So I'd like to see if there's something that can be done to move the migration forward. The same issue also happen with git when several people push at the same time. Yes, it can. The major difference, I suspect, is due to Git-svn asynchronous, delayed updates. My guess is that Git-svn pull requests are based on updates from SVN that happen only every few minutes, but pushes happen in real time. So when we pull, we're likely to get outdated sources (changes committed since the last Git update are not included). But when we push, we're likely to run into (at a minimum) ChangeLog conflicts with those already committed changes that Git-svn hasn't been updated with. This is just a wild guess based on the errors I've seen and their increased incidence since 7 has been released. Martin
Re: git-svn error due to out-of-sync changes?
On 2017.05.18 at 13:42 -0600, Martin Sebor wrote: > On 05/18/2017 12:55 PM, Markus Trippelsdorf wrote: > > On 2017.05.18 at 12:41 -0600, Martin Sebor wrote: > > > On 05/18/2017 11:59 AM, Jeff Law wrote: > > > > On 05/18/2017 11:41 AM, Martin Sebor wrote: > > > > > I just tried to push a change and got the error below. git > > > > > pull says my tree is up to date. I wonder if it's caused by > > > > > my commit conflicting with another commit (in this case > > > > > r248244) that git-svn doesn't see because it lags behind SVN. > > > > > I brushed this (and other strange errors) off before, not > > > > > bothering to try to understand it but it's happened enough > > > > > times that I'd like to bring it up. I expect some (maybe > > > > > even most) of these issues would not exist if we were using > > > > > Git directly rather than the git-svn wrapper. Has any more > > > > > progress been made on the Git integration project? Is there > > > > > something I/we can do to help get it done? > > > > That just means something changed upstream betwen your last git svn > > > > rebase and your local commit. > > > > > > > > Just "git svn rebase", resolve conflicts (the ChangeLogs are the most > > > > common source of conflicts) and you should be good to go. > > > > > > The main issue is that there tend to be errors that wouldn't > > > happen without the extra layer between Git and SVN. The two > > > are out of sync by minutes (I don't know exactly how many but > > > it seems like at least 10), so clearing these things up takes > > > time. Some (I'd say most) of the errors I've seen out of > > > Git-svn are also not completely intuitive so it's not always > > > clear what or where the problem is. > > > > > > So I'd like to see if there's something that can be done to > > > move the migration forward. > > > > The same issue also happen with git when several people push at the same > > time. > > Yes, it can. The major difference, I suspect, is due to Git-svn > asynchronous, delayed updates. My guess is that Git-svn pull > requests are based on updates from SVN that happen only every > few minutes, but pushes happen in real time. So when we pull, > we're likely to get outdated sources (changes committed since > the last Git update are not included). But when we push, we're > likely to run into (at a minimum) ChangeLog conflicts with those > already committed changes that Git-svn hasn't been updated with. > This is just a wild guess based on the errors I've seen and > their increased incidence since 7 has been released. "git svn dcommit" will run "git svn rebase" automatically, so you are already on the latest svn revision. It doesn't matter if git lags behind or not, only svn counts here. The situation will be exactly the same after the switch to git. If you are unlucky and several people push at the same time, you could be forced to pull/rebase and retry your push request several times. -- Markus
gcc-7-20170518 is now available
Snapshot gcc-7-20170518 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20170518/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 248254 You'll find: gcc-7-20170518.tar.bz2 Complete GCC SHA256=9b23c9fac27ae58a6316eb851a33e58e0191060a8b9dae8ad71edf26b5a1a18d SHA1=304de0dde668d9c067b6acbc55ef73b077dd8ebd Diffs from 7-20170511 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 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.
Re: comparing parallel test runs
On 05/17/2017 11:19 PM, Andi Kleen wrote: Marek Polacek writes: On Wed, May 17, 2017 at 09:13:40AM -0600, Jeff Law wrote: On 05/17/2017 04:23 AM, Aldy Hernandez wrote: Hi folks. I've been having troubles comparing the results of different test runs for quite some time, and have finally decided to whine about it. Perhaps someone can point out to whatever I may be doing wrong. I generally do "make check -k -j60" on two different trees and compare Make sure you've got Andi's patch installed and report back. It's supposed to help with smaller -j loads, but it's unclear if it's enough to address the problems with higher loads like you're using. I'm still seeing spurious tree-prof failures there (with -j48). Do they go away if you run first (as root) echo 5000 > /proc/sys/kernel/perf_event_mlock_kb first? I tried three runs of the profiling tests and the failures did clear up with the increased setting. Martin
Re: comparing parallel test runs
On Thu, May 18, 2017 at 05:22:50PM -0600, Martin Sebor wrote: > On 05/17/2017 11:19 PM, Andi Kleen wrote: > > Marek Polacek writes: > > > > > On Wed, May 17, 2017 at 09:13:40AM -0600, Jeff Law wrote: > > > > On 05/17/2017 04:23 AM, Aldy Hernandez wrote: > > > > > Hi folks. > > > > > > > > > > I've been having troubles comparing the results of different test runs > > > > > for quite some time, and have finally decided to whine about it. > > > > > Perhaps > > > > > someone can point out to whatever I may be doing wrong. > > > > > > > > > > I generally do "make check -k -j60" on two different trees and compare > > > > Make sure you've got Andi's patch installed and report back. It's > > > > supposed to help with smaller -j loads, but it's unclear if it's enough > > > > to address the problems with higher loads like you're using. > > > > > > I'm still seeing spurious tree-prof failures there (with -j48). > > > > Do they go away if you run first (as root) > > > > echo 5000 > /proc/sys/kernel/perf_event_mlock_kb > > > > first? > > I tried three runs of the profiling tests and the failures did > clear up with the increased setting. I tried setting that but I still saw a very small number of tree-prof failures, at least in one of the runs. But it did help - thanks. Marek
