similar to: [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++/

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

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

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

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=*:

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

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

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.

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

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 =

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 >

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;

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

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

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

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

> This means that I don't have a working llvm-gcc with TOT either. I get the same thing on x86-32. Ciao, Duncan.

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:

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,

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.