Folks,
you all are great brave men hacking on one of the most mission-critical
free software piece ever. I'm seeing some of you are more and more
frustrated, since this thread is turning into the flame-war.
As a long time GCC user, I would like to ask you to calm down a bit if
this is possible,
Peter Barada wrote on 17/05/2005 07:12:41:
>
> >BS. Even the large disto builders do cross compilations a lot.
>
> Yeah, I know. I did consulting for a 'large disto builder'. Do you
> have a clue how long it takes to build the base packages for a PXA255
> board(including X11 that won't ev
>BS. Even the large disto builders do cross compilations a lot.
Yeah, I know. I did consulting for a 'large disto builder'. Do you
have a clue how long it takes to build the base packages for a PXA255
board(including X11 that won't even run on the board but is required
due to package dependeci
On May 16, 2005, Georg Bauhaus <[EMAIL PROTECTED]> wrote:
> - cd ada/doctools && gnatmake -q xgnatugn
> + cd ada/doctools && gnatmake -q --GCC=$(CC) xgnatugn -largs --GCC=$(CC)
Don't you need quotes around $(CC), for the general case in which it's
not as simple as `gcc', but rather someth
On May 16, 2005, Florian Weimer <[EMAIL PROTECTED]> wrote:
> Is this really necessary? I would think that a LD_PRELOADed DSO which
> prevents execution of freshly compiled binaries would be sufficient to
> catch the most obvious errors.
This would break legitimate tests on the build environment,
On May 16, 2005, Russ Allbery <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> On May 16, 2005, Russ Allbery <[EMAIL PROTECTED]> wrote:
>>> And package maintainers will never take cross-compilation seriously
>>> even if they really want to because they, for the most par
> Please download, build, and test.
I've now completed testing on the PA and don't see any major issues.
The only easily fixable issue that showed up in testing was the failure
of 26_numerics/complex/pow.cc under hpux 10.20. This fails because of
a corner case in the 10.20 math library. The pro
"zouq" <[EMAIL PROTECTED]> writes:
> in the gt-c-decl.h,
> three functions about lang_decl,
> gt_pch_nx_lang_decl(),gt_ggc_mx_lang_decl, gt_pch_g_9lang_decl(),
> what are the differences between the three functions?
The _nx_ functions fill in the pchw field of ggc_root_tab. This is used
when sav
> Yes, feel free to send questions to this list or, if you prefer, to
> contact me directly about getting started.
>
> Janis Johnson
> IBM Linux Technology Center
Alright, to start with, I'd like to get a few clarifications.
Should I go through all of the test cases in testsuite/gcc.misc-tests
David Edelsohn wrote:
Mark Mitchell writes:
Mark> In the past, if libiconv wasn't set in site.exp,
Mark> target_supports.exp:check_iconv_available would crash. So, I changed it
Mark> to default to "-liconv".
Mark> On GNU/Linux, that's not a very good default, since iconv is in libc.
Mark> The
Hi list,
We are currently making a port for the TMS320C54x, I have some questions
on how to implement certain operations. Most arithmetic operations on
this machine are affected by flags which control how the operations do
sign-extension and overflow. These are called the "SXM" and "OVM" flags
res
> Mark Mitchell writes:
Mark> In the past, if libiconv wasn't set in site.exp,
Mark> target_supports.exp:check_iconv_available would crash. So, I changed it
Mark> to default to "-liconv".
Mark> On GNU/Linux, that's not a very good default, since iconv is in libc.
Mark> The same seems to h
On Tuesday 17 May 2005 03:16, Joe Buck wrote:
> On Tue, May 17, 2005 at 03:11:03AM +0200, Steven Bosscher wrote:
> > On Tuesday 17 May 2005 02:59, Steven Bosscher wrote:
> > > Oh, and how helpful of you to post that patch to gcc-patches@ too...
> > > NOT!
> >
> > Ah, I see you did post it to gcc-pa
In the past, if libiconv wasn't set in site.exp,
target_supports.exp:check_iconv_available would crash. So, I changed it
to default to "-liconv".
On GNU/Linux, that's not a very good default, since iconv is in libc.
The same seems to hold on Solaris and HP-UX.
Does anyone have opinions about
On Tue, May 17, 2005 at 03:11:03AM +0200, Steven Bosscher wrote:
> On Tuesday 17 May 2005 02:59, Steven Bosscher wrote:
> > Oh, and how helpful of you to post that patch to gcc-patches@ too...
> > NOT!
>
> Ah, I see you did post it to gcc-patches@, but not to fortran@, which
> is a requirement for
On Tuesday 17 May 2005 02:59, Steven Bosscher wrote:
> On Tuesday 17 May 2005 02:53, Ralf Corsepius wrote:
> > On Tue, 2005-05-17 at 00:10 +0200, Steven Bosscher wrote:
> > > On Monday 16 May 2005 23:43, Ralf Corsepius wrote:
> > > > On Mon, 2005-05-16 at 10:42 -0400, Peter Barada wrote:
> > > > >
DJ Delorie wrote:
(There's still a POSIX-ism in the generator, in that it tries to
write to "/dev/null". On Windows systems, I bet this will often
work, but create a real file with that name. It would be better,
and avoid portability problems, to guard the calls to fwrite, etc.,
with "if (file)"
On Tuesday 17 May 2005 02:53, Ralf Corsepius wrote:
> On Tue, 2005-05-17 at 00:10 +0200, Steven Bosscher wrote:
> > On Monday 16 May 2005 23:43, Ralf Corsepius wrote:
> > > On Mon, 2005-05-16 at 10:42 -0400, Peter Barada wrote:
> > > > Until package maintainers take cross-compilation *seriously*, I
1.
in the gt-c-decl.h,
three functions about lang_decl,
gt_pch_nx_lang_decl(),gt_ggc_mx_lang_decl, gt_pch_g_9lang_decl(),
what are the differences between the three functions?
2.
i can find the prefixes in the gengtype.c,
what are they setting for?
static const struct write_types_data ggc_wtd =
> (There's still a POSIX-ism in the generator, in that it tries to
> write to "/dev/null". On Windows systems, I bet this will often
> work, but create a real file with that name. It would be better,
> and avoid portability problems, to guard the calls to fwrite, etc.,
> with "if (file)" rather
On Tue, 2005-05-17 at 00:10 +0200, Steven Bosscher wrote:
> On Monday 16 May 2005 23:43, Ralf Corsepius wrote:
> > On Mon, 2005-05-16 at 10:42 -0400, Peter Barada wrote:
> > > Until package maintainers take cross-compilation *seriously*, I have
> > > no choice but to do native compilation of a larg
> So you can say "mem=128m" or the like.
Yes, but that doesn't help when I want to test one application on a
system that's been otherwise up and running for months, and is busy
doing other things. The RSS limit is *supposed* to do just what we
want, but nobody seems to implement it correctly any
I've very nearly ready to release GCC 3.4.4. If you have objections or
high-priority fixes that you think will be required for this release,
please speak up within the next 24 hours.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Ian Lance Taylor wrote:
1. Remove the use of config.h and HAVE_*_H.
2. Modify the generator not to depend on libiberty headers, including
hashtab.h, by substituting a simple dictonary object.
3. Adjust struct-layout-1.exp accordingly.
This is what I would recommend anyhow.
Done with the attached
On Mon, May 16, 2005 at 03:18:28PM -0700, Zack Weinberg wrote:
>
> No, the instability in test names is a minor price to pay for having
> less custom Tcl cruft.
>
> You want to talk to Janis Johnson <[EMAIL PROTECTED]>, she's the
> testsuite maintainer these days.
Yes, feel free to send question
On Fri, 13 May 2005, dmdlf wrote:
> I note that you have a wiki from 27 January 2005.
> It is made known by a line in the News/Announcements, which will disappear at
> some time, and anyway is not always the first reading for people.
> I suggest that, when the state of the wiki will be mature enoug
Nicholas K Rivers <[EMAIL PROTECTED]> writes:
> Mike Stump wrote:
>>
>> In general, I am against bug migration. We want the testcase names
>> to be stable, for ever, to quote my favorite.., uhm, to quote sponge
>> bob.
>
> I see. Well maybe there's a better task I could do.
No, the instability
On Mon, May 16, 2005 at 05:35:43PM -0400, DJ Delorie wrote:
>
> > What I have problem understanding is the last sentence of this
> > paragraph in the light of your claim that it will results in
> > swapping especially when we consider developers' machines with
> > 512MB/1GB RAM, i.e. machines wher
On Tuesday 17 May 2005 00:07, Joe Buck wrote:
> On Mon, May 16, 2005 at 10:15:29PM +0200, Steven Bosscher wrote:
> > On Monday 16 May 2005 20:26, Karel Gardas wrote:
> > > On Mon, 16 May 2005, Steven Bosscher wrote:
> > > > Just for the record, attached is gcctest's history of the overall
> > > > m
On Monday 16 May 2005 23:43, Ralf Corsepius wrote:
> On Mon, 2005-05-16 at 10:42 -0400, Peter Barada wrote:
> > Until package maintainers take cross-compilation *seriously*, I have
> > no choice but to do native compilation of a large hunk of the packages
> > on eval boards that can literally takes
On Mon, May 16, 2005 at 10:15:29PM +0200, Steven Bosscher wrote:
> On Monday 16 May 2005 20:26, Karel Gardas wrote:
> > On Mon, 16 May 2005, Steven Bosscher wrote:
> > > Just for the record, attached is gcctest's history of the overall
> > > memory requirement at -O[0123] for combine.i, insn-attrta
Mike Stump wrote:
> On May 16, 2005, at 12:21 PM, Nicholas K Rivers wrote:
>> I'm new to GCC and hoping to get involved in its development. I'm
>> working on
>> moving tests out of testsuite/gcc.misc-tests and putting them into
>> the more
>> general frameworks--a project listed on
>> http://gcc.g
On Mon, 2005-05-16 at 10:42 -0400, Peter Barada wrote:
> Until package maintainers take cross-compilation *seriously*, I have
> no choice but to do native compilation of a large hunk of the packages
> on eval boards that can literally takes *DAYS* to build.
The most amazing fact to me is: Not eve
On Thu, 5 May 2005, John Sullivan wrote:
> I've updated the mirror list on gnu.org. I'm passing this on to you so
> you can consider it for the GCC mirrors list as per his request.
Thanks.
Please note that for http://gcc.gnu.org/mirrors.html we only add mirrors
which specifically mirror the ftp a
> What I have problem understanding is the last sentence of this
> paragraph in the light of your claim that it will results in
> swapping especially when we consider developers' machines with
> 512MB/1GB RAM, i.e. machines where memory is not "tight".
Sigh, Linux works the same way. Processes c
>What I have problem understanding is the last sentence of this paragraph
>in the light of your claim that it will results in swapping especially
>when we consider developers' machines with 512MB/1GB RAM, i.e. machines
>where memory is not "tight".
Sure, and this is the point. Pick a number f
On May 16, 2005, at 12:21 PM, Nicholas K Rivers wrote:
I'm new to GCC and hoping to get involved in its development. I'm
working on
moving tests out of testsuite/gcc.misc-tests and putting them into
the more
general frameworks--a project listed on
http://gcc.gnu.org/projects/beginner.html. Is t
On Mon, 16 May 2005, DJ Delorie wrote:
so I assume setting hard ulimit to 128MB will just result in build
process crashing instead of slowdown and swapping,
We would limit physical ram, not virtual ram. If you do a "man
setrlimit", I'm talking about RLIMIT_RSS. The result would be slowing
down a
Hello,
I'm new to GCC and hoping to get involved in its development. I'm working on
moving tests out of testsuite/gcc.misc-tests and putting them into the more
general frameworks--a project listed on
http://gcc.gnu.org/projects/beginner.html. Is there someone who would
receive my updates and revie
> so I assume setting hard ulimit to 128MB will just result in build
> process crashing instead of slowdown and swapping,
We would limit physical ram, not virtual ram. If you do a "man
setrlimit", I'm talking about RLIMIT_RSS. The result would be slowing
down and swapping, not crashing.
On Monday 16 May 2005 20:26, Karel Gardas wrote:
> On Mon, 16 May 2005, Steven Bosscher wrote:
> > Just for the record, attached is gcctest's history of the overall
> > memory requirement at -O[0123] for combine.i, insn-attrtab.i, and
> > generate.ii (aka PR8361). Honza's bot has been sending thes
On Mon, 16 May 2005, DJ Delorie wrote:
We already do that for when checking is enabled, well the GC heuristics
are tuned such that it does not change which is why
--enable-checking=release is always faster than without it.
Right, but it doesn't call ulimit(), so other sources of memory
leakage wou
Georg Bauhaus wrote:
On Mac OX X 10.2, the results are slightly discomforting,
even though I do get a compiler with
--enable-languages=c,ada,f77,c++,objc.
gcc summary has
# of unexpected failures1080
First, I would suggest disabling Ada, in order to get further.
As for the GCC failures, 108
On Mon, 16 May 2005, Steven Bosscher wrote:
> Just for the record, attached is gcctest's history of the overall
> memory requirement at -O[0123] for combine.i, insn-attrtab.i, and
> generate.ii (aka PR8361). Honza's bot has been sending these
> reports since Septemper 2004, so that's where I star
On May 16, 2005, at 12:25 PM, Hugh Sasse wrote:
Is it pertinent to remind people of the wider spread of Free
Software, such as Bangladesh (Brave GNU World, issue 56) and Africa
(various issues of Brave GNU World Eg 53,43) where people have
considerably more difficulties keeping up with Moore's Law?
* Russ Allbery:
> Seriously, though, I think the above only tests things out to the degree
> that Autoconf would already be warning about no default specified for
> cross-compiling, yes? Wouldn't you have to at least cross-compile from a
> system with one endianness and int size to a system with
On Mon, 16 May 2005, Alexandre Oliva wrote:
On May 16, 2005, Robert Dewar <[EMAIL PROTECTED]> wrote:
After all, you can buy from Dell today a 2.4GHz machine with a 17"
monitor, DVD drive, and 256Meg memory for $299 complete. Sure, some
people cannot even afford that, but it is not clear that the gc
Mark Mitchell wrote:
GCC 3.4.4 RC2 is now available here:
Please download, build, and test.
On Mac OX X 10.2, the results are slightly discomforting,
even though I do get a compiler with
--enable-languages=c,ada,f77,c++,objc.
gcc summary has
# of unexpected failures1080
(Couldn't get any
> We already do that for when checking is enabled, well the GC heuristics
> are tuned such that it does not change which is why
> --enable-checking=release is always faster than without it.
Right, but it doesn't call ulimit(), so other sources of memory
leakage wouldn't be affected. I'm thinking
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On May 16, 2005, Russ Allbery <[EMAIL PROTECTED]> wrote:
>> And package maintainers will never take cross-compilation seriously
>> even if they really want to because they, for the most part, can't test
>> it.
> configure --build=i686-pc-linux-gnu \
>
On May 16, 2005, Russ Allbery <[EMAIL PROTECTED]> wrote:
> And package maintainers will never take cross-compilation seriously even
> if they really want to because they, for the most part, can't test it.
configure --build=i686-pc-linux-gnu \
--host=i686-somethingelse-linux-gnu
should be enough
On May 16, 2005, at 2:46 PM, DJ Delorie wrote:
No company is going to spend money on fixing this until we adjust
our (collective) attitude and take this seriously.
We could call ulimit() to force everyone to have less available RAM.
Connect it with one of the maintainer flags, like enable-checking
> No company is going to spend money on fixing this until we adjust
> our (collective) attitude and take this seriously.
We could call ulimit() to force everyone to have less available RAM.
Connect it with one of the maintainer flags, like enable-checking or
something, so it doesn't penalize dist
On May 16, 2005, Robert Dewar <[EMAIL PROTECTED]> wrote:
> After all, you can buy from Dell today a 2.4GHz machine with a 17"
> monitor, DVD drive, and 256Meg memory for $299 complete. Sure, some
> people cannot even afford that, but it is not clear that the gcc
> project can regard this as a majo
On Mon, 16 May 2005, Steven Bosscher wrote:
Just for the record, attached is gcctest's history of the overall
memory requirement at -O[0123] for combine.i, insn-attrtab.i, and
generate.ii (aka PR8361). Honza's bot has been sending these
reports since Septemper 2004, so that's where I started.
Is i
Peter Barada <[EMAIL PROTECTED]> writes:
> Until package maintainers take cross-compilation *seriously*, I have no
> choice but to do native compilation of a large hunk of the packages on
> eval boards that can literally takes *DAYS* to build.
And package maintainers will never take cross-compila
As David describes here:
http://gcc.gnu.org/ml/gcc/2005-05/msg00807.html
having options.c include config.h, system.h, coretypes.h and tm.h
was causing a bootstrap failure on AIX. The first of the two problems
was caused by options.c including before anything else.
The patch below changes th
William Beebe writes:
>
>... If you want what LXR provides (and yes, I looked it up) then get
Doxygen
>
Not only does Doxygen not meet my requirements, but also it doesn't make
much sense to me for each cross-reference tool to implement its own source
code parser and symbol database when the
Peter Barada wrote:
Until package maintainers take cross-compilation *seriously*,
Or cross-programming in general,
or until GNU programmers write software in a way such that if
the GNU platform changes, translation of configuration tools is
still possible by design.
I've just given up running the G
Janis Johnson wrote:
I hadn't noticed originally but on powerpc64-linux with 3.4.4 RC2 and
with the 3.4 branch, the results for libstdc++-v3 show only one run of
the tests for "unix", not two for "unix/-m32" and "unix/-m64", and the
results are actually for check-abi. The leftover temp files in th
Sigh. This appears to be a combination of issues related to the
new headers being included.
First, src/gcc/intl.h includes:
#ifndef HAVE_SETLOCALE
# define setlocale(category, locale) (locale)
#endif
and auto-host.h in the build directory includes:
/* Define to 1 if you have th
Richard Sandiford <[EMAIL PROTECTED]> writes:
> David Edelsohn <[EMAIL PROTECTED]> writes:
>> I notice that options.h no longer is included, but including that
>> file does not fix the problem.
>
> Argh! Sorry for the breakage. Can you send me the preprocessed
> options.c file?
BTW, that wa
David Edelsohn <[EMAIL PROTECTED]> writes:
> I notice that options.h no longer is included, but including that
> file does not fix the problem.
Argh! Sorry for the breakage. Can you send me the preprocessed
options.c file?
Richard
The awk patch appears to have broken bootstrap:
In file included from /usr/include/sys/localedef.h:44,
from /usr/gnu/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/3.2.3/include/
stdlib.h:447,
from /farm/dje/src/src/gcc/system.h:208,
from options.c:5:
>> Also there are so many interdependencies
>> between packages that we have to build a pile of libraries and support
>> stuff that is never used on the target just so we can get a package
>> that we do need to configure/build(like sed and perl).
>
>Please give me as much information as possible o
On Sat, May 14, 2005 at 12:16:54PM +1000, Paul C. Leopardi wrote:
> Hi all,
> I originally posted these messages to gcc-help, but had no reply, so I am
> re-posting links to them here.
>
> I think I have found a bug in g++ 4.0.0, but need help in reporting it.
> Maintainers like their bug repor
On Sun, May 15, 2005 at 08:59:48AM -0700, Mark Mitchell wrote:
> Joseph S. Myers wrote:
>
> >It also looks like this patch has been backported to 3.4 branch but not to
> >4.0 branch? Because 4.0 branch builds are still creating
> >libstdc++-abi.sum, while 3.4 branch builds no longer do, the ABI
I am pleased to announce that the GCC Steering Committee has
appointed Daniel Berlin as maintainer of
tree-chrec.*
tree-data-ref.*
tree-scalar-evolution.*
tree-ssa-sink.*
lambda*
and Sebastian Pop as maintainer of
tree-chrec.*
tree-data-ref.*
tree-scalar-evolution.*
Daniel and S
> Also there are so many interdependencies
between packages that we have to build a pile of libraries and support
stuff that is never used on the target just so we can get a package
that we do need to configure/build(like sed and perl).
Please give me as much information as possible on sed. AFAIK,
On Mon, 2005-05-16 at 17:03, Daniel Berlin wrote:
> > if only it were that simple[1]. However, even if the money does get
> > spent it's unlikely to help because there are too many developers that
> > just DON'T CARE about (or worse, seem to be openly hostile to) making
> > the compiler more effi
On Monday 16 May 2005 17:53, Richard Earnshaw wrote:
> On Mon, 2005-05-16 at 16:17, Steven Bosscher wrote:
> > On Monday 16 May 2005 16:53, Scott Robert Ladd wrote:
> > > The problem is, a bloated GCC has no consequences for the majority of
> > > GCC developers -- their employers have other (and va
On Mon, 2005-05-16 at 16:53 +0100, Richard Earnshaw wrote:
> On Mon, 2005-05-16 at 16:17, Steven Bosscher wrote:
> > On Monday 16 May 2005 16:53, Scott Robert Ladd wrote:
> > > The problem is, a bloated GCC has no consequences for the majority of
> > > GCC developers -- their employers have other (
On Mon, 2005-05-16 at 16:17, Steven Bosscher wrote:
> On Monday 16 May 2005 16:53, Scott Robert Ladd wrote:
> > The problem is, a bloated GCC has no consequences for the majority of
> > GCC developers -- their employers have other (and valid) concerns. It's
> > less a matter of laziness than it is
>But AFAICT even the developers who work on embedded targets focus
>on code quality and new features, instead of on the compile time
>and memory footprint issues that you would expect their group of
>users to complain about.
I think that most of us embedded developers are trying to keep up with
w
On Monday 16 May 2005 16:53, Scott Robert Ladd wrote:
> The problem is, a bloated GCC has no consequences for the majority of
> GCC developers -- their employers have other (and valid) concerns. It's
> less a matter of laziness than it is of not caring outside one's own
> backyard.
And to second y
>> Also don't forget us embedded people that are *desperately* trying to
>> do native compilations using an NFSroot with limited main memory and
>> don't have a disk in the hardware design to swap to.
>
>Why would you work in such a crippled environment?
Agh!
Believe me, I do as much work on
Etienne Lorrain wrote:
GCC 3.4.4 RC2 is now available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-3.4.4-20050512
There are just a few changes from RC1 to fix critical problems people
experienced with RC1.
Work for me, thanks.
Good; thanks for confirming.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL P
"zouq" <[EMAIL PROTECTED]> writes:
> yes, as you have suggested, i have already read the gcc-int about garbage
> collection, and i still can`t get the imformation i want.
> i want to know the following constructs:
> gt_ggc_cache_rtab, gt_ggc_deletable_rtab
> acording to what rules to genenrat
> "Robert" == Robert Dewar <[EMAIL PROTECTED]> writes:
Robert> Peter Barada wrote:
>>> We're not talking about 5% speedup; if the linker starts
>>> thrashing because of insufficient memory you pay far more than
>>> that. And certainly anyone with an older computer who is
>>> dissatified
Mark Mitchell wrote:
OK. Do you happen to have access to any other testsuites, beyond the
GCC testsuite? If so, it would be great to validate the behavior of
the compiler on the 4.0 branch with and without your patch to make
sure that we're not doing any harm.
I am sorry I don't have it.
--Kr
On Mon, 2005-05-16 at 13:44, Robert Dewar wrote:
> Richard Earnshaw wrote:
>
> > Robert, please stop trying to shoot the messenger. The problems are
> > real, and users often cannot 'fix' these problems themselves. Just like
> > they can't 'fix' the compiler bloat themselves.
>
> Right, but aga
On Mon, 2005-05-16 at 13:19, Robert Dewar wrote:
> >
> > Also don't forget us embedded people that are *desperately* trying to
> > do native compilations using an NFSroot with limited main memory and
> > don't have a disk in the hardware design to swap to.
>
> Why would you work in such a crippl
>We're not talking about 5% speedup; if the linker starts thrashing because
>of insufficient memory you pay far more than that. And certainly anyone
>with an older computer who is dissatified with its performance, but
>doesn't have a lot of money, should look into getting more memory before
>anyt
> GCC 3.4.4 RC2 is now available here:
> ftp://gcc.gnu.org/pub/gcc/prerelease-3.4.4-20050512
> There are just a few changes from RC1 to fix critical problems people
experienced with RC1.
Work for me, thanks.
Etienne.
[Disclaimer: the transition to GC happened around the time I started
paying attention to GCC, so my knowledge of the pre-GC situation
may be inaccurate.]
On 16 May 2005, zouq suggested tentatively:
> and now i am thinking that why use garbage collection in gcc,
> is it because of its high effici
On Sun, May 15, 2005 at 08:16:04PM -0700, Mike Stump wrote:
> On Sunday, May 15, 2005, at 04:11 PM, Luke Kenneth Casson Leighton
> wrote:
> > *click* - so you you... ooo :)
> >
> > holy cow.
> >
> > you looked at valarray,
>
> No, not really, I'm not a library guy. I know of almost no
On Sun, May 15, 2005 at 02:43:57PM -0700, Mike Stump wrote:
> On Sunday, May 15, 2005, at 01:01 PM, Luke Kenneth Casson Leighton
> wrote:
> >unfortunately, integration of aspex's proprietary tool-chain - written
> >in modula-2 - is extremely unlikely to ever be integrated into gcc.
>
> Right. B
i am sorry for that.
> "zouq" <[EMAIL PROTECTED]> writes:
>
> Please don't start a new thread by replying to a message on an
> existing thread. Just send a new message, instead. Otherwise your
> message goes in the wrong place for people who use threaded e-mail
> readers.
yes, as you have sugge
On Sun, May 15, 2005 at 02:43:57PM -0700, Mike Stump wrote:
> See google("OpenMP") for what I mean by OpenMP.
ah _ha_ *grin*.
this is _very_ significant for the parallel processor project
i have been asked about.
The default expansion of builtin_longjmp will use nonlocal_goto if it is
defined by the backend.
Looking at the builtin_longjmp expansion code in builtins.c, I find that
it does not match the documentation for 'nonlocal_goto' in GCC
internals: "the first argument is to be loaded into the frame poi
Andrew Pinski writes:
>
> On May 15, 2005, at 10:33 AM, Andrew Pinski wrote:
> > The multiple exit comes bounds checking (which VRP does not remove
> > still
> > because we don't pull out a load of the length).
> >
> > If we add -fno-bounds-checks, we get:
> > Test.java:7: note: not vecto
Or probably using sourcenav software from sourcenav.sourceforge.net
Daniel Berlin wrote:
On Fri, 2005-05-13 at 14:49 -0500, Paul Albrecht wrote:
Eric writes:
-Wl,-Map=mapfile.map,--cref
I'm not looking for a cross-reference from a symbol to its memory location
in linked file, rather a cross-refere
Ian Lance Taylor writes:
[...]
| I think the more conservative approach would be to simply add strerror
| to AC_CHECK_DECLS, include in xstrerror.c (protected by
| HAVE_STRING_H), and protect the strerror declaration with
| #if !HAVE_DECL_STRERROR
Thanks, that indeed makes sense. Patch pe
93 matches
Mail list logo
