RE: Is this a bug?

RE: Is this a bug?

[Lev Assinovsky]

The test case passed under gcc 3.3.1.
The problem was in lack of SOM weak support in gcc prior 3.3

----
Lev Assinovsky
Aelita Software Corporation
O&S Core Division, Programmer
ICQ# 165072909


> -----Original Message-----
> From: Alexandre Oliva [mailto:aoliva@redhat.com]
> Sent: Tuesday, August 12, 2003 10:57 PM
> To: Lev Assinovsky
> Cc: Gcc-Bugs (E-mail); Gcc-Help (E-mail)
> Subject: Re: Is this a bug?
> 
> 
> On Aug 12, 2003, "Lev Assinovsky" 
> <LAssinovsky@algorithm.aelita.com> wrote:
> 
> > gcc 3.2.3, HPUX-11.00:
> 
> > t.cpp: In static member function `static const item* A::f()':
> > t.cpp:6: warning: sorry: semantics of inline function 
> static data `const item 
> >    arr[1]' are wrong (you'll wind up with multiple copies)
> > t.cpp:6: warning:   you can work around this by removing 
> the initializer
> 
> It's not as much of a bug, but rather a limitation AFAIK imposed by
> the object file of the platform you've chosen.  GCC requires weak
> symbols in order to implement this feature correctly, and 32-bit HP-UX
> object files don't support them (completely?).
> 
> -- 
> Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
> Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
> CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
> Free Software Evangelist                Professional serial bug killer
> 

Re: Is this a bug?

[Bill McEnaney]

Bob told us his preference.  So I'll admit my preferences: Haskell,
Ocaml, Prolog, Python, and Lisp, probably in that order.

Bill

> On Thu, 2009-07-16 at 17:31 -0700, Ian Lance Taylor wrote:
> > For an integer type there is no performance difference between ++x and
> > x++.
> > 
> > For a C++ class which defines operator++ and a copy constructor, there
> > can be performance differences between ++x and x++.  The latter often
> > requires the compiler to invoke the copy constructor to hold onto the
> > old value before invoking operator++.  So if you are writing C++, it's
> > often a good idea to write ++x when x is a class type, such as an STL
> > iterator.  The compiler can sometimes eliminate the copy constructor,
> > but not always.
> > 
> > Ian
> 
> Thank you, Ian. Being mostly a C programmer, I often forget about the
> things that C++ does behind the scenes.
> 
> My real preference is assembly language. Then it's just me and the
> machine. ;)
> 
> Bob
> 
> 
> 

________________________________________________________________
Please visit a saintly hero:
http://www.jakemoore.org

Re: Is this a bug?

[Bob Plantz]

On Thu, 2009-07-16 at 17:31 -0700, Ian Lance Taylor wrote:
> For an integer type there is no performance difference between ++x and
> x++.
> 
> For a C++ class which defines operator++ and a copy constructor, there
> can be performance differences between ++x and x++.  The latter often
> requires the compiler to invoke the copy constructor to hold onto the
> old value before invoking operator++.  So if you are writing C++, it's
> often a good idea to write ++x when x is a class type, such as an STL
> iterator.  The compiler can sometimes eliminate the copy constructor,
> but not always.
> 
> Ian

Thank you, Ian. Being mostly a C programmer, I often forget about the
things that C++ does behind the scenes.

My real preference is assembly language. Then it's just me and the
machine. ;)

Bob

Re: Is this a bug?

[Ian Lance Taylor]

Bob Plantz <plantz@cds1.net> writes:

> I have often heard students say they were told that ++x is more
> efficient than x++. From looking at gcc-generated assembly language, I
> knew this is not always true. It's been pointed out here that the
> situation is more "interesting" than I realized.

For an integer type there is no performance difference between ++x and
x++.

For a C++ class which defines operator++ and a copy constructor, there
can be performance differences between ++x and x++.  The latter often
requires the compiler to invoke the copy constructor to hold onto the
old value before invoking operator++.  So if you are writing C++, it's
often a good idea to write ++x when x is a class type, such as an STL
iterator.  The compiler can sometimes eliminate the copy constructor,
but not always.

Ian

RE: Is this a bug?

[Bob Plantz]

This was also a learning experience for me.

I have often heard students say they were told that ++x is more
efficient than x++. From looking at gcc-generated assembly language, I
knew this is not always true. It's been pointed out here that the
situation is more "interesting" than I realized.

By the way, I don't like complicated expressions because I find them
more difficult to read and change. I would've written this example as

#include <stdio.h>
int main()
{
    volatile int  x = 20,y = 35;
    x = y + x;
    x += 2;
    y += 2;
    y = y + x;
    printf("x=%d  y=%d\n" ,x,y);
    return 0;
}

Now the volatile type qualifier works independently from the algorithm,
the way god intended. (Of course, "volatile" implies we should expect
the unexpected.)

RE: Is this a bug?

[Honggang Xu]

Thank both of you, I didn't think the problem in right way -- the
behavior is undefined, I have been thinking it was caused by volatile
key word, your explanation makes me released. -Honggang 

-----Original Message-----
From: Andrew Haley [mailto:aph@redhat.com] 
Sent: Thursday, July 16, 2009 11:22 AM
To: David Daney
Cc: Honggang Xu; gcc-help@gcc.gnu.org
Subject: Re: Is this a bug?

David Daney wrote:
> Honggang Xu wrote:
>> Or my understand of keyword "volatile" is wrong, following code 
>> outputs compiled by gcc 4.1.1:  x=22 ,y=59
>>  
>> main()
>> {
>> volatile int  x=20,y=35;
>> x=y++ + x++;
>> y= ++y + ++x;
>> printf("x=%d  y=%d\n" ,x,y);
>>  
>> }
>>
> 
> Your program has undefined behavior, the volatile may change the 
> output, but it doesn't change the fact that its behavior is undefined.
> 
> The problem is that the affect of the increment operator can take 
> place either before or after the affect of the assignment.  The 
> compiler can order the affects any way that it desires between
sequence points.

Actually, that's not quite true: as this expression exhibits undefined
behaviour, the compiler can return absolutely anything: it isn't limited
to just where it does the increment.

Andrew.

Re: Is this a bug?

[Andrew Haley]

David Daney wrote:
> Honggang Xu wrote:
>> Or my understand of keyword "volatile" is wrong, following code outputs
>> compiled by gcc 4.1.1:  x=22 ,y=59
>>  
>> main()
>> {
>> volatile int  x=20,y=35;
>> x=y++ + x++;
>> y= ++y + ++x;
>> printf("x=%d  y=%d\n" ,x,y);
>>  
>> }
>>
> 
> Your program has undefined behavior, the volatile may change the output,
> but it doesn't change the fact that its behavior is undefined.
> 
> The problem is that the affect of the increment operator can take place
> either before or after the affect of the assignment.  The compiler can
> order the affects any way that it desires between sequence points.

Actually, that's not quite true: as this expression exhibits undefined
behaviour, the compiler can return absolutely anything: it isn't limited
to just where it does the increment.

Andrew.

Re: Is this a bug?

[David Daney]

Honggang Xu wrote:
> Or my understand of keyword "volatile" is wrong, following code outputs
> compiled by gcc 4.1.1:  x=22 ,y=59
>  
> main()
> {
> volatile int  x=20,y=35;
> x=y++ + x++;
> y= ++y + ++x;
> printf("x=%d  y=%d\n" ,x,y);
>  
> }
> 

Your program has undefined behavior, the volatile may change the output, 
but it doesn't change the fact that its behavior is undefined.

The problem is that the affect of the increment operator can take place 
either before or after the affect of the assignment.  The compiler can 
order the affects any way that it desires between sequence points.

You might want to read up on sequence points: 
http://en.wikipedia.org/wiki/Sequence_point

David Daney

Re: Is this a bug?

[Andrew Haley]

Honggang Xu wrote:
> Or my understand of keyword "volatile" is wrong, following code outputs
> compiled by gcc 4.1.1:  x=22 ,y=59
>  
> main()
> {
> volatile int  x=20,y=35;
> x=y++ + x++;
> y= ++y + ++x;
> printf("x=%d  y=%d\n" ,x,y);
>  
> }

No, it's not a gcc bug: your program exhibits undefined behaviour.

http://c-faq.com/expr/ieqiplusplus.html

Andrew.

RE: Is this a bug?

[Honggang Xu]

Or my understand of keyword "volatile" is wrong, following code outputs
compiled by gcc 4.1.1:  x=22 ,y=59
 
main()
{
volatile int  x=20,y=35;
x=y++ + x++;
y= ++y + ++x;
printf("x=%d  y=%d\n" ,x,y);
 
}

thanks
Honggang
 

Re: Is this a bug?

[Alexandre Oliva]

On Aug 14, 2003, "Lev Assinovsky" <LAssinovsky@algorithm.aelita.com> wrote:

> But the program works after that warning.

Not if you relied on the uniqueness of the static variable across
translation units.  What the warning is telling you is that they won't
be unified, which is required by the standard, but can't be
implemented in this object file format (AFAIK).

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

RE: Is this a bug?

[Lev Assinovsky]

But the program works after that warning.

----
Lev Assinovsky
Aelita Software Corporation
O&S Core Division, Programmer
ICQ# 165072909


> -----Original Message-----
> From: Alexandre Oliva [mailto:aoliva@redhat.com]
> Sent: Tuesday, August 12, 2003 10:57 PM
> To: Lev Assinovsky
> Cc: Gcc-Bugs (E-mail); Gcc-Help (E-mail)
> Subject: Re: Is this a bug?
> 
> 
> On Aug 12, 2003, "Lev Assinovsky" 
> <LAssinovsky@algorithm.aelita.com> wrote:
> 
> > gcc 3.2.3, HPUX-11.00:
> 
> > t.cpp: In static member function `static const item* A::f()':
> > t.cpp:6: warning: sorry: semantics of inline function 
> static data `const item 
> >    arr[1]' are wrong (you'll wind up with multiple copies)
> > t.cpp:6: warning:   you can work around this by removing 
> the initializer
> 
> It's not as much of a bug, but rather a limitation AFAIK imposed by
> the object file of the platform you've chosen.  GCC requires weak
> symbols in order to implement this feature correctly, and 32-bit HP-UX
> object files don't support them (completely?).
> 
> -- 
> Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
> Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
> CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
> Free Software Evangelist                Professional serial bug killer
> 

Re: Is this a bug?

[Alexandre Oliva]

On Aug 12, 2003, "Lev Assinovsky" <LAssinovsky@algorithm.aelita.com> wrote:

> gcc 3.2.3, HPUX-11.00:

> t.cpp: In static member function `static const item* A::f()':
> t.cpp:6: warning: sorry: semantics of inline function static data `const item 
>    arr[1]' are wrong (you'll wind up with multiple copies)
> t.cpp:6: warning:   you can work around this by removing the initializer

It's not as much of a bug, but rather a limitation AFAIK imposed by
the object file of the platform you've chosen.  GCC requires weak
symbols in order to implement this feature correctly, and 32-bit HP-UX
object files don't support them (completely?).

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Is this a bug?

[Lev Assinovsky]

gcc 3.2.3, HPUX-11.00:

typedef struct  { int a, b; } item; 
class A {
public:
    static const item *  f()
        {
            static const item  arr[] = {{0,0}}; 
            return arr;
        }
};

The result:

t.cpp: In static member function `static const item* A::f()':
t.cpp:6: warning: sorry: semantics of inline function static data `const item 
   arr[1]' are wrong (you'll wind up with multiple copies)
t.cpp:6: warning:   you can work around this by removing the initializer

----
Lev Assinovsky
Aelita Software Corporation
O&S Core Division, Programmer
ICQ# 165072909