Chelsea Antiques Fair-2020
Hi, Trust you are doing well. We take this opportunity to know if you would be interested in acquiring the Attendees & Exhibitors list of Chelsea Antiques Fair- 2020 At uk for pre-show marketing campaign, networking and various marketing initiatives The list contains: Company/Firm Name, Full Name, First Name, Middle Name, Last Name, Business Email, Title, Address, Phone Number, Website. Please let me know your interest to send you the counts and cost details of attendees or exhibitors as per your requirement. If you are not the right person, please forward this email to the concern person. Awaiting for your positive replay. Warm regards, Jane Smith Marketing
Re: Git ChangeLog policy for GCC Testsuite inquiry
On Fri, Feb 7, 2020 at 4:43 PM Richard Earnshaw (lists) wrote: > > On 07/02/2020 15:32, Segher Boessenkool wrote: > > On Fri, Feb 07, 2020 at 01:56:08PM +, Richard Earnshaw (lists) wrote: > >> On 07/02/2020 13:48, Segher Boessenkool wrote: > >>> Should we require some simple markup in the commit message before the > >>> changelogs? Maybe > >>> > >>> CL gcc/ > >>> * blablalba etc. > >>> CL gcc/testsuite/ > >>> * gcc.target/... > >> > >>> etc. > >>> > >>> (Dunno if just "^CL " is too short?) > >> > >> I was thinking "@CL ", but ^CL would work just as well. > > > > I meant ^ as in a regular expression, sorry for not being clear. > > Ah! I think something more syntactically explicit would help avoid the > risk of mis-parsing. One just has to err on the side of rejection ... sofar I've tried to start matching at ^20 (the date line) until the last ^\tPR line (multiple PR foo/12345 lines) then the actual ChangeLog file entries are separated by blank likes where there's unwritten policy to prepend those with ^\tDIR/ where DIR is for example cp (implicitely inside gcc) or libgomp (toplevel). There's easy enough heuristics to detect the gcc/ and gcc/testsuite case which is most often omitted (just see where the first mentioned file lives in). That said, doing the parsing is reasonably easy but the question is the execution environment of the git hook - does the script have access to an actual checkout? I guess not (so much for file existance tests), but then how to amend the commit with new file changes? And yes, the idea was to keep the status quo (checked in and updated ChangeLog files) but have the convenience of not manually updating them. And indeed that makes a transition to a post ChangeLog file world easy. Richard. > > > >> Any script should, in addition to extracting the author and email also > >> grep for "Co-authored-by:" annotations and add those as additional > >> contributors, of course. > > > > Is there no existing established practice for that? (Or is this it and > > so infrquent that I never have seen it :-) ) > > > > > > It's a convention (much like signed-off-by, etc). But it's fairly > widely accepted. In the git conversion we added fields for it where we > detected co-authorship in the ChangeLog entries. Git has no specific > field for recording additional authors, so this approach addresses this > and some tools know how to add the appropriate accreditation based on it. > > https://git.wiki.kernel.org/index.php/CommitMessageConventions > > Also "git help interpret-trailers" > > R. > > > > Segher > > >
Re: Git ChangeLog policy for GCC Testsuite inquiry
On Thu, 6 Feb 2020, Segher Boessenkool wrote: > Instead of "git am" I had "patch -p1 <", May I suggest "git apply" instead of the good old patch program. (The "-p1" is of course built-in and you never have to do a manual roll-back or separate --dry-run pass.) brgds, H-P
Re: Git ChangeLog policy for GCC Testsuite inquiry
On 08/02/2020 16:50, Segher Boessenkool wrote: On Fri, Feb 07, 2020 at 03:34:03PM -0700, Tom Tromey wrote: "Jason" == Jason Merrill writes: Jason> I omit ChangeLogs by adding ':!*/ChangeLog' to the end of the git Jason> send-email command. I don't remember where I found that incantation. Cool, I did not know about this. Yeah, me neither. And it isn't something new, it is ancient. The manpage for this is "man gitrevisions". It doesn't explain the ! though, and not wildcards even. (dir.c in git.git, if you like spelunking). Segher Just for anyone interested -- the manpage that describes the '!' is `gitglossary`. It's under the description of `pathspec`, and has a long-form of `:(exclude)`. http://man7.org/linux/man-pages/man7/gitglossary.7.html MM
Request For Partnership
Hello, CLI Investment Group here in New York, an affiliate of CLI Ventures. We are a Financial Investment Company looking for Company(s) with profitable projects or entrepreneurial teams that require partnership. We are focusing on supporting early to late stage Companies. If interested, please contact us for details and procedures. Regards, Samuel Price. Loan Administration CLI Investment Group 14 Wall St, New York, NY 10005 U.S.A Email: samuel.pr...@cliinvestmentgroups.com Samuel Price 14 Wall St , New York , NY 10005 Unsubscribe ( https://u14851712.ct.sendgrid.net/wf/unsubscribe?upn=iaYFtpR3d-2FR9fRvTiX3jMDBZwjPPo4QKSVBIjjPRdwz3SSTlv2F936N010GwmXCUCuDRkOuS0ht29ObqtALY1UKK3uNZV6WD-2BX-2BK4-2BFC-2Fw75W8xCRqxjBYlr0sSjnQg0grszvigrr-2Ffaa-2FWgmR7cYYTRqf3TxmY708YKsh9jAIJs-2BegcH4QIKfPp5lzPRhKtbRAmcNpFTEZeBqrJfDm2vIA70UrcOwLdwHGLqOve6qBjPSZLKdqhrospXRoZBXNKMxjhaOiJE9e9vp1ZKU1dfLxDUYrrEucB4yoBNAtFP6yAa9aH7m2xlfwtiIon26z6nrw51UvBVZZDS94gZLrzibQ-2F7mTScmc9Ad6hzjj6GlKWdHOdN-2BeAdOQsCHjj9eJNyFlVjLOTcTt5FQZ6E8WmJx-2FNTGCmwHyvoDxGQSn1fwHXGCjbDqug2w4ahMOR-2FEMqnSeWR3Gl3glOZO7YGQEwO7lRRkr3abOta-2BqyvC6orMIgbpZExR3npDlC3LYtZMPu8fxOK3npsCgMb-2FldS85XmLvwBH9DNdgcHQJr-2FNNzLNoy7vl5YCKcLEw9EoQ0lscsNsyC-2FbVfE8Zx8Npr2zFRQxb-2F88GGeySUK-2Fx4Z-2BvoRGCfUOT6uM8ZCKOHfT2Xhqtd )
Re: Git ChangeLog policy for GCC Testsuite inquiry
On Mon, Feb 10, 2020 at 05:51:10PM +, Matthew Malcomson wrote: > Just for anyone interested -- the manpage that describes the '!' is > `gitglossary`. > > It's under the description of `pathspec`, and has a long-form of > `:(exclude)`. https://github.com/git/git/commit/93dbefb389a011c9107a3908fd38e743055be267 (2017, Git 2.14.3) made this more discoverable, and https://github.com/git/git/commit/ef79b1f8704668a6cdf4278f9255e03ca785bfb4 is what implemented this originally (2014, Git 1.9.0). Which makes me wonder why it did not work with 2.0.0? Hrm. Maybe I messed up the syntax somewhere, for testing it. Segher
Eagerly evaluate __atomic_is_lock_free to 0 for oversized types
GCC never evaluates __atomic_is_lock_free to 0. (gcc/builtins.c:fold_builtin_atomic_always_lock_free) I'd like to change clang to eagerly evaluate __atomic_is_lock_free to 0 for apparently oversized types. This helps some platforms to avoid a dependency on libatomic. Either of the following choices can move my patch https://reviews.llvm.org/D72579 forward: * GCC will like do the same * GCC is committed to not extend __atomic_is_lock_free in a clang incompatible way.
Re: Eagerly evaluate __atomic_is_lock_free to 0 for oversized types
On Mon, Feb 10, 2020 at 8:35 PM Fangrui Song wrote: > > GCC never evaluates __atomic_is_lock_free to 0. > (gcc/builtins.c:fold_builtin_atomic_always_lock_free) Huh? /* We need a corresponding integer mode for the access to be lock-free. */ size = INTVAL (expand_normal (arg0)) * BITS_PER_UNIT; if (!int_mode_for_size (size, 0).exists (&mode)) return boolean_false_node; ... /* If the object has smaller alignment, the lock free routines cannot be used. */ if (type_align < mode_align) return boolean_false_node; /* Check if a compare_and_swap pattern exists for the mode which represents the required size. The pattern is not allowed to fail, so the existence of the pattern indicates support is present. Also require that an atomic load exists for the required size. */ if (can_compare_and_swap_p (mode, true) && can_atomic_load_p (mode)) return boolean_true_node; else return boolean_false_node; Thanks, Andrew Pinski > I'd like to change clang to eagerly evaluate __atomic_is_lock_free to 0 for > apparently oversized types. > This helps some platforms to avoid a dependency on libatomic. > > Either of the following choices can move my patch > https://reviews.llvm.org/D72579 forward: > > * GCC will like do the same > * GCC is committed to not extend __atomic_is_lock_free in a clang > incompatible way.
Re: Eagerly evaluate __atomic_is_lock_free to 0 for oversized types
On Mon, Feb 10, 2020 at 8:40 PM Andrew Pinski wrote:
>
> On Mon, Feb 10, 2020 at 8:35 PM Fangrui Song wrote:
> >
> > GCC never evaluates __atomic_is_lock_free to 0.
> > (gcc/builtins.c:fold_builtin_atomic_always_lock_free)
>
> Huh?
Oh it is this, you quoted the wrong function which made things more complicated.
/* Return a one or zero if it can be determined that object ARG1 of size ARG
is lock free on this architecture. */
static tree
fold_builtin_atomic_is_lock_free (tree arg0, tree arg1)
{
if (!flag_inline_atomics)
return NULL_TREE;
/* If it isn't always lock free, don't generate a result. */
if (fold_builtin_atomic_always_lock_free (arg0, arg1) == boolean_true_node)
return boolean_true_node;
return NULL_TREE;
}
--- CUT ---
Thanks,
Andrew Pinski
> /* We need a corresponding integer mode for the access to be lock-free. */
> size = INTVAL (expand_normal (arg0)) * BITS_PER_UNIT;
> if (!int_mode_for_size (size, 0).exists (&mode))
> return boolean_false_node;
> ...
> /* If the object has smaller alignment, the lock free routines cannot
> be used. */
> if (type_align < mode_align)
> return boolean_false_node;
> /* Check if a compare_and_swap pattern exists for the mode which represents
> the required size. The pattern is not allowed to fail, so the existence
> of the pattern indicates support is present. Also require that an
> atomic load exists for the required size. */
> if (can_compare_and_swap_p (mode, true) && can_atomic_load_p (mode))
> return boolean_true_node;
> else
> return boolean_false_node;
>
>
> Thanks,
> Andrew Pinski
>
>
>
> > I'd like to change clang to eagerly evaluate __atomic_is_lock_free to 0 for
> > apparently oversized types.
> > This helps some platforms to avoid a dependency on libatomic.
> >
> > Either of the following choices can move my patch
> > https://reviews.llvm.org/D72579 forward:
> >
> > * GCC will like do the same
> > * GCC is committed to not extend __atomic_is_lock_free in a clang
> > incompatible way.
