similar to: [LLVMdev] Debugging atom builds?

On 3 April 2013 14:59, Timur Iskhodzhanov <timurrrr at google.com> wrote: > I'd usually expect tests to work exactly the same way on all platforms. > If there are things that must be handled differently on different > platforms, I'd expect those to have a separate test for each platform > with explicit flags for each of these platforms. > You're absolutely right,

Hi LLVM Dev, One of my recent commits has broken build on Ubuntu Atom D2700. 2013/4/3 <llvm.buildmaster at lab.llvm.org>: > The Buildbot has detected a new failure on builder clang-atom-d2700-ubuntu-rel while building llvm. > Full details are available at: > http://lab.llvm.org:8011/builders/clang-atom-d2700-ubuntu-rel/builds/7852 > > Buildbot URL:

Hi Brian, The Atom1-buildbot buildslave has been failing for a few days but I don't think the problem lies in the LLVM/Clang source. From the logs at http://lab.llvm.org:8011/builders/clang-atom-d2700-ubuntu-rel/builds/13632 (and newer builds): ******************** TEST 'Clang :: Driver/x86_features.s' FAILED ******************** Test has no run line!

Hi. As per[1], gcc-4.8 is the oldest supported *major* gcc version. But what about minor/patch versions? When https://reviews.llvm.org/D43779 was initially committed, a few[2][3] buildbots failed. As i have now looked into the issue: * but it is *REPRODUCIBLE* with gcc-4.8.4 and gcc-4.9.2 from debian oldstable (Jessie). * it is *NOT* reproducible with gcc-4.8.5 and gcc-4.9.3 from ubuntu 16.04,

On Wed, Mar 20, 2013 at 5:21 PM, Timur Iskhodzhanov <timurrrr at google.com>wrote: > 2013/3/20 Timur Iskhodzhanov <timurrrr at google.com>: > > Anton, > > > > [+Eric, Nick, > > the e-mail thread context has been broken a few times, so you should > > probably look at the llvmdev archives. > > It all starts here: > >

Hi, My New Year's resolution is to complain (constructively) whenever I get a spurious build failure email from a buildbot. For new or infrequent contributors especially, they can be extremely confusing and unnecessarily alarming. This one below is the first build ever attempted by the builder, so how on earth can it have come up with a meaningful blame list? And in any case, surely we

On Thu, Oct 23, 2014 at 2:46 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > 2014-10-23 11:34 GMT-07:00 Aaron Ballman <aaron at aaronballman.com>: >> On Thu, Oct 23, 2014 at 2:24 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: >>> I don't think this is the right approach. >>> >>> Currently we intentionally define malloc etc

On Tue, Oct 2, 2012 at 11:02 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > On Tue, Oct 2, 2012 at 8:28 PM, David Blaikie <dblaikie at gmail.com> wrote: >> On Tue, Oct 2, 2012 at 8:54 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote: >>> [+cfe-dev as this does seem like both LLVM+Clang issue] >>> [Sorry for an incomplete e-mail context,

On Thu, Oct 23, 2014 at 2:24 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > I don't think this is the right approach. > > Currently we intentionally define malloc etc without changing the > names and (when stuff works ok) the linker just links all the mem > allocator calls with calls to our RTL. This is kind of a link-time > interception. How could that work

Attached is a slightly updated patch. (it doesn't include D2222 yet). 2013/11/19 Eric Christopher <echristo at gmail.com>: > In general I do think we're going to need to abstract it out as much > as possible. I'm not sure what the previous patch looks like, but > abstracting the interface out would be general goodness for this. We > can talk about designs for that as

http://llvm.org/bugs/show_bug.cgi?id=21241 ? 2014-10-23 10:18 GMT-07:00 Aaron Ballman <aaron at aaronballman.com>: > On Thu, Oct 23, 2014 at 1:15 PM, Aaron Ballman <aaron at aaronballman.com> wrote: >> On Thu, Oct 23, 2014 at 1:13 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: >>> Yes it is. >>> Are you doing a Debug or Release build?

Anton, What do you think? 2013/3/20 Eric Christopher <echristo at gmail.com>: > > > > On Wed, Mar 20, 2013 at 5:21 PM, Timur Iskhodzhanov <timurrrr at google.com> > wrote: >> >> 2013/3/20 Timur Iskhodzhanov <timurrrr at google.com>: >> > Anton, >> > >> > [+Eric, Nick, >> > the e-mail thread context has been broken a

On Tue, Oct 2, 2012 at 8:54 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > [+cfe-dev as this does seem like both LLVM+Clang issue] > [Sorry for an incomplete e-mail context, please see > http://llvm.org/PR13676#c6 if you're interested] > > I've read these bugs and now I'm even more confused than I was before :) > > What do you think about the

On Wed, Nov 20, 2013 at 9:46 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > Eric, David, > > 2013/11/19 Timur Iskhodzhanov <timurrrr at google.com>: >> Attached is a slightly updated patch. >> (it doesn't include D2222 yet). > > The new version of the patch stopped fitting into the llvmdev 100K limit, > so I've uploaded it to

I think this issue is that we were not using the INTERCEPTOR macros to define these functions. The following patch seems to work for me to get the build linking again, however, I cannot test -- when I run check-asan, I get: 2> lit.py: lit.common.cfg:59: fatal: Invalid llvm_tools_dir config attribute: 'E:/llvm/2013/$(Configuration)/bin' ~Aaron On Thu, Oct 23, 2014 at 1:20 PM, Aaron

>> > >> >> Probably the same structure that we've been going down via >> lib/DebugInfo/. A set of files than handle reading and parsing and >> both some binary files and some files produced by the backend. > > > Ooph, that's a big one. > Any more tips to prioritize diving into this codebase? > It mostly uses libObject to do the initial read

Hmm, i guess i should have mailed cfe-dev too. Doing that now. On Sun, Apr 8, 2018 at 9:38 PM, Roman Lebedev <lebedev.ri at gmail.com> wrote: > Hi. > > As per[1], gcc-4.8 is the oldest supported *major* gcc version. > But what about minor/patch versions? > > When https://reviews.llvm.org/D43779 was initially committed, > a few[2][3] buildbots failed. As i have now

Hi Timur, I myself find the name "Win32" pretty confusing and easy to misuse (especially for someone who assumes that windows == msvc). After all mingw and cygwin is also win32. Maybe we should rename it into isTargetMSVC or something like this? On Wed, Mar 27, 2013 at 6:26 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > Anton, > > What do you think? > >

Hi Timur, There's also a pending patch adding CodeView support in Phab: http://llvm-reviews.chandlerc.com/D165 Does your patch provide just a subset of the CodeView debug info provided in the other patch? Looking at the patch, I think the approach the other patch took of abstracting the emission of debug information is a bit cleaner and it will probably make life easier when adding more

Eric, David, 2013/11/19 Timur Iskhodzhanov <timurrrr at google.com>: > Attached is a slightly updated patch. > (it doesn't include D2222 yet). The new version of the patch stopped fitting into the llvmdev 100K limit, so I've uploaded it to http://llvm-reviews.chandlerc.com/D2232 (you need to apply D2222 first if you'd like to give D2232 a try) > 2013/11/19 Eric