Re: Use Bohem's GC for compiler proper in 4.1?
Kaveh R. Ghazi schrieb: > 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. I haven't thought about a regression, I was only using 3.4, but look at this: mem peakuser sys gcc 3.4 -S -O0 476 MB1m39s 2s gcc 4.0 -S -O0 655 MB2m23s 3s icc -S -O0 264 MB1m24s 15s the file makes quite heavy use of virtual inheritance so there are a lot of virtual tables involved. are there any known performance bugs in this area or should I file a PR? any suggestions on how to simplify the testcase? (preprocessed is ~60k lines) -- Stefan Strasser
Re: Use Bohem's GC for compiler proper in 4.1?
Joe Buck <[EMAIL PROTECTED]> writes: | 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 embedded machine :). | > | > That is the point of Mike Stump, nothing else. | | We should still care about memory consumption, because older machines | sometimes have limited expandability (there are laptops added today that | cannot take more than 512Mb, and that's a current machine). | | Folks in third-world countries with cast-off machines should be able to | use GCC. a note that this issue is just about some starved people in some obscure countries with obscure machines that escaped from Middle Age. While I know a bit of third-wrld, I have also been working in some western European countries for a sufficiant time to say that, well, far many real machines used there for work in univeristies and research labs still don't go beyond 512Mb memory; and they really would love to use GCC and GCC should be usable on those machines. -- Gaby
Re: memcpy(a,b,CONST) is not inlined by gcc 3.4.1 in Linux kernel
> > childregs = ((struct pt_regs *) (THREAD_SIZE + (unsigned long)
> > p->thread_info)) - 1;
> > *childregs = *regs;
> > ^^^
> > childregs->eax = 0;
> > childregs->esp = esp;
> >
> > # make arch/i386/kernel/process.s
> >
> > copy_thread:
> > pushl %ebp
> > movl%esp, %ebp
> > pushl %edi
> > pushl %esi
> > pushl %ebx
> > subl$20, %esp
> > movl24(%ebp), %eax
> > movl4(%eax), %esi
> > pushl $60
> > leal8132(%esi), %ebx
> > pushl 28(%ebp)
> > pushl %ebx
> > callmemcpy <=
> > movl$0, 24(%ebx)
> >
> > Jakub, is there a way to instruct gcc to inine this copy, or better yet,
> > to use user-supplied inline version of memcpy?
>
> You can't inline struct copy as it is not function call at first place.
> You can experiment with -minline-all-stringops where GCC will use it's
> own memcpy implementation for this.
No luck. Actually, memcpy calls are produced with -Os. Adding
-minline-all-stringops changes nothing.
-O2 compile does inline copying, however, suboptimally.
Pushing/popping esi/edi on the stack is not needed.
Also "mov $1,ecx; rep; movsl" is rather silly.
Here what did I test:
t.c:
#define STRUCT1(n) struct s##n { char c[n]; } v##n, w##n; void f##n(void) {
v##n = w##n; }
#define STRUCT(n) STRUCT1(n)
STRUCT(1)
STRUCT(2)
STRUCT(3)
STRUCT(4)
STRUCT(5)
STRUCT(6)
STRUCT(7)
STRUCT(8)
STRUCT(9)
STRUCT(10)
STRUCT(11)
STRUCT(12)
STRUCT(13)
STRUCT(14)
STRUCT(15)
STRUCT(16)
STRUCT(17)
STRUCT(18)
STRUCT(19)
STRUCT(20)
mk.sh:
#!/bin/sh
# yeah yeah. push/pop + 1 repetition 'rep movsl'
# 88: 55 push %ebp
# 89: 89 e5 mov%esp,%ebp
# 8b: 57 push %edi
# 8c: 56 push %esi
# 8d: fc cld
# 8e: bf 00 00 00 00 mov$0x0,%edi
#8f: R_386_32v7
# 93: be 00 00 00 00 mov$0x0,%esi
#94: R_386_32w7
# 98: b9 01 00 00 00 mov$0x1,%ecx
# 9d: f3 a5 repz movsl %ds:(%esi),%es:(%edi)
# 9f: 66 a5 movsw %ds:(%esi),%es:(%edi)
# a1: a4 movsb %ds:(%esi),%es:(%edi)
# a2: 5e pop%esi
# a3: 5f pop%edi
# a4: c9 leave
# a5: c3 ret
# a6: 89 f6 mov%esi,%esi
if false; then
gcc -O2 \
falign-functions=1 -falign-labels=1 -falign-loops=1 -falign-jumps=1 \
-c t.c
echo Done; read junk
objdump -d -r t.o | $PAGER
exit
fi
# -Os: emits memcpy
if false; then
gcc -nostdinc -isystem
/.share/usr/app/gcc-3.4.1/bin/../lib/gcc/i386-pc-linux-gnu/3.4.1/include \
-Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing \
-fno-common -ffreestanding -Os -falign-functions=1 -falign-labels=1 \
-falign-loops=1 -falign-jumps=1 -fno-omit-frame-pointer -pipe -msoft-float \
-mpreferred-stack-boundary=2 -fno-unit-at-a-time -march=i486 \
-Wdeclaration-after-statement -c t.c
echo Done; read junk
objdump -d -r t.o | $PAGER
exit
fi
# -march=486: emits horrible tail:
# 271: f3 a5 repz movsl %ds:(%esi),%es:(%edi)
# 273: 5e pop%esi
# 274: 66 a1 10 00 00 00 mov0x10,%ax
#276: R_386_32 w19
# 27a: 5f pop%edi
# 27b: 66 a3 10 00 00 00 mov%ax,0x10
#27d: R_386_32 v19
# 281: 5d pop%ebp
# 282: a0 12 00 00 00 mov0x12,%al
#283: R_386_32 w19
# 287: a2 12 00 00 00 mov%al,0x12
#288: R_386_32 v19
# 28c: c3 ret
if false; then
gcc \
-fno-common -ffreestanding -O2 -falign-functions=1 -falign-labels=1 \
-falign-loops=1 -falign-jumps=1 -fno-omit-frame-pointer -pipe -msoft-float \
-mpreferred-stack-boundary=2 -fno-unit-at-a-time -march=i486 \
-Wdeclaration-after-statement \
-c t.c
echo Done; read junk
objdump -d -r t.o | $PAGER
exit
fi
# -Os -minline-all-stringops: still emits memcpy
if true; then
gcc -nostdinc -isystem
/.share/usr/app/gcc-3.4.1/bin/../lib/gcc/i386-pc-linux-gnu/3.4.1/include \
-Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing \
-fno-common -ffreestanding -Os -minline-all-stringops -falign-functions=1
-falign-labels=1 \
-falign-loops=1 -falign-jumps=1 -fno-omit-frame-pointer -pipe -msoft-float \
-mpreferred-stack-boundary=2 -fno-unit-at-a-time -march=i486 \
-Wdeclaration-after-statement -c t.c
echo Done; read junk
objdump -d -r t.o | $PAGER
exit
fi
--
vda
Re: memcpy(a,b,CONST) is not inlined by gcc 3.4.1 in Linux kernel
On Saturday 02 April 2005 15:18, Denis Vlasenko wrote:
> -O2 compile does inline copying, however, suboptimally.
> Pushing/popping esi/edi on the stack is not needed.
> Also "mov $1,ecx; rep; movsl" is rather silly.
I think I am wrong about push/pop. Sorry.
However, other observation is still valid. You
may wish to compile this updated t.c and see.
--
vda
static inline void * __memcpy(void * to, const void * from, int n)
{
int d0, d1, d2;
__asm__ __volatile__(
"rep ; movsl\n\t"
"movl %4,%%ecx\n\t"
"andl $3,%%ecx\n\t"
"jz 1f\n\t" /* pay 2 byte penalty for a chance to skip microcoded rep */
"rep ; movsb\n\t"
"1:"
: "=&c" (d0), "=&D" (d1), "=&S" (d2)
: "0" (n/4), "g" (n), "1" ((long) to), "2" ((long) from)
: "memory");
return (to);
}
/*
* This looks ugly, but the compiler can optimize it totally,
* as the count is constant.
*/
static inline void * __constant_memcpy(void * to, const void * from, int n)
{
#if 1 /* want to do small copies with non-string ops? */
switch (n) {
case 0: return to;
case 1: *(char*)to = *(char*)from; return to;
case 2: *(short*)to = *(short*)from; return to;
case 4: *(int*)to = *(int*)from; return to;
#if 1 /* including those doable with two moves? */
case 3: *(short*)to = *(short*)from;
*((char*)to+2) = *((char*)from+2); return to;
case 5: *(int*)to = *(int*)from;
*((char*)to+4) = *((char*)from+4); return to;
case 6: *(int*)to = *(int*)from;
*((short*)to+2) = *((short*)from+2); return to;
case 8: *(int*)to = *(int*)from;
*((int*)to+1) = *((int*)from+1); return to;
#endif
}
#else
if (!n) return to;
#endif
{
/* load esi/edi */
int esi, edi;
__asm__ __volatile__(
""
: "=&D" (edi), "=&S" (esi)
: "0" ((long) to),"1" ((long) from)
: "memory"
);
}
if (n >= 5*4) {
/* large block: use rep prefix */
int ecx;
__asm__ __volatile__(
"rep ; movsl"
: "=&c" (ecx)
: "0" (n/4)
);
} else {
/* small block: don't clobber ecx + smaller code */
if (n >= 4*4) __asm__ __volatile__("movsl");
if (n >= 3*4) __asm__ __volatile__("movsl");
if (n >= 2*4) __asm__ __volatile__("movsl");
if (n >= 1*4) __asm__ __volatile__("movsl");
}
switch (n % 4) {
/* tail */
case 0: return to;
case 1: __asm__ __volatile__("movsb"); return to;
case 2: __asm__ __volatile__("movsw"); return to;
default: __asm__ __volatile__("movsw\n\tmovsb"); return to;
}
}
#define memcpy(t, f, n) \
(__builtin_constant_p(n) ? \
__constant_memcpy((t),(f),(n)) : \
__memcpy((t),(f),(n)))
#define STRUCT1(n) struct s##n { char c[n]; } v##n, w##n; void f##n(void) { v##n = w##n; } void g##n(void) { memcpy(&v##n,&w##n,n); }
#define STRUCT(n) STRUCT1(n)
STRUCT(1)
STRUCT(2)
STRUCT(3)
STRUCT(4)
STRUCT(5)
STRUCT(6)
STRUCT(7)
STRUCT(8)
STRUCT(9)
STRUCT(10)
STRUCT(11)
STRUCT(12)
STRUCT(13)
STRUCT(14)
STRUCT(15)
STRUCT(16)
STRUCT(17)
STRUCT(18)
STRUCT(19)
STRUCT(20)
Re: Use Bohem's GC for compiler proper in 4.1?
>> 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. You don't know whay swapping is? Shifting memory over from physical RAM to the hard drive when not in use, and putting it back in RAM when in use. > Now, having said that, we do believe that it would make for > interesting research to try less memory intensive algorithms, or to > rearrange code so that the working set is reduced to help boost > cache hits. Currently gcc takes a cache miss every 20 > instructions, or some ungodly number, and that really saps > performance. Would it be possible for an option -fprofile-cache that allows GCOV to profile cache hits/misses? That would really pay off during a profiled bootstrap. And an option -ftry-keeping-on-stack that (on machines allowing random access[1] to the stack) attempts to use the upper part of the stack as a storage for automatic (or equivlent for programming langauge) variables on stack? That would help[2] reduce GCC's cache misses, because not only is it cached, it's there. Samuel Lauber [1] I don't know if any machines do, but last time I looked at `-1(%esp)', I thought so. [2] It would also have the disadvantage that if a program wrecks havoc on the stack or overflows it, some internal variables might get out of sync and cause the generated program to core-dump (a lesson to be learned from GCC 3.3.3's [flaky] SSA optimizer). -- _ Web-based SMS services available at http://www.operamail.com. From your mailbox to local or overseas cell phones. Powered by Outblaze
Re: Use Bohem's GC for compiler proper in 4.1?
>> 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. You don't know whay swapping is? Shifting memory over from physical RAM to the hard drive when not in use, and putting it back in RAM when in use. > Now, having said that, we do believe that it would make for > interesting research to try less memory intensive algorithms, or to > rearrange code so that the working set is reduced to help boost > cache hits. Currently gcc takes a cache miss every 20 > instructions, or some ungodly number, and that really saps > performance. Would it be possible for an option -fprofile-cache that allows GCOV to profile cache hits/misses? That would really pay off during a profiled bootstrap. And an option -ftry-keeping-on-stack that (on machines allowing random access[1] to the stack) attempts to use the upper part of the stack as a storage for automatic (or equivlent for programming langauge) variables on stack? That would help[2] reduce GCC's cache misses, because not only is it cached, it's there. Samuel Lauber [1] I don't know if any machines do, but last time I looked at `-1(%esp)', I thought so. [2] It would also have the disadvantage that if a program wrecks havoc on the stack or overflows it, some internal variables might get out of sync and cause the generated program to core-dump (a lesson to be learned from GCC 3.3.3's [flaky] SSA optimizer). -- _ Web-based SMS services available at http://www.operamail.com. From your mailbox to local or overseas cell phones. Powered by Outblaze
Re: Use Bohem's GC for compiler proper in 4.1?
>> 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. You don't know whay swapping is? Shifting memory over from physical RAM to the hard drive when not in use, and putting it back in RAM when in use. > Now, having said that, we do believe that it would make for > interesting research to try less memory intensive algorithms, or to > rearrange code so that the working set is reduced to help boost > cache hits. Currently gcc takes a cache miss every 20 > instructions, or some ungodly number, and that really saps > performance. Would it be possible for an option -fprofile-cache that allows GCOV to profile cache hits/misses? That would really pay off during a profiled bootstrap. And an option -ftry-keeping-on-stack that (on machines allowing random access[1] to the stack) attempts to use the upper part of the stack as a storage for automatic (or equivlent for programming langauge) variables on stack? That would help[2] reduce GCC's cache misses, because not only is it cached, it's there. Samuel Lauber [1] I don't know if any machines do, but last time I looked at `-1(%esp)', I thought so. [2] It would also have the disadvantage that if a program wrecks havoc on the stack or overflows it, some internal variables might get out of sync and cause the generated program to core-dump (a lesson to be learned from GCC 3.3.3's [flaky] SSA optimizer). -- _ Web-based SMS services available at http://www.operamail.com. From your mailbox to local or overseas cell phones. Powered by Outblaze
Re: Use Bohem's GC for compiler proper in 4.1?
> mem peak user sys > > > gcc 3.4 -S -O0 476 MB1m39s 2s > gcc 4.0 -S -O0 655 MB2m23s 3s > > icc -S -O0 264 MB 1m24s 15s > > > the file makes quite heavy use of virtual inheritance so there are a > lot of virtual tables involved. are there any known performance bugs > in this area or should I file a PR? > > any suggestions on how to simplify the testcase? (preprocessed is ~60k > lines) I'm curious what the 3.3 numbers are, but the same proprocessed file may not compile there since the parser changed in 3.4. Not critical. The regression in 4.0 is pretty bad, definitely file a PR. See: http://gcc.gnu.org/bugs.html for instructions. It may be a known problem or a new one, let's find out. If you can't reduce the .ii testcase, don't worry so much. Just bzip it and submit it as a compressed attachment. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Use Bohem's GC for compiler proper in 4.1?
On 04/01/2005 11:23 AM, Daniel Jacobowitz wrote: [snip] There are other ways to solve this problem, including creating a generational collector using our existing accurate GC. I've been working on this on-and-off (mostly off at the moment, though). I briefly looked at: Type-Information.html from: http://gcc.gnu.org/onlinedocs/gccint-html.tar.gz I was wondering why the method described here: http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc_typedh.txt was not used instead to create an accurate GC method in the compiler. I assume the reason is that using: GTY(()) as described in the .html file was just easier and less error prone than Boehm's at the cost of requiring some extra preprocesssing? That makes me wonder whether this method could be made available to programmer's of c or even c++ file to enable accurate GC in their code? Of course this would be an extension, but it wouldn't be the 1st time gcc's added extensions ;)
Re: Use Bohem's GC for compiler proper in 4.1?
On Sat, Apr 02, 2005 at 10:40:35AM -0600, Larry Evans wrote: > I briefly looked at: > > Type-Information.html > > from: > > http://gcc.gnu.org/onlinedocs/gccint-html.tar.gz > > I was wondering why the method described here: > > http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc_typedh.txt > > was not used instead to create an accurate GC method in the compiler. > I assume the reason is that using: > >GTY(()) > > as described in the .html file was just easier and less error prone > than Boehm's at the cost of requiring some extra preprocesssing? They don't have the same design constraints or goals. For instance, the GTY machinery can determine the type of an object during tree walking; it does not need to store the type in memory. We also reuse the GTY machinery for precompiled header support; I don't know if we could get Boehm to do that. -- Daniel Jacobowitz CodeSourcery, LLC
Re: Use Bohem's GC for compiler proper in 4.1?
Mike Stump wrote: > Swapping, what's that? Here's $20, go buy a gigabyte. I hope that was not meant to be taken literally, or perhaps memory really is that cheap where you live. Apple charge me 19x-33x that amount, depending on model. Plus shipping. On topic: Even if memory were cheap (which it is not) and if locality were good (which is not the case either), spare memory would be more useful to run more things at once (parallel compilations).
GCC errors
Hi, I am trying to compile MEDIABENCH (@UCLA) using the latest GCC CVS checkout. I get the following errors when I compile with "-O3 -fprofile-generate". I just want to make sure that this is not a silly mistake before I file a bug report. Can someone help? Almost 9 out of 11 benchmarks throw error. Two errors are reported below. For benchmark(epic) * gcc -static -fprofile-generate -O3 -c build_pyr.c build_pyr.c: In function âbuild_levelâ: build_pyr.c:94: error: Abnormal edges for no purpose in bb 162 build_pyr.c:94: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make: *** [build_pyr.o] Error 1 For benchmark (g721) * gcc -static -fprofile-generate -o encode encode.c g711.o g72x.o g721.o g723_24.o g723_40.o encode.c: In function âmainâ: encode.c:98: warning: incompatible implicit declaration of built-in function âexitâ encode.c:99: warning: incompatible implicit declaration of built-in function âstrcpyâ encode.c:100: warning: incompatible implicit declaration of built-in function âstrcatâ encode.c:132: error: unrecognizable insn: (insn 738 159 739 74 (set (reg:SI 242) (reg:SI 19 dirflag)) -1 (nil) (nil)) encode.c:132: internal compiler error: in extract_insn, at recog.c:2042 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make: *** [encode] Error 1 --Raj
Re: GCC errors
On Saturday 02 April 2005 20:22, Rajkishore Barik wrote: > Hi, > I am trying to compile MEDIABENCH (@UCLA) using the latest GCC CVS > checkout. I get > the following errors when I compile with "-O3 -fprofile-generate". I just > want to make sure > that this is not a silly mistake before I file a bug report. Can someone > help? If you see an internal compiler error (ICE), you found a bug in GCC. No matter how many silly mistakes you make, GCC should never "ICE". > Almost 9 out of 11 Almost 9 out of 11? Is that 8.9 out of 11, or 9.1 out of 11? :-P > gcc -static -fprofile-generate -O3 -c build_pyr.c > build_pyr.c: In function âbuild_levelâ: > build_pyr.c:94: error: Abnormal edges for no purpose in bb 162 > build_pyr.c:94: internal compiler error: verify_flow_info failed > Please submit a full bug report, > with preprocessed source if appropriate. > See http://gcc.gnu.org/bugs.html> for instructions. > make: *** [build_pyr.o] Error 1 So, See http://gcc.gnu.org/bugs.html for instructions about how to report this bug. Gr. Steven
Re: RFC: #pragma optimization_level
On Fri, 1 Apr 2005, Joe Buck wrote: > Unfortunately, where there is a good argument for not using empty loops > as busy-waits, at one time it was documented GCC behavior that it would > work, so we can't really blame the users for trusting the doc. However, it's really a looong time since we clarified that: Mon Dec 28 19:26:32 1998 Gerald Pfeifer <[EMAIL PROTECTED]> * gcc.texi (Non-bugs): ``Empty'' loops will be optimized away in the future; indeed that already happens in some cases. Gerald
Re: RFC: #pragma optimization_level
On Sat, Apr 02, 2005 at 08:29:48PM +0200, Gerald Pfeifer wrote: > On Fri, 1 Apr 2005, Joe Buck wrote: > > Unfortunately, where there is a good argument for not using empty loops > > as busy-waits, at one time it was documented GCC behavior that it would > > work, so we can't really blame the users for trusting the doc. > > However, it's really a looong time since we clarified that: > > Mon Dec 28 19:26:32 1998 Gerald Pfeifer <[EMAIL PROTECTED]> > > * gcc.texi (Non-bugs): ``Empty'' loops will be optimized away in > the future; indeed that already happens in some cases. You forget that I am as old as the hills. :-)
Re: Bug#300945: romeo: FTBFS (amd64/gcc-4.0): invalid lvalue in assignment
Can the GCC "C Extension" of "Generalized Lvalues" be enabled with a switch in gcc-4.0? Cheers, Shaun On Mar 22, 2005 12:29 PM, Andreas Jochens <[EMAIL PROTECTED]> wrote: > Package: romeo > Severity: normal > Tags: patch > > When building 'romeo' on amd64 with gcc-4.0, > I get the following error: > > assemble.c:581: error: invalid lvalue in assignment > assemble.c: In function 'MergeIfAdjacent': > assemble.c:645: error: invalid lvalue in assignment > assemble.c:647: error: invalid lvalue in assignment > assemble.c:649: error: invalid lvalue in assignment > assemble.c: In function 'ROMfree': > assemble.c:710: error: invalid lvalue in assignment > assemble.c:720: error: invalid lvalue in assignment > assemble.c:744: error: invalid lvalue in assignment > assemble.c:745: error: invalid lvalue in assignment > assemble.c: In function 'CompareTypeCtor': > assemble.c:1420: warning: pointer targets in passing argument 1 of 'strncmp' > differ in signedness > assemble.c:1420: warning: pointer targets in passing argument 2 of 'strncmp' > differ in signedness > assemble.c: In function 'SetSystem': > assemble.c:1504: warning: pointer targets in initialization differ in > signedness > assemble.c:1597: warning: pointer targets in passing argument 1 of 'strlen' > differ in signedness > assemble.c:1606: warning: pointer targets in passing argument 1 of 'strlen' > differ in signedness > make[1]: *** [assemble.o] Error 1 > make[1]: Leaving directory `/romeo-0.5.0' > make: *** [build-stamp] Error 2 > > With the attached patch 'romeo' can be compiled > on amd64 using gcc-4.0. > > Regards > Andreas Jochens [clip patch]
Re: Bug#300945: romeo: FTBFS (amd64/gcc-4.0): invalid lvalue in assignment
On Apr 2, 2005, at 4:53 PM, Shaun Jackman wrote: Can the GCC "C Extension" of "Generalized Lvalues" be enabled with a switch in gcc-4.0? No. Cheers, Shaun On Mar 22, 2005 12:29 PM, Andreas Jochens <[EMAIL PROTECTED]> wrote: Package: romeo Severity: normal Tags: patch When building 'romeo' on amd64 with gcc-4.0, I get the following error: assemble.c:581: error: invalid lvalue in assignment assemble.c: In function 'MergeIfAdjacent': assemble.c:645: error: invalid lvalue in assignment assemble.c:647: error: invalid lvalue in assignment assemble.c:649: error: invalid lvalue in assignment assemble.c: In function 'ROMfree': assemble.c:710: error: invalid lvalue in assignment assemble.c:720: error: invalid lvalue in assignment assemble.c:744: error: invalid lvalue in assignment assemble.c:745: error: invalid lvalue in assignment assemble.c: In function 'CompareTypeCtor': assemble.c:1420: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness assemble.c:1420: warning: pointer targets in passing argument 2 of 'strncmp' differ in signedness assemble.c: In function 'SetSystem': assemble.c:1504: warning: pointer targets in initialization differ in signedness assemble.c:1597: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness assemble.c:1606: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness make[1]: *** [assemble.o] Error 1 make[1]: Leaving directory `/romeo-0.5.0' make: *** [build-stamp] Error 2 With the attached patch 'romeo' can be compiled on amd64 using gcc-4.0. Regards Andreas Jochens [clip patch]
Re: Bug#300945: romeo: FTBFS (amd64/gcc-4.0): invalid lvalue in assignment
On Apr 2, 2005, at 4:57 PM, Andrew Pinski wrote: On Apr 2, 2005, at 4:53 PM, Shaun Jackman wrote: Can the GCC "C Extension" of "Generalized Lvalues" be enabled with a switch in gcc-4.0? No. Note a better fix for the bug would be: #definememUHeapSize(p,ver) \ *(ver>2 ? &((MemHeapHeaderPtr)p)->size : (ver>1 ? &((Mem2HeapHeaderPtr)p)->size : (&(Mem1HeapHeaderPtr)p)->size)) And then you get a lvalue. -- Pinski
Re: Bug#300945: romeo: FTBFS (amd64/gcc-4.0): invalid lvalue in assignment
Shaun Jackman <[EMAIL PROTECTED]> writes: | Can the GCC "C Extension" of "Generalized Lvalues" be enabled with a | switch in gcc-4.0? It is gone forever. -- Gaby
Re: Use Bohem's GC for compiler proper in 4.1?
Kaveh R. Ghazi schrieb: I'm curious what the 3.3 numbers are, 3.3 => 4.0 is a small improvement cpu-wise(not mem-wise). 3.4 is much better than both: gcc-Version 3.3.5 (Debian 1:3.3.5-8) mem 426 mb user2m10.870s sys 0m2.250s gcc-Version 3.4.4 20041218 (prerelease) (Debian 3.4.3-6) mem 387 mb user1m4.920s sys 0m1.210s gcc-Version 4.0.0 20041218 (experimental) mem 581 mb user2m0.800s sys 0m2.720s (it's another file than yesterday, because on this one 3.4 -> 4.0 is more extreme) The regression in 4.0 is pretty bad, definitely file a PR. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20733 -- Stefan Strasser
Re: Use Bohem's GC for compiler proper in 4.1?
On Apr 2, 2005, at 6:12 PM, Stefan Strasser wrote: gcc-Version 4.0.0 20041218 (experimental) this 4.0.0 is almost 4 months old. That is not a far comparison as there was speedups after that and other bug fixes. -- Pinski
Re: Use Bohem's GC for compiler proper in 4.1?
On Sat, Apr 02, 2005 at 06:10:29PM -0500, Andrew Pinski wrote: > > On Apr 2, 2005, at 6:12 PM, Stefan Strasser wrote: > > >gcc-Version 4.0.0 20041218 (experimental) > > > > this 4.0.0 is almost 4 months old. > That is not a far comparison as there was speedups after that > and other bug fixes. No one should ever be saying "4.0.0" without modification; it does not yet exist. If you refer to it in a benchmark, please say something like 4.0.0-20041218 since it's changing every day.
gcc-4.0-20050402 is now available
Snapshot gcc-4.0-20050402 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050402/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 CVS branch with the following options: -rgcc-ss-4_0-20050402 You'll find: gcc-4.0-20050402.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20050402.tar.bz2 C front end and core compiler gcc-ada-4.0-20050402.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20050402.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20050402.tar.bz2 C++ front end and runtime gcc-java-4.0-20050402.tar.bz2 Java front end and runtime gcc-objc-4.0-20050402.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20050402.tar.bz2The GCC testsuite Diffs from 4.0-20050326 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Use Bohem's GC for compiler proper in 4.1?
Andrew Pinski schrieb: On Apr 2, 2005, at 6:12 PM, Stefan Strasser wrote: gcc-Version 4.0.0 20041218 (experimental) this 4.0.0 is almost 4 months old. That is not a far comparison as there was speedups after that and other bug fixes. you're right, I wasn't prepared to do performance tests: gcc-Version 3.4.4 20041218 (prerelease) (Debian 3.4.3-6) user0m57.250s sys 0m1.050s gcc-Version 4.0.0 20041218 (experimental) user1m53.810s sys 0m2.850s gcc-Version 4.0.0 20050402 (prerelease) user0m40.290s sys 0m1.070s impressing. thank you very much to whoever fixed this. mem usage 3.4/current 4.0 is about equal. intel: user0m42.080s sys 0m9.040s (slightly different file due to PR20734) -- Stefan Strasser
