A simple sample code involving templates, friends and lookup
Hello,
I'm aware about these issues being around for quite a while now, but
there is still a chance this sample code can be helpful. I apologize
if someone gets annoyed :-P
template
struct Foo
{
template
friend void func(const Foo &);
};
void check(const Foo & x)
{
// Foo weird; // uncomment this line and all works
func(x);// <-- ERROR
}
Tested with gcc 4.0 - 4.3, and all behave the same:
"error: ‘func’ was not declared in this scope"
but it works if you uncomment the weird line.
Best regards,
Dragan Milenkovic
Re: powercp-linux cross GCC 4.2 vs GCC 4.0.0: -Os code size regression?
On Wed, Jan 16, 2008 at 04:55:19PM +0300, Sergei Poselenov wrote: > Hello, > > I've just noted an error in my calculations: not 40%, but 10% > regression (used gdb to do the calculations and forgot to convert > inputs to float). Sorry. > > But the problem still persists for me - I'm building an embedded > firmware (U-Boot) and it doesn't fit into the reserved space > anymore. > [snipped] > As for the CSiBE results - the average regression is > 3%, including top 3 winners: > 100% (32768 vs 16384 for "linux-2.4.23-pre3-testplatform - > arch/testplatform/kernel/init_task") A change from an exact power of 2 to the next one looks very suspiscious: I seriously doubt that it is a code generation or instruction choice issue. While there might be a relatively small increase in size inherent to the compiler, it looks like it then goes to a "round to the next power of 2" step. Do you set the right options for your particular processor (-Os might not override some scheduling decisions and the default target processor might have changed between GCC releases)? Regards, Gabriel
Re: powercp-linux cross GCC 4.2 vs GCC 4.0.0: -Os code size regression?
Hello Gabriel, Gabriel Paubert wrote: On Wed, Jan 16, 2008 at 04:55:19PM +0300, Sergei Poselenov wrote: Hello, I've just noted an error in my calculations: not 40%, but 10% regression (used gdb to do the calculations and forgot to convert inputs to float). Sorry. But the problem still persists for me - I'm building an embedded firmware (U-Boot) and it doesn't fit into the reserved space anymore. [snipped] As for the CSiBE results - the average regression is 3%, including top 3 winners: 100% (32768 vs 16384 for "linux-2.4.23-pre3-testplatform - arch/testplatform/kernel/init_task") A change from an exact power of 2 to the next one looks very suspiscious: I seriously doubt that it is a code generation or instruction choice issue. While there might be a relatively small increase in size inherent to the compiler, it looks like it then goes to a "round to the next power of 2" step. Probably your are right. Do you set the right options for your particular processor (-Os might not override some scheduling decisions and the default target processor might have changed between GCC releases)? I don't know now, actually, this is what I'm asking. As for the target processor - as I stated in the initial message: ... Currently, it builds as following: ppc-linux-gcc -g -Os -fPIC -ffixed-r14 -meabi -fno-strict-aliasing -D__KERNEL__ -DTEXT_BASE=0xfffc -I/work/psl/tmp/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem /opt/eldk-4.2-01-08/usr/bin/../lib/gcc/powerpc-linux/4.2.2/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_4xx -ffixed-r2 -ffixed-r29 -mstring -msoft-float -Wa,-m440 -mcpu=440 -DCONFIG_440=1 -Wall -Wstrict-prototypes -c -o interrupts.o interrupts.c ... Note the "-mcpu=440" switch. I removed all "-ffixed" option (just for test - we surely need them) - it doesn't change the size of the resultant gcc-4.2.2 code. Regards, Sergei Regards, Gabriel
Re: A simple sample code involving templates, friends and lookup
On Jan 17, 2008 11:44 AM, Dragan Milenkovic <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I'm aware about these issues being around for quite a while now, but
> there is still a chance this sample code can be helpful. I apologize
> if someone gets annoyed :-P
>
>
> template
> struct Foo
> {
> template
> friend void func(const Foo &);
> };
>
> void check(const Foo & x)
> {
> // Foo weird; // uncomment this line and all works
>
> func(x);// <-- ERROR
> }
>
>
> Tested with gcc 4.0 - 4.3, and all behave the same:
>
> "error: 'func' was not declared in this scope"
>
> but it works if you uncomment the weird line.
Actually even with the weird line the program is invalid. What are
you trying to do? ;)
Richard.
Re: powercp-linux cross GCC 4.2 vs GCC 4.0.0: -Os code size regression?
Hello Sergei, On Thu, Jan 17, 2008 at 03:13:59PM +0300, Sergei Poselenov wrote: > I don't know now, actually, this is what I'm asking. As for the > target processor - as I stated in the initial message: > > ... > Currently, it builds as following: > ppc-linux-gcc -g -Os -fPIC -ffixed-r14 -meabi -fno-strict-aliasing > -D__KERNEL__ -DTEXT_BASE=0xfffc -I/work/psl/tmp/u-boot/include > -fno-builtin -ffreestanding -nostdinc -isystem > /opt/eldk-4.2-01-08/usr/bin/../lib/gcc/powerpc-linux/4.2.2/include > -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_4xx -ffixed-r2 -ffixed-r29 > -mstring -msoft-float -Wa,-m440 -mcpu=440 -DCONFIG_440=1 -Wall > -Wstrict-prototypes -c -o interrupts.o interrupts.c > ... > > Note the "-mcpu=440" switch. Doh, I missed this, sorry. > > I removed all "-ffixed" option (just for test - we surely need them) > - it doesn't change the size of the resultant gcc-4.2.2 code. I'm not sure that having -ffixed-r29 is a wise choice when you are looking for small code size. It might prevent the use of load/store multiple in prologue and epilogue code. Regards, Gabriel
Re: A simple sample code involving templates, friends and lookup
Richard Guenther wrote:
[snip]
template
struct Foo
{
template
friend void func(const Foo &);
};
void check(const Foo & x)
{
// Foo weird; // uncomment this line and all works
func(x);// <-- ERROR
}
Tested with gcc 4.0 - 4.3, and all behave the same:
"error: 'func' was not declared in this scope"
but it works if you uncomment the weird line.
Actually even with the weird line the program is invalid. What are
you trying to do? ;)
Richard.
Ok... afaik, that func should be defined on that very place where it is
declared as friend. But could you please elaborate why it is invalid,
since you made me start questioning my C++ knowledge... :-D
Dragan
Re: A simple sample code involving templates, friends and lookup
On Jan 17, 2008 2:12 PM, Dragan Milenkovic <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
> [snip]
> >> template
> >> struct Foo
> >> {
> >> template
> >> friend void func(const Foo &);
> >> };
> >>
> >> void check(const Foo & x)
> >> {
> >> // Foo weird; // uncomment this line and all works
> >>
> >> func(x);// <-- ERROR
> >> }
> >>
> >>
> >> Tested with gcc 4.0 - 4.3, and all behave the same:
> >>
> >> "error: 'func' was not declared in this scope"
> >>
> >> but it works if you uncomment the weird line.
> >
> > Actually even with the weird line the program is invalid. What are
> > you trying to do? ;)
> >
> > Richard.
>
> Ok... afaik, that func should be defined on that very place where it is
> declared as friend. But could you please elaborate why it is invalid,
> since you made me start questioning my C++ knowledge... :-D
How should name-lookup find func?
Richard.
Re: powercp-linux cross GCC 4.2 vs GCC 4.0.0: -Os code size regression? [Emcraft #11717]
On Jan 17, 2008 3:48 PM, Sergei Poselenov <[EMAIL PROTECTED]> wrote: > Hello Andrew, > > I agree. Actually, the CSiBE results are impressive: I've built the > bzip2 library for powerpc and got similar results. > > I wonder why GCC maintainers are ignoring the -Os regression for > most of their cases (at least for powerpc). As always - patches welcome. Richard.
Re: powercp-linux cross GCC 4.2 vs GCC 4.0.0: -Os code size regression? [Emcraft #11717]
Hello Andrew, Andrew Haley wrote: Sergei Poselenov writes: > Hello Andrew, > > > Now, I sympathize that in your particular case you have a code size > > regression. This happens: when we do optimization in gcc, some code > > bases will lose out. All that we can promise is that we try not to > > make it worse for most users. > > > > What we can do is compare your code that has got much worse, and try > > to figure out why. > > > > Would the generated asm listings be enough? Or should I send > the preprocessed sources as well? Both. Rather than sending stuff, best to stick it on a web site if you can. Here it is: Preprocessed and assembler code generated by the GCC 4.2.2 ppc-linux cross-compiler: http://www.emcraft.com/codesize/gcc-4.2.2/interrupts.i http://www.emcraft.com/codesize/gcc-4.2.2/interrupts.s The same code built with gcc-4.0.0 cross-compiler: http://www.emcraft.com/codesize/gcc-4.0.0/interrupts.i http://www.emcraft.com/codesize/gcc-4.0.0/interrupts.s Again, for convenience, the compilation string is: ppc-linux-gcc -g -Os -fPIC -D__KERNEL__ -DTEXT_BASE=0xfffc -I/work/psl/tmp/u-boot/include -fno-builtin -nostdinc -isystem /opt/eldk-4.2-01-08/usr/bin/../lib/gcc/powerpc-linux/4.2.2/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_4xx -msoft-float -Wa,-m440 -mcpu=440 -DCONFIG_440=1 -Wall -Wstrict-prototypes -c interrupts.c The 'size' output for both the cases: textdata bss dec hex filename 2696 601536429210c4 interrupts.o and textdata bss dec hex filename 2424 8815364048 fd0 interrupts.o Having said that, your example is tiny, so it's likely that it won't be very representative, and the less representative the code is the less likely a gcc maintainer will be interested. But at least we'll be able to see the difference. I agree. Actually, the CSiBE results are impressive: I've built the bzip2 library for powerpc and got similar results. I wonder why GCC maintainers are ignoring the -Os regression for most of their cases (at least for powerpc). Thanks, Sergei Andrew.
Re: History of m68k ABI and `-malign-int'?
On Thu, Jan 17, 2008 at 01:08:16AM +0100, Andreas Schwab wrote: > Carlos O'Donell <[EMAIL PROTECTED]> writes: > > > Why is 16-bit int alignment the default for m68k in gcc? > > > > Which ABIs influenced this decision? > > The original ABI was defined by Sun PCC. Note that the SysV ABI > actually uses natural alignment for all types, but that came only much > later. > > You can find much of the history in the change logs of gcc 1.42. Excellent, that scratches my itch, thanks for providing a history lesson and a good pointer. Cheers, Carlos. -- Carlos O'Donell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x716
Re: A simple sample code involving templates, friends and lookup
template
struct Foo
{
template
friend void func(const Foo &);
};
void check(const Foo & x)
{
// Foo weird; // uncomment this line and all works
func(x);// <-- ERROR
}
Tested with gcc 4.0 - 4.3, and all behave the same:
"error: 'func' was not declared in this scope"
but it works if you uncomment the weird line.
Actually even with the weird line the program is invalid. What are
you trying to do? ;)
I don't know if it is invalid or not, but with the weird line
uncommented it compiles (like if func was brought into scope).
Paolo
RE: Memory leaks in compiler
On 16 January 2008 22:09, Diego Novillo wrote: > On 1/16/08 4:16 PM, Andrew Haley wrote: > >> Because it's not a bug? You're changing the code to silence a false >> negative, which this is what we here in England call "putting the cart >> before the horse." If we clean up all the memory regions on closedown >> we'll be wasting CPU time. And for what? > > I agree. Freeing memory right before we exit is a waste of time. So, no gcc without an MMU and virtual memory platform ever again? Shame, it used to run on Amigas. cheers, DaveK -- Can't think of a witty .sigline today
RE: Memory leaks in compiler
Diego Novillo wrote: >I agree. Freeing memory right before we exit is a waste of time. Dave Korn writes: > So, no gcc without an MMU and virtual memory platform ever again? >Shame, it used to run on Amigas. I don't know if GCC ever freed all of its memory before exiting. An operating system doesn't need an MMU or virtual memory in order to free all the memory used by a process when it exits. MS-DOS did this, and I assume AmigaOS did as well. Ross Ridge
Re: Memory leaks in compiler
> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes: Dave> So, no gcc without an MMU and virtual memory platform ever Dave> again? Shame, it used to run on Amigas. If you are serious about doing a port like this, then I will recant and support not only this patch, but all the other ones you will have to write to make it work. Perhaps this could be done as an optional thing, to avoid penalizing platforms that don't need it. Tom
Re: jc1 out of memory error gcc 4.2.2 Linux 64-bit OS
> > I am trying to compile a java app. I don't have the script in front of
> > me that i am using because I am at a client's office right now. The
> > jist of
> > the command line is as follows:
> >
> > gcj -O -fjni -s -main=main.App --classpath=x1.jar x2.jar x3.jar x4.jar
> > x5.jar x6.jar x7.jar x8.jar -o scln.exe class1.java class2.java
> > class3.java ... class125.java -ly -ldz
>
> This is very likely to cause out of memory errors. This will probably
> work better:
>
> gcj -c -O -fjni --classpath=x1.jar x2.jar
> gcj -c -O -fjni --classpath=x1.jar x3.jar
> gcj -c -O -fjni --classpath=x1.jar x4.jar
>
> And link them all together at the end.
Thanks to everyone for their kind help and advice. I tried Andrew's
advice out as noted above, and it worked! I was finally able to
generate a windows executable on 64 bit processors . On another note,
I had to process all my classes as class files and not as java files
for this to work. There is one last issue, of which I have a feeling
may not be a big issue. When I double click on my executable, I get
the following stacktrace printed out to a command prompt window:
Exception in thread "main" java.lang.NoClassDefFoundError: main.App
at java.lang.Class.initializeClass(/datal/gcc/gcc/gcc/libgcc2.c:0)
Caused by: java.lang.ClassNotFoundException: org.eclipse.swt.widgets.Listener no
t found in gnu.gcj.runtime.SystemClassLoader{urls=[file:.\], parent=gnu.gcj.runt
ime.ExtensionClassLoader{urls=[], parent=null}}
at java.net.URLClassLoader.findClass(/datal/gcc/gcc/libjava/java/net/URLClass
Loader.java:1080)
at java.lang.ClassLoader.loadClass(/datal/gcc/gcc/libjava/java/lang/ClassLoad
er.java:351)
at java.lang.ClassLoader.loadClass(/datal/gcc/gcc/libjava/java/lang/ClassLoad
er.java:295)
at java.lang.VMClassLoader.defineClass(/datal/gcc/gcc/libjava/classpath/java/
io/Writer.java:187)
at java.lang.ClassLoader.defineClass(/datal/gcc/gcc/libjava/java/lang/ClassLo
ader.java:483)
at java.security.SecureClassLoader.defineClass(/datal/gcc/gcc/libjava/classpa
th/java/security/SecureClassLoader.java:108)
at java.net.URLClassLoader.findClass(/datal/gcc/gcc/libjava/java/net/URLClass
Loader.java:1171)
at java.lang.ClassLoader.loadClass(/datal/gcc/gcc/libjava/java/lang/ClassLoad
er.java:351)
at java.lang.ClassLoader.loadClass(/datal/gcc/gcc/libjava/java/lang/ClassLoad
er.java:295)
at java.lang.Class.initializeClass(/datal/gcc/gcc/gcc/libgcc2.c:0)
It looks like it is not able to find or load the swt library i use for
my app. I have compiled, and linked the swt jar to the executable, and
the corresponding swt dll is in the same directory where my executable
is located. The following line below is used to generate my
executable:
gcj -O -fjni -findirect-dispatch "--classpath=
C:/lib/x1.jar;C:/lib/x2.jar" --main=main.App -o scnlm.exe y1.class
y2.class -LC:/projects/java/TSCN/Desktop/3232 -lswt -lswt-win32-3232
Note all of the jars have been compiled into libswt, including swt.jar
--
Harpal Grover
President
Harpal Grover Consulting Inc
Re: Memory leaks in compiler
On Thu, Jan 17, 2008 at 11:08:25AM -0500, Ross Ridge wrote: > Diego Novillo wrote: > >I agree. Freeing memory right before we exit is a waste of time. > > Dave Korn writes: > > So, no gcc without an MMU and virtual memory platform ever again? > >Shame, it used to run on Amigas. > > I don't know if GCC ever freed all of its memory before exiting. > An operating system doesn't need an MMU or virtual memory in order to > free all the memory used by a process when it exits. MS-DOS did this, > and I assume AmigaOS did as well. No, AmigaOS did not free memory used by a process when it exits. AmigaOS did not keep track of which memory belonged to which process. For programs that exited normally (e.g. through exit() or a return from main()) then the C library freed all memory that had been allocated through malloc/calloc/realloc (together with closing open files and calling functions registered through atexit(), etc.). A program that crashed and thus did not call these cleanup routines caused a memory leak. -- Erik Trulsson [EMAIL PROTECTED]
Re: Memory leaks in compiler
On Thu, Jan 17, 2008 at 11:08:25AM -0500, Ross Ridge wrote: > Diego Novillo wrote: > >I agree. Freeing memory right before we exit is a waste of time. > > Dave Korn writes: > > So, no gcc without an MMU and virtual memory platform ever again? > >Shame, it used to run on Amigas. > > I don't know if GCC ever freed all of its memory before exiting. > An operating system doesn't need an MMU or virtual memory in order to > free all the memory used by a process when it exits. MS-DOS did this, > and I assume AmigaOS did as well. valgrind will not report a heap block as a leak if it is pointed to by a global or static pointer. So if you want to shut up valgrind (and other leak detectors that work based on reachability, like Purify), then instead of doing a "free" (or delete, or other deallocation call) at the end, you could just assign a pointer to the top of the data structure to some global pointer that you reserve for the purpose. So, instead of dealloc_big_object(obj_ptr); just static T* shut_up_valgrind; shut_up_valgrind = obj_ptr; valgrind can also give you a report of how much memory remains allocated on exit, but that is a separate issue.
Re: A simple sample code involving templates, friends and lookup
On 17 Jan 2008 09:09:38 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>
> "Richard Guenther" <[EMAIL PROTECTED]> writes:
>
> > On Jan 17, 2008 2:12 PM, Dragan Milenkovic <[EMAIL PROTECTED]> wrote:
> > > Richard Guenther wrote:
> > > [snip]
> > > >> template
> > > >> struct Foo
> > > >> {
> > > >> template
> > > >> friend void func(const Foo &);
> > > >> };
> > > >>
> > > >> void check(const Foo & x)
> > > >> {
> > > >> // Foo weird; // uncomment this line and all works
> > > >>
> > > >> func(x);// <-- ERROR
> > > >> }
> > > >>
> > > >>
> > > >> Tested with gcc 4.0 - 4.3, and all behave the same:
> > > >>
> > > >> "error: 'func' was not declared in this scope"
> > > >>
> > > >> but it works if you uncomment the weird line.
> > > >
> > > > Actually even with the weird line the program is invalid. What are
> > > > you trying to do? ;)
> > > >
> > > > Richard.
> > >
> > > Ok... afaik, that func should be defined on that very place where it is
> > > declared as friend. But could you please elaborate why it is invalid,
> > > since you made me start questioning my C++ knowledge... :-D
> >
> > How should name-lookup find func?
>
> It should use argument dependent lookup. This is like the common case
> of
>
> class x
> {
> friend x operator+(const& x, const& x) { return x.var + x.var; }
> };
>
> in which x::operator+ is found without taking special action.
Well, first I think you'd need friend-injection or otherwise a global
decl of the function. Second I thought argument dependent
name-lookup only applies to namespaces, not classes.
EDG rejects this consistently btw.
Richard.
Re: A simple sample code involving templates, friends and lookup
"Richard Guenther" <[EMAIL PROTECTED]> writes:
> On Jan 17, 2008 2:12 PM, Dragan Milenkovic <[EMAIL PROTECTED]> wrote:
> > Richard Guenther wrote:
> > [snip]
> > >> template
> > >> struct Foo
> > >> {
> > >> template
> > >> friend void func(const Foo &);
> > >> };
> > >>
> > >> void check(const Foo & x)
> > >> {
> > >> // Foo weird; // uncomment this line and all works
> > >>
> > >> func(x);// <-- ERROR
> > >> }
> > >>
> > >>
> > >> Tested with gcc 4.0 - 4.3, and all behave the same:
> > >>
> > >> "error: 'func' was not declared in this scope"
> > >>
> > >> but it works if you uncomment the weird line.
> > >
> > > Actually even with the weird line the program is invalid. What are
> > > you trying to do? ;)
> > >
> > > Richard.
> >
> > Ok... afaik, that func should be defined on that very place where it is
> > declared as friend. But could you please elaborate why it is invalid,
> > since you made me start questioning my C++ knowledge... :-D
>
> How should name-lookup find func?
It should use argument dependent lookup. This is like the common case
of
class x
{
friend x operator+(const& x, const& x) { return x.var + x.var; }
};
in which x::operator+ is found without taking special action.
Ian
libgcc_s.so.1 for IRIX
Dear all. I am trying to obtain a libgcc_s.so.1 for IRIX. I have downloaded and installed the fw_gcc-3.3.tardist, but the closest file to the one I want is libgcc.a. Could anybody help? Thamks, João.
Re: powercp-linux cross GCC 4.2 vs GCC 4.0.0: -Os code size regression? [Emcraft #11717]
On Thu, Jan 17, 2008 at 05:48:10PM +0300, Sergei Poselenov wrote: > Hello Andrew, > > Andrew Haley wrote: > >Sergei Poselenov writes: > > > Hello Andrew, > > > > > > > Now, I sympathize that in your particular case you have a code size > > > > regression. This happens: when we do optimization in gcc, some code > > > > bases will lose out. All that we can promise is that we try not to > > > > make it worse for most users. > > > > > > > > What we can do is compare your code that has got much worse, and try > > > > to figure out why. > > > > > > > > > > Would the generated asm listings be enough? Or should I send > > > the preprocessed sources as well? > > > >Both. > > > >Rather than sending stuff, best to stick it on a web site if you can. > > > > Here it is: > Preprocessed and assembler code generated by the GCC 4.2.2 ppc-linux > cross-compiler: > http://www.emcraft.com/codesize/gcc-4.2.2/interrupts.i > http://www.emcraft.com/codesize/gcc-4.2.2/interrupts.s > > The same code built with gcc-4.0.0 cross-compiler: > http://www.emcraft.com/codesize/gcc-4.0.0/interrupts.i > http://www.emcraft.com/codesize/gcc-4.0.0/interrupts.s > The functions do not appear in the same order in both files, it's a bit surprising! Anyway look for example at irq_install_handler: - gcc-4.0 saves all registers using stmw r24,xx(r1) and restores them with lmw r24,xx(r1) however this means that r29 is overwritten in the epilogue. - gcc-4.2.2 saves and restores registers individually which means that it takes 12 more instructions. There go 48 bytes. This is especially visible in the epilogue (in the prologue the saves are interspersed with other instructions). In this case -ffixed-r29 hurts, but gcc4.2.2 looks more correct. Regards, Gabriel
Re: A simple sample code involving templates, friends and lookup
"Richard Guenther" <[EMAIL PROTECTED]> writes:
> > > On Jan 17, 2008 2:12 PM, Dragan Milenkovic <[EMAIL PROTECTED]> wrote:
> > > > Richard Guenther wrote:
> > > > [snip]
> > > > >> template
> > > > >> struct Foo
> > > > >> {
> > > > >> template
> > > > >> friend void func(const Foo &);
> > > > >> };
> > > > >>
> > > > >> void check(const Foo & x)
> > > > >> {
> > > > >> // Foo weird; // uncomment this line and all works
> > > > >>
> > > > >> func(x);// <-- ERROR
> > > > >> }
> > > > >>
> > > > >>
> > > > >> Tested with gcc 4.0 - 4.3, and all behave the same:
> > > > >>
> > > > >> "error: 'func' was not declared in this scope"
> > > > >>
> > > > >> but it works if you uncomment the weird line.
> > > > >
> > > > > Actually even with the weird line the program is invalid. What are
> > > > > you trying to do? ;)
> > > > >
> > > > > Richard.
> > > >
> > > > Ok... afaik, that func should be defined on that very place where it is
> > > > declared as friend. But could you please elaborate why it is invalid,
> > > > since you made me start questioning my C++ knowledge... :-D
> > >
> > > How should name-lookup find func?
> >
> > It should use argument dependent lookup. This is like the common case
> > of
> >
> > class x
> > {
> > friend x operator+(const& x, const& x) { return x.var + x.var; }
> > };
> >
> > in which x::operator+ is found without taking special action.
>
> Well, first I think you'd need friend-injection or otherwise a global
> decl of the function.
ADL works without friend injection. Look at 3.4.2
[basic.lookup.koenig] in C++98.
> Second I thought argument dependent
> name-lookup only applies to namespaces, not classes.
No.
> EDG rejects this consistently btw.
Well, I'm probably misinterpreting the example. Adding the templates
must change it somehow.
For example, this works fine, even without -ffriend-injection:
class x { friend x operator+(const x& x1, const x& x2); };
x foo(x x1, x x2) { return x1 + x2; }
Ian
Re: A simple sample code involving templates, friends and lookup
On 17 Jan 2008 11:46:52 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>
> "Richard Guenther" <[EMAIL PROTECTED]> writes:
> >
> > Well, first I think you'd need friend-injection or otherwise a global
> > decl of the function.
>
> ADL works without friend injection. Look at 3.4.2
> [basic.lookup.koenig] in C++98.
I did. It says "other _namespaces_ not considered...".
> > Second I thought argument dependent
> > name-lookup only applies to namespaces, not classes.
>
> No.
>
> > EDG rejects this consistently btw.
>
> Well, I'm probably misinterpreting the example. Adding the templates
> must change it somehow.
Well, the actual call to func is not dependent, so it should not affect
name-resolution.
> For example, this works fine, even without -ffriend-injection:
>
> class x { friend x operator+(const x& x1, const x& x2); };
> x foo(x x1, x x2) { return x1 + x2; }
It does, even with EDG.
Well, a language lawyer can probably clear things up. From a look
at the std it looks like w/o a previous declaration the above should
be invalid. And at a different point it suggests the decl becomes
available.
Bah.
Richard.
GCC pretty printer + typedefs
Hi,
I am working on a static analysis plugin for Mozilla. I noticed the the
C++ frontend has a very convenient pretty-printing API exposed through
(decl|type)_as_string. I use decl_as_string() to get string
representations of types. The scripts are interested in both kinds of
types: the type name and the actual type. The API seems to be designed
to provide that, but in reality returned strings contain a mix of the
two, which is problematic for my scripting needs and results in
inconsistent typedef usage in GCC error messages..
Major Issue: Specifying TFF_CHASE_TYPEDEFS as a parameter only works
with top-level typenames because the C/C++ pretty printing code does
not support/propagate the flags parameter. Is this considered a bug or
a TODO? Would a patch to move the TFF* flags into the C frontend be of
interest?
Minor issues:
I think this is a bug, likely a manifestation of the major issue:
typedef int* pint;
pint foo; <-- type_as_string(type, 0) returns "int*"
Is the following behavior intentional?
typedef int t1;
class c{
typedef t1 t2;
t2 v; <-- type_as_string returns "t1".
};
Thanks,
Taras
More info on my plugin: http://wiki.mozilla.org/Dehydra_GCC
Re: My email address has been changed
On Fri, Jan 18, 2008 at 10:20:23AM +1100, Ben Elliston wrote: > > My old email address, [EMAIL PROTECTED], may no longer works. My > > new email address is [EMAIL PROTECTED] > > Don't forget to update the MAINTAINERS file, HJ. > Hi Ben, I updated my email address in MAINTAINERS in gcc, gdb and binutils. Thanks. H.J.
My email address has been changed
Hi, My old email address, [EMAIL PROTECTED], may no longer works. My new email address is [EMAIL PROTECTED] H.J.
Gcc stack alignment branch is created
I created gcc stack alignment branch to implement our proposal to automatically align stack: svn://gcc.gnu.org/svn/gcc/branches/stack I am enclosing the design document here. Joey, Xuepeng and I are working on it. We will start sending patches to gcc-patches with subject "[stack] x". We are targeting it for gcc 4.4. Please send feedbacks to us as well as gcc-patches. We'd like to work with everyone to get it ready for gcc 4.4. If anyone has patches for stack branch, please send them to gcc-patches and CC us. The current status is we have about 38 regressions on Linux/ia32 and Linux/x86-64. Thanks. H.J. -- 0. MOTIVATION -- Some local variables (such as of __m128 type or marked with alignment attribute) require stack aligned at a boundary larger than the default stack boundary. Current GCC partially supports this with limitations. We are proposing a new design to fully solve the problem. -- 1. CURRENT IMPLEMENTATION -- There are two ways current GCC supports bigger than default stack alignment. One is to make sure that stack is aligned at program entry point, and then ensure that for each non-leaf function, its frame size is aligned. This approach doesn't work when linking with libs or objects compiled by other psABI confirming compilers. Some problems are logged as PR 33721. Another is to adjust stack alignment at the entry point of a function if it is marked with __attribute__ ((force_align_arg_pointer)) or -mstackrealign option is provided. This method guarantees the alignment in most of the cases but with following problems and limitations: * Only 16 bytes alignment is supported * Adjusting stack alignment at each function prologue hurts performance unnecessarily, because not all functions need bigger alignment. In fact, commonly only those functions which have SSE variables defined locally (either declared by the user or compiler generated internal temporary variables) need corresponding alignment. * Doesn't support x86_64 for the cases when required stack alignment is > 16 bytes * Emits inefficient and complicated prologue/epilogue code to adjust stack alignment * Doesn't work with nested functions * Has a bug handling register parameters, which resulted in a cpu2006 failure. A patch is available as a workaround. -- 2. NEW PROPOSAL: DESIGN -- Here, we propose a new design to fully support stack alignment while overcoming above problems. The new design will * Support arbitrary alignment value, including 4,8,16,32... * Adjust function stack alignment only when necessary * Initial development will be on i386 and x86_64, but can be extended to other platforms * Emit more efficient prologue/epilogue code * Coexist with special features like dynamic stack allocation (alloca), nested functions, register parameter passing, PIC code and tail call optimization * Be able to debug and unwind stack 2.1 Support arbitrary alignment value Different source code and optimizations requires different stack alignment, as in following table: Feature Alignment (bytes) i386_ABI4 x86_64_ABI 16 char1 short 2 int 4 long4/8* long long 8 __m64 8 __m128 16 float 4 double 8 long double 16 user specified any power of 2 *Note: 4 for i386, 8 for x86_64 The new design will support any alignment value in this table. 2.2 Adjust function stack alignment only when necessary Current GCC defines following macros related to stack alignment: i. STACK_BOUNDARY in bits, which is preferred by hardware, 32 for i386 and 64 for x86_64. It is the minimum stack boundary. It is fixed. ii. PREFERRED_STACK_BOUNDARY. It sets the stack alignment when calling a function. It may be set at command line and has no impact on stack alignment at function entry. This proposal requires PREFERRED >= STACK, and by default set to ABI_STACK_BOUNDARY This design will define a few more macros, or concepts not explicitly defined in code: iii. ABI_STACK_BOUNDARY in bits, which is the stack boundary specified by psABI, 32 for i386 and 128 for x86_64. ABI_STACK_BOUNDARY >= STACK_BOUNDARY. It is fixed for a given psABI. iv. LOCAL_STACK_BOUNDARY in bits. Each function stack has its own stack alignment requirement, which depends the alignment of its stack variables, LOCAL_STACK_BOUNDARY = MAX (alignment of each effective stack variable). v. INCOMING_STACK_BOUNDARY in bits, which is the stack boundary at function entry. If a function is marked with __attribute__ ((force_align_arg_pointer)) or -mstackrealign option is provided, INCOMING = STACK_BOUNDARY. Otherwise, INCOMING == PREFERRED_STACK_BOUNDARY because a function is typically called locally with the same PREFERRED_STACK_BOUNDARY. For those function whose PREFERRED is larger than ABI, it is the caller's responsibility to invoke them with appropriate PREFERRED. vi. REQUIRED_STACK_ALIGNMENT in bits, which is stack alignment required by local variables and calling other f
Re: GCC pretty printer + typedefs
On Thu, 17 Jan 2008, Taras Glek wrote: | Major Issue: Specifying TFF_CHASE_TYPEDEFS as a parameter only works with | top-level typenames because the C/C++ pretty printing code does not | support/propagate the flags parameter. Is this considered a bug or a TODO? | Would a patch to move the TFF* flags into the C frontend be of interest? In the context of C++, this has been discussed many times (especially in the context of template instantiations), but no clear conclusion and implementation strategy came out. If you're going to do this for C++, please make sure that Dave Abrahams (from Boost community) has some input in your strategy. -- Gaby
Re: A simple sample code involving templates, friends and lookup
On 17/01/2008, Richard Guenther wrote: > > Well, a language lawyer can probably clear things up. From a look > at the std it looks like w/o a previous declaration the above should > be invalid. And at a different point it suggests the decl becomes > available. Yes, at the point of instantiation of Foo the friend is declared, and can then be found by ADL because Foo is an associated type. The reference parameter 'x' doesn't cause an instantiation, only 'weird' does. However, see the discussion in section 9.2.2 of Vandevoorde and Josuttis' C++ Templates book and the footnote saying the standard isn't exactly clear. I'm only guessing, but EDG's behaviour could be related to their interpretation of DR329 http://www.open-std.org/jtc1/sc22/wg21//docs/cwg_defects.html#329 I'm not sure which interpretation is correct, but GCC's seems reasonable to me. Jon
Re: A simple sample code involving templates, friends and lookup
On 18/01/2008, Jonathan Wakely <[EMAIL PROTECTED]> wrote: > > Yes, at the point of instantiation of Foo the friend is declared, > and can then be found by ADL because Foo is an associated type. > The reference parameter 'x' doesn't cause an instantiation, only 'weird' does. Forgot the reference - this is 14.6.5 [temp.inject] DR387 fixes some errors in the example, but doesn't change the wording. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#387 Jon
Re: Memory leaks in compiler
On Thu, Jan 17, 2008 at 02:46:12PM -, Dave Korn wrote: > On 16 January 2008 22:09, Diego Novillo wrote: > > > On 1/16/08 4:16 PM, Andrew Haley wrote: > > > >> Because it's not a bug? You're changing the code to silence a false > >> negative, which this is what we here in England call "putting the cart > >> before the horse." If we clean up all the memory regions on closedown > >> we'll be wasting CPU time. And for what? > > > > I agree. Freeing memory right before we exit is a waste of time. > > So, no gcc without an MMU and virtual memory platform ever again? Shame, it > used to run on Amigas. You mean the Amiga didn't automatically free all process memory on termination, the way MS-DOS did (without an MMU and virtual memory platform)? (Unless, of course, you expressly asked for that not to happen, by calling "terminate and stay resident".)
