| Message ID | 8127ea37-aa1e-cdff-a9eb-43e6f5bbf0f1@ramsayjones.plus.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Fri, Mar 02, 2018 at 08:57:27PM +0000, Ramsay Jones wrote: > > I quickly tried this on cygwin (because I don't have LLVM installed > on Linux at the moment). I have had, for a long time, three of > the backend (ie. LLVM) tests failing on master. I have e-mailed the > list about these failures before - but I had forgotten to e-mail > about some 'workarounds' that I have found since then (and they may > well be specific to cygwin). > > Anyway, without those 'workarounds' I see several more failures in > the backend tests (but _not_ backend/call-variadic.c), but if I apply ... > Hope That Helps! Yes, it helps a lot to understand the problems you had. Thanks. I've quickly checked and those workarounds doesn't have a negative effect on my environments, so I'm fine with them and to me they can even go into to current HEAD (or upcoming release 0.5.2 if Chris is fine doing one). OTOH, I would prefer to better understand what they do (OK, choosing non-default method for exeception handling and not using JIT) and even more why they're only needed for your env (cygwin). Are you using an old version of LLVM or something relatively recent like 3.8, 3.9 or 4.0+? Best regards, -- Luc -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/03/18 21:57, Luc Van Oostenryck wrote: > On Fri, Mar 02, 2018 at 08:57:27PM +0000, Ramsay Jones wrote: >> >> I quickly tried this on cygwin (because I don't have LLVM installed >> on Linux at the moment). I have had, for a long time, three of >> the backend (ie. LLVM) tests failing on master. I have e-mailed the >> list about these failures before - but I had forgotten to e-mail >> about some 'workarounds' that I have found since then (and they may >> well be specific to cygwin). >> >> Anyway, without those 'workarounds' I see several more failures in >> the backend tests (but _not_ backend/call-variadic.c), but if I apply > > ... > >> Hope That Helps! > > Yes, it helps a lot to understand the problems you had. > Thanks. Note that I didn't get any unexpected failures - Chris mentioned some failures (on Linux?). > I've quickly checked and those workarounds doesn't have > a negative effect on my environments, so I'm fine with > them and to me they can even go into to current HEAD > (or upcoming release 0.5.2 if Chris is fine doing one). I don't think I would apply them as-is - I've been meaning to install LLVM on Linux again, so I can check these things out for myself. Also, I think these are platform specific (maybe!). ;-) > OTOH, I would prefer to better understand what they > do (OK, choosing non-default method for exeception handling > and not using JIT) and even more why they're only needed > for your env (cygwin). Are you using an old version of LLVM > or something relatively recent like 3.8, 3.9 or 4.0+? The LLVM version is 5.0.1. I think the exception-model is specific to the cygwin (Windows) platform. I chanced upon that solution by noting the errors related to some '.seh_xxx' asm directives (Structured Exception Handling) and skimming the 'llc --help' output for clues. [Perhaps that should be the default for the cygwin build of LLVM!] Forcing the use of the interpreter was just a wild guess that paid off! I tried several things, including using an intermediate file rather than piping into the stdin of LLI - don't quote me, but I think that may have worked as well (I don't remember). [It may have something to do with buffering on the pipe.] In other words, I didn't investigate too much, since the LLVM backend is not something I'm too interested in, except for a general desire to keep bugs out of the project. ATB, Ramsay Jones -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Mar 02, 2018 at 11:33:52PM +0000, Ramsay Jones wrote: > > Note that I didn't get any unexpected failures - Chris mentioned > some failures (on Linux?). I don't remember. > > I've quickly checked and those workarounds doesn't have > > a negative effect on my environments, so I'm fine with > > them and to me they can even go into to current HEAD > > (or upcoming release 0.5.2 if Chris is fine doing one). > > I don't think I would apply them as-is - I've been meaning > to install LLVM on Linux again, so I can check these things > out for myself. No, no. They would need at least a description and additional verifications. > Also, I think these are platform specific > (maybe!). ;-) It was what I was afraid of but they're fine on a few linux 32 or 64bit with LLVM 3.5, 3.9, 4.0 or 5.0 > > OTOH, I would prefer to better understand what they > > do (OK, choosing non-default method for exeception handling > > and not using JIT) and even more why they're only needed > > for your env (cygwin). Are you using an old version of LLVM > > or something relatively recent like 3.8, 3.9 or 4.0+? > > The LLVM version is 5.0.1. > > I think the exception-model is specific to the cygwin (Windows) > platform. I chanced upon that solution by noting the errors I understood that 'sjlj' was ok for linux too while 'seh' was only for Windows but I may be wrong. > related to some '.seh_xxx' asm directives (Structured Exception > Handling) and skimming the 'llc --help' output for clues. > [Perhaps that should be the default for the cygwin build of LLVM!] Yes, I think it would be better to have these options conditionaly set on cygwin. > Forcing the use of the interpreter was just a wild guess that > paid off! hehe :) > I tried several things, including using an intermediate > file rather than piping into the stdin of LLI - don't quote me, > but I think that may have worked as well (I don't remember). > [It may have something to do with buffering on the pipe.] > > In other words, I didn't investigate too much, since the LLVM > backend is not something I'm too interested in, except for a > general desire to keep bugs out of the project. Same here for me. Thanks for the info. -- Luc -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Mar 2, 2018 at 3:33 PM, Ramsay Jones <ramsay@ramsayjones.plus.com> wrote: > > Note that I didn't get any unexpected failures - Chris mentioned > some failures (on Linux?). That is on the merge-luc-master branch. It is not part of the 0.5.2-RC1 release. So Luc is proposing make a 0.5.2 release first before merging luc's master branch. > >> I've quickly checked and those workarounds doesn't have >> a negative effect on my environments, so I'm fine with >> them and to me they can even go into to current HEAD >> (or upcoming release 0.5.2 if Chris is fine doing one). > > I don't think I would apply them as-is - I've been meaning > to install LLVM on Linux again, so I can check these things > out for myself. Also, I think these are platform specific > (maybe!). ;-) I am fine with either way. I should suggest hold it off for 0.5.2 because none of us have try those very strange flags on Linux yet. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Mar 3, 2018 at 12:33 AM, Ramsay Jones <ramsay@ramsayjones.plus.com> wrote: > > Note that I didn't get any unexpected failures - Chris mentioned > some failures (on Linux?). I hadn't failures on the 3 environments I test the most but I can see it too now on another one. -- Luc -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/sparsec b/sparsec index e421776..9ed65ac 100755 --- a/sparsec +++ b/sparsec @@ -36,7 +36,7 @@ $DIRNAME/sparse-llvm $SPARSEOPTS > $TMPLLVM LLC=`"${LLVM_CONFIG:-llvm-config}" --bindir`/llc -$LLC -o - $TMPLLVM | as -o $TMPFILE +$LLC -exception-model=sjlj -o - $TMPLLVM | as -o $TMPFILE if [ $NEED_LINK -eq 1 ]; then if [ -z $OUTFILE ]; then diff --git a/sparsei b/sparsei index 3431a9f..d915b1f 100755 --- a/sparsei +++ b/sparsei @@ -10,4 +10,4 @@ if [ $# -eq 0 ]; then exit 1 fi -$DIRNAME/sparse-llvm $@ | $LLI +$DIRNAME/sparse-llvm $@ | $LLI -force-interpreter=true