gcc-8-20170521 is now available
Snapshot gcc-8-20170521 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/8-20170521/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 248313 You'll find: gcc-8-20170521.tar.bz2 Complete GCC SHA256=d60f3e4e3a3327718bbe82a3b0e1bcb7a724239e4c2f628f124392914da4cb2b SHA1=9030968f6351422035b026ac240022c3a6df64db Diffs from 8-20170514 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: git-svn error due to out-of-sync changes?
On 05/19/2017 03:46 PM, Jason Merrill wrote: On Thu, May 18, 2017 at 3:42 PM, 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. Yes, the git mirror can lag the SVN repo by a few minutes, that's why you need to 'git svn rebase' to pull directly from SVN before a commit. Ah, so that's so the magic spell! Thanks for explaining it. I've been using 'git pull' and it didn't occur to me that I should be using 'git svn rebase' instead to get the most up-to-date sources. It would be worth to highlight this bit more prominently on the Wiki. Martin
Re: Duplicating loops and virtual phis
Hi Bin and Steve,
On 17 May 2017 at 19:41, Bin.Cheng wrote:
> On Mon, May 15, 2017 at 7:32 PM, Richard Biener
> wrote:
>> On May 15, 2017 6:56:53 PM GMT+02:00, Steve Ellcey
>> wrote:
>>>On Sat, 2017-05-13 at 08:18 +0200, Richard Biener wrote:
On May 12, 2017 10:42:34 PM GMT+02:00, Steve Ellcey >>> om> wrote:
>
> (Short version of this email, is there a way to recalculate/rebuild
> virtual
> phi nodes after modifying the CFG.)
>
> I have a question about duplicating loops and virtual phi nodes.
> I am trying to implement the following optimization as a pass:
>
> Transform:
>
> for (i = 0; i < n; i++) {
>A[i] = A[i] + B[i];
>C[i] = C[i-1] + D[i];
> }
>
> Into:
>
> if (noalias between A&B, A&C, A&D)
>for (i = 0; i < 100; i++)
>A[i] = A[i] + B[i];
>for (i = 0; i < 100; i++)
>C[i] = C[i-1] + D[i];
> else
>for (i = 0; i < 100; i++) {
>A[i] = A[i] + B[i];
>C[i] = C[i-1] + D[i];
>}
>
> Right now the vectorizer sees that 'C[i] = C[i-1] + D[i];' cannot
>>>be
> vectorized so it gives up and does not vectorize the loop. If we
>>>split
> up the loop into two loops then the vector add with A[i] could be
> vectorized
> even if the one with C[i] could not.
Loop distribution does this transform but it doesn't know about
versioning for unknown dependences.
>>>
>>>Yes, I looked at loop distribution. But it only works with global
>>>arrays and not with pointer arguments where it doesn't know the size of
>>>the array being pointed at. I would like to be able to have it work
>>>with pointer arguments. If I call a function with 2 or
>>>more integer pointers, and I have a loop that accesses them with
>>>offsets between 0 and N where N is loop invariant then I should have
>>>enough information (at runtime) to determine if there are overlapping
>>>memory accesses through the pointers and determine whether or not I can
>>>distribute the loop.
>>
>> Not sure where you got that from. Loop distribution works with our data
>> reference / dependence analysis. The cost model might be more restricted
>> but that can be fixed.
>>
>>>The loop splitting code seemed like a better template since it already
>>>knows how to split a loop based on a runtime determined condition. That
>>>part seems to be working for me, it is when I try to
>>>distribute/duplicate one of those loops (under the unaliased condition)
>>>that I am running into the problem with virtual PHIs.
>>
>> There's mark_virtual*for_renaming (sp?).
>>
>> But as said you are performing loop distribution so please enhance the
>> existing pass rather than writing a new one.
> I happen to be working on loop distribution now (If guess correctly,
> to get hmmer fixed). So far my idea is to fuse the finest distributed
> loop in two passes, in the first pass, we merge all SCCs due to "true"
> data dependence; in the second one we identify all SCCs and breaks
> them on dependent edges due to possible alias. Breaking SCCs with
> minimal edge set can be modeled as Feedback arc set problem which is
> NP-hard. Fortunately the problem is small in our case and there are
> approximation algorithms. OTOH, we should also improve loop
> distribution/fusion to maximize parallelism / minimize
> synchronization, as well as maximize data locality, but I think this
> is not needed to get hmmer vectorized.
I am also looking into vectoring homer loop. Glad to know you are also
looking at this problem and looking forward to seeing the patches.
I have some experimental patches where I added the data reference that
needs runtime checking to a list
static int
pg_add_dependence_edges (struct graph *rdg, vec loops, int dir,
vec drs1,
- vec drs2)
+ vec drs2,
+ vec &ddrs,
+ bool runtime_alias_check)
Then I am vesioning the main loop based on the condition generated
from the runtime check. I have borrowed the logic from vectorizer
(like pruning the list and generating the condition). I have neither
verified nor benchmarked it enough yet.
As I understand, we also should have some form of cost model where we
should be able too see the data access patterns and decide if the
distributed loops can be vectorized?
Cost model in similar_memory_accesses also need to be relaxd based on
the ability to vectorize distributed loops.
Thanks,
Kugan
> Thanks,
> bin
>>
>> Richard.
>>
>>>Steve Ellcey
>>>sell...@cavium.com
>>
Re: git-svn error due to out-of-sync changes?
On Sun, May 21, 2017 at 7:34 PM, Martin Sebor wrote: > On 05/19/2017 03:46 PM, Jason Merrill wrote: >> >> On Thu, May 18, 2017 at 3:42 PM, 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. >> >> >> Yes, the git mirror can lag the SVN repo by a few minutes, that's why >> you need to 'git svn rebase' to pull directly from SVN before a >> commit. > > > Ah, so that's so the magic spell! Thanks for explaining it. I've > been using 'git pull' and it didn't occur to me that I should be > using 'git svn rebase' instead to get the most up-to-date sources. > It would be worth to highlight this bit more prominently on the > Wiki. Done, thanks for the suggestion. Jason
