David Edelsohn <[EMAIL PROTECTED]> writes:
> Upgrading GNU tar to 1.15.1 fixed the problem for me.
So what is the actual requirement - 1.14 or "1.14 or above" ?
--
With regards, Roman.
> Dan Kegel writes:
>> The problem has nothing to do with warnings from tar, which are neither
>> errors nor silent failures. I believe a file either got skipped or
>> unpacked with the wrong name.
Dan> Egads. Can you point me to more info? I've been building with older
Dan> versions of t
Greg Schafer wrote:
> Remove the -j3 and all is well. I suppose most folks never run `make
> install' in parallel.. but sometimes it's convenient to just simply:
>
> export MAKEFLAGS=-j3
>
> for big compile jobs.
I'm not aware of anything parallel-make unfriendly about my patch, but I
can beli
On 03/01/06 17:51, H. J. Lu wrote:
> SPECint_base2000 1.31%
> SPECfp_base2000 1.62%
>
All these numbers are within the usual SPEC noise. Not Worth It.
Daniel Towner <[EMAIL PROTECTED]> writes:
> I maintain a port of gcc for an embedded processor which has a HALT
> instruction. This instruction stops the processor, and generates an
> appropriate interrupt to indicate to its parent system that it has
> stopped. The instruction is accessed by the p
On Thu, Mar 02, 2006 at 12:27:46AM +, Steven Newbury wrote:
> I've given this a go. I've successully built a stage1 cross compiler and
> installed the glibc headers. However, on re-building gcc it fails to link
> libgcc:
>
> ... ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp
H. J. Lu wrote:
> You are comparing apply with orange. If a user uses -O2, he/she will
> see much more than that.
We can argue about that, but I don't think so. I'm comparing a user can
achieve without the patch with the performance they can achieve with the
patch. On all chips, for all time, u
Eric Botcazou wrote:
Richard, Arnaud, could you check amongst GNAT experts if for such types
(non power of two modulus), it's not worth enabling overflow checks by
default now that we have VRP doing non trivial optimisations? People
using non power of two modulus are not caring for performance an
Laurent GUERBY wrote:
VRP might now force us to update the overflow list but I'm not sure
about switching to a full -gnato everywhere.
well you can expect some fiddling each version if you work this way
> Richard, Arnaud, could you check amongst GNAT experts if for such types
> (non power of two modulus), it's not worth enabling overflow checks by
> default now that we have VRP doing non trivial optimisations? People
> using non power of two modulus are not caring for performance anyway, so
> havi
--- Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 01, 2006 at 06:20:53PM +, Steven Newbury wrote:
> > OK, thank-you. I'll target "arm-iwmmxt-linux-gnueabi" with --with-cpu= etc
> and
> > --disable-multilib. The vendor string is for my build scripts and also
> will
> > help diff
On Wed, Mar 01, 2006 at 04:05:16PM -0800, H. J. Lu wrote:
> On Wed, Mar 01, 2006 at 03:06:46PM -0800, Mark Mitchell wrote:
> > H. J. Lu wrote:
> >
> > > Here are diffs of "-O2 -mtune=nocona -ffast-math" vs
> > > "-O2 -mtune=generic -ffast-math" on Nocona:
> >
> > A 1.5% performance improvement, w
On Wed, Mar 01, 2006 at 03:06:46PM -0800, Mark Mitchell wrote:
> H. J. Lu wrote:
>
> > Here are diffs of "-O2 -mtune=nocona -ffast-math" vs
> > "-O2 -mtune=generic -ffast-math" on Nocona:
>
> A 1.5% performance improvement, while certainly significant for some
> users, is not worth taking any ser
On GCC we use -gnato on tests known to need it
(/gcc/testsuite/ada/acats/overflow.lst) since we want to test flags
the typical GCC/Ada user does use and not what official validation
requires (which is -gnato -gnatE IIRC).
Well that would make the most sense if the code in the ACATS
On Mar 1, 2006, at 3:47 AM, HASSAN AL MOATASSIME wrote:
I have a problem with the compiler gcc 3.4.4.
With the gcc 3.2 compiler, i have no problem with the following
instruction :
creal(U0[i])=PartieReelle;
cimag(U0[i])=PartieImaginaire;
Now with the gcc 3.4.4 i
Laurent GUERBY wrote:
Ok this test is checking a corner case of the language, namely
non power of two modular types.
It looks like this one needs overflow checking to pass (-gnato):
All ACATS tests should be run with -gnatE -gnato
On Wed, 2006-03-01 at 18:48 -0500, Richard Kenner wrote:
> It looks like this one needs overflow checking to pass (-gnato):
>
> ACATS should aways be run with -gnato since that's the only way to
> get the behavior mandated by RM. Why are we running it without it? Is
> this new? Certainly -g
It looks like this one needs overflow checking to pass (-gnato):
ACATS should aways be run with -gnato since that's the only way to
get the behavior mandated by RM. Why are we running it without it? Is
this new? Certainly -gnato was used during validations.
Richard, Arnaud, could you c
Ok this test is checking a corner case of the language, namely
non power of two modular types.
It looks like this one needs overflow checking to pass (-gnato):
$ gnatmake -f -I../../../support/ c460008.adb
gcc -c -I../../../support/ c460008.adb
gcc -c -I./ -I../../../support/ -I-
/home/guerby/wo
H. J. Lu wrote:
> Here are diffs of "-O2 -mtune=nocona -ffast-math" vs
> "-O2 -mtune=generic -ffast-math" on Nocona:
A 1.5% performance improvement, while certainly significant for some
users, is not worth taking any serious risks on a release branch. The
purpose of bug-fix releases on the relea
On Wednesday 01 March 2006 23:51, H. J. Lu wrote:
> I'd like to see the default -O2 generate decent code for Nocona.
But then, you did so too months ago, when the GCC 4.1 development
cycle was still in stage1/stage2. Nocona has been around for a
very long time already (I have a Prescott-T myself
On Wed, Mar 01, 2006 at 02:19:47PM -0800, Mark Mitchell wrote:
> H. J. Lu wrote:
>
> > Here are diffs of SPEC CPU 2K between before and after with gcc 4.1
> > using "-O2 -ffast-math" on Nocona:
>
> Steven's right; this is clearly a new feature. HJ's also right; we've
> made exceptions before.
>
On Wednesday 01 March 2006 22:06, Steven Bosscher wrote:
> Your patch implements a new feature. New features usually don't fix
> regression. So your patch should be considered for GCC 4.1 IMHO.
I mean should not, obviously.
Gr.
Steven
On Wed, Mar 01, 2006 at 02:24:58PM -0800, Mark Mitchell wrote:
> Joe Buck wrote:
>
> > What is the basis for the report that older tars don't work?
>
> This posting:
>
> http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01861.html
>
> It may certainly be the case that some patched version of tar on
Here's the next segment in the ongoing saga of VRP vs Ada...
Not surprisingly we have another case where an object gets a
value outside of its TYPE_MIN_VALUE/TYPE_MAX_VALUE defined range.
Investigating the c460008 testsuite failure we have the following
code for Fixed_To_Short before VRP runs:
Joe Buck wrote:
> What is the basis for the report that older tars don't work?
This posting:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01861.html
It may certainly be the case that some patched version of tar on RHEL
works fine (one would indeed hope and expect that distributors are
adding va
H. J. Lu wrote:
> Here are diffs of SPEC CPU 2K between before and after with gcc 4.1
> using "-O2 -ffast-math" on Nocona:
Steven's right; this is clearly a new feature. HJ's also right; we've
made exceptions before.
Like Steven, I would like to see what the difference is between
-mtune=generic
> That is the whole point: I'd like to back port the -mtune=generic
> change to 4.1 branch. There are so many different IA32/x86-64
> processors. The default optimization is more useful than -mtune=xxx.
> The new default (-mtune=generic) is much better than the old one for
> the current IA32/x86-64
On Wed, Mar 01, 2006 at 10:43:40PM +0100, Richard Guenther wrote:
> On 3/1/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> > On Wed, Mar 01, 2006 at 10:06:57PM +0100, Steven Bosscher wrote:
> > > On Wednesday 01 March 2006 21:49, H. J. Lu wrote:
> > > > It is the issue of quality of gcc 4.1 on IA32/x86-6
On 3/1/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 01, 2006 at 10:06:57PM +0100, Steven Bosscher wrote:
> > On Wednesday 01 March 2006 21:49, H. J. Lu wrote:
> > > It is the issue of quality of gcc 4.1 on IA32/x86-64. The current gcc
> > > 4.1 performs very poorly on IA32/x86-64, comparin
On Wed, Mar 01, 2006 at 10:06:57PM +0100, Steven Bosscher wrote:
> On Wednesday 01 March 2006 21:49, H. J. Lu wrote:
> > It is the issue of quality of gcc 4.1 on IA32/x86-64. The current gcc
> > 4.1 performs very poorly on IA32/x86-64, comparing against gcc 4.2.
>
> Oh, really? Where are the numb
On Wed, 2006-03-01 at 08:24 -0500, Richard Kenner wrote:
> So this is likely to be a FE Ada coding bug and not a FE/ME/BE interface
> issue, thanks for spotting this!
>
> Sorry, my last suggestion is clearly wrong. I think is right.
>
> *** uintp.adb 12 Sep 2003 21:50:56 - 1.80
On Wednesday 01 March 2006 21:49, H. J. Lu wrote:
> It is the issue of quality of gcc 4.1 on IA32/x86-64. The current gcc
> 4.1 performs very poorly on IA32/x86-64, comparing against gcc 4.2.
Oh, really? Where are the numbers you have to support this, may I
say, unlikely claim?
It seemed to me t
> > It's a new feature and not a fix for a regression. -> totally
> > inappropriate.
>
> It is the issue of quality of gcc 4.1 on IA32/x86-64. The current gcc
> 4.1 performs very poorly on IA32/x86-64, comparing against gcc 4.2. I
> can't recommond gcc 4.1 to most people using IA32/x86-64. This ch
On Wed, Mar 01, 2006 at 09:42:19PM +0100, Richard Guenther wrote:
> On 3/1/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> > On Wed, Mar 01, 2006 at 09:21:19PM +0100, Steven Bosscher wrote:
> > > On Wednesday 01 March 2006 21:14, H. J. Lu wrote:
> > > > Is 4.1 branch open now? I'd like to back port the x
On 3/1/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 01, 2006 at 09:21:19PM +0100, Steven Bosscher wrote:
> > On Wednesday 01 March 2006 21:14, H. J. Lu wrote:
> > > Is 4.1 branch open now? I'd like to back port the x86
> > > -mtune=generic patch:
> >
> > Isn't that totally inappropriate fo
On Wed, Mar 01, 2006 at 09:21:19PM +0100, Steven Bosscher wrote:
> On Wednesday 01 March 2006 21:14, H. J. Lu wrote:
> > Is 4.1 branch open now? I'd like to back port the x86
> > -mtune=generic patch:
>
> Isn't that totally inappropriate for a release branch?
>
What is it inappropriate about?
On Wednesday 01 March 2006 21:14, H. J. Lu wrote:
> Is 4.1 branch open now? I'd like to back port the x86
> -mtune=generic patch:
Isn't that totally inappropriate for a release branch?
Gr.
Steven
The GCC 4.1 branch is now open, under the usual branch rules: fixes for
regressions only.
Remember: the GCC 4.0 branch will freeze at midnight tonight, GMT-8, in
preparation for GCC 4.0.3.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
On Wed, Mar 01, 2006 at 08:24:18AM -0800, Mark Mitchell wrote:
>
> GCC 4.1.0 has been released.
>
It is great. Is 4.1 branch open now? I'd like to back port the x86
-mtune=generic patch:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01436.html
to 4.1.1.
Thanks.
H.J.
On Wed, Mar 01, 2006 at 08:24:18AM -0800, Mark Mitchell wrote:
> 1. GNU TAR 1.14 is required to unpack the source releases. Other
>versions of tar are likely to report errors or silently unpack the
>file incorrectly.
Red Hat EL3 comes with tar 1.13.25 (though since the RPM package on the
Hi,
A pre-release of GCC-3.4.6 is available at
ftp://gcc.gnu.org/pub/gcc/prerelease-3.4.6-20060301/
Please download and test.
At the moment, there is only one issue I consider important for
GCC-3.4.6. This is wrong code generation issue middle-end/24804. It
was already present in
On Wed, Mar 01, 2006 at 06:20:53PM +, Steven Newbury wrote:
> OK, thank-you. I'll target "arm-iwmmxt-linux-gnueabi" with --with-cpu= etc
> and
> --disable-multilib. The vendor string is for my build scripts and also will
> help differentiate the toolchain, is that valid?
Yep.
--
Daniel Ja
--- Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 01, 2006 at 05:43:53PM +, Steven Newbury wrote:
> > My reason for using the xscale-* triplets was because of the warning below
> from
> > gcc/config/arm/t-xscale-elf:
> >
> > # The iWMMXt multilibs are suppressed for now because
On Wed, Mar 01, 2006 at 10:10:39AM -0800, Dan Kegel wrote:
> On 3/1/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> > > > 1. GNU TAR 1.14 is required to unpack the source releases. Other
> > > > versions of tar are likely to report errors or silently unpack the
> > > > file incorrectly.
> >
On 3/1/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> > > 1. GNU TAR 1.14 is required to unpack the source releases. Other
> > > versions of tar are likely to report errors or silently unpack the
> > > file incorrectly.
>
> The problem has nothing to do with warnings from tar, which are ne
On Wed, Mar 01, 2006 at 10:05:52AM -0800, Dan Kegel wrote:
> Mark wrote:
> > 1. GNU TAR 1.14 is required to unpack the source releases. Other
> > versions of tar are likely to report errors or silently unpack the
> > file incorrectly.
>
> Now hold on there, bubaloo.
> I thought the warnings f
Mark wrote:
> 1. GNU TAR 1.14 is required to unpack the source releases. Other
> versions of tar are likely to report errors or silently unpack the
> file incorrectly.
Now hold on there, bubaloo.
I thought the warnings from older versions of tar were benign.
The warnings I'm seeing from tar-1
On Wed, Mar 01, 2006 at 05:43:53PM +, Steven Newbury wrote:
> My reason for using the xscale-* triplets was because of the warning below
> from
> gcc/config/arm/t-xscale-elf:
>
> # The iWMMXt multilibs are suppressed for now because gcc only
> # supports generating them with the IWMMXT or AAP
--- Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 01, 2006 at 05:15:07AM +, Steven Newbury wrote:
> > I have managed to build with arm-iwmmxt-linux-gnu, where iwmmxt as the
> vendor
> > string is picked up by my ebuild scripts to pass the iwmmxt target flags.
> > Given my object
--- Paul Brook <[EMAIL PROTECTED]> wrote:
> On Wednesday 01 March 2006 05:05, Daniel Jacobowitz wrote:
> > On Wed, Mar 01, 2006 at 04:57:03AM +, Steven Newbury wrote:
> > > Thanks for the quick response!
> > > I'm sure it seems I like to make hard wok for myself! It gets worse, I'm
> > > port
René Rebe wrote:
> As expected the headers are in the correct location now.
Good. Have you filed a bug in Bugzilla about this issue? If not, would
you care to do so? To do so, please visit gcc.gnu.org, and look for the
link on the left side of the page.
Thanks,
--
Mark Mitchell
CodeSourcery
>
> Hi Andrew,
>
> The problem with calling __builtin_trap directly comes when several
> traps are called in the same function. For example, if a function
> contains several identical assertions on different code paths, then gcc
> will generate a single copy of the assertion, and branch to tha
On Wed, 2006-03-01 at 08:15 +0100, Eric Botcazou wrote:
> Hi,
>
> I'm a big fan of Zack's "over-my-dead-body" motto when it comes to ditching
> bootstrap with non-GCC compilers. :-) It turns out that bootstrap is again
> broken on mainline for them (at least Sun CC) and that the problem is anot
GCC 4.1.0 has been released.
This release is a major release, containing substantial new
functionality relative to previous releases. See:
http://gcc.gnu.org/gcc-4.1/changes.html
for a list of new features, improvements, and other changes.
This release is available from the FTP servers list
>My confusion is that these functions currently allow arithmetic
>operations of the form "reg = op(mem,immed)" even though this
>shape isn't supported by x86 ISA.
The IMUL instruction can have this form.
Ross Ridge
Hi Andrew,
The problem with calling __builtin_trap directly comes when several
traps are called in the same function. For example, if a function
contains several identical assertions on different code paths, then gcc
will generate a single copy of the assertion, and branch to that copy
from e
On Wednesday 01 March 2006 05:05, Daniel Jacobowitz wrote:
> On Wed, Mar 01, 2006 at 04:57:03AM +, Steven Newbury wrote:
> > Thanks for the quick response!
> > I'm sure it seems I like to make hard wok for myself! It gets worse, I'm
> > porting Gentoo Linux to iWMMXt with pure EABI kernel and u
H. J. Lu writes:
> On Wed, Mar 01, 2006 at 03:19:18PM +, Andrew Haley wrote:
> > H. J. Lu writes:
> > > On Wed, Mar 01, 2006 at 02:11:21PM +, Andrew Haley wrote:
> > > > H. J. Lu writes:
> > > > >
> > > > > The fix was posted at
> > > > >
> > > > > http://gcc.gnu.org/ml/
On Wed, Mar 01, 2006 at 03:19:18PM +, Andrew Haley wrote:
> H. J. Lu writes:
> > On Wed, Mar 01, 2006 at 02:11:21PM +, Andrew Haley wrote:
> > > H. J. Lu writes:
> > > >
> > > > The fix was posted at
> > > >
> > > > http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01486.html
> > >
H. J. Lu writes:
> On Wed, Mar 01, 2006 at 02:11:21PM +, Andrew Haley wrote:
> > H. J. Lu writes:
> > >
> > > The fix was posted at
> > >
> > > http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01486.html
> >
> > If it still works, please check it in.
>
> Ooops. The correct patch i
On Wed, Mar 01, 2006 at 02:11:21PM +, Andrew Haley wrote:
> H. J. Lu writes:
> > On Wed, Mar 01, 2006 at 11:48:39AM +, Andrew Haley wrote:
> > > Andrew Haley writes:
> > > > Andrew Pinski writes:
> > > > > With clean sources on x86_64-linux-gnu, I am getting almost all
> tests
> >
>
> Hi all,
>
> I maintain a port of gcc for an embedded processor which has a HALT
> instruction. This instruction stops the processor, and generates an
> appropriate interrupt to indicate to its parent system that it has
> stopped. The instruction is accessed by the programmer using a
> por
Hi all,
I maintain a port of gcc for an embedded processor which has a HALT
instruction. This instruction stops the processor, and generates an
appropriate interrupt to indicate to its parent system that it has
stopped. The instruction is accessed by the programmer using a
port-specific built
On Wed, Mar 01, 2006 at 05:15:07AM +, Steven Newbury wrote:
> I have managed to build with arm-iwmmxt-linux-gnu, where iwmmxt as the vendor
> string is picked up by my ebuild scripts to pass the iwmmxt target flags.
> Given my objective, am I wrong to try to make a tool chain that targets
> xs
H. J. Lu writes:
> On Wed, Mar 01, 2006 at 11:48:39AM +, Andrew Haley wrote:
> > Andrew Haley writes:
> > > Andrew Pinski writes:
> > > > With clean sources on x86_64-linux-gnu, I am getting almost all
> > tests
> > > > for running gij to fail. Does anyone know what is going on he
On Wed, Mar 01, 2006 at 11:48:39AM +, Andrew Haley wrote:
> Andrew Haley writes:
> > Andrew Pinski writes:
> > > With clean sources on x86_64-linux-gnu, I am getting almost all tests
> > > for running gij to fail. Does anyone know what is going on here?
> >
> > I'll have a try now.
>
On Tue, Feb 28, 2006 at 08:40:18PM -0500, Andrew Pinski wrote:
> With clean sources on x86_64-linux-gnu, I am getting almost all tests
> for running gij to fail. Does anyone know what is going on here?
I will bet it is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311
H.J.
On Wed, 1 Mar 2006, Andrew Pinski wrote:
This means your libmpfr.a was compiled for the wrong glibc.
Thanks for the hint -- now I have completed the 4.1.0 build/install, with
[EMAIL PROTECTED] 19 $ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.0/configure
So this is likely to be a FE Ada coding bug and not a FE/ME/BE interface
issue, thanks for spotting this!
Sorry, my last suggestion is clearly wrong. I think is right.
*** uintp.adb 12 Sep 2003 21:50:56 - 1.80
--- uintp.adb 1 Mar 2006 13:16:21 -
*** package b
On Mar 1, 2006, at 6:48 AM, Andrew Haley wrote:
Andrew Haley writes:
Andrew Pinski writes:
With clean sources on x86_64-linux-gnu, I am getting almost all tests
for running gij to fail. Does anyone know what is going on here?
I'll have a try now.
You are right. The error is
lt-gij: rel
So this is likely to be a FE Ada coding bug and not a FE/ME/BE interface
issue, thanks for spotting this!
Indeed, having looked a bit closer at Uintp, I think this is the right fix.
Robert, please confirm.
*** uintp.adb 12 Sep 2003 21:50:56 - 1.80
--- uintp.adb 1 Mar 2006 13:
On Mar 1, 2006, at 2:43 AM, Maurizio Loreti wrote:
/usr/soft/lib/libmpfr.a(set_str.o): In function `mpfr_set_str':
set_str.c:(.text+0x174): undefined reference to `__ctype_b'
set_str.c:(.text+0x3b5): undefined reference to `__ctype_b'
set_str.c:(.text+0x411): undefined reference to `__ctype_b'
On Tue, 2006-02-28 at 18:59 -0500, Daniel Jacobowitz wrote:
> On Tue, Feb 28, 2006 at 03:40:37PM -0700, Jeffrey A Law wrote:
> > Here's a great example from uintp.adb (which is the cause of the
> > testsuite hang FWIW)
> >
> > We have a loop with the following termination code in uintp.num_bits
>
Andrew Haley writes:
> Andrew Pinski writes:
> > With clean sources on x86_64-linux-gnu, I am getting almost all tests
> > for running gij to fail. Does anyone know what is going on here?
>
> I'll have a try now.
You are right. The error is
lt-gij: relocation error:
/home/aph/gcc/trun
Hi,
I have a problem with the compiler gcc 3.4.4.
With the gcc 3.2 compiler, i have no problem with the following instruction :
creal(U0[i])=PartieReelle;
cimag(U0[i])=PartieImaginaire;
Now with the gcc 3.4.4 i have the folowing message :
-- erreur: invalid lvalue
Jeffrey A Law wrote:
> I wouldn't have a problem with non-canonical bounds if there were
> no way to get a value into an object which is outside the
> bounds. But if we can get values into the object which are outside
> those bounds, then either the bounds are incorrect or the program
> is invali
Andrew Pinski writes:
> With clean sources on x86_64-linux-gnu, I am getting almost all tests
> for running gij to fail. Does anyone know what is going on here?
I'll have a try now.
Andrew.
Eric Botcazou <[EMAIL PROTECTED]> writes:
[...]
| Comments?
Go for it!
-- Gaby
On Mar 1, 2006, at 1:43 AM, Eric Fisher wrote:
Hi,
After talking about mips-elf, mips-linux, mips-elf-linux-gnu, my
friend told that there is also a target of mips-linux-elf. My God,
confused.
Ignore your friend.
-eric
Hi,
After talking about mips-elf, mips-linux, mips-elf-linux-gnu, my
friend told that there is also a target of mips-linux-elf. My God,
confused.
Yours,
Eric.
Hi all,
I'm designing a new hardware that needs to know which GPR contains a
simple integer, and which contained pointer. The hardware simply needs
different load operations for both (we're talking load/store machines,
with no indirect addressing to make life easier).
From the compiler's per
Hi,
On Tuesday 28 February 2006 22:30, René Rebe wrote:
> Hi,
>
> On Tuesday 28 February 2006 20:54, Mark Mitchell wrote:
>
> > > gxx_include_dir = $(libsubdir)/include/c++
> >
> > That's the problem, then; there's no definition of libsubdir in that
> > Makefile. What happens if you provide th
83 matches
Mail list logo
