June 2008 - Darwin-dev - lists.apple.com

Re: Odd GCC Behavior
by Andy Wiese 30 Jun '08

30 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Jun 30, 2008, at 3:27 PM, Brian Mastenbrook wrote: On Jun 30, 2008, at 3:02 PM, Jean-Daniel Dupas wrote: -- Brian Mastenbrook brian(a)mastenbrook.net http://brian.mastenbrook.net/ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Maybe the compiler should warn or even produce an error instead of generating "random" code with undefined behavior ? It does. The moral of the story is "develop with -Wall -Werror, deploy with -Wall". Complaints about gcc's default laconic nature are probably best addressed to the gcc mailing list. The rest of this thread is the same discussion about nasal demons that has been rehashed a million times over on comp.lang.c. (If you don't know what nasal demons are, be thankful that you didn't run that test of yours on the DeathStation Pro!) Thank you Brian. That's the most useful thing I've learned from this thread! This email sent to site_archiver(a)lists.apple.com

1 0

Re: Odd GCC Behavior
by Brian Mastenbrook 30 Jun '08

30 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Jun 30, 2008, at 3:02 PM, Jean-Daniel Dupas wrote: -- Brian Mastenbrook brian(a)mastenbrook.net http://brian.mastenbrook.net/ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Maybe the compiler should warn or even produce an error instead of generating "random" code with undefined behavior ? It does. The moral of the story is "develop with -Wall -Werror, deploy with -Wall". Complaints about gcc's default laconic nature are probably best addressed to the gcc mailing list. The rest of this thread is the same discussion about nasal demons that has been rehashed a million times over on comp.lang.c. (If you don't know what nasal demons are, be thankful that you didn't run that test of yours on the DeathStation Pro!) This email sent to site_archiver(a)lists.apple.com

1 0

Re: Odd GCC Behavior
by Jean-Daniel Dupas 30 Jun '08

30 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Le 30 juin 08 à 21:44, Eli Bach a écrit : On Jun 30, 2008, at 11:32 AM, J. Aaron Pendergrass wrote: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com I'm certainly not trying to get anyone to do my work, merely pointing out what seemed like a peculiar implementation and potential source of cross-platform incompatibilities, and perhaps to gain some insight into exactly what decisions led to this piece of behavior. Others have comments on why it may result in significantly different code for different platforms [heck, may even different optimization levels]. Just switching from ggc 3.3 to gcc 4.0 on PowerPC could make it work differently [only in a less noticeable way]. I would argue it's a feature/benefit that it works differently as often as possible, as I would automatically classify using undefined compiler behavior as a serious bug. Wouldn't it be best for your code base that all use of undefined behavior be removed as soon as possible. The more different it works hopefully makes the problem more apparent. Maybe the compiler should warn or even produce an error instead of generating "random" code with undefined behavior ? smime.p7s

1 0

Re: Odd GCC Behavior
by Eli Bach 30 Jun '08

30 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=9ebiw9J0BoqzN4n5x7BrFCQjwckkLjnphKP+65YfJIk=; b=OdDiNuvzaEYN1nyLcJrdMUKHmGTOGsdVKZjeYXsaxzuUdmJS4VxW6nNOldOMwG+4DU nB/cSCUo1R4rMtvceMbBVwitTHhTWa3cLoqqfxp8p4Rb+I2EDkrZyOMkmzHopwK5qawk FLKHnLlgwtNRMvfxQFzVNIDJolceRlMaiJn4A= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=NNChLFkx9Hj7aCVjFZ4m1WZtGoSpoVZgbzZ+qq1XEhUg2XRz/6iafoFUzZf8QugYYG 7XfKPnC9TPHs9YwYHAH+yt+H51KorglHEG3PX+f5O87Q2QosMMX1JBbwh5RRLAPXrtkG N7Xf9nbzHbQIURRUeSEHVKYkqnP2EBMJw5GR8= On Jun 30, 2008, at 11:32 AM, J. Aaron Pendergrass wrote: I'm certainly not trying to get anyone to do my work, merely pointing out what seemed like a peculiar implementation and potential source of cross-platform incompatibilities, and perhaps to gain some insight into exactly what decisions led to this piece of behavior. Others have comments on why it may result in significantly different code for different platforms [heck, may even different optimization levels]. Just switching from ggc 3.3 to gcc 4.0 on PowerPC could make it work differently [only in a less noticeable way]. I would argue it's a feature/benefit that it works differently as often as possible, as I would automatically classify using undefined compiler behavior as a serious bug. Wouldn't it be best for your code base that all use of undefined behavior be removed as soon as possible. The more different it works hopefully makes the problem more apparent. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Odd GCC Behavior
by Jonas Maebe 30 Jun '08

30 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 30 Jun 2008, at 19:32, J. Aaron Pendergrass wrote: Jonas _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I was somewhat surprised that the "most convenient thing for the programmer" was something like "if the left hand of side of a compound assignment statement is a pointer dereference, then determine it's r-value first, then evaluate the right hand side (including any pre/post increments/decrements), perform the arithmetic for the compound assignment, then determine the l-value of the left hand side and perform the actual assignment otherwise evaluate the left-hand side to determine both its r-value and l-value, then evaluate the right hand side (including any pre/post increments/decremetns), perform the arithmetic for the compound assignment, then store the result in the previously computed l- value." If the standard for a programming language does not define a particular evaluation order, the compiler usually uses some notion of complexity to determine what to do first in order to minimize the register pressure, to minimize the number of instructions required, etc. (all of which can be processor dependent). Such optimizations are by no means defined in if-then choices like you write above, but using some kind of heuristics which have been chosen based on resulting in good code for a bunch of test cases. Invalid/ undefined code is not commonly considered when writing/evaluating such heuristics. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Odd GCC Behavior
by Clark Cox 30 Jun '08

30 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=aZG/3cX5NHhFa6QPFmPAL16qT27bCE/A5Zlo1QNU/mo=; b=tgJgq0siSMBTM4XfKzf2ZqHbDifXgeXcwumNCGJAsPKuykM07bWYIXYMeALT87hquA ZLGvfXzvHCGyUFullvz3gucnwz1XWNi0Lz5FuenhpgidkrUWfrSzbptZcUBmkGPR3uST dYa/FKJ+m4D6fZWK/XOh7aFzObfLWNAYMsjyM= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=btoOd0MPfWy8m7TKdJPuiYWHA+zInh05KjokcOJdioPw8V/fKFkz9J2AHbakmg+G9p RYiJQSDgETVQsqhL3XwqTcHcspkmvYiG8xa+/g1+bz9O3qvoGiYz7m2rdBYf3cDxOy+k 8vv8H0OaaUZYu6HytlshoKlv4uucm8HFMyX40= On Mon, Jun 30, 2008 at 9:36 AM, J. Aaron Pendergrass <james.pendergrass(a)jhuapl.edu> wrote: > > On Jun 30, 2008, at 12:26 PM, Clark Cox wrote: > >> On Mon, Jun 30, 2008 at 6:38 AM, J. Aaron Pendergrass >> <james.pendergrass(a)jhuapl.edu> wrote: >>> >>> I'm aware that this is undefined. >>> I did explicitly say that the C spec leaves this unspecified. >>> But {1,2,7,4} seems like such an odd choice. Especially when looking at >>> the >>> disassembly: >>> >>> lwz r2,56(r30) >>> addi r2,r2,-8 >>> lwz r9,0(r2) >>> lwz r2,56(r30) >>> addi r0,r2,-4 >>> stw r0,56(r30) >>> lwz r2,56(r30) >>> lwz r0,0(r2) >>> add r0,r9,r0 >>> lwz r2,56(r30) >>> addi r2,r2,-8 >>> stw r0,0(r2) >>> >>> which really seems to be going out of its way to implement a fairly >>> unintuitive semantics >>> for this piece of undefined behavior and I was curious what the >>> motivation >>> behind this behavior might be. >> >> With undefined behavior, there is no such thing as an "odd choice". >> There is no choice to be made. > > Of course there's a choice to be made. > The compiler has to do something. It chose to do something on powerpc that > is > completely different from what it chooses to do on other architectures, and > on other > programs which have very similar undefined usages, and which seemed somewhat > unintuitive (in the sense that if I were to define a particular behavior it > would not have > been the one I observed). That implies that someone consciously chose the behavior that you're seeing. Which isn't necessarily the case. Any time spent on this kind of undefined behavior (by compiler writers) is a waste of time, as nobody should be writing such code, and anyone who does, deserves the undefined behavior that they get. > I'm curious what the motivation is for this particular choice. > If you don't know the answer don't respond. The "answer" is that there isn't any. -- Clark S. Cox III clarkcox3(a)gmail.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Odd GCC Behavior
by J. Aaron Pendergrass 30 Jun '08

30 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Jun 30, 2008, at 1:12 PM, Steve Sisak wrote: I'm curious what the motivation is for this particular choice. If you don't know the answer don't respond. To be correct, you MUST write it on 2 lines: { long stack[4] = {1,2,3,4}; long *sp = test + 4; /* top of stack is at (sp - 1) */ /* add the top of stack to the next element and pop */ sp -= 1; *(sp - 2) += *sp; } Are you sure you aren't trying to get us to do your homework? ;-) Cheers, sp = sp - 1; *(sp - 2) += *(sp) or *(sp - 2) += *(sp); sp = sp -1 ; or even: tmp = sp -1; (sp - 2) += (*tmp); sp = tmp; None of which actually match the observed behavior of: tmp = *(sp - 2); sp -= 1; *(sp - 2) = tmp + (*sp); -Aaron _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… At 12:36 PM -0400 6/30/08, J. Aaron Pendergrass wrote: Of course there's a choice to be made. The compiler has to do something. It chose to do something on powerpc that is completely different from what it chooses to do on other architectures, and on other programs which have very similar undefined usages, and which seemed somewhat unintuitive (in the sense that if I were to define a particular behavior it would not have been the one I observed). Because PPC and Intel have different instruction sets and therefor different optimizers. What the spec is saying by "undefined" is that "if a programmer writes code like this it's a bug" so there's no need for compiler writers to do anything but what's most convenient. This is a very common interview question to test basic literacy in the in the C programming language. If you see someone writing code like this it's a good signal not to trust other they write (and not to hire them). :-) There are still some people who think that reducing the number of lines of C somehow reduces code size. -Steve Thanks for the more detailed response. I understand what "undefined" means, and that different architectures are different. but I was also under the impression that programmers wrote buggy code fairly frequently. I may have been wrong in this. But I point out that in Andrew Pinski's previous email he enumerated a number of options for the possible semantics of "*(sp-2) += *(--sp)": I stumbled upon this behavior when converting code which made heavy use of macros to do stack manipulation from using array indices to using pointers and found that the semantics were totally different (as are the dissaembly for PPC). I was somewhat surprised that the "most convenient thing for the programmer" was something like "if the left hand of side of a compound assignment statement is a pointer dereference, then determine it's r-value first, then evaluate the right hand side (including any pre/post increments/decrements), perform the arithmetic for the compound assignment, then determine the l-value of the left hand side and perform the actual assignment otherwise evaluate the left-hand side to determine both its r-value and l-value, then evaluate the right hand side (including any pre/post increments/decremetns), perform the arithmetic for the compound assignment, then store the result in the previously computed l-value." I'm certainly not trying to get anyone to do my work, merely pointing out what seemed like a peculiar implementation and potential source of cross-platform incompatibilities, and perhaps to gain some insight into exactly what decisions led to this piece of behavior. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Odd GCC Behavior
by Steve Sisak 30 Jun '08

30 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com I'm curious what the motivation is for this particular choice. If you don't know the answer don't respond. To be correct, you MUST write it on 2 lines: { long stack[4] = {1,2,3,4}; long *sp = test + 4; /* top of stack is at (sp - 1) */ /* add the top of stack to the next element and pop */ sp -= 1; *(sp - 2) += *sp; } Are you sure you aren't trying to get us to do your homework? ;-) Cheers, -Steve _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… At 12:36 PM -0400 6/30/08, J. Aaron Pendergrass wrote: Of course there's a choice to be made. The compiler has to do something. It chose to do something on powerpc that is completely different from what it chooses to do on other architectures, and on other programs which have very similar undefined usages, and which seemed somewhat unintuitive (in the sense that if I were to define a particular behavior it would not have been the one I observed). Because PPC and Intel have different instruction sets and therefor different optimizers. What the spec is saying by "undefined" is that "if a programmer writes code like this it's a bug" so there's no need for compiler writers to do anything but what's most convenient. This is a very common interview question to test basic literacy in the in the C programming language. If you see someone writing code like this it's a good signal not to trust other they write (and not to hire them). :-) There are still some people who think that reducing the number of lines of C somehow reduces code size. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Odd GCC Behavior
by Andrew Pinski 30 Jun '08

30 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=sGOgsodKjJodlW5gvkAeJd7TanDue5iMLjeBoiZ1Ybc=; b=u5E/FlG/nZ1KeT20SgnwAeTQQFlqqETA37SxnnrDd3uaDH0R8cbTMK3b3ENmiVmpPh uBYM3kQOMAkVEl8J7FNVj9rBLWHr8ZIl9m0PdWPgZoNpkZl0OLW2G8E/kshZWdOpVICu WXJkgtHlzN8pkCNHv770YyZHi1OCfx7PTta8k= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Lde4JxomISt5C3yp1APejkWlHvAvHlRM0ZCdgFaxG2ssSTypEgh59K0BJtSkaLv4Zi NTvgfzo1OJKvYtCBxS9qqV+VciQZnED8vZsz/o2UmnMc++TZWNxEtgzk8Fw6PqnWRM8p 2CX+7XsiF7pEt0XJa5bfe/jMmOnPMqosuICeA= On Mon, Jun 30, 2008 at 6:26 AM, Andrew Pinski <pinskia(a)gmail.com> wrote: > This code is undefined as you are acessing and modifying a variable with a > sequence point inbetween the acess and modification. Try compiling with > warnings turned on. -Wsequence-point should get you a warning. More to the point, what is unspecified is the order of execution of sp = (sp - 1) and the other access of sp. So we could have: sp = sp - 1; *(sp - 2) += *(sp) or *(sp - 2) += *(sp); sp = sp -1 ; or even: tmp = sp -1; (sp - 2) += (*tmp); sp = tmp; So with this case, you get an undefined behavior because of the access. Thanks, Andrew Pinski _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Odd GCC Behavior
by J. Aaron Pendergrass 30 Jun '08

30 Jun '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Jun 30, 2008, at 12:26 PM, Clark Cox wrote: On Mon, Jun 30, 2008 at 6:38 AM, J. Aaron Pendergrass <james.pendergrass(a)jhuapl.edu> wrote: lwz r2,56(r30) addi r2,r2,-8 lwz r9,0(r2) lwz r2,56(r30) addi r0,r2,-4 stw r0,56(r30) lwz r2,56(r30) lwz r0,0(r2) add r0,r9,r0 lwz r2,56(r30) addi r2,r2,-8 stw r0,0(r2) With undefined behavior, there is no such thing as an "odd choice". There is no choice to be made. I'm curious what the motivation is for this particular choice. If you don't know the answer don't respond. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I'm aware that this is undefined. I did explicitly say that the C spec leaves this unspecified. But {1,2,7,4} seems like such an odd choice. Especially when looking at the disassembly: which really seems to be going out of its way to implement a fairly unintuitive semantics for this piece of undefined behavior and I was curious what the motivation behind this behavior might be. Of course there's a choice to be made. The compiler has to do something. It chose to do something on powerpc that is completely different from what it chooses to do on other architectures, and on other programs which have very similar undefined usages, and which seemed somewhat unintuitive (in the sense that if I were to define a particular behavior it would not have been the one I observed). This email sent to site_archiver(a)lists.apple.com

1 0