[llvm-commits] CVS: llvm/tools/llvm-config/Makefile
Changes in directory llvm/tools/llvm-config: Makefile updated: 1.21 -> 1.22 --- Log message: Run GenLibDeps.pl with the configured PERL path to handle different install locations for Perl on different systems. --- Diffs of the changes: (+1 -1) Makefile |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Index: llvm/tools/llvm-config/Makefile diff -u llvm/tools/llvm-config/Makefile:1.21 llvm/tools/llvm-config/Makefile:1.22 --- llvm/tools/llvm-config/Makefile:1.21Mon Jan 8 20:38:29 2007 +++ llvm/tools/llvm-config/Makefile Sun Jan 21 09:53:18 2007 @@ -35,7 +35,7 @@ $(LibDepsTemp): $(GenLibDeps) $(LibDir) $(wildcard $(LibDir)/*.a $(LibDir)/*.o) $(Echo) "Regenerating LibDeps.txt.tmp" - $(Verb) $(GenLibDeps) -flat $(LibDir) $(NM_PATH) > $(LibDepsTemp) + $(Verb) $(PERL) $(GenLibDeps) -flat $(LibDir) $(NM_PATH) > $(LibDepsTemp) $(LibDeps): $(LibDepsTemp) $(Verb) $(CMP) -s $@ $< || ( $(CP) $< $@ && \ ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] Repository is broken
cvs update: cannot open directory /var/cvs/llvm/llvm/test/Regression: No such file or directory cvs update: skipping directory test/Regression ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] Repository is broken
On Jan 21, 2007, at 14:23, Jeff Cohen wrote: > cvs update: cannot open directory /var/cvs/llvm/llvm/test/ > Regression: No > such file or directory > cvs update: skipping directory test/Regression It's empty or gone in the repository. Just delete the directory locally. — Gordon ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [PATCH] PR746: Make Function not annotatable and get rid of Annotations
This patch addresses http://llvm.org/PR746. This patch simply replaces the subversive and overgeneralized annotation classes with a map in MachineFunction and a listener interface so that MachineFunctions can destroy themselves when the parent Function is deleted. I wish I'd noticed PR746 before http://llvm.org/PR927. Not sure you'll want to apply this patch in light of the comments on this PR746, which suggest using an Analysis to store MachineFunctions, and thus to also manage their lifetimes. — Gordon replace-annotation-with-listener.patch Description: Binary data ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] Major regressions
In the two weeks since I last ran them, the regression tests have gone from 4 to 63 unexpected failures. Is this expected? ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] Repository is broken
On Sun, 2007-01-21 at 14:32 -0500, Gordon Henriksen wrote: > On Jan 21, 2007, at 14:23, Jeff Cohen wrote: > > > cvs update: cannot open directory /var/cvs/llvm/llvm/test/ > > Regression: No > > such file or directory > > cvs update: skipping directory test/Regression > > It's empty or gone in the repository. Just delete the directory locally. Yeah, unfortunately this was a consequence of the files being mv'd instead of cp'd. So, there was never a "cvs rm" to remove the Regression directory. Gordon is correct though, just blow away your local copy. > > — Gordon > > > ___ > llvm-commits mailing list > llvm-commits@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] Major regressions
On Sun, 2007-01-21 at 12:01 -0800, Jeff Cohen wrote: > In the two weeks since I last ran them, the regression tests have gone > from 4 to 63 unexpected failures. Is this expected? No, TOT gives me 6 right now .. 5 in the new ARM backend (be patient) and 1 in the X86 backend. > > ___ > llvm-commits mailing list > llvm-commits@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] Major regressions
Well, I'm using the most recent version of both llvm and llvm-gcc (revision 254). 21 of the failures are ARM, but I don't care about those. llvm-test is still running, but it's on track to matching the 275 failures I got the last time I ran it. I'm not going to switch to Linux or OS X or even 32-bit FreeBSD, and I'm not going to spend the time figuring out why LLVM hates 64-bit FreeBSD--especially as it's getting worse, not better--and it's clear no one else is going to spend the time either. So I'm putting LLVM back on hold until later this year and hopefully the situation will be better then. Reid Spencer wrote: > On Sun, 2007-01-21 at 12:01 -0800, Jeff Cohen wrote: > >> In the two weeks since I last ran them, the regression tests have gone >> from 4 to 63 unexpected failures. Is this expected? >> > > No, TOT gives me 6 right now .. 5 in the new ARM backend (be patient) > and 1 in the X86 backend. > > >> ___ >> llvm-commits mailing list >> llvm-commits@cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits >> > > > > > ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] llvm-gcc4: resurrect fortran
> > + $(F95_OBJS) $(F95_BACKEND) $(F95_LIBS) $(C_STUBS)
>
> I don't see C_STUBS anywhere.
Indeed - well spotted.
> Would it be possible for you to resend
> this patch with appropriate "APPLE LOCAL llvm" markers ?
This time without C_STUBS and with markers.
Best wishes,
Duncan.
Index: gcc.llvm.master/gcc/fortran/Make-lang.in
===
--- gcc.llvm.master.orig/gcc/fortran/Make-lang.in 2007-01-21
22:50:53.0 +0100
+++ gcc.llvm.master/gcc/fortran/Make-lang.in2007-01-21 23:01:06.0
+0100
@@ -103,12 +103,16 @@
-rm -f gfortran-cross$(exeext)
cp gfortran$(exeext) gfortran-cross$(exeext)
+# APPLE LOCAL begin llvm
+# Language-independent object files.
+F95_BACKEND = $(BACKEND) attribs.o stub-objc.o stub-c.o
+
# The compiler itself is called f951.
f951$(exeext): $(F95_OBJS) \
- $(BACKEND) $(LIBDEPS)
- # APPLE LOCAL LLVM
+ $(F95_BACKEND) $(LIBDEPS)
$(LINKCC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ \
- $(F95_OBJS) $(BACKEND) $(F95_LIBS)
+ $(F95_OBJS) $(F95_BACKEND) $(F95_LIBS)
+# APPLE LOCAL end llvm
gt-fortran-f95-lang.h gtype-fortran.h: s-gtype; @true
gt-fortran-trans-decl.h gt-fortran-trans.h: s-gtype; @true
Index: gcc.llvm.master/gcc/fortran/f95-lang.c
===
--- gcc.llvm.master.orig/gcc/fortran/f95-lang.c 2007-01-21 22:50:53.0
+0100
+++ gcc.llvm.master/gcc/fortran/f95-lang.c 2007-01-21 22:59:51.0
+0100
@@ -154,21 +154,6 @@
/* APPLE LOCAL disable_typechecking_for_spec_flag */
int disable_typechecking_for_spec_flag = 0;
-/* APPLE LOCAL begin CW asm blocks */
-/* Dummies needed because we use them from cpplib, yuck. */
-int flag_iasm_blocks;
-int iasm_state;
-int iasm_in_operands;
-/* APPLE LOCAL end CW asm blocks */
-
-/* APPLE LOCAL begin 4174833 */
-tree
-objc_is_class_name (tree ARG_UNUSED (arg))
-{
- return 0;
-}
-
-/* APPLE LOCAL end 4174833 */
/* A list (chain of TREE_LIST nodes) of all LABEL_DECLs in the function
that have names. Here so we can clear out their names' definitions
at the end of the function. */
Index: gcc.llvm.master/gcc/fortran/trans-types.c
===
--- gcc.llvm.master.orig/gcc/fortran/trans-types.c 2007-01-21
22:50:53.0 +0100
+++ gcc.llvm.master/gcc/fortran/trans-types.c 2007-01-21 22:59:51.0
+0100
@@ -1752,18 +1752,4 @@
/* APPLE LOCAL constant cfstrings */
struct cpp_reader* parse_in;
-/* APPLE LOCAL begin AltiVec */
-tree
-build_stmt (enum tree_code code ATTRIBUTE_UNUSED, ...)
-{
- gcc_assert(0);
-}
-
-void
-store_init_value (tree decl ATTRIBUTE_UNUSED, tree init ATTRIBUTE_UNUSED)
-{
- gcc_assert(0);
-}
-/* APPLE LOCAL end AltiVec */
-
#include "gt-fortran-trans-types.h"
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] Major regressions
On Jan 21, 2007, at 2:01 PM, Jeff Cohen wrote: > Well, I'm using the most recent version of both llvm and llvm-gcc > (revision 254). 21 of the failures are ARM, but I don't care about > those. llvm-test is still running, but it's on track to matching the > 275 failures I got the last time I ran it. > > I'm not going to switch to Linux or OS X or even 32-bit FreeBSD, > and I'm > not going to spend the time figuring out why LLVM hates 64-bit > FreeBSD--especially as it's getting worse, not better--and it's > clear no > one else is going to spend the time either. So I'm putting LLVM > back on > hold until later this year and hopefully the situation will be > better then. Fair enough. However, unless *someone* on 64-bit freebsd investigates, it won't get better. There is not much we can do about this. -Chris ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] Major regressions
Chris Lattner wrote: > > On Jan 21, 2007, at 2:01 PM, Jeff Cohen wrote: > >> Well, I'm using the most recent version of both llvm and llvm-gcc >> (revision 254). 21 of the failures are ARM, but I don't care about >> those. llvm-test is still running, but it's on track to matching the >> 275 failures I got the last time I ran it. >> >> I'm not going to switch to Linux or OS X or even 32-bit FreeBSD, and I'm >> not going to spend the time figuring out why LLVM hates 64-bit >> FreeBSD--especially as it's getting worse, not better--and it's clear no >> one else is going to spend the time either. So I'm putting LLVM back on >> hold until later this year and hopefully the situation will be better >> then. > > Fair enough. However, unless *someone* on 64-bit freebsd > investigates, it won't get better. There is not much we can do about > this. > > -Chris > > True enough, but that someone will not be me. I estimate that the work required exceeds the benefits of me using LLVM. The imbalance is far worse on Windows. And as if to prove the point, llvm-test has just finished, with a record 287 failures. So after fixing 5 of them, another 12 have started failing. ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] Major regressions
Jeff, > True enough, but that someone will not be me. I estimate that the work > required exceeds the benefits of me using LLVM. The imbalance is far > worse on Windows. And as if to prove the point, llvm-test has just > finished, with a record 287 failures. So after fixing 5 of them, > another 12 have started failing. llvm-test needs to be fixed for running on windows (at least for mingw32 flavour of llvm-gcc). Some time ago I posted big patch for llvm-test for thuis. However, it was incomplete and should be rewritten. It's currently in my todo list, so, I hope to return to it soon... -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University. ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] Major regressions
Jeff, On Sun, 2007-01-21 at 14:49 -0800, Jeff Cohen wrote: > Chris Lattner wrote: > > > > On Jan 21, 2007, at 2:01 PM, Jeff Cohen wrote: > > > >> Well, I'm using the most recent version of both llvm and llvm-gcc > >> (revision 254). 21 of the failures are ARM, but I don't care about > >> those. llvm-test is still running, but it's on track to matching the > >> 275 failures I got the last time I ran it. > >> > >> I'm not going to switch to Linux or OS X or even 32-bit FreeBSD, and I'm > >> not going to spend the time figuring out why LLVM hates 64-bit > >> FreeBSD--especially as it's getting worse, not better--and it's clear no > >> one else is going to spend the time either. So I'm putting LLVM back on > >> hold until later this year and hopefully the situation will be better > >> then. > > > > Fair enough. However, unless *someone* on 64-bit freebsd > > investigates, it won't get better. There is not much we can do about > > this. FWIW, I agree with Chris on this. Someone on FreeBSD needs to do the work. However, I'd be willing to take a crack at the obvious failures. Most likely they are portability issues in the test cases. Could you forward me the output of a nightly test run? I might be able to make a dent in it. Reid. > > > > -Chris > > > > > True enough, but that someone will not be me. I estimate that the work > required exceeds the benefits of me using LLVM. The imbalance is far > worse on Windows. And as if to prove the point, llvm-test has just > finished, with a record 287 failures. So after fixing 5 of them, > another 12 have started failing. > ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] CVS: llvm/lib/Transforms/Scalar/InstructionCombining.cpp
Changes in directory llvm/lib/Transforms/Scalar:
InstructionCombining.cpp updated: 1.607 -> 1.608
---
Log message:
Cleanup checks in the load and store of casted pointer transforms. Two
changes: (1) don't special case for i1 any more, (2) use the new
TargetData::getTypeSizeInBits method to ensure source and dest are the
same bit width.
---
Diffs of the changes: (+7 -8)
InstructionCombining.cpp | 15 +++
1 files changed, 7 insertions(+), 8 deletions(-)
Index: llvm/lib/Transforms/Scalar/InstructionCombining.cpp
diff -u llvm/lib/Transforms/Scalar/InstructionCombining.cpp:1.607
llvm/lib/Transforms/Scalar/InstructionCombining.cpp:1.608
--- llvm/lib/Transforms/Scalar/InstructionCombining.cpp:1.607 Sat Jan 20
17:35:48 2007
+++ llvm/lib/Transforms/Scalar/InstructionCombining.cpp Sun Jan 21 23:51:25 2007
@@ -7990,8 +7990,8 @@
if (const PointerType *SrcTy = dyn_cast(CastOp->getType())) {
const Type *SrcPTy = SrcTy->getElementType();
-if ((DestPTy->isInteger() && DestPTy != Type::Int1Ty) ||
-isa(DestPTy) || isa(DestPTy)) {
+if (DestPTy->isInteger() || isa(DestPTy) ||
+ isa(DestPTy)) {
// If the source is an array, the code below will not succeed. Check to
// see if a trivial 'gep P, 0, 0' will help matters. Only do this for
// constants.
@@ -8004,13 +8004,13 @@
SrcPTy = SrcTy->getElementType();
}
- if (((SrcPTy->isInteger() && SrcPTy != Type::Int1Ty) ||
- isa(SrcPTy) || isa(SrcPTy)) &&
+ if ((SrcPTy->isInteger() || isa(SrcPTy) ||
+isa(SrcPTy)) &&
// Do not allow turning this into a load of an integer, which is then
// casted to a pointer, this pessimizes pointer analysis a lot.
(isa(SrcPTy) == isa(LI.getType())) &&
- IC.getTargetData().getTypeSize(SrcPTy) ==
- IC.getTargetData().getTypeSize(DestPTy)) {
+ IC.getTargetData().getTypeSizeInBits(SrcPTy) ==
+ IC.getTargetData().getTypeSizeInBits(DestPTy)) {
// Okay, we are casting from one integer or pointer type to another of
// the same size. Instead of casting the pointer before the load, cast
@@ -8178,8 +8178,7 @@
if (const PointerType *SrcTy = dyn_cast(CastOp->getType())) {
const Type *SrcPTy = SrcTy->getElementType();
-if ((DestPTy->isInteger() && DestPTy != Type::Int1Ty) ||
-isa(DestPTy)) {
+if (DestPTy->isInteger() || isa(DestPTy)) {
// If the source is an array, the code below will not succeed. Check to
// see if a trivial 'gep P, 0, 0' will help matters. Only do this for
// constants.
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
