plese help to install gcc 2.95.3 compiler
I have already install gcc 4.3 version.I need to install gcc 2.95.3 for a research on Polis IDE and Ptolami.Please let me know how can I remove gcc 4.3 and install gcc 2.95.3. Thanks!
Re: plese help to install gcc 2.95.3 compiler
On 02/14/2011 05:06 PM, nayanalekha sugandanee wrote: > I have already install gcc 4.3 version.I need to install gcc 2.95.3 > for a research on Polis IDE and Ptolami.Please let me know how can I > remove gcc 4.3 and install gcc 2.95.3. > I would recommend asking the closest computer science museum. Paolo.
Re: loop hoisting fails
On 11/02/11 19:41, Ian Lance Taylor wrote: My case was somewhat different. I think I just patched gcse_constant_p. Thanks!
Re: plese help to install gcc 2.95.3 compiler
On 14 February 2011 16:08, Paolo Carlini wrote: > On 02/14/2011 05:06 PM, nayanalekha sugandanee wrote: >> I have already install gcc 4.3 version.I need to install gcc 2.95.3 >> for a research on Polis IDE and Ptolami.Please let me know how can I >> remove gcc 4.3 and install gcc 2.95.3. >> > I would recommend asking the closest computer science museum. > > Paolo. Also, please use the right mailing list - this list is for development of GCC itself, not help using or installing it. As stated at http://gcc.gnu.org/lists.html requests for support should go to the gcc-help mailing list, thanks.
Re: Target deprecations for 4.6
On Sat, Feb 12, 2011 at 08:11:07AM -0500, David Edelsohn wrote:
> On Fri, Feb 11, 2011 at 9:15 PM, Joseph S. Myers
> wrote:
> > appear to involve a simultaneously maintained set of upstream components
> > that are usable together in their current upstream forms; they got Linux
> > kernel support upstream in 2009 (and don't seem to have maintained it much
> > since then), some time after they got GCC support upstream (and then
> > stopped maintaining it).
>
> The SCORE port was accepted and maintainers appointed with the
> understanding that lack of maintenance would lead to rapid deprecation
> and removal.
>
> I would suggest directly sending a message to the last contacts and
> any other contact email address for SCORE that the port must function
> and test results posted or it will be deprecated and removed. That
> the GCC community needs to see action, not future promises.
Patch for adding score-* and crx-* to obsolete ports below. Last
contact for SCORE and current crx maintainer CC'd.
OK to commit?
-Nathan
* config.gcc: Declare score-* and crx-* obsolete.
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 54b822e..0f7050d 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -237,6 +237,7 @@ case ${target} in
| alpha*-*-gnu* \
| arm*-*-netbsd* \
| arm-*-pe* \
+ | crx-* \
| i[34567]86-*-interix3* \
| i[34567]86-*-netbsd*\
| i[34567]86-*-pe \
@@ -247,6 +248,7 @@ case ${target} in
| m68k-*-uclinuxoldabi* \
| mcore-*-pe* \
| powerpc*-*-gnu* \
+ | score-* \
| sh*-*-symbianelf* \
| vax-*-netbsd* \
)
Re: plese help to install gcc 2.95.3 compiler
nayanalekha sugandanee writes: > I have already install gcc 4.3 version.I need to install gcc 2.95.3 > for a research on Polis IDE and Ptolami.Please let me know how can I > remove gcc 4.3 and install gcc 2.95.3. This question is not appropriate for the mailing list gcc@gcc.gnu.org, which is for the development of gcc itself. It would be appropriate for gcc-h...@gcc.gnu.org. Please take any followups to gcc-help. Thanks. You can run multiple versions of gcc on a single computer, so there is no need to remove gcc 4.3. In fact you should not remove gcc 4.3, as you will need it to build 2.95.3. To install gcc 2.95.3, you need to download it and build it according to the installation instructions. After you download it look at the file gcc/install.texi. Use the --prefix option when you run configure so that 2.95.3 does not overwrite 4.3 when you install it. Ian
A problem of our Gcc mirror
Hi us, When i want to download the mirror of Gcc 4.3 from the URL of China it shows broken. The URL is: http://gcc.gnu.org/mirrors.html You can click China's for a try. Could anyone do for it. Or i want to take the mirror on my website server(www.harrywei.org). I don't know whether it can be well. Any idea? Thanks. Best Regards. Harry Wei.
Re: plese help to install gcc 2.95.3 compiler
On 02/14/2011 05:50 PM, Ian Lance Taylor wrote: nayanalekha sugandanee writes: I have already install gcc 4.3 version.I need to install gcc 2.95.3 for a research on Polis IDE and Ptolami.Please let me know how can I remove gcc 4.3 and install gcc 2.95.3. This question is not appropriate for the mailing list gcc@gcc.gnu.org, which is for the development of gcc itself. It would be appropriate for gcc-h...@gcc.gnu.org. Please take any followups to gcc-help. Thanks. You can run multiple versions of gcc on a single computer, so there is no need to remove gcc 4.3. In fact you should not remove gcc 4.3, as you will need it to build 2.95.3. To install gcc 2.95.3, you need to download it and build it according to the installation instructions. After you download it look at the file gcc/install.texi. Use the --prefix option when you run configure so that 2.95.3 does not overwrite 4.3 when you install it. It's not quite that straightforward: I had to patch a few things to get 2.95.3 to build with gcc 4.x. Andrew.
Re: GCC bootstrap mismatch on OS X 10.4
On Sun, Feb 13, 2011 at 05:27:37PM +, Jonathan Wakely wrote: On 13 February 2011 09:01, Csaba Raduly wrote: Any idea what could be the problem and how to fix it? Should I just run a simple "make"? Questions about using or building gcc should be sent to gcc-h...@gcc.gnu.org, not this list, please follow up there instead, thanks. I don't know if it will solve your problem, but yes, you just build gcc with 'make' these days, not 'make bootstrap' I suspect his problems will be solved by adding --with-dwarf2 to the configure options. We don't seem to have a specific PR for this but I This PR seems to match: :) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45248 One user has reported that --with-dwarf2 was enough to fix bootstrap. believe there are bootstrap comparision failures in libgomp for darwin8 using stabs. We don't get a lot of testing on darwin8 theses days since the regress Apple tester is now on darwin9 (plus this could be intel specific). Both Mike and Iain have access to darwin8 so we hopefully can get a PR opened. Jack ps I had suggested awhile back that we default darwin8 to dwarf2 but Mike thinks the dwarf2 support is too immature in the Xcode for darwin8 to safely do that. Fang David Fang http://www.csl.cornell.edu/~fang/ http://www.achronix.com/
RFC: A new MIPS64 ABI
Background: Current MIPS 32-bit ABIs (both o32 and n32) are restricted to 2GB of user virtual memory space. This is due the way MIPS32 memory space is segmented. Only the range from 0..2^31-1 is available. Pointer values are always sign extended. Because there are not already enough MIPS ABIs, I present the ... Proposal: A new ABI to support 4GB of address space with 32-bit pointers. The proposed new ABI would only be available on MIPS64 platforms. It would be identical to the current MIPS n32 ABI *except* that pointers would be zero-extended rather than sign-extended when resident in registers. In the remainder of this document I will call it 'n32-big'. As a result, applications would have access to a full 4GB of virtual address space. The operating environment would be configured such that the entire lower 4GB of the virtual address space was available to the program. At a low level here is how it would work: 1) Load a pointer to a register from memory: n32: LW $reg, offset($reg) n32-big: LWU $reg, offset($reg) 2) Load an address constant into a register: n32: LUI $reg, high_part ORI $reg, low_part n32-big: ORI $reg, high_part DSLL $reg, $reg, 16 ORI $reg, low_part Q: What would have to change to make this work? o A new ELF header flag to denote the ABI. o Linker support to use proper library search paths, and linker scrips to set the INTERP program header, etc. o GCC has to emit code for the new ABI. o Could all existing n32 relocation types be used? I think so. o Runtime libraries would have to be placed in a new location (/lib32big, /usr/lib32big ...) o The C library's ld.so would have to use a distinct LD_LIBRARY_PATH for n32-big code. o What would the Linux system call interface be? I would propose using the existing Linux n32 system call interface. Most system calls would just work. Some, that pass pointers in in-memory structures, might require kernel modifications (sigaction() for example).
Re: RFC: A new MIPS64 ABI
On Feb 14, 2011, at 12:29 PM, David Daney wrote: > Background: > > Current MIPS 32-bit ABIs (both o32 and n32) are restricted to 2GB of > user virtual memory space. This is due the way MIPS32 memory space is > segmented. Only the range from 0..2^31-1 is available. Pointer > values are always sign extended. > > Because there are not already enough MIPS ABIs, I present the ... > > Proposal: A new ABI to support 4GB of address space with 32-bit > pointers. > > The proposed new ABI would only be available on MIPS64 platforms. It > would be identical to the current MIPS n32 ABI *except* that pointers > would be zero-extended rather than sign-extended when resident in > registers. In the remainder of this document I will call it > 'n32-big'. As a result, applications would have access to a full 4GB > of virtual address space. The operating environment would be > configured such that the entire lower 4GB of the virtual address space > was available to the program. I have to wonder if it's worth the effort. The primary problem I see is that this new ABI requires a 64bit kernel since faults through the upper 2G will go through the XTLB miss exception vector. > At a low level here is how it would work: > > 1) Load a pointer to a register from memory: > > n32: > LW $reg, offset($reg) > > n32-big: > LWU $reg, offset($reg) That might be sufficient for userland, but the kernel will need to do similar things (even if a 64bit kernel) when accessing structures supplied by 32-bit syscalls. It seems to be workable but if you need the additional address space why not use N64?
Re: A problem of our Gcc mirror
2011/2/15 Harry Wei : > Hi us, > When i want to download the mirror of Gcc 4.3 from the URL of > China it shows broken. The URL is: http://gcc.gnu.org/mirrors.html > You can click China's for a try. Could anyone do for it. Or i want > to take the mirror on my website server(www.harrywei.org). I don't know > whether it can be well. Any idea? > > Thanks. > Best Regards. > Harry Wei. > The mirror site in China is unavailable for a long time. I believe it is helpful if we can have one, though I don't know the requirements of being a mirror. Thanks, Mingjie
Re: RFC: A new MIPS64 ABI
On Feb 14, 2011, at 7:15 PM, Matt Thomas wrote: > > On Feb 14, 2011, at 12:29 PM, David Daney wrote: > >> Background: >> >> Current MIPS 32-bit ABIs (both o32 and n32) are restricted to 2GB of >> user virtual memory space. This is due the way MIPS32 memory space is >> segmented. Only the range from 0..2^31-1 is available. Pointer >> values are always sign extended. >> >> Because there are not already enough MIPS ABIs, I present the ... >> >> Proposal: A new ABI to support 4GB of address space with 32-bit >> pointers > > I have to wonder if it's worth the effort. The primary problem I see > is that this new ABI requires a 64bit kernel since faults through the > upper 2G will go through the XTLB miss exception vector. It seems a very large amount of work for a very small benefit. > >> At a low level here is how it would work: >> >> 1) Load a pointer to a register from memory: >> >> n32: >> LW $reg, offset($reg) >> >> n32-big: >> LWU $reg, offset($reg) > > > That might be sufficient for userland, but the kernel will need > to do similar things (even if a 64bit kernel) when accessing > structures supplied by 32-bit syscalls. Right, which creates amazing opportunities for bugs. > > It seems to be workable but if you need the additional address space > why not use N64? It seems that this proposal would benefit programs that need more than 2 GB but less than 4 GB, and for some reason really don't want 64 bit pointers. This seems like a microscopically small market segment. I can't see any sense in such an effort. paul
Re: RFC: A new MIPS64 ABI
On Mon, Feb 14, 2011 at 05:57:13PM -0800, Paul Koning wrote: > It seems that this proposal would benefit programs that need more than 2 GB > but less than 4 GB, and for some reason really don't want 64 bit pointers. > > This seems like a microscopically small market segment. I can't see any > sense in such an effort. I remember the RHEL hugemem patch being a big deal for lots of their customers, so a process could address the full 4GB instead of only 3GB on a 32-bit machine. If I recall correctly, upstream didn't want it (get a 64-bit machine!) but lots of paying customers clamored for it. (I personally don't have an opinion on whether it's worth bothering with).
Re: RFC: A new MIPS64 ABI
On Feb 14, 2011, at 9:14 PM, Joe Buck wrote: > On Mon, Feb 14, 2011 at 05:57:13PM -0800, Paul Koning wrote: >> It seems that this proposal would benefit programs that need more than 2 GB >> but less than 4 GB, and for some reason really don't want 64 bit pointers. >> >> This seems like a microscopically small market segment. I can't see any >> sense in such an effort. > > I remember the RHEL hugemem patch being a big deal for lots of their > customers, so a process could address the full 4GB instead of only 3GB > on a 32-bit machine. If I recall correctly, upstream didn't want it > (get a 64-bit machine!) but lots of paying customers clamored for it. Fair enough, but that's a very different case. As Matt points out, the proposal here requires a 64 bit machine; the only difference is in the user process space limit when that process is running in 32 bit mode. paul
Re: RFC: A new MIPS64 ABI
On 02/14/2011 04:15 PM, Matt Thomas wrote: On Feb 14, 2011, at 12:29 PM, David Daney wrote: Background: Current MIPS 32-bit ABIs (both o32 and n32) are restricted to 2GB of user virtual memory space. This is due the way MIPS32 memory space is segmented. Only the range from 0..2^31-1 is available. Pointer values are always sign extended. Because there are not already enough MIPS ABIs, I present the ... Proposal: A new ABI to support 4GB of address space with 32-bit pointers. The proposed new ABI would only be available on MIPS64 platforms. It would be identical to the current MIPS n32 ABI *except* that pointers would be zero-extended rather than sign-extended when resident in registers. In the remainder of this document I will call it 'n32-big'. As a result, applications would have access to a full 4GB of virtual address space. The operating environment would be configured such that the entire lower 4GB of the virtual address space was available to the program. I have to wonder if it's worth the effort. The primary problem I see is that this new ABI requires a 64bit kernel since faults through the upper 2G will go through the XTLB miss exception vector. Yes, that is correct. It is a 64-bit ABI, and like the existing n32 ABI requires a 64-bit kernel. At a low level here is how it would work: 1) Load a pointer to a register from memory: n32: LW $reg, offset($reg) n32-big: LWU $reg, offset($reg) That might be sufficient for userland, but the kernel will need to do similar things (even if a 64bit kernel) when accessing structures supplied by 32-bit syscalls. It is a userspace ABI. The MIPS64 kernel already uses something similar (the -msym32 option). There would be no change to the kernel. It seems to be workable but if you need the additional address space why not use N64? In n64 pointers are 64-bits wide. Programs that use many pointer laden data structures have a much larger cache/memory footprint than their n32 versions. Also the number of instructions required to load a 64-bit constant is much larger than that needed to load a 32-bit constant. David Daney
Re: RFC: A new MIPS64 ABI
On 02/14/2011 06:14 PM, Joe Buck wrote: On Mon, Feb 14, 2011 at 05:57:13PM -0800, Paul Koning wrote: It seems that this proposal would benefit programs that need more than 2 GB but less than 4 GB, and for some reason really don't want 64 bit pointers. This seems like a microscopically small market segment. I can't see any sense in such an effort. I remember the RHEL hugemem patch being a big deal for lots of their customers, so a process could address the full 4GB instead of only 3GB on a 32-bit machine. If I recall correctly, upstream didn't want it (get a 64-bit machine!) but lots of paying customers clamored for it. (I personally don't have an opinion on whether it's worth bothering with). Also look at the new x86_64 ABI (See all those X32 psABI messages) that the Intel folks are actively working on. This proposal is very similar to what they are doing. David Daney
Re: RFC: A new MIPS64 ABI
On Feb 14, 2011, at 6:22 PM, David Daney wrote: > On 02/14/2011 04:15 PM, Matt Thomas wrote: >> >> I have to wonder if it's worth the effort. The primary problem I see >> is that this new ABI requires a 64bit kernel since faults through the >> upper 2G will go through the XTLB miss exception vector. >> > > Yes, that is correct. It is a 64-bit ABI, and like the existing n32 ABI > requires a 64-bit kernel. N32 doesn't require a LP64 kernel, just a 64-bit register aware kernel. Your N32-big does require a LP64 kernel.
Re: RFC: A new MIPS64 ABI
On Feb 14, 2011, at 6:26 PM, David Daney wrote: > On 02/14/2011 06:14 PM, Joe Buck wrote: >> On Mon, Feb 14, 2011 at 05:57:13PM -0800, Paul Koning wrote: >>> It seems that this proposal would benefit programs that need more than 2 GB >>> but less than 4 GB, and for some reason really don't want 64 bit pointers. >>> >>> This seems like a microscopically small market segment. I can't see any >>> sense in such an effort. >> >> I remember the RHEL hugemem patch being a big deal for lots of their >> customers, so a process could address the full 4GB instead of only 3GB >> on a 32-bit machine. If I recall correctly, upstream didn't want it >> (get a 64-bit machine!) but lots of paying customers clamored for it. >> >> (I personally don't have an opinion on whether it's worth bothering with). >> > > Also look at the new x86_64 ABI (See all those X32 psABI messages) that the > Intel folks are actively working on. This proposal is very similar to what > they are doing. untrue. N32 is closer to the X32 ABI since it is limited to 2GB.
Re: RFC: A new MIPS64 ABI
On 02/14/2011 06:34 PM, Matt Thomas wrote: On Feb 14, 2011, at 6:26 PM, David Daney wrote: On 02/14/2011 06:14 PM, Joe Buck wrote: On Mon, Feb 14, 2011 at 05:57:13PM -0800, Paul Koning wrote: It seems that this proposal would benefit programs that need more than 2 GB but less than 4 GB, and for some reason really don't want 64 bit pointers. This seems like a microscopically small market segment. I can't see any sense in such an effort. I remember the RHEL hugemem patch being a big deal for lots of their customers, so a process could address the full 4GB instead of only 3GB on a 32-bit machine. If I recall correctly, upstream didn't want it (get a 64-bit machine!) but lots of paying customers clamored for it. (I personally don't have an opinion on whether it's worth bothering with). Also look at the new x86_64 ABI (See all those X32 psABI messages) that the Intel folks are actively working on. This proposal is very similar to what they are doing. untrue. N32 is closer to the X32 ABI since it is limited to 2GB. It would only be 'untrue' if I had said it was *exactly like* the X32 thing. Really n32 is, as you note, already quite similar to what X32 is trying to do. My proposal is really for a small improvement to n32 to allow doubling the size of the virtual address space to 4GB. David Daney
Re: RFC: A new MIPS64 ABI
On 02/14/2011 06:33 PM, Matt Thomas wrote: On Feb 14, 2011, at 6:22 PM, David Daney wrote: On 02/14/2011 04:15 PM, Matt Thomas wrote: I have to wonder if it's worth the effort. The primary problem I see is that this new ABI requires a 64bit kernel since faults through the upper 2G will go through the XTLB miss exception vector. Yes, that is correct. It is a 64-bit ABI, and like the existing n32 ABI requires a 64-bit kernel. N32 doesn't require a LP64 kernel, just a 64-bit register aware kernel. Your N32-big does require a LP64 kernel. But using 'official' kernel sources the only way to get a 64-bit register aware kernel is for it to also be LP64. So effectively, you do in fact need a 64-bit kernel to run n32 userspace code. My proposed ABI would need trivial kernel changes: o Fix a couple of places where pointers are sign extended instead of zero extended. o Change the stack address and address ranges returned by mmap(). The main work would be in the compiler toolchain and runtime libraries. David Daney
Re: RFC: A new MIPS64 ABI
On Feb 14, 2011, at 6:50 PM, David Daney wrote: > On 02/14/2011 06:33 PM, Matt Thomas wrote: >> >> On Feb 14, 2011, at 6:22 PM, David Daney wrote: >> >>> On 02/14/2011 04:15 PM, Matt Thomas wrote: I have to wonder if it's worth the effort. The primary problem I see is that this new ABI requires a 64bit kernel since faults through the upper 2G will go through the XTLB miss exception vector. >>> >>> Yes, that is correct. It is a 64-bit ABI, and like the existing n32 ABI >>> requires a 64-bit kernel. >> >> N32 doesn't require a LP64 kernel, just a 64-bit register aware kernel. >> Your N32-big does require a LP64 kernel. >> > > But using 'official' kernel sources the only way to get a 64-bit register > aware kernel is for it to also be LP64. So effectively, you do in fact need > a 64-bit kernel to run n32 userspace code. Not all the world is Linux. :) NetBSD supports N32 kernels. > My proposed ABI would need trivial kernel changes: > > o Fix a couple of places where pointers are sign extended instead of zero > extended. I think you'll find there are more of these than you'd expect. > o Change the stack address and address ranges returned by mmap(). My biggest concern is that many many mips opcodes expect properly sign-extended value for registers. Thusly N32-big will require using daddu/dadd/dsub/dsubu for addresses. So that's yet another departure from N32 which can use addu/add/sub/subu. > The main work would be in the compiler toolchain and runtime libraries. You'd also need to update gas for la and dla expansion.
Variant code generation
Hi all, Does GCC has any command line switches which generate variant code? Regards, Sankar Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/
Re: A problem of our Gcc mirror
On Tue, Feb 15, 2011 at 08:51:22AM +0800, Mingjie Xing wrote: > 2011/2/15 Harry Wei : > > Hi us, > >When i want to download the mirror of Gcc 4.3 from the URL > > of China it shows broken. The URL is: http://gcc.gnu.org/mirrors.html > >You can click China's for a try. Could anyone do for it. Or > > i want to take the mirror on my website server(www.harrywei.org). I don't > > know whether it can be well. Any idea? > > > > Thanks. > > Best Regards. > > Harry Wei. > > > > The mirror site in China is unavailable for a long time. I believe it > is helpful if we can have one, though I don't know the requirements of > being a mirror. Hi Mingjie, I think we should take another mirror website for China. This is surely important for us. We should contack the miantainer. Thanks. Best Regards. Harry Wei. > > Thanks, > Mingjie
Re: Variant code generation
sankar chebolu writes: > Does GCC has any command line switches which generate variant code? This question as stated is not appropriate for the mailing list gcc@gcc.gnu.org, which is for the development of gcc. It would be appropriate for gcc-h...@gcc.gnu.org. Please take any followups to gcc-help. Thanks. GCC has many command line options that change the generated code. I could try to guess what you mean by "variant code," but I think it would be best if you followed up to gcc-help with a more specific question. Ian
Re: Target deprecations for 4.6
Joseph S. Myers wrote: * Interix (i[34567]86-*-interix3*) (see PR 47096). I would appreciate it if you could leave Interix. I'll take the responsibility to get it working.
