I asked Google. I thinks he doesn't know about that. :(
I thought I might find a specfic directory in gcc sources whether it supports
the files.
I don't want to compile the whole source files. :(
Still wrong list? Sorry then...
-Original Message-
From: Mike Stump [mailto:[EMAIL PROTEC
On Sunday, July 3, 2005, at 10:57 PM, Sung-Gu wrote:
How can I get byteswap.c, endian.c and some related files for an aleady
installed gcc library? The aleady installed gcc is gcc-3.4.2 for sol8
sparc on
www.sunfreeware.com. But there isn't include/bits/varisouc_files.h. :(
Wrong list. Mayb
Hi everybody,
I have a problem with delayed branch scheduling. Problem in a DSP porting which
has VLIW instructions and delayed branches. While scheduling delayed branches,
GCC (3.4.3) schedules an instruction which is a part of a VLIW instruction. Is
this the problem of the following define_d
Subject: byteswap.c and endian.c for gcc?
How can I get byteswap.c, endian.c and some related files for an aleady
installed gcc library? The aleady installed gcc is gcc-3.4.2 for sol8 sparc on
www.sunfreeware.com. But there isn't include/bits/varisouc_files.h. :(
What do I do to fix my problem?
On Sunday, July 3, 2005, at 03:28 PM, Nathanael Nerode wrote:
Of these, only newlib actually uses libtool, so it's the last holdout
for
switching to newer libtool.
Hopefully we ask the newlib maintainers for a timeline for conversion...
Zack Weinberg asked me to forward this to the GCC mailing list.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
--- Begin Message ---
I appear to have been too quick off the gun unsubscribing to the GCC
mailing lists; this message bounced. Would you please forward it
there?
Daniel Jacobowitz wrote:
>If you want to update libtool, you get to play the all-of-src-uses-it
>game. I have been updating src directories to more recent autoconf
>versions in the hope of getting rid of our outdated libtool someday. I
>believe the only remaining holdout is newlib, but I didn't ch
> GCC 4.0.1 RC3 is now available here:
>
>ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050702/
>
> With luck, this will be the last 4.0.1 release candidate.
SPARC/Solaris 8, 9, 10 are OK:
http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00140.html
http://gcc.gnu.org/ml/gcc-testresults/2005-07/
GCC 4.0.1 RC3 is now available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050702/
With luck, this will be the last 4.0.1 release candidate.
Please do download tarballs from the above URL and confirm that they
work OK on your systems.
I plan to make the final release during the comi
> I am concerned about the use of MEMBER_TYPE_FORCES_BLK in stor-layout.c.
> I believe that, if MEMBER_TYPE_FORCES_BLK is not defined, this code will
> change the mode of a structure containing a single field from BLKmode
> into the mode of the field.
Right, that's precisely what we would need for
> Steve Ellcey defined MEMBER_TYPE_FORCES_BLK when he first implemented
> the ia64-hpux port. At the time, I mentioned using PARALLELs was a
> better solution, but this was a simpler way for him to get the initial
> port working. Since then, there have been a lot of bug fixes to the
> ia64-hp
On Fri, Jul 01, 2005 at 06:49:18PM -0700, James E Wilson wrote:
> Martin Koegler wrote:
> >I continued to work on the support for named address spaces in GCC.
>
> An possible issue is the effect on gcc memory usage and compile time. I
> see you increased the size of MEM rtl which will increase m
Hi,
Now that the copyright paperwork is in place, I would like to submit the
port I've worked on (ST20).
Ideally, I would like to create a dedicated branch for this. Here is the
situation:
-- the port was against GCC 3.3.x;
-- even at that point, it required further work (< 10% of C-only tests
f
Hans Boehm writes:
>
> On Tue, 28 Jun 2005, Andrew Haley wrote:
>
> > Martin Egholm Nielsen writes:
> > > Hi there,
> > >
> > > Sorry for bringing up what may be the most tedious thread ever. But does
> > > "double checked locking" work with GCJ:
> > >
> > > // Works with acquire/
Robert Dewar <[EMAIL PROTECTED]> writes:
[...]
| > The issue is whether they need to become expect in red herring or just
| > know how to write good and correct programs. Interestingly, backis
| > the old days K&R put emphasis on how to write good and useful programs
| > rather than academic exe
Florian Weimer wrote:
* Robert Dewar:
Making programs bug free has more to it than understanding the language
you are writing in, but it is a useful step forward to avoid problems
that come from simply not knowing the rules of the language you are
writing in (I can't guarantee that GNAT is bug
* Robert Dewar:
> Making programs bug free has more to it than understanding the language
> you are writing in, but it is a useful step forward to avoid problems
> that come from simply not knowing the rules of the language you are
> writing in (I can't guarantee that GNAT is bug free in that rega
Gabriel Dos Reis wrote:
Then, one wonders why the GNAT is not bug free ;-p
Making programs bug free has more to it than understanding the language
you are writing in, but it is a useful step forward to avoid problems
that come from simply not knowing the rules of the language you are
writing i
Gabriel Dos Reis wrote:
You may not have noticed but this issue is primarily about C and C++
and we're discussing what the relevant standard says and what
engineering decision we would take. Please, let's not get into
more distractions. We already have plenty of them (many orginating
from you)
19 matches
Mail list logo
