[Bug target/30047] Corrupt return value in specific context

2008-06-08 Thread gcc at david dot osborn dot name


--- Comment #1 from gcc at david dot osborn dot name  2008-06-08 19:55 
---
Created an attachment (id=15736)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15736action=view)
reduced testcase

This bug still exists in GCC 4.3.1.  I've narrowed it down to line 183 in
bits/basic_ios.tcc where it says:

extern template class basic_ioschar;

If you comment out this line, the code produces the correct result (12345). 
Otherwise it produced zero consistently.  The attached testcase leaves a lot
out of the iostream classes, so it may be technically invalid.  But it yields
that same results as the previous testcase, as well as with respect to the
extern template line.

Also, the std::vector in the original testcase can be replaced by an empty
class with an explicit destructor.


-- 


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



[Bug target/30047] Corrupt return value in specific context

2008-06-08 Thread gcc at david dot osborn dot name


--- Comment #2 from gcc at david dot osborn dot name  2008-06-08 20:01 
---
Created an attachment (id=15738)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15738action=view)
compiler output

This shows bad code being generated.  The return value (12345) gets pushed into
eax on line 77, and then is subsequently overwritten for a call to
__Unwind_SjLj_Unregister.  Line 85 was added by me to show how to recover the
return value.


-- 


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



[Bug libstdc++/35637] New: tr1::function fails with const member function pointer

2008-03-19 Thread gcc at david dot osborn dot name
The following program fails under GCC 4.3.0 in pedantic mode, but works under
4.2.3.

#include tr1/functional
struct S
{
void F() const {}
};
int main()
{
std::tr1::functionvoid (S *) a(S::F); // doesn't work
std::tr1::functionvoid (S *) b(std::mem_fun(S::F)); // works
}

g++ -c -pedantic test.cpp
...
c:/devel/mingw/lib/gcc/../../include/c++/4.3.0/tr1_impl/type_traits:320: error:
ignoring 'const' qualifiers added to function type 'void ()()const'

I think the problem has to do with the way the signature gets decomposed.  It
starts off as void(S::*)()const.  Next, tr1::is_member_function_pointer removes
S::*, yielding void()()const.  Finally, tr1::is_function calls remove_cv, which
produces the above error.


-- 
   Summary: tr1::function fails with const member function pointer
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at david dot osborn dot name
  GCC host triplet: i686-pc-mingw32


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



[Bug c++/35182] New: ICE in coalesce_abnormal_edges

2008-02-13 Thread gcc at david dot osborn dot name
The following testcase produces an ICE. I couldn't reduce it any further. Fails
with GCC 4.2.2/4.2.3 under i686-pc-linux-gnu/i686-pc-mingw32.

#include tr1/array
#include tr1/memory
int main()
{
typedef std::tr1::arraystd::tr1::shared_ptrint, 1 Array;
Array array;
for (Array::iterator iter(array.begin());;)
{
try
{
(iter++)-reset(new int);
}
catch (...) {}
}
}

g++ -O test.cpp
test.cpp: In function 'int main()':
test.cpp:3: internal compiler error: in coalesce_abnormal_edges, at
tree-outof-ssa.c:643


-- 
   Summary: ICE in coalesce_abnormal_edges
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at david dot osborn dot name


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



[Bug libstdc++/33605] New: Comparable concepts cause errors with abstract types

2007-09-30 Thread gcc at david dot osborn dot name
The following code fails because __gnu_cxx::_LessThanOpConcept has member
variables of type iterator::value_type, where iterator is an iterator over
an abstract type.  20.1.2 (LessThanComparable) doesn't mention that the type
has to be concrete.

#define _GLIBCXX_CONCEPT_CHECKS
#include algorithm
#include tr1/memory
#include vector
#include boost/iterator/indirect_iterator.hpp

struct AbstractThing
{
virtual void F() = 0; // comment this out and it works
};
struct ConcreteThing : AbstractThing
{
void F() {}
};
bool operator (const AbstractThing , const AbstractThing )
{
return false;
}

int main()
{
typedef std::vectorstd::tr1::shared_ptrAbstractThing  Things;
Things things;
std::lower_bound(
boost::make_indirect_iterator(things.begin()),
boost::make_indirect_iterator(things.end()), ConcreteThing());
}

$ g++ -I../../../boost.1.34.0 -otest test.cpp
C:/devel/mingw/include/c++/4.2.1/bits/boost_concept_check.h: In instantiation
of
 '__gnu_cxx::_LessThanOpConceptAbstractThing, ConcreteThing':
C:/devel/mingw/include/c++/4.2.1/bits/boost_concept_check.h:63:   instantiated
f
rom 'void __gnu_cxx::__function_requires() [with _Concept =
__gnu_cxx::_LessThan
OpConceptAbstractThing, ConcreteThing]'
C:/devel/mingw/include/c++/4.2.1/bits/stl_algo.h:2894:   instantiated from
'_For
wardIterator std::lower_bound(_ForwardIterator, _ForwardIterator, const _Tp)
[w
ith _ForwardIterator =
boost::indirect_iterator__gnu_cxx::__normal_iteratorstd
::tr1::shared_ptrAbstractThing*,
std::vectorstd::tr1::shared_ptrAbstractThin
g, std::allocatorstd::tr1::shared_ptrAbstractThing   ,
boost::use_default
, boost::use_default, boost::use_default, boost::use_default, _Tp =
ConcreteThi
ng]'
test.cpp:26:   instantiated from here
C:/devel/mingw/include/c++/4.2.1/bits/boost_concept_check.h:299: error: cannot
d
eclare field '__gnu_cxx::_LessThanOpConceptAbstractThing, ConcreteThing::__a'
to be of abstract type 'AbstractThing'
test.cpp:8: note:   because the following virtual functions are pure within
'Abs
tractThing':
test.cpp:9: note:   virtual void AbstractThing::F()


-- 
   Summary: Comparable concepts cause errors with abstract types
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at david dot osborn dot name
 GCC build triplet: i686-pc-mingw32
  GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32


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



[Bug libstdc++/33605] Comparable concepts cause errors with abstract types

2007-09-30 Thread gcc at david dot osborn dot name


--- Comment #1 from gcc at david dot osborn dot name  2007-09-30 22:48 
---
Created an attachment (id=14275)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14275action=view)
Patch for predicate and arithmetic constraints

This patch fixes the immediate problem, but I think there may be other
instances of this issue in bits/boost_concept_check.h.  See this comment:

// possibly should be Tp* a; and then dereference a in constraint
// functions?  present way would require a default ctor, i think...


-- 


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



[Bug c++/33260] New: For scope warning despite -ffor-scope

2007-08-31 Thread gcc at david dot osborn dot name
The following program produces a variable scope warning, even when compiled
with -ffor-scope, preventing use of -Werror.  The documentation only mentions
warnings being generated if the flag is not given.

int main()
{
int i;
{
for (int i = 0; i  100; ++i);
return i;
}
}

g++ -ffor-scope -Werror -otest test.cpp
cc1plus.exe: warnings being treated as errors
test.cpp: In function 'int main()':
test.cpp:6: warning: name lookup of 'i' changed
test.cpp:3: warning:   matches this 'i' under ISO standard rules
test.cpp:5: warning:   matches this 'i' under old rules


-- 
   Summary: For scope warning despite -ffor-scope
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at david dot osborn dot name
 GCC build triplet: i686-pc-mingw32
  GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32


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



[Bug c++/31534] New: typedef template in function template argument deduction

2007-04-11 Thread gcc at david dot osborn dot name
With the following code, the compiler can't match the function template, with a
typedef template argument, when deduction is involved.

template typename T struct S
{
typedef T Type;
};
template typename T void F(typename ST::Type) {}
int main()
{
F(int());  // fails
F(Sint::Type()); // fails
Fint(int()); // succeeds
}

$ g++ -otest test.cpp
test.cpp: In function `int main()':
test.cpp:8: error: no matching function for call to `F(int)'
test.cpp:9: error: no matching function for call to `F(int)'


-- 
   Summary: typedef template in function template argument deduction
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at david dot osborn dot name
 GCC build triplet: i686-pc-mingw32
  GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32


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



[Bug c++/31534] typedef template in function template argument deduction

2007-04-11 Thread gcc at david dot osborn dot name


--- Comment #1 from gcc at david dot osborn dot name  2007-04-11 08:03 
---
It seems that nested types cannot be deduced according to the 14.8.2.4/4, which
is what I guess this is.  Sorry for the false report.


-- 

gcc at david dot osborn dot name changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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