similar to: [LLVMdev] gfortran link failure in current llvm svn

Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] gfortran link failure in current llvm svn"

2008 Oct 31
3
[LLVMdev] gfortran link failure in current llvm svn
On Oct 30, 2008, at 11:02 PM, Chris Lattner wrote: > On Oct 30, 2008, at 5:23 PM, Jack Howarth wrote: >> ps We do have one oddity left in llvm-gfortran from current llvm >> svn. I find everytime I compile something with llvm-gfortran that >> I get a series of warning messages... >> >> f951: warning: command line option "-Wformat" is valid for C/C++/
2008 Oct 31
0
[LLVMdev] gfortran link failure in current llvm svn
On Oct 30, 2008, at 5:23 PM, Jack Howarth wrote: > ps We do have one oddity left in llvm-gfortran from current llvm > svn. I find everytime I compile something with llvm-gfortran that > I get a series of warning messages... > > f951: warning: command line option "-Wformat" is valid for C/C++/ > ObjC/ObjC++ but not for Fortran > f951: warning: command line option
2008 Oct 31
0
[LLVMdev] gfortran link failure in current llvm svn
On Thu, Oct 30, 2008 at 5:23 PM, Jack Howarth <howarth at bromo.msbb.uc.edu> wrote: > Chris and Bill, > I have tested the proposed patch from... > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-August/016490.html > > under i686-apple-darwin9 and it solves the problems building gfortran > from llvm svn. The resulting compiler works fine so can we get that > patch
2008 Oct 31
1
[LLVMdev] gfortran link failure in current llvm svn
On Thu, Oct 30, 2008 at 05:38:30PM -0700, Bill Wendling wrote: > On Thu, Oct 30, 2008 at 5:23 PM, Jack Howarth <howarth at bromo.msbb.uc.edu> wrote: > > Chris and Bill, > > I have tested the proposed patch from... > > > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-August/016490.html > > > > under i686-apple-darwin9 and it solves the problems
2008 Oct 31
1
[LLVMdev] r57326 malfunctions?
Looking back through the commits to llvm-gcc-4.2/trunk/gcc/config/i386/darwin.h, I see a total backout of format related warnings in r56923 followed by the reapplication of r569065 with a fix (r56946)... -- llvm-gcc-4.2/trunk/gcc/config/i386/darwin.h 2008/10/01 17:38:40 56923 +++ llvm-gcc-4.2/trunk/gcc/config/i386/darwin.h 2008/10/02 06:16:08 56946 @@ -101,6 +101,8 @@ %{!mmacosx-version-min=*:
2009 Jan 19
5
[LLVMdev] llvm/llvm-gcc-4.2 svn still produces -Wformat/-Wformat-security
The current llvm/llvm-gcc-4.2 svn when built on i686-apple-darwin9 still produces the bogus warnings... f951: warning: command line option "-Wformat" is valid for C/C++/ObjC/ObjC++ but not for Fortran f951: warning: command line option "-Wformat-security" is valid for C/C++/ObjC/ObjC++ but not for Fortran whenc compling any code with gfortran. This causes the gfortran
2009 Jan 19
0
[LLVMdev] llvm/llvm-gcc-4.2 svn still produces -Wformat/-Wformat-security
Hi Jack, Because of the new changes and the fact that we have only 2 days before branching for 2.5, please retest the Fortran front end as soon as you can to see if the problem has been resolved. Thanks! -bw On Sun, Jan 18, 2009 at 5:11 PM, Jack Howarth <howarth at bromo.med.uc.edu> wrote: > The current llvm/llvm-gcc-4.2 svn when built on > i686-apple-darwin9 still produces the
2008 Oct 31
0
[LLVMdev] gfortran link failure in current llvm svn
On Oct 31, 2008, at 9:44 AM, Devang Patel wrote: >>> f951: warning: command line option "-Wformat" is valid for C/C++/ >>> ObjC/ObjC++ but not for Fortran > Try this not so elegant and untested patch. I'd not expect this to work for Ada, java or Pascal.
2018 Mar 19
2
objc++ enhancements?
hi. Is there interest in enhancing the objc++ compiler to make objc mechanisms friendly to the newer features of c++? For instance... 1) making blocks movable so that they can capture things like unique_ptr<> and still be moved off the stack 2) making @property declarations work with move-only types like unique_ptr<> 3) enabling std::weak_ptr<> to weakly store an objc pointer
2020 Jun 07
5
use of the tcltk package crashes R 4.0.1 for Windows
So this wasn't tested for a month? Anyways, Free() is just free() with a check that we're not freeing a null pointer, followed by setting the pointer to NULL. At that point of tcltk.c, we have for (objc = i = 0; i < length(avec); i++){ const char *s; char *tmp; if (!isNull(nm) && strlen(s = translateChar(STRING_ELT(nm, i)))){ // tmp =
2012 Jun 20
2
[LLVMdev] Exception handling slowdown?
Did something change with exception handling recently? A bunch of lit bots are showing slower compile times for many tests. Ciao, Duncan. On 20/06/12 07:53, llvm-testresults at cs.uiuc.edu wrote: > > lab-mini-03__O0-g__clang_DEV__x86_64 test results > <http://llvm.org/perf/db_default/v4/nts/1283?compare_to=1278&baseline=999> > > Run Order Start Time Duration >
2020 Jun 07
3
[External] Re: use of the tcltk package crashes R 4.0.1 for Windows
On Sun, Jun 7, 2020 at 5:53 PM <luke-tierney at uiowa.edu> wrote: > > On Sun, 7 Jun 2020, peter dalgaard wrote: > > > So this wasn't tested for a month? > > > > Anyways, Free() is just free() with a check that we're not freeing a null pointer, followed by setting the pointer to NULL. At that point of tcltk.c, we have > > > > for (objc = i = 0;
2011 Sep 05
3
[LLVMdev] [MacOSX] make check failures
Hi, I built LLVM + Clang on Mac OS X and ran make check. I get the following result summary: Failing Tests (11): LLVM :: LLVMC/C++/dash-x.cpp LLVM :: LLVMC/C++/hello.cpp LLVM :: LLVMC/C++/just-compile.cpp LLVM :: LLVMC/C++/together.cpp LLVM :: LLVMC/C++/unknown_suffix.unk LLVM :: LLVMC/C/hello.c LLVM :: LLVMC/C/opt-test.c LLVM :: LLVMC/C/sink.c LLVM ::
2012 Jun 25
0
[LLVMdev] Exception handling slowdown?
Nothing that I'm aware of has changed with EH. Is it possible to bisect the problem? -bw On Jun 20, 2012, at 12:38 AM, Duncan Sands <baldrick at free.fr> wrote: > Did something change with exception handling recently? A bunch of lit bots are > showing slower compile times for many tests. > > Ciao, Duncan. > > On 20/06/12 07:53, llvm-testresults at cs.uiuc.edu
2012 Jul 05
2
[LLVMdev] Exception handling slowdown?
Hi Bill, > Nothing that I'm aware of has changed with EH. Is it possible to bisect the problem? I don't see any relevant LLVM changes, so I guess clang C++ compilation slowed down due to some clang changes. I'm not going to investigate this. Ciao, Duncan. > > -bw > > On Jun 20, 2012, at 12:38 AM, Duncan Sands <baldrick at free.fr> wrote: > >> Did
2018 Mar 19
0
objc++ enhancements?
Hi James, Non-Apple people can’t “see radar”. Do you work at Apple? In either case, the clang development email list would be the right start for this. Also, if you work at Apple, please consider reaching out to the DevTools department directly. Dave > On Mar 19, 2018, at 12:21, James Gregurich via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > hi. > > Is there interest
2008 Oct 01
3
[LLVMdev] llvm-gcc linux build broken
> This means that I don't have a working llvm-gcc with TOT either. I get the same thing on x86-32. Ciao, Duncan.
2008 Oct 01
0
[LLVMdev] llvm-gcc linux build broken
On 2008-10-01 18:55, Duncan Sands wrote: >> This means that I don't have a working llvm-gcc with TOT either. >> > > I get the same thing on x86-32. > > Ciao, > > Duncan. > HAVE_STDLIB_H is not defined, which causes a 'char* malloc()' definition in cplus-dem.c. >From config.log: configure:8421: checking for stdlib.h configure:8461: result:
2012 Oct 02
5
[LLVMdev] adding support for -ffixed-<reg>
I'm adding support for -ffixed-<reg> <http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Code-Gen-Options.html#index-ffixed-1435> for Hexagon and was wondering if I should do it in such a way that other targets get the support as well by default or if a given target back-end should have to explicitly opt-in for support. Any opinions? Matthew Curtis. -- Qualcomm Innovation Center,
2019 Jan 04
2
[RFC] Allocatable Global Register Variables for ARM
Thank you for your reply Eli, I too was working with Carey on this feature, so please let me reply. On 12/21/18 8:05 PM, Friedman, Eli via llvm-dev wrote: > As a side-note, you might want to check that prologue/epilogue emission won't emit a PUSH/POP that refers to a register reserved this way; we sometimes add an "extra" register to align the stack. Yes, you are right.