Re: Feature request - a macro defined for GCC

gt; alternatively, __GNUC__ should be defined by the GCC compiler proper, > not CPP. And do what with the preprocessor symbol? If the symbol is defined by the compiler *after* preprocessing occurs(as in the compiler and not the preprocessor) , then it can't be used to selectively preprocess code... -- Peter Barada [EMAIL PROTECTED]

Re: bug management: WAITING bugs that have timed out

someone has gone to at least the effort of reporting only to get ignored if no further information is forthcoming - perhaps the description of the issue is enough for some energetic intern to come along and create a testcase, who knows? -- Peter Barada [EMAIL PROTECTED]

Re: Mis-handled ColdFire submission?

was reported half a > year ago and at least three people worked on fixing. So once your patches > are ready, go ahead and submit them. 28181 has been popping up over the last several years in various forms (5373, 13803, 18421, 23695, etc). -- Peter Barada [EMAIL PROTECTED]

Re: warning: '' may be used uninitialized in this function

he assignment to best.d never happens in the loop which leaves trash in best.d since best is allocated off the stack and holds trash until initialized. Hence the warning for reading at a possibly unitialized variable. Initialize best.d where you initialize best.score to quiet the warning. -- Pet

CVS access to the uberbaum tree

Does the uberbaum tree exist on savanna, or is it only on sources.redhat.com? If so, what is the procedure for accessing it? Thanks in advance... -- Peter Barada [EMAIL PROTECTED]

Re: Minimum/maximum operators are deprecated?

stcase. Hopefully some kind volunteer will spend their valuable time to fix it. But if you don't report it, tough, don't complain about it... -- Peter Barada [EMAIL PROTECTED]

problemns confgire/build gcc/libstdc++ for ColdFire v4e

needs options to select ColdFire specific behavior. Thanks in advance! -- Peter Barada [EMAIL PROTECTED]

Re: GCC 4.1: Buildable on GHz machines only?

omips: 2287.20, cpu MHz: 1145.142). > >Comparisions like yours are worse than meaningless. I wouldn't call it meaningless. I don't have other benchmark numbers for the chip, and it was menat to show that it isn't a blazingly fast processor (as compared to desktop machines). -- Peter Barada [EMAIL PROTECTED]

Re: GCC 4.1: Buildable on GHz machines only?

s, causing "larger memory requirements" of flash, not DRAM. -- Peter Barada [EMAIL PROTECTED]

Re: GCC 4.1: Buildable on GHz machines only?

ince it can't cache any source. >I build GCC while at work (i.e., while away from the notebook at home :-) > >Try it ... it works, Huh? I can cross-compile GCC, its all the packages that require native configuration/building -- Peter Barada [EMAIL PROTECTED]

Re: GCC 4.1: Buildable on GHz machines only?

t;slower. Its currently NFS all the way. :) >How much RAM? 128Mb. I do have some experimental kernel hacks in to allow swapping via NFS, so you can understand why it can take *days* to build stuff. -- Peter Barada [EMAIL PROTECTED]

Re: GCC 4.1: Buildable on GHz machines only?

>> Yes, but Ralf was complaining about embedded cross-compiling development >> for RTEMS. I have not tried to reply to Peter Barada who complains about >> GCC inablity to be run on embedded targets directly. > >Logically Peter's situation is the same as the Net

Re: GCC 4.1: Buildable on GHz machines only?

o it, but please understand that Linux systems are built using GCC, whether its for a workstation or an embedeed Linux device, and as such *should* consider the problems that both encounter and not just favor the workstation end. -- Peter Barada [EMAIL PROTECTED]

Re: GCC 4.1: Buildable on GHz machines only?

ity of reference since poor locality will cause thrashing if the RSS is set low enough. Of course if the RSS is set too low than *any* pattern of page access will cause thrashing. -- Peter Barada [EMAIL PROTECTED]

Re: GCC 4.1: Buildable on GHz machines only?

natively built that compounds the problem. -- Peter Barada [EMAIL PROTECTED]

Re: GCC 4.1: Buildable on GHz machines only?

oping that the build doesn't blow its brains out due to a "minor" increase in memory consumption. -- Peter Barada [EMAIL PROTECTED]

Re: GCC 4.1: Buildable on GHz machines only?

ting the "get faster hardware" as the patent cure-all to execution speed problems, but in my case, there is no other hardware I can use. -- Peter Barada [EMAIL PROTECTED]

Re: GCC 4.1: Buildable on GHz machines only?

native compilations using an NFSroot with limited main memory and don't have a disk in the hardware design to swap to. -- Peter Barada [EMAIL PROTECTED]

Re: GCC 4.1: Buildable on GHz machines only?

ce. > >How about a successful crossbuild plus >passing some regression test suite, >e.g. gcc's, glibc's, and/or ltp's? >Any one of them would provide a nice reality check. I'm open to running them if there's a *really* clear how-to to do it that takes into account remote hardware. -- Peter Barada [EMAIL PROTECTED]

Re: GCC 4.1: Buildable on GHz machines only?

packages out there that can't cross-configure/compile (openssh, perl as examples off the top of my head) without a *lot* of work. Its just that it takes a lot of time and work to cross-build a non-x86 linux environment to verify any changes in the toolchain. And comments like "get

Re: GCC 4.1: Buildable on GHz machines only?

ll obvioulsy make it take longer. >A 2.4 Ghz P4 isn't what I would consider an obsolete machine and it took >90 minutes for "make" -- not a full bootstrap. Even on a 3.0Ghz P4 with HT, 1Gb DDR and a hardware RAID with SATA drives it takes about 30 minutes so there's a

Re: GCC 4.1: Buildable on GHz machines only?

-lgcc-eh), so >> even really fast machines(2.4Ghz P4) take an hour to do a cross-build >> from scratch. > >This could be made substantially easier if libgcc moved to the top >level. You wanna help out with that? Uh, ok. What do you mean by "move to the top level"? -- Peter Barada [EMAIL PROTECTED]

Re: GCC 4.1: Buildable on GHz machines only?

ve to repeat a few steps (build gcc twice, build glibc twice) because glibc and gcc assume that a near-complete environment is available(such as gcc needing headers, and glibc needing -lgcc-eh), so even really fast machines(2.4Ghz P4) take an hour to do a cross-build from scratch. -- Peter Barada [EMAIL PROTECTED]

Re: GCC 4.1: Buildable on GHz machines only?

o limited memory and no usable mass-storage device on the hardware I have available, so hopefully a successful crossbuild will suffice. -- Peter Barada [EMAIL PROTECTED]

Re: [m68k]: More trouble with byte moves into Address registers

had punched paper and a duplex laser printer. Here at home I have neither. >If you mean a printed and bound book published by somebody else, I >don't think there is a newer one available. I like the printed book since I can dog-ear pages and scribble notes in it. As it is, my 2.95 version's binding is nearly fallying apart :) -- Peter Barada [EMAIL PROTECTED]

Re: [m68k]: More trouble with byte moves into Address registers

ing and Porting GNU CC" manual for rev 2.95, and am looking around for a newer one and can't find it anywhere. Does anyone know if a newer printed manual is available(and if so, where I can find it)? Eventually I'll have to try my changes on gcc-4.0 to see what that does. -- Peter Barada [EMAIL PROTECTED]

Re: [m68k]: More trouble with byte moves into Address registers

the ?a change. What in the .lreg dump am I looking for that will tellm "where regclass things that the register should go"? Is it: ;; Register 1421 in 0. -- Peter Barada [EMAIL PROTECTED]

Re: [m68k]: More trouble with byte moves into Address registers

1421? I'll dig into it with gdb, but there's so much code in reload that a clue or two would *really* help :) I'll undo the change to PREFERRED_RELOAD_CLASS, and then change the '?a' to '*a' in addsi3_5200 to see if that helps reload to not pick and ADDR_REG for the value. If it still fails, I'll regenerate all the information as I did in the 2nd email to you. Thanks! -- Peter Barada [EMAIL PROTECTED]

Re: [m68k]: More trouble with byte moves into Address registers

68881|TARGET_CFV4E) && (CLASS == FP_REGS || CLASS == DATA_OR_FP_REGS) \ ? FP_REGS : NO_REGS) \ : (TARGET_PCREL \ && (GET_CODE (X) == SYMBOL_REF || GET_CODE (X) == CONST \ || GET_CODE (X) == LABEL_REF))\ ? ADDR_REGS \ : (CLASS)) -- Peter Barada [EMAIL PROTECTED]

Re: [m68k]: More trouble with byte moves into Address registers

if ((GET_MODE_CLASS (mode) == MODE_FLOAT || GET_MODE_CLASS (mode) == MODE_COMPLEX_FLOAT) && (((GET_MODE_UNIT_SIZE (mode) <= 12) && TARGET_68881) || ((GET_MODE_UNIT_SIZE (mode) <= 8) && TARGET_CFV4E))) return 1; } return 0; } Any further insight or suggestions are *really* appreciated! -- Peter Barada [EMAIL PROTECTED]

Re: [m68k]: More trouble with byte moves into Address registers

r complex float of long double or smaller */ if ((GET_MODE_CLASS (mode) == MODE_FLOAT || GET_MODE_CLASS (mode) == MODE_COMPLEX_FLOAT) && (((GET_MODE_UNIT_SIZE (mode) <= 12) && TARGET_68881) || ((GET_MODE_UNIT_SIZE (mode) <= 8) && TARGET_CFV4E))) return 1; } return 0; } Any further insight or suggestions are *really* appreciated! -- Peter Barada [EMAIL PROTECTED]

[m68k]: More trouble with byte moves into Address registers

407 has more instructions and less restrictive addressing modes on some instructions than the 5200 has. Can anyone take a stab at describing *how* to debug this? Is this just a case where there are so many live registers that reload has just backed itself into a corner? Any suggestions are appreciated! -- Peter Barada [EMAIL PROTECTED]

Re: Sorry for the noise: Bootstrap fails on HEAD 4.1 for AVR

ot configure will use 'as' in your path and find your host assembler instead. -- Peter Barada [EMAIL PROTECTED]

Re: [m68k]: Trouble trying to figure out LEGITIMIZE_RELOAD_ADDRESS

>Peter Barada wrote: >> I'd like to make the reload look like: >> (set (reg:SI y) (plus:SI (reg_SI 16) (const_int 32832))) >> (set (reg:DF x) (mem:DF (reg:SI y))) > >Reload already knows how to make this transformation, so it should not >be necessary to resort

[m68k]: Trouble trying to figure out LEGITIMIZE_RELOAD_ADDRESS

I'm in the midst of fixing the m68k prologue/epilogue code for ColdFire and its FPU, and stumbled across a problem. The following code when compiled with -O2 -mcfv4e -fomit-frame-pointer (with the v4e cod in): double func(int i1, int i2, int i3, int i4, double a, double b) { int stuff[8192];

Re: matching constraints in asm operands question

*v, int i) { __asm__ __volatile__("addl %1,%0" : "+m" (*v) : "d" (i)); } Then the compiler complains with: /asm/atomic.h:33: warning: read-write constraint does not allow a register So is the warning wrong? -- Peter Barada [EMAIL PROTECTED]

Re: matching constraints in asm operands question

atile__("addl %2,%0" : "=m" (*v) : "m" (*v), "d" (i)); } Is that correct? And if so, then isn't the documentation wrong? -- Peter Barada [EMAIL PROTECTED]

matching constraints in asm operands question

'm really concerned about the manuals warning of the input and output operads being in seperate places. Which form is correct? -- Peter Barada [EMAIL PROTECTED]