search for: sigill

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 is imminent. bye, //mirabilos -- FWIW, I'm quite impressed with mksh interactively. I thought it was much *much* more bare bones. But it turns out it beats t...

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 at barakus:$ ./test-clang++ Illegal...

...https for hostname 'XXX.xxxxx.xxxxxxxx.xx'" changes > to "TLS autogeneration skipped - some TLS files already exist". > Then I get the same error as above. > > > Any suggestion? > TIA. What is your platform, and what is signal 4 on your platform? It is SIGILL on x86_64 linux. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba

(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

...sly, 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? AFAIK, on posix systems only SIGFPE, SIGILL, SIGSEGV and SIGBUS are turned into exceptions. For other signals, if there is no signal handler then the program is terminated; if the user installed a signal handler then it is run, and as far as I know there is no way for a user installed handler to raise an exception at the original point of e...

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 FreeBSD too. > > Where does this lead? I always thought SIGILL was for un-alligned memory access, which is slow but permitted on x86. I guess get it under a debugger...

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.

...(I could probably ask for access to an hppa lenny chroot, but? ugh!) and see whether it?ll work for you ? klibc on sh4, for example, was broken and nobody noticed it until I ssh?d to a porterbox (there seem to not exist any for hppa and powerpcspe) to fix an FTBFS, wanted to test the result and saw SIGILL (then downloaded the last version that had built, ran it and saw a SIGILL, so _that_ was no regression). A klibc 2.0 release is imminent, so please have a look. I?d also be interested in the general status of these two ports. bye, //mirabilos PS: It?s possible to get d-p.o access as non-DD. It?s...

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

...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 lib/Support/Unix/Signals.inc currently registers a signal handler routine via "sigaction". When this handler is called due to a SIGSEGV, SIGILL or similar signal, it will show a stack backtrace, deactivate the handler, and...

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?