Re: gcc compiler modification to cater for new programming language
On 14/06/2012 04:05, Chris Jones wrote: David Brown wrote: On 11/06/2012 09:45, Chris Jones wrote: Is it possible to modify the source code of gcc to enable to compilation of a completely new programming language, as yet unrecognized? How much of a big job would I be looking at for such a task? I would think that would depend entirely on the language you want to implement. If your language has similar principles to existing gcc languages, then most of the middle-end and back-end could be left untouched. But if it has major differences, you might need to change gcc in all sorts of difficult places. I guess the best guide here would be to look at the integration of Go into gcc - I believe it is the most recent addition to gcc. You could also consider a stepping stone of making a translator between your new language and C (or C++, D, Go, etc.), then using gcc to compile the C code. It is not going to be optimal, but it could be useful in developing your language, testing the concepts, developing the libraries, etc. And it will also help answer your question - if you can make a reasonably efficient translator to C (using any gcc extensions as needed), then you can expect a reasonably straightforward job in writing a gcc front-end to the language. But if you find concepts that are particularly alien to C, then you are going to have a bigger job writing a gcc front-end. (Note that my opinions here are based on zero experience of developing new languages, just on my thoughts and observations about the processes, having observed the creation and development of a few languages.) So it seems I have two options really. Use a translator to implement my language with gcc. Or I could develop a new front-end for it to integrate it into gcc. Am I right? I don't see these as a choice of two options - I see them as "phase 1" and "phase 2" of making a compiler. You might also want to include a "phase 0", which would be an interpreter. Phase 0 and 1 should be written in a language like Python - performance is totally irrelevant, but you want something that can easily and naturally work with strings, dictionaries (hashes), etc., and can be quickly modified. When you are developing a new language, your main effort has to start with the language - how it is put together, and how it will work in practice. So the bulk of your thoughts for now should go in that direction. You need either an interpreter or a simple language-to-C translator so that you can get a feel for your language in practice - this will be changed over time as you develop the language. Also, my new language is completely written from scratch and is nothing like any other language currently available. http://simpledictionarylanguage.weebly.com It's currently in very early stages and is not yet anything workable, but development is coming along nicely. But I need to know how I'm gonna compile the eventual code with gcc before I get myself in too deep. At least now in the early stages, I can change my development path pretty easily. Worrying about a gcc implementation at this stage is premature. In fact, I would suggest that thinking about being able to compile at all is premature - especially if your language is very unusual. There are many alternatives, including interpretation and byte-compiling for existing virtual machines (JVM, Python PyPy, Perl Parrot, osv.) or your own virtual machine. If you do end up compiling, then gcc is only one option - the other obvious choice would be LLVM. There are also more unusual choices for borrowing an existing compiler, such as the Glasgow Haskell Compiler or the oocaml tools (which might be a better fit if you have functional programming style constructs). I presume that you have more information about your language than is available via that weblink. My thinking is that you should be building up an information site, with background for the language, what problems you see it solving better than existing languages, how the language is structured, example programs, etc. Then it will be possible to give more informed suggestions about the best way to implement it. mvh., David
[Target maintainers]: Please update libjava/sysdep/*/locks.h with new atomic builtins
Hello! I would like to point out that in libjava/sysdep/*/locks.h many targets still implement atomics in assembly. These utility functions can be implemented with new atomic builtins, avoiding quite some compexity. Maintaniers of unconverted targets (m68k, pa, powerpc, s390, sh and sparc) CC'd. Uros.
GCC 4.7.2 Status Report (2012-06-14)
Status == The GCC 4.7.1 release tarballs have been created and are being uploaded to ftp.gnu.org right now. The GCC 4.7 branch is thus open again for regression and documentation fixes. Quality Data Priority # Change from Last Report --- --- P10 P2 74 - 11 P3 14 + 9 --- --- Total88 - 2 Previous Report === http://gcc.gnu.org/ml/gcc/2012-06/msg00060.html
Re: GCC 4.7.2 Status Report (2012-06-14)
2012/6/14 Richard Guenther: > The GCC 4.7.1 release tarballs have been created and are being uploaded > to ftp.gnu.org right now. Tell me please, where I can see a list of changes/fixes for GCC-4.7.1? Thanks! -- Regards, niXman ___ Dual-target(32 & 64 bit) MinGW compilers for 32 and 64 bit Windows: http://sourceforge.net/projects/mingwbuilds/
Re: GCC 4.7.2 Status Report (2012-06-14)
On Thu, Jun 14, 2012 at 2:32 PM, niXman wrote: > 2012/6/14 Richard Guenther: >> The GCC 4.7.1 release tarballs have been created and are being uploaded >> to ftp.gnu.org right now. > > Tell me please, where I can see a list of changes/fixes for GCC-4.7.1? If you look at changes.html for GCC 4.7, at the very end you find a bugzilla search for bugs fixed for 4.7.1. Cut&pasted: http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.7.1 Richard.
GCC 4.7.1 Released
The GNU Compiler Collection version 4.7.1 has been released. GCC 4.7.1 is the first bug-fix release containing important fixes for regressions and serious bugs in GCC 4.7.0 with over 100 bugs fixed since the previous release. This release is available from the FTP servers listed at: http://www.gnu.org/order/ftp.html Please do not contact me directly regarding questions or comments about this release. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank them individually!
RA best is NO_REGS
Hi, I found a problem with my port where IRA generates a spill error. After looking at the logs I get this kind of output for the best class for the pseudo regs: Pass 0 for finding pseudo/allocno costs a2 (r30,l0) best NO_REGS, allocno NO_REGS a3 (r29,l0) best NO_REGS, allocno NO_REGS a4 (r28,l0) best NO_REGS, allocno NO_REGS a5 (r27,l0) best NO_REGS, allocno NO_REGS a0 (r26,l0) best XL_REG, allocno XL_REG a1 (r20,l0) best AL_REG, allocno AL_REG This doesn't look good. Why NO_REGS? Cheers, -- PMatos
Re: RA best is NO_REGS
I forgot to mention this is in 4.7.0. 4.6.3 happily assigns the right classes to the registers. I wonder if there's any new macro in 4.7 that I haven't defined... On 14/06/12 13:47, Paulo J. Matos wrote: Hi, I found a problem with my port where IRA generates a spill error. After looking at the logs I get this kind of output for the best class for the pseudo regs: Pass 0 for finding pseudo/allocno costs a2 (r30,l0) best NO_REGS, allocno NO_REGS a3 (r29,l0) best NO_REGS, allocno NO_REGS a4 (r28,l0) best NO_REGS, allocno NO_REGS a5 (r27,l0) best NO_REGS, allocno NO_REGS a0 (r26,l0) best XL_REG, allocno XL_REG a1 (r20,l0) best AL_REG, allocno AL_REG This doesn't look good. Why NO_REGS? Cheers, -- PMatos
libstdc++ c++98 & c++11 ABI incompatibility
While PR53646 claims that c++98 and c++11 should be ABI
compatible (modulo bugs), the addition of the _M_size member
to std::_List_base::_List_impl makes libraries using
std::list in headers incompatible, when built in c++98 and
c++11 mode. Currently seen in libsigc++ (Signal Framework
for C++) and libapt-pkg (Debian package management).
sigc++/signal_base.h:
struct SIGC_API signal_impl
{
typedef size_t size_type;
typedef std::list slot_list;
typedef slot_list::iterator iterator_type;
typedef slot_list::const_iterator const_iterator_type;
signal_impl();
[...]
apt-pkg/error.h:
class GlobalError
{
[...]
std::list Messages;
bool PendingFlag;
Inline-ing code accessing these members gets the offset wrong.
For apt this probably can be changed so that it works in both
modes, but it gets more difficult for software which is not
controlled by the distribution like libsigc++. I'll check
the archive for more occurrences of such code.
Looking at the build logs for packages built by a distribution,
I see that a lot of packages already build in c++0x/c++11 mode,
while the majority still uses the c++98 default. The GCC
documentation says "Support for C++11 is still experimental,
and may change in incompatible ways in future releases",
however upstream authors already use it by default (e.g.
LibreOffice).
So what could be done for a distribution?
- For this particular issue, ask upstreams to work around this
particular incompatibility. This might work better, if the
upstream sits "closer" to the distribution, but doesn't seem
to be a general solution.
- Identify all libraries with this incompatibility, and build
the library twice for each mode. That would need a new soname
when built in c++11 mode (which better should be done upstream
first), and some logic to link with the c++11 library when
building in c++11 mode. But I don't think that distributions
want to build and maintain a second c++ stack.
- Build all packages in c++98 mode or in c++11 mode. Because
c++11 is still experimental, this would be c++98 mode. But
then c++11-only software would need removal from the
distribution if a dependent library is only available in c++98
mode. Or an internal copy of a library could be built in
c++11 mode.
I currently tend to the latter approach, but would like to get
some feedback about other alternatives.
And is there a way to tell which mode a shared object/an
executable was built for, when just looking at the stripped
or unstripped object?
Matthias
Re: C++98/C++11 ABI compatibility for gcc-4.7
On 31 May 2012 22:35, James Y Knight wrote: > You've missed at least one ABI incompatibility in GCC 4.7 and later, as > demonstrated in real life by (at least) libboost_python, and distilled > into this test case. > > At least these bug reports are probably caused by this ABI incompatibility: > https://svn.boost.org/trac/boost/ticket/6919 That appears to be a strict aliasing violation. Boost.Python has lots of warnings about them when built. > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455 > https://svn.boost.org/trac/boost/ticket/6895 > > As I've said before, I really wish GCC devs would take the ABI > incompatibility problem more seriously. Those two reports and your test case are the same as http://gcc.gnu.org/PR53646 and http://gcc.gnu.org/PR53657 and should be fixable. It might also be the cause of http://gcc.gnu.org/PR53490 (I couldn't reproduce that one so I'm not sure.) It seems to be an inadvertent incompatibility caused by the interaction of a libstdc++ workaround for a bug and g++ behaviour that may not have been known to the libstdc++ devs, so not something that could have been prevented by making it a linker error, because noone knew it was even broken. Testing and reporting bugs and analysing the problem should lead to it being fixed. I think the problem was GCC devs not knowing the problem existed, rather than not taking it seriously.
"self" keyword
How hard would it be to implement a "self" keyword extension which
references the contextual function name wherein it was referenced?
int foo(int a)
{
// recursion
self(a + 1);
}
int food(int a)
{
// recursion
self(a + 1);
}
Obviously not a useful example, but demonstrates that to call each
function it's in again that it can be done without knowing the function
name.
Best regards,
Rick C. Hodgin
crtstuff.c:300: error
Hello All,
I have gcc-4.6.1. Now I am trying to install gcc-3.4.6 for sake of msp430x. I
received many errors. The last one was following:
./crtstuff.c:300: error: syntax error before '{' token
These what I could copy from my terminal:
/usr/include/unistd.h:1019: error: syntax error before "__off64_t"
/usr/include/unistd.h:1020: error: storage class specified for parameter
`truncate64'
/usr/include/unistd.h:1029: error: syntax error before "__off_t"
/usr/include/unistd.h:1029: error: storage class specified for parameter
`ftruncate'
/usr/include/unistd.h:1039: error: syntax error before "__off64_t"
/usr/include/unistd.h:1039: error: storage class specified for parameter
`ftruncate64'
/usr/include/unistd.h:1050: error: storage class specified for parameter `brk'
/usr/include/unistd.h:1050: error: syntax error before "__THROW"
/usr/include/unistd.h:1056: error: syntax error before "__delta"
/usr/include/unistd.h:1056: error: storage class specified for parameter `sbrk'
/usr/include/unistd.h:1071: error: storage class specified for parameter
`syscall'
/usr/include/unistd.h:1071: error: syntax error before "__THROW"
/usr/include/unistd.h:1094: error: syntax error before "__off_t"
/usr/include/unistd.h:1094: error: storage class specified for parameter `lockf'
/usr/include/unistd.h:1104: error: syntax error before "__off64_t"
/usr/include/unistd.h:1104: error: storage class specified for parameter
`lockf64'
/usr/include/unistd.h:1125: error: storage class specified for parameter
`fdatasync'
/usr/include/unistd.h:1134: error: storage class specified for parameter `crypt'
/usr/include/unistd.h:1134: error: syntax error before "__THROW"
/usr/include/unistd.h:1138: error: storage class specified for parameter
`encrypt'
/usr/include/unistd.h:1138: error: syntax error before "__THROW"
/usr/include/unistd.h:1146: error: syntax error before "ssize_t"
/usr/include/unistd.h:1146: error: storage class specified for parameter `swab'
/usr/include/unistd.h:1154: error: storage class specified for parameter
`ctermid'
/usr/include/unistd.h:1154: error: redefinition of parameter 'ctermid'
/usr/include/stdio.h:878: error: previous definition of 'ctermid' was here
/usr/include/unistd.h:1154: error: syntax error before "__THROW"
In file included from /opt/gcc-3.4.6/gcc/include/limits.h:122,
from /opt/gcc-3.4.6/gcc/include/syslimits.h:7,
from /opt/gcc-3.4.6/gcc/include/limits.h:11,
from ./tsystem.h:97,
from ./crtstuff.c:62:
/usr/include/limits.h:145:30: bits/posix1_lim.h: No such file or directory
/usr/include/limits.h:149:30: bits/posix2_lim.h: No such file or directory
/usr/include/limits.h:153:29: bits/xopen_lim.h: No such file or directory
In file included from ./tsystem.h:100,
from ./crtstuff.c:62:
/usr/include/time.h:42:24: bits/time.h: No such file or directory
In file included from ./tsystem.h:100,
from ./crtstuff.c:62:
/usr/include/time.h:104: error: storage class specified for parameter
`__timer_t'
/usr/include/time.h:104: error: syntax error before "timer_t"
/usr/include/time.h:122: error: syntax error before "__time_t"
/usr/include/time.h:124: error: syntax error before '}' token
/usr/include/time.h:152: error: syntax error before '}' token
/usr/include/time.h:165: error: syntax error before '}' token
/usr/include/time.h:180: error: syntax error before "__BEGIN_NAMESPACE_STD"
/usr/include/time.h:186: error: storage class specified for parameter `time_t'
/usr/include/time.h:186: error: syntax error before "time"
/usr/include/time.h:189: error: syntax error before "__time1"
/usr/include/time.h:190: error: storage class specified for parameter `difftime'
/usr/include/time.h:193: error: storage class specified for parameter `time_t'
/usr/include/time.h:193: error: redefinition of parameter 'time_t'
/usr/include/time.h:186: error: previous definition of 'time_t' was here
/usr/include/time.h:193: error: syntax error before "mktime"
/usr/include/time.h:201: error: storage class specified for parameter `strftime'
/usr/include/time.h:201: error: syntax error before "__THROW"
/usr/include/time.h:220: error: syntax error before "__locale_t"
/usr/include/time.h:220: error: storage class specified for parameter
`strftime_l'
/usr/include/time.h:226: error: syntax error before "__locale_t"
/usr/include/time.h:226: error: storage class specified for parameter
`strptime_l'
/usr/include/time.h:237: error: syntax error before '*' token
/usr/include/time.h:237: error: storage class specified for parameter
`localtime'
/usr/include/time.h:248: error: syntax error before '*' token
/usr/include/time.h:249: error: storage class specified for parameter
`localtime_r'
/usr/include/time.h:258: error: syntax error before '*' token
/usr/include/time.h:258: error: storage class specified for parameter `ctime'
/usr/include/time.h:270: error: syntax error before '*' token
/usr/include/time.h:271: error: storage class specified for pa
Re: [Target maintainers]: Please update libjava/sysdep/*/locks.h with new atomic builtins
On Thu, Jun 14, 2012 at 5:41 AM, Uros Bizjak wrote: > Hello! > > I would like to point out that in libjava/sysdep/*/locks.h many > targets still implement atomics in assembly. These utility functions > can be implemented with new atomic builtins, avoiding quite some > compexity. > > Maintaniers of unconverted targets (m68k, pa, powerpc, s390, sh and sparc) > CC'd. Other than cleaning up the ports, is there enough use of gcj, especially on these other architectures, where this matters? - David
Re: "self" keyword
"Rick C. Hodgin" writes:
> How hard would it be to implement a "self" keyword extension which
> references the contextual function name wherein it was referenced?
>
> int foo(int a)
> {
> // recursion
> self(a + 1);
> }
>
> int food(int a)
> {
> // recursion
> self(a + 1);
> }
>
> Obviously not a useful example, but demonstrates that to call each
> function it's in again that it can be done without knowing the
> function name.
I assume you are asking about C? It would be easy to implement. The
compiler always know what function it is compiling. But I don't think
the extension would be accepted back into GCC mainline.
Ian
Re: crtstuff.c:300: error
Mohammad Katmawi writes: > I have gcc-4.6.1. Now I am trying to install gcc-3.4.6 for sake of msp430x. I > received many errors. The last one was following: This message is not appropriate for the mailing list gcc@gcc.gnu.org, which is about the development of GCC itself. It would be appropriate for gcc-h...@gcc.gnu.org. Please take any followups to gcc-help. Thanks. In order to answer your question, we need to see the first error lines, not the last. Direct your build output to a log file so that you can find that. Ian
Re: "self" keyword
Ian,
I was thinking C and C++.
int myclass::foo(int a)
{
// recursion
self(a + 1);
}
Just out of curiosity, why wouldn't it be accepted back into mainline?
Thanks for your help. :-)
Best regards,
Rick C. Hodgin
On 06/14/2012 12:48 PM, Ian Lance Taylor wrote:
"Rick C. Hodgin" writes:
How hard would it be to implement a "self" keyword extension which
references the contextual function name wherein it was referenced?
int foo(int a)
{
// recursion
self(a + 1);
}
int food(int a)
{
// recursion
self(a + 1);
}
Obviously not a useful example, but demonstrates that to call each
function it's in again that it can be done without knowing the
function name.
I assume you are asking about C? It would be easy to implement. The
compiler always know what function it is compiling. But I don't think
the extension would be accepted back into GCC mainline.
Ian
Re: "self" keyword
FWIW "self" today is a perfectly good variable name, and practically all
C and C++ code that interacts with Python (including the C
implementation of Python itself) uses "self" to name variables
throughout: many thousands of projects, many millions of lines of code.
Having this snatched away as a keyword under some compiler settings
would be a major PITA.
On Thu, 2012-06-14 at 12:53 -0400, Rick C. Hodgin wrote:
> Ian,
>
> I was thinking C and C++.
>
> int myclass::foo(int a)
> {
> // recursion
> self(a + 1);
> }
>
> Just out of curiosity, why wouldn't it be accepted back into mainline?
>
> Thanks for your help. :-)
>
> Best regards,
> Rick C. Hodgin
>
> On 06/14/2012 12:48 PM, Ian Lance Taylor wrote:
> > "Rick C. Hodgin" writes:
> >
> >> How hard would it be to implement a "self" keyword extension which
> >> references the contextual function name wherein it was referenced?
> >>
> >> int foo(int a)
> >> {
> >> // recursion
> >> self(a + 1);
> >> }
> >>
> >> int food(int a)
> >> {
> >> // recursion
> >> self(a + 1);
> >> }
> >>
> >> Obviously not a useful example, but demonstrates that to call each
> >> function it's in again that it can be done without knowing the
> >> function name.
> > I assume you are asking about C? It would be easy to implement. The
> > compiler always know what function it is compiling. But I don't think
> > the extension would be accepted back into GCC mainline.
> >
> > Ian
> >
Re: "self" keyword
David,
Oh! Well, it doesn't have to be called self. :-) It could be __self__
or whatever would be fine. I see C99 has __FUNC__ for the current
function name used in strings. But, I was thinking more of an actual
reference to the current function as a function entity, sort of like a
name substitution.
Best regards,
Rick C. Hodgin
On 06/14/2012 01:08 PM, David Malcolm wrote:
FWIW "self" today is a perfectly good variable name, and practically all
C and C++ code that interacts with Python (including the C
implementation of Python itself) uses "self" to name variables
throughout: many thousands of projects, many millions of lines of code.
Having this snatched away as a keyword under some compiler settings
would be a major PITA.
On Thu, 2012-06-14 at 12:53 -0400, Rick C. Hodgin wrote:
Ian,
I was thinking C and C++.
int myclass::foo(int a)
{
// recursion
self(a + 1);
}
Just out of curiosity, why wouldn't it be accepted back into mainline?
Thanks for your help. :-)
Best regards,
Rick C. Hodgin
On 06/14/2012 12:48 PM, Ian Lance Taylor wrote:
"Rick C. Hodgin" writes:
How hard would it be to implement a "self" keyword extension which
references the contextual function name wherein it was referenced?
int foo(int a)
{
// recursion
self(a + 1);
}
int food(int a)
{
// recursion
self(a + 1);
}
Obviously not a useful example, but demonstrates that to call each
function it's in again that it can be done without knowing the
function name.
I assume you are asking about C? It would be easy to implement. The
compiler always know what function it is compiling. But I don't think
the extension would be accepted back into GCC mainline.
Ian
Re: "self" keyword
"Rick C. Hodgin" writes:
> I was thinking C and C++.
>
> int myclass::foo(int a)
> {
> // recursion
> self(a + 1);
> }
>
> Just out of curiosity, why wouldn't it be accepted back into mainline?
In general these days GCC discourages language extensions. They would
have to have a compelling advantage. I don't see that here. Even if I
did, I would recommend running it through a language standards body
first.
Ian
RE: "self" keyword
It only saves one character in any case: your "self" is just "*this".
From: gcc-ow...@gcc.gnu.org [gcc-ow...@gcc.gnu.org] on behalf of Ian Lance
Taylor [i...@google.com]
Sent: Thursday, June 14, 2012 10:19 AM
To: Rick C. Hodgin
Cc: gcc@gcc.gnu.org
Subject: Re: "self" keyword
"Rick C. Hodgin" writes:
> I was thinking C and C++.
>
> int myclass::foo(int a)
> {
> // recursion
> self(a + 1);
> }
>
> Just out of curiosity, why wouldn't it be accepted back into mainline?
In general these days GCC discourages language extensions. They would
have to have a compelling advantage. I don't see that here. Even if I
did, I would recommend running it through a language standards body
first.
Ian
Re: "self" keyword
On 14/06/12 19:31, Joe Buck wrote:
It only saves one character in any case: your "self" is just "*this".
No, "this" points to the object in C++. The OP's "self" is referring to
the function being compiled. So here "self" would be the same as "foo".
I don't think there is any way to get this without making a language
extension, unless there is some way of turning the string __FUNC__ into
the function. But I also don't see any advantage over simply using the
function name directly. After all, how often do you need recursion -
and what is the problem with writing out the function name in full on
those occasions?
mvh.,
David
From: gcc-ow...@gcc.gnu.org [gcc-ow...@gcc.gnu.org] on behalf of Ian Lance
Taylor [i...@google.com]
Sent: Thursday, June 14, 2012 10:19 AM
To: Rick C. Hodgin
Cc: gcc@gcc.gnu.org
Subject: Re: "self" keyword
"Rick C. Hodgin" writes:
I was thinking C and C++.
int myclass::foo(int a)
{
// recursion
self(a + 1);
}
Just out of curiosity, why wouldn't it be accepted back into mainline?
In general these days GCC discourages language extensions. They would
have to have a compelling advantage. I don't see that here. Even if I
did, I would recommend running it through a language standards body
first.
Ian
Re: C++98/C++11 ABI compatibility for gcc-4.7
On Thursday 31 of May 2012 22:58:32 Jonathan Wakely wrote: > On 31 May 2012 22:39, Jonathan Wakely wrote: > > On 31 May 2012 22:35, James Y Knight wrote: > >> I understand that the ABI changes generally cannot be avoided, but a lot > >> of pain for a lot of people could be avoided by making things fail > >> obviously with a link error, instead of sometimes, arbitrarily, if you're > >> lucky, you'll get a segfault at runtime. > > > > Do you have any suggestions for how to do that? > > ... *without* breaking the current ABI, because if we weren't trying > to keep it stable it would be much easier. > > If you want to you can configure with > --enable-symvers=gnu-versioned-namespace and test that mode, which > would allow everything to be put in something like std::__cxx2011::__8 > for -std=c++11 mode, but AFAICT only one person seems to be trying > that option out and giving feedback on it. the versioned namespace doesn't solve all problems. if you put c++11/std::list in the e.g., std::__8 namespace then you trig a nice linker error for incompatible objects that passes std::list as a function argument but std::list used as a return type won't be catched (return type is not mangled in function symbol). from the others side, someone can use -frecord-gcc-switches to detect mixed '-std=...' after final linking and report error in such cases.
Re: "self" keyword
David,
Well, I probably don't have a NEED for it. I've gotten along for 25+
years without it. :-)
However, what prompted my inquiry is using it would've saved me tracking
down a few bugs in recent weeks. Some prior code was re-used for a
similar function, but the name of the recursive calls weren't updated in
every case. It didn't take long to debug, but I realized that had it
always been written as self() it never would've been an issue.
I can also see a use for generated code where there's a base source code
template in use with an embedded include file reference that changes as
it's generated per pass, such as:
int step1(int a, int b)
{
#include "\current_task\step1.cpp"
}
int step2(int a, int b)
{
#include "\current_task\step2.cpp"
}
Using the self() reference for recursion, one could modify stepN.cpp's
generator algorithms without having to know or care anything in the
wrapper code. Likewise, the wrapper could be modified without having to
concern itself with anything in the generated code, save some
requirements of an API like a "print_notice()" or "print_error()"
message function, which could just be a requirement of the app to always
be there. The rest, however, could be fluid.
A few other uses I can think of as well. Minor ones.
Best regards,
Rick C. Hodgin
On 06/14/2012 04:24 PM, David Brown wrote:
On 14/06/12 19:31, Joe Buck wrote:
It only saves one character in any case: your "self" is just "*this".
No, "this" points to the object in C++. The OP's "self" is referring
to the function being compiled. So here "self" would be the same as
"foo".
I don't think there is any way to get this without making a language
extension, unless there is some way of turning the string __FUNC__
into the function. But I also don't see any advantage over simply
using the function name directly. After all, how often do you need
recursion - and what is the problem with writing out the function name
in full on those occasions?
mvh.,
David
From: gcc-ow...@gcc.gnu.org [gcc-ow...@gcc.gnu.org] on behalf of Ian
Lance Taylor [i...@google.com]
Sent: Thursday, June 14, 2012 10:19 AM
To: Rick C. Hodgin
Cc: gcc@gcc.gnu.org
Subject: Re: "self" keyword
"Rick C. Hodgin" writes:
I was thinking C and C++.
int myclass::foo(int a)
{
// recursion
self(a + 1);
}
Just out of curiosity, why wouldn't it be accepted back into mainline?
In general these days GCC discourages language extensions. They would
have to have a compelling advantage. I don't see that here. Even if I
did, I would recommend running it through a language standards body
first.
Ian
Re: C++98/C++11 ABI compatibility for gcc-4.7
On 06/14/2012 02:33 PM, Paweł Sikora wrote: from the others side, someone can use -frecord-gcc-switches to detect mixed '-std=...' after final linking and report error in such cases. Given that we have -fabi= to go along with the -std= options, ISTM that we'd really be better off recording the ABI information in its own section rather than pull it out of the options section and that doing so should be the default rather than contingent on user options. We'd then want some linker support to warn/error when attempts to mix-n-match are made. jeff
Re: "self" keyword
"Rick C. Hodgin" writes:
> I can also see a use for generated code where there's a base source code
> template in use with an embedded include file reference that changes as
> it's generated per pass, such as:
>
> int step1(int a, int b)
> {
#define self step1
> #include "\current_task\step1.cpp"
#undef self
> }
>
> int step2(int a, int b)
> {
#define self step2
> #include "\current_task\step2.cpp"
#undef self
> }
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: "self" keyword
Andreas,
That would work. But now I'm back to remembering to fix something when
I copy / re-use code.
I'll admit it's minor. But we have tools to help us for a reason,
right? :-)
Best regards,
Rick C. Hodgin
On 06/14/2012 04:38 PM, Andreas Schwab wrote:
"Rick C. Hodgin" writes:
I can also see a use for generated code where there's a base source code
template in use with an embedded include file reference that changes as
it's generated per pass, such as:
int step1(int a, int b)
{
#define self step1
#include "\current_task\step1.cpp"
#undef self
}
int step2(int a, int b)
{
#define self step2
#include "\current_task\step2.cpp"
#undef self
}
Andreas.
Re: "self" keyword
On Thu, 2012-06-14 at 16:34 -0400, Rick C. Hodgin wrote:
> David,
>
> Well, I probably don't have a NEED for it. I've gotten along for 25+
> years without it. :-)
>
> However, what prompted my inquiry is using it would've saved me tracking
> down a few bugs in recent weeks. Some prior code was re-used for a
> similar function, but the name of the recursive calls weren't updated in
> every case. It didn't take long to debug, but I realized that had it
> always been written as self() it never would've been an issue.
>
> I can also see a use for generated code where there's a base source code
> template in use with an embedded include file reference that changes as
> it's generated per pass, such as:
>
> int step1(int a, int b)
> {
> #include "\current_task\step1.cpp"
> }
>
> int step2(int a, int b)
> {
> #include "\current_task\step2.cpp"
> }
>
> Using the self() reference for recursion, one could modify stepN.cpp's
> generator algorithms without having to know or care anything in the
> wrapper code.
Wouldn't this do?
#define __self__ step1
int __self__ (int a, int b)
{
#include "something"
__self__ (x, y);
}
#undef __self__
Cheers,
Oleg
C++ Expression Template Benchmarks for GCC/Clang/Intel/PGI/MSVC
Hello Everyone, I thought you might be interested in some C++ expression template benchmarks I have done. http://www.wlandry.net/Projects/FTensor#Benchmarks I found that GCC optimized the expression template code better than unrolling expressions by hand. In fact, GCC was far, far better at optimizing code with expression templates than any other compiler. I ran the same benchmarks back in 2003, and GCC has improved quite a lot since then. Cheers, Walter Landry wlan...@caltech.edu
gcc-4.5-20120614 is now available
Snapshot gcc-4.5-20120614 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20120614/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 188638 You'll find: gcc-4.5-20120614.tar.bz2 Complete GCC MD5=ca59a86c7442e0d5481aa3fdfc40fa19 SHA1=608b63dd82148fcb8ebec97c3a4cde94d5890b06 Diffs from 4.5-20120607 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 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: libstdc++ c++98 & c++11 ABI incompatibility
On 06/14/2012 06:14 AM, Matthias Klose wrote: While PR53646 claims that c++98 and c++11 should be ABI compatible (modulo bugs), the addition of the _M_size member to std::_List_base::_List_impl makes libraries using std::list in headers incompatible, when built in c++98 and c++11 mode. So it does. That change should not have gone into 4.7 without having a plan to deal with the consequences. I thought we weren't going to mess with ABI-breaking changes like this yet... Jason
Re: libstdc++ c++98 & c++11 ABI incompatibility
On 14 June 2012 14:14, Matthias Klose wrote: > So what could be done for a distribution? > > - For this particular issue, ask upstreams to work around this > particular incompatibility. This might work better, if the > upstream sits "closer" to the distribution, but doesn't seem > to be a general solution. > > - Identify all libraries with this incompatibility, and build > the library twice for each mode. That would need a new soname > when built in c++11 mode (which better should be done upstream > first), and some logic to link with the c++11 library when > building in c++11 mode. But I don't think that distributions > want to build and maintain a second c++ stack. Or bump the libstdc++ soname and add the size member to std::list in c++98 mode too. I don't see that being a popular choice yet, but it is likely to happen eventually.
