search for: sigills

Hi A few of us have discussed enhancing the MIR vregs to include support for named-vregs. At the moment named regs are only supported for physical registers and number regs are reserved for vregs. We've decided that to properly implement a syntax for MIR named vregs we first need to reorganized the sigils used for physical registers and external symbols so our proposal is to swap the sigil

When we discussed this our line of thought was like this: - LLVM IR already uses %name for SSA values which is closer to what a vreg is than to what a physreg is. It would be neat to draw that parallel to llvm IR. - We wanted another sigil for physregs so they are easy to differentiate from vregs to allow people to differentiate vregs/physregs even if they don't know all the physreg names of

Can we use %% for vregs? Seems slightly easier to remember %/%% than $/%. Also, %eax and $some_symbol are already familiar from typical assembly syntax and we probably don't want to break that association. It's all a bikeshed, but being more consistent with assembly is probably a win. -- Sean Silva On Dec 25, 2017 11:31 AM, "Puyan Lotfi via llvm-dev" < llvm-dev at

On Mon, Jan 8, 2018 at 2:27 PM, Matthias Braun <mbraun at apple.com> wrote: > When we discussed this our line of thought was like this: > > - LLVM IR already uses %name for SSA values which is closer to what a vreg > is than to what a physreg is. It would be neat to draw that parallel to > llvm IR. > - We wanted another sigil for physregs so they are easy to differentiate

Hi sh4 porters, I?ve just fixed a regression of klibc to build from source on sh4 using the sumotsu.debian.net porterbox (thanks for making one available) and found a problem with your archi- tecture: all binaries built with klibc (shared and static) get a SIGILL (illegal instruction). I suspect that different CFLAGS are needed. Please, someone, have a look at it; a release of klibc 2.0 upstream

Hi, I have this simple program: #include <regex> int main() { std::regex re; re.assign(std::regex("foo")); // SIGILL return 0; } It runs smoothly if compiled with g++ but raises "illegal instruction" when compiled with clang++: g++ -std=c++11 -O0 -g -o test-g++ test.cpp clang++ -std=c++11 -O0 -g -o test-clang++ test.cpp ptomulik at barakus:$ ./test-g++ ptomulik

On Mon, 2017-05-15 at 18:58 +0200, Andrea Venturoli via samba wrote: > On 05/08/17 11:17, Andrea Venturoli wrote: > > Hello. > > > > I've got a network of FreeBSD servers which traditionally hosted a > > classic domain. > > I upgraded some months ago, removing the old PDC and BDC and migrating > > to an AD DC controller in a jail. > > This is

(gah, this turned into a huge digression, sorry) The implicit numbering of BB's seems to be a pretty frequent issue for people. Surprisingly, the issue boils down to simply changing the IR asm (.ll file) syntax so that it can have "unnamed BB's" in a recognizable way that fits in with how unnamed values work (the asmprinter makes an effort to print a comment with the BB number,

Thanks for the lecture :) But I was not planning on changing a single line in LLVM/Clang. I stick to the documentation until I've learned to swim, perhaps even forever. Ah, now I see. You thought I meant "should I modify the code to do this or that." I only meant to change the documentation. Please refer to the patch I've sent on LLVM-commits. That's about what I had

The language reference states that local temporaries begin with index 0, but if I try that on my not-entirely-up-to-date v3.4 llc (it is like a week old), I get an error "instruction expected to be numbered '%1'". Also, quite a few examples in the LR uses %0 as a local identifier. Should I fix those or is it a problem in llc? -- Mikael -------------- next part --------------

On Tue, Nov 26, 2013 at 9:58 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > Thanks for the lecture :) But I was not planning on changing a single > line in LLVM/Clang. I stick to the documentation until I've learned to > swim, perhaps even forever. Ah, now I see. You thought I meant "should I > modify the code to do this or that." I only meant to change

Hi Chris, I've CC'd Eric Botcazou in the hope that he will clear up just what the Ada front-end needs from the rest of the compiler as far as asynchronous exceptions are concerned. >> gcc Ada turns signals into exceptions. As far as I know it does this >> completely asynchronously, and the fact that LLVM doesn't support this >> is rather bad as far as Ada is

On Thu, 2017-05-18 at 09:27 +0200, Andrea Venturoli via samba wrote: > On 05/17/17 21:14, Andrew Bartlett wrote: > > > What is your platform > > FreeBSD 10.3/amd64. > > > > > and what is signal 4 on your platform? > > It is SIGILL on x86_64 linux. > > I believe signals are more or less standard across all Unices... anyway > it's SIGILL on

Without ANY intent of offending anybody, I simply don't like C++. I did code in it for some 12 years back from 1990 to 2002, but then I left it behind with a feeling of happiness. The main reason I am _trying_ to make a new language is that I hope to one day come up with something that can help retiring C++. I love C# but that language is yet too slow for many demanding problem domains.

Hi, no mailing list for powerpcspe? What?s the progress of your architectures? I don?t see much happening on debian-ports.org, and taking your architectures off that infrastructure hurts others (I?ve ?revived? m68k and kept it running on d-p.o which helps a bit). Anyway: a new klibc (2.0~rc5-1) has been uploaded, and an mksh companion version (40.9.20120518-1) depending on it and trying to use

On Tue, Nov 26, 2013 at 10:35 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > Without ANY intent of offending anybody, I simply don't like C++. I did > code in it for some 12 years back from 1990 to 2002, but then I left it > behind with a feeling of happiness. The main reason I am _trying_ to make > a new language is that I hope to one day come up with something that

...rts and it includes GCC and Clang. GCC is the compiler, and Clang is the assembler. We perform a compile/link on a test file to ensure an ISA is supported by the toolchain. If an ISA is available then we compile a source file to the ISA as needed. Then, we guard the higher ISAs at runtime to avoid SIGILLs. It worked well until we added AVX2. For AVX2 we see this as expected: $ CXX=/opt/local/bin/clang++-mp-5.0 make /opt/local/bin/clang++-mp-5.0 ... -c chacha.cpp /opt/local/bin/clang++-mp-5.0 ... -mavx2 -c chacha_avx.cpp /opt/local/bin/clang++-mp-5.0 ... -msse2 -c chacha_simd.cpp...

On 1/7/2015 8:59 AM, Chandler Carruth wrote: > > Essentially, I think target-independent optimizations are still > attractive, but we might want to just force them to go through an > actual target-implemented API to interpret the scopes rather than > making the interpretation work from first principles. I just worry > that the targets are going to be too different and we may

Hello, this last patch is strictly-speaking not related to System Z as target platform, but to running LLVM on (Linux on) System Z as a *host* architecture. Most of the LLVM and Clang code base builds and works fine on System Z, however, there is one problem relating to use of signal handlers to react to crashes (SIGSEGV, SIGILL etc.). The llvm::sys::AddSignalHandler (and related) function in

On Jun 14, 2011, at 2:11 AM, Duncan Sands wrote: > gcc Ada turns signals into exceptions. As far as I know it does this > completely asynchronously, and the fact that LLVM doesn't support this > is rather bad as far as Ada is concerned. That said, the Ada front-end You're saying that it turns asynch signals like SIGHUP (which can occur on any machine instruction) into signals?