search for: renato

On 3 August 2016 at 10:46, Renato Golin <renato.golin at linaro.org> wrote: > We certainly do. This is a big deal. I'll write up something and let > Dmitry correct my mistakes. :) Done. > We'll also add the ARM/AArch64 changelogs. Done. :) cheers, --renato

...SVN r213684): http://reviews.llvm.org/D4614 But it seems to build fine on my machine... I don't know enough about CMake to tell, but that seemed to be a bug/feature in CMake to which needed the work-around. Now, just looks like the work-around is broken. Should I revert the patch? cheers, --renato

Ping? This is getting as often as every other run... Is that process downloading from an internal server? If not, should we? If yes, should we not? thanks, --renato On 20 April 2013 14:03, Renato Golin <renato.golin at linaro.org> wrote: > Hi folks, > > I noticed our test-suite bot is failing randomly when getting a timeout on > the install phase: > > > http://lab.llvm.org:8011/builders/clang-native-arm-lnt/builds/666/steps/venv.l...

Renato, When I tried running "opcontrol --start" (after previously running "opcontrol --start-daemon") in dom0, I get this error message: /usr/local/bin/opcontrol: line 1639: echo: write error: Operation not permitted and this message in the Xen console: (XEN) xenoprof: operation 9...

Renato, When I tried running "opcontrol --start" (after previously running "opcontrol --start-daemon") in dom0, I get this error message: /usr/local/bin/opcontrol: line 1639: echo: write error: Operation not permitted and this message in the Xen console: (XEN) xenoprof: operation 9...

We just wanted to check to see if they are real bugs first. We will report them if they are not already fixed. Thanks. Del From: Renato Golin [mailto:renato.golin at linaro.org] Sent: Wednesday, July 6, 2016 12:07 AM To: Del Myers <delmyers at microsoft.com> Cc: LLVM Dev <llvm-dev at lists.llvm.org> Subject: RE: [llvm-dev] llvm 3.8.1 Release Did you report the bugs? It would be a lot easier to know if those were in bu...

I can. I've removed every other compilation flags from clang and even used GCC, with the exact same behaviour. cheers, --renato On 29 July 2014 15:15, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: > OK, we can switch to SIGHUP. Could you please verify that this SIGUSR1 > behavior is not caused by MSan? > > On Tue, Jul 29, 2014 at 6:09 PM, Renato Golin <renato.golin at linaro.org> wrote: &gt...

...-1.2.1-py2.7.egg/pip/download.py", line 380, in _download_url chunk = resp.read(4096) (...) timeout: timed out The package getting time out is not always the same, sometimes it also happens with SQLAlchemy. I'm guessing the server is loaded or the connection is somehow bad? cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130420/a2063ce0/attachment.html>

OK, so, if I understand, the tag is at 3.8.1, but there is no source drop available for download? Del From: Renato Golin [mailto:renato.golin at linaro.org] Sent: Tuesday, July 5, 2016 4:12 PM To: Del Myers <delmyers at microsoft.com> Cc: LLVM Dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] llvm 3.8.1 Release Hi Del, Yes, the tag is for the latest stable release. It's a bit confusing...

Right! Can you add a comment to the document review? The other two hooks were good (email, update umbrella), so I think we're set. Cheers, Renato On 20 Jul 2016 12:48 a.m., "Chandler Carruth" <chandlerc at google.com> wrote: > I have already tested protected branches on GitHub successfully and found > it allowed exactly the pushes that were correct -- they must all have the > current HEAD as an ancestor, and so the...

...;s ran as "not chained_origin_with_signals.cc.tmp", expecting it to fail. Also, the FileCheck expects to find warnings on the output, for which there is none Maybe I'm missing some CMake flag or library, and that's why the signal functionality is not working on my box? cheers, --renato On 25 July 2014 09:39, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: > Hi, > > is it still an issue? > Just by looking at the code, I don't see why it could fail. Do you > need any help debugging it? > > On Wed, Jul 23, 2014 at 1:15 AM, Renato Golin <rena...

...to support safelen() and even the simd construct itself, LLVM will require infrastructure work to know when a lexically backwards dependence may have been introduced. Jon -----Original Message----- From: Tian, Xinmin [mailto:xinmin.tian at intel.com] Sent: Monday, September 29, 2014 10:43 AM To: Renato Golin; Hal Finkel Cc: Humphreys, Jonathan; Robison, Arch; LLVM Dev Subject: RE: [LLVMdev] Proposal for ""llvm.mem.vectorize.safelen" Renato, I think Hal meant to ensure partial ordering, e.g. not to convert lexical forward data dep to lexical backward data dep due to statement order...

...il with __aeabi_* symbols missing). Most problems should be all fixed once we reload the configuration in the build master. Right now, there's only one failure remaining, which I'm investigating. backtrace_test.cpp:59: int main(): Assertion `nothrow_ntraced > 1' failed. cheers, --renato

...gt; wrote: > Could it be that I'm misunderstanding signal semantics, and SIGUSR1 is > not guaranteed to be delivered (to the same process!) before kill() > returns? Could you check if that's what happens by adding a sleep() > somewhere? > > On Tue, Jul 29, 2014 at 2:17 AM, Renato Golin <renato.golin at linaro.org> wrote: >> Hi Evgeniy, >> >> Yes, it is. The problem here is that the program doesn't fail on my >> box (release and debug builds), so I have no idea how to debug the >> problem. According to the test, it's ran as "n...

...nd "armv3" to have an "ARM v4" tag, which is wrong. I know GCC does that, but I don't think we should. Given that this will probably never happen in LLVM, I think we can safely take the correct approach and ignore GCC. Any other reason why you added those tests? cheers, --renato

On 26 August 2016 at 23:22, Renato Golin <renato.golin at linaro.org> wrote: > Woot! Compiling RT as we speak... :) Right, all went well until I got this: [0/1] Re-running CMake... -- Builtin supported architectures: i386;x86_64 -- Configuring done -- Generating done -- Build files have been written to: /home/rengolin/dev...

On 19 February 2015 at 13:57, Renato Golin <renato.golin at linaro.org> wrote: > test/CodeGen/R600/Output/infinite-loop-evergreen.ll > > Is actually in an infinite loop on AArch64... This is RC4 Phase3. I > didn't see that on RC3. Well, I spoke too early. Apparently the test finished after 8 minutes running... I...

On Sat, Dec 20, 2014 at 2:00 AM, Renato Golin <renato.golin at linaro.org> wrote: > > On 19 December 2014 at 17:29, Daniel Sanders <Daniel.Sanders at imgtec.com> > wrote: > > My understanding was the other way around. The tests timeout but they > shouldn't. However, re-reading the original email I see th...

Hi Renato, We're also seeing this on internal bots. My first guess is that it was triggered by the Flask package getting updated at Pypi on 29th of May, see https://pypi.python.org/pypi/Flask. I haven't investigated further at this point. Thanks, Kristof On 29 May 2016, at 14:28, Renato Golin &l...

...org:8011/builders/clang-cmake-aarch64-full/builds/2208 http://lab.llvm.org:8011/builders/clang-native-arm-lnt/builds/18012 http://lab.llvm.org:8011/builders/clang-ppc64be-linux-lnt/builds/4347 http://lab.llvm.org:8011/builders/clang-ppc64le-linux-lnt/builds/2042 Any one has any idea? cheers, --renato