search for: sigilized

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

...you could probably get a working solution too. However, this introduces an inconsistency in that now there's this pseudo-common syntax (%[0-9]+) for unnamed things for both BB's and instructions, but in the case of instructions, the % sigil is always needed, while the label syntax isn't sigilized by default, but permits this weird sigilized temporary numbered form. Maybe that slight inconsistency is worth it? If the inconsistency is really bothersome, we could also have BB's be able to start sigilized with % in the other case like instructions are (there is no ambiguity because of the t...

...et a working solution too. However, this introduces an > inconsistency in that now there's this pseudo-common syntax (%[0-9]+) for > unnamed things for both BB's and instructions, but in the case of > instructions, the % sigil is always needed, while the label syntax isn't > sigilized by default, but permits this weird sigilized temporary numbered > form. Maybe that slight inconsistency is worth it? If the inconsistency is > really bothersome, we could also have BB's be able to start sigilized with > % in the other case like instructions are (there is no ambiguity b...

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 --------------

...ution too. However, this introduces an >> inconsistency in that now there's this pseudo-common syntax (%[0-9]+) for >> unnamed things for both BB's and instructions, but in the case of >> instructions, the % sigil is always needed, while the label syntax isn't >> sigilized by default, but permits this weird sigilized temporary numbered >> form. Maybe that slight inconsistency is worth it? If the inconsistency is >> really bothersome, we could also have BB's be able to start sigilized with >> % in the other case like instructions are (there is no...

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

...er, this introduces an >>> inconsistency in that now there's this pseudo-common syntax (%[0-9]+) for >>> unnamed things for both BB's and instructions, but in the case of >>> instructions, the % sigil is always needed, while the label syntax isn't >>> sigilized by default, but permits this weird sigilized temporary numbered >>> form. Maybe that slight inconsistency is worth it? If the inconsistency is >>> really bothersome, we could also have BB's be able to start sigilized with >>> % in the other case like instructions are...

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

...ces an >>>> inconsistency in that now there's this pseudo-common syntax (%[0-9]+) for >>>> unnamed things for both BB's and instructions, but in the case of >>>> instructions, the % sigil is always needed, while the label syntax isn't >>>> sigilized by default, but permits this weird sigilized temporary numbered >>>> form. Maybe that slight inconsistency is worth it? If the inconsistency is >>>> really bothersome, we could also have BB's be able to start sigilized with >>>> % in the other case like instr...

I'm testing on older OS X 10.8 with older SSE4 hardware from about 2010. I've got updated gear from MacPorts 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

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?