[Bug c++/38007] New: g++ instantiate same operator twice due to bitfield in -O0 mode, causing symbol already defined assembler error

2008-11-03 Thread jengliang at gmail dot com
Following code produces symbol already defined assembler error when compiled
with g++ 4.2.4 with -O0 flag.  It can compile without problem with g++ 4.1.1.

=== foo.hpp ===
class foo {
public:
template  operator T ();
};

template 
inline foo::operator T () {
return (T)0;
}

=== foo.cpp ===
#include "foo.hpp"

struct bar {
unsigned int _bar : 24;
};

int main() {
foo a;
unsigned int b = a;
bar c;
c._bar = a;
return 1;
}


compile with g++ -O0 foo.cpp

Regards,
Jeng-Liang


-- 
   Summary: g++ instantiate same operator twice due to bitfield in -
O0 mode, causing symbol already defined assembler error
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jengliang at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38007



[Bug c++/39513] New: class defined in file scope got linked by other files

2009-03-20 Thread jengliang at gmail dot com
This happens when one class is defined in header file, the other defined in cpp
file, have the same name.  The program behavior becomes gcc argument order
dependent.  At any rate, class A defined in foo.cpp has file scope shouldn't be
seen in bar.cpp.

$ g++ main.cpp foo.cpp bar.cpp
$ ./a.out
foo.cpp: A::A()
foo.cpp: A::~A()
foo.cpp: A::A()
foo.cpp: A::~A()

$ g++ main.cpp bar.cpp foo.cpp
$ ./a.out
bar.h: A::A()
bar.h: A::~A()
bar.h: A::A()
bar.h: A::~A()


-- main.cpp --
#include 

#include "foo.h"
#include "bar.h"

int main()
{
foo f;
bar b;

return 1;
}

-- foo.h --
class foo {
  public:
foo();
};

-- foo.cpp --
#include "foo.h"
#include 

class A {
  public:
A() { std::cout << "foo.cpp: A::A()" << std::endl; }
~A() { std::cout << "foo.cpp: A::~A()" << std::endl; }
};

foo::foo()
{
A * a = new A();
delete a;
}

-- bar.h --
#include 

class A {
  public:
A() { std::cout << "bar.h: A::A()" << std::endl; }
~A() { std::cout << "bar.h: A::~A()" << std::endl; }
};

class bar {
  public:
bar();
};

-- bar.cpp --
#include "bar.h"
#include 

bar::bar()
{
  A *a = new A();
  delete a;
}


-- 
   Summary: class defined in file scope got linked by other files
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
      Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jengliang at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39513



[Bug c++/39513] class defined in file scope got linked by other files

2009-03-20 Thread jengliang at gmail dot com


--- Comment #2 from jengliang at gmail dot com  2009-03-20 20:52 ---
(In reply to comment #1)
> You are violating C++'s One definition rule (ODR).  This code is undefined
> because the definition of A::A() (and others) are different between the two
> files.

Thanks for the quick response and sorry about the spam... It would be nice if
gcc can detect such violations though.  In large software team, this is bound
to happen and we learned it the hard way.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39513



[Bug c/39170] cannot silence -Wconversion warnings for bit-fields

2010-03-05 Thread jengliang at gmail dot com


--- Comment #10 from jengliang at gmail dot com  2010-03-06 01:37 ---
Hi Manuel,

I think it is a good idea to warn about narrowing both from a type to another
type, and from a type to a bit-field.  For new codes, one should use the
bit-masking technique for bit-field narrowing just as one should use
type-casting for general narrowing.

However, with so many lines of legacy code out there using bit-filed that have
been proven to work, it doesn't make sense to revisit/modify them.  Would it be
possible for gcc to provide a -Wbitfield-conversion flag in new releases and
make 39170 an enhancement (preferably high priority)?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39170