Re: Obsoleting IRIX < 6.5, Solaris 7, and Tru64 UNIX < V5.1
Rainer Orth writes: > * IRIX before 6.5: > > ** IRIX 5.3 entered retired mode by the end of 1998. Patches are no >longer available from support.sgi.com, and a full bootstrap and test >cycle takes 8 1/2 days on the machines I have available, even without >java/libgcj. > > ** IRIX 6.2 entered retired mode by 01/2003 and patches aren't available >either. I don't have any machine available running that version. > > ** IRIX 6.3 and 6.4 were only ever released for specific hardware. > > ** With a few exceptions, all machines supported by IRIX 6.[2-4] are >supported by IRIX 6.5, too (at least until 6.5.22). Sounds like a good plan ;) > ** I also consider obsoleting support for the O32 ABI: the SGI linker used >is different from the N32/N64 ld, and has repeatedly caused problems >which couldn't be resolved even when SGI still had full IRIX >support. Also, the ISO C99 support in libc is only available for the >N32 and N64 ABIs. Yeah, that's a difficult one. On the one hand, I can see that it doesn't make sense to support an ABI that was there for compatibility with IRIX 5 and earlier (which we're declaring obselete). On the other, I think o32 worked better with the GNU linker than it did with the SGI linker. E.g. I remember hitting GOT overflow problems with the SGI o32 linker (which didn't support multiple GOTs) that were solved by using the GNU linker. But that was a long time ago (binutils 2.15?) and I don't know how well it works now. And I still can't see any reason why IRIX 6.5 users would prefer o32 over n32. I certainly don't object to removing o32 support from the IRIX port. Richard
gcc version 4.4.3 (GCC)
config.guess: i686-pc-linux-gnu gcc --v: Using built-in specs. Target: i686-pc-linux-gnu Configured with: ./configure Thread model: posix gcc version 4.4.3 (GCC) packages: gcc-4.4.3.tar.bz2 gcc-core-4.4.3.tar.bz2 gcc-g++-4.4.3.tar.bz2 linux distribution: Ubuntu 8.04.4 LTS \n \l kernel version: Linux HDHN2432 2.6.24-26-generic #1 SMP Tue Dec 1 18:37:31 UTC 2009 i686 GNU/Linux glibc version: Desired=Unknown/Install/ Remove/Purge/Hold | Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==-==-=== ii libc6 2.7-10ubuntu5 GNU C Library: Shared libraries
Re: Obsoleting IRIX < 6.5, Solaris 7, and Tru64 UNIX < V5.1
Richard Sandiford writes: >> ** I also consider obsoleting support for the O32 ABI: the SGI linker used >>is different from the N32/N64 ld, and has repeatedly caused problems >>which couldn't be resolved even when SGI still had full IRIX >>support. Also, the ISO C99 support in libc is only available for the >>N32 and N64 ABIs. > > Yeah, that's a difficult one. On the one hand, I can see that it > doesn't make sense to support an ABI that was there for compatibility > with IRIX 5 and earlier (which we're declaring obselete). On the other, > I think o32 worked better with the GNU linker than it did with the > SGI linker. E.g. I remember hitting GOT overflow problems with the > SGI o32 linker (which didn't support multiple GOTs) that were solved > by using the GNU linker. > > But that was a long time ago (binutils 2.15?) and I don't know how > well it works now. And I still can't see any reason why IRIX 6.5 > users would prefer o32 over n32. I certainly don't object to > removing o32 support from the IRIX port. I agree with removing support for o32 from the Irix port. However, it would not surprise me to discover that there are embedded systems out there still using o32, with assembly functions which expect the o32 calling convention. I would be cautious about removing support for o32 entirely. Ian
Re: Obsoleting IRIX < 6.5, Solaris 7, and Tru64 UNIX < V5.1
On Sat, Jan 30, 2010 at 4:28 PM, Ian Lance Taylor wrote: > Richard Sandiford writes: > >>> ** I also consider obsoleting support for the O32 ABI: the SGI linker used >>> is different from the N32/N64 ld, and has repeatedly caused problems >>> which couldn't be resolved even when SGI still had full IRIX >>> support. Also, the ISO C99 support in libc is only available for the >>> N32 and N64 ABIs. >> >> Yeah, that's a difficult one. On the one hand, I can see that it >> doesn't make sense to support an ABI that was there for compatibility >> with IRIX 5 and earlier (which we're declaring obselete). On the other, >> I think o32 worked better with the GNU linker than it did with the >> SGI linker. E.g. I remember hitting GOT overflow problems with the >> SGI o32 linker (which didn't support multiple GOTs) that were solved >> by using the GNU linker. >> >> But that was a long time ago (binutils 2.15?) and I don't know how >> well it works now. And I still can't see any reason why IRIX 6.5 >> users would prefer o32 over n32. I certainly don't object to >> removing o32 support from the IRIX port. > > I agree with removing support for o32 from the Irix port. > > However, it would not surprise me to discover that there are embedded > systems out there still using o32, with assembly functions which > expect the o32 calling convention. I would be cautious about removing > support for o32 entirely. I wouldn't be surprised if they're stuck with using GCC 3.x either ;) Richard.
Re: Obsoleting IRIX < 6.5, Solaris 7, and Tru64 UNIX < V5.1
On Sat, Jan 30, 2010 at 07:28:01AM -0800, Ian Lance Taylor wrote: > However, it would not surprise me to discover that there are embedded > systems out there still using o32, with assembly functions which > expect the o32 calling convention. I would be cautious about removing > support for o32 entirely. I don't think anyone's suggested that. o32 is the default ABI for 32-bit MIPS GNU/Linux targets which are still in wide use. -- Daniel Jacobowitz CodeSourcery
Question about reworking internals manual
Hi, folks. I'm looking at reworking the sections on trees in the internals manual and had a question about how to proceed. Right now, the information is spread between the GENERIC chapter and Trees chapter. The Trees chapter interleaves a lot of C and C++-specific info in with GENERIC info. What I'd like to do is the following: 1) Make GENERIC the chapter that talks about the front end representation. 2) Extract those portions of Trees that really talk about GENERIC (a large part of it) and integrate that into the GENERIC chapter 3) Make the remainder part of a section on language-dependent trees The problem I see is that doing the whole thing at once will make for a large hard-to-review patch. But to do it in steps will result in an inconsistent document until a good part of the work is done. Any suggestions about the best way to proceed? Thanks, Jerry
Register allocation and multi-reg HARD_FRAME_POINTER
Hello!
The target that I would like to support has 8-bit registers, so for any
sane compilation, stack pointer, frame pointer and hard frame pointer
all need to be constructed from at least two registers, to form 16-bit
register pair {rA, rB}.
The stack pointer is defined as a fixed register, so it is not reachable
to register allocator.
The frame pointer is actually a fake register (with a regnum above last
hard register regnum) that eliminates either to SP or HW_FP, so RA
ignores it.
The problem is with HW_FP. Looking at the register allocator, it seems
that only HARD_FRAME_POINTER_REGNO is marked as live in the allocator,
although hard_frame_pointer_rtx shows itself as a HImode register with
H_F_P_R register number. Since H_F_P_R+1 is marked "empty", RA puts
various QImode values there, clobbering high part of hard frame pointer.
There is nothing in the documentation that would describe this
limitation, and I found no solution browsing the web archives. Also, I
believe that AVR should have the same problems.
Is this a known limitation in the RA? If it is, is there a solution for
multi-reg [HARD]_FRAME_POINTER?
Thanks,
Uros.
Re: Support for export keyword to use with C++ templates ?
Hi I already tried to tell him that upthread. Sorry about that, last night was tired and didn't follow the whole thread. Anyway, modulo a possible deprecation (I believe M$ through Herb is still pushing for it) I think the slightly more serious side of this export thing is something Mark, if I'm not mistaken, said some time ago, at the very beginning of the Lto ideas, to the effect that probably some infrastructure could be also used to attack the implementation of export. Does that make sense to anybody? Paolo
Re: Question about reworking internals manual
Jerry Quinn writes: > I'm looking at reworking the sections on trees in the internals manual > and had a question about how to proceed. Right now, the information is > spread between the GENERIC chapter and Trees chapter. The Trees chapter > interleaves a lot of C and C++-specific info in with GENERIC info. > > What I'd like to do is the following: > > 1) Make GENERIC the chapter that talks about the front end > representation. > > 2) Extract those portions of Trees that really talk about GENERIC (a > large part of it) and integrate that into the GENERIC chapter > > 3) Make the remainder part of a section on language-dependent trees > > The problem I see is that doing the whole thing at once will make for a > large hard-to-review patch. But to do it in steps will result in an > inconsistent document until a good part of the work is done. > > Any suggestions about the best way to proceed? Personally, I think a large patch will be acceptable for this kind of thing. Of course, most of the compiler uses GIMPLE now. GIMPLE is yet another IR, although it does still use GENERIC for things like types and memory addresses. Thanks for working on this. Ian
Re: Register allocation and multi-reg HARD_FRAME_POINTER
Uros Bizjak writes:
> The target that I would like to support has 8-bit registers, so for
> any sane compilation, stack pointer, frame pointer and hard frame
> pointer all need to be constructed from at least two registers, to
> form 16-bit register pair {rA, rB}.
>
> The stack pointer is defined as a fixed register, so it is not
> reachable to register allocator.
> The frame pointer is actually a fake register (with a regnum above
> last hard register regnum) that eliminates either to SP or HW_FP, so
> RA ignores it.
>
> The problem is with HW_FP. Looking at the register allocator, it seems
> that only HARD_FRAME_POINTER_REGNO is marked as live in the allocator,
> although hard_frame_pointer_rtx shows itself as a HImode register with
> H_F_P_R register number. Since H_F_P_R+1 is marked "empty", RA puts
> various QImode values there, clobbering high part of hard frame
> pointer.
>
> There is nothing in the documentation that would describe this
> limitation, and I found no solution browsing the web archives. Also, I
> believe that AVR should have the same problems.
>
> Is this a known limitation in the RA? If it is, is there a solution
> for multi-reg [HARD]_FRAME_POINTER?
I think the AVR does it by treating the soft frame pointer as a pair
of registers, and eliminating both registers, one to
HARD_FRAME_POINTER_REGNO and the other to HARD_FRAME_POINTER_REGNO+1.
Make the elimination conditions the same, and the compiler should
reliably eliminate either both or neither.
Ian
Re: Support for export keyword to use with C++ templates ?
Paolo Carlini writes: > Anyway, modulo a possible deprecation (I believe M$ through Herb is > still pushing for it) I think the slightly more serious side of this > export thing is something Mark, if I'm not mistaken, said some time > ago, at the very beginning of the Lto ideas, to the effect that > probably some infrastructure could be also used to attack the > implementation of export. Does that make sense to anybody? The LTO infrastructure could probably be somewhat useful to anybody who wants to tackle export. However, it will only be somewhat useful. LTO provides the ability to write out GIMPLE. But to support export you need to instead stream out the C++ frontend representation, which is trees. In the gcc way, there is overlap between GIMPLE and trees, but they are not the same thing. So a bunch more work will still be required even for the first basic step of export, which is the ability to write out a parse tree. Ian
Re: gccgo language contribution accepted
On Thu, Jan 28, 2010 at 10:03:04AM -0800, Ian Lance Taylor wrote: > "Joseph S. Myers" writes: > > What has been decided about copyright assignment requirements? > > This is the general plan as I understand it. > > I will separate the gcc-specific parts from the rest of the Go > frontend. Those gcc-specific parts will be under the GPL and follow > the usual gcc rules. The rest will remain under the BSD-style > license, and will move to a different hosting site (probably at > code.google.com). I will regularly merge from that other hosting site > to the gcc sources, much as we do with classpath and other code today. Just a note that GNU Classpath as a project is also assigned to the FSF and hosted at savannah. The original libgcj implementation and the classpath implementation were merged as projects to have just one code base that implemented a free java core library with the FSF as guardian. Code is merged both ways. There might be other code bases which aren't assigned to the FSF, but are imported into the gcc tree anyway. For libgcj/classpath this was done because it made sharing of the core library between other compiler/vm implementations easier, not because of avoiding copyright assignment. Cheers, Mark
Re: Support for export keyword to use with C++ templates ?
On Sat, Jan 30, 2010 at 01:47:03AM +0200, Timothy Madden wrote: > So nobody here wants to try a big thing ? :( This question strikes me as being not very fair because many GCC people are already pretty much involved. Would you fancy giving a hand? > How long would it take for someone to understand how parsing works in > g++ ? Or to understand the build system in gcc ? It depends (amongst other things) on the motivation of said person, I guess. Maybe several months? As usual in this kind of things, I guess a good approach is to try to scratch your own itches without thinking too much about the time it would take, especially for something as big as this particular feature you are talking about :-) Dodji
Re: gccgo language contribution accepted
Mark Wielaard writes: > On Thu, Jan 28, 2010 at 10:03:04AM -0800, Ian Lance Taylor wrote: >> "Joseph S. Myers" writes: >> > What has been decided about copyright assignment requirements? >> >> This is the general plan as I understand it. >> >> I will separate the gcc-specific parts from the rest of the Go >> frontend. Those gcc-specific parts will be under the GPL and follow >> the usual gcc rules. The rest will remain under the BSD-style >> license, and will move to a different hosting site (probably at >> code.google.com). I will regularly merge from that other hosting site >> to the gcc sources, much as we do with classpath and other code today. > > Just a note that GNU Classpath as a project is also assigned to the FSF > and hosted at savannah. The original libgcj implementation and the > classpath implementation were merged as projects to have just one code > base that implemented a free java core library with the FSF as guardian. > Code is merged both ways. There might be other code bases which aren't > assigned to the FSF, but are imported into the gcc tree anyway. For > libgcj/classpath this was done because it made sharing of the core > library between other compiler/vm implementations easier, not because > of avoiding copyright assignment. Thanks. I didn't mean to imply that the situation with classpath was identical to that of gccgo, merely that it was another case where sources are merged from an external site to gcc.gnu.org. Note that copyright assignment is not the issue with the gccgo frontend; Google has a blanket copyright assignment with the FSF, and copyright assignments will be required for all changes to the gccgo frontend. The reason for the separation is that gccgo is not under the GPL. Ian
