[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #52 from rogerio at rilhas dot com 2010-08-14 13:17 --- Do you really want me to go away? You are not using the right formula for that. You know I have a problem and I can't resist. Everytime you post a message you're just calling me back! (In reply to comment #49) You're rude, ignorant and annoying. Yes I am. But a little bit less every day, thanks to (respectively) my mom, your clarifications about the standards, and my 12-step program. (In reply to comment #51) There you go, you are now famous. http://en.wikipedia.org/wiki/GNU_Compiler_Collection#Criticism Why did you remove the post? Do you think something there is not true? You said it, why is it not true? Are you recanting? Wikipedia is the place to post true statements, it if is the truth then it should be there. Don't tell me now that you are ashamed of what you said, are you? Please: you and your friends keep of from removing a perfectly valid criticism that I backed up with your statements. You think you can just keep on removing, but I'll just keep on putting it back. Until I get bored and take it up to Wilkipedia. Why didn't you remove the other guy's criticism about GCC being buggy and producing crappy code? Is his criticism better than mine? Is it better substantiated than mine? Thank you, that's encouraging, I just hope the language of that article won't be changed too much to also mention everyone else who has a clue. No, from the time I posted it first I changed it only once because I realised (based on it being undefined right now) that the code could break at any time, not just with future releases of GCC. Because, you see, I'm of course very excited about me being famous now and about being the only one who knows the truth, but OTOH I fear there were some other clever people that happen to agree with me, and I now see a real danger of those replacing me in that wikipedia article. I don't see where you are getting at. I don't want you to be the only one who knows the truth, I want everyone to know about it. Duhh!! Why else would I post it on Wikipedia?? I don't want GCC to keep any secret pitfalls from anyone, is that alright with you? Even worse would be that the list of names would be too large to mention in wikipedia and that the list would be replaced by some more unspecific phrases like people who actually understood the standard or the like. Ah, I see. You are afraid of someone removing your name from the post? I won't do that, I promise. And while the reference to your comment is there you will always have a place among the stars. So be sure to try your best to keep it there!! The comunity has been warned about GCC. Everybody who reads Wikipedia. Some of them are programmers. Which community? Rogerio-cdecl church followers? Possibly. In between our other rituals. My followers use their prayer time as they like, many of them use that time to seek enlightment. They can get it from wherever they like, including Wikipedia. Or C standards. Or bugzilla bug reports. Whatever. In that case I'm happy, because I'll expect less bug-reports from supporters of that specific religion. Sure, you already shut me up. And I thanked you, remember? (I still have the same opinion of you, but your error rate dropped a little more... still impressivly high, though). I confessed that I did learn from your post (not being sarcastic, I really did). I'll continue to feel sorry for them (especially because I've learned over the conversation that you might actually influence new programmers, which is a terrible thing to do for you) but am not particularly looking forward to seeing misguided and crippled attempts of creating meagre imitations of stumbling pseudo bug-reports, especially because we can have the best there is: Rilhas bugs! Yup. I now realize why my bug reports aren't really bug report. Just some side-effect of me not realizing the full impact of GCC just following standards. It claims is cdecl conformant, but even without optimizations it doesn't place parameters on the stack as cdecl states. My bad, GCC does not guarantee cdecl anywhere, you are right. So I'll just shut up with that. And getting the address of parameters? You are right, not defined in the standards. You are right too. So I'll just shut up with that too. So, the 2 bug reports are, thus, squashed as invalid. (not being sarcastic either). As for Rilhas' bugs? None, as long as I steer clear of GCC. And my code works? Yes. And am I good at what I do? Yes? How do I know? My mom tells me so all the time (and besides I continuously get paid very well, which is my second strongest indicator that I do a good job). Am I afraid of doing non-standard things? No, standards have to keep up with the real world and with special pusher compilers, like MSC. If one day some standard realizes that what MSC does is clever and adopts it then GCC will eventually follow. If not then I'll just keep on
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #53 from redi at gcc dot gnu dot org 2010-08-14 13:55 ---
(In reply to comment #52)
(In reply to comment #51)
There you go, you are now famous.
http://en.wikipedia.org/wiki/GNU_Compiler_Collection#Criticism
Why did you remove the post? Do you think something there is not true? You
said
it, why is it not true? Are you recanting? Wikipedia is the place to post true
statements, it if is the truth then it should be there. Don't tell me now that
you are ashamed of what you said, are you?
Look at the page history, it was removed by someone else, probably because your
comment is badly written and not suitable for the Wikipedia page.
As with most of your comments, they are unfounded and easily refuted by
checking facts, but you're so sure you know them that you don't need to check.
As you've said before, learn to read.
Please: you and your friends keep of from removing a perfectly valid criticism
that I backed up with your statements. You think you can just keep on
removing,
but I'll just keep on putting it back. Until I get bored and take it up to
Wilkipedia. Why didn't you remove the other guy's criticism about GCC being
buggy and producing crappy code? Is his criticism better than mine? Is it
better substantiated than mine?
Wikipedia editors are our friends now? Are you paranoid?
I don't see where you are getting at. I don't want you to be the only one who
knows the truth, I want everyone to know about it. Duhh!! Why else would I
post
it on Wikipedia?? I don't want GCC to keep any secret pitfalls from anyone, is
that alright with you?
Noone wants it to be a secret, everyone in the GCC project would prefer if no
users shared your incorrect beliefs.
It claims is cdecl conformant, but even without optimizations it doesn't place
parameters on the stack as cdecl states. My bad, GCC does not guarantee cdecl
anywhere, you are right. So I'll just shut up with that.
Check your favourite reference - the Wikipedia entry on cdecl says GCC is the
de facto standard for caling conventions on Linux - so by definition what GCC
does is correct. It must be true, Wikipedia says so.
Was Microsoft wrong? No, us in the real world love it. In fact, this code:
class Color;
class Vector;
virtual func(Color c=Color(WHITE), Vector v=Vector(VECTOR_Z));
Has no workaround for in GCC. Why? Because GCC can't initialize parameters
that
are classes. MSC can. So this code (which I needed to do, no real practical
alternative), cannot be compiled in GCC. Why? Because GCC doesn't go beyond
standards. Period.
What are you talking about? You were originally talking about initializing
non-const references with temporaries. The code above would work fine, if
you'd defined Color and Vector.
class Color { public: Color(int); };
class Vector { public: Vector(int); };
const int WHITE = 0;
const int VECTOR_Z = 0;
class Idiot {
virtual void func(Color c = Color(WHITE), Vector v = Vector(VECTOR_Z));
};
GCC compiles that fine, try it.
GCC compiles that because it's valid C++.
What is your point?
Keep this up, future employers will love to see you making an idiot of yourself
so publicly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #54 from redi at gcc dot gnu dot org 2010-08-14 14:25 --- (In reply to comment #53) GCC compiles that fine, try it. Sorry, I forgot my manners, what I meant is... Why don't you think before shooting off some crap. So I have shown you talk crap. Do you like it? Better get used to it, I'm a mean sonofagun and I'll keep showing you why you're wrong. You're an idiot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #55 from rogerio at rilhas dot com 2010-08-14 14:31 ---
(In reply to comment #53)
(In reply to comment #52)
(In reply to comment #51)
Look at the page history, it was removed by someone else, probably because
your
comment is badly written and not suitable for the Wikipedia page.
I thought that was your mom, sorry. We are alright then. When the guy removes
it again I'll tell him to ask you if it is true. If you don't recant he will
know I'm telling the truth.
As with most of your comments, they are unfounded and easily refuted by
checking facts, but you're so sure you know them that you don't need to check.
As you've said before, learn to read.
Right, that must be it. As if I didn't backed it up with your own comment #35.
Boy, it will sure be easy to prove my post to be unfounded!!!
Noone wants it to be a secret, everyone in the GCC project would prefer if no
users shared your incorrect beliefs.
So do I. I don't want anyone sharing my incorrect beliefs. Did we just agree on
something here? So I'll tell the guy to talk to ask you.
Check your favourite reference - the Wikipedia entry on cdecl says GCC is the
de facto standard for caling conventions on Linux - so by definition what GCC
does is correct. It must be true, Wikipedia says so.
... unless it was your post! You tend to miss more than you hit. But yeah,
you've shut me up on that too. I just wrote that in my previous post.
What are you talking about? You were originally talking about initializing
non-const references with temporaries.
Yes, that is right. GCC gave me the same error in both cases (aren't default
parameters initialized with classes the same as parameters initialized with
classes?). Probably my bad.
The code above would work fine, if
you'd defined Color and Vector.
class Color { public: Color(int); };
class Vector { public: Vector(int); };
const int WHITE = 0;
const int VECTOR_Z = 0;
class Idiot {
virtual void func(Color c = Color(WHITE), Vector v = Vector(VECTOR_Z));
};
GCC compiles that fine, try it.
Yeah, you are right, your class does. But mine don't, the diference is that
mine are a bit more complex and derive a lot... but you were right, yours does
compile. And I was right, my code with GCC would have given me more trouble to
deliver to the client. But you are right, I posted an Idiot class. (see how
easy it is to admit when we are wrong? .. if you tried it you would quickly
gain a lot of practice! ... anyway, good job in reducing your error rate, it is
now close to a normal person!)
GCC compiles that because it's valid C++.
What is your point?
Keep this up, future employers will love to see you making an idiot of
yourself
so publicly.
No, the worse is being wrong and don't admit it. When we admit we learn, so
I've been learning quite a lot with you guys. You didn't admit anything, so in
your mind LDT read accesses a still prohibitive, and crap like that. Or did you
think I would forget all the crap that you said that I shot down and you didn't
admit?? Your future employers (if any!) will see that your ability to learn
simple stuff is impaired.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #56 from rogerio at rilhas dot com 2010-08-14 14:34 --- (In reply to comment #54) (In reply to comment #53) GCC compiles that fine, try it. Sorry, I forgot my manners, what I meant is... Why don't you think before shooting off some crap. So I have shown you talk crap. Do you like it? Better get used to it, I'm a mean sonofagun and I'll keep showing you why you're wrong. You're an idiot. Yeah, I've seen you show me I said crap that I didn't study well enough before saying it. I learned, it will never be repeated. All the rap you said that I shot down didn't make you learn anything. We are both idiots, but I'm a little bit less every day. I've left you behind a long time ago. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #57 from redi at gcc dot gnu dot org 2010-08-14 15:09 --- (In reply to comment #55) (In reply to comment #53) Look at the page history, it was removed by someone else, probably because your comment is badly written and not suitable for the Wikipedia page. I thought that was your mom, sorry. Good way to make a convincing argument. You've tried to turn this into a your mom argument in three replies now, but noone seems to be rising to the bait. No, the worse is being wrong and don't admit it. When we admit we learn, so I've been learning quite a lot with you guys. You didn't admit anything, so in your mind LDT read accesses a still prohibitive, and crap like that. Or did you think I would forget all the crap that you said that I shot down and you didn't admit?? Your future employers (if any!) will see that your ability to learn simple stuff is impaired. Are you confusing me with Michael? I've not said anything about LDT. What am I supposed to admit? That GCC compiles valid C++ code? That I've wasted time replying to you? That's true, but it's my weekend and I'm waiting for a GCC testsuite run to finish so I have time. You keep accusing GCC of not compiling useful C++ code, but haven't shown a valid example yet. I am happy to learn but I don't see anything worth learning from you, your opinions or your debating style. Even your trolling skills are poor, and you started so well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #58 from rogerio at rilhas dot com 2010-08-14 16:02 --- Why?? Why do you keep calling me back?? I was just going out and I heard the new e-mail sound! Now I'm going to be late!! (In reply to comment #57) Good way to make a convincing argument. You've tried to turn this into a your mom argument in three replies now, but noone seems to be rising to the bait. Not an argument. I said I was sorry to think it was you or one of your friends (is Chris your friend?). Anyway, I understand why you got confused and missed my apology, I inserted the mom joke. My bad, it was not funny at all, and you thought it was an argument. My bad. Are you confusing me with Michael? I've not said anything about LDT. Yes I am. I'm sorry for that, I really am. I got mixed up. We were discussing the post and I didn't check the sender. There are just too many of you guys. I'm sorry, this comment wasn't meant for you (I must be getting tired). What am I supposed to admit? That GCC compiles valid C++ code? You don't have to admit anything really. But in your comment #34 to bug #45249 you missed the point entirely and just spewed out standards. You missed the point really, as I was saying GCC can't, and it really can't. Spewing out standards just to explain GCC can't because insert standards here was not really useful for that discussion. Does not make an idiot out of you though. Then you claimed What a charming idea, that a compiler could become perfect by doing what I said it should. And that is very close to making an idiot out of you, because you deflected without getting the background for the conversation straight. I had to show you (again) that you failed to see that what I say is what C99+cdecl say. These all don't make an idiot out of you yet. Adding them all together was borderline-idiot, but still safe. Then, for this bug, your comment #45 missed the point. You didn't understand why I posted it on Wikipedia, although it is well explained there. But ok, I'll grant you that that also does not make an idiot out of you. ... then, from comment #53 on we really looked to me like Michael, so I lost it. Here I go, back to being more of an idiot, and there you go not an idiot yet. That I've wasted time replying to you? That's true, but it's my weekend and I'm waiting for a GCC testsuite run to finish so I have time. You keep accusing GCC of not compiling useful C++ code, but haven't shown a valid example yet. Yes I have. It is there on Wikipedia. The code compiled is not valid (in a functional sense) because the programmer cannot trust the pointer difference. Maybe at this point you get confused because you didn't type valid [according to standards] example, but you didn't type it. So valid is open for discussion. And I say that is valid if it returns 0x4000-0x3000=0x1000. So there you go, now you're an idiot like Michael (well, still less, your error rate is much lower and of much less significance). You are an idiot because you don't know what valid is to everyone, you just think you do because you know of some standard that says what is valid in a given context. I do assembly inside my C code with MSC, is that not valid because it is not defined in any C standard? Nope. It is valid, no matter how much you kick and scream. With the same train of thought I could talk about initializing classes as parameters to functions as in comment #25 of bug #45249 (as another example I posted and that you didn't see), because, again, you didn't explain what the valid word in your text was supposed to mean. I know you mean standards, but there is more to it. But this one does not make an idiot out of you because valid is much harder to define here. So I'm am not in a position to spot the level of idiocy in your comment (I'll just assume it is none). So I say valid (outside in the real world) and you say invalid (based on C standards), but none of us are idiots for it. I am happy to learn but I don't see anything worth learning from you, your opinions or your debating style. Even your trolling skills are poor, and you started so well. That's my point. You keep proving my point. You don't feel the need to learn anything from me because you are all cosy inside your standards box and look down on the other kids playing outside in the real world. You wear all your silk-based standards shirts and mock the dumb kids in the playground that use silk+cotton immitations. You call them idiots even after they've shown you that when you are outside silk doesn't cover all the needs. You don't even realize that I'm right that GCC thus alienates memory mapped device programmers, thus making it inferior to many others. You're stuck in idiot-land. I still don't know what a troll is. English is not my native language. Checking the web it seems like a troll is someone whose primary purpose when posting comments is to provoke disruption. I don't feel like that, I posted what I thought to be actual bugs
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #59 from redi at gcc dot gnu dot org 2010-08-14 17:10 ---
(In reply to comment #58)
(is Chris your friend?)
Of course not. I have no idea who he is.
Are you confusing me with Michael? I've not said anything about LDT.
Yes I am. I'm sorry for that, I really am. I got mixed up. We were discussing
the post and I didn't check the sender. There are just too many of you guys.
I'm sorry, this comment wasn't meant for you (I must be getting tired).
See, you talk crap? (I'm responding like that because that's your manner of
response, you attack and you insult and you aren't even paying attention to
what you're replying to.)
What am I supposed to admit? That GCC compiles valid C++ code?
You don't have to admit anything really. But in your comment #34 to bug #45249
you missed the point entirely and just spewed out standards. You missed the
point really, as I was saying GCC can't, and it really can't. Spewing out
standards just to explain GCC can't because insert standards here was not
really useful for that discussion. Does not make an idiot out of you though.
GCC *could* compile invalid code, if we wanted it to, but it doesn't. That's by
design, not due to accident or inability to make it work.
Several other C++ compilers don't compile it either.
The reason is because they aim to follow the relevant standards. And so that's
why I referenced the standard.
Then you claimed What a charming idea, that a compiler could become perfect
by
doing what I said it should. And that is very close to making an idiot out
of you, because you deflected without getting the background for the
conversation straight. I had to show you (again) that you failed to see that
what I say is what C99+cdecl say.
Yes, that was sarcasm, in the (apparently wrong) hope that you'd get a hint and
go away.
You keep accusing GCC of not compiling useful C++ code, but haven't shown a
valid example yet.
Yes I have. It is there on Wikipedia. The code compiled is not valid (in a
functional sense) because the programmer cannot trust the pointer difference.
Maybe at this point you get confused because you didn't type valid [according
to standards] example, but you didn't type it. So valid is open for
discussion. And I say that is valid if it returns 0x4000-0x3000=0x1000.
The ISO C and C++ standards say what's valid in this context, not you.
So there you go, now you're an idiot like Michael (well, still less, your
error
rate is much lower and of much less significance). You are an idiot because
you
don't know what valid is to everyone, you just think you do because you know
of some standard that says what is valid in a given context. I do assembly
inside my C code with MSC, is that not valid because it is not defined in
any
C standard? Nope. It is valid, no matter how much you kick and scream.
No, in the context of a compiler which tries to conform to the ISO standard,
the ISO standard is the definition of what's valid.
With the same train of thought I could talk about initializing classes as
parameters to functions as in comment #25 of bug #45249 (as another example I
posted and that you didn't see), because, again, you didn't explain what the
valid word in your text was supposed to mean. I know you mean standards, but
there is more to it. But this one does not make an idiot out of you because
valid is much harder to define here. So I'm am not in a position to spot the
level of idiocy in your comment (I'll just assume it is none). So I say
valid
(outside in the real world) and you say invalid (based on C standards), but
none of us are idiots for it.
You are welcome to use any definition of valid in your personal conversations,
but in the context of a compiler which aims to conform to the ISO standards you
don't get to decide what the definition of valid is. And this bugzilla is,
most certainly, in the context of GCC.
If you want to discuss other uses of valid or non-standard code, do it
somewhere else, such as the comp.lang.c newsgroup.
G++ doesn't compile that code because the code is invalid, and binding
non-const references to rvalues is unsafe, and C++ experts have decided that a
conforming compiler should not allow it. One reason for that is the following:
class X { int i; }
X f(X x) { return x; }
int main()
{
X x1 = f( X() );
return x.i;
}
This code is unsafe because it accesses X::i after it has been freed.
The standard says it's not allowed, and G++ implements that. You are free to
say it should be different, but noone will agree with you.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #34 from rogerio at rilhas dot com 2010-08-13 12:14 --- (In reply to comment #33) Not really, you could always subtract. However, far pointers gave predictable addresses, just like C99 says they pointer arithmetic should. They didn't. If you subtracted far pointers that pointed into different segment, the segment difference was ignored. If you include real segmentation like on 80286, where there's no linear relationship between effective address and segment+offset, subtraction would have been prohibitively expensive to implement anyway. That's just ignorance on your part (nothing new, I guess I'm becoming used to that). You are saying things that you don't know. You said that without even knowing if there were any compilers back then that didn't do what you said. You just took your personal experience with some crappy compiler and generalized it for everyone. Wrong. What you don't know is that when you subtracted far pointers the compiler generated the code to change seg16:ofs16 into abs20. What you think is prohibitively expensive would come down to 4 instructions or something like that (2 shifts, 2 additions). But lets say 10. Is that prohibitively expensive?? If the user requested a pointer difference you would be happy as a compiler developer to just not compile (or produce an incorrect difference) instead of generating 10 machine instructions? Or 20? A compiler should NEVER EVER EVER refuse to compile (or compile bad code) because the resulting number of instructions is large. Your comment and opinion thus don't deserve any respect because we are defending the way to do a bad compiler. That claim is not just wrong, it is dumb. I'm not trying to offend you, I'm sure you are not dumb, but you let a dumb comment slip out. Anyway, again you are just plain wrong. The compilers I used back then did this operation well. In those days there were no real standards that developers would generally follow, and programmers used to rely on what they knew about a compiler. So I guess you might have used some crappy one that failed miserably at pointer arithmetic, and based your whole opinion that it is beller to compile bad arithmetic or not compile at all than to add 10 instructions to the code. Your ignorance is in not knowing that segmented addresses were already being abstracted to C programmers by mid-range compilers. I remember this being already done on 8088 compilers, abstraction of the underlying hardware was something every C compiler strived to do. No compiler I knew of didn't do an operation correctly because it had to generate 10 instructions or 20. or a loop. So you stated something as an absolute truth but failed to see that one single exception would prove you wrong. So you you threw yourself head on against the wall again. But don't worry, I think I know your type fairly well. You will probably just get right back up on the horse, shake it all off, forget about what you did wrong, and start anew with some other wrong statement. I'm basing this on your track record in our conversations, where almost 100% of your claims are wrong or miss the point. That is just impressive. In case I'm wrong about you my apologies. And you still wouldn't get around the size limitation of ptrdiff_t that was 16bit. What the hell are you talking about? I personally disassembled code in the late 80's to see how the compiler implemented 32-bit arithmetic on a 286. It did, and it did it well. You weren't able to go beyond 16 bits in the 80's? Or are just making this stuff up? I'm sure you are making it up, on an 8-bit PIC I have written assembly code to do 32-bit shift-add and it uses up something like 12 instructions or so. Not hard at all. Not prohibitive at all. Again: you wished you were right, but you are wrong. You think you known, but you don't. But are you careful? No, you just keep throwing yourself against a wall. And you don't seem to realise that that is becomming a recurring pattern for you. Keep it up, it is fun to watch. And of course the subtraction of addresses of parameter is always meaningless in C, segmented or not, as pointed out multiple times. With or without cdecl. Yup, and multiple times you have been wrong. The cute C99 box you live in doesn't let you see beyond that. But param is not meaningless if the compiler adheres to cdecl, I've shown that numerous times, you are just unable to see (your bad). operation 1 - place parameters as cdecl (try to learn something here please, it is important that you don't run away and hide inside C99): push param3 to address X+8 on the stack push param2 to address X+4 on the stack push param1 to address X on the stack call function function: get address of param1: MUST BE X! get address of param2: MUST BE X+4! get address of param3: MUST BE X+8! But I guess you will just keep on losing yourself here because cdecl is outside of C99. And if you try to leave the C99 box your brain crashes and
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #35 from matz at gcc dot gnu dot org 2010-08-13 13:00 --- char* p1=(char*)0x3000; // address not pointing to any C-object in the C99 sense char* p2=(char*)0x4000; // address not pointing to any C-object in the C99 sense Can GCC users trust that p2-p1 will always return a predictable and well defined integer value of 0x1000 on any platform with 16-bit or more that GCC currently supports or that will come to support in the future? [ ] Yes [x] No -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #36 from matz at gcc dot gnu dot org 2010-08-13 13:14 --- If you include real segmentation like on 80286, where there's no linear relationship between effective address and segment+offset, subtraction would have been prohibitively expensive to implement anyway. What you don't know is that when you subtracted far pointers the compiler generated the code to change seg16:ofs16 into abs20. What in the words real segmentation like on 286, where there's no linear relationship between effective address and segment+offset was unclear to you to expect that abs20==seg16*16+ofs16? The prohibitive expensive referred to the necessary lookup of the base in the LDT/GDT that would have been required for every far pointer subtraction. And you still wouldn't get around the size limitation of ptrdiff_t that was 16bit. What the hell are you talking about? I personally disassembled code in the late 80's to see how the compiler implemented 32-bit arithmetic on a 286. It did, and it did it well. You weren't able to go beyond 16 bits in the 80's? Did I say that? Let's see: size limitation of ptrdiff_t that was 16bit. Nope. I didn't. The point being that if ptrdiff_t is only 16 bit, then no matter how fantastically capable the compiler was in emitting 32bit arithmetic, the result of subtracting to char pointers pointing more than 64KB (or in fact 32KB) apart would not fit into a ptrdiff_t. No, not me, I don't want to write nonsense on the web, Maybe you don't necessarily want to. But ... , well, there we are. I prefer to be clear headed. One never knows when stuff one wrote on the net will come back and bite one in the ass!! I'm not sure you realize just how true that is. But keep going, you're by far one of the best trolls I've seen in GCC land. Much better than Pizarro. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #37 from paolo dot carlini at oracle dot com 2010-08-13 13:31 --- (In reply to comment #36) I'm not sure you realize just how true that is. But keep going, you're by far one of the best trolls I've seen in GCC land. Well, I can easily imagine more funny things to do, some even summer-specific, but indeed, can be interesting, from a psychological point of view, I mean ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #38 from rogerio at rilhas dot com 2010-08-13 14:47 --- (In reply to comment #36) If you include real segmentation like on 80286, where there's no linear relationship between effective address and segment+offset, subtraction would have been prohibitively expensive to implement anyway. What you don't know is that when you subtracted far pointers the compiler generated the code to change seg16:ofs16 into abs20. What in the words real segmentation like on 286, where there's no linear relationship between effective address and segment+offset was unclear to you to expect that abs20==seg16*16+ofs16? The prohibitive expensive referred to the necessary lookup of the base in the LDT/GDT that would have been required for every far pointer subtraction. From wikipedia: Rather than concatenating the segment register with the address register, as in most processors whose address space exceeded their register size, the 8086 shifted the 16-bit segment only 4 bits left before adding it to the 16-bit offset (16·segment + offset), therefore producing a 20-bit external (or effective or physical) address from the 32-bit segment:offset pair. So there you go: the relation between effective abs20 address and seg16:ofs16 pair. And it is a linear relation: abs20=K*seg+ofs establishes a linear relation. Check your algebra, and check x86 operation before saying random stuff. Can you guess how tricky it is for a compiler to get an effective abs20 address out of a seg:ofs pair? abs20=seg*16+ofs (voilá! ...magic!!) What are you dreaming about LDT/GDT? Do you think you need any of that to get an abs20 from a seg16:ofs16 pair? Or maybe you think that a far qualifier would noke the compiler carry seg16 and ofs16 everywhere it went? You just made that stuff up again. Michael Michael Michael: what did I tell you about making stuff up? You don't need to prove to anyone that you are creative, will all know that by now. ... and if Wikipedia is not good enough for you then you can learn about segmentation and how to compute effective addresses in many places. All will teach you what Wikipedia shows. I would teach you if you paid me. No, scratch that: I woudn't, so I'll just leave you alone on this one. And you still wouldn't get around the size limitation of ptrdiff_t that was 16bit. What the hell are you talking about? I personally disassembled code in the late 80's to see how the compiler implemented 32-bit arithmetic on a 286. It did, and it did it well. You weren't able to go beyond 16 bits in the 80's? Did I say that? Let's see: size limitation of ptrdiff_t that was 16bit. Nope. I didn't. The point being that if ptrdiff_t is only 16 bit, then no matter how fantastically capable the compiler was in emitting 32bit arithmetic, the result of subtracting to char pointers pointing more than 64KB (or in fact 32KB) apart would not fit into a ptrdiff_t. The code I used to do was somthing like long dif=ptr2-ptr1 (long was most often 32-bit back then). Why the hell did you bring ptrdiff_t to the conversation? I didn't get it, honestly. But if you brought it was was surely to show me that there was no point in doing 20-bit arithmetic because I would not be able to fit that result anywhere, right? Maybe not, you lost me with the whole ptrdiff_t that you decided to bring into the conversation. No, not me, I don't want to write nonsense on the web, Maybe you don't necessarily want to. But ... , well, there we are. Yup. You have still to make one valid claim, and I've been easily shooting you down everytime. And I back it up, isn't that an amazing concept? You should try it sometime. I prefer to be clear headed. One never knows when stuff one wrote on the net will come back and bite one in the ass!! I'm not sure you realize just how true that is. But keep going, you're by far one of the best trolls I've seen in GCC land. Much better than Pizarro. ... is troll code for guy who doesn't forgive any false claims and repeatedly shoots down and squashes people who do that repeatedly like a mean son of a insert_repulsive_animal_here that he is? In that case thanks! :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #39 from rogerio at rilhas dot com 2010-08-13 14:48 --- (In reply to comment #35) char* p1=(char*)0x3000; // address not pointing to any C-object in the C99 sense char* p2=(char*)0x4000; // address not pointing to any C-object in the C99 sense Can GCC users trust that p2-p1 will always return a predictable and well defined integer value of 0x1000 on any platform with 16-bit or more that GCC currently supports or that will come to support in the future? [ ] Yes [x] No Thanks. The comunity will be alerted to this. I'll get back to you when your name is in some famous place associated with this claim. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #40 from rogerio at rilhas dot com 2010-08-13 14:53 --- (In reply to comment #37) (In reply to comment #36) I'm not sure you realize just how true that is. But keep going, you're by far one of the best trolls I've seen in GCC land. Well, I can easily imagine more funny things to do, some even summer-specific, but indeed, can be interesting, from a psychological point of view, I mean ;) Possibly... I'm on vacation, so this morning I just played a little bit of Half Life 2 on the console (yes, keep the wise cracks to yourself, I know I'm severely outdated when it comes to video games!). Anyway, after about half an hour of killing zombies and shooting down bad guys I got bored. Turned on the PC and THERE WAS MICHAEL It is easier and more entertaining to shoot him down than zombies with a 5 year old AI. Then I went for a swim, had lunch with the family, and the Sun got to strong to be outside. What else is there to do?? I know!!! Let's check on Michael again!! :-) So you see: I do have a problem. I will seek help. Promise. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #41 from matz at gcc dot gnu dot org 2010-08-13 15:18 --- You should really adjust your glasses if you want to continue trolling with the high standards we're used to meanwhile: What in the words real segmentation like on 286, where there's no linear relationship between effective address and segment+offset So, I think it's pretty clear that I'm referring to the 80286, whereas you cite something ... From wikipedia: Rather than concatenating the segment register with the address register, as in most processors whose address space exceeded their register size, the 8086 shifted the 16-bit segment only 4 bits left ... about the 8086. To make it very obvious, even to you: 86 vs 286. As you have so huge experiences with such old processors, I'm sure you can guess what I meant with real segmentation aka protected mode now. In case you still can't and because we seem to start using wikipedia to back up claims: http://en.wikipedia.org/wiki/X86_memory_segmentation . Now, implement a routine that subtracts two pointer for this memory model. You'll see that it requires bit-magic on the segment selector, lookup in the GDT or LDT and finally some 24bit arithmetic to produce the result. The arithmetic is of course trivial, the lookup is expensive. Doing it for every pointer subtract was what I called prohibitive expensive for a normal pointer subtraction. That, together with the fact that all segments are max 2^16 in size, and that it's impossible to map back all 24bit numbers into segmented addresses without generally adding new entries into the GDT/LDT made it useless to have pointer differences any larger than 16 bit, not impossible but useless in real compilers. Therefore the result of such a subtraction isn't always representable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #42 from matz at gcc dot gnu dot org 2010-08-13 15:25 --- [ ] Yes [x] No Thanks. The comunity will be alerted to this. I'll get back to you when your name is in some famous place associated with this claim. That's very good. Though I'm a bit confused because you only wanted to post my name everywhere if I got the answer wrong. Now, it's very obvious that my answer is the only correct one. Well, nevertheless I'm looking forward to become famous. Thanks for your help in that, though I fear somebody else will become even more famous than me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #43 from rogerio at rilhas dot com 2010-08-13 16:28 --- (In reply to comment #41) You should really adjust your glasses if you want to continue trolling with the high standards we're used to meanwhile: What in the words real segmentation like on 286, where there's no linear relationship between effective address and segment+offset So, I think it's pretty clear that I'm referring to the 80286, whereas you cite something ... Oh really? Because you so cleverly used the word real to lead me to believe you were talking about real mode 286? How clever of you, you were talking about protected mode after all. Ok, after interpreting your incorrect wording I can give you that: 286 protected mode was a pain. You just dropped your error rate to less than 100%, kudos!! (should adjust your phrasing though, if you want to be correctly inrepreted) From wikipedia: Rather than concatenating the segment register with the address register, as in most processors whose address space exceeded their register size, the 8086 shifted the 16-bit segment only 4 bits left ... about the 8086. To make it very obvious, even to you: 86 vs 286. As you have so huge experiences with such old processors, I'm sure you can guess what I meant with real segmentation aka protected mode now. There is no thing as real segmentation, you must have made it up. The Linux community seems to talk a little about it... but I never saw Intel say or write anything about it when I was studying the 286. Linux guys use that expression, is that why you thought it was standard? Wrong. What Intel defined was real mode and protected mode. So you see what you do when you don't use your words correctly and call it real segmentation? Of course it would look like segmentation in real mode. Your bad. Unless you can backup real segmentation with some official doccument from Intel, can you? In case you still can't and because we seem to start using wikipedia to back up claims: http://en.wikipedia.org/wiki/X86_memory_segmentation . No mention of real segmentation. Is this what you wanted to show me? Now, implement a routine that subtracts two pointer for this memory model. You'll see that it requires bit-magic on the segment selector, lookup in the GDT or LDT and finally some 24bit arithmetic to produce the result. Yup, too much work. Better leave it alone and return some random pointer subtraction number. Better yet: don't compile such code. And never again guarantee to anyone anything about pointer subtraction unless it fits inside C99 box. I had one class on 286 which made us implement processes on a minimal protected mode OS for the 286. I can tell you it isn't that hard to read the LDT or GDT, and it didn't have any prohibitive performance penalty, contrary to what you claim. Maybe you are confusing yourself between reading from and writing to the GDT/LDT? Or maybe you can backup your claim that reading from GDT/LDT is prohibitive? The arithmetic is of course trivial, the lookup is expensive. Could you please back it up? That's contrary to my experience, you see, and since it lacks logic since the processor reads to those tables were designed to be fast to make it run fast... so I think you should back that up, otherwise it just looks like you are making it up (not to me though, I know it wasn't prohibitive). Doing it for every pointer subtract was what I called prohibitive expensive for a normal pointer subtraction. Yes, you are wrong to call it prohibitive. You just want to imagine it to be prohibitive so that you can stick to your claim that pointer subtraction result is not guaranteed by GCC *EVER* because of the 286. What a boring unsubstantiated argument. Without backing up such illogical claims its all just jiberish. So go ahead and find a techncal paper or report that shows that reading the LDT or GDT causes a significant performance penalty. Let's set a threshold: 50 instructions? So, ok: if you can find such a document that says that accessing those tables always costs 50 instructions or more then I'll grant you that the compiler should have an option to disable correct pointer subtraction. I will still not grant you an incorrect pointer subtraction by default, but I will insert apology here in that my experience with 286 was unexplainably better than yours. If you can't find such a document then insert apology here for making unsubstiated claims and forget about it (apology accepted). That, together with the fact that all segments are max 2^16 in size, and that it's impossible to map back all 24bit numbers into segmented addresses without generally adding new entries into the GDT/LDT made it useless to have pointer differences any larger than 16 bit, not impossible but useless in real compilers. Therefore the result of such a subtraction isn't always representable. In the copilers I used back then the far pointer was 32-bit, just like it was 32-bit on the
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #44 from rogerio at rilhas dot com 2010-08-13 16:30 --- (In reply to comment #35) char* p1=(char*)0x3000; // address not pointing to any C-object in the C99 sense char* p2=(char*)0x4000; // address not pointing to any C-object in the C99 sense Can GCC users trust that p2-p1 will always return a predictable and well defined integer value of 0x1000 on any platform with 16-bit or more that GCC currently supports or that will come to support in the future? [ ] Yes [x] No There you go, you are now famous. http://en.wikipedia.org/wiki/GNU_Compiler_Collection#Criticism The comunity has been warned about GCC. It was a good day's work after all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #45 from redi at gcc dot gnu dot org 2010-08-13 16:32 --- Congratulations. Are you done now? What else are you hoping to achieve? Is this a cry for attention? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #46 from rogerio at rilhas dot com 2010-08-13 16:42 --- (In reply to comment #45) Congratulations. Are you done now? What else are you hoping to achieve? Is this a cry for attention? No much really. Now it is all up to the community. I just want everyone to know that computing pointer subtraction is not guaranteed to be accurate on GCC. My personal gains will be (possibly): 1) Maybe the community can force GCC to start making such guarantees. That would help all of us. The example I posted there is real, I'm not making anything up! 2) Showing all of you that a compiler should be more than just C99. A good compiler need to be more than C99. And an excelent compiler must be more than just C99. All of you confine your answers to C99 forgetting that a compiler will be used in many real world situation, for example in memory mapped devices. 3) Showing Michael that he says a lot of crap. Show him that he just shot himself in the foot for not thinking before speaking. Maybe get him to think before making claims? Even with all my warnings he didn't think of people that compile for memory mapped devices? He should think before he says something, he is not just some random guy like me, he is a representative of the GCC project and his answers (crap included) are GCC-binding. I confess I get some satisfaction out of that 3rd item. But I would do it even if I had the first 2. The community at large thinks more like I do, and expect the pointer subtraction to always return accurate results. I'm just warning them. I'm not lying. I'm not distorting anything. If it helps someone then good, otherwise it can«t harm anyone, right? That's it, really. As for the bugs I reported I have no further hope. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #47 from ubizjak at gmail dot com 2010-08-13 18:00 --- OK, here is the deal: Since you want this feature so much, I'm sure that everybody would gladly implement it for you, for - say - measly 5000 EUR. You can then offer this c-like compiler to the world and save the planet. Just imagine, how the link to this enhanced compiler would be a great addition to your Wikipedia entry! You can even call this custom compiler whatever you like, except gcc. You will rewrite the history! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #48 from rogerio at rilhas dot com 2010-08-13 21:16 --- (In reply to comment #47) OK, here is the deal: Since you want this feature so much, I'm sure that everybody would gladly implement it for you, for - say - measly 5000 EUR. You can then offer this c-like compiler to the world and save the planet. Just imagine, how the link to this enhanced compiler would be a great addition to your Wikipedia entry! You can even call this custom compiler whatever you like, except gcc. You will rewrite the history! It sounds like a good deal. Really, I'm not being sarcastic in any way. I would like to have 5000 to invest on GCC. Maybe you all got me wrong: the reason I wrote the 2 bug reports is because I do think GCC is a *very important project for the community*. I'm being honest. If GCC were not important I would not have gone to any trouble at all, yet alone spend several hours writing 2 or 3 complete reports (with files and snapshots) and many messages. Maybe it is time for you to understand what I really am all about. I say stuff about GCC, I've called lowest common denominator (and I mean it), but I still think it to be among the top 5 most important compiler projects in the world (including Microsoft's and Intel's and a bunch of comercial compilers). It could be top 1, if it weren't for being so confined to C99 and not *want* to go beyond it. And I would like to have 5K to put on GCC. As I said I know I can't demand anything, after all the thing is being offered to me! Even more than that: it is being offered to me without me having ever contributed with a bit. So, as I said before, I'm not demanding anything (nor could I). I was just hoping that you would see the importance of my feature (although I still call it a bug and not a feature, and if you want I can give you examples of why it is important to be able to initialize classes as function parameters). You didn't see it? Or you saw it but you don't agree that it is important? I'll insist, I'll bring new angles to the discussion. Still no? I'll insist some more, maybe get some other examples. Nothing still? Whatever, I'll shut up and go away, no problem. The reason I'm still here is (to a great extent) because of Michael... that guy just cracks me up. It is possibly the person that I've ever known that has such a high error rate (it was up to 100% for a while there!). But this conversation has stopped being about my bug reports a long long long long time ago. I'm on vacation, so I have had more time on my hands than I'm used to, and Half Life 2 bores me a little if I play it for too long! :-) ... so I keep comming back. As I said before I will seek help. Just one more, this is the last one!!! Promise!! I'll buy a new game and leave you all alone soon! :-) I posted the criticism on Wikipedia not to hurt anyone in particular. But I do criticize GCC for not being able to guarantee correct pointer arithmetic. And me, as a citizen of this world, have the right to make my criticism and post it where everybody can see and judge for themselves. And, being an important criticism, I should back it up. So I did, and posted 2 references. I was very careful not to write anything that might be incorrect or misleading. I quoted our conversation almost exactly. And even with the different words I made sure the content is exactly the same as in my conversation with Michael. I didn't lie. I didn't distort. I didn't exagerate. I didn't take it out of context. I said it like it is, no more, no less. So here is the deal to you: If you all agree with Michael then my Wikipedia post is correct and has a reason to exist, and people like me will want to be alerted to what it says. Programmers don't go around reading C99, generally speaking they just try to write good code. That's it. I would guess 90%+ of programmers don't go out checking if their line of code is C99 conformant or not. However, I believe their code can be more than 99.9% C99 conformant, so very little people have any problems. I'm one such programmer, I hadn't read C99 before talking to you but 99.9% of what I do falls completely within the things defined in C99. But there is a fraction of what I do that does not fall there, and I still have to do it. And like me there are many others, who have a fraction of their work fall outside C99 (without knowing). And the code still has to work. Always. Guaranteed. And we trust the compiler to give us the expected result. Always. Guaranteed. If I am wrong in trusting it then I want to be alerted. That's all I did in the Wikipedia post: alert people that do code for memory mapped devices and similar (like I often do). So if you think Michael is correct then he is, in fact, a hero. He is the one guy, on the face of this planet that I know of, that had the balls to come out and say beware of pointer subtraction when using GCC!!. No sarcasm here, I trully believe this. If he is, in fact, right then I will personally thank him because up
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #49 from redi at gcc dot gnu dot org 2010-08-13 22:38 --- Please, start a blog and write your views somewhere else. PLEASE. You're rude, ignorant and annoying. (In reply to comment #48) of why it is important to be able to initialize classes as function parameters You clearly don't know what you're talking about. If you think the C++ language is incorrectly defined then take it up with the C++ Standard Committee, or your national standards body, not with GCC. GCC implements the C++ standard. If there's a problem with the standard, change the standard, not GCC. But the standard won't change in this respect. You cannot initialise a non-const reference with a temporary in C++, Microsoft's compiler is wrong to accept it, try Intel's compiler for confirmation if you don't believe me. Andrew already told you to read about rvalue-references, which allow you to bind a reference to a temporary, but you're too busy arguing to accept that maybe, JUST MAYBE, someone knows something you don't. So please, stop posting here and go away. Publish your ideas where someone gives a damn. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #50 from redi at gcc dot gnu dot org 2010-08-13 22:40 --- Oh, and if you do get people to understand that pointer arithmetic is not always well-defined, that would be a good thing. There are other people who share you're incorrect understanding of the C and C++ languages, so educating them is a good thing. But you won't do that by posting here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #51 from matz at gcc dot gnu dot org 2010-08-14 01:26 --- There you go, you are now famous. http://en.wikipedia.org/wiki/GNU_Compiler_Collection#Criticism Thank you, that's encouraging, I just hope the language of that article won't be changed too much to also mention everyone else who has a clue. Because, you see, I'm of course very excited about me being famous now and about being the only one who knows the truth, but OTOH I fear there were some other clever people that happen to agree with me, and I now see a real danger of those replacing me in that wikipedia article. Even worse would be that the list of names would be too large to mention in wikipedia and that the list would be replaced by some more unspecific phrases like people who actually understood the standard or the like. The comunity has been warned about GCC. Which community? Rogerio-cdecl church followers? In that case I'm happy, because I'll expect less bug-reports from supporters of that specific religion. I'll continue to feel sorry for them (especially because I've learned over the conversation that you might actually influence new programmers, which is a terrible thing to do for you) but am not particularly looking forward to seeing misguided and crippled attempts of creating meagre imitations of stumbling pseudo bug-reports, especially because we can have the best there is: Rilhas bugs! If, OTOH, you mean a different community, like for instance that consisting of people who actually write C source code, I don't see any warning about using GCC for them. If anything, it's more like an invitation to use GCC for developing because it's more standard compliant than other compilers. It was a good day's work after all. You mean writing down incoherent brain-dumps? Uhm, well, if that's all your day-work is about... more power to you! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #1 from rogerio at rilhas dot com 2010-08-12 14:52 --- Created an attachment (id=21469) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21469action=view) Preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #2 from rogerio at rilhas dot com 2010-08-12 14:52 --- Created an attachment (id=21470) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21470action=view) Compilation script -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #3 from rogerio at rilhas dot com 2010-08-12 14:54 --- Correction: If line char buffer[1000]; buffer[0]=0; _is removed then_ GCC then compiles the code as expected and dif will be 4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #4 from jakub at gcc dot gnu dot org 2010-08-12 15:08 --- Pretty please, before filing further bugs take time and learn C. The pointer subtraction triggers undefined behavior, because one pointer points to one object and the other pointer points to different object. See ISO C99, 6.5.6/9. In particular, in this testcase the functions are inlined and thus i and strp are just normal automatic variables in main, obviously nothing guarantees how they are laid out in the stack. But even if it isn't inlined, the behavior would be undefined. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #5 from schwab at linux-m68k dot org 2010-08-12 15:24 --- ISO/IEC 9899:1999, 6.9.1 Function definitions 9. Each parameter has automatic storage duration. Its identifier is an lvalue, which is in effect declared at the head of the compound statement that constitutes the function body (and therefore cannot be redeclared in the function body except in an enclosed block). *The layout of the storage for parameters is unspecified.* -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #6 from rogerio at rilhas dot com 2010-08-12 15:33 --- (In reply to comment #4) Pretty please, before filing further bugs take time and learn C. The pointer subtraction triggers undefined behavior, because one pointer points to one object and the other pointer points to different object. Pretty pretty please: before you give out such wrong and embarassing answers please take the time to learn the standards and also take the time to learn how to read. I'm subtracting 2 pointers of the same type. If you knew how to read you would have seen that p1 and p2 are of the same type. Or maybe you just don't know C, but I'm sure you can learn it so that you can be helpful to the GCC team and not waste my time. See ISO C99, 6.5.6/9. I did read it, but it is not the case here, you got it wrong. In particular, in this testcase the functions are inlined Where did you get that idea from??? They are not inlined, you are wrong, check the assembler before imagining what is hapening. and thus i and strp are just normal automatic variables in main, obviously nothing guarantees how they are laid out in the stack. Wrong, you should learn your C. You could have understood this by yourself if you realized that i works but 10 doesn't. If you knew your basic C you would know that both strp and i were passed by value, and so they are not the original in the main but instead copies in bug_example. I'm sure you would want it not to be so, to save face, but you said it now you're stuck with it. But even if it isn't inlined, the behavior would be undefined. Wrong again. Undefined by C99 but not undefined by cdecl. I didn't specify inline, so GCC should have made cdecl. If it didn't then GCC should not claim to be cdecl. So choose: is it GCC's bug possibility 1 or possibility 2? (is it really that easy for you to write such wrong answers for everyone to see and keep wasting my time like this??? ... do you think that helps GCC?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #7 from rogerio at rilhas dot com 2010-08-12 15:33 --- (In reply to comment #5) ISO/IEC 9899:1999, 6.9.1 Function definitions 9. Each parameter has automatic storage duration. Its identifier is an lvalue, which is in effect declared at the head of the compound statement that constitutes the function body (and therefore cannot be redeclared in the function body except in an enclosed block). *The layout of the storage for parameters is unspecified.* Wrong again. Undefined by C99 but not undefined by cdecl. So choose: is it GCC's bug possibility 1 or possibility 2? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #8 from redi at gcc dot gnu dot org 2010-08-12 15:52 --- (In reply to comment #6) (In reply to comment #4) Pretty please, before filing further bugs take time and learn C. The pointer subtraction triggers undefined behavior, because one pointer points to one object and the other pointer points to different object. Pretty pretty please: before you give out such wrong and embarassing answers please take the time to learn the standards and also take the time to learn how to read. Bravo, well trolled. I'm subtracting 2 pointers of the same type. If you knew how to read you would have seen that p1 and p2 are of the same type. Or maybe you just don't know C, but I'm sure you can learn it so that you can be helpful to the GCC team and not waste my time. Please stop trying to use GCC, we'll all be better off. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #9 from schwab at linux-m68k dot org 2010-08-12 15:52 --- The parameters contain copies of the argument values (6.9.1#10: as if by assignment). The address of a parameter has no meaning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #10 from matz at gcc dot gnu dot org 2010-08-12 16:00 --- Ahh, it's just so entertaining. C99 is a language, cdecl a calling convention. There is no 'cdecl compiler', it makes no sense to speak about such a thing. cdecl is a calling convention for function written in all kinds of languages. If you chose to program in C (and you claim you do), then you have to work by the rules the relevant language standard imposes on you. It has been shown multiple times to you (and you even agree), that what you do is outside of C99. Countering this with but it should still work, because 'cdecl' says so is invalid reasoning, a calling convention can't override any limitation the language standard imposes. What you want to program in is not C99 (or any C whatsoever), but rather Microsofts idea of what a language looking similar to C might look like-C. GCC makes no claim to support such language. It supports C99, and it supports the cdecl calling convention. It does not support the language that you think is C, but isn't. It might be conceivable that somebody implements a new language frontend for GCC that would support the Microsoft language without name, as long as that isn't the case (and you yourself aren't interested in developing such frontend) the bug reports remain invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #11 from rogerio at rilhas dot com 2010-08-12 16:04 --- (In reply to comment #8) (In reply to comment #6) (In reply to comment #4) Pretty please, before filing further bugs take time and learn C. The pointer subtraction triggers undefined behavior, because one pointer points to one object and the other pointer points to different object. Pretty pretty please: before you give out such wrong and embarassing answers please take the time to learn the standards and also take the time to learn how to read. Bravo, well trolled. I'm subtracting 2 pointers of the same type. If you knew how to read you would have seen that p1 and p2 are of the same type. Or maybe you just don't know C, but I'm sure you can learn it so that you can be helpful to the GCC team and not waste my time. Please stop trying to use GCC, we'll all be better off. Oh and that will make your colleague Jakub right about p1 and p2 be of diferent types? Does it make his answer intelligent? Sure, whatever you say, I'll follow your recommendation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #12 from redi at gcc dot gnu dot org 2010-08-12 16:09 --- Seriously, go away. I'll get far ruder if you're going to open bug reports worded like this: (In reply to comment #0) Don't bother trying to understand why I need the operand to work as stated in C99, or why I need the code to be cdecl compliant, that is too complicated for you and it would just confuse you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #13 from pinskia at gcc dot gnu dot org 2010-08-12 16:09 --- diferent types? He did not say different types but different objects. There is a difference between objects and types. This comes down to: a - b being undefined in C90/C99/C++98/C++03/C++0x because a and b are two different objects. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #14 from jakub at gcc dot gnu dot org 2010-08-12 16:11 --- I never claimed p1 and p2 have different types. They have the same type. But the standard paragraph I mentioned says: When two pointers are subtracted, both shall point to elements of the same array object, or one past the last element of the array object That is not the case in your testcase, strp and i are different objects. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #15 from rogerio at rilhas dot com 2010-08-12 16:15 --- (In reply to comment #14) I never claimed p1 and p2 have different types. They have the same type. But the standard paragraph I mentioned says: When two pointers are subtracted, both shall point to elements of the same array object, or one past the last element of the array object That is not the case in your testcase, strp and i are different objects. char* p1=random_address(); char* p2=another_random_address(); p1-p2 is always well defined, no matter to which objects they point to. After the subtracion they will point to objects of the same type (char's). So, you don't know your C nor C99 (we are reading it wrong). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #16 from redi at gcc dot gnu dot org 2010-08-12 16:17 --- (In reply to comment #15) char* p1=random_address(); char* p2=another_random_address(); p1-p2 is always well defined, no matter to which objects they point to. No. No it isn't. It really isn't. (In reply to comment #6) Pretty pretty please: before you give out such wrong and embarassing answers please take the time to learn the standards and also take the time to learn how to read. Maybe you should practice what you preach. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #17 from rogerio at rilhas dot com 2010-08-12 16:18 --- (In reply to comment #12) Seriously, go away. I'll get far ruder if you're going to open bug reports worded like this: (In reply to comment #0) Don't bother trying to understand why I need the operand to work as stated in C99, or why I need the code to be cdecl compliant, that is too complicated for you and it would just confuse you. ... o... now you got me scared. I will just go away before you call me C-ignorant or something really insightful like that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #18 from rogerio at rilhas dot com 2010-08-12 16:18 --- You know what? I did a small sample showing this bug to other people. They all understood it, but not you. They all know what it means C99+cdecl at the same time. You don't. I'm surprised at your lack of capacity for uderstanding. Well, as long as you are proud of yourselves then that is what really matters, right? Good luck with that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #19 from redi at gcc dot gnu dot org 2010-08-12 16:20 --- Everyone understands it, you're just wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #20 from dj at redhat dot com 2010-08-12 16:57 --- Just for fun, I compiled this test case with various levels of optimization. It works fine without optimization or with -O1, but segfaults at -O2 or -O3. That indicates that the program only works by coincidence, not by design - you've made assumptions about how GCC will interpret your sources, and those assumptions are wrong. In this case, your assumption is that bug_example_2 will always be a separate function, and will always be called as a separate function, and thus that you can assume some knowledge of the internals of the stack layout. The C language does *not* require that a function which is called, be called as a separate function, only that the semantics of the call be the same as far as the C language requires. The C language allows GCC to implement that function call in any way it chooses - and GCC chooses to implement it without actually doing a function call, but by copying the function body to the callee. At least, it does when optimizing. Without optimization, it *happens* to do what you expect. It will also do what you expect if bug_example_2 and bug_example are in separate source files - *then* the cdecl standard you refer to applies, because cross-object calls are limited by the compatibility standards. However - if you use gcc to link as well, gcc has the option of optimizing those calls *also*. So, GCC is cdecl compliant because *if* there's a function call, *then* the *stack* is laid out the same. However, the cdecl standard does *not* require that your program work, because C allows the optimizer to avoid the actual function call completely when the callee and caller are in the same scope. Note: you can tell gcc to not inline a function with __attribute__((noinline)) in which case a call to it is always an actual call to it, but it would be easier to just use the standard methods for accessing parameters so that it *always* works. Also, with full optimization enabled, your code crashes with MSVC also. Please file a bug report with Microsoft. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #21 from froydnj at gcc dot gnu dot org 2010-08-12 17:08 --- Even without optimization (as the compilation script uses), the program crashes. To be concrete about what's going wrong based on what the assembly code actually looks like (GCC version Ubuntu 4.4.3-4ubuntu5): bug_example: pushl%ebp movl%esp, %ebp subl$1048, %esp # space for buffer movl8(%ebp), %eax # move string elsewhere movl%eax, -1020(%ebp) movl%gs:20, %eax# stuff for stack checking movl%eax, -12(%ebp) xorl%eax, %eax movb$0, -1012(%ebp) leal12(%ebp), %eax # address of i to stack movl%eax, 4(%esp) leal-1020(%ebp), %eax # address of (copied) strp to stack movl%eax, (%esp) callbug_example_2 movl-12(%ebp), %eax xorl%gs:20, %eax je.L6 call__stack_chk_fail .L6: leave ret .sizebug_example, .-bug_example You are assuming that in `bug_example' that the parameters passed to `bug_example_2' must be the addresses of those variables *as they were passed on the stack*. This is certainly one way of implementing it, but it is not mandated by the standard (as comment #9 points out). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #22 from rogerio at rilhas dot com 2010-08-12 17:24 --- (In reply to comment #21) Even without optimization (as the compilation script uses), the program crashes. Right, that was the point of introducing the 1000-character buffer. With it it crashes always. To be concrete about what's going wrong based on what the assembly code actually looks like (GCC version Ubuntu 4.4.3-4ubuntu5): bug_example: pushl%ebp movl%esp, %ebp subl$1048, %esp # space for buffer movl8(%ebp), %eax # move string elsewhere movl%eax, -1020(%ebp) movl%gs:20, %eax# stuff for stack checking movl%eax, -12(%ebp) xorl%eax, %eax movb$0, -1012(%ebp) leal12(%ebp), %eax # address of i to stack movl%eax, 4(%esp) leal-1020(%ebp), %eax # address of (copied) strp to stack movl%eax, (%esp) callbug_example_2 movl-12(%ebp), %eax xorl%gs:20, %eax je.L6 call__stack_chk_fail .L6: leave ret .sizebug_example, .-bug_example You are assuming that in `bug_example' that the parameters passed to `bug_example_2' must be the addresses of those variables *as they were passed on the stack*. This is certainly one way of implementing it, but it is not mandated by the standard (as comment #9 points out). You are absolutelly right, I fully agree that a non-cdecl conformant GCC would not need to pass parameters on the stack. It only has to pass parameters on the stack (in a very well-defined way) if it claims to be cdecl-compliant. But even with the cdecl specifier in the source the generated assembly code is wrong. Hence a bug. Hadn't you realized yet that that is my point from the start -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #23 from rogerio at rilhas dot com 2010-08-12 17:25 --- (In reply to comment #19) Everyone understands it, you're just wrong. No I'm not, the problem seems to be just to complex for you because you would have to tie up C99+cdecl to understand, but you don't understand it because you don't know cdecl language (this still makes me laugh!) and so you don't get out of your little C99 box (which makes you lose sight of the big picture). char* p1=random_address(); char* p2=another_random_address(); Any compiler that does not predictably compute p2-p1 is a piece of crap. You can twist C99 all you want, but whenever p2-p1 is left to some undefined criteria of the compiler then it is just an absolute piece of crap. Period. That is why no compiler leaves this indefined, even GCC (apparently it was just luck). This should be enough for you to see you are not getting C99 right, because following what you say would create crappy compilers. Feel free to try and prove they would not be crappy. Even if you could convince me of your interpretation of C99 and p2-p1 were not well defined, you would still have to explain why strp is not 4 bytes before i (not subtracting, just looking at their disassembled addresses). This is the big picture that you do not understand, you just keep deflecting. ... while we discuss GCC still doesn't return the correct address for strp. So, let me just summarize by saying I was so so so so wrong to expect GCC to have returned the address that my little brain expected to result from the combination C99+cdecl. Of course I was wrong and you were right, which makes me stupit and you smart. Meanwhile everyone else knows that if it compiles in GCC and executes correctly then it compiles and executes correctly in any other compiler... can you deduce why? Does it make you proud? ... hint: which do you think is the compiler with the most reduced capabilities that serves as a baseline for your code? Would you like to keep GCC at this low end of the spectrum? Good, just keep on insisting on your interpretation of C99. http://en.wikipedia.org/wiki/GNU_Compiler_Collection In 2007, GCC received criticism from one OpenBSD developer who complained that GCC is mostly developed by companies, that it is large, buggy, slow, and that it generates poor code,[31][not in citation given][32] and who also dislike v3 of the GNU GPL.[33] The OpenBSD project and FreeBSD projects, respectively, are experimenting with replacing GCC with the Portable C Compiler[33] and Clang/LLVM.[34] The NetBSD and DragonFlyBSD projects have commented that on replacing GCC, they have explored various compiler replacements but have no solid answers.[35] (I've checked the references, they are fine!!) Does it have anything to do that you dismiss people who find and show you bugs? Maybe you do a good job when you quickly send them away after stamping it with non-conformant, I don't know, but I expected a little more interest on your part to make GCC better. I would be open to anything, including something along the lines of ok, it is not a bug, but we will consider this as a feature request... but not even that. I'll come back some day (be afraid!! :-) ) with a list of compilers tested to see how many produce correct results for this bug report. For now in 4 compilers tested (2 from Microsoft) 3 of them do the job correctly and GCC is the only one that doesn't. Oopss...! I meant: GCC is the only one to have correctly interpreted C99, the other 3 got it wrong and let me get the addresses of the parameters as I wrongfully expected. And let me subtract them predictably. This surelly proves you are very insightfull and that you know C99 better than anyone else. Gone, sorry for any inconvenience. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #24 from rogerio at rilhas dot com 2010-08-12 17:50 --- (In reply to comment #20) I couldn't resist to comming back (you respond very quickly, kudos!, I'm not used to that! :-) Just for fun, I compiled this test case with various levels of optimization. It works fine without optimization or with -O1, but segfaults at -O2 or -O3. The script I sent you does not request optimizations and segfaults. That indicates that the program only works by coincidence, not by design - you've made assumptions about how GCC will interpret your sources, and those assumptions are wrong. In this case, your assumption is that bug_example_2 will always be a separate function, and will always be called as a separate function, and thus that you can assume some knowledge of the internals of the stack layout. When I don«t request optimizations my interpretation is right. A function declaration (that doesn't specifically request inline) is a function. I don't know if C99 says it (probably does, in a C-sense function), but cdecl does. The C language does *not* require that a function which is called, be called as a separate function, only that the semantics of the call be the same as far as the C language requires. The C language allows GCC to implement that function call in any way it chooses - and GCC chooses to implement it without actually doing a function call, but by copying the function body to the callee. At least, it does when optimizing. Without optimization, it *happens* to do what you expect. Compile it like I did in the script (without optimizations) and see it fail. It will also do what you expect if bug_example_2 and bug_example are in separate source files - *then* the cdecl standard you refer to applies, because cross-object calls are limited by the compatibility standards. However - if you use gcc to link as well, gcc has the option of optimizing those calls *also*. So, GCC is cdecl compliant because *if* there's a function call, *then* the *stack* is laid out the same. However, the cdecl standard does *not* require that your program work, because C allows the optimizer to avoid the actual function call completely when the callee and caller are in the same scope. Incorrect, code should not be optimized if I don't request it. If I do I have to live without cdecl compliance, obviously, as I don't know of any compiler that has an option like optimize_as_possible_but_keep_cdecl_always. My point is for non-optimized code, and that is why I included the scrip I used to build it. Note: you can tell gcc to not inline a function with __attribute__((noinline)) in which case a call to it is always an actual call to it, but it would be easier to just use the standard methods for accessing parameters so that it *always* works. Agreed. But I'm determining the addresses of the parameters just to check GCC's conformity, remember? So don't you worry about how easy the code is for me, I will deal with that. I just tried the attribute and didn't make any difference in the code, and is still not cdecl. I'm sure it is not a bug in GCC though... Also, with full optimization enabled, your code crashes with MSVC also. Right. As explained, this bug report is about non-optimized code. I also didn't expect Microsoft's code to not crash if optimized (nor tried it until your comment). I don't think I ever mentioned optimizations in this bug report, I did it in the variable parameters bug report bucause that was how I initially got it to crash and had no way to report it to you (it crashed without optimizations in a larger program that I could not send to you), but I later sent you a full report (with snapshots and all in comment #51) a non-optimized version that crashed. Here I could easilly show it to crash when not optimized, and so I could live with disabling optimizations to get the addresses to be returned properly. Please file a bug report with Microsoft. No need. Their code *NEVER* crashes if I don't request optimizations. This is it, I must resist! Bye!! :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #25 from redi at gcc dot gnu dot org 2010-08-12 17:53 --- (In reply to comment #23) Maybe you do a good job when you quickly send them away after stamping it with non-conformant, I don't know, but I expected a little more interest on your part to make GCC better. I would be open to anything, including something along the lines of ok, it is not a bug, but we will consider this as a feature request... but not even that. You opened this bug report with insults, what sort of response do you expect? GCC is too crappy and amateur for your awesome code, so I suggest you stick to better compilers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #26 from rogerio at rilhas dot com 2010-08-12 18:04 --- You opened this bug report with insults, what sort of response do you expect? GCC is too crappy and amateur for your awesome code, so I suggest you stick to better compilers. Will do, thanks. ... and sorry for my opening lines, I was very pissed off that after a great deal of work making a full report you didn't see that problem was not related to the variable arguments and it seemed to me that you were not even bothering to to read it, and kept dismissing me as trying to do non-conformat things. That is what motivated me to isolate the problem for this bug report, and I am sorry I was unable to put on a happy face, my bad. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #27 from matz at gcc dot gnu dot org 2010-08-12 18:05 --- Oh, this fun. Enjoyable, really! ;-) So, you admit that MSVC does in fact miscompile your perfectly fine cdecl code, if you request optimization from it? How bad is that of them? Terrible! I would consider creating a bug report with them, because if they miscompile your code with optimizations it must surely be their bug. After all optimization is a process of transforming a valid program into another program that behaves exactly the same, hence if they optimize your valid program into a crasher, what else could it be than a bug in their compiler? I mean, really. They are supposed to provide a commercial grade compiler. How can it be that they force you to deactivate optimization options (and hence live with slow runtime) just so that your valid cdecl program doesn't crash? One side remark about your p2-p1 claim: char* p1=random_address(); char* p2=another_random_address(); Any compiler that does not predictably compute p2-p1 is a piece of crap. You can twist C99 all you want, but whenever p2-p1 is left to some undefined criteria of the compiler then it is just an absolute piece of crap. Period. You obviously never used segmented platforms (old DOS was such a thing, but there are others more recent, e.g. Cell with PowerPC is similar in this respect). On those it was valid only to sunstract pointers from each other when they pointed into the same segment. Because the pointer difference type was a 16 bit type, whereas the pointers could address 1MB of memory (hence effectively 20 bit). If you do the math you'll see that it's impossible to map all 2^20 possible differences between pointers (unsigned 2-completement 20-bit arithmetic, otherwise 2^21 differences) into just 16 bit. So yes, on those platforms it really was impossible to substract two arbitrary pointers. C (the language) reflects such constraints. With complete trust in your incapability to grok these concepts. but hats off to a capable troll, Michael. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #28 from dj at redhat dot com 2010-08-12 18:08 --- I built your test case with gcc and g++ without optimizations, and it worked fine. I could only get it to fail with gcc/g++ by optimizing, but then, I could get it to fail with MSVC by optimizing. Seems to me, gcc and MSVC are doing the same thing, or you have some modified version of gcc that is not acting the same way as the official version. Also, please provide an official spec for this cdecl you keep referring to. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #29 from rogerio at rilhas dot com 2010-08-12 18:24 --- (In reply to comment #27) Oh, this fun. Enjoyable, really! ;-) Again I couldn't resist! Everytime I'm ready to go away you say something shocking that I simply can«t resist. Its time for me to admit I have a problem! :-) So, you admit that MSVC does in fact miscompile your perfectly fine cdecl code, if you request optimization from it? Yes. How bad is that of them? Not perfect, but still better than GCC, because at least I can get it to work. Terrible! ... n... that's just your jealousy talking because you can't even begin to understand how to make a temporary variable an l-value... how can someone be defending a compiler that never conforms (GCC) to one that conforms if I don't request it to optimize? That's just bad logic. It's not my intention to insult you, but the observation itself lacks any underlying logic. I would consider creating a bug report with them, because if they miscompile your code with optimizations it must surely be their bug. No, optimizations take away room for assumptions. That's why GCC can optimize for(i=0; istrlen(sp); i++). What??? GCC didn't call strlen() every time? How stupid! No, you are just lacking logic. Drink something with vitamins and get out more, it will do you good. After all optimization is a process of transforming a valid program into another program that behaves exactly the same, hence if they optimize your valid program into a crasher, what else could it be than a bug in their compiler? Read my strlen() example. That shows you are wrong. You invented that definition, you can't really back it up otherwise strlen() would have to be called every time. I mean, really. They are supposed to provide a commercial grade compiler. How can it be that they force you to deactivate optimization options (and hence live with slow runtime) just so that your valid cdecl program doesn't crash? Yup, money can only buy so much. No money can buy you alittle bit less. One side remark about your p2-p1 claim: char* p1=random_address(); char* p2=another_random_address(); Any compiler that does not predictably compute p2-p1 is a piece of crap. You can twist C99 all you want, but whenever p2-p1 is left to some undefined criteria of the compiler then it is just an absolute piece of crap. Period. You obviously never used segmented platforms (old DOS was such a thing, but there are others more recent, e.g. Cell with PowerPC is similar in this respect). Yes I did work with those platforms. Remember the far qualifiers? Remember what they were for? They were invented to make you, again, write something wrong. However, as parameters to functions, they were always in the same segment, so the subtraction was always valid. C99 cannot back this up though, it was just the way things were made back then. Maybe GCC inherited too much from those days. On those it was valid only to sunstract pointers from each other when they pointed into the same segment. Not really, you could always subtract. However, far pointers gave predictable addresses, just like C99 says they pointer arithmetic should. Go and read C99 about the far qualifier so that you can see why it was not smart of you to talk about DOS. Still, on every segmented platform, the subtraction of the addresses of parameters is always valid, as parameter will be all placed on the same stack. And if some parameters had far qualifies and other not then the compilers would warn you about it so that you could requalify them. Don't talk about what you don't know, you clearly know much less about the old days than me. Stick to C99. Because the pointer difference type was a 16 bit type, whereas the pointers could address 1MB of memory (hence effectively 20 bit). If you do the math you'll see that it's impossible to map all 2^20 possible differences between pointers (unsigned 2-completement 20-bit arithmetic, otherwise 2^21 differences) into just 16 bit. So yes, on those platforms it really was impossible to substract two arbitrary pointers. No. Pointers of the same type, with the same qualifiers, were always subtractable. Don't invent, it will just make you wrong. The addresses of parameters on the stack would always be near (16-bit), so subtraction would always be well-defined. C (the language) reflects such constraints. Not really, no. Or can you back up your claims with an old standard applycable 30 or 40 years ago? I'm sure you can't. I don't even know if cdecl was well defined back then, do you? With complete trust in your incapability to grok these concepts. but hats off to a capable troll, Michael. Its is amazing how foast you take your self out and crash head-on into a wall. And be proud of it. But you are right, this is fun. Keep on sending your errors, inventions, inconsistencies, and mistakes, and I'll keep on correcting them. Then you deflect and try to pretend that you said smart
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #30 from pinskia at gcc dot gnu dot org 2010-08-12 18:27 --- you can't even begin to understand how to make a temporary variable an l-value. Please look up move constructors and rvalue references. move constructors are not standard C++ code but the C++ standard committee decided to add rvalue references instead. Please read the history of those and then come back when you understand what you are talking about. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #31 from rogerio at rilhas dot com 2010-08-12 18:32 --- (In reply to comment #28) I built your test case with gcc and g++ without optimizations, and it worked fine. Just like my script? I noticed that I'm using a not-the-newest GCC version, and I know that some older version 3.xxx didn't have the problem (a few years ago). Maybe it is something changed in the most recent versions? I could only get it to fail with gcc/g++ by optimizing, but then, I could get it to fail with MSVC by optimizing. Seems to me, gcc and MSVC are doing the same thing, or you have some modified version of gcc that is not acting the same way as the official version. I'm sorry, but I'm new to Linux, I'm not sure if the GCC I'm using got tweaked in any way. It came with Ubuntu, but I don't know if it got upgraded with Code::Blocks. I thought that -save-temps would provide you with that information, didn't it? How can I get such information? Also, please provide an official spec for this cdecl you keep referring to. Sorry, I did send you one in my variable arguments report and I forgot to send it here olso. http://sco.com./developers/devspecs/abi386-4.pdf, see Figure 3-48: C Stack Frame. It is not a standard, as I'm sure you know, but it is a well-defined concept. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #32 from rogerio at rilhas dot com 2010-08-12 18:38 --- (In reply to comment #30) you can't even begin to understand how to make a temporary variable an l-value. Please look up move constructors and rvalue references. move constructors are not standard C++ code but the C++ standard committee decided to add rvalue references instead. Please read the history of those and then come back when you understand what you are talking about. If I were to follow your logic I would, because acording to your logic a parameter doesn't have an address. But C99 doesn't limit this in any way, does it? The get the address of the item, period. So I don't need to go look up unrelated topics, you are the one who should look up address of parameter. function(class_name(initializer)) ... should work if class_name(initializer) were an lvalue. One of you posted a standard for that. Microsoft can get the address of class_name(initializer), hence Microsft is capable of looking at class_name(initializer) as an l-value. How Microsoft does it is not important, they do it and GCC doesn't. So Microsoft can compile all these equivalently: int a=10; function(i) function(int(20)) function(class_name(initializer)) I don't really care what GCC could do to make class_name(initializer) an l-value, but if move constructors are a good way to go at it then do it. As C99 doesn't specify this GCC is happy and doesn't need the feel to change. And, so, I don't call it a bug, just a very nice feature that it is missing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #33 from matz at gcc dot gnu dot org 2010-08-12 18:56 --- Don't talk about what you don't know, you clearly know much less about the old days than me. Well, I'll grant you that you know many wondrous and astounding facts, indeed. Let me just answer one random sentence out of your answer, just to keep it funny: Not really, you could always subtract. However, far pointers gave predictable addresses, just like C99 says they pointer arithmetic should. They didn't. If you subtracted far pointers that pointed into different segment, the segment difference was ignored. If you include real segmentation like on 80286, where there's no linear relationship between effective address and segment+offset, subtraction would have been prohibitively expensive to implement anyway. And you still wouldn't get around the size limitation of ptrdiff_t that was 16bit. And of course the subtraction of addresses of parameter is always meaningless in C, segmented or not, as pointed out multiple times. With or without cdecl. Or, another one: No, optimizations take away room for assumptions. Um, huh? That's completely backwards. Optimizations make _use_ of the assumptions/guarantees that the relevant standard gives you. Drink something with vitamins and get out more, it will do you good. That is certainly a good advise. I OTOH would advise you to possibly drink more alcohol. Much more. Really much much more. Go and read C99 about the far qualifier so that you can see why it was not smart of you to talk about DOS. C99 doesn't mention such qualifiers. I said that the restrictions in the standard (in this case which pointers can be compared/subtracted) have their reason in wanting to support all imaginable memory models. Nevertheless those restriction apply to _all_ implementations, even those that have trivial memory models, like a flat address space. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
