Re: IRA memory cost calculation
Jeff Law wrote: On 11/30/09 14:48, Michael Eager wrote: Jeff Law wrote: On 11/30/09 14:17, Michael Eager wrote: I've run into a situation where assign_hard_reg() decides that there are no registers available. That can certainly happen. It's also the case that assign_hard_reg may decide that memory is cheaper than a register and refuse to assign a register for certain allocnos. This results in a memory reference being substituted for a pseudo-register. There's no check to see if the modified instruction is valid, which it isn't. reload performs this action, not IRA. Reload is allowed to replace a pseudo with its equivalent memory location, then emit whatever reloads are necessary to fix up the resulting insn. So what you need to do is debug the generated reloads for the insn in question. Often this kind of failure is a predicate, constraint or secondary reload problem. Thanks. I did step through reload and it looked like everything it was doing was OK. I'll look at reload again and re-check constraints. Also double check your predicates and look at secondary reload issues. It's not uncommon to need to define secondary reloads for oddball cases. If you described more attributes of your target we might be able to point you at another target with similar attributes and describe how it handles these situations. After more hours trudging through reload, I found out that the invalid instruction was caused by an incorrect constraint. This was in code dating from gcc-2.96. Apparently, nothing had ever matched this combination before until I added cbranch support. Thanks for the pointing me in the right direction. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [Patch, libfortran] PR 40812 Large file support on MinGW
On Wed, Dec 2, 2009 at 7:18 AM, Janne Blomqvist wrote: > Hi, > > the attached patch should make gfortran support > 2 GB files on MinGW. > I don't have a windows installation to test on, so I don't know if > this works or not. Though I regtested on x86_64-unknown-linux-gnu to > make sure that non-MinGW targets didn't change (it's all behind > #ifdefs, but just to be sure). > > Another caveat is that it uses features from the Win32 API that > according to MSDN are available only as of w2k and newer, so with this > patch we effectively drop support for pre-w2k targets on MinGW. I > don't know if anybody cares about such platforms any longer, if so > maybe the interested party could step up to the plate and contribute > some configure checks or somesuch so that we could fall back to the > old ftruncate or chsize functions? I care about pre-w2k WinNT at least. Please hold off on this while I test a simple modification that doesn't require the newer API. Danny
gcc-4.4-20091201 is now available
Snapshot gcc-4.4-20091201 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20091201/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 154886 You'll find: gcc-4.4-20091201.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20091201.tar.bz2 C front end and core compiler gcc-ada-4.4-20091201.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20091201.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20091201.tar.bz2 C++ front end and runtime gcc-java-4.4-20091201.tar.bz2 Java front end and runtime gcc-objc-4.4-20091201.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20091201.tar.bz2The GCC testsuite Diffs from 4.4-20091124 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Delay loaded shared objects
On Tue, Dec 1, 2009 at 12:18 AM, Richard Henderson wrote: > On 11/30/2009 02:53 PM, Robert Huo wrote: >> >> Does gcc/g++ (on a typical Linux platform) supports delayed loaded >> shared objects similar to the /DELAYLOAD option of MSVC [1]? > > No. > > The glibc elf.h file defines (and thus presumably reserves) the > DF_P1_LAZYLOAD interface used on Solaris, but does not actually implement > lazy loading in the glibc dynamic linker. Nor does the binutils linker > provide a mechanism for setting this bit. > Thanks for your answer. Robert.
[Patch, libfortran] PR 40812 Large file support on MinGW
Hi,
the attached patch should make gfortran support > 2 GB files on MinGW.
I don't have a windows installation to test on, so I don't know if
this works or not. Though I regtested on x86_64-unknown-linux-gnu to
make sure that non-MinGW targets didn't change (it's all behind
#ifdefs, but just to be sure).
Another caveat is that it uses features from the Win32 API that
according to MSDN are available only as of w2k and newer, so with this
patch we effectively drop support for pre-w2k targets on MinGW. I
don't know if anybody cares about such platforms any longer, if so
maybe the interested party could step up to the plate and contribute
some configure checks or somesuch so that we could fall back to the
old ftruncate or chsize functions?
Ok for trunk?
2009-12-01 Janne Blomqvist
PR libfortran/40812
* libgfortran.h: typedef gfc_offset differently for mingw.
* io/unix.h (struct stream): Change function pointers to use
gfc_offset instead of off_t.
(sseek): Change prototype to use gfc_offset instead of off_t.
(stell): Likewise.
(struncate): Likewise.
* io/unix.c: Redefine lseek() for mingw.
(raw_seek): Use gfc_offset instead of off_t.
(raw_tell): Likewise.
(buf_seek): Likewise.
(buf_tell): Likewise.
(buf_truncate): Likewise.
(mem_seek): Likewise.
(mem_tell): Likewise.
(mem_truncate): Likewise.
(fd_to_stream): Likewise.
(file_length): Likewise.
(raw_truncate): Use gfc_offset instead of off_t, add large file
capable implementation for MinGW.
--
Janne Blomqvist
diff --git a/libgfortran/io/unix.c b/libgfortran/io/unix.c
index 8b32475..18ce6bb 100644
--- a/libgfortran/io/unix.c
+++ b/libgfortran/io/unix.c
@@ -47,6 +47,8 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
#define WIN32_LEAN_AND_MEAN
#include
+#define lseek _lseeki64
+
static uint64_t
id_from_handle (HANDLE hFile)
{
@@ -274,22 +276,63 @@ raw_write (unix_stream * s, const void * buf, ssize_t nbyte)
return nbyte - bytes_left;
}
-static off_t
-raw_seek (unix_stream * s, off_t offset, int whence)
+static gfc_offset
+raw_seek (unix_stream * s, gfc_offset offset, int whence)
{
return lseek (s->fd, offset, whence);
}
-static off_t
+static gfc_offset
raw_tell (unix_stream * s)
{
return lseek (s->fd, 0, SEEK_CUR);
}
static int
-raw_truncate (unix_stream * s, off_t length)
+raw_truncate (unix_stream * s, gfc_offset length)
{
-#ifdef HAVE_FTRUNCATE
+#ifdef __MINGW32__
+ LARGE_INTEGER cur, tmp;
+ HANDLE h;
+ long htmp;
+
+ if (isatty (s->fd))
+{
+ errno = EBADF;
+ return -1;
+}
+ htmp = _get_osfhandle (s->fd);
+ if (htmp == INVALID_HANDLE_VALUE)
+{
+ runtime_error ("Couldn't get handle from fd");
+ return -1;
+}
+ h = (HANDLE) htmp;
+ tmp.LowPart = 0;
+ tmp.HighPart = 0;
+ if (!SetFilePointerEx (h, tmp, &cur, FILE_CURRENT))
+{
+ runtime_error ("Couldn't determine file position");
+ return -1;
+}
+ tmp.QuadPart = length;
+ if (!SetFilePointerEx (h, tmp, NULL, FILE_CURRENT))
+{
+ runtime_error ("Couldn't seek to specified position for truncation");
+ return -1;
+}
+ if (!SetEndOfFile (h))
+{
+ runtime_error ("Couldn't truncate file");
+ return -1;
+}
+ if (!SetFilePointerEx (h, cur, NULL, FILE_BEGIN))
+{
+ runtime_error ("Couldn't seek back after truncating");
+ return -1;
+}
+ return 0;
+#elif defined HAVE_FTRUNCATE
return ftruncate (s->fd, length);
#elif defined HAVE_CHSIZE
return chsize (s->fd, length);
@@ -470,8 +513,8 @@ buf_write (unix_stream * s, const void * buf, ssize_t nbyte)
return nbyte;
}
-static off_t
-buf_seek (unix_stream * s, off_t offset, int whence)
+static gfc_offset
+buf_seek (unix_stream * s, gfc_offset offset, int whence)
{
switch (whence)
{
@@ -495,14 +538,14 @@ buf_seek (unix_stream * s, off_t offset, int whence)
return offset;
}
-static off_t
+static gfc_offset
buf_tell (unix_stream * s)
{
return s->logical_offset;
}
static int
-buf_truncate (unix_stream * s, off_t length)
+buf_truncate (unix_stream * s, gfc_offset length)
{
int r;
@@ -631,8 +674,8 @@ mem_write (stream * s, const void * buf, ssize_t nbytes)
}
-static off_t
-mem_seek (stream * strm, off_t offset, int whence)
+static gfc_offset
+mem_seek (stream * strm, gfc_offset offset, int whence)
{
unix_stream * s = (unix_stream *) strm;
switch (whence)
@@ -668,7 +711,7 @@ mem_seek (stream * strm, off_t offset, int whence)
}
-static off_t
+static gfc_offset
mem_tell (stream * s)
{
return ((unix_stream *)s)->logical_offset;
@@ -677,7 +720,7 @@ mem_tell (stream * s)
static int
mem_truncate (unix_stream * s __attribute__ ((unused)),
- off_t length __attribute__ ((unused)))
+ gfc_offset length __attribute__ ((unused)))
{
return 0;
}
@@ -764,7 +807,7 @@ fd_to_stream (in
ICE on unique_ptr
GCC-4.5-trunk/Cygwin ICEs in the following way: /opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/bits/unique_ptr.h:233:5: internal compiler error: in finish_member_declaration, at cp/semantics.c:2416 I can't provide a testcase. Best regards Piotr Wyderski
Re: issue building ppl with trunk
On 12/01/2009 09:02 AM, Rainer Emrich wrote: C:/MinGW/i686-pc/i686-pc/i686-pc/gcc-4.5.0/mingw/lib/libppl.a(Polyhedron_widenings.o):Polyhedron_widenings.cc:(.text$_ZN23Parma_Polyhedra_Library3BoxINS_8IntervalI10__gmp_exprIA1_12__mpq_structS4_ENS_25Interval_Restriction_NoneINS_20Interval_Info_BitsetIjNS_29Rational_Interval_Info_Policy15refine_no_checkERKNS_10ConstraintE[Parma_Polyhedra_Library::Box, Parma_Polyhedra_Library::Interval_Restriction_None > > ::refine_no_check(Parma_Polyhedra_Library::Constraint const&)]+0x50): undefined reference to `Parma_Polyhedra_Library::extract_interval_constraint(Parma_Polyhedra_Library::Constraint const&, unsigned int, unsigned int&, unsigned int) &)' Any idea? I believe this is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41611 which I guess I ought to get to today :) Jason
issue building ppl with trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since beginning of November trunk fails to build ppl properly at least on *-*-mingw32 targets. ppl itself builds, but building cloog-ppl or bootstrapping gcc fails: C:/MinGW/i686-pc/i686-pc/i686-pc/gcc-4.5.0/mingw/lib/libppl.a(Polyhedron_widenings.o):Polyhedron_widenings.cc:(.text$_ZN23Parma_Polyhedra_Library3BoxINS_8IntervalI10__gmp_exprIA1_12__mpq_structS4_ENS_25Interval_Restriction_NoneINS_20Interval_Info_BitsetIjNS_29Rational_Interval_Info_Policy15refine_no_checkERKNS_10ConstraintE[Parma_Polyhedra_Library::Box, Parma_Polyhedra_Library::Interval_Restriction_None > > >::refine_no_check(Parma_Polyhedra_Library::Constraint const&)]+0x50): undefined reference to `Parma_Polyhedra_Library::extract_interval_constraint(Parma_Polyhedra_Library::Constraint const&, unsigned int, unsigned int&, unsigned int) &)' Any idea? gcc-4.4.x is ok! Cheers, Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksVIfAACgkQoUhjsh59BL4bRgCgsjXIfsrHgwU3WkF1FJhqG9ap r3AAnA0qsomDm9Ir/eHWFKzXOfElBVt8 =SYgi -END PGP SIGNATURE-
Plugin callback interface (Was: plugin events for ICI)
Quoting Richard Guenther : (Btw, why does invoke_plugin_callbacks not return a value, that would make code way more readable than going through the passed by reference appearant return value ...) Actually, I made it return a value that indicates if a callback took place. But apparently you want it to return the result of the callback itself. For that to make sense, the callbacks themselves would have to return values, and these would have to be somehow accumulated to an overall return value. So, either we'd have to change the interface that all existing plugins use, to give the callbacks a return value, or we'd have to have different variants of register_callback - or one that takes a union - or introduce not quite conformant function casts - to accommodate the different callback function types, and likewise something would have to be done on the invoke_plugin_callbacks side.
Re: Support for VLE code in PowerPC
Hi Kaushik, We are planning to support the same in binutils, gcc and newlib. Please let us know if you have any suggestions to implement this support for easier FSF approval. Please make sure that you have an FSF Binutils Copyright assignment in place. Please follow the GNU Coding Standards: http://savannah.gnu.org/projects/gnustandards Please try to include one or more assembler test cases to check the assembly and disassembly of the new instructions. Cheers Nick
Re: MPC required in one week.
On 11/30/2009 09:47 PM, Michael Witten wrote: On Mon, Nov 30, 2009 at 12:04 AM, Kaveh R. GHAZI wrote: The patch which makes the MPC library a hard requirement for GCC bootstrapping has been approved today. Out of curiosity and ignorance: Why, specifically, is MPC going to be a hard requirement? On the prerequisites page, MPC is currently described with: "Having this library will enable additional optimizations on complex numbers." Does that mean that such optimizations are now an important requirement? or is MPC being used for something else? They are a requirement for Fortran, but it's (much) simpler to do them for all front-ends. Paolo
Re: Question about filling multi delay slots
On Tue, Dec 1, 2009 at 5:31 AM, Jeff Law wrote: > On 11/25/09 07:34, Amker.Cheng wrote: > > First, it's worth noting very few targets support multiple delay slots and > as a result that code isn't tested nearly as well as handling of single > delay slots. > > I'm pretty sure we assume that the first insn we add to the delay list > always goes in the first slot, 2nd insn in the 2nd slot and so-on. > > Jeff > > > Thanks for explanation, I will take closer look into at these codes. -- Best Regards.
