Re: Handling of extern inline in c99 mode
I'm not subscribed to this list, I just noticed this discussion while browsing around... Don't know if the list accept non-subscriber messages either, but let's see: Ian Lance Taylor wrote: > codesearch.google.com finds about 6000 uses of "extern line" in > code written in C, but the search > inline -static -extern -# lang:c file:\.c$ > finds only 100 occurrences (...) Because you don't search for "inline" declarations with no "static" nor "extern", but files with "inline" which contain no "static" nor "extern" _anywhere_ in the file, if I understand codesearch correctly. One wish for whatever happens with "inline": Please document what #if tests one should put in a portable (non-GNU:-) program in order to (a) get the intended operation of gcc 'inline' and (b) not drown the program's users in warning messages. In this regard, 'inline' which behaves differently with -std=c99 and gnu99 will make for a more complicated test. So will introducing the change - even just the default warning - in many branches at once. A new -Wno-inline-warning option would not help either, since older gcc versions will complain about the new option. Maybe you should #define __gcc_gnu_inline__ and __gcc_c99_inline__ as the proper attribute/keyword so that a program can #ifdef on them. I wonder what "-pedantic" should do about "inline"? I've seen many people use "-pedantic" without "-std"/"-ansi", because on many systems the latter break some header files. -- Regards, Hallvard
conditional assigments vs. "may be used uninitialized"
Info node (gcc)Warning Options mentions that gcc warns about
int save_y;
if (change_y) save_y = y, y = new_y;
...
if (change_y) y = save_y;
However that's not always true, so it looks like gcc does have
the smarts to drop the warning. Could that be improved?
gcc -W -O does not warn about this snippet, but it does warn with
-DMACRO or -O2. So it looks like the information that this code
is safe is available but not used.
#define foo(x) (x < 3 ? 0 : x)
#ifndef MACRO
int (foo)(int x) { return foo(x); }
#undef foo
#endif
int bar(int y, const int change_y)
{
int save_y;
if (change_y) save_y = y, y = -y;
y = foo(y);
if (change_y) y = save_y;
return y;
}
gcc 4.3.2 on x86_64-unknown-linux-gnu.
--
Hallvard
optimizer hints for critical sections
It would be nice to have optimizer hints useful for critical sections - sections that should be optimized at the expense of code surrounding it. pthread_mutex_lock(&m); critical section; pthread_mutex_unlock(&m); Things like spilling registers, .p2align, jumps that the compiler need to insert etc, should here preferably be outside the critical section. I imagine this could be done by giving pthread_mutex_lock() weak variants of __attribute__((cold)) before the function and ((hot)) after, and the inverse for pthread_mutex_unlock(). Whether an exit point is hot or not can depend on the result code though. E.g. pthread_mutex_trylock(&m) would be hot only when returning 0. Well, so is pthread_mutex_lock, but there it makes sense to default to "hot" if the error code is not checked or if the compiler cannot figure out how the error code is used. Such a default is likely wrong for trylock. -fprofile-use may not work right for these optimizations. If anything, it may pessimize a critical section which is not entered often because the surrounding code works at avoiding entry into it. __builtin_expect() may not help either since it is not branches at the function call as such that need to be optimized, but also e.g. where to insert an unconditional jump which needs to be put somewhere - inside or outside the critical section, regardless of branches or no branches. The compiler already can optimize entry into the critical section somewhat if the program branches on whether entry succeeded. Does not help near exit from a critical section though. And it would be nice to optimize it when there is no profile data or __builtin_expect. These hints should not be too strong - do not pessimize too much at the outside of the critical section, since there may be nested critical sections. There are some other cases which could use this too. E.g. execvp() is likely "cold" on return but not on entry. The manual suggests e.g. perror could be "cold", but that's not right for the branch leading up to execvp - since it's just the return which is unlikely. In that regard, it'd also be useful to have an attribute or something which just cancels out __attribute__((cold)) but does not make anything "hot". -- Hallvard
gcc participation in C standards process
Thread "What's the deal with C99?" in comp.lang.c discusses the C99 standard, and people are among other things speculating about why gcc was never represented in the committee. I'd be interesting if you'd reply there, e.g. to to message <[EMAIL PROTECTED]> from lawrence.jones in the C committee: > (...) I suspect it's the usual open source problem: no one is > sufficiently interested to do it on their own and it's not a high > enough priority for the steering committee to encourage/direct someone > to do it. (...) Searching the gcc.gnu.org site I found a few anti-C-committe postings from apparent C++ committee members, but not much else. Another exchange from the thread: Paul Hsieh (criticizing the C99 standard and the committee): > Well, in the case of gcc, apparently the variable length arrays are > fatal, because some critical amount of the code out there that uses > gcc relies on the specific gcc semantics which conflict with C99's > VLAs. Jones: > It's interesting to note that GCC is the only major compiler that has > never been represented in the standardization process. I consider that > a major loss for GCC, the C standard, and the C community in general. Hsieh: > I agree. So what the hell is the committee planning on doing about > it? Jones: > That's not the committee's job. In fact, it would probably go against > the rules. Participation is open to all, but actively soliciting one > vendor would open the committee to complaints from other vendors who > were not solicited and raise questions about the fairness of the > process. -- Hallvard
