[LLVMdev] Testing canaries
Izabela Maffra
izabelakarennina at gmail.com
Mon Jan 28 10:20:32 PST 2013
Dear Duncan,
thank you very much. I have been able to use it now, via the following
command line:
clang -emit-llvm -c -fstack-protector canary.c -o canary.bc
llc -print-before=stack-protector -print-after=stack-protector -o
canary.s < canary.bc
Thank you again,
Izabela Maffra.
On 26 January 2013 15:55, <llvmdev-request at cs.uiuc.edu> wrote:
> Send LLVMdev mailing list submissions to
> llvmdev at cs.uiuc.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> or, via email, send a message with subject or body 'help' to
> llvmdev-request at cs.uiuc.edu
>
> You can reach the person managing the list at
> llvmdev-owner at cs.uiuc.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of LLVMdev digest..."
>
>
> Today's Topics:
>
> 1. Re: [cfe-dev] RFC: put commit messages in *-commits subject
> lines? (Daniel Dunbar)
> 2. Re: TargetLowering vs. TargetTransform (Nadav Rotem)
> 3. Re: [cfe-dev] RFC: put commit messages in *-commits subject
> lines? (Sebastian Pop)
> 4. Re: [cfe-dev] RFC: put commit messages in *-commits subject
> lines? (Daniel Dunbar)
> 5. Re: [cfe-dev] RFC: put commit messages in *-commits subject
> lines? (Daniel Dunbar)
> 6. Re: [cfe-dev] RFC: put commit messages in *-commits subject
> lines? (NAKAMURA Takumi)
> 7. Re: [cfe-dev] RFC: put commit messages in *-commits subject
> lines? (Tobias Grosser)
> 8. Re: [cfe-dev] RFC: put commit messages in *-commits subject
> lines? (Daniel Dunbar)
> 9. Re: [cfe-dev] RFC: put commit messages in *-commits subject
> lines? (Eli Bendersky)
> 10. Re: [cfe-dev] RFC: put commit messages in *-commits subject
> lines? (David Blaikie)
> 11. Re: [cfe-dev] RFC: put commit messages in *-commits subject
> lines? (Eli Bendersky)
> 12. Re: TargetLowering vs. TargetTransform (Renato Golin)
> 13. Re: [cfe-dev] RFC: put commit messages in *-commits subject
> lines? (Tobias Grosser)
> 14. Re: Testing canaries (Duncan Sands)
> 15. Re: [cfe-dev] RFC: put commit messages in *-commits subject
> lines? (David Blaikie)
> 16. lli problem with a simple OpenGL (sara.elshobaky)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 25 Jan 2013 14:18:08 -0800
> From: Daniel Dunbar <daniel at zuster.org>
> To: Sebastian Pop <spop at codeaurora.org>
> Cc: "cfe-dev at cs.uiuc.edu Developers" <cfe-dev at cs.uiuc.edu>, Daniel
> Dunbar <daniel_dunbar at apple.com>, LLVM Developers Mailing
> List
> <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] [cfe-dev] RFC: put commit messages in *-commits
> subject lines?
> Message-ID:
> <
> CAEU8z69eX+QQyakoKMK38fGZ9ZN5xOQV_tq+HhxGromLOAmsXg at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Fri, Jan 25, 2013 at 2:06 PM, Sebastian Pop <spop at codeaurora.org>
> wrote:
>
> > Sebastian Pop wrote:
> > > Hi Daniel,
> > >
> > > Daniel Dunbar wrote:
> > > > Hi Sebastion,
> > > >
> > > > I've attached the current configuration file from the server.
> > > >
> > > > I'm not sure how far you want to go down the "trying to get realize
> > nice
> > > > summary path" lines, but if svn_mailer somehow supported running an
> > > > external script to process the commit and come up with the path that
> > would
> > > > be ideal for integration on the server.
> > >
> > > I think you could modify the sources of svn_mailer to add such a hook.
> > When I
> > > first investigated this issue, I ended on a bug report from the debian
> > project
> > > that fixed the subject line with a one line patch:
> > >
> > > > To get the first line of the log message as a subject line, please
> > apply this
> > > > one line patch:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=17;bug=379534
> > > > Note that you can directly patch the installed script: on my machine
> > it is
> > > > located in
> > /usr/local/lib/python2.7/dist-packages/svnmailer/notifier/_mail.py
> > >
> > > For your convenience, here is the patch from that debian bug report:
> > >
> > >
> > > svnmailer: add log substitution for subject templates
> > >
> > > Add first line of commit log as a substitution variable for
> > > *_subject_template, E.G. add %(log)s to use.
> > >
> > > Signed-off-by: Peter Korsgaard <jacmet at sunsite.dk>
> > >
> > > Index: svnmailer-1.0.8/src/lib/svnmailer/notifier/_mail.py
> > > ===================================================================
> > > --- svnmailer-1.0.8.orig/src/lib/svnmailer/notifier/_mail.py
> 2008-05-27
> > 14:56:27.000000000 +0200
> > > +++ svnmailer-1.0.8/src/lib/svnmailer/notifier/_mail.py
> 2008-05-27
> > 15:01:50.000000000 +0200
> > > @@ -314,6 +314,7 @@
> > > 'part' : countprefix,
> > > 'files' : self._getPrefixedFiles(changeset),
> > > 'dirs' : self._getPrefixedDirectories(changeset),
> > > + 'log' : self.getLog().split('\n',1)[0],
> > > }
> > >
> > > # We may try twice, first with files/dirs = files
> > >
> > >
> >
> > Once you patched the installed version of this file, in
> > /usr/local/lib/python2.7/dist-packages/svnmailer/notifier/_mail.py
> > you have two more changes in the config file you sent me: (the first
> > change to
> > print the context of diff is something that I was missing more than the
> > subject)
> >
>
> I'm a bit hesitant to just hack up the installed copy of svnmailer, are we
> sure this patch hasn't been dealt with in an upstream version?
>
>
> >
> > --- svn-mailer.conf.orig 2013-01-25 15:39:23.000000000 -0600
> > +++ svn-mailer.conf 2013-01-25 15:42:02.000000000 -0600
> > @@ -1,6 +1,6 @@
> > [general]
> > sendmail_command = /usr/sbin/sendmail
> > -diff_command = /usr/bin/diff -u -L %(label_from)s -L %(label_to)s
> > %(from)s %(to)s
> > +diff_command = /usr/bin/diff -up -L %(label_from)s -L %(label_to)s
> > %(from)s %(to)s
> > generate_diffs = add copy modify propchange
> >
>
> I'll go ahead and make this change.
>
> - Daniel
>
>
> >
> > [authors]
> > @@ -360,6 +360,7 @@
> > mail_type = single
> > show_applied_charset = nondefault
> > custom_header = SVN-Repository %(REPOS)s
> > +commit_subject_template = %(prefix)s r%(revision)s - %(log)s
> >
> > [branch]
> > for_repos = .*/llvm-project$
> >
> >
> >
> > Note that I have not addressed the path prefix suggestion from David:
> >
> > >>> For what it's worth, (I think) Chris' suggestion of including the
> > >>> directories was about including them "smart"ly by removing conceptual
> > >>> duplicates (lib/foo + include/foo + test/foo) and generally giving a
> > >>> brief sense of what a change is touching. If the change you have adds
> > >>> the full (repo-relative) path all the directories without any smart
> > >>> deduplication then I suspect it's going to easily push the log
> > >>> description off most mail readers (especially mobile) & reduce the
> > >>> value of this change.
> > >>>
> > >>> I suspect we'll want to just stick with revision + log for now.
> > >>
> > >> That's fine. Alternatively we can provide a list of all the dirs that
> > we want
> > >> to see appearing and match them like this:
> > >>
> > >> for_paths =
> >
> .*(?P<SelectDirs>(lib/Analysis|lib/Transforms/Vectorize|lib/Transforms/Scalar)).*
> > >>
> > >> commit_subject_template = %(prefix)s r%(revision)s - [%(SelectDirs)s]
> > %(log)s
> > >
> > >Could we go one step further and map these paths to names (eg: map
> > >"lib/Analysis", "include/llvm/Analysis", "test/Analysis" -> "Analysis"
> > >and unique the results)? Also, I'd prefer to have the dirs after the
> > >log message I think, though perhaps if we get them short enough it'd
> > >work.
> > >
> > >This solution does seem like it could involve a bit of manual work to
> > >update the list of blessed dirs all the time. If we could express it
> > >generically (lib/*, test/*, include/llvm/*) it might be OK, but as it
> > >stands I'm still not sure it's worth the hassle.
> >
> > This could be done as Daniel has suggested, running a separate script
> that
> > filters and classifies in a smarter way the commits following the paths
> > they are
> > touching.
> >
> > Thanks,
> > Sebastian
> > --
> > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> > by The Linux Foundation
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20130125/d6cf234a/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Fri, 25 Jan 2013 15:03:48 -0800
> From: Nadav Rotem <nrotem at apple.com>
> To: Renato Golin <renato.golin at linaro.org>
> Cc: LLVM Dev <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] TargetLowering vs. TargetTransform
> Message-ID: <4AF031DB-A805-4154-AD95-516B85A79F20 at apple.com>
> Content-Type: text/plain; CHARSET=US-ASCII
>
> >
> > TargetTransform (TT) only has the free checks on types, while
> TargetLowering (TL) has on SDValue and destination type.
> >
>
> Yes. This is a limitation of the current API. The design decision behind
> it was that in many cases you want to know the cost of IR before you
> generate it.
> For example, during vectorization you want to know how a particular IR
> would look if you were to vectorize it. Also, we wanted to rely on tables
> as much as possible. We did not want to write code to resemble ISel in
> order to estimate the cost. Is this something that we can live with ?
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 25 Jan 2013 17:06:33 -0600
> From: Sebastian Pop <spop at codeaurora.org>
> To: Daniel Dunbar <daniel at zuster.org>
> Cc: "cfe-dev at cs.uiuc.edu Developers" <cfe-dev at cs.uiuc.edu>, Daniel
> Dunbar <daniel_dunbar at apple.com>, LLVM Developers Mailing
> List
> <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] [cfe-dev] RFC: put commit messages in *-commits
> subject lines?
> Message-ID: <20130125230633.GA21987 at codeaurora.org>
> Content-Type: text/plain; charset=us-ascii
>
> Daniel Dunbar wrote:
> > I'm a bit hesitant to just hack up the installed copy of svnmailer, are
> we
> > sure this patch hasn't been dealt with in an upstream version?
>
> I don't see that change in the last dev version:
> http://storage.perlig.de/svnmailer/svnmailer-1.1.0-dev-r1373.tar.bz2
>
> > > -diff_command = /usr/bin/diff -u -L %(label_from)s -L %(label_to)s
> > > %(from)s %(to)s
> > > +diff_command = /usr/bin/diff -up -L %(label_from)s -L %(label_to)s
> > > %(from)s %(to)s
> > > generate_diffs = add copy modify propchange
> > >
> >
> > I'll go ahead and make this change.
>
> Thanks,
> Sebastian
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by The Linux Foundation
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 25 Jan 2013 15:11:40 -0800
> From: Daniel Dunbar <daniel at zuster.org>
> To: Sebastian Pop <spop at codeaurora.org>
> Cc: "cfe-dev at cs.uiuc.edu Developers" <cfe-dev at cs.uiuc.edu>, Daniel
> Dunbar <daniel_dunbar at apple.com>, LLVM Developers Mailing
> List
> <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] [cfe-dev] RFC: put commit messages in *-commits
> subject lines?
> Message-ID:
> <CAEU8z6-wn8SjDtJiDoGxbyVR=
> 6QCSQczT7Y8LvvGtbyw5hXFFw at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Yup, I didn't either. I went ahead and hacked up a copy with that change
> and am switching it over now.
>
> - Daniel
>
>
> On Fri, Jan 25, 2013 at 3:06 PM, Sebastian Pop <spop at codeaurora.org>
> wrote:
>
> > Daniel Dunbar wrote:
> > > I'm a bit hesitant to just hack up the installed copy of svnmailer, are
> > we
> > > sure this patch hasn't been dealt with in an upstream version?
> >
> > I don't see that change in the last dev version:
> > http://storage.perlig.de/svnmailer/svnmailer-1.1.0-dev-r1373.tar.bz2
> >
> > > > -diff_command = /usr/bin/diff -u -L %(label_from)s -L %(label_to)s
> > > > %(from)s %(to)s
> > > > +diff_command = /usr/bin/diff -up -L %(label_from)s -L %(label_to)s
> > > > %(from)s %(to)s
> > > > generate_diffs = add copy modify propchange
> > > >
> > >
> > > I'll go ahead and make this change.
> >
> > Thanks,
> > Sebastian
> > --
> > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> > by The Linux Foundation
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20130125/a8245c63/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 5
> Date: Fri, 25 Jan 2013 15:15:46 -0800
> From: Daniel Dunbar <daniel at zuster.org>
> To: Sebastian Pop <spop at codeaurora.org>
> Cc: "cfe-dev at cs.uiuc.edu Developers" <cfe-dev at cs.uiuc.edu>, Daniel
> Dunbar <daniel_dunbar at apple.com>, LLVM Developers Mailing
> List
> <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] [cfe-dev] RFC: put commit messages in *-commits
> subject lines?
> Message-ID:
> <
> CAEU8z69qnQnZ44m+eTeMsvEGtReK288SFKUC4Tyk-wzgJeiOyQ at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Ok, this is done and seems to work.
>
> As far as Chris's request for getting "key directory" paths into the commit
> message, I thought about working on it, but in the end I'm not sure why we
> shouldn't just encourage people to self-tag their leading commit line with
> some sort of standard key ([MC], [Target/Mips], whatever).
>
> - Daniel
>
>
> On Fri, Jan 25, 2013 at 3:11 PM, Daniel Dunbar <daniel at zuster.org> wrote:
>
> > Yup, I didn't either. I went ahead and hacked up a copy with that change
> > and am switching it over now.
> >
> > - Daniel
> >
> >
> > On Fri, Jan 25, 2013 at 3:06 PM, Sebastian Pop <spop at codeaurora.org
> >wrote:
> >
> >> Daniel Dunbar wrote:
> >> > I'm a bit hesitant to just hack up the installed copy of svnmailer,
> are
> >> we
> >> > sure this patch hasn't been dealt with in an upstream version?
> >>
> >> I don't see that change in the last dev version:
> >> http://storage.perlig.de/svnmailer/svnmailer-1.1.0-dev-r1373.tar.bz2
> >>
> >> > > -diff_command = /usr/bin/diff -u -L %(label_from)s -L %(label_to)s
> >> > > %(from)s %(to)s
> >> > > +diff_command = /usr/bin/diff -up -L %(label_from)s -L %(label_to)s
> >> > > %(from)s %(to)s
> >> > > generate_diffs = add copy modify propchange
> >> > >
> >> >
> >> > I'll go ahead and make this change.
> >>
> >> Thanks,
> >> Sebastian
> >> --
> >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted
> >> by The Linux Foundation
> >>
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20130125/4c2976f4/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 6
> Date: Sat, 26 Jan 2013 08:40:50 +0900
> From: NAKAMURA Takumi <geek4civic at gmail.com>
> To: Daniel Dunbar <daniel at zuster.org>
> Cc: Chris Lattner <sabre at nondot.org>, Sebastian Pop
> <spop at codeaurora.org>, "cfe-dev at cs.uiuc.edu Developers"
> <cfe-dev at cs.uiuc.edu>, Daniel Dunbar <daniel_dunbar at apple.com>,
> LLVM
> Developers Mailing List <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] [cfe-dev] RFC: put commit messages in *-commits
> subject lines?
> Message-ID:
> <
> CADiQthOGj+v42gGovfjES5Y_bSy-VGp_bkzhqw2pgnLgYiSJoQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 2013/1/26 Daniel Dunbar <daniel at zuster.org>:
> > Ok, this is done and seems to work.
>
> Cool!
>
> > As far as Chris's request for getting "key directory" paths into the
> commit
> > message, I thought about working on it, but in the end I'm not sure why
> we
> > shouldn't just encourage people to self-tag their leading commit line
> with
> > some sort of standard key ([MC], [Target/Mips], whatever).
>
> +1. At least for now, I think it might be redundant to add "key
> directories".
> We may watch on how better this change would have been.
>
> ...Takumi
>
>
> ------------------------------
>
> Message: 7
> Date: Sat, 26 Jan 2013 01:00:13 +0100
> From: Tobias Grosser <tobias at grosser.es>
> To: Daniel Dunbar <daniel at zuster.org>
> Cc: Sebastian Pop <spop at codeaurora.org>, "cfe-dev at cs.uiuc.edu
> Developers" <cfe-dev at cs.uiuc.edu>, Daniel Dunbar
> <daniel_dunbar at apple.com>, LLVM Developers Mailing List
> <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] [cfe-dev] RFC: put commit messages in *-commits
> subject lines?
> Message-ID: <51031C8D.6090005 at grosser.es>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 01/26/2013 12:15 AM, Daniel Dunbar wrote:
> > Ok, this is done and seems to work.
> >
> > As far as Chris's request for getting "key directory" paths into the
> > commit message, I thought about working on it, but in the end I'm not
> > sure why we shouldn't just encourage people to self-tag their leading
> > commit line with some sort of standard key ([MC], [Target/Mips],
> whatever).
>
> Very nice.
>
> While at that, who can get rid of the [llvm],[cfe-commits], ...
> prefixes? I remember we agreed they just cost screen real estate.
>
> Tobi
>
>
>
> ------------------------------
>
> Message: 8
> Date: Fri, 25 Jan 2013 16:07:42 -0800
> From: Daniel Dunbar <daniel at zuster.org>
> To: Tanya Lattner <tonic at nondot.org>, Chris Lattner
> <sabre at nondot.org>, John Criswell <criswell at illinois.edu>
> Cc: Sebastian Pop <spop at codeaurora.org>, "cfe-dev at cs.uiuc.edu
> Developers" <cfe-dev at cs.uiuc.edu>, Daniel Dunbar
> <daniel_dunbar at apple.com>, LLVM Developers Mailing List
> <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] [cfe-dev] RFC: put commit messages in *-commits
> subject lines?
> Message-ID:
> <CAEU8z680rOiCMAEt_Z+QTxwCcxsk5Fm8=
> 10+_C0s2pOQhuXzWg at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Fri, Jan 25, 2013 at 4:00 PM, Tobias Grosser <tobias at grosser.es> wrote:
>
> > On 01/26/2013 12:15 AM, Daniel Dunbar wrote:
> >
> >> Ok, this is done and seems to work.
> >>
> >> As far as Chris's request for getting "key directory" paths into the
> >> commit message, I thought about working on it, but in the end I'm not
> >> sure why we shouldn't just encourage people to self-tag their leading
> >> commit line with some sort of standard key ([MC], [Target/Mips],
> >> whatever).
> >>
> >
> > Very nice.
> >
> > While at that, who can get rid of the [llvm],[cfe-commits], ... prefixes?
> > I remember we agreed they just cost screen real estate.
> >
>
> That needs to be done by someone with admin access to the mailing lists,
> Chris, Tanya, John C., not sure who else?
>
> - Daniel
>
>
> >
> > Tobi
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20130125/8c4039fe/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 9
> Date: Fri, 25 Jan 2013 16:28:29 -0800
> From: Eli Bendersky <eliben at google.com>
> To: Daniel Dunbar <daniel at zuster.org>
> Cc: Daniel Dunbar <daniel_dunbar at apple.com>, Sebastian Pop
> <spop at codeaurora.org>, Chris Lattner <sabre at nondot.org>,
> LLVM
> Developers Mailing List <llvmdev at cs.uiuc.edu>, Tanya Lattner
> <tonic at nondot.org>, "cfe-dev at cs.uiuc.edu Developers"
> <cfe-dev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] [cfe-dev] RFC: put commit messages in *-commits
> subject lines?
> Message-ID:
> <
> CACLQwhFTtZa4_KRX0eFwDM6TVmZoLbfQYWBfuBiqAe8irQQZOw at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Fri, Jan 25, 2013 at 4:07 PM, Daniel Dunbar <daniel at zuster.org> wrote:
> >
> >
> >
> > On Fri, Jan 25, 2013 at 4:00 PM, Tobias Grosser <tobias at grosser.es>
> wrote:
> >>
> >> On 01/26/2013 12:15 AM, Daniel Dunbar wrote:
> >>>
> >>> Ok, this is done and seems to work.
> >>>
> >>> As far as Chris's request for getting "key directory" paths into the
> >>> commit message, I thought about working on it, but in the end I'm not
> >>> sure why we shouldn't just encourage people to self-tag their leading
> >>> commit line with some sort of standard key ([MC], [Target/Mips],
> >>> whatever).
> >>
> >>
> >> Very nice.
> >>
> >> While at that, who can get rid of the [llvm],[cfe-commits], ...
> prefixes?
> >> I remember we agreed they just cost screen real estate.
> >
>
> Careful here, these may be used to set up filters in mail clients, and
> an alternative has to be provided.
>
> For instance, I have a filter that sends all [compiler-rt] related
> mail to its own folder, which is quite important for me.
>
> Eli
>
>
> ------------------------------
>
> Message: 10
> Date: Fri, 25 Jan 2013 16:37:37 -0800
> From: David Blaikie <dblaikie at gmail.com>
> To: Eli Bendersky <eliben at google.com>
> Cc: Daniel Dunbar <daniel_dunbar at apple.com>, Sebastian Pop
> <spop at codeaurora.org>, Chris Lattner <sabre at nondot.org>,
> Tanya Lattner
> <tonic at nondot.org>, "cfe-dev at cs.uiuc.edu Developers"
> <cfe-dev at cs.uiuc.edu>, LLVM Developers Mailing List
> <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] [cfe-dev] RFC: put commit messages in *-commits
> subject lines?
> Message-ID:
> <
> CAENS6EtGL6o3wUV2zcUkge_vzX2zgahOsQWDLKJ5HWFuLJG5vw at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Fri, Jan 25, 2013 at 4:28 PM, Eli Bendersky <eliben at google.com> wrote:
> > On Fri, Jan 25, 2013 at 4:07 PM, Daniel Dunbar <daniel at zuster.org>
> wrote:
> >>
> >>
> >>
> >> On Fri, Jan 25, 2013 at 4:00 PM, Tobias Grosser <tobias at grosser.es>
> wrote:
> >>>
> >>> On 01/26/2013 12:15 AM, Daniel Dunbar wrote:
> >>>>
> >>>> Ok, this is done and seems to work.
> >>>>
> >>>> As far as Chris's request for getting "key directory" paths into the
> >>>> commit message, I thought about working on it, but in the end I'm not
> >>>> sure why we shouldn't just encourage people to self-tag their leading
> >>>> commit line with some sort of standard key ([MC], [Target/Mips],
> >>>> whatever).
> >>>
> >>>
> >>> Very nice.
> >>>
> >>> While at that, who can get rid of the [llvm],[cfe-commits], ...
> prefixes?
> >>> I remember we agreed they just cost screen real estate.
> >>
> >
> > Careful here, these may be used to set up filters in mail clients, and
> > an alternative has to be provided.
>
> Agreed.
>
> > For instance, I have a filter that sends all [compiler-rt] related
> > mail to its own folder, which is quite important for me.
>
> the [compiler-rt] prefix is for the specific repository, rather than
> the mailing list - that would remain (it's part of the svn mail
> sending process), but the mailing list prefix is a property of the
> mailing list software overall, which is what's going to (potentially)
> be removed.
>
> That being said, even though I (& probably most gmail users) have
> mailing list rules setup based on list headers rather than subject
> prefixes, like you, I wouldn't be sure that everyone has this setup or
> that it's convenient for everyone to do so.
>
> I'd like this change, I'm just not sure how to evaluate whether it's
> correct (short of changing it seeing how many people complain/how many
> of them cannot be helped/fixed)
>
>
> ------------------------------
>
> Message: 11
> Date: Fri, 25 Jan 2013 16:41:53 -0800
> From: Eli Bendersky <eliben at google.com>
> To: David Blaikie <dblaikie at gmail.com>
> Cc: Daniel Dunbar <daniel_dunbar at apple.com>, Sebastian Pop
> <spop at codeaurora.org>, Chris Lattner <sabre at nondot.org>,
> Tanya Lattner
> <tonic at nondot.org>, "cfe-dev at cs.uiuc.edu Developers"
> <cfe-dev at cs.uiuc.edu>, LLVM Developers Mailing List
> <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] [cfe-dev] RFC: put commit messages in *-commits
> subject lines?
> Message-ID:
> <CACLQwhFmq=QJuRSyPxWE6e=eCTmRL4tWhYyz=
> 3aYXbdCoYsHkg at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Fri, Jan 25, 2013 at 4:37 PM, David Blaikie <dblaikie at gmail.com> wrote:
> > On Fri, Jan 25, 2013 at 4:28 PM, Eli Bendersky <eliben at google.com>
> wrote:
> >> On Fri, Jan 25, 2013 at 4:07 PM, Daniel Dunbar <daniel at zuster.org>
> wrote:
> >>>
> >>>
> >>>
> >>> On Fri, Jan 25, 2013 at 4:00 PM, Tobias Grosser <tobias at grosser.es>
> wrote:
> >>>>
> >>>> On 01/26/2013 12:15 AM, Daniel Dunbar wrote:
> >>>>>
> >>>>> Ok, this is done and seems to work.
> >>>>>
> >>>>> As far as Chris's request for getting "key directory" paths into the
> >>>>> commit message, I thought about working on it, but in the end I'm not
> >>>>> sure why we shouldn't just encourage people to self-tag their leading
> >>>>> commit line with some sort of standard key ([MC], [Target/Mips],
> >>>>> whatever).
> >>>>
> >>>>
> >>>> Very nice.
> >>>>
> >>>> While at that, who can get rid of the [llvm],[cfe-commits], ...
> prefixes?
> >>>> I remember we agreed they just cost screen real estate.
> >>>
> >>
> >> Careful here, these may be used to set up filters in mail clients, and
> >> an alternative has to be provided.
> >
> > Agreed.
> >
> >> For instance, I have a filter that sends all [compiler-rt] related
> >> mail to its own folder, which is quite important for me.
> >
> > the [compiler-rt] prefix is for the specific repository, rather than
> > the mailing list - that would remain (it's part of the svn mail
> > sending process), but the mailing list prefix is a property of the
> > mailing list software overall, which is what's going to (potentially)
> > be removed.
> >
>
> OK, I see.
>
> > That being said, even though I (& probably most gmail users) have
> > mailing list rules setup based on list headers rather than subject
> > prefixes, like you, I wouldn't be sure that everyone has this setup or
> > that it's convenient for everyone to do so.
> >
> > I'd like this change, I'm just not sure how to evaluate whether it's
> > correct (short of changing it seeing how many people complain/how many
> > of them cannot be helped/fixed)
>
> I guess that the need can be summarized to:
>
> - If email comes from separate email addresses (or "to" separate
> addresses), further specification in the subject is superfluous and
> can be nuked.
> - If email is otherwise indistinguishable but comes from different
> sub-projects, some specification in the subject has to be retained to
> allow effective mailbox management.
>
> What am I missing?
>
> Eli
>
>
> ------------------------------
>
> Message: 12
> Date: Sat, 26 Jan 2013 13:16:57 +0000
> From: Renato Golin <renato.golin at linaro.org>
> To: Nadav Rotem <nrotem at apple.com>
> Cc: LLVM Dev <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] TargetLowering vs. TargetTransform
> Message-ID:
> <CAMSE1kf=
> FD8rRu9gj3FNe1esiuXWjdiZf5AXSYovfTWuGUgGSA at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On 25 January 2013 23:03, Nadav Rotem <nrotem at apple.com> wrote:
>
> > Yes. This is a limitation of the current API. The design decision behind
> > it was that in many cases you want to know the cost of IR before you
> > generate it.
> >
>
> That makes sense.
>
>
> Also, we wanted to rely on tables as much as possible. We did not want to
> > write code to resemble ISel in order to estimate the cost. Is this
> > something that we can live with ?
> >
>
> It depends on the final design intentions. If these costs are only ever
> going to be used by the vectorization, or if other optimizations are going
> to start using TargetTransformInfo for cost information, than yes, it makes
> sense to begin focusing cost models on TTI. But if other passes call TL
> directly, then we might re-think the strategy.
>
> It looks to me that only lowering would need to call TL's costs, since they
> can be different than a more high level cost, and possibly assume that the
> code is already valid and checked, which is not the case for most
> transformations, including the vectorization. I think this is more or less
> what you were saying before.
>
> I'll give it a few tries and send to the list so we can discuss with more
> concrete implementations.
>
> cheers,
> --renato
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20130126/db160fb4/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 13
> Date: Sat, 26 Jan 2013 15:22:45 +0100
> From: Tobias Grosser <tobias at grosser.es>
> To: Eli Bendersky <eliben at google.com>
> Cc: Daniel Dunbar <daniel_dunbar at apple.com>, Sebastian Pop
> <spop at codeaurora.org>, Chris Lattner <sabre at nondot.org>,
> Tanya Lattner
> <tonic at nondot.org>, LLVM Developers Mailing List
> <llvmdev at cs.uiuc.edu>, "cfe-dev at cs.uiuc.edu Developers"
> <cfe-dev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] [cfe-dev] RFC: put commit messages in *-commits
> subject lines?
> Message-ID: <5103E6B5.2060807 at grosser.es>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 01/26/2013 01:41 AM, Eli Bendersky wrote:
> > On Fri, Jan 25, 2013 at 4:37 PM, David Blaikie <dblaikie at gmail.com>
> wrote:
> >> On Fri, Jan 25, 2013 at 4:28 PM, Eli Bendersky <eliben at google.com>
> wrote:
> >>> On Fri, Jan 25, 2013 at 4:07 PM, Daniel Dunbar <daniel at zuster.org>
> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On Fri, Jan 25, 2013 at 4:00 PM, Tobias Grosser <tobias at grosser.es>
> wrote:
> >>>>>
> >>>>> On 01/26/2013 12:15 AM, Daniel Dunbar wrote:
> >>>>>>
> >>>>>> Ok, this is done and seems to work.
> >>>>>>
> >>>>>> As far as Chris's request for getting "key directory" paths into the
> >>>>>> commit message, I thought about working on it, but in the end I'm
> not
> >>>>>> sure why we shouldn't just encourage people to self-tag their
> leading
> >>>>>> commit line with some sort of standard key ([MC], [Target/Mips],
> >>>>>> whatever).
> >>>>>
> >>>>>
> >>>>> Very nice.
> >>>>>
> >>>>> While at that, who can get rid of the [llvm],[cfe-commits], ...
> prefixes?
> >>>>> I remember we agreed they just cost screen real estate.
> >>>>
> >>>
> >>> Careful here, these may be used to set up filters in mail clients, and
> >>> an alternative has to be provided.
> >>
> >> Agreed.
> >>
> >>> For instance, I have a filter that sends all [compiler-rt] related
> >>> mail to its own folder, which is quite important for me.
> >>
> >> the [compiler-rt] prefix is for the specific repository, rather than
> >> the mailing list - that would remain (it's part of the svn mail
> >> sending process), but the mailing list prefix is a property of the
> >> mailing list software overall, which is what's going to (potentially)
> >> be removed.
> >>
> >
> > OK, I see.
> >
> >> That being said, even though I (& probably most gmail users) have
> >> mailing list rules setup based on list headers rather than subject
> >> prefixes, like you, I wouldn't be sure that everyone has this setup or
> >> that it's convenient for everyone to do so.
> >>
> >> I'd like this change, I'm just not sure how to evaluate whether it's
> >> correct (short of changing it seeing how many people complain/how many
> >> of them cannot be helped/fixed)
> >
> > I guess that the need can be summarized to:
> >
> > - If email comes from separate email addresses (or "to" separate
> > addresses), further specification in the subject is superfluous and
> > can be nuked.
> > - If email is otherwise indistinguishable but comes from different
> > sub-projects, some specification in the subject has to be retained to
> > allow effective mailbox management.
> >
> > What am I missing?
>
> I don't see anything missing.
>
> I asked to remove the list name from the subject, as it is already
> provided in the "List-Id" header of all mailing list emails and is
> consequently redundant. The different svn sub-projects are useful and I
> don't think we should remove this information.
>
> Chris replied to that request earlier (15. Nov):
>
> > I agree that the list name is redundant and should be dropped, but
> > the revision number is compact and very useful...
> >
> > -Chris
>
> If we agreed to perform this change and we found the person who can
> change it, we can probably give a heads-up a couple of days before to
> see if anybody will have major issues.
>
> Cheers,
> Tobi
>
>
>
>
> ------------------------------
>
> Message: 14
> Date: Sat, 26 Jan 2013 17:47:03 +0100
> From: Duncan Sands <baldrick at free.fr>
> To: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] Testing canaries
> Message-ID: <51040887.90309 at free.fr>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi Izabela,
>
> On 21/01/13 18:37, Izabela Maffra wrote:
> > Dear LLVMers,
> >
> > I am trying to measure the performance overhead (if any) of the
> canaries
> > that clang inserts in the code. I would like to do this automatically,
> using the
> > LLVM test infra-structure. However, I am not sure if that is possible.
> Could
> > someone tell me which flags in the TEST.nightly.Makefile script, (or any
> other
> > script) I must change to have this done? Usually I insert canaries with
> the
> > following command line:
> >
> > $> clang -S -fstack-protector hello.c
> >
> > But I would like to know which part of LLVM calls the pass that inserts
> the
> > canaries. It seems it is llc, as the pass that inserts the canaries is in
> > /lib/CodeGen/StackProtector.cpp. Yet, I cannot see 'fstack-protector' in
> the llc
> > --help list, although I can see 'stack-protector-buffer-size' in llc
> --help.
>
> the -fstack-protector option is processed by the clang front-end. If you
> grep
> for stack-protector in the clang source, you will discover that the action
> is
> happening in clang/lib/Driver/Tools.cpp, here:
>
> if (StackProtectorLevel) {
> CmdArgs.push_back("-stack-protector");
> CmdArgs.push_back(Args.MakeArgString(Twine(StackProtectorLevel)));
> }
>
> The argument -stack-protector is for the code generators, and you should
> find
> that llc has the same argument. However if you look for it it doesn't
> seem to
> exist:
>
> $ llc -help | grep stack-protector
> -stack-protector-buffer-size=<uint> - Lower bound for a buffer to be
> considered for stack protection
>
> What is going on? Some options aren't considered generally useful and are
> hidden. If you use -help-hidden you get to see all options:
>
> $ llc -help-hidden | grep stack-protector
> =stack-protector - Insert stack protectors
> =stack-protector - Insert stack protectors
> -stack-protector-buffer-size=<uint> - Lower bound for a buffer to be
> considered for stack protection
>
> There it is! It's not clear to me why -stack-protector is hidden away like
> that. Hidden options work just the same as visible options: just pass
> -stack-protector to llc.
>
> Ciao, Duncan.
>
>
> ------------------------------
>
> Message: 15
> Date: Sat, 26 Jan 2013 09:49:35 -0800
> From: David Blaikie <dblaikie at gmail.com>
> To: Tobias Grosser <tobias at grosser.es>
> Cc: Daniel Dunbar <daniel_dunbar at apple.com>, Sebastian Pop
> <spop at codeaurora.org>, Chris Lattner <sabre at nondot.org>,
> Tanya Lattner
> <tonic at nondot.org>, LLVM Developers Mailing List
> <llvmdev at cs.uiuc.edu>, "cfe-dev at cs.uiuc.edu Developers"
> <cfe-dev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] [cfe-dev] RFC: put commit messages in *-commits
> subject lines?
> Message-ID:
> <CAENS6Ev1g=qzp=+
> Vk4JJuiwiBUB8vTL_yd7M6eHzWJc76Rfe9g at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Sat, Jan 26, 2013 at 6:22 AM, Tobias Grosser <tobias at grosser.es> wrote:
> > On 01/26/2013 01:41 AM, Eli Bendersky wrote:
> >>
> >> On Fri, Jan 25, 2013 at 4:37 PM, David Blaikie <dblaikie at gmail.com>
> wrote:
> >>>
> >>> On Fri, Jan 25, 2013 at 4:28 PM, Eli Bendersky <eliben at google.com>
> wrote:
> >>>>
> >>>> On Fri, Jan 25, 2013 at 4:07 PM, Daniel Dunbar <daniel at zuster.org>
> >>>> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Fri, Jan 25, 2013 at 4:00 PM, Tobias Grosser <tobias at grosser.es>
> >>>>> wrote:
> >>>>>>
> >>>>>>
> >>>>>> On 01/26/2013 12:15 AM, Daniel Dunbar wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> Ok, this is done and seems to work.
> >>>>>>>
> >>>>>>> As far as Chris's request for getting "key directory" paths into
> the
> >>>>>>> commit message, I thought about working on it, but in the end I'm
> not
> >>>>>>> sure why we shouldn't just encourage people to self-tag their
> leading
> >>>>>>> commit line with some sort of standard key ([MC], [Target/Mips],
> >>>>>>> whatever).
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Very nice.
> >>>>>>
> >>>>>> While at that, who can get rid of the [llvm],[cfe-commits], ...
> >>>>>> prefixes?
> >>>>>> I remember we agreed they just cost screen real estate.
> >>>>>
> >>>>>
> >>>>
> >>>> Careful here, these may be used to set up filters in mail clients, and
> >>>> an alternative has to be provided.
> >>>
> >>>
> >>> Agreed.
> >>>
> >>>> For instance, I have a filter that sends all [compiler-rt] related
> >>>> mail to its own folder, which is quite important for me.
> >>>
> >>>
> >>> the [compiler-rt] prefix is for the specific repository, rather than
> >>> the mailing list - that would remain (it's part of the svn mail
> >>> sending process), but the mailing list prefix is a property of the
> >>> mailing list software overall, which is what's going to (potentially)
> >>> be removed.
> >>>
> >>
> >> OK, I see.
> >>
> >>> That being said, even though I (& probably most gmail users) have
> >>> mailing list rules setup based on list headers rather than subject
> >>> prefixes, like you, I wouldn't be sure that everyone has this setup or
> >>> that it's convenient for everyone to do so.
> >>>
> >>> I'd like this change, I'm just not sure how to evaluate whether it's
> >>> correct (short of changing it seeing how many people complain/how many
> >>> of them cannot be helped/fixed)
> >>
> >>
> >> I guess that the need can be summarized to:
> >>
> >> - If email comes from separate email addresses (or "to" separate
> >> addresses), further specification in the subject is superfluous and
> >> can be nuked.
> >> - If email is otherwise indistinguishable but comes from different
> >> sub-projects, some specification in the subject has to be retained to
> >> allow effective mailbox management.
> >>
> >> What am I missing?
> >
> >
> > I don't see anything missing.
> >
> > I asked to remove the list name from the subject, as it is already
> provided
> > in the "List-Id" header of all mailing list emails and is consequently
> > redundant. The different svn sub-projects are useful and I don't think we
> > should remove this information.
> >
> > Chris replied to that request earlier (15. Nov):
> >
> >
> >> I agree that the list name is redundant and should be dropped, but
> >> the revision number is compact and very useful...
> >>
> >> -Chris
> >
> > If we agreed to perform this change and we found the person who can
> change
> > it, we can probably give a heads-up a couple of days before to see if
> > anybody will have major issues.
>
> SGTM - thanks for the recap/quotation. (but, yes, I'm not the person
> who can change that - hopefully Tanya or one of the other admins will
> speak up with details)
>
>
> ------------------------------
>
> Message: 16
> Date: Sat, 26 Jan 2013 18:55:37 +0100
> From: "sara.elshobaky" <sara.elshobaky at laposte.net>
> To: LLVMdev at cs.uiuc.edu
> Cc: sara.elshobaky at gmail.com
> Subject: [LLVMdev] lli problem with a simple OpenGL
> Message-ID: <1500165980.71560.1359222937641.JavaMail.www at wwinf8316>
> Content-Type: text/plain; charset="utf-8"
>
> ?Hello,
>
> I wrote a very simple openGL application, as below
>
> #include
> #include
> int main(int argc, char **argv)
> {
> ? glutInit(&argc, argv);
> ? glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGB | GLUT_DEPTH);
> ? glutCreateWindow("red 3D lighted cube");
> ? printf("GL_VERSION = %s\n",glGetString(GL_VERSION) );
> ? return 0;
> }
>
> Compiling it with Clang and adding -lglut option worked correctly
> $ clang? simple.c? -o? simple? -lglut
> $ ./simple
> GL_VERSION = 2.1 Mesa 7.10.2
>
> But, adding the -emit-llvm option to clang, does not work as below
> $ clang -O3 -emit-llvm simple.c? -o simple.bc -lglut
> /usr/bin/ld: /usr/local/bin/../lib/LLVMgold.so: error loading plugin
> /usr/bin/ld: /usr/local/bin/../lib/LLVMgold.so: error in plugin cleanup
> (ignored)
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
> Also, removing the -lglut option worked with clang but failed with lli as
> below
> $ clang -O3 -emit-llvm simple.c -c -o simple.bc
> $ lli simple.bc
> LLVM ERROR: Program used external function 'glutInit' which could not be
> resolved!
>
> Please advice how to run it using the llvm jit 'lli'
>
> Thanks in advance
> Sara
>
>
>
> Une messagerie gratuite, garantie ? vie et des services en plus, ?a vous
> tente ?
> Je cr?e ma bo?te mail www.laposte.net
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20130126/71730723/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> LLVMdev mailing list
> LLVMdev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> End of LLVMdev Digest, Vol 103, Issue 72
> ****************************************
>
--
Izabela Maffra.
*Ciência da Computação
Universidade Federal de Minas Gerais
(31) 8615-3077*
"Don't count the days, make the days count." -- Muhammad Ali
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130128/1e97b9d2/attachment.html>
More information about the llvm-dev
mailing list