search for: 20130114

...umber. how can do permission to this plan? and how can get stored call record in asterisk (IVR recorded voice) via php programming (AGI is better or AMI). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20130114/29ddd211/attachment.htm>

...he most readable structure is the first: minsizeopt sizeopt quickopt opt maxopt I'd like to hear some support for one or the other of these before deciding. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130114/2828bf59/attachment.html>

...corresponds to -O2 and is intended to represent a good optimization level for most cases with a balance of compile time, space, and runtime efficiency. - Kaelyn -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130114/b5c00d3f/attachment.html>

...s shown as haoweilee but not HaoweiLee as the correct one. Could any one help me to solve this? Thank you very much. Best Regards, Haowei from China. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-docs/attachments/20130114/e7f342a0/attachment-0006.html>

[This email is either empty or too large to be displayed at this time]

Chandler Carruth <chandlerc at gmail.com> writes: > minsizeopt > sizeopt > quickopt > opt > maxopt I prefer being consistent and putting "opt" at the end. I would still like something other than "opt" for the fourth one. "opt" seems too generic given the other levels. -David

...for unique_ptr<> (which is part of the built-in type traits part I believe). range-for and nullptr are unfortunately not supported with those. -- Matthieu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130114/54deb722/attachment.html>

...; behavior. Whether the compilation is LTO should be an orthogonal decision to the particular level of optimization, and we have -flto to achieve this. -Chandler -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130114/b07d9f40/attachment.html>

On Sun, Jan 13, 2013 at 2:10 PM, Matthieu Monrocq <matthieu.monrocq at gmail.com> wrote: > gcc 4.5, MSVC 10, clang 3.1 > - decltype v1.0 [1] + late specified return type > - lambda v1.0 [2] > - local types as template arguments > - r-value 2.0 [3] > - static_assert > - built-in type traits This isn't very encouraging. Anecdotally from what I've seen in LLD

...___________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130114/9c001f74/attachment.html>

...ist > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > -- Thanks, Justin Holewinski -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130114/e2c9e32a/attachment.html>

...t, that was my intent! Is there something about my proposed wording that makes you think it differs from the status quo, or would lead to differences? -Chandler -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130114/707bddc4/attachment.html>

Hi Daniel, Bill, all, Now that the Sphinx conversion is done, I'm going to move forward with the plan which was discussed in <http://thread.gmane.org/gmane.comp.compilers.llvm.cvs/115358>. The first step is going to be to inline all of the pages that are just below the current homepage (subsystems.rst, programming.rst, etc.) into the homepage, bringing back {Ctrl,Cmd}-f'ability.

...long)' We are reaching the deadline of the project but I haven't found any solution for this problem. So, please help me. Any help would be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130114/ff8e78c0/attachment.html>

Galina, it seems (at least) bbmaster works better, displayed within a few seconds. Thank you! 2013/1/14 Galina Kistanova <gkistanova at gmail.com>: > Hello everyone, > > I have migrated the buildmaster to the PostgreSQL. > All the data has been preserved and all builds are valid (none of the builds > has been affected by the migration and restart). > > I have tested and

...erformance of the image is irrelevant. Normally, the extra time is the number of breakpoints or watchpoints you have set, and not the image itself... ;) --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130114/3121fbff/attachment.html>

Renato Golin Linaro <renato.golin at linaro.org> writes: > I don't think you really need a performing debug image, though. Oh, you'd be surprised. We have hit many cases where debugging a completely unoptimized program is so slow it's not worth doing. Think about large parallel codes with millions of threads running on hundreds of thousands of sockets. Debugging even

...t it? What I meant is that there is little need for an -O3-no-reorder optimization level. Maybe in extreme cases, but I wouldn't bet on it. cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130114/4ecb11de/attachment.html>

...ist > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > -- Thanks, Justin Holewinski -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130114/4a19d962/attachment.html>

On 1/14/2013 3:09 AM, Chandler Carruth wrote: > > [...] This level should always produce > binaries at least as fast as quickopt, but they might be both slower to > compile. The "always" part cannot really be guaranteed or enforced. I'd state it in terms of intention, i.e. "this level is intended to produce binaries at least as fast as quickopt". Otherwise,