> DJGPP solves this thusly:
>
> /* If INTERP is a Unix-style pathname, like "/bin/sh", we will try
> it with the usual extensions and, if that fails, will further
> search for the basename of the shell along the PATH; this
> allows to run Unix shell scripts without editing their f
powerpc-apple-darwin8.2.0
Using built-in specs.
Target: powerpc-apple-darwin8.2.0
Configured with: ../gcc-4.0.1/configure --enable-languages=c,c+
+,f95,java --program-suffix=-4.0.1 --with-gmp=/sw --with-mpfr=/sw
Thread model: posix
gcc version 4.0.1
> "Jim" == James E Wilson <[EMAIL PROTECTED]> writes:
Jim> Java uses CHAR_TYPE. So Ada would not be the only supported language
Jim> using it if you switched to it.
I was under the impression that CHAR_TYPE was deprecated, so I
purposely avoided it in gcjx. I'm not sure where I got that
imp
Jerome Guitton wrote:
Two solutions : we can either change the tree code to CHAR_TYPE or add a test
to detect Ada character types in the INTEGER_TYPE case, like it is done for
C:
...
The first solution would probably be cleaner, but it would mean that
Ada would be the only supported langage to us
I'm porting gcc 4.0.1 to a new VLIW architecture.
Some of its function units doesn't have internal hardware pipeline forwarding,
so I need to insert "nop" instructions in order to resovle the data hazard.
I used the automata based pipeline description for my ports,
I described the data latency ti
On Thu, Aug 11, 2005 at 12:12:30AM +0200, FX Coudert wrote:
> That's a very nice offer. I think the idea of an automated patch
> boostrap & regtester is of much interest, and i can volunteer to set up
> the systems (if need be, i can move to the machines since i live in Paris).
>
> Furthermore,
On Aug 10, 2005, at 8:54 AM, Jack Howarth wrote:
FX,
I forgot to mention that since the gcc cvs I built last night now
contains your ISATTY and TTYNAM intrinsics patch, I regressed the
portion of the xplor.patch which worked around the prior absence
of the ISATTY intrinsic in gfortran. The
Andreas Schwab wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
The even more correct solution is to not build anything with the
compiler (including libgcc) until after it is installed. Then, it will
just look where it would normally look, and all will be well.
You sure don't want to over
Marcin Dalecki wrote:
On 2005-08-10, at 19:05, Mark Mitchell wrote:
The even more correct solution is to not build anything with the
compiler (including libgcc) until after it is installed. Then, it
will just look where it would normally look, and all will be well.
install host != bui
Mark Mitchell <[EMAIL PROTECTED]> writes:
> The even more correct solution is to not build anything with the
> compiler (including libgcc) until after it is installed. Then, it will
> just look where it would normally look, and all will be well.
You sure don't want to overwrite a compiler that
That's a very nice offer. I think the idea of an automated patch
boostrap & regtester is of much interest, and i can volunteer to set up
the systems (if need be, i can move to the machines since i live in Paris).
Furthermore, it would be interesting if we could install, on some of
those, a rat
On 2005-08-10, at 19:05, Mark Mitchell wrote:
The even more correct solution is to not build anything with the
compiler (including libgcc) until after it is installed. Then, it
will just look where it would normally look, and all will be well.
install host != build host
Most of the time
On Aug 10, 2005, at 12:43 PM, Fariborz Jahanian wrote:
Following patch has exposed an optimization shortcoming:
2005-07-12 Dale Johannesen <[EMAIL PROTECTED]>
* expr.c (compress_float_constant): Add cost check.
* config/rs6000.c (rs6000_rtx_cost): Adjust FLOAT_EXTEND cost.
This patch resul
> Well, it's stopping a real fix for the MinGW build failure being made.
> Adding #! support to libiberty won't work because the problem scripts
> have MSYS/Cygwin paths for the shell (eg. "/bin/sh") that aren't likely
> to be valid to plain Windows.
DJGPP solves this thusly:
/* If INTERP is a
DJ Delorie wrote:
>Supporting #! in libiberty doesn't have to stop you from enhancing gcc
>anyway ;-)
Well, it's stopping a real fix for the MinGW build failure being made.
Adding #! support to libiberty won't work because the problem scripts
have MSYS/Cygwin paths for the shell (eg. "/bin/sh") th
>
> Following patch has exposed an optimization shortcoming:
>
> 2005-07-12 Dale Johannesen <[EMAIL PROTECTED]>
>
> * expr.c (compress_float_constant): Add cost check.
> * config/rs6000.c (rs6000_rtx_cost): Adjust FLOAT_EXTEND cost.
I think this is the same problem as PR 2
Following patch has exposed an optimization shortcoming:
2005-07-12 Dale Johannesen <[EMAIL PROTECTED]>
* expr.c (compress_float_constant): Add cost check.
* config/rs6000.c (rs6000_rtx_cost): Adjust FLOAT_EXTEND cost.
This patch results in generating worse code for the foll
On Wed, Aug 10, 2005 at 11:41:30AM -0700, Mark Mitchell wrote:
>However, by the time I write this, I see that DJ -- who is a right
>person to answer to talk about the purpose of libiberty -- thinks #! is
>a good idea. So, consider me the loyal opposition; let's get on with
>the fix you and DJ like
> I think they are designed to provide a uniform interface to process
> creation, etc. that is a lowest-common-denominator across systems.
I think a better term is "highest common denominator". We *do* want
to enhance systems when we can, because that makes it easier for the
application develo
On Wed, Aug 10, 2005 at 02:35:41PM -0400, DJ Delorie wrote:
>
> > I still think it's a bad solution, though; it's imposing special
> > semantics for process execution in libiberty, rather than the normal
> > ones that you would expect from the OS.
>
> Doing that is part of the purpose of libibert
Christopher Faylor wrote:
Aren't the pex* functions designed to provide a uniform interface where
"uniform" means "like unix"?
I guess I'm not the right person to answer that...
I think they are designed to provide a uniform interface to process
creation, etc. that is a lowest-common-denomin
> Aren't the pex* functions designed to provide a uniform interface
> where "uniform" means "like unix"?
Uniform, yes. "Like Unix" is a coincidence, not a goal. Sometimes we
hide a unix-specific feature because we can't mimic it elsewhere (like
simultaneous multithreading) but we prefer to add
> I still think it's a bad solution, though; it's imposing special
> semantics for process execution in libiberty, rather than the normal
> ones that you would expect from the OS.
Doing that is part of the purpose of libiberty. If the OS does
something unusual, we try to make it act in a conform
On Wed, Aug 10, 2005 at 10:38:26AM -0700, Mark Mitchell wrote:
>Daniel Jacobowitz wrote:
>>On Wed, Aug 10, 2005 at 10:05:26AM -0700, Mark Mitchell wrote:
>>
>>>Christopher Faylor wrote:
>>>
>>>
This would conflict with my proposed changes to pex-win32.c . It seems
like getting '#!' functio
Daniel Jacobowitz wrote:
On Wed, Aug 10, 2005 at 10:05:26AM -0700, Mark Mitchell wrote:
Christopher Faylor wrote:
This would conflict with my proposed changes to pex-win32.c . It seems
like getting '#!' functioning on mingw would be a better solution than
relying on $(LN) on mingw.
FWIW,
On Wed, Aug 10, 2005 at 10:05:26AM -0700, Mark Mitchell wrote:
> Christopher Faylor wrote:
>
> >This would conflict with my proposed changes to pex-win32.c . It seems
> >like getting '#!' functioning on mingw would be a better solution than
> >relying on $(LN) on mingw.
>
> FWIW, I'm opposed to
On Wed, Aug 10, 2005 at 08:48:44AM -0700, H. J. Lu wrote:
> * config.gcc (i[34567]86-*-linux*): Add i386/t-crtfm to tm-file.
> (x86_64-*-linux*): Likewise.
>
> * config/i386/crtfastmath.c: New file.
> * config/i386/t-crtfm: Likewise.
>
> * config/i386/linux.h (ENDFIL
Christopher Faylor wrote:
This would conflict with my proposed changes to pex-win32.c . It seems
like getting '#!' functioning on mingw would be a better solution than
relying on $(LN) on mingw.
FWIW, I'm opposed to the "#!" change to MinGW. It just seems hackish to
me, and it means that we
On Wed, Aug 10, 2005 at 08:13:17AM -0700, H. J. Lu wrote:
> On Wed, Aug 10, 2005 at 10:18:41AM -0400, Jakub Jelinek wrote:
> > On Wed, Aug 10, 2005 at 07:09:04AM -0700, H. J. Lu wrote:
> > > On Tue, Aug 09, 2005 at 02:58:51PM -0700, Richard Henderson wrote:
> > > > On Tue, Aug 09, 2005 at 02:30:46P
On Wed, Aug 10, 2005 at 10:18:41AM -0400, Jakub Jelinek wrote:
> On Wed, Aug 10, 2005 at 07:09:04AM -0700, H. J. Lu wrote:
> > On Tue, Aug 09, 2005 at 02:58:51PM -0700, Richard Henderson wrote:
> > > On Tue, Aug 09, 2005 at 02:30:46PM -0700, H. J. Lu wrote:
> > > > There is a minor problem. How can
On Wed, Aug 10, 2005 at 07:09:04AM -0700, H. J. Lu wrote:
> On Tue, Aug 09, 2005 at 02:58:51PM -0700, Richard Henderson wrote:
> > On Tue, Aug 09, 2005 at 02:30:46PM -0700, H. J. Lu wrote:
> > > There is a minor problem. How can I add crtfastmath.o for SSE targets
> > > only?
> >
> > You don't.
On Tue, Aug 09, 2005 at 02:58:51PM -0700, Richard Henderson wrote:
> On Tue, Aug 09, 2005 at 02:30:46PM -0700, H. J. Lu wrote:
> > There is a minor problem. How can I add crtfastmath.o for SSE targets
> > only?
>
> You don't. You either add code to detect sse, or you make the
> spec depend on -m
One other question. Do you know much c++? I had to make one change
to some buggy c++ code to allow gcc 4.0 and main branch to compile
xplor-nih...
I'm sorry but i don't know anything more about c++ than its name. About
your problem, i'd guess that you could try to create a reduced
preproce
FX,
I forgot to mention that since the gcc cvs I built last night now
contains your ISATTY and TTYNAM intrinsics patch, I regressed the
portion of the xplor.patch which worked around the prior absence
of the ISATTY intrinsic in gfortran. The resulting xplor-nih build
works fine.
One other q
Is it just me...or?
I get the feeling that if I first bootstrap gcc, then update some
files, then bubblestrap to check again... that gnat and friends get
rebuilt?
I really like bubblestrap, it gets me a shorter time to test a patch
or so. However, if gnat and friends somehow are more sensitively
35 matches
Mail list logo
