[Bug c++/16630] missing type name in __PRETTY_FUNCTION__

[gcc-bugzilla at contacts dot eelis dot net]

--- Comment #6 from gcc-bugzilla at contacts dot eelis dot net  2010-06-05 
20:12 ---
Looks fixed in 4.4.1.


-- 

gcc-bugzilla at contacts dot eelis dot net changed:

   What|Removed |Added

 CC||gcc-bugzilla at contacts dot
   ||eelis dot net


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

[Bug libstdc++/44190] New: Debug vector resize does not update capacity

[gcc-bugzilla at contacts dot eelis dot net]

The assertion in the following testcase should /not/ fail, but does:

  #define _GLIBCXX_DEBUG
  #define _GLIBCXX_DEBUG_PEDANTIC

  #include vector
  #include cassert

  int main()
  {
std::vectorint v;
v.resize(10);
assert(v.size() = v.capacity());
  }


-- 
   Summary: Debug vector resize does not update capacity
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug libstdc++/44190] Debug vector resize does not update capacity

[gcc-bugzilla at contacts dot eelis dot net]

--- Comment #1 from gcc-bugzilla at contacts dot eelis dot net  2010-05-18 
21:45 ---
Created an attachment (id=20695)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20695action=view)
Trivial patch that fixes the problem.

The problem was just a missing call to _M_update_guaranteed_capacity().


-- 


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

[Bug libstdc++/44190] Debug vector resize does not update capacity

[gcc-bugzilla at contacts dot eelis dot net]

--- Comment #3 from gcc-bugzilla at contacts dot eelis dot net  2010-05-18 
23:38 ---
(In reply to comment #2)
 I'm going to apply the patch

Great, thanks! :)

 could you please provide name and family name for
 the ChangeLog entry?

It's Eelis van der Weegen


-- 


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

[Bug c++/42490] New: using-directive in namespace doesn't work properly

[gcc-bugzilla at contacts dot eelis dot net]

Consider:

  namespace B { struct C {}; }
  namespace A { namespace C { } using namespace B; }
  struct A::C c;

GCC complains:

  error: 'C' in namespace 'A' does not name a type

Not knowing much about the subtleties of name lookup myself, I'm relying on the
following two sources for the code's well-formed-ness:

* Comeau 4.3.10.1 /does/ accept the code.
* The opinion of a particularly well-read regular (litb) on Freenode's C++ IRC
channel.


-- 
   Summary: using-directive in namespace doesn't work properly
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug c++/21534] Declaration in wrong namespace not rejected

[gcc-bugzilla at contacts dot eelis dot net]

--- Comment #2 from gcc-bugzilla at contacts dot eelis dot net  2009-12-22 
15:18 ---
Here's a related snippet that should be rejected but isn't:

  namespace NS { class x; } int NS::x;


-- 

gcc-bugzilla at contacts dot eelis dot net changed:

   What|Removed |Added

 CC||gcc-bugzilla at contacts dot
   ||eelis dot net


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

[Bug libstdc++/41037] New: dec not set in cerr flags

[gcc-bugzilla at contacts dot eelis dot net]

Consider:

#include iostream
#include cstdio

int main()
{ std::printf(%d\n, std::cerr.flags()  std::ios_base::dec); }

In 27.3.1p5, the standard states:

After the object cerr is initialized, cerr.flags()  unitbuf is
nonzero. Its state is otherwise the same as required for
basic_ioschar::init (27.4.4.1).

In 27.4.4.1p3, it is specified that flags() is set to skipws|dec.

Hence, the program above should not output 0. But it does.


-- 
   Summary: dec not set in cerr flags
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug c++/38020] New: Undiagnosed const violation in pointer conversion in CRTP context.

[gcc-bugzilla at contacts dot eelis dot net]

Consider:

  template typename Derived
  struct Base { Derived * f() { return static_castDerived const *(this); } };

  struct D: BaseD {};

  int main() { D d; d.f(); }

This code is ill-formed, because f is declared to return a Derived*, but the
return statement specifies an expression of type Derived const*.

However, g++ accepts the code without any diagnostic.

Comeau 4.3.10.1 /does/ diagnose the problem, saying error: return value type
does not match the function type.


-- 
   Summary: Undiagnosed const violation in pointer conversion in
CRTP context.
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug c++/37875] New: [c++0x] misinterpreted closing angle bracket in decltype operand

[gcc-bugzilla at contacts dot eelis dot net]

I think g++ incorrectly rejects the following code when compiled with
-std=c++0x:

  template typename struct X {};
  Xdecltype(1  2) x;
// t.cpp:2: error: template argument 1 is invalid
// t.cpp:2: error: invalid type in declaration before ‘;’ token

For comparison, here is very similar code that is accepted:

  template int struct Y {};
  Ysizeof(1  2) y;

Hence, I suspect it is a problem with decltype.


-- 
   Summary: [c++0x] misinterpreted closing angle bracket in decltype
operand
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug c++/37204] New: reinterpret_castT(v) incorrectly yields an lvalue

[gcc-bugzilla at contacts dot eelis dot net]

Consider:

  #include iostream
  void f(int ) { std::cout  lvalue\n; }
  void f(int ) { std::cout  rvalue\n; }
  int main() { int x(3); f(reinterpret_castint(x)); }

This /should/ output rvalue, but it outputs lvalue instead (when compiled
with -std=c++0x).

In 5.2.10p1, n2691 (the most recent C++0x draft) states w.r.t.
reinterpret_castT(v):

  If T is an lvalue reference type, the result is an lvalue; otherwise, the
result is an rvalue


-- 
   Summary: reinterpret_castT(v) incorrectly yields an lvalue
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug c++/37206] New: [c++0x] Spurious copy/move requirement for initialization of rvalue reference variable from rvalue initializer.

[gcc-bugzilla at contacts dot eelis dot net]

Consider:

  struct nocopy { private: nocopy(nocopy const); };
  nocopy  f();
  nocopy  r = f();

On the last line, g++ 4.4 (with -std=c++0x) complains:

  error: nocopy::nocopy(const nocopy) is private in this context

Thus, it seems g++ wants to create a temporary. While there
are many similar situations that do indeed call for the creation
of a temporary, I think there is no such requirement here.

With regard to initialization of a reference of type cv1 T1 by an
expression of cv2 T2, 8.5.3p5 item 2, subitem 1 in n2691 (the
latest C++0x draft) states:

  If the initializer expression is an rvalue, with T2 a class type,
  and cv1 T1 is reference-compatible with cv2 T2, the
  reference is bound to the object represented by the rvalue
  or to a sub-object within that object.

This item applies because the expression f() is an rvalue (by 5p6),
nocopy is a class type, and nocopy is reference compatible with
itself (by 8.5.3p4). Hence, there is no call for a temporary, and the
code should be accepted.

At least, that's my humble interpretation. Apologies if I overlooked
something or misunderstood the wording in the draft.


-- 
   Summary: [c++0x] Spurious copy/move requirement for
initialization of rvalue reference variable from rvalue
initializer.
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug c++/37047] Missing warning for deprecated use of static

[gcc-bugzilla at contacts dot eelis dot net]

--- Comment #4 from gcc-bugzilla at contacts dot eelis dot net  2008-08-23 
02:58 ---
(In reply to comment #3)
 Where is the namespace scope in the example?

From the standard, 3.3.5p3:

  The outermost declarative region of a translation unit is
  also a namespace, called the global namespace.


-- 


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

[Bug c++/36734] Incorrect access to tyedef in base of template class.

[gcc-bugzilla at contacts dot eelis dot net]

--- Comment #1 from gcc-bugzilla at contacts dot eelis dot net  2008-08-21 
11:35 ---
It seems access control for templates is broken at a more basic level than the
reporter's testcase suggests; witness the following simplified testcase:

  class A { typedef int X; };
  template typename struct B { A::X x; };
  Bint b;

Again, g++ does not complain. Comeau rightly rejects the code, complaining that
A::X is inaccessible.


-- 

gcc-bugzilla at contacts dot eelis dot net changed:

   What|Removed |Added

 CC||gcc-bugzilla at contacts dot
   ||eelis dot net


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

[Bug c++/36430] Cannot convert a temporary to a non-const reference even with conversion operator

[gcc-bugzilla at contacts dot eelis dot net]

--- Comment #1 from gcc-bugzilla at contacts dot eelis dot net  2008-08-21 
11:43 ---
This report is invalid. By 12.3.2,

  A conversion function is never used to convert a
  (possibly cv-qualified) object to the (possibly
  cv-qualified) same object type (or a reference to it).

Comeau warns explicitly about this, saying:

  line 2: warning: Foo::operator Foo () will not be
called for implicit or explicit conversions


-- 

gcc-bugzilla at contacts dot eelis dot net changed:

   What|Removed |Added

 CC||gcc-bugzilla at contacts dot
   ||eelis dot net


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

[Bug c++/36734] Incorrect access to tyedef in base of template class.

[gcc-bugzilla at contacts dot eelis dot net]

--- Comment #2 from gcc-bugzilla at contacts dot eelis dot net  2008-08-21 
11:53 ---
Most likely related to bug 26693.


-- 


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

[Bug c++/32039] Using declaration accepts non-visible members from base classes

[gcc-bugzilla at contacts dot eelis dot net]

--- Comment #1 from gcc-bugzilla at contacts dot eelis dot net  2008-08-21 
12:00 ---
Still accepted by 4.4. Comeau concurs with reporter, and rejects saying:

  line 15: error: class member designated by a
using-declaration must be visible in a direct base class


-- 

gcc-bugzilla at contacts dot eelis dot net changed:

   What|Removed |Added

 CC||gcc-bugzilla at contacts dot
   ||eelis dot net


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

[Bug c++/34121] wrong this pointer passed to constructor of temporary object

[gcc-bugzilla at contacts dot eelis dot net]

--- Comment #4 from gcc-bugzilla at contacts dot eelis dot net  2008-08-21 
12:51 ---
Isolated and reproduced with GCC 4.4 on x86_64:

  #include iostream
  #include stdint.h

  struct A
  {
uint64_t p;
char m_ac[18];

A() { std::cout  default constructed at   this  '\n'; }
~A() { std::cout  destructed at   this  '\n'; }

A(A const ) { std::cout  copy constructed at   this  '\n'; }
  };

  A f() { return A(); }

  struct B: A { B(): A(f()) {} };

  int main() { B b; }

Output:

  default constructed at 0x7fffd583ca40
  destructed at 0x7fffd583ca90

These two addresses really should be the same.


-- 

gcc-bugzilla at contacts dot eelis dot net changed:

   What|Removed |Added

 CC||gcc-bugzilla at contacts dot
   ||eelis dot net


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

[Bug c++/37119] New: sizeof simple struct consisting of bit-fields too large and unpredictable

[gcc-bugzilla at contacts dot eelis dot net]

Consider:

  #include stdint.h
  struct X { uint32_t a:17; uint8_t b:8; bool c:1; };
  #include iostream
  int main() { std::cout  sizeof(X)  '\n'; }

This prints 8, while I'd really expect it to print 4. Even more
surprisingly, if b's type is changed from uint8_t to uint16_t, the output
/does/ become 4.


-- 
   Summary: sizeof simple struct consisting of bit-fields too large
and unpredictable
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net
  GCC host triplet: x86_64-pc-linux


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

[Bug c++/37119] sizeof simple struct consisting of bit-fields too large and unpredictable

[gcc-bugzilla at contacts dot eelis dot net]

--- Comment #2 from gcc-bugzilla at contacts dot eelis dot net  2008-08-13 
21:39 ---
(In reply to comment #1)
 so 26bits which is a little over 4 bytes.

I don't follow. 4 bytes is 4*8=32 bits, which is more than 26, no?


-- 


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

[Bug c++/37119] sizeof simple struct consisting of bit-fields too large and unpredictable

[gcc-bugzilla at contacts dot eelis dot net]

--- Comment #9 from gcc-bugzilla at contacts dot eelis dot net  2008-08-13 
22:24 ---
Ok, I see. Sorry for wasting your time.


-- 


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

[Bug c++/37047] New: Missing warning for deprecated use of static

[gcc-bugzilla at contacts dot eelis dot net]

In 7.3.1.1p2, the standard states The use of the static keyword is deprecated
when declaring objects in a namespace scope, yet g++ does not warn about such
uses. Compiling the following snippet:

  static int i;
  int g() { return i; }

results in no diagnostics of any kind, not even with -std=c++98 -Wall -Wextra
-pedantic.


-- 
   Summary: Missing warning for deprecated use of static
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug c++/36943] New: Use of nested C++0x initializer list for non-aggregate rejected

[gcc-bugzilla at contacts dot eelis dot net]

C++0x-style initializer list support was recently added, but the following
valid code is rejected:

  struct p { p(int, int); };
  p a[] = { { 3, 2 } };

With -std=c++0x, the second line results in:

  error: braces around scalar initializer for type 'p'


-- 
   Summary: Use of nested C++0x initializer list for non-aggregate
rejected
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug c++/36778] New: [feature request] -Wfatal-warnings

[gcc-bugzilla at contacts dot eelis dot net]

Gcc has a versatile set of warning/error flags that let one tune its behavior,
but there is one thing that it seems is currently not supported: the ability to
have gcc abort on the first diagnostic, without losing information about
whether that diagnostic is a warning or an error.

One can use -Werror -Wfatal-errors to get abortion on the first diagnostic, but
then warnings like suggest parentheses around  within || are reported as
errors.

Ideally, there would be a flag -Wfatal-warnings, which would cause the compiler
to abort compilation on the first warning. One could then use -Wfatal-errors
-Wfatal-warnings to get abortion on the first diagnostic without losing
information about whether that diagnostic is a warning or an error.

While I believe this feature would be more generally useful, the particular use
case I'm requesting this for is geordi ( http://www.eelis.net/geordi/ ), a
popular educational IRC C++ bot which compiles C++ code snippets with gcc and
reports the first diagnostic (if any). Since only the first diagnostic is
needed, geordi uses -Werror -Wfatal-errors to reduce its response time, but
this means it misreports warnings like the one mentioned above, as errors.
Having -Wfatal-warnings would trivially solve this without imposing a
responsiveness penalty.

I realize this request might be a bit of a stretch, but I thought I'd give it a
shot. Thanks for your time.


-- 
   Summary: [feature request] -Wfatal-warnings
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug c++/36760] New: Simple std::bind use causes warnings with -Wextra

[gcc-bugzilla at contacts dot eelis dot net]

Consider:

  #include functional
  void f() {}
  void g() { std::bind(f)(); }

Compiling this with g++-svn -c -std=c++0x -Wextra gives:

  In file included from
/home/eelis/soft/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/functional:75,
 from t.cpp:1:
/home/eelis/soft/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/tr1_impl/functional:
In function ‘void g()’:
/home/eelis/soft/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/tr1_impl/functional:1226:
warning: type qualifiers ignored on function return type
/home/eelis/soft/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/tr1_impl/functional:1213:
warning: type qualifiers ignored on function return type
/home/eelis/soft/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/tr1_impl/functional:1201:
warning: type qualifiers ignored on function return type


-- 
   Summary: Simple std::bind use causes warnings with -Wextra
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug c++/36744] New: function modifying argument received by-value affects caller's variable when passed as rvalue

[gcc-bugzilla at contacts dot eelis dot net]

Consider:

  #include iostream

  struct S
  {
S(): i(2) {}
S(S const) {}
int i;
  };

  void f(S x) { x.i = 0; }

  int main()
  {
S y;
f(static_castS(y));
std::cout  y.i  '\n';
  }

Expected output: 2
Actual output: 0

Thus, the assignment to the independent local variable x in f somehow modifies
y. That can't be right, not even with that static_cast to S, can it?


-- 
   Summary: function modifying argument received by-value affects
caller's variable when passed as rvalue
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug c++/36744] function modifying argument received by-value affects caller's variable when passed as rvalue

[gcc-bugzilla at contacts dot eelis dot net]

--- Comment #1 from gcc-bugzilla at contacts dot eelis dot net  2008-07-06 
14:48 ---
Forgot to mention: compile with -std=c++0x.


-- 


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

[Bug c++/36655] unjustified warning for extern template when using -pedantic -std=c++0x

[gcc-bugzilla at contacts dot eelis dot net]

--- Comment #4 from gcc-bugzilla at contacts dot eelis dot net  2008-06-29 
12:53 ---
(In reply to comment #3)
 Fixed for 4.4.0.

Thanks! However, I just noticed that while the problem has been fixed for
function templates, it's still there for class templates. This code:

  template typename void f() {}
  extern template void fint();

still triggers the warning when compiled with g++ -std=c++0x -pedantic.


-- 

gcc-bugzilla at contacts dot eelis dot net changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug c++/36655] unjustified warning for extern template when using -pedantic -std=c++0x

[gcc-bugzilla at contacts dot eelis dot net]

--- Comment #5 from gcc-bugzilla at contacts dot eelis dot net  2008-06-29 
12:54 ---
Crap, pasted the wrong code. Here's the code that now triggers the warning:

  template typename class S {};
  extern template class Sint;


-- 


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

[Bug c++/36655] New: unjustified warning for extern template when using -pedantic -std=c++0x

[gcc-bugzilla at contacts dot eelis dot net]

Consider:

  template typename void f() {}
  extern template void fint();

When compiled with:

   g++ -pedantic -std=c++0x -c t.cpp

the following warning is emitted:

   warning: ISO C++ forbids the use of ‘extern’ on explicit instantiations

Since extern template has already been integrated into the C++0x working paper,
I think this warning should not be emitted when using -std=c++0x, not even with
-pedantic.


-- 
   Summary: unjustified warning for extern template when using -
pedantic -std=c++0x
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug libstdc++/36032] New: -fno-exceptions breaks simple if-statement.

[gcc-bugzilla at contacts dot eelis dot net]

Consider:

  #include iostream

  int main()
  {
if(true) try {} catch(int) {}
else std::cout  bla\n;
  }

When compiled without -fno-exceptions, bla is not printed (which is correct).
When compiled /with/ -fno-exceptions, bla /is/ printed (which is not
correct).

This appears to be due to the following overly simplistic definitions in
libsupc++/exception_defines.h:

  #ifndef __EXCEPTIONS
  // Iff -fno-exceptions, transform error handling code to work without it.
  # define try  if (true)
  # define catch(X) if (false)


-- 
   Summary: -fno-exceptions breaks simple if-statement.
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug c++/36002] New: Error messages report wrong, invalid function type.

[gcc-bugzilla at contacts dot eelis dot net]

Consider the following invalid code:

  template typename T void f() { T::bla; }
  void g() { fvoid ()(); }

g++ emits:

  t.cpp: In function ‘void f() [with T = void ()()]’:
  t.cpp:2:   instantiated from here
  t.cpp:1: error: ‘bla’ is not a member of ‘void ()()’

The error should say void (), not void ()(). The latter is not even a valid
C++ type, as can be seen by doing:

  template typename T void f();
  void g() { fvoid()()(); }

resulting in:

  error: ‘type name’ declared as function returning a function


-- 
   Summary: Error messages report wrong, invalid function type.
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug c++/35975] New: Invalid argumentless functional explicit type conversion to reference type not rejected

[gcc-bugzilla at contacts dot eelis dot net]

The following invalid code is accepted by G++:

  void f() { typedef int  T; T(); }

Comeau 4.3.9 rejects the code with an error: invalid type conversion
diagnostic.


-- 
   Summary: Invalid argumentless functional explicit type conversion
to reference type not rejected
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug c++/35966] New: array-subscript-above-bounds warning disappears when unrelated constructor definition is added

[gcc-bugzilla at contacts dot eelis dot net]

If I have the following three files:

  /usr/include/blub.hpp:

struct Y { virtual ~Y(); };
struct X: Y { X(); };

  t.cpp

#include blub.hpp
int main() { int i[3]; return i[3]; }

  t2.cpp

#include blub.hpp
int main() { int i[3]; return i[3]; }
X::X() {}

then g++ -O2 -Wall -c t.cpp correctly warns

  t.cpp:2: warning: array subscript is above array bounds

However, g++ -O2 -Wall -c t2.cpp is silent.
In other words, the warning disappears when X::X() is defined. This makes no
sense, because X has nothing to do with the array subscript.

Even weirder, the warning reappears if blub.hpp is either located elsewhere or
included manually by copy+paste-ing its contents.

Bug 35587 seems related, though it doesn't have the #include weirdness.

Problem is reproducible with gcc 4.3.0 20080106 (experimental) on SUSE 10.2,
and on Debian sid using the gcc-4.3 4.3.0-3 package.


-- 
   Summary: array-subscript-above-bounds warning disappears when
unrelated constructor definition is added
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug c++/5786] array types decay too quickly

[gcc-bugzilla at contacts dot eelis dot net]

--- Comment #7 from gcc-bugzilla at contacts dot eelis dot net  2008-04-13 
21:19 ---
Still fails on GCC 4.4.0 20080413 (experimental).


-- 


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

[Bug c++/35784] New: Bogus inaccessibility error on variadic partial template specialization.

[gcc-bugzilla at contacts dot eelis dot net]

Consider:

  template typename... struct p;

  template typename, typename struct d;

  template typename... A, typename... B
  struct dpA..., pB...  { typedef int t; };

  typedef dp, pint, float ::t q;
  typedef dq, dpint, pfloat ::t r; // *

  typedef ddp, pint, float ::t, dp, p ::t s;
// error: ‘typedef int dpint, pfloat ::t’ is inaccessible within
this context

The error makes no sense. In fact, it disappears if the unrelated line marked
with an asterisk is removed.


-- 
   Summary: Bogus inaccessibility error on variadic partial template
specialization.
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug c++/35678] New: partial template specialization ICE in dependent_type_p, at cp/pt.c:15539

[gcc-bugzilla at contacts dot eelis dot net]

Consider:

  templatetypename T, T struct A;
  templatetypename struct B; 
  templatetemplatetypename T, T class U struct BUchar, 'h'  {};
  BAchar,'h'  x;
// internal compiler error: in dependent_type_p, at cp/pt.c:15539

Comeau 4.3.9 and GCC 4.1.2 accept the code.


-- 
   Summary: partial template specialization ICE in dependent_type_p,
at cp/pt.c:15539
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug c++/35650] New: Can't bind ref-to-function through using-decl. in namespace

[gcc-bugzilla at contacts dot eelis dot net]

Consider:

  void f();
  namespace N { using ::f; }

  void h()
  {
void ( a)() = f; // ok
void ( b)() = N::f;
  // error: invalid initialization of non-const reference of
  // type ‘void ()()’ from a temporary of type ‘void ()()’
  }

Since in h, f and N::f are simply two ways of naming the same function, the
error seems unwarranted to me.

Comeau 4.3.9 accepts the code.


-- 
   Summary: Can't bind ref-to-function through using-decl. in
namespace
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug c++/35153] New: Taking address of result of calling function returning rvalue reference should not compile.

[gcc-bugzilla at contacts dot eelis dot net]

Consider:

  int  f();
  void g() { (f()); }

GCC accepts, but shouldn't, because by 5.3.1p2 (in n2461) the operand of unary
 must be an lvalue, and by 5p6 (f()) is an rvalue.

I'm using g++ (GCC) 4.3.0 20080106 (experimental).


-- 
   Summary: Taking address of result of calling function returning
rvalue reference should not compile.
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug libstdc++/34524] New: Use of invalidated std::string iterators not caught in debug mode

[gcc-bugzilla at contacts dot eelis dot net]

In the following code, libstdc++'s debug mode does not catch the use of a
potentially invalidated std::string iterator.

  #define _GLIBCXX_DEBUG
  #define _GLIBCXX_DEBUG_PEDANTIC

  #include string
  #include vector
  #include iostream

  int main()
  {
typedef std::string S;

S s (3, 'x');
S::iterator i = s.begin(); ++i;
s.push_back('y');
std::cout  *i  std::endl; // just outputs 'x'
  }

Since the push_back may invalidate i (per 21.3 para 5, 4th item), libstdc++'s
debug mode should emit an error and abort.

If I change the typedef to std::vectorchar, then the indicated line /does/
cause libstdc++ to emit an error (attempt to dereference a singular iterator)
and abort.


-- 
   Summary: Use of invalidated std::string iterators not caught in
debug mode
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug libstdc++/34524] Use of invalidated std::string iterators not caught in debug mode

[gcc-bugzilla at contacts dot eelis dot net]

--- Comment #2 from gcc-bugzilla at contacts dot eelis dot net  2007-12-18 
20:16 ---
My apologies.


-- 


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

[Bug c++/34365] New: Diagnostic mistakenly characterizes function as being overloaded

[gcc-bugzilla at contacts dot eelis dot net]

When asked to compile the following code:

  template typename void f();
  void g() { fint; }

G++ opines:

  error: statement cannot resolve address of overloaded function

However, f is not overloaded. (The standard says: When two or more different
declarations are specified for a single name in the same scope, that name is
said to be overloaded.)

PS. As for the validity of the code: while I personally really wouldn't know
whether it is valid, I should for completeness at least mention that it is
accepted by Comeau.


-- 
   Summary: Diagnostic mistakenly characterizes function as being
overloaded
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug libstdc++/11196] parse error before numeric constant M_PI is defined in C++

[gcc-bugzilla at contacts dot eelis dot net]

--- Comment #7 from gcc-bugzilla at contacts dot eelis dot net  2007-11-13 
18:42 ---
(In reply to comment #6)
 The bug is that the C++ front end implicitly #defines _GNU_SOURCE. 
 [..]
 Could some libstdc++ guru explain why this define is actually needed? 

I am no libstdc++ guru, but this:

  echo #include cstdlib | g++ -x c++ -U _GNU_SOURCE -c -

produces:

  /usr/include/c++/4.1.2/cstdlib:162: error: ‘::lldiv_t’ has not been
declared
  /usr/include/c++/4.1.2/cstdlib:168: error: ‘::_Exit’ has not been
declared
  /usr/include/c++/4.1.2/cstdlib:175: error: ‘::llabs’ has not been
declared
  /usr/include/c++/4.1.2/cstdlib:177: error: ‘lldiv_t’ does not name a type
  /usr/include/c++/4.1.2/cstdlib:181: error: ‘::lldiv’ has not been
declared
  /usr/include/c++/4.1.2/cstdlib:196: error: ‘::strtof’ has not been
declared
  /usr/include/c++/4.1.2/cstdlib:197: error: ‘::strtold’ has not been
declared
  /usr/include/c++/4.1.2/cstdlib:203: error: ‘__gnu_cxx::lldiv_t’ has not
been declared
  /usr/include/c++/4.1.2/cstdlib:205: error: ‘__gnu_cxx::_Exit’ has not
been declared
  /usr/include/c++/4.1.2/cstdlib:208: error: ‘__gnu_cxx::llabs’ has not
been declared
  /usr/include/c++/4.1.2/cstdlib:209: error: ‘__gnu_cxx::div’ has not been
declared
  /usr/include/c++/4.1.2/cstdlib:210: error: ‘__gnu_cxx::lldiv’ has not
been declared
  /usr/include/c++/4.1.2/cstdlib:213: error: ‘__gnu_cxx::strtof’ has not
been declared
  /usr/include/c++/4.1.2/cstdlib:216: error: ‘__gnu_cxx::strtold’ has not
been declared


-- 


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

[Bug c++/33952] New: -Wfatal-errors truncates multi-line error messages.

[gcc-bugzilla at contacts dot eelis dot net]

Consider:

  int main () { goto foo; { int i = 0; foo:; } }

Compiling this snippet /without/ -Wfatal-errors produces:

  t.cpp: In function ‘int main()’:
  t.cpp:1: error: jump to label ‘foo’
  t.cpp:1: error:   from here
  t.cpp:1: error:   crosses initialization of ‘int i’

Compiling the snippet /with/ -Wfatal-errors, we get:

  t.cpp: In function ‘int main()’:
  t.cpp:1: error: jump to label ‘foo’
  compilation terminated due to -Wfatal-errors.

Alas, half the error message has disappeared.


-- 
   Summary: -Wfatal-errors truncates multi-line error messages.
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug c++/33952] -Wfatal-errors truncates multi-line error messages.

[gcc-bugzilla at contacts dot eelis dot net]

--- Comment #2 from gcc-bugzilla at contacts dot eelis dot net  2007-10-31 
00:44 ---
Then perhaps I ought to explain what I'm using -Wfatal-errors for.

I wrote an IRC bot called geordi ( http://www.eelis.net/geordi ) that accepts
lines of C++ code, compiles them with g++, and either reports the first
compilation error or proceeds to run the resulting program and report its
output. Geordi has proved to be an extremely useful demonstration tool that is
now used in several C++ channels, including Freenode's ##c++ and ##iso-c++.

Since geordi only reports the first error (if any), it passes -Wfatal-errors to
g++ to not waste time compiling further (response time is very important here).
Unfortunately, this means that it currently reports truncated errors for
snippets like the one I mentioned.


-- 


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

[Bug c++/33067] New: Awkward long decimal expansion for double literal in error.

[gcc-bugzilla at contacts dot eelis dot net]

Consider:

  struct T {} t;
  bool b = 1.1  t;

The code is invalid, but GCC's error message is peculiar:

  error: no match for 'operator' in
'1.100088817841970012523233890533447265625e+0  t'

The long decimal expansion makes for a messy error that suggests the user typed
something he did not.

It should just say:

  error: no match for 'operator' in '1.1  t'


-- 
   Summary: Awkward long decimal expansion for double literal in
error.
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net
  GCC host triplet: x86_64-suse-linux


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

[Bug c++/33067] Awkward long decimal expansion for double literal in error.

[gcc-bugzilla at contacts dot eelis dot net]

--- Comment #2 from gcc-bugzilla at contacts dot eelis dot net  2007-08-14 
17:19 ---
I know that, but that's irrelevant from a user interface perspective. The fact
remains that the error message is needlessly messy and would be far clearer and
less surprising to the user if it said 1.1 instead of
1.100088817841970012523233890533447265625e+0.


-- 


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

[Bug c++/33045] New: [c++0x] Incorrect decltype result for function calls.

[gcc-bugzilla at contacts dot eelis dot net]

Given:

  int  f ();
  template typename struct incomplete;
  incompletedecltype(f()) i;

GCC says (when invoked with -std=c++0x): 'incompleteint i' has incomplete
type

However, the latest standard draft (n2369) states in section 7.1.6.2 paragraph
4: if e is a function call [...], decltype(e) is the return type of that
function. So the error should've been: 'incompleteint  i' has incomplete
type.


-- 
   Summary: [c++0x] Incorrect decltype result for function calls.
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug libstdc++/31518] New: _GLIBCXX_DEBUG error message formatter line width not configurable

[gcc-bugzilla at contacts dot eelis dot net]

The _M_max_length member variable of _Error_formatter is not configurable. It
is currently initialized directly with the value 78, in
libstdc++-v3/include/debug/formatter.h . Having this be configurable (using a
macro, for example) would nicely follow gcc's -fmessage-length=N example.


-- 
   Summary: _GLIBCXX_DEBUG error message formatter line width not
configurable
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug c++/27689] New: [4.0/4.2 regression] function template incorrectly selected as candidate

[gcc-bugzilla at contacts dot eelis dot net]

The following code compiles with gcc version 4.0.2 20050901 (prerelease) but
does not compile with gcc version 4.2.0 20060513 (experimental)

  void f (...);
  template template typename class F, typename T void f (FT);
  template typename struct foo { struct bar {}; };
  void g (fooint::bar x) { f(x); } // error: call to f is ambiguous

Comeau 4.3.3 accepts the code.


-- 
   Summary: [4.0/4.2 regression] function template incorrectly
selected as candidate
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net


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

[Bug c++/27689] [4.1/4.2 regression] function template incorrectly selected as candidate

[gcc-bugzilla at contacts dot eelis dot net]

--- Comment #2 from gcc-bugzilla at contacts dot eelis dot net  2006-05-20 
21:32 ---
But for what F and T would FT match fooint::bar ?

In looking for workarounds I found that the same problem occurs when using
partial specialization:

  template typename struct S {};
  template template typename class T struct STint ;
  template typename struct foo { struct bar {}; };
  Sfooint::bar s; // error: S is incomplete

Again, Comeau accepts the code.

Finally, to show that at least *something* is wrong, consider:

  template typename struct S { enum { x }; };
  template template typename class T struct STint  { enum { x }; };
  template typename struct foo { struct bar {}; };
  int i = Sfooint::bar::x; // error: x is not a member of Sfooint::bar

Surely at least one of the two S versions should be selected, and both expose
x. (Again, Comeau accepts the code.)


-- 


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