similar to: [LLVMdev] is anyone using the sparc backend?

Hi, in section B.29. (Write State Register Instructions) of 'The SPARC Architecture Manual Version 8' it is said that the "The write state register instructions are delayed-write instructions." The Y-register is a state-register. Furthermore in the B.29-secion there is a programming note saying: MULScc, RDY, SDIV, SDIVcc, UDIV, and UDIVcc implicitly read the Y register.

Sparc is a popular target for architecture simulators, and removing that back end would force people using such simulators to use some other compiler infrastructure. Sparc is also useful for University courses. I'd strongly discourage removing this back end. --Vikram Professor, Computer Science University of Illinois at Urbana-Champaign http://llvm.org/~vadve On Oct 25, 2011, at 4:00

On Tue, 11 Nov 2008, Peter Shugalev wrote: > Hi, > > Anton Korobeynikov wrote: >>> I thought llvm-gcc isn't meant to compile for specific target (at least >>> with -emit-llvm flag I'm using). >> No, it is not. C language is highly target-specific, thus LLVM IR >> obtained from such sources also has the same nice 'property' > > I can see

FYI, I completely agree that we shouldn't remove the sparc target. However, it is currently unmaintained, and has some pretty glaring bugs. Is anyone interested in stepping up to maintain the target? -Chris On Oct 25, 2011, at 6:35 AM, Vikram Adve wrote: > Sparc is a popular target for architecture simulators, and removing that back end would force people using such simulators to use

Hi, Anton Korobeynikov wrote: >> I thought llvm-gcc isn't meant to compile for specific target (at least >> with -emit-llvm flag I'm using). > No, it is not. C language is highly target-specific, thus LLVM IR > obtained from such sources also has the same nice 'property' I can see only one reason for such dependence: inclusion of system headers in /usr/include.

Hi, > I thought llvm-gcc isn't meant to compile for specific target (at least > with -emit-llvm flag I'm using). No, it is not. C language is highly target-specific, thus LLVM IR obtained from such sources also has the same nice 'property' > Speaking of SPARC ABI can I still call non-FP external (i.e. compiled > with regular non-llvm gcc to native sparc binary)

On Oct 24, 2011, at 7:54 PM, 陳韋任 wrote: >> I'm removing old targets that no longer appear actively maintained, >> to reduce the burden for target-independent codegen maintenance. > > I don't know what you exactly mean. Could you give an example? I am making some scheduler changes. It appears that some of my changes uncovered a long-standing bug in the Alpha backend.

I'm removing old targets that no longer appear actively maintained, to reduce the burden for target-independent codegen maintenance. Does anyone object to the removal of the Alpha backend? Dan

Hi, Now I am working on BCC Cross-compiler in order to get the binaries for LEON3 (Google SoC 2007). I changed these lines of Makefile ... CC = gcc CPP = gcc -E ... to these : CC = sparc-elf-gcc -mv8 -msoft-float CPP = sparc-elf-gcc -mv8 -msoft-float -E The options means: -mv8 : generate SPARC V8 instructions -msoft-float : emulate floating-point When I run "make", there is a

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-03:08.realpath Security Advisory The FreeBSD Project Topic: Single byte buffer overflow in realpath(3) Category: core Module: libc Announced:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-03:08.realpath Security Advisory The FreeBSD Project Topic: Single byte buffer overflow in realpath(3) Category: core Module: libc Announced:

I have ported ASan in LLVM to Myriad RTEMS, and I would like to upstream the port. Below is the design doc. Feedback welcome. https://docs.google.com/document/d/1oxmk0xUojybDaQDAuTEVpHVMi5xQX74cJPyMJbaSaRM The port is expected to work with modified versions of RTEMS and newlib. I have a git repo with changes to those projects, that I can make available if there is interest. Here is the patch

On Oct 25, 2011, at 9:29 AM, David A. Greene wrote: > Dan Gohman <gohman at apple.com> writes: > >> I'm removing old targets that no longer appear actively maintained, >> to reduce the burden for target-independent codegen maintenance. >> >> Does anyone object to the removal of the Alpha backend? > > It would be a shame to lose it. Alpha is an

Hi Walter, I've done a first quick scan. Overall looks reasonable, but I'd like to try reducing the number of newly introduced platform-specific ifs. Vitaly, please also take a look (once my initial comments are addressed). One outstanding issue is your problem with initialization vs checking, which requires you to insert so many ifs. Is there any chance you can avoid this? If you

Dan Gohman <gohman at apple.com> writes: > I'm removing old targets that no longer appear actively maintained, > to reduce the burden for target-independent codegen maintenance. > > Does anyone object to the removal of the Alpha backend? It would be a shame to lose it. Alpha is an excellent example of a good RISC-style ISA. There's at least one simulator out there

Hey, I work on fuchsia symbolizer stuff. I don't know if you guys already have an external symbolizer but I'm working on making one right now and I plan on making one backed by LLVM that can be run host-side or target-side. I'd like to contribute that back to llvm ideally. What do you guys have so far? I have a prototype in golang that just spins up an instance of llvm-symbolizer

Hi Jake. Thanks for the info. Where can I keep up to date on the symbolizer status? Our symbolizer is provided by the Myriad vendor and integrated into its host test environment. It doesn't do much: just look for PC string patterns and symbolize them using addr2line. Thanks, Walter On Fri, May 4, 2018 at 5:36 PM Jake Ehrlich <jakehehrlich at google.com> wrote: > Hey, > I

Hi, I'd like to load with pxelinux an RTEMS executable file, the format is ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, strtipped Can someone tell me if there is a way to load it with PXElinux. When I try to do it, the error message is : invalid or corrupt kernel image Thanks for your help. Regards. Stephane ARQUER

Hi Kostya. Thanks for the quick feedback. I will work on addressing your comments. In regard to initialization checks, I can eliminate most of them by initializing the shadow memory very early, but I still need to do something in two places, __asan_handle_no_return and GetFakeStackFast. Would it be ok to have guards for those two places only? Walter On Fri, May 4, 2018 at 6:10 PM Kostya

Hello, I am searching a SSH server for remote administration of an embedded application running on RTEMS (https://www.rtems.org). This environment has neither virtual memory nor user and kernel space. So this is like an application running in kernel mode only. Would it be possible to run (a very basic version of) OpenSSH in such an environment using e.g. threads instead of forking new