PT Carbide / Tungsten carbide wear parts for oilfield/ Factory
Dear customer, Many thanks for your time to reading this email ! We are producer of tungsten carbide wear parts for oil & gas industry for 16 years in Chengdu , China! We supply : Carbide balls and seats Carbide wear sleeves , carbide bottom sleeves Carbide tube for choke beans , choke valve seat Carbide tip for choke valve stem Carbide thread nozzles for drill bits Carbide teeth for drill bits , mining tools Assembled choke stem , Assembled choke seat , Assembled choke beans (TC+410SS /4130 /4140/316SS) Delivery time : 15-20 days for blanks , 25-30 days for finished We can provide customized solution for you if you could inform us your detailed requirements ! We will give you a quick reply if you have any questions or doubts about our products or company ! Thanks for your attentions and look forward to your further talking ! Ling Shen Best regards Mechanical seal ring , bushing and sleeves ,choke stem and seat ,ball and seat ,choke beans ,choke valve and seat, sandblasting nozzles , carbide blades , carbide tiles for centrifuges etc. ISO9001:2015 Sichuan Precision Carbide Tech Co.,Ltd Xiaonan Village ,Xiaohan Town , Guanghan City , Sichuan , China , 618300 Web: www.pt-carbide.com Tel: 86-0838-5288652 Fax: 86-0838-5288635 Cell : 86-13551106919
Re: PPC64 libmvec implementation of sincos
On Thu, Jan 16, 2020 at 4:54 PM GT wrote:
>
>
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, January 15, 2020 3:20 PM, GT wrote:
>
> > ‐‐‐ Original Message ‐‐‐
> > On Thursday, January 9, 2020 8:42 AM, Richard Biener
> > richard.guent...@gmail.com wrote:
> >
> > > As for the other question for testing you probably want to provide a
> > > OMP simd declaration
> > > of a function like
> > > _Complex double mycexpi (double);
> > > and make a testcase like
> > > void foo (_Complex double * __restrict out, double *in)
> > > {
> > > for (int i = 0; i < 1024; ++i)
> > > {
> > > out[i] = mycexpi (in[i]);
> > > }
> > > }
> > > or eventually with two output arrays and explicit __real/__imag
> > > processing. The real
> > > and main question is how is the OMP SIMD declaration of mycexpi looking
> > > like?
> > > So I'd completely side-step sincos() and GCCs sincos() ->
> > > __builtin_cepxi transform
> > > and concentrate on OMP SIMD of a function with the signature we need to
> > > handle.
> > > Richard.
> >
> > I think what is required here is to attach either #pragma omp declare simd
> > orattribute ((simd))
> > to the declaration of builtin cexpi. In gcc/builtins.def, some attributes
> > are provided during
> > creation of cexpi (line 656, call containing BUILT_IN_CEXPI). Attaching the
> > simd attributes to
> > function declarations is how sin, cos, and the other math functions were
> > handled in math-vector.h
> > glibc header file.
>
> You probably intended that we first teach GCC how to vectorize any function
> which returns a
> _Complex double and has a single parameter of type double. When that's done,
> move on to solving
> the specific vectorization of __builtin_cexpi. Right?
Yes.
Richard.
> Bert.
Re: gcc-cvs mails for personal/vendor branches for merge commits
> I think it's desirable for development that *happens on* the personal and > vendor branches to be visible in gcc-cvs - that is different from things > getting merged into them. > > Likewise for the refs/heads/devel/* development branches - > non-fast-forward pushes are not permitted there, but such branches can > expect to have lots of merges from master, and it's the actual development > taking place *on* the branches - the new commits - that is of interest to > see on gcc-cvs, not the merging of existing commits. Would it be sufficient to say that some branches would only trigger a summary email, but not individual commit emails? The downside is that you would not be getting the "diff" for commits that are really completely new. But on the other hand, it would fit better with the fact that user branches could have frequent re-basing, thus causing the same commit email being sent over and over at each rebase operation. It would also answer the issue of the number of emails being sent when people are doing a merge which brings in more commits than the max-emails number. -- Joel
Re: Whitespace at the start of first line of commit
> Unfortunately, that's not as simple to implement as I'd hoped, because > git.py:git_run removes all leading and trailing whitespace from the output > of the git command it runs, so the code checking commit messages can't > tell whether there was whitespace at the start of the first line (or the > end of the last line, I suppose) at all. I don't know what git commands > the hooks are using that might depend on removing leading whitespace (no > doubt the removal of trailing whitespace is needed in various places to > remove a final newline output by commands giving single-line output). A quick run of the testsuite reveals that this assumption is made all over. I am opposed to having this feature be a standard feature of the git-hooks, so you wouldn't have to add an ad hoc check. The way I would do it is by enhancing the git_run function to check for a parameter named "_no_strip" and block the strip() operation when passed as True. You can then implement your check using the usual git interface, with the extra "_no_strip=True" parameter. Do open a GitHub issue if you'd like me to add this check to the git-hooks. I will likely give it less priority because you'll have a way to implement it on your on, but I will get to it eventually. -- Joel
Re: Whitespace at the start of first line of commit
> A quick run of the testsuite reveals that this assumption is made > all over. I am opposed to having this feature be a standard feature > of the git-hooks, so you wouldn't have to add an ad hoc check. > The way I would do it is by enhancing the git_run function to check > for a parameter named "_no_strip" and block the strip() operation > when passed as True. You can then implement your check using the usual > git interface, with the extra "_no_strip=True" parameter. > > Do open a GitHub issue if you'd like me to add this check to > the git-hooks. I will likely give it less priority because > you'll have a way to implement it on your on, but I will get to it > eventually. I apologize. Re-reading myself, I'm mixing various issues and not being clear as a result, let me rephrase: For your immediate need, I am proposing a way to adapt the git_run function so you can use it to implement your check. Another option is to use Python's subprocess module directly, but I think this will be more work than what I suggest. For the longer term, you'll have access to a hook that you can use to call a script to validate an update. In that hook, you'll have total implementation freedom, so you can implement that check there, and not have to worry about that implementation detail in the git-hooks. Also longer term, I can add that check directly in the git-hooks as well. I don't remember anyone ever really making this kind of mistake, but it doesn't mean that it's unlikely either, nor that it would be specific to the GCC community. Hence the merit of having it in git-hooks directly. -- Joel
Re: gcc-cvs mails for personal/vendor branches for merge commits
Joel Brobecker wrote: I think it's desirable for development that *happens on* the personal and vendor branches to be visible in gcc-cvs - that is different from things getting merged into them. Likewise for the refs/heads/devel/* development branches - non-fast-forward pushes are not permitted there, but such branches can expect to have lots of merges from master, and it's the actual development taking place *on* the branches - the new commits - that is of interest to see on gcc-cvs, not the merging of existing commits. Would it be sufficient to say that some branches would only trigger a summary email, but not individual commit emails? The downside is that you would not be getting the "diff" for commits that are really completely new. But on the other hand, it would fit better with the fact that user branches could have frequent re-basing, thus causing the same commit email being sent over and over at each rebase operation. It would also answer the issue of the number of emails being sent when people are doing a merge which brings in more commits than the max-emails number. AFAIU, we have access to more fine-grained information; isn’t it possible to differentiate “new” commits, from ‘merges’ and from ‘rebases’? (because a ‘new’ commit does not have the extra fields set up for merges and rebases). For example, I’d like to know that user/fred has rebased the branch i’m interested in but OTOH, would not find the per-commit mails useful (so a summary there is good). If a push contains a combination of things - new work, merged and rebased commits - then there would have to be some way to react to split or aggregate the messages / diffs per commit id. Iain
Re: gcc-cvs mails for personal/vendor branches for merge commits
On Fri, 17 Jan 2020, Joel Brobecker wrote: > Would it be sufficient to say that some branches would only > trigger a summary email, but not individual commit emails? Maybe that will end up being appropriate for users / vendors branches, if we can't effectively distinguish rebased commits from new ones. But for shared fast-forward-only development branches, I think the individual commit emails are appropriate for commits new to the branch, while a summary email is appropriate for merges to the branch. -- Joseph S. Myers jos...@codesourcery.com
Re: Whitespace at the start of first line of commit
On Fri, 17 Jan 2020, Joel Brobecker wrote: > Do open a GitHub issue if you'd like me to add this check to > the git-hooks. I will likely give it less priority because > you'll have a way to implement it on your on, but I will get to it > eventually. I think https://github.com/AdaCore/git-hooks/issues/7 generally covers all the things we've come up with regarding custom checks *on commit messages*, both those that are clearly GCC-specific (From-SVN:) and those that are more generic for projects where people formerly used ChangeLog content as their commit messages (rejecting a first line looking like a ChangeLog header, rejecting a first line starting with whitespace, rejecting a single-word first line). -- Joseph S. Myers jos...@codesourcery.com
Re: gcc-cvs mails for personal/vendor branches for merge commits
> AFAIU, we have access to more fine-grained information; isn’t it possible > to differentiate “new” commits, from ‘merges’ and from ‘rebases’? > (because a ‘new’ commit does not have the extra fields set up for merges > and rebases). In my opinion, this would create a lot of complication for the benefits being gained. I also think that the more variations of behaviors you introduce, the harder is becomes for people to know what's right and what's not expected. People then start getting surprised and start asking about it. At best, it's just a quick answer, but in some cases, it takes time to remember why we set things up the way they are and why it doesn't make sense to change it. Over the years, I have really learnt to enjoy the benefits of consistency, even if it is means some areas are suboptimal. The "suboptimality" can still be a better compromise overall than a superengineered system. > For example, I’d like to know that user/fred has rebased the branch i’m > interested in but OTOH, would not find the per-commit mails useful (so a > summary there is good). > > If a push contains a combination of things - new work, merged and rebased > commits - then there would have to be some way to react to split or aggregate > the messages / diffs per commit id. -- Joel
Re: gcc-cvs mails for personal/vendor branches for merge commits
On 1/17/20 11:55 AM, Joel Brobecker wrote: AFAIU, we have access to more fine-grained information; isn’t it possible to differentiate “new” commits, from ‘merges’ and from ‘rebases’? (because a ‘new’ commit does not have the extra fields set up for merges and rebases). In my opinion, this would create a lot of complication for the benefits being gained. I also think that the more variations of behaviors you introduce, the harder is becomes for people to know what's right and what's not expected. People then start getting surprised and start asking about it. At best, it's just a quick answer, but in some cases, it takes time to remember why we set things up the way they are and why it doesn't make sense to change it. Over the years, I have really learnt to enjoy the benefits of consistency, even if it is means some areas are suboptimal. The "suboptimality" can still be a better compromise overall than a superengineered system. Spamming the list with emails every time someone merges master to their development branch sounds highly suboptimal, and likely to lead to disabling email entirely for those branches. Is it so complicated to send a single email for a merge commit or non-fast-forward push? Jason
Re: gcc-cvs mails for personal/vendor branches for merge commits
> > Would it be sufficient to say that some branches would only > > trigger a summary email, but not individual commit emails? > > Maybe that will end up being appropriate for users / vendors branches, if > we can't effectively distinguish rebased commits from new ones. But for > shared fast-forward-only development branches, I think the individual > commit emails are appropriate for commits new to the branch, while a > summary email is appropriate for merges to the branch. OK. I will see if there is a reasonable way to provide this. -- Joel
Re: gcc-cvs mails for personal/vendor branches for merge commits
> > > AFAIU, we have access to more fine-grained information; isn’t it possible > > > to differentiate “new” commits, from ‘merges’ and from ‘rebases’? > > > (because a ‘new’ commit does not have the extra fields set up for merges > > > and rebases). > > > > In my opinion, this would create a lot of complication for the benefits > > being gained. I also think that the more variations of behaviors you > > introduce, the harder is becomes for people to know what's right and > > what's not expected. People then start getting surprised and start > > asking about it. At best, it's just a quick answer, but in some cases, > > it takes time to remember why we set things up the way they are and why > > it doesn't make sense to change it. Over the years, I have really learnt > > to enjoy the benefits of consistency, even if it is means some areas > > are suboptimal. The "suboptimality" can still be a better compromise > > overall than a superengineered system. > > Spamming the list with emails every time someone merges master to their > development branch sounds highly suboptimal, and likely to lead to disabling > email entirely for those branches. Is it so complicated to send a single > email for a merge commit or non-fast-forward push? Well, no. I was going so say that this is what I have been proposing all along, except the way you phrased your suggestion above makes me think that perhaps you want something more automatic, where the hooks decide dynamically, rather than the choice being made by configuration. So it's not exactly the same, but quite similar in spirit. I think we can find ways that will satisfy the need for fewer emails without having to have that extra logic, though. Also, you guys have to understand that you are all coming to me from multiple directions at the same time, and making requests that are not always easy to reconcile. I do completely understand that getting hundreds of emails because of a merge into a development branch is far from optimal, and it's absolutely not what I am suggesting we do here. In fact, you'll see that I told Joseph in a separate mail that I will think this over and try to come up with something that answers the situation he described. What I am alerting people to is trying to have special-case handling for every scenario we can conceive. I'm wondering if we wouldn't be better off having this discussion live over a meeting or a series of meetings... -- Joel
Re: gcc-cvs mails for personal/vendor branches for merge commits
Joel Brobecker wrote: AFAIU, we have access to more fine-grained information; isn’t it possible to differentiate “new” commits, from ‘merges’ and from ‘rebases’? (because a ‘new’ commit does not have the extra fields set up for merges and rebases). In my opinion, this would create a lot of complication for the benefits being gained. I also think that the more variations of behaviors you introduce, the harder is becomes for people to know what's right and what's not expected. People then start getting surprised and start asking about it. At best, it's just a quick answer, but in some cases, it takes time to remember why we set things up the way they are and why it doesn't make sense to change it. Over the years, I have really learnt to enjoy the benefits of consistency, even if it is means some areas are suboptimal. The "suboptimality" can still be a better compromise overall than a superengineered system. Spamming the list with emails every time someone merges master to their development branch sounds highly suboptimal, and likely to lead to disabling email entirely for those branches. Is it so complicated to send a single email for a merge commit or non-fast-forward push? Well, no. I was going so say that this is what I have been proposing all along, except the way you phrased your suggestion above makes me think that perhaps you want something more automatic, where the hooks decide dynamically, rather than the choice being made by configuration. So it's not exactly the same, but quite similar in spirit. I think we can find ways that will satisfy the need for fewer emails without having to have that extra logic, though. Also, you guys have to understand that you are all coming to me from multiple directions at the same time, and making requests that are not always easy to reconcile. I do completely understand that getting hundreds of emails because of a merge into a development branch is far from optimal, and it's absolutely not what I am suggesting we do here. In fact, you'll see that I told Joseph in a separate mail that I will think this over and try to come up with something that answers the situation he described. What I am alerting people to is trying to have special-case handling for every scenario we can conceive. for my part, I was not trying to specify “requirements” - but identify different scenarios that we might want to handle (better to decide how we want to do things at the start, than to create changes later). As a general rule, I’m 100% in favour of KISS. I'm wondering if we wouldn't be better off having this discussion live over a meeting or a series of meetings… could be, Iain
Re: gcc-cvs mails for personal/vendor branches for merge commits
On 1/17/20 12:59 PM, Iain Sandoe wrote: Joel Brobecker wrote: AFAIU, we have access to more fine-grained information; isn’t it possible to differentiate “new” commits, from ‘merges’ and from ‘rebases’? (because a ‘new’ commit does not have the extra fields set up for merges and rebases). In my opinion, this would create a lot of complication for the benefits being gained. I also think that the more variations of behaviors you introduce, the harder is becomes for people to know what's right and what's not expected. People then start getting surprised and start asking about it. At best, it's just a quick answer, but in some cases, it takes time to remember why we set things up the way they are and why it doesn't make sense to change it. Over the years, I have really learnt to enjoy the benefits of consistency, even if it is means some areas are suboptimal. The "suboptimality" can still be a better compromise overall than a superengineered system. Spamming the list with emails every time someone merges master to their development branch sounds highly suboptimal, and likely to lead to disabling email entirely for those branches. Is it so complicated to send a single email for a merge commit or non-fast-forward push? Well, no. I was going so say that this is what I have been proposing all along, except the way you phrased your suggestion above makes me think that perhaps you want something more automatic, where the hooks decide dynamically, rather than the choice being made by configuration. So it's not exactly the same, but quite similar in spirit. I think we can find ways that will satisfy the need for fewer emails without having to have that extra logic, though. Also, you guys have to understand that you are all coming to me from multiple directions at the same time, and making requests that are not always easy to reconcile. I do completely understand that getting hundreds of emails because of a merge into a development branch is far from optimal, and it's absolutely not what I am suggesting we do here. In fact, you'll see that I told Joseph in a separate mail that I will think this over and try to come up with something that answers the situation he described. What I am alerting people to is trying to have special-case handling for every scenario we can conceive. for my part, I was not trying to specify “requirements” - but identify different scenarios that we might want to handle (better to decide how we want to do things at the start, than to create changes later). Indeed, this is largely a discussion about what is desirable and feasible. How straightforward a particular request will be is helpful feedback. Thank you, and sorry I got snarky above. Jason
Re: gcc-cvs mails for personal/vendor branches for merge commits
On Fri, 17 Jan 2020, Joel Brobecker wrote: > Also, you guys have to understand that you are all coming to me from > multiple directions at the same time, and making requests that are > not always easy to reconcile. I do completely understand that getting The issues filed on GitHub are meant to help track individual issues (both those we've fixed locally with GCC-specific patches and those, such as this one, that we haven't), although that doesn't guarantee there's a single consistent view of how best to address a particular issue. -- Joseph S. Myers jos...@codesourcery.com
gcc-8-20200117 is now available
Snapshot gcc-8-20200117 is now available on https://gcc.gnu.org/pub/gcc/snapshots/8-20200117/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-8 revision bb0763101b88f5f916bb5b2aa13fed9e7b6a8d9e You'll find: gcc-8-20200117.tar.xzComplete GCC SHA256=a6b9bf4e02b5bd120b378dd340b99793e521993b634d9e5066cf49b3a748c2c3 SHA1=ab57e8a4babc1191282701f39a9cd33f0ee8536d Diffs from 8-20200110 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.
