Re: __sync_sychronize on ARM
On Mon, Jan 30, 2012 at 6:56 AM, Jon Masters wrote: > The __sync_synchronize "legacy" sync function is intended to be used to > perform an expensive data memory barrier operation. It is defined within > libgcc in such a way that I *believe* means that, on most architectures, > it is replaced with an inline assembly code emitted that performs a sync > operation. On ARM, and some other architectures with mixed ISAs wherein > there may not be a sync function nor one way to do this, this function > (__sync_synchronize) can be a real function call. In that case, it might > cause inline assembly generation, or e.g. call a kernel VDSO helper. On ARM we don't have a kernel VDSO , sync_synchronize for older versions of the architecture ( anything prior to armv6k) should result in a call to sync_synchronize in libgcc.a which should take care of calling the kernel helper function. Therefore I'm assuming this is a breakage you face when building for armv5te > > The icu package contains a direct call to __sync_sychronize, especially > in the iotest test cases. I believe that this compiles fine on x86 > because there is no function call. However, on ARM, the code fails to > link because the __sync_synchronize function is HIDDEN and not exported > (or so goes my understanding - is that correct?). No, the HIDDEN shouldn't cause a link failure in this case - you should be able to pull this in when you link against the static libgcc where this should be defined. I don't know what your linker command line is so maybe that's a place to start investigating from. cheers Ramana
[AVR,committed]: out_movqi_mr_r: Fix length computation
This patchlet fixes length computation of "std %0,%1" and "st %0,%1" that
reported 2 instead of 1. The reason is that the insn length was accumulated and
added to the length of 1 already set in the caller.
These length are unconditionally set to 1 now because there is no code emit
before these instructions and there is no need to accumulate lengths.
Johann
* config/avr/avr.c (out_movqi_mr_r): Fix length computation.
Index: config/avr/avr.c
===
--- config/avr/avr.c(revision 183695)
+++ config/avr/avr.c(working copy)
@@ -3838,10 +3838,10 @@ out_movqi_mr_r (rtx insn, rtx op[], int
return "";
}
- return avr_asm_len ("std %0,%1", op, plen, 1);
+ return avr_asm_len ("std %0,%1", op, plen, -1);
}
- return avr_asm_len ("st %0,%1", op, plen, 1);
+ return avr_asm_len ("st %0,%1", op, plen, -1);
}
static const char*
Re: expected '=', ',', ';', 'asm' or '__attribute__' before 'foo'
Miles Bader wrote:
> Chris Lattner writes:
>>> Int foo (void) { return 1; }
>>>
>>> A message like
>>> error: expected '=', ',', ';', 'asm' or '__attribute__' before 'foo'
>>>
>>> is just pain to the eyes, and apart from that it is not more helpful
>>> than a simple "syntax error before 'foo':
>> FWIW, Clang produces:
>>
>> t.c:1:1: error: unknown type name 'Int'; did you mean 'int'?
>> Int foo (void)
>
> gcc 4.6 (and later) produces a more reasonable message:
>
>$ gcc-4.6 -c e.c
>e.c:1:1: error: unknown type name ‘Int’
>
> I suspect the OA has an older version of gcc...
Ya, with a freshly built 4.7 the message is really good now, but with a slight
different typo the message is still there:
Int 2 foo (void)
{
return 1;
}
or here:
int foo 1(void)
{
return 1;
}
So the pain-to-the-eyes diagnose is still hanging around in the sources of
GNU C (GCC) version 4.7.0 20120130 (experimental) (avr)
Johann
>
> -Miles
>
Re: Dealing with compilers that pretend to be GCC
Hello, Chris Lattner skribis: > On Jan 20, 2012, at 5:24 PM, Jonathan Wakely wrote: > >> On 21 January 2012 00:32, Vincent Lefevre wrote: >>> On 2012-01-20 23:28:07 +, Jonathan Wakely wrote: May I politely suggest that this is the wrong place to complain about other compilers pretending to be GCC :) >>> >>> I think that's the fault of GCC, which should have defined a macro >>> for each extension. >> >> And what about the fact other compilers haven't defined such a macro >> for each extension they implement, whether it comes from GCC or not, >> is that GCC's fault too? > > If fact, some do: > http://clang.llvm.org/docs/LanguageExtensions.html#feature_check That seems like a very useful approach to solve the problem. The docs say that ‘__has_builtin’ & co. are macros. What do they expand to? Thanks, Ludo’.
Re: __sync_sychronize on ARM
Hi Ramana, Thanks very much for getting back to me! On Mon, 2012-01-30 at 08:50 +, Ramana Radhakrishnan wrote: > On Mon, Jan 30, 2012 at 6:56 AM, Jon Masters wrote: > > The __sync_synchronize "legacy" sync function is intended to be used to > > perform an expensive data memory barrier operation. It is defined within > > libgcc in such a way that I *believe* means that, on most architectures, > > it is replaced with an inline assembly code emitted that performs a sync > > operation. On ARM, and some other architectures with mixed ISAs wherein > > there may not be a sync function nor one way to do this, this function > > (__sync_synchronize) can be a real function call. In that case, it might > > cause inline assembly generation, or e.g. call a kernel VDSO helper. > > On ARM we don't have a kernel VDSO You're right of course! I was confusing the VDSO-like user mode mapped helpers (Documentation/arm/kernel_user_helpers.txt) with full VDSO. I apologize for my mistake. Nonetheless, I believe for the purposes of this thread, we can consider the behavior I described roughly consistent with reality, because a kernel helper will be called in a VDSO-like way. > sync_synchronize for older versions of > the architecture ( anything prior to armv6k) should result in a call > to sync_synchronize > in libgcc.a which should take care of calling the kernel helper function. This is what's confusing me :) Is one supposed (from some random source) to be calling __sync_synchronize or sync_synchronize? Convention suggests the latter, but I was sufficiently confused by the aliasing of the names in the source vs. the documentation, so I'd like to ask you :) > Therefore I'm assuming this is a breakage you face when building for > armv5te It is indeed. Thanks for noting that. > > The icu package contains a direct call to __sync_sychronize, especially > > in the iotest test cases. I believe that this compiles fine on x86 > > because there is no function call. However, on ARM, the code fails to > > link because the __sync_synchronize function is HIDDEN and not exported > > (or so goes my understanding - is that correct?). > > No, the HIDDEN shouldn't cause a link failure in this case - you > should be able to pull this > in when you link against the static libgcc where this should be defined. > > I don't know what your linker command line is so maybe that's a place > to start investigating from. Thanks! You're the second person to suggest that, so I'll look some more. Could you let me know about the correct function name, above? Appreciate the help. Jon.
Re: __sync_sychronize on ARM
On 01/30/2012 05:26 PM, Jon Masters wrote: > > On Mon, 2012-01-30 at 08:50 +, Ramana Radhakrishnan wrote: > >> Therefore I'm assuming this is a breakage you face when building for >> armv5te > > It is indeed. Thanks for noting that. > >>> The icu package contains a direct call to __sync_sychronize, especially >>> in the iotest test cases. I believe that this compiles fine on x86 >>> because there is no function call. However, on ARM, the code fails to >>> link because the __sync_synchronize function is HIDDEN and not exported >>> (or so goes my understanding - is that correct?). >> >> No, the HIDDEN shouldn't cause a link failure in this case - you >> should be able to pull this >> in when you link against the static libgcc where this should be defined. >> >> I don't know what your linker command line is so maybe that's a place >> to start investigating from. There has been a bug in the past where /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.6.1/libgcc_s.so was not a linker script, but a shared library or a symlink. That bug definitely would cause the problem you're seeing. libgcc_s.so must be a script. You can get a linker map with the option -Wl,-Map,mapfile This would be very useful. > Thanks! You're the second person to suggest that, so I'll look some > more. Could you let me know about the correct function name, above? The official documented builtin is __sync_synchronize () Andrew.
Re: Dealing with compilers that pretend to be GCC
On Jan 30, 2012, at 7:56 AM, Ludovic Courtès wrote: > Hello, > > Chris Lattner skribis: > >> On Jan 20, 2012, at 5:24 PM, Jonathan Wakely wrote: >> >>> On 21 January 2012 00:32, Vincent Lefevre wrote: On 2012-01-20 23:28:07 +, Jonathan Wakely wrote: > May I politely suggest that this is the wrong place to complain about > other compilers pretending to be GCC :) I think that's the fault of GCC, which should have defined a macro for each extension. >>> >>> And what about the fact other compilers haven't defined such a macro >>> for each extension they implement, whether it comes from GCC or not, >>> is that GCC's fault too? >> >> If fact, some do: >> http://clang.llvm.org/docs/LanguageExtensions.html#feature_check > > That seems like a very useful approach to solve the problem. > > The docs say that ‘__has_builtin’ & co. are macros. What do they expand to? 0 or 1. -Chris
RESOLVED - Re: __sync_sychronize on ARM
Hello everyone, Just a quick followup. This problem is now resolved. There is no breakage in gcc, just a problem in the Fedora icu package. That package contains some sed scripts in the "SPEC" (build description meta) file that intentionally were munging the Makefiles used to build ICU such that "nostdlib" was being given to gcc and it was never using libgcc. The intention of the person who made this change apparently was to prevent linking the standard math library into icu, but unfortunately a rather unusual solution was chosen. On some systems, one can almost get away with this because __sync_synchronize happens to be implemented in such a fashion that it is optimized into inline emitted assembly. On ARM, that isn't the case. In addition, it is likely that telling GCC not to link in core libraries like libgcc will lead to other breakage later. I have requested the package be fixed to remove the sed scripts and have temporarily (just to solve our problem in the Fedora ARM community) had "-lgcc" added to the linker flags as a very hackish solution for today. Thanks for the replies, and I apologize for the noise. I have learned a great deal about gcc atomics over the past few days. I have also learned that debugging packages requires that you build the package *exactly* as it is in the spec file, not just by running configure/make as therein ;) Jon.
Assignment to volatile objects
Now that the new C standard is out, is there any chance that gcc's behaviour regarding to volatile lhs in an assignment changes? This is what it does today: volatile int a, b; a = b = 0; translates to b = 0; a = b; because the standard (up to and including C99) stated that the value of the assignment operator is the value of the lhs after the assignment. The C11 standard says the same but then it explicitely states that the compiler does not have to read back the value of the lhs, not even when the lhs is volatile. So it is actually legal now not to read back the lhs. Is there a chance for the compiler to get a switch which would tell it explicitely not to read the value back? Zoltan
RE: Assignment to volatile objects
I would prefer this to generate a warning. The C language standard change you refer to is a classic example of a misguided change, and any code whose behavior depends on this deserves a warning message, NOT an option to work one way or the other. paul -Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Zoltán Kócsi Sent: Monday, January 30, 2012 5:03 PM To: gcc@gcc.gnu.org Subject: Assignment to volatile objects Now that the new C standard is out, is there any chance that gcc's behaviour regarding to volatile lhs in an assignment changes? This is what it does today: volatile int a, b; a = b = 0; translates to b = 0; a = b; because the standard (up to and including C99) stated that the value of the assignment operator is the value of the lhs after the assignment. The C11 standard says the same but then it explicitely states that the compiler does not have to read back the value of the lhs, not even when the lhs is volatile. So it is actually legal now not to read back the lhs. Is there a chance for the compiler to get a switch which would tell it explicitely not to read the value back? Zoltan
Re: Assignment to volatile objects
On 30/01/12 23:22, paul_kon...@dell.com wrote: I would prefer this to generate a warning. The C language standard change you refer to is a classic example of a misguided change, and any code whose behavior depends on this deserves a warning message, NOT an option to work one way or the other. Until gcc gets a feature allowing it to whack the programmer on the back of the head with Knuth's "The Art of Computer Programming" for writing such stupid code that relies on the behaviour of volatile "a = b = 0;", then a warning seems like a good idea. mvh., David paul -Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Zoltán Kócsi Sent: Monday, January 30, 2012 5:03 PM To: gcc@gcc.gnu.org Subject: Assignment to volatile objects Now that the new C standard is out, is there any chance that gcc's behaviour regarding to volatile lhs in an assignment changes? This is what it does today: volatile int a, b; a = b = 0; translates to b = 0; a = b; because the standard (up to and including C99) stated that the value of the assignment operator is the value of the lhs after the assignment. The C11 standard says the same but then it explicitely states that the compiler does not have to read back the value of the lhs, not even when the lhs is volatile. So it is actually legal now not to read back the lhs. Is there a chance for the compiler to get a switch which would tell it explicitely not to read the value back? Zoltan
Re: Assignment to volatile objects
David Brown wrote: > Until gcc gets a feature allowing it to whack the programmer on the back > of the head with Knuth's "The Art of Computer Programming" for writing > such stupid code that relies on the behaviour of volatile "a = b = 0;", > then a warning seems like a good idea. a = b = 0; might be stupid. Is if ( ( a = expr ) ); is also stupid? I thought that that idiom was cited as an example for the expressiveness of C in the C bible (the K&R book). Zoltan
Re: Assignment to volatile objects
paul_kon...@dell.com> wrote: > I would prefer this to generate a warning. The C language standard change > you refer to is a classic example of a misguided change, and any code whose > behavior depends on this deserves a warning message, NOT an option to work > one way or the other. Sure. However, a compiler is a tool and the best thing it can do is to serve its user's needs. Generate a warning, because there's an ambiguous construct (actually, it has always been a bit iffy, but now it is officially an implementation choice). When there is a possibility of helping the user, what's wrong with offering it? If there's a switch and it is being used, then the user explicitely tells you how (s)he wants the ambiguity to be resolved. The user, by specifying his or her preference clearly indicates that (s)he is aware of the ambiguity, i.e. knows what (s)he is doing and asked you kindly to resolve it this way or the other. You can answer with a "piss off, idiot" or just do what the user asked you to do. So why not help the user? Zoltan
Re: Assignment to volatile objects
Zoltán Kócsi schrieb: paul_kon...@dell.com> wrote: I would prefer this to generate a warning. The C language standard change you refer to is a classic example of a misguided change, and any code whose behavior depends on this deserves a warning message, NOT an option to work one way or the other. Sure. However, a compiler is a tool and the best thing it can do is to serve its user's needs. Generate a warning, because there's an ambiguous construct (actually, it has always been a bit iffy, but now it is officially an implementation choice). From what you quotet is's "maybe or maybe not", not "implementation defined". I.e. the behavior may be different for a=b=0 or a=a=a. When there is a possibility of helping the user, what's wrong with offering it? A warning would be much of a help to write unambiguous, robust code. So the question is rather why user refuses to write robust code in the first place once there is a warning. If there's a switch and it is being used, then the user explicitely tells you how (s)he wants the ambiguity to be resolved. The user, by specifying his or her preference clearly indicates that (s)he is aware of the ambiguity, i.e. knows what (s)he is doing and asked you kindly to resolve it this way or the other. You can answer with a "piss off, idiot" or just do what the user asked you to do. So why not help the user? IMHO it's about weigh cluttering up compiler souces with zillions of command line options like - how to resolve a = b = c; if b is volatile. - how to resolve i = i++; - how to resolve f(i++, i++); - etc. against benefit for the user. I don't really see benefit. There are more important things than this in a compiler, and a warning is fine.
-fno-inline-functions vs glibc's initfini
glibc 2.15 won't build with GCC 4.7ish on ppc64: -fno-inline-functions is no longer enough to prevent call_gmon_start from being inlined into initfini.c's _init, as required by glibc's somewhat convoluted compilation of initfini.c into crt*.o. As a result of the inlining, a branch and its target label end up in separate object files, after the compiler's assembly output is broken up in pieces. I suppose this could be easily worked around in glibc, by using attribute noinline (and noclone, for good measure, for partial inlining of the gmon_start undef-weak test would be just as damaging), or compiling sysdeps/generic/initfini.c with -fno-inline-functions-called-once (if available), and perhaps also -fno-inline-small-functions, -fno-indirect-inlining and -fno-partial-inlining, with room for whatever other options we GCC developers come up with to control other cases or kinds of inlining. I'm a bit surprised that -fno-inline-functions doesn't imply all of these, as long as they're not specified explicitly. IMHO it should. I'm also surprised that some parts of GCC appear to assume that -fno-inline was supposed to behave that way, preventing any inlining whatsoever. Grepping for flag_no_inline shows some hits that appear to indicate some confusion as to its meaning. To make matters worse for glibc, it appears that at least -finline-functions-called-once is already present in earlier releases of GCC, which means we might have no choice but to bite the bullet and use this option if it's available, even though I have no evidence that the implementation controlled by the option caused any problems to glibc's initfini compilation in already-released versions of GCC. So, where do we go from here? Is there any reason why glibc doesn't use the noinline attribute in sysdeps/generic/initfini.c, or for glibc not to auto-detect -fno-inline-functions-called-once et al and use them in addition to -fno-inline-functions to compile initfini.c? As for GCC, shouldn't we aim at providing a stable, reliable option that prevents inlining of functions not marked always_inline, regardless of special cases and exceptions to the general inlining rules we might come up with in the future? Also, shouldn't the implementation of -finline/-fno-inline be adjusted to match the documentation, and have flag_no_inline_functions become what we test for as flag_no_inline in some functions that make decisions about whether or not to perform inlining? Thanks in advance for feedback and suggestions, -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: Assignment to volatile objects
On Mon, Jan 30, 2012 at 4:59 PM, Zoltán Kócsi wrote: > David Brown wrote: > >> Until gcc gets a feature allowing it to whack the programmer on the back >> of the head with Knuth's "The Art of Computer Programming" for writing >> such stupid code that relies on the behaviour of volatile "a = b = 0;", >> then a warning seems like a good idea. > > a = b = 0; might be stupid. > > Is if ( ( a = expr ) ); is also stupid? If you ask me, yes. > > I thought that that idiom was cited as an example for the expressiveness of C > in the C bible (the K&R book). > > Zoltan
Re: Assignment to volatile objects
On Tue, 31 Jan 2012 00:38:15 +0100 Georg-Johann Lay wrote: > A warning would be much of a help to write unambiguous, robust code. > So the question is rather why user refuses to write robust code in the > first place once there is a warning. The user (me, in this case) does not refuse writing robust code, because he has no other choice, warning or not. The user is kindly asking to accomodate his wish to write concise and more elegant code which is not five times longer just to get around a language ambiguity (i.e. robust). > IMHO it's about weigh cluttering up compiler souces with zillions of > command line options like > > - how to resolve a = b = c; if b is volatile. > - how to resolve i = i++; > - how to resolve f(i++, i++); > - etc. > > against benefit for the user. I don't really see benefit. I think there is a rather important difference between the volatile case and the others. Accessing a volatile is a side effect and so is the postincrementing of the object. In the increment case you do know that the side effects will happen before the next sequence point, you just do not know exactly when within the two enclosing sequence points. With the a=b=0 case the side effect of reading b may or may not happen at all. That, I think, is a major difference. In fact, I think there is an even bigger ambiguity with the volatile. Consider the case of the single statement of a = 0; where a is volatile. a=0; is an expression statement. Such a statement is evaluated as a void expression for its side effects, as per 6.8.3.2. A void expression is an expression of which the value is discarded, as per 6.3.2.2. Thus, the value of a=0 should be calculated and then discarded. Since evaluating the value of that expression when 'a' is volatile may or may not read 'a' back, as per 6.5.16.3, the compiler thus has every right to randomly generate or not a read after writing the 0 to a. That is, a simple assignment has an unpredictable side effect on volatile objects. Nothing in the standard says that you must not actually calculate the value of an expression statement before discarding it, actually it explicitely states in 5.1.2.3.4 that you must not omit parts of an expression evaluation which have side effects even if the expression's value is not used. The read-back of a volatile lhs of an expression is a side effect, which, according to the standard, the compiler can emit or omit at whim. And with that writing 'robust' code becomes impossible, as long as it matters to you whether the a=0; statement will read back the volatile 'a' or not. Zoltan
Re: Assignment to volatile objects
On Mon, 30 Jan 2012 19:51:47 -0600
Gabriel Dos Reis wrote:
> On Mon, Jan 30, 2012 at 4:59 PM, Zoltán Kócsi wrote:
> > David Brown wrote:
> >
> >> Until gcc gets a feature allowing it to whack the programmer on the back
> >> of the head with Knuth's "The Art of Computer Programming" for writing
> >> such stupid code that relies on the behaviour of volatile "a = b = 0;",
> >> then a warning seems like a good idea.
> >
> > a = b = 0; might be stupid.
> >
> > Is if ( ( a = expr ) ); is also stupid?
>
> If you ask me, yes.
Beauty is in the eye of the beholder, I like
while (( *dst++ = *src++ ));
better than
_some_type_ tmp;
do {
tmp = *src;
*dst = tmp;
src = src + 1;
dst = dst + 1;
} while ( tmp != 0 );
Zoltan
Re: Is it possible to get virtual function indication from mangled name?
Sergei Dyshel writes: > I need to profile a C++ program with 'gprof' but I'm only interested in > virtual functions. Is it possible to get indication of virtual function in > flat profile? As of now, virtual functions aren't marked in any special > way inside demangled names. Correct: the mangled name of a method does not indicate whether or not that method is virtual. > PS. A more general question, in case if it's not possible, which means > that information about a function being virtual or not isn't stored in the > mangled name, is there a profiling tool which can provide such an > indication? Particularly I'm interested in call counts. As far as I know the only way to tell is to pull apart the debugging information. I don't know of any tool that does this. Ian
Re: Assignment to volatile objects
On Mon, Jan 30, 2012 at 8:20 PM, Zoltán Kócsi wrote:
> On Mon, 30 Jan 2012 19:51:47 -0600
> Gabriel Dos Reis wrote:
>
>> On Mon, Jan 30, 2012 at 4:59 PM, Zoltán Kócsi wrote:
>> > David Brown wrote:
>> >
>> >> Until gcc gets a feature allowing it to whack the programmer on the back
>> >> of the head with Knuth's "The Art of Computer Programming" for writing
>> >> such stupid code that relies on the behaviour of volatile "a = b = 0;",
>> >> then a warning seems like a good idea.
>> >
>> > a = b = 0; might be stupid.
>> >
>> > Is if ( ( a = expr ) ); is also stupid?
>>
>> If you ask me, yes.
>
> Beauty is in the eye of the beholder, I like
The question I was responding to did not ask
about "beauty" nor "likability".
>
> while (( *dst++ = *src++ ));
>
> better than
>
> _some_type_ tmp;
>
> do {
> tmp = *src;
> *dst = tmp;
> src = src + 1;
> dst = dst + 1;
> } while ( tmp != 0 );
I don't think there a claim that one couldn't write more stupid code.
>
>
> Zoltan
