On Sat, Apr 02, 2005 at 01:10:42AM -0500, Andrew Pinski wrote:
> >Memory bloat is a problem for embedded systems. Attitudes about just
> >"buy
> >another gigabyte" is why i use C for everything for speed, portability,
> >compactness, and conciseness of design.
>
> But you are not compiling on the
On Apr 1, 2005, at 10:11 PM, Russell Shaw wrote:
Stefan Strasser wrote:
Mike Stump schrieb:
On Friday, April 1, 2005, at 08:48 AM, Stefan Strasser wrote:
if gcc uses more memory than physically available it spends a
_very_ long time swapping
Swapping, what's that? Here's $20, go buy a gigabyte.
E. Weddington wrote:
What do you get if you use the C99 construct of declaring the variable
in the for statement? Like so:
for(volatile int i = 0; i < COUNT; ++i);
I get the same code afaics.
In fact, I haven't been able to produce an empty loop that
isn't translated into an actual loop, volatile
Zagorodnev, Grigory wrote:
How it is possible that recent cgraph changes affect ia64 compiler
behavior? I see reclaimed callgraph differs on ia64 but not on ia32;
therefore ia32/x86_64 compiler remains stable.
This is presumably the same problem that is now PR 20717.
--
Jim Wilson, GNU Tools Suppor
Vinayak Ghate wrote:
Do we have GNU toolchain for blackfin processor?? Can anybody help me out in
this regard??
I was mistaken. The Blackfin port has already been submitted, but not
yet added to our source code repository. There is a chance that it may
end up in the upcoming release, gcc-4.0.
-
> I do have swapping on a 1 GB machine with 2 CPUs(-> 2 GCCs)
If you can demonstrate that say GCC-4.0 uses much more memory than 3.4
or 3.3 to compile some code, then file a PR with preprocessed source
and someone will eventually look at it.
Don't compare current GCC to 3.2 since the collection
Stefan Strasser wrote:
Mike Stump schrieb:
On Friday, April 1, 2005, at 08:48 AM, Stefan Strasser wrote:
if gcc uses more memory than physically available it spends a _very_
long time swapping
Swapping, what's that? Here's $20, go buy a gigabyte.
expect memory to become a problem again with the
> Joe Buck wrote:
>>Georg Bauhaus <[EMAIL PROTECTED]> writes:
>> | A busy-loop function is used to effect a delay, not too precise,
>> | but portably. Like
>> |
>> | #define COUNT 1000
>> |
>> | void f() {
>> |/*volatile*/ /*register*/ int i;
>> |
>> |for (i = 0; i < COUNT; ++i)
>> |
Gabriel Dos Reis wrote:
| void f() {
|/*volatile*/ /*register*/ int i;
|
|for (i = 0; i < COUNT; ++i)
| ;
This must be an FAQ. The above is no way of (no matter how popular
the urban legend makes it) implementing delay.
As a normative statement, a busy loop might not be the
w
Mike Stump schrieb:
On Friday, April 1, 2005, at 08:48 AM, Stefan Strasser wrote:
if gcc uses more memory than physically available it spends a _very_
long time swapping
Swapping, what's that? Here's $20, go buy a gigabyte.
expect memory to become a problem again with the advent of multicore a
On 2005-04-01, at 23:36, Mark Mitchell wrote:
Richard Guenther wrote:
But the question is, do we want all this sort of #pragmas? It would
surely better to improve the compilers decisions on applying certain
optimizations. As usual, in most of the cases the compiler will be
smarter than the user t
On 2005-04-01, at 23:17, Richard Guenther wrote:
On Apr 1, 2005 11:07 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Dale Johannesen wrote:
Agree. (And documentation will be written.)
Yay. It sounds like we're definitely on the same page. I think that
as
long as we keep the semantics clear, this
On Fri, 2005-01-04 at 00:10 -0500, Grzegorz B. Prokopski wrote:
> /* Leave the rest as it was. */
> FOR_EACH_BB (bb)
> if ((bb->next_bb != EXIT_BLOCK_PTR) && (!bb->rbi->next))
> bb->rbi->next = bb->next_bb;
This code worked well in some other place from which I copied it,
but unfortuna
Snapshot gcc-3.4-20050401 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050401/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050401
You'll
Joe Buck wrote:
Georg Bauhaus <[EMAIL PROTECTED]> writes:
| A busy-loop function is used to effect a delay, not too precise,
| but portably. Like
|
| #define COUNT 1000
|
| void f() {
|/*volatile*/ /*register*/ int i;
|
|for (i = 0; i < COUNT; ++i)
| ;
Unfortunately, wh
> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:
Joe> Georg Bauhaus <[EMAIL PROTECTED]> writes:
>> | A busy-loop function is used to effect a delay, not too precise,
>> | but portably. Like
>> |
>> | #define COUNT 1000
>> |
>> | void f() { | /*volatile*/ /*register*/ int i;
>> |
>>
Georg Bauhaus <[EMAIL PROTECTED]> writes:
> | A busy-loop function is used to effect a delay, not too precise,
> | but portably. Like
> |
> | #define COUNT 1000
> |
> | void f() {
> |/*volatile*/ /*register*/ int i;
> |
> |for (i = 0; i < COUNT; ++i)
> | ;
On Sat, Apr 02, 200
Georg Bauhaus <[EMAIL PROTECTED]> writes:
| Joe Buck wrote:
|
| > Are you using "volatile" correctly? There are situations where "volatile"
| > alone does not suffice and you need more locking, but the Linux and BSD
| > kernel folks manage to optimize their device driver code.
|
| We have just
Georg Bauhaus wrote:
We have just been discussing a similar topic in a de.* newsgroup.
A busy-loop function is used to effect a delay, not too precise,
but portably. Like
#define COUNT 1000
void f() {
/*volatile*/ /*register*/ int i;
for (i = 0; i < COUNT; ++i)
;
}
If volatile is used
Joe Buck wrote:
Are you using "volatile" correctly? There are situations where "volatile"
alone does not suffice and you need more locking, but the Linux and BSD
kernel folks manage to optimize their device driver code.
We have just been discussing a similar topic in a de.* newsgroup.
A busy-loop
Richard Guenther wrote:
On Apr 1, 2005 11:23 PM, E. Weddington <[EMAIL PROTECTED]> wrote:
Is your objection to a grain finer than the function level? Or is it to
the whole concept of having pragmas change the optimization level per
function?
It would be a general objection - I thought we're
> On Wednesday 30 March 2005 05:27, Gerold Jury wrote:
> >
> > >> On Tue, Mar 29, 2005 at 05:37:06PM +0300, Denis Vlasenko wrote:
> > >> > /*
> > >> > * This looks horribly ugly, but the compiler can optimize it totally,
> > >> > * as the count is constant.
> > >> > */
> > >> > static inline vo
Richard Guenther wrote:
But the question is, do we want all this sort of #pragmas? It would
surely better to improve the compilers decisions on applying certain
optimizations. As usual, in most of the cases the compiler will be
smarter than the user trying to override it (and hereby maybe only
wo
On Apr 1, 2005 11:23 PM, E. Weddington <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
> >But the question is, do we want all this sort of #pragmas? It would
> >surely better to improve the compilers decisions on applying certain
> >optimizations. As usual, in most of the cases the compil
Richard Guenther wrote:
But the question is, do we want all this sort of #pragmas? It would
surely better to improve the compilers decisions on applying certain
optimizations. As usual, in most of the cases the compiler will be
smarter than the user trying to override it (and hereby maybe only
wo
On Apr 1, 2005 11:07 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Dale Johannesen wrote:
> > Agree. (And documentation will be written.)
>
> Yay. It sounds like we're definitely on the same page. I think that as
> long as we keep the semantics clear, this will be useful functionality.
>
> >>
Dale Johannesen wrote:
Agree. (And documentation will be written.)
Yay. It sounds like we're definitely on the same page. I think that as
long as we keep the semantics clear, this will be useful functionality.
That's what I assumed. Anything finer than that is insane. :-)
Actually there are
On Apr 1, 2005, at 11:24 AM, Mark Mitchell wrote:
Dale Johannesen wrote:
So I guess question 1 is, Mark, do you feel negatively enough about
this
feature to block its acceptance in mainline?
I'm not sure that I *could* block it, but, no, I don't feel that
negatively.
Well, in theory nobody can bl
Diego Novillo <[EMAIL PROTECTED]> writes:
| On Fri, Apr 01, 2005 at 11:24:06AM -0800, Mark Mitchell wrote:
| > Dale Johannesen wrote:
| >
| > >So I guess question 1 is, Mark, do you feel negatively enough about this
| > >feature to block its acceptance in mainline?
| >
| > I'm not sure that I *c
Richard Guenther wrote:
On Apr 1, 2005 9:36 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Diego Novillo wrote:
On Fri, Apr 01, 2005 at 11:24:06AM -0800, Mark Mitchell wrote:
Dale Johannesen wrote:
So I guess question 1 is, Mark, do you feel negatively enough about this
feature to block its accepta
On Apr 1, 2005 9:36 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Diego Novillo wrote:
> > On Fri, Apr 01, 2005 at 11:24:06AM -0800, Mark Mitchell wrote:
> >
> >>Dale Johannesen wrote:
> >>
> >>
> >>>So I guess question 1 is, Mark, do you feel negatively enough about this
> >>>feature to block its
James E Wilson wrote:
The testcase is not portable, as I pointed out in the PR. Trying this
on an x86_64-linux system, I get 27 "excess errors" failures. All of
them are
error: cast from 'int*' to 'int' loses precision
Using long works better than int, but is still not fool proof, as there
ar
On Fri, 2005-04-01 at 00:38, Nathan Sidwell wrote:
> Here it is, ok?
The patch is OK. The ChangeLog entry should refer to INTEGER_CST
instead of INT_CST.
You are missing a ChangeLog entry for the testcase.
The testcase is not portable, as I pointed out in the PR. Trying this
on an x86_64-linux
On Friday, April 1, 2005, at 10:16 AM, Kelly Murphy wrote:
There's the case where we'd like to have the files of a subsystem to
be optimized but we want a handful of functions that directly access
hardware be unoptimized. (We found that the optimization did some
write reordering that the hardware
On Friday, April 1, 2005, at 08:48 AM, Stefan Strasser wrote:
if gcc uses more memory than physically available it spends a _very_
long time swapping
Swapping, what's that? Here's $20, go buy a gigabyte.
Now, having said that, we do believe that it would make for interesting
research to try le
On Thursday, March 31, 2005, at 10:38 PM, GOEBAX wrote:
my project is that Connect to Gcc's front-end and My back-end
We generally don't support this concept. We'd rather you enhance and
extend gcc's back end. Because of this, this is beyond the scope of
this list.
On topic for this list, w
Diego Novillo wrote:
On Fri, Apr 01, 2005 at 11:24:06AM -0800, Mark Mitchell wrote:
Dale Johannesen wrote:
So I guess question 1 is, Mark, do you feel negatively enough about this
feature to block its acceptance in mainline?
I'm not sure that I *could* block it, but, no, I don't feel that negative
On Fri, Apr 01, 2005 at 11:24:06AM -0800, Mark Mitchell wrote:
> Dale Johannesen wrote:
>
> >So I guess question 1 is, Mark, do you feel negatively enough about this
> >feature to block its acceptance in mainline?
>
> I'm not sure that I *could* block it, but, no, I don't feel that negatively.
>
Dale Johannesen wrote:
So I guess question 1 is, Mark, do you feel negatively enough about this
feature to block its acceptance in mainline?
I'm not sure that I *could* block it, but, no, I don't feel that negatively.
I think that a #pragma (or attribute) that affects only optimization
options is
a) what makes your backend different from gcc's backend so it is worth
porting it?
하태준 schrieb:
> sorry, my english is not good,
>
> Umm...
>
> my project is that Connect to Gcc's front-end and My back-end
>
> first gcc parse sorce code
there is an IR created while parsing which is simply ca
On Fri, Apr 01, 2005 at 10:16:44AM -0800, Kelly Murphy wrote:
> I know we'd find something like that really handy for some of the
> embedded stuff we're doing.
>
> There's the case where we'd like to have the files of a subsystem to
> be optimized but we want a handful of functions that directly a
I know we'd find something like that really handy for some of the
embedded stuff we're doing.
There's the case where we'd like to have the files of a subsystem to
be optimized but we want a handful of functions that directly access
hardware be unoptimized. (We found that the optimization did some
On Fri, 2005-04-01 at 18:09, aram bharathi wrote:
> hi
>
> i have downloaded the gcc4.0 from the gcc web site
> and i compiled the above program by the following option
>
> main()
> {
> float a=88.88,b=99.99,c=0;
> c=a*b;
> printf("%f",c);
> }
>
> arm-elf-gcc -mfpu=vfp -S new.c
>
> but it produ
On Fri, Apr 01, 2005 at 06:48:56PM +0200, Stefan Strasser wrote:
> Andrew Haley schrieb:
> >Sam Lauber writes:
> > > I know that Bohem's GC is used in the Java runtime for GCC.
> > > However, the compiler proper itself can _really_ cramp people's
> > > avalible RAM (for those who don't belive me an
hi
i have downloaded the gcc4.0 from the gcc web site
and i compiled the above program by the following option
main()
{
float a=88.88,b=99.99,c=0;
c=a*b;
printf("%f",c);
}
arm-elf-gcc -mfpu=vfp -S new.c
but it produces the new.s file without any special kind of (vfp
instructions) instructions.
Andrew Haley schrieb:
Sam Lauber writes:
> I know that Bohem's GC is used in the Java runtime for GCC.
> However, the compiler proper itself can _really_ cramp people's
> avalible RAM (for those who don't belive me and have Windows w/
> DJGPP, change all the memory controls from `auto' to the h
Giovanni Bajo wrote:
James E Wilson <[EMAIL PROTECTED]> wrote:
IA64 bootstrap failed at abi_check stage reporting undefined
references from libstdc++ (see log at the bottom).
This seems indirectly related to bug 20964. Mark's proposed fix to
stop building abi-check at bootstrap time means the IA-
On 04/01/2005 08:21 AM, Larry Evans wrote:
On 04/01/2005 07:35 AM, Andrew Haley wrote:
[snip]
To be fair to the Boehm gc, though: it isn't inherently a conservative
collector, but will also do precise gc.
Wouldn't this require a GC_descr as defined here:
http://www.hpl.hp.com/personal/Hans_Boehm
Dale Johannesen <[EMAIL PROTECTED]> writes:
> I've currently got the job of implementing pragma(s) to change
> optimization level in the middle of a file. This has come up a few
> times before,
Would it be possible to make it a function attribute? I would
really like to have
void __attribute__(
Hi,
On Thu, 31 Mar 2005, zouq wrote:
> in gcc3.4.1,i found rest_of_new_handle_regalloc
> why in gcc4.0, it has been removed?
It was removed from gcc 4 because it bitrotted and broke on all kinds of
code. If you want to see a more recent and more working version look at
the new-regalloc-branch
On 04/01/2005 07:35 AM, Andrew Haley wrote:
[snip]
To be fair to the Boehm gc, though: it isn't inherently a conservative
collector, but will also do precise gc.
Wouldn't this require a GC_descr as defined here:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc_typedh.txt
for each data st
Perhaps then a scheme in which the compiler
1) compresses all tree structures (this would be a good project)
2) after each pass, all internal structures are freed unless doing so would
create a dead pointer (maybe an -Om option like -Os but saves compilation
memory?)
3) dosen't use memory in
Daniel Berlin writes:
> On Fri, 2005-04-01 at 12:43 +0100, Andrew Haley wrote:
> > Sam Lauber writes:
> > > I know that Bohem's GC is used in the Java runtime for GCC.
> > > However, the compiler proper itself can _really_ cramp people's
> > > avalible RAM (for those who don't belive me and
On Fri, 2005-04-01 at 12:43 +0100, Andrew Haley wrote:
> Sam Lauber writes:
> > I know that Bohem's GC is used in the Java runtime for GCC.
> > However, the compiler proper itself can _really_ cramp people's
> > avalible RAM (for those who don't belive me and have Windows w/
> > DJGPP, change a
Sam Lauber writes:
> I know that Bohem's GC is used in the Java runtime for GCC.
> However, the compiler proper itself can _really_ cramp people's
> avalible RAM (for those who don't belive me and have Windows w/
> DJGPP, change all the memory controls from `auto' to the highest
> value and ju
I know that Bohem's GC is used in the Java runtime for GCC. However, the
compiler proper itself can _really_ cramp people's avalible RAM (for those who
don't belive me and have Windows w/ DJGPP, change all the memory controls
from `auto' to the highest value and just try to compile libiberty/re
James E Wilson wrote:
Nathan Sidwell wrote:
Being conservative I'd go for my patch on 4.0 and yours (if verified) on
mainline.
I'm fine with that. Have you actually written a patch yet? I don't see
one in the bug report or in gcc-patches.
My mistake. I'd forgotten the post-to-list part :)
Here
57 matches
Mail list logo
