[Bug c++/45265] New: GCC has an intermittent bug when computing the address of function parameters

[Bug c++/45265] New: GCC has an intermittent bug when computing the address of function parameters

[rogerio at rilhas dot com]

The following code:

void bug_example_2(const char** format_address, int* ip) {
        char* p1=(char*)format_address;
        char* p2=(char*)ip;
        int dif=p2-p1;
        if (dif!=sizeof(char*)) {
                // crash
                char* p=0; *p=0;
        }
}

void bug_example(const char* strp, int i) {
        char buffer[1000]; buffer[0]=0;
        bug_example_2(&strp, &i);
}

int main(void) {
        bug_example("GCC has a bug", 10);
        return 0;
}

... is incorrectly compiled by GCC. As you can see there are no variable
parameters in this code, so there is nothing here out of the ordinary.

Possibility 1) GCC is not cdecl-ABI compliant, so the "dif" can have values
other than 4 on x86-32. In this case GCC should not claim to be
cdecl-compliant.

Possibility 2) GCC is not conformant to C99 but it is cdecl-ABI compliant. C99
states in section 6.5.3.2 paragraph 3 that "The unary & operator yields the
address of its operand.", but GCC is not doing that, as the "if" in
bug_example_2 is occasionally entered. Thus "dif" is not 4 (and with cdecl ABI
it should be 4 on x86-32).

If line "char buffer[1000]; buffer[0]=0;" GCC then compiles the code as
expected and "dif" will be 4.

This proves GCC is not conforming to C99 recommendations or that is not
cdecl-ABI compliant (or possibly both).

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. For the purpose of this bug you may simply
consider that I'm performing conformity tests on GCC against C99 and cdecl, and
that GCC failed the test.

Next I will send you the preprocessed file and the compilation script.


-- 
           Summary: GCC has an intermittent bug when computing the address
                    of function parameters
           Product: gcc
           Version: 4.3.3
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rogerio at rilhas dot com
 GCC build triplet: i686-virtualboxvm-ubuntu?
  GCC host triplet: i686-virtualboxvm-ubuntu?
GCC target triplet: i686-virtualboxvm-ubuntu?


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

[rogerio at rilhas dot com]

------- 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=21470&action=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

[rogerio at rilhas dot com]

------- 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=21469&action=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

[rogerio at rilhas dot com]

------- 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

[jakub at gcc dot gnu dot org]

------- 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

[schwab at linux-m68k dot org]

------- 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

[rogerio at rilhas dot com]

------- 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

[rogerio at rilhas dot com]

------- 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

[schwab at linux-m68k dot org]

------- 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

[redi at gcc dot gnu dot org]

------- 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

[matz at gcc dot gnu dot org]

------- 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

[rogerio at rilhas dot com]

------- 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

[redi at gcc dot gnu dot org]

------- 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

[pinskia at gcc dot gnu dot org]

------- 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

[jakub at gcc dot gnu dot org]

------- 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

[rogerio at rilhas dot com]

------- 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

[redi at gcc dot gnu dot org]

------- 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

[rogerio at rilhas dot com]

------- 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.


... ooooo... 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

[rogerio at rilhas dot com]

------- 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

[redi at gcc dot gnu dot org]

------- 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

[dj at redhat dot com]

------- 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

[froydnj at gcc dot gnu dot org]

------- 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
    movl    8(%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)
    leal    12(%ebp), %eax      # address of i to stack
    movl    %eax, 4(%esp)
    leal    -1020(%ebp), %eax   # address of (copied) strp to stack
    movl    %eax, (%esp)
    call    bug_example_2
    movl    -12(%ebp), %eax
    xorl    %gs:20, %eax
    je    .L6
    call    __stack_chk_fail
.L6:
    leave
    ret
    .size    bug_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

[rogerio at rilhas dot com]

------- 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

[rogerio at rilhas dot com]

------- 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
>     movl    8(%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)
>     leal    12(%ebp), %eax      # address of i to stack
>     movl    %eax, 4(%esp)
>     leal    -1020(%ebp), %eax   # address of (copied) strp to stack
>     movl    %eax, (%esp)
>     call    bug_example_2
>     movl    -12(%ebp), %eax
>     xorl    %gs:20, %eax
>     je    .L6
>     call    __stack_chk_fail
> .L6:
>     leave
>     ret
>     .size    bug_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

[rogerio at rilhas dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4182 bytes --]



------- 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

[redi at gcc dot gnu dot org]

------- 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

[rogerio at rilhas dot com]

------- 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

[matz at gcc dot gnu dot org]

------- 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

[dj at redhat dot com]

------- 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

[rogerio at rilhas dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5200 bytes --]



------- 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!

... noooo... 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; i<strlen(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 things and send
me a bunch of errors again. We could make a really fun game out of it.


-- 


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

[pinskia at gcc dot gnu dot org]

------- 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

[rogerio at rilhas dot com]

------- 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

[rogerio at rilhas dot com]

------- 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

[matz at gcc dot gnu dot org]

------- 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

[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters

[rogerio at rilhas dot com]

------- 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 you just
have to run back inside C99 and miss the point again. And shoot out some crappy
malformed argument about why I am oh just so wrong.

Colleagues of yours did confirm it, so that "With or without cdecl" is just you
making it up, not the truth. Do you want me to quote your colleagues? I think
it would look bad on you if I did that, but I will if you like.


> 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.


c0=get_total_instructions_from_cpu();
for(i=0; i<strlen(big_string); i++) call_big_function();
c1=get_total_instructions_from_cpu();
selected_country=c1-c0;
while(1) launch_missile_to(selected_country);

You've developed, compiled it, and everytime you ran it it always bombed my
country, and you were happy. Then you optimized and it started bombing your
country. And you didn't know why. You simply didn't know. You didn't
understand, because you believe with all your heart that the compiler is
supposed to do "functionally equivalent" code, and that that equivalency is
guaranteed. You push your brain to the max, and you strugle and you strugle and
you strugle and go up and down on C99 and there is nothing there to tell you
what went wrong!

I do understand why. The compiler will make *a number of assumptions* about
what you want to do. And most of the times it will be right to do so. One of
the assumptions that the compiler makes is that you (as a programmer) don't
care about the number of CPU instructions executed. The compiler will be right
to assume so, because 99.99999% of all programmers really don't care about the
number of instructions executed, or, in the very least, they want the number to
be as low as possible.

But there will come some guy that really needs to know the number of CPU
instructions because he needs to synchronize the something to the whatever, and
so the compiler will not generate "functionally equivalent" code.

By definition, optimized code is not equivalent. So "functionally equivalent"
is something that you just made up and defined poorly because you don't know
what the function will be. This particular function needs the number of CPU
instructions executed, so this particular function will not be optimized to
another "functionally equivalent" function.

You think you know what "functionally equivalent" because you didn't step out
of your C99 box (which doesn't specify what functions people will want to do in
the whole wide world) but that just makes you wrong and careless in your
claims. And so I keep proving you wrong very easily, because in the real world
a function is something with a meaning that you cannot possible imagine that
you know everything about.

So you should be more careful because all this is leaving a permanent record
with your name on it for everyone to see how consistently wrong you always are
and how you don't think things through before you write something. Worse, the
GCC is bound to your claims, so everyone there should help you not make such
mistakes repeatedly.

I'm one of those guys: I want to get addresses of parameters. The compiler
expects that no one cares about the addresses of parameters (and it will be
right to do so 99.9999999% of the time), so it may feel free to change those
addresses when I ask it to optimize. (it shouldn't if I explicitly used the
cdecl keyword, but unfortunatelly many programers abused it so now the compiler
cannot optimize a lot from many libraries if it doesn't ignore cdecl when
optimizing).

So it would be dumb of me to get the addresses of parameters with optimized
code, like it would be dumb for the bomber to optimize his bombing code when he
relies on the number of instructions. He should know the optimizing compiler
could change the number of instructions and so should not optimize his code. So
I know that optimizing may make code not comply to cdecl anymore and, so, the
addresses of parameters may come out wrong.

Clear enough for you now? I think I've reached the limit of what words can
express, as is all fairly obvious and I don't see why you missed it.

BTW: in my "real world" applications built with Microsoft's compilers I was
always able to optimize the variable parameters functions and the compiler
still gave me the correct addresses. To prove this you can compile the code I
sent you in MS VS 2008, with optimizations on, and confirm by yourself that it
works. I've made many variations of it over the years and it never failed me,
so much so I trust it implicitly these days.

Maybe Microsoft has special code in the optimizing compiler to handle the
specific case of variable parameter arguments in a cdecl-conformat way always,
who knows? Or maybe they suspected that those types of functions could likelly
be used by users to access parameters directly and so they needed to respect
cdecl even when optimized.

So, the conclusion, is that MS made the right option to, at least, not mess up
cdecl in variable argument functions, and another right option of not
optimizing if the user didn't request it. By comparison GCC made zero good
options here.


> > 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.


Why? So that we can be on the same page?? No, not me, I don't want to write
nonsense on the web, 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!!


> > 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.


Exactly. Don't tell me you went there looking for it!! I was being sarcastic as
a short way to tell you that you were on your own for this discussion, C99
would not help you.


>  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.


And in your mind a C standard cannot abstract from a sgmented memory model.
Right. I know what you think, I'm just glad it is not true, as it is very
confortable for me to have compilers abstract me from the underlying
architecture and always return valid and correct pointer diferences no matter
what. I'll keep on trying out compilers and platforms and will let you when I
find one combination of those that does what you say. I will then throw it
away, as a piece of crap that it will be, but I'll come back to let you know
that I found one.


>  Nevertheless
> those restriction apply to _all_ implementations, even those that have trivial
> memory models, like a flat address space.


Just to make sure you leave a useful contribution to the world (and because you
already lost track of the original issue) please tell me:

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
[ ] No

Please think thoroughly before you answer, as I will feel free to use your
answer as GCC-binding in any public forum I like.

As you might have guessed by the tone of this comment I was wrong to think this
would be a fun game. I'm begining to feel your comments don't deserve any
respect. I'll come back to see if you answered "yes" or "no" to the question
above. If you answered correctly I'll just leave you alone then and won't try
to backtrace our conversation to my initial comment to show you I was right
from the start about the pointer arithmetic and that you were wrong to not look
beyond C99. If you select the wrong answer you will see your name posted on a
lot of public forums binding GCC to what you said. Sorry if I crossed any lines
with you, I tried hard not to be disrespectful (but it is a very difficult
task!!).


-- 


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

[matz at gcc dot gnu dot org]

------- 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

[matz at gcc dot gnu dot org]

------- 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

[paolo dot carlini at oracle dot com]

------- 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

[rogerio at rilhas dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4322 bytes --]



------- 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

[rogerio at rilhas dot com]

------- 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

[rogerio at rilhas dot com]

------- 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

[matz at gcc dot gnu dot org]

------- 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

[matz at gcc dot gnu dot org]

------- 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

[rogerio at rilhas dot com]

------- 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 seg16:ofs16 pair. So the compilers we used didn't need to check
on any GDT/LDT as they approached a flat 24-bit memory model and could do all
arithmetic with the 32 bits alone.

Didn't your compiler do that?? What did it do with a far pointer? Keep only the
16 bits? Really???? So you could only access 64k then? Crappy compiler. Your
point has been proven for your crappy compiler, congratulations.

I don't know how the compilers I used converted near to far and back, but we
didn't really used to do that. However that is not the point because I never
asked you about pointer subtraction with mixed qualifiers.

In fact, you are just digging a deeper and deeper hole for yourself, as I
placed 2 equivalent pointers:

char* p1=...
char* p2=...

... and then asked about their subtraction. None of them is far, because (as
you should know) the default was near in just about every compiler
(naturally!!).

So you made up segmentation as an excuse, and you are drifting away form the
original issue. That issue is that, on any platform, pointers defined like this
must *ALYWAYS* return the correct difference.

And for that original issue (as for many others we started making up as we went
along) you are just wrong. Had I written "far char*"... but I'm not stupid. I'm
just a mean son of <some animal>, right?

:-)


-- 


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

[rogerio at rilhas dot com]

------- 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

[redi at gcc dot gnu dot org]

------- 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

[rogerio at rilhas dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1807 bytes --]



------- 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

[ubizjak at gmail dot com]

------- 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

[rogerio at rilhas dot com]

------- 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 to this
point I trusted pointer subtraction implicitly for *ANY* compiler in the world.
My conversation with him shows that I've been trusting that since the 80's,
from the time of the 8086 or 80286. And I've been successful always, so I kept
on believing all these decades.

So, at the same time I criticize GCC's "unreliable pointer subtraction" I could
write in Wikipedia that Michael is the guy who provided this information to the
world. If he is right then I already did that and his name is there for the
credits. And I already know he truly believes he is right, so I must not have
hurt his feelings in any way.

I wrote the criticism on Wikipedia because I really believe that if Michael is
right then GCC is a very big risk for memory mapped devices (or cases that need
similar constructs). And I do believe it is unacceptable to any developper that
code that is working today may break tomorrow for some unexpected event
(unexpected on the programmers part, since memory mapped devices are outside
C99's definitions). I kid you not, I've seen problems cause by compilers too
many times.

As I told you before I had 3 reasons to post my message there: any of the first
2 would have been enough to go to Wikipedia, the 2 together even more, the 3rd
is just an added bonus, by itself it wouldn't justify posting anything
anywhere. And Michael said a lot of crap, but only the pointer subtraction was
important enough to affect the programmer's assumptions and merit public
display. The rest I just ignored.

As we both know, code built with GCC (or any other compiler) always produces
correct results. And we know the results will forever be correct, because one
would have to write specific code in the compiler to mess up the arithmetic at
those specific instances not defined by C99 (something like "if (p1 or p2 not
in c99 known space) then mess up p2-p1"). But according to Michael we cannot
trust that, officially, because C99 does not define it, and I criticize that
(and a large part of the comunity will too). Hence my hope that GCC will
benefit from the post, in the long run.

Now if Michael is wrong then that is a completely diferent matter. Personally I
believe he is wrong, and I think he is an idiot. He let his personal pride and
inability to take a criticism and shut up reach the point where GCC got hurt.
He should have seen I'm not stupid. He should have realized I'm not your
average run-of-the-mill pain in the ass. He should have suspected he was going
to get hurt if he were not careful. He should have realized he was officially
speaking on behalf of the GCC project and should have taken a step back. But,
as I said, the guy just throws himself head on into walls.

I don't say this of the rest of you: you've given me your opinions, and I have
respected them (at least I tried, but I didn't always succeeded as was pointed
out to me about my "opening lines" for this bug report, and I already
apologised for that). So, for the rest of you, I just say you are wrong for
being so confined to C99, but I don't think you are idiots for that.

On top of that I don't know how busy you are, so even after realizing that you
didn't read all my posts and reports thorougly I still cannot blame you for
that. Seen that GCC has many comercial interests behind it I don't even know if
you are getting paid by some company to put up with me or if you are doing it
just for "the fun of it". So I must be understanding, and I tried to be.
Furthermore, I recognize that I must be humble about it and I cannot make any
demands about GCC, so I didn't. And if that is your opinion then tough luck for
me. No sarcasm here either, I agree.

However, if Michael is wrong then he is, in fact, an idiot. I already think he
is an idiot, but if he is wrong then everybody will know it. If this is the
case Michael should recant. He should swallow up his pride and just come out
and admit it. Not for me, but because this matter is much more serious than he
thinks. A lot of people out there trust GCC implicitly, without having read
C99.

If Michael recanted my temptation would be to leave the post in Wikipedia and
add "However, Michael later recanted", just to to screw with him. That would
teach him that once you say it its out there and there is no getting it back.
Maybe teach him to think before saying unsubstantiated crap. Maybe the GCC bug
tracking team would benefit if Michael could learn such a lesson.

However I'm not really a petty guy, and if Michael recanted then, in the spirit
of Wikipedia, the whole post should be removed. And I would do this gladly,
free of charge! :-) Why? If Michael is wrong then developers can, in fact,
trust pointer arithmetic implicitly, so the criticism post in Wikipedia loses
its reason for being (it would no longer be a reason to criticize GCC).

So, what is the bottom line: is Michael right?


-- 


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

[redi at gcc dot gnu dot org]

------- 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

[redi at gcc dot gnu dot org]

------- 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

[matz at gcc dot gnu dot org]

------- 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

[rogerio at rilhas dot com]

------- 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 using MSC. What if I can't? I'll cross that bridge when I come to
it, meanwhile me and my followers make code faster and more confortably year
after year after year.



> 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.


You don't see it because you removed it. Or your frieds. Or your mom. Not
really important. It was removed by someone who didn't present a any reason why
it is not a valid criticism. You say that other criticism there? People who
want to refute it add stuff like "citation needed" or "needs references".

I've put it back again. You can take it down again, but you will just make me
ask Wikipedia referees to lock it and so you will get even more exposure.
They'll check it and see I'm not doing anything wrong.

The fact that you (or your frieds) keep removing it just proves to me that you
are somewhat ashamed of what you claimed. If not then just let it be.

BTW: don't bother sneaking late at night to remove it because I have a bot
warning me the second the post gets removed (or modified). So you, your
friends, your mom, nor your dog will ever win this one unless you recant.


>  If anything, it's more like an invitation to use GCC for
> developing because it's more standard compliant than other compilers.


That claim should be backed up so that everyone knows if your "others" include
MSC or Intel. Please demonstrate why GCC is more standards compliant than MSC
or Intel's, or otherwise your sentence is just shallow. This is the kind of
stuff that comes back to bite you in the ass because if you can't demonstrate
it you may end up on Wikipedia with something like "Michael Matz, from the GCC
bug tracking team, failed to demonstrate any way in which GCC is more standards
compliant than MSC or Intel". Like the mean-ignorant-rude bastard that I am I
would do it! Shouldn't you be more careful about what you claim at this point?
Do you have some impairment that I don't know about? Don't make claims you are
unable to substantiate.


> > 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!

Yeah... sure... or, in my words, I learned a lot. You didn't.

I learned GCC cannot be trusted in any situation not covered by the standards.
I didn't know that. I was very very ignorant and now I'm just ignorant. Good,
that's not bad for a day's work.

You saw that GCC conforming to "just standards" leaves out a very large number
of real world applications. Isn't the embedded and experimental platforms one
of the most important targets for GCC? Shouldn't GCC try to make more
guarantees than just standard then? GCC is just average. GCC is just standard.
Like a standard car, or a standard dishwasher. It does no better than average.
It is not special.

Others strive to be special. A special car, a special dishwasher, a special
compiler. Those do what is standard and more, and that makes them great. You
didn't learn that. Too bad for you.

You seem to be unable to understand this. My English is surelly very bad, I'm
sorry, it is not my native language. Let me try it another way.

standards=average
standards+other_stuff=special

GCC=standards=average
MSC=standards+old_school_stuff+new_bleeding_edge_stuff=special

memory_mapped=standard+old_school_stuff
memory_mapped+GCC=not_guaranteed=unreliable
memory_mapped+MSC=reliable

GCC<reliable[memory_mapped]

programmers_for_memory_mapped_need>=reliable
programmers_for_memory_mapped_need+GCC=maybe_break_someday

GCC could be better in the future if it added something. I get it, you don't
want to go outside any standard. I get it. For a long time it frustrated me
that you didn't want to, now I have made my peace with it. Really.

You still don't get it? Who cares.


(In reply to comment #49)

This code:

res=function(class(initializer))

Does not compile in GCC. Why? Who cares!! You have shown me that it has
something to do with not being defined in the standard or whatever. Don't miss
the point, I don't care why. I didn't ask you to explain to me why GCC can't. I
didn't ask you what it would take for GCC to be able to do it. I didn't ask you
to change the standards. And I certainly didn't ask GCC not to go beyond
standards! I would burn in hell surely (well, even more so).

It is simple, try to understand: GCC can't, MSC can. GCC is average, MSC is
above average. I have to manually do an equivalency for GCC to compile:

{
class random_name(initializer);
res=function(random_name)
}

It is stupid that I have to do this manually. Stupid of the standards?
Probably, but I don't know why it is not there, so I won't say anything about
it. Stupid of GCC? Well, possibly. Microsoft probably also knows about the
standards and solved it, why not GCC? Can it be done with "move constructors"?
Who cares! As far as I'm concerned it could have been done with the
preprocessor!!

You just keep missing the point!!!!!!!

I just informed you: MSC can, GCC can't. Period. Your little brains couldn't
take it. It was too much for you. You just made a really big effor to explain
to my why it can't and didn't realize I don't care and that was not the point!!

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 about me overloading the function in GCC? That would solve it!! No, wrong.
It is virtual, I don't know who derives the class and overrides the function.
So with GCC I would be stuck, and the code would not have been produced in time
for my clients to pay me.

Was Microsoft right to make such a special compiler and let me do things not in
the standards? Yes. Is what I'm doing called C++? I think so, but I don't
really care, as long as it works *RELIABLY* and *GUARANTEED* (MSC guarantees
this). Should the standards be updated? Probably. Will I do it? No. Do I have a
problem? No, I'll just avoid GCC.

So don't keep missing the point. I am *INFORMING YOU* that MSC can and GCC
can't. And I'm also *INFORMING YOU* that I don't care why GCC can't. It just
can't. You don't care about this information? Drop it.

So keep throwing standards at me and call me ignorant and see if I care.


-- 


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

[redi at gcc dot gnu dot org]

------- 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

[redi at gcc dot gnu dot org]

------- 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

[rogerio at rilhas dot com]

------- 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

[rogerio at rilhas dot com]

------- 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

[redi at gcc dot gnu dot org]

------- 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

[rogerio at rilhas dot com]

------- 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 in GCC. And I backed down my claims when I finally
understood that GCC does go anywhere where standards don't tell it to go. I
backed down because you've shown me it is not a bug. I'll grant I've put up a
fight, but for me it was a fair fight. The Wikipedia post shows that, it is me
admiting that I got GCC all wrong from the start. At this point I'm just
arguing like you are, I don't think I'm any more of a troll than you. As for my
skills as a troll being crap: that seems only natural, I don't have any intent
to disrupt anything.


-- 


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

[redi at gcc dot gnu dot org]

------- 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