similar to: [LLVMdev] bug of tail call optimization on x86 target

Hi Katsuhiro, Thanks very much for taking the time to dig into this and produce a patch. Is there any chance you could make a couple of tweaks? > This bug is due to wrong computation of stack object indices by the > x86 backend. The attached patch indicates the wrong points. Due to > integral promotion, explicit conversion to signed integer is needed > at those points. I'm not

Hi Tim, Thank you for your quick response. > I'm not convinced that's the best solution, at least conceptually. > SlotSize really is an unsigned quantity, and though it's unlikely we'd > like 0x80000000 to be interpreted as positive, rather than negative if > it ever does occur. I totally agree with you. I rewrote my fix and made a test case according to your

Hello everybody, hi Evan, this patch changes the lowering of arguments for tail call optimized calls. Before arguments that could be overwritten by each other were explicitly lowered to a stack slot, not giving the register allocator a chance to optimize. Now a sequence of copyto/copyfrom virtual registers ensures that arguments are loaded in (virtual) registers before they are lowered to the

Hi Katsuhiro, > I rewrote my fix and made a test case according to your suggestion. > All of them are included in the attached file. Thanks very much for doing that and taking the time in the first place to make the patch. It looked good to me so I committed it in r187703. It'll automatically make its way into the 3.4 release later this year. Cheers. Tim.

Hi, I found a mysterious behavior of LLVM optimizer. I compiled the following code by clang -emit-llvm -S: #include <stddef.h> static const struct t {char t[4]; char s;} p = {{}, 'a'}; char f() { return ((char*)&p)[offsetof(struct t, s)]; } then I obtained the following LLVM IR: %struct.t = type { [4 x i8], i8 } @p = constant %struct.t { [4 x i8] zeroinitializer, i8 97

Hi, Is this expected or not? From: user1 at fuga.example.com <user1 at example.com> To: user2 at hoge.example.com <user2 at example.com> ? a uid fetch 43055 (envelope) * 1860 FETCH (UID 43055 ENVELOPE ("Thu, 30 Jul 2020 13:52:59 +0900" "test1" ((NIL NIL "user1" "fuga.example.com")) ((NIL NIL "user1" "fuga.example.com"))

On Tue, 1 Sep, 2020 at 09:59, Timo Sirainen <timo at sirainen.com> wrote: > On 1. Sep 2020, at 6.24, TACHIBANA Masashi <tachibana at qualitia.co.jp> > wrote: >> >> Hi, >> >> Is this expected or not? >> >> From: user1 at fuga.example.com <user1 at example.com> >> To: user2 at hoge.example.com <user2 at example.com> >>

On 1. Sep 2020, at 6.24, TACHIBANA Masashi <tachibana at qualitia.co.jp> wrote: > > Hi, > > Is this expected or not? > > From: user1 at fuga.example.com <user1 at example.com> > To: user2 at hoge.example.com <user2 at example.com> > ? > a uid fetch 43055 (envelope) > * 1860 FETCH (UID 43055 ENVELOPE ("Thu, 30 Jul 2020 13:52:59 +0900"

Hi there, No information was found which version of XFree86 get along with R. I could not compile R version 1.8.1 with XFree86 4.3.99.902. Here is error message. gcc -I. -I../../../src/include -I../../../src/include -DI18N_MB -I/usr/X11R6/include -I/usr/local/include -DHAVE_CONFIG_H -D__NO_MATH_INLINES -mieee-fp -fPIC -O2 -pipe -march=i386 -mcpu=i686 -c dataentry_mb.c -o dataentry_mb.lo In

Hi. OS: Solaris 2.6 and 8 OpenSSH: 2.9p2 I found a bug. Output of last command becomes strange in case of "UseLogin yes" in sshd_config. # Two entries are output with one time of login. strange case: % last fuga pts/3 bar.foo.co.jp Thu Jun 21 12:45 - 20:02 (07:16) fuga pts/3 bar.foo.co.jp Thu Jan 1 09:00 - 12:45 (11494+03:45) hoge pts/2

ola, ive been looking at adding support for an -msave-args option for use on x86_64. the short explanation of it is that it makes x86_64 function prologues store their register arguments on the stack. the purpose of this is to make the arguments trivially accessible for things like stack traces with arguments. as per https://blogs.oracle.com/sherrym/entry/obtaining_function_arguments_on_amd64,

Is it possible to bootstrap a static llvm bindist that uses its own libcxx and maybe a little bit if musl libc.a on Linux (and libc.a on FreeBSD) bundled in? The use case is that one often needs to keep an older LLVM toolchain around for some languages targeting an older bitcode stream and, with C++ and everything, that older toolchain will easily stop working with other global updates to the

Wanted to raise two questions: 1. Is bugs.r-project.org down? I haven't been able to reach it for two or three days: ``` ping bugs.r-project.org PING rbugs.research.att.com (207.140.168.137): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 Request timeout for icmp_seq 3 Request timeout for icmp_seq 4 Request timeout for icmp_seq 5

Yes please. Evan On Oct 5, 2007, at 11:55 AM, Arnold Schwaighofer wrote: > > On 5 Oct 2007, at 20:47, Evan Cheng wrote: > >> >> On Oct 5, 2007, at 10:56 AM, Arnold Schwaighofer wrote: >> >>> >>>> We can set a policy of treating fastcc external functions >>>> as c functions. Then there is no chance of introducing ABI >>>>

Hello, I started off trying to test HLVM (http://www.ffconsultancy.com/ocaml/hlvm/) in a freshly compiled LLVM3.0, and found a few errors have crept into LLVM between revisions 2.7 and 2.8. System info: 2.6.31-23-generic #75-Ubuntu SMP x86_64 GNU/Linux, oprofile version 0.9.3-1.1ubuntu2_amd64 HLVM uses the following code to set "guaranteed" tail call optimization: <code>

On Oct 5, 2007, at 10:56 AM, Arnold Schwaighofer wrote: > >> We can set a policy of treating fastcc external functions >> as c functions. Then there is no chance of introducing ABI >> incompatibility. > this means limiting tail call opt to protected/invisible functions > within a module? > a little limiting i think. It makes sense to be extra careful at this point.

On 5 Oct 2007, at 20:47, Evan Cheng wrote: > > On Oct 5, 2007, at 10:56 AM, Arnold Schwaighofer wrote: > >> >>> We can set a policy of treating fastcc external functions >>> as c functions. Then there is no chance of introducing ABI >>> incompatibility. >> this means limiting tail call opt to protected/invisible functions >> within a module?

Another round ;) Sadly not beer. tested against r42630 darwin-x86: SPASS llc-beta still fails thanks for the patience On 5 Oct 2007, at 20:58, Evan Cheng wrote: > Yes please. >> okay then i'll make tailcallopt switch stack adjusting behaviour? the patch for the test suite (when/if it's needed) would be something like: >>>>> --- Makefile.programs (revision

> Tail calls are disabled by default; to enable them, you have to pass > -tailcallopt to llc. It looks like there's a bug preventing indirect > tail calls from working... I don't think there's anything > fundamentally preventing them from working, though. I will not be using llc, it will all be through the C++ API. I looked through the code a bit, but could not see any

On Sun, Jan 3, 2010 at 10:50 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > On Monday 04 January 2010 03:33:06 Simon Harris wrote: >> On 04/01/2010, at 3:01 PM, Jon Harrop wrote: >> > I am certainly interested in tail calls because my HLVM project relies >> > upon LLVM's tail call elimination. However, I do not understand what tail >> > calls LLVM