[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] gcc 4.2.2 compile error



Hi,

On Friday 04 January 2008, MiKRO wrote:
> To summarize it, I've tried that stack command, it didn't help. Btw
> strange thing -- is there any limit for the stack?

Where?  On Linux stack grows on demand.  For threads it doesn't grow,
by default for them it's 2MB (and due to virtual memory, it's of course not
physically in use until written).


> I set 4 MB for that 
> xgcc and I've got memory violation as soon as some compilation
> involved (configure script "checking if gcc works"), same for 512K
> (and this even occured in gcc 2.95!). So the safest boundary seems to
> be 256K?.
>
> When I'll be at home, I'll try to disable that -O2 with regex.c,
> hopefully it helps.

Besides -O0, try also -O1.


> Maybe would be good to think about porting the 
> latest 3.x gcc instead of 4.x. I remember there were many complaints
> in linux world gcc 4.x is even slower and less effective to produce
> code than 3.x...

Gcc 4.x may compile slower when optimizations are enabled, but it:
- Produces in general faster code[1]
- Gives more/better warnings
- Has better debugging support for optimized binaries
  (I think locationlists were added in Gcc 4.x and that they let debugger
   to know e.g. when local variable is in register instead of stack)
- Supports C++ (standard) better
- Is already in all Linux distros

Because of the last two, you might not be able to build upstream C++ code
without problems for long.


	- Eero

[1] They rewrote how gcc parses/optimizes the code to be able to
     improve it, so I'm not surprised it's at first slower in doing
     compilations.