Re: ISO_IEC_14882-2011-5.1.2/10 - bug
Hi > Hello. > > Quote from ISO_IEC_14882-2011, 5.1.2/10: Please open a normal Bugzilla PR Thanks, Paolo
Re: The AST tree modification. Edited.
Up. 2011/10/12 niXman : > Hello! > > I have figured out the creation of functions and structures, thanks > Andi's and Balaji's. Couldn't understand how to create tree for > template functions, classes, methods. > Can you help me figure that out, please? > > Thanks. >
asm in inline function invalidating function attributes?
I think gcc should allow the programmer to tell it something about a
function return value even if the function is inlined and the compiler
can see all the code. Consider the code below.
If NOINLINE is defined the compiler will call g once. No need to do
anything after the h() call since the function is marked const.
If NOINLINE is not defined and the compiler sees the asm statement it
will expand the function body twice. Don't worry about the content of
the asm, this is correct in the case I care about. What I expect is
that gcc still respects that the function is marked const and performs
the same optimization as in the case when the function is not inlined.
Is there anything I miss how to achieve this? I don't think so in
which case, do people agree that this should be changed?
extern int **g(void) __attribute__((const, nothrow));
#ifndef NOINLINE
extern inline int ** __attribute__((always_inline, const, nothrow,
gnu_inline, artificial)) g(void) {
int **p;
asm ("call g@plt" : "=a" (p));
return p;
}
#endif
#define pr(c) ((*g())[c] & 0x80)
extern void h(void);
int
f(const char *s)
{
int c = 0;
for (int i = 0; i < 20; ++i)
c |= pr(s[i]);
h();
for (int i = 20; i < 40; ++i)
c |= pr(s[i]);
return c;
}
gcc-4.7-20111015 is now available
Snapshot gcc-4.7-20111015 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20111015/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 180048 You'll find: gcc-4.7-20111015.tar.bz2 Complete GCC MD5=236d8300ad8b3db0489632aa13da3672 SHA1=fadfd1813ae7b0022b3de36be3908a4fa74b9fcf Diffs from 4.7-20111008 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.7 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.
RFC: Add --plugin-gcc option to ar/nm
Hi, ---plugin option for ar/nm is very long. I am proposing to add a --plugin-gcc option. It can be implemented with 1. Move LTOPLUGINSONAME from gcc to config/plugins.m4. 2. Define LTOPLUGINSONAME for ar/nm. 3. For --plugin-gcc, ar/nm call popen using environment variable GCC if set, or gcc with -print-prog-name=$LTOPLUGINSONAM to get plugin name. Any comments? -- H.J.
Re: RFC: Add --plugin-gcc option to ar/nm
"H.J. Lu" writes: > Hi, > > ---plugin option for ar/nm is very long. I am proposing to add > a --plugin-gcc option. It can be implemented with > > 1. Move LTOPLUGINSONAME from gcc to config/plugins.m4. > 2. Define LTOPLUGINSONAME for ar/nm. > 3. For --plugin-gcc, ar/nm call popen using environment variable GCC if set, > or gcc with -print-prog-name=$LTOPLUGINSONAM to get > plugin name. > > Any comments? I had some old patches for gcc-ar, gcc-nm etc. That's similar how other compilers do it. http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02471.html With that it doesn't matter how long the option is. The original feedback was that shell wrapper were not portable enough. I actually did C based wrappers recently, but haven't submitted them yet. I think wrappers are preferable over shorter options because they are easier to use and easier to fit into existing makefiles. The best long term direction probably would be to put a reference to the plugin into the object files and let BFD find it itself. This would be most compatible with existing Makefiles. But that would need more work. -andi -- a...@linux.intel.com -- Speaking for myself only
