search for: renatos

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

The following bot is broken: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/4016 because of the following change (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

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: > > >

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 failed for dom 0 (status : -1) It looks like opcontrol is trying to do this: echo 1 >

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 failed for dom 0 (status : -1) It looks like opcontrol is trying to do this: echo 1 >

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

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

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.lnt.install/logs/stdio Downloading/unpacking Werkzeug>=0.6.1 (from Flask->LNT==0.4.1dev) Exception: File

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

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

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 "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

Yes, I think the 2 outcomes are: - the current spec is unclear and will be clarified - in order 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:

Hi folks, I've updated the configuration for my libcxx buildbot (r220701) to pass some additional flags to compilation, including setting the CPU (so it won't need to use soft divide) and link flags + compiler-rt dependency to lit (so it won't fail with __aeabi_* symbols missing). Most problems should be all fixed once we reload the configuration in the build master. Right now,

Yup, using SIGHUP works. On 29 July 2014 13:14, Evgeniy Stepanov <eugeni.stepanov at gmail.com> 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,

Hi Logan, There are some tests in the MC/ARM directory that seem suspicious: directive-arch-armv{2,3}.s They expect "armv2" and "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

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/devel/llvm/workdir/libs/build/runtimes/builtins-bins ninja: no work

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... Is that expected? 8 minutes is longer than it takes to run the

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 that my mind > inserted a word that isn't there. >

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 <renato.golin at linaro.org<mailto:renato.golin at linaro.org>> wrote: Folks,

Folks, Its seems that the latest master restart has introduced a failure in *many* test-suite bots: File "/home/buildslave/buildslave/clang-cmake-aarch64-full/test/lnt/lnt/server/ui/decorators.py", line 6, in <module> frontend = flask.Module(__name__) AttributeError: 'module' object has no attribute 'Module'