bugGNU Octave - Bugs: bug #41061, Octave fails to build with LLVM 3.5

 
 

bug #41061: Octave fails to build with LLVM 3.5

Submitted by:  Albert <aaahaaah>
Submitted on:  Wed 01 Jan 2014 10:28:03 PM UTC  
 
Category: Configuration and Build SystemSeverity: 1 - Wish
Priority: 1 - LaterItem Group: Build Failure
Status: PostponedAssigned to: None
Originator Name: AlbertOpen/Closed: Open
Release: devOperating System: GNU/Linux

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Sun 03 May 2015 08:57:49 PM UTC, comment #37:

There you go: file #33887

Used the AX_CHECK_COMPILE_FLAG macro. The file #33888 ax_compare_version.m4 needs to be included in the m4/ directory.

http://www.gnu.org/software/autoconf-archive/ax_check_compile_flag.html

Seems to work but couldn't test with older version of gcc.

Josué Mercado <mpad>
Sun 03 May 2015 07:32:04 PM UTC, comment #36:

You're still checking for versions instead of features. It doesn't matter what the compiler is or its version. All that matters is if it accepts -std=c++11 or -stc=c++0x. Indeed, gcc versions earlier to 4.7 have quite a bit of C++11 implemented, back when it was still known as C++0x.

But I really think this is a waste of time, at least as it pertains to LLVM. Why are you so interested in compiling JIT support into Octave?

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Sat 02 May 2015 12:34:55 PM UTC, comment #35:

Added file #33878: Now checks the LVMM features (DataLayoutPass) instead of the version macros. No change to c++11.
Regarding the gnulib-hg patch it just checks if _GCC_MAX_ALIGN_T is already defined which is the case on my system.

Josué Mercado <mpad>
Fri 01 May 2015 09:24:01 PM UTC, comment #34:

Jordi: As you point out, this is not a happy
situation. Someday, RHEL may move up, but I would
not hold my breath. They are VERY "conservative."
And, to make matters worse, many major sites are one
or two levels behind the current release of RHEL.
For a large production site, moving up is a very major
effort. It would be helpful to continue to provide
Octave that they can use.

However, note that the default for LLVM is to NOT
attempt to include it. Only ./configure --enable-jit
attempts to turn it on. So, I see no need to remove
the, normally unused, code.

So, obviously, the recent patch should not be applied
in its present form or probably not at all.

This should be preserved in case someone shows up to
put serious work into the implementation.

On the brighter side, I was surprised that the current
system does compile "correctly" using C++11. The various
warnings do not apparently prevent it from generating
correct code.

Michael Godfrey <godfrey>
Fri 01 May 2015 09:08:38 PM UTC, comment #33:

Agree with Jordi, these patches are not appropriate.

I already opened a separate bug about optionally enabling C++11 features in the compiler if the compiler supports it, see bug #44965. That is the appropriate place to talk about how to add the right compiler flags, and it's basically a solved problem, but will not be done until after 4.0.0 is out.

The first patch should also not look at LLVM_VERSION macros, it should add a configure.ac test for llvm::DataLayoutPass vs llvm::DataLayout, if that's what is failing.

And agree about the gnulib patch, can you show an error message or demonstrate a small example showing what the problem is and why a change is needed?

Mike Miller <mtmiller>
Project Member
Fri 01 May 2015 09:02:35 PM UTC, comment #32:

We don't generally check versions. We check for features.

But we also don't use C++11, not as long as RHEL doesn't have a C++11 compiler. If LLVM 3.5 will not compile without C++11, the right thing to do would be to check if we can compile an LLVM program, and if not, check that the compiler, whatever compiler it may be, can accept a -std=c++11 flag and then try to compile an LLVM program again with -std=c+11.

This is all awfully complicated and for almost no benefit. It's far easier to just drop the LLVM dependency completely, since we don't really have any interesting JIT compiling at all.

I would be happy to see either (1) someone come along and actually implement JIT compiling or (2) someone come along and remove all traces of LLVM from our codebase.

Finally, the gnulib patch should be pushed upstream to gnulib. I don't understand what it does, though, can you explain more?

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Fri 01 May 2015 08:22:53 PM UTC, comment #31:

Added two patches:
file #33858
Added GCC check. If version is >= 4.7 then uses c++11 flag (LLVM).
Added LLVM version check (preprocesor macro check)

file #33859
Minor fix (gnulib-hg sub-repo) to avoid conflicting declarations.

Tested on OpenSuse 12.3 (GCC 4.7/LLVM 3.2) and OpenSuse 13.2 (GCC 4.8/LLVM 3.5).

Josué Mercado <mpad>
Thu 30 Apr 2015 05:05:46 PM UTC, comment #30:

Well, I am one of those who has complained a lot about
the API and other incompatibilities with llvm. But, there
is a very definite need to improve Octave performance.

So, giving up on llvm should only be done if something better
can be found. Right now llvm seems to be the "mainstream"
system -- it is a part of clang for instance.

Also, some of the benefits of JIT have not been realized.
The current implementation is incomplete.

It would be good if someone could be found to do more
work on it.

Michael Godfrey <godfrey>
Thu 30 Apr 2015 02:44:27 PM UTC, comment #29:

We probably should drop the JIT compiler white elephant at this point. It has turn out to be a huge annoyance for almost no benefit.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Thu 30 Apr 2015 02:27:32 AM UTC, comment #28:

Oh so LLVM 3.5 and newer requires C++11 now?

I've been thinking it might be time to conditionally add the compiler flags needed to enable C++11 if the compiler supports it.

Just opened bug #44965, adding as a dependency.

Mike Miller <mtmiller>
Project Member
Thu 30 Apr 2015 01:44:43 AM UTC, comment #27:

On Fedora 21 this patch works after one minor
patch and a number of new warnings.

It obviously needs more work, but should be
kept around as a valid base for llvm 3.5 support.

Make check result was:

PASS 13002
FAIL 0
XFAIL 14
SKIPPED 1

Michael Godfrey <godfrey>
Wed 29 Apr 2015 06:06:12 PM UTC, comment #26:

The use of '-std=c++11' isn't supported by some, just modestly old, gcc versions like 4.6. Rather than just adding it to the LLVM flags in configure.ac, I think one would need more extensive tests in configure to determine if LLVM3.5 is being used AND if the compiler supports it.

LLVM has been incredibly bad about changing their API all the time resulting in lots of failures to compile perfectly good old code. They really seem to scoff at the concept of code re-use.

Anyways, after applying the patch the JIT code fails to compile with LLVM3.2. This can be fixed, but it would need more work with configure.ac and using #ifdefs in the code to support the multiple versions of LLVM.

Rik <rik5>
Project Administrator
Wed 29 Apr 2015 01:43:37 PM UTC, comment #25:

Added file #33837

make check:
jit.tst ..................................................... PASS 42/44
XFAIL 2

Anonymous
Mon 02 Feb 2015 04:23:03 AM UTC, comment #24:

Re-titling to reflect the remaining problem is with LLVM 3.5. I've lowered the Priority and Severity since LLVM is only required for JIT which isn't going to be a gating item for the 4.0 release.

Rik <rik5>
Project Administrator
Thu 01 Jan 2015 09:08:05 PM UTC, comment #23:

A bit more information: After setting,
CPPFLAGS=-std=c++11
./configure --enable-jit
make
gets to:

from corefcn/jit-typeinfo.cc:46:
/usr/include/llvm/ADT/Twine.h: In constructor 'jit_typeinfo::jit_typeinfo(llvm::Module, llvm::ExecutionEngine)':
/usr/include/llvm/ADT/Twine.h:187:12: error: 'llvm::Twine& llvm::Twine::operator=(const llvm::Twine&)' is private
Twine &operator=(const Twine &Other) LLVM_DELETED_FUNCTION;
^
corefcn/jit-typeinfo.cc:1211:15: error: within this context
fn_name = fn_name + llvm::Twine (op);
^
corefcn/jit-typeinfo.cc:1211:15: error: use of deleted function 'llvm::Twine& llvm::Twine::operator=(const llvm::Twine&)'
In file included from /usr/include/llvm/IR/GlobalVariable.h:23:0,
from corefcn/jit-typeinfo.cc:46:
/usr/include/llvm/ADT/Twine.h:187:12: note: declared here
Twine &operator=(const Twine &Other) LLVM_DELETED_FUNCTION;
===============================
So, a code change is needed.

Michael Godfrey <godfrey>
Sat 20 Dec 2014 10:54:18 PM UTC, comment #22:

It was hoped that the patch below would work for the
llvm 3.5 release, but it does not, from onfig.log:

3693: configure:15342: g++ -c -g -O2 -pthread -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -isystem /usr/include conftest.cpp >&5
3694: In file included from /usr/include/c++/4.9.2/type_traits:35:0,
3695: from /usr/include/llvm/Support/MathExtras.h:21,
3696: from /usr/include/llvm/ADT/SmallVector.h:20,
3697: from /usr/include/llvm/ADT/ArrayRef.h:14,
3698: from /usr/include/llvm/IR/Attributes.h:19,
3699: from /usr/include/llvm/IR/Argument.h:19,
3700: from /usr/include/llvm/IR/Function.h:22,
3701: from conftest.cpp:83:
3702: /usr/include/c++/4.9.2/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
3703: #error This file requires compiler and library support for the \
3704: ^

Michael Godfrey <godfrey>
Sun 15 Jun 2014 04:52:44 AM UTC, comment #21:

I applied Stefan's patch to development branch. Closing report.

Rik <rik5>
Project Administrator
Sun 11 May 2014 08:04:20 PM UTC, comment #20:

This patch works correctly on current Fedora 20
using llvm 3.4.6

Michael Godfrey <godfrey>
Sun 11 May 2014 10:20:11 AM UTC, comment #19:

If this patch is likely to work for the 3.5 release
it might be helpful to push it to the dev system.

I will verity that it works for the current Fedora 20 (3.4).

Michael Godfrey <godfrey>
Sun 11 May 2014 09:12:40 AM UTC, comment #18:

I forgot to mention: Tested on Ubuntu 14.04 with LLVM 3.4 (default LLVM) and LLVM 3.3 and 3.5 as alternative build (LLVM_CONFIG=llvm-config-3.3/3.5)

Stefan Mahr <dac922>
Sun 11 May 2014 09:10:49 AM UTC, comment #17:

I added autoconf checks to queueram's patch and an additional headerfile check for LLVM 3.5 pre version as distributed with Ubuntu 14.04.

Patch is attached and can be found here too: http://inversethought.com/hg/octave-nkf/rev/81472221adc3

(file #31351)

Stefan Mahr <dac922>
Mon 21 Apr 2014 10:35:33 PM UTC, comment #16:

Now that Fedora 20 has been updated to llvm
3.4.6 the patch (#30296) below is needed to
compile the current dev system with
--enable-jit. The system builds and
passes make check. The patch finds the
"legacy" files needed to make 3.4 act like
3.3. So, it is definitely not a long-term
solution.

However, note that this patch will cause
systems using llvm < 3.4 to fail to build.

Probably should check on when 3.5 is coming
so as not to waste too much time trying to
track the effervescent llvm.

Michael Godfrey <godfrey>
Tue 01 Apr 2014 08:41:06 PM UTC, comment #15:

Exactly, JIT is experimental, and LLVM 3.5 will probably bring a new set of incompatible changes, and I'm not very motivated to work on this :)

Mike Miller <mtmiller>
Project Member
Tue 01 Apr 2014 05:18:04 PM UTC, comment #14:

If you think you can make the changeset work then go ahead and commit it. Otherwise, JIT is experimental and I wouldn't spend too much time on it until we have someone who wants to work on that section of code.

Rik <rik5>
Project Administrator
Tue 01 Apr 2014 02:33:21 PM UTC, comment #13:

Just noting that I have done a test build using this proof-of-concept patch and LLVM 3.4 and it works for me (Debian unstable). In Debian we will either have to adapt Octave to build for LLVM 3.4 or turn off JIT completely, since there is a library conflict with the Mesa graphics stack now being linked with LLVM 3.4.

Mike Miller <mtmiller>
Project Member
Fri 17 Jan 2014 02:37:18 PM UTC, comment #12:

> Note that this patch will break building with LLVM < 3.4, but
> perhaps someone with more understanding of the octave build system
> can clean it up so that it still builds successfully with older LLVM
> versions.


Yeah, it's not that difficult to figure out how to adapt to the latest version of their ever-changing API. It's more difficult to adapt to all of them at once. Can you please look at the following commits for examples of what needs to be done in order to support all LLVM versions at once?

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Fri 17 Jan 2014 12:50:02 AM UTC, comment #11:

The LLVM folks appear to have made significant changes to the PassManager class to warrant moving the 3.3 one into a 'legacy' namespace in 3.4. I didn't see anything in the release notes or documentation, but these changes are evident in the header files. I'm attaching a patch file that allows octave 3.8.0 to be built against LLVM 3.4 under Arch Linux. Note that this patch will break building with LLVM < 3.4, but perhaps someone with more understanding of the octave build system can clean it up so that it still builds successfully with older LLVM versions.

(file #30296)

M.S. <queueram>
Thu 16 Jan 2014 09:53:49 PM UTC, comment #10:

Compiling against LLVM 3.0 works. (Recently tested with armel/debian wheezy.)

Stefan Mahr <dac922>
Thu 16 Jan 2014 07:37:32 PM UTC, comment #9:

We definitely support LLVM 3.2 and 3.3. I personally don't know about LLVM 3.0 or 3.1. We definitely fail to compile against LLVM 2.9, 3.4, and 3.5.

Mike Miller <mtmiller>
Project Member
Thu 16 Jan 2014 06:00:14 PM UTC, comment #8:

What is the current situation with Octave? I know we don't build with LLVM < 3.0. Do we build with LLVM 3.0? I see from cset 36fd98b9ce48 that Max added support for LLVM 3.3 so I think we might work only with 3.1, 3.2, and 3.3.

Rik <rik5>
Project Administrator
Thu 16 Jan 2014 02:53:14 AM UTC, comment #7:

Either way, confirmed that I get the same set of errors with LLVM 3.4 (as packaged for Debian). Retitling to reflect this.

Mike Miller <mtmiller>
Project Member
Wed 15 Jan 2014 05:59:31 PM UTC, comment #6:

Right, it is very foolish that the LLVM folks
live in their own world where changing the API
and file locations, etc., even within a "release"
does not matter.

But, the libgccjit seems right now to be just beyond
an idea. When it may become defined and stable is not
clear.

Our present JIT, but only for x86 and subject to
the continuing configuration and API issues, does
actually work, at least for me.

So, maybe patience is required for a while.

And, someone might ask the LLVM folks if they ever
plan to support users like us. And, if so, how.

Michael Godfrey <godfrey>
Wed 15 Jan 2014 03:14:00 PM UTC, comment #5:

I think we might want work towards using something other than LLVM. It's ridiculous that every damn LLVM release is breaking their API. Our autoconf checks are getting stupid. They obviously do not want anyone but themselves to be using LLVM as a JIT library.

We wouldn't lose much at this point. It's not like our JIT is compiling any interesting loops. There's libgccjit, which is kind of experimental right now, but might be a perfect fit for us.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Wed 15 Jan 2014 02:34:11 PM UTC, comment #4:

Hmm, could be. I went back to an earlier bug that was about porting to 3.3 and 3.4, but apparently I had been testing a 3.4 svn prerelease at the time. I'll have to do another test build with 3.4 now to confirm.

Mike Miller <mtmiller>
Project Member
Wed 15 Jan 2014 09:41:08 AM UTC, comment #3:

I compiled today with the llvm binary shipped with my distribution (ArchLinux); that is 3.4 according to llvm-config --version and was released on 02 Jan 2014 [1].

I get the same errors with this - stable - version.

[1] http://llvm.org/releases/

Lasse Schuirmann <sils1297>
Thu 02 Jan 2014 05:07:45 PM UTC, comment #2:

I lowered the priority to "later". LLVM seems to drastically change their API for every release and it is a pain in the ass to keep up with. When they have a stable release we can think about modifying Octave to build with it.

Rik <rik5>
Project Administrator
Thu 02 Jan 2014 03:21:22 AM UTC, comment #1:

Confirmed on the development version as well, attempting to build on Debian testing with LLVM 3.5. Yet another API change. LLVM 3.5 is not yet released, there is probably not much point attempting to chase their in-development API changes until it is a stable release.

Mike Miller <mtmiller>
Project Member
Wed 01 Jan 2014 10:28:03 PM UTC, original submission:

This is the first time I cannot build Octave on RedHat/Fedora system. The problem resides in LLVM/JIT related files.
RedHat 6.4, 64 bit
The very fresh LLVM/CLang distribution (3.5) compiled from the source (the version compiled few months ago had the same failure).
./configure --prefix=/home/albert/soft/octave
make
...
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -I../liboctave/cruft/misc -I../liboctave/array -I../liboctave/numeric -I../liboctave/numeric -I../liboctave/operators -I../liboctave/operators -I../liboctave/system -I../liboctave/util -I./octave-value -I./operators -Iparse-tree -I./parse-tree -Icorefcn -I./corefcn -I../libgnu -I../libgnu -I/usr/include/freetype2 -isystem /usr/local/include -Wall -W -Wshadow -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -g -O2 -pthread -MT corefcn/corefcn_libcorefcn_la-pt-jit.lo -MD -MP -MF corefcn/.deps/corefcn_libcorefcn_la-pt-jit.Tpo -c corefcn/pt-jit.cc -fPIC -DPIC -o corefcn/.libs/corefcn_libcorefcn_la-pt-jit.o
In file included from corefcn/pt-jit.cc:55:
/usr/local/include/llvm/PassManager.h:34: error: 'PassManager' is already declared in this scope
/usr/local/include/llvm/PassManager.h:35: error: 'FunctionPassManager' is already declared in this scope
corefcn/pt-jit.cc: In member function 'bool tree_jit::initialize()':
corefcn/pt-jit.cc:1891: error: cannot convert 'llvm::legacy::PassManager' to 'llvm::PassManager' in assignment
corefcn/pt-jit.cc:1892: error: invalid use of incomplete type 'struct llvm::PassManager'
corefcn/jit-util.h:46: error: forward declaration of 'struct llvm::PassManager'
corefcn/pt-jit.cc:1894: error: cannot convert 'llvm::legacy::FunctionPassManager' to 'llvm::FunctionPassManager' in assignment
corefcn/pt-jit.cc:1896: error: invalid use of incomplete type 'struct llvm::FunctionPassManager'
corefcn/jit-util.h:45: error: forward declaration of 'struct llvm::FunctionPassManager'
corefcn/pt-jit.cc:1900: error: invalid use of incomplete type 'struct llvm::FunctionPassManager'
corefcn/jit-util.h:45: error: forward declaration of 'struct llvm::FunctionPassManager'
corefcn/pt-jit.cc:1901: error: invalid use of incomplete type 'struct llvm::FunctionPassManager'
corefcn/jit-util.h:45: error: forward declaration of 'struct llvm::FunctionPassManager'
corefcn/pt-jit.cc:1902: error: invalid use of incomplete type 'struct llvm::FunctionPassManager'
corefcn/jit-util.h:45: error: forward declaration of 'struct llvm::FunctionPassManager'
corefcn/pt-jit.cc:1903: error: invalid use of incomplete type 'struct llvm::FunctionPassManager'
corefcn/jit-util.h:45: error: forward declaration of 'struct llvm::FunctionPassManager'
corefcn/pt-jit.cc:1904: error: invalid use of incomplete type 'struct llvm::FunctionPassManager'
corefcn/jit-util.h:45: error: forward declaration of 'struct llvm::FunctionPassManager'
corefcn/pt-jit.cc:1905: error: invalid use of incomplete type 'struct llvm::FunctionPassManager'
corefcn/jit-util.h:45: error: forward declaration of 'struct llvm::FunctionPassManager'
corefcn/pt-jit.cc:1906: error: invalid use of incomplete type 'struct llvm::FunctionPassManager'
corefcn/jit-util.h:45: error: forward declaration of 'struct llvm::FunctionPassManager'
corefcn/pt-jit.cc:1907: error: invalid use of incomplete type 'struct llvm::FunctionPassManager'
corefcn/jit-util.h:45: error: forward declaration of 'struct llvm::FunctionPassManager'
corefcn/pt-jit.cc: In member function 'void tree_jit::optimize(llvm::Function*)':
corefcn/pt-jit.cc:2003: error: invalid use of incomplete type 'struct llvm::PassManager'
corefcn/jit-util.h:46: error: forward declaration of 'struct llvm::PassManager'
corefcn/pt-jit.cc:2004: error: invalid use of incomplete type 'struct llvm::FunctionPassManager'
corefcn/jit-util.h:45: error: forward declaration of 'struct llvm::FunctionPassManager'
corefcn/pt-jit.cc:2010: error: 'F_Binary' is not a member of 'llvm::raw_fd_ostream'
make[3]: *** [corefcn/corefcn_libcorefcn_la-pt-jit.lo] Error 1
make[3]: Leaving directory `/home/albert/Downloads/octave-3.8.0/libinterp'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/albert/Downloads/octave-3.8.0/libinterp'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/albert/Downloads/octave-3.8.0'
make: *** [all] Error 2

Albert <aaahaaah>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #33887:  llvm-3.5.0_4.patch added by mpad (4kB - text/x-patch - patch for octave 4.0.0-rc3 to build against LLVM 3.5 (checks if gcc accepts -std=c++11 ))
file #33888:  ax_compare_version.m4 added by mpad (6kB - application/x-m4 - patch for octave 4.0.0-rc3 to build against LLVM 3.5 (checks if gcc accepts -std=c++11 ))
file #33878:  llvm-3.5.0_3.patch added by mpad (4kB - text/x-patch - patch for octave 4.0.0-rc3 to build against LLVM 3.5)
file #33858:  llvm-3.5.0_2.patch added by mpad (3kB - text/x-patch - patch for octave 4.0.0-rc3 to build against LLVM 3.5))
file #33859:  llvm-3.5.0_gnulib-hg.patch added by mpad (431B - text/x-patch - patch for octave 4.0.0-rc3 to build against LLVM 3.5))
file #33837:  llvm-3.5.0.patch added by None (3kB - text/x-patch - patch for octave 4.0.0-rc3 to build against LLVM 3.5)
file #31351:  llvm-3.4-3.5pre.patch added by dac922 (7kB - text/x-patch)
file #30296:  llvm-3.4.patch added by queueram (2kB - application/octet-stream - patch for octave 3.8.0 to build against LLVM 3.4)
file #30144:  config.output.txt added by aaahaaah (68kB - text/plain - Output of configuration script)

 

Digest:
   bug dependencies.

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -unavailable- added by mpad (Updated the item)
  • -unavailable- added by queueram (Updated the item)
  • -unavailable- added by dac922 (Posted a comment)
  • -unavailable- added by godfrey (Posted a comment)
  • -unavailable- added by jordigh (Posted a comment)
  • -unavailable- added by jordigh
  • -unavailable- added by sils1297 (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by aaahaaah (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 24 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 03 May 2015 08:53:25 PM UTCmpadAttached File-=>Added llvm-3.5.0_4.patch, #33887
      Attached File-=>Added ax_compare_version.m4, #33888
    Sat 02 May 2015 12:29:19 PM UTCmpadAttached File-=>Added llvm-3.5.0_3.patch, #33878
    Fri 01 May 2015 09:08:44 PM UTCmtmillerStatusNone=>Postponed
    Fri 01 May 2015 08:12:13 PM UTCmpadAttached File-=>Added llvm-3.5.0_2.patch, #33858
      Attached File-=>Added llvm-3.5.0_gnulib-hg.patch, #33859
    Thu 30 Apr 2015 02:27:32 AM UTCmtmillerDependencies-=>Depends on bugs #44965
    Wed 29 Apr 2015 01:40:23 PM UTCNoneAttached File-=>Added llvm-3.5.0.patch, #33837
    Mon 27 Apr 2015 01:44:15 PM UTCmtmillerDependencies-=>bugs #44937 is dependent
    Mon 02 Feb 2015 04:23:03 AM UTCrik5Severity3 - Normal=>1 - Wish
      SummaryOctave fails to build with LLVM 3.4 and 3.5-pre-release=>Octave fails to build with LLVM 3.5
    Fri 02 Jan 2015 02:54:45 AM UTCrik5StatusFixed=>None
      Open/ClosedClosed=>Open
    Sun 15 Jun 2014 04:52:44 AM UTCrik5StatusConfirmed=>Fixed
      Open/ClosedOpen=>Closed
    Sun 11 May 2014 09:10:49 AM UTCdac922Attached File-=>Added llvm-3.4-3.5pre.patch, #31351
    Fri 17 Jan 2014 12:50:02 AM UTCqueueramAttached File-=>Added llvm-3.4.patch, #30296
    Thu 16 Jan 2014 02:53:14 AM UTCmtmillerSummaryOctave fails to build with LLVM 3.5 (pre-release)=>Octave fails to build with LLVM 3.4 and 3.5-pre-release
    Wed 15 Jan 2014 03:14:00 PM UTCjordighCarbon-Copy-=>Added david malcolm
    Thu 02 Jan 2014 05:07:45 PM UTCrik5Priority5 - Normal=>1 - Later
    Thu 02 Jan 2014 03:21:22 AM UTCmtmillerStatusNone=>Confirmed
      Release3.8.0=>dev
      SummaryLLVM problem=>Octave fails to build with LLVM 3.5 (pre-release)
    Wed 01 Jan 2014 10:28:03 PM UTCaaahaaahAttached File-=>Added config.output.txt, #30144

    Back to the top


    Powered by Savane 3.1-cleanup