similar to: Staging buildmaster down?

Hello everyone, LLVM buildmaster will be offline on 1/13/17 hopefully for short time due for replacing network hardware. Thank you for understanding. Thanks Galina -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170112/cafe6991/attachment.html>

Hello everyone, LLVM buildmaster will be restarted today after 6 PM Pacific time today. Thanks Galina -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141126/2d94025c/attachment.html>

Hello everyone, LLVM buildmaster is up and running as lab.llvm.org:8011. Daniel Berlin is working on getting the current buildslave passwords from the old buildmaster, but this may not be possible. I'd suggest changing buildslave passwords anyway, just in case. Buildslave owners, please contact me directly with your new passwords and I'll update the master as soon as I can. Thanks

Hello everyone, LLVM buildmaster will be off-line for about 30 minutes today after 5 pm PST for maintenance. Thank you for understanding. Thanks Galina -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190620/333eb4de/attachment.html>

Hello, LLVM buildbot master will be stopped tonight for short time due to maintenance jobs. Thanks for understanding. Thanks Galina -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130121/e38ef221/attachment.html>

Hello everyone, I'm going to restart the LLVM buildmaster in about an hour or so, when the majority of the builders will be idle. Few slow builders will loose r143858 and r143861, and you will need to check the results later when new changes will be built. Sorry for this. Thanks, Galina

Hi Dylan, the following code volatile uint8_t v1; volatile uint8_t v2; __attribute__((interrupt)) void __vector_21(void) { v2 = v1; } produces in C mode: 00000092 <__vector_21>: 92: 80 91 61 00 lds r24, 0x0061 ; 0x800061 <v1> 96: 80 93 60 00 sts 0x0060, r24 ; 0x800060 <__data_end> 9a: 08 95 ret and in C++ mode: 00000074

Thanks Dylan, I am working on a backend which has mulhsu instruction that performs multiplication between signed and unsigned number and returns upper 32 bits into result register. I think I also need to write some code probably as you indicated to check signedness of the operands and based on that lower to mulhsu instruction. -Vivek On Mon, Feb 27, 2017 at 11:13 AM, Dylan McKay <me at

On Mon, Mar 16, 2020 at 10:50 AM Robinson, Paul <paul.robinson at sony.com> wrote: > SCE tuning does turn on the .debug_aranges section. Our debugger team > really cares about startup cost. Turnaround time in general is huge for our > licensees, to the point where we support edit-and-continue (minimal > rebuild, live-patch the running process). > Ah, good to know! I'd

Am 04.03.20 um 13:28 schrieb Dylan McKay: > > * *The C/C++ function needs to be declared with either the calling > convention avr-interrupt or avr-non-blocking-interrupt.* Skipping > this step will cause regular ret instructions to be emitted for > return-from-subroutine, instead of the required reti for interrupt > handlers. ISRs also have stricter

My experience of having the address space for functions (or function pointers) in the DataLayout i that when the .ll file is parsed we need to parse the DataLayout before any function declarations. That is needed because we want to attribute the functions with correct address space (according to DataLayout) when inserting them in the symbol table. An alternative would be to update address space

> -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: den 13 juli 2017 16:01 > To: Björn Pettersson A <bjorn.a.pettersson at ericsson.com>; David Chisnall > <David.Chisnall at cl.cam.ac.uk>; Dylan McKay <me at dylanmckay.io> > Cc: llvm-dev at lists.llvm.org; Carl Peto <carl.peto at me.com> > Subject: Re: [llvm-dev] RFC:

Hello everyone, LLVM buildmaster will be updated and restarted after 5PM Pacific time today. Thanks Galina -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200120/567b3b5a/attachment.html>

Hey Wilhelm, That's a bug, the "interrupt" attribute is not being recognized by the backend. I have fixed it in https://github.com/llvm/llvm-project/commit/339b34266c1b54a9b5ff2f83cfb1da9cd8c9d90a Pull the latest LLVM and it should be fixed. On Tue, Mar 31, 2020 at 8:00 AM Wilhelm Meier <wilhelm.meier at hs-kl.de> wrote: > Hi Dylan, > > I used the following

Hi Dylan, looks ok now. One thing: the ISR is now: __vector_21: ; @__vector_21 __vector_21$local: sei push r0 push r1 in r0, 63 push r0 clr r0 push r24 lds r24, v1 sts v2, r24 pop r24 pop r0 out 63, r0 pop r1 pop r0 reti There are unneccessary push/pops of r1 and r0 too, since the clr is useless ... GCC had the same

Hey Wilhelm, Could you post the LLVM IR generated from your C++ file? This can be achieved with 'clang -S -emit-llvm' Cheers On Sat, Mar 28, 2020 at 6:36 PM Wilhelm Meier <wilhelm.meier at hs-kl.de> wrote: > Answering partly to myself there was a extern "C" missing. > > But the register pushes ans reti are still missing. > > Whats wrong? > > Am

Hello everyone, LLVM buildmaster is back to work. Two slaves remain off for now as they produce a lot of warnings and their log files are way too big. The next builds have full logs available. Hope this helps to fix this issue: http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/8716 http://lab.llvm.org:8011/builders/clang-with-thin-lto-windows/builds/2645 Thanks Galina

I’ve had another look, and some of the failing tests don’t use temporary files, so I don’t think this is a case of tests having side-effects. Instead, I’ve noticed that in the build log (http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/6552/steps/build-unified-tree/logs/stdio), llvm-tblgen.exe is built (my patch modified it), but the table-generation steps of the

Is there anything I can do about it? BTW: gcc is loosing the AVR backend, so I would assume, there will be a greater interest to this in llvm compared to the past. Thanks, Wilhelm Am 03.04.20 um 15:09 schrieb Wilhelm Meier via llvm-dev: > Should I create an issue in bugzilla for this? Just to be reminded ... > > Am 31.03.20 um 09:34 schrieb Wilhelm Meier via llvm-dev: >> Hi

Hi Galina, I'm seeing a lot of timeouts on my monitor script, but the bots seem fine. I'm thinking it may be the master swapping or something? cheers, --renato