[Bug c++/39863] variadic templates : wrong error mismatched argument pack lengths
--- Comment #1 from sylvain dot pion at sophia dot inria dot fr 2009-10-05 21:51 --- Same situation as of today's trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39863
[Bug c++/39866] [c++0x] deleted functions not removed from no match error messages
--- Comment #1 from sylvain dot pion at sophia dot inria dot fr 2009-10-05 21:52 --- Problem still present as of today's trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39866
[Bug c++/39863] New: variadic templates : wrong error mismatched argument pack lengths
The following code :
==
template typename... T
struct A {};
template typename T, typename U
struct S {};
template typename... T, typename... U
A ST, U... f(U... u)
{ return A ST, U... (); }
int main()
{
fint(0.0);
}
compiled with g++ -std=c++0x on today's trunk, produces :
test_variadic_2.cpp: In function 'int main()':
test_variadic_2.cpp:13: error: mismatched argument pack lengths while expanding
'ST, U'
test_variadic_2.cpp:13: error: no matching function for call to 'f(double)'
I believe this is a bug, and the code should be accepted.
--
Summary: variadic templates : wrong error mismatched argument
pack lengths
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sylvain dot pion at sophia dot inria dot fr
GCC host triplet: i386-apple-darwin9.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39863
[Bug c++/39866] New: [c++0x] deleted functions not removed from no match error messages
The following program :
=
struct A {
A operator=(const A) = delete;
void operator=(int) {}
void operator=(char) {}
};
struct B {};
int main()
{
A a;
a = B(); // no match
a = 1.0; // ambiguous
}
==
produces, with g++ -std=c++0x, current trunk version, the following
two error messages :
test_note_deleted_function.cpp: In function 'int main()':
test_note_deleted_function.cpp:13: error: no match for 'operator=' in 'a = B()'
test_note_deleted_function.cpp:2: note: candidates are: A A::operator=(const
A)
test_note_deleted_function.cpp:4: note: void A::operator=(int)
test_note_deleted_function.cpp:5: note: void A::operator=(char)
test_note_deleted_function.cpp:14: error: ambiguous overload for 'operator=' in
'a = 1.0e+0'
test_note_deleted_function.cpp:4: note: candidates are: void A::operator=(int)
test_note_deleted_function.cpp:5: note: void A::operator=(char)
Note how the deleted assignment operator is listed as candidate in the
no match error. It should probably be removed.
The ambiguous overload case does not mention it as candidate, which I think
is the right thing to do.
--
Summary: [c++0x] deleted functions not removed from no match
error messages
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sylvain dot pion at sophia dot inria dot fr
GCC host triplet: i386-apple-darwin9.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39866
[Bug other/6588] throw() takes 20,000 cycles : is it expected ?
--- Comment #9 from sylvain dot pion at sophia dot inria dot fr 2009-04-09 10:06 --- There seems to have been some progress : it now takes 6000-9000 cycles instead of 2. This is 6000 with g++ 4.3.1 on a Fedora 10 x86_64 box, and 9000 on a MacBook Pro with various g++ versions up to current mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6588
[Bug c++/36912] [4.2/4.3/4.4 regression] ICE with -frounding-math -g
--- Comment #9 from sylvain dot pion at sophia dot inria dot fr 2008-12-09 20:03 --- Incidentally, I submitted to WG21 a few days ago a proposal which will appear in the coming mid-term mailing as N2811, named Directed Rounding Arithmetic Operations. In the meantime, you can find it here: http://www-sop.inria.fr/members/Sylvain.Pion/cxx/rounded_operations_N2811.pdf This document proposes the addition of functions like: -- template float_round_style r, FloatingPointLike T, FloatingPointLike U requires True(r != round_indeterminate) constexpr auto add(T t, U u) - decltype(t + u); Returns: The addition of t and u rounded according to r. -- (and similarly for sub, mul, div, sqrt, fma, and int-float and float-float conversions). With these, it would be possible to explictly attach a rounding mode to an operation in the source code. Moreover, their constexpr nature would mean that they would work for compile-time constants as well. This would require a bit of help from the compiler. That would mean that code which cares about rounding modes would have a way to say so, and then, other codes can more easily be dealt with (that is: no need to bother thinking about the effect of -frounding-math on compile-time constants computations). (comments on the proposal are welcome, BTW) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36912
[Bug other/37625] 32-bit bootstrap failure on darwin9
--- Comment #2 from sylvain dot pion at sophia dot inria dot fr 2008-10-29 16:36 --- I have also seen this, and it seems that --with-libiconv-prefix=/sw/ does not do the trick anymore with the trunk (unless some other difference in my setup is responsible for this). Googleing a bit showed that the problem comes from the system iconv.h under /usr/include, which conflicts with Fink's under /sw/. A solution is to replace /usr/include/iconv.h by a symlink to /sw/include/iconv.h. Maybe there is a better solution, though. -- sylvain dot pion at sophia dot inria dot fr changed: What|Removed |Added CC||sylvain dot pion at sophia ||dot inria dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37625
[Bug c++/36912] [4.2/4.3/4.4 regression] ICE with -frounding-math -g
--- Comment #6 from sylvain dot pion at sophia dot inria dot fr 2008-08-18
16:12 ---
Maybe my comment is going to be out of scope, but the question is also
to know what the primary question is here, that is, what usage is supposed
to be supported by -frounding-math.
g++ currently accepts code like the following (in non-pedantic mode) :
template int i struct A {};
A(int) (1.5-2.0) a;
I am not sure it would be wise to have -frounding-math break this
(I understand that this would be a consequence of one of Jakub's proposals).
There are users who would like to see constant propagation of floats,
obviously, even with -frounding-math.
(see also C++0x's constexpr which requires this ability, I think).
And there are users who would like to have constant propagation aware
of the rounding mode (either deferring the computation at runtime,
and/or have a way to tell the compiler which rounding mode to use at
compile-time). It's also related to the FENV_ACCESS pragma.
The current behavior of -frounding-math which keeps on propagating
floats constants is not nice for interval arithmetic code (the main
user of -frounding-math I guess?): you need to protect against the
compiler in ways which affects performance (and code clarity like
introducing volatiles or other workarounds in odd places...).
The fact that -frounding-math affects the whole translation unit is
also problematic. Usually, it's only in very particular places that
you need to tell the compiler that a block of code needs such an
attention.
Ideally, for me, one should have the option to tell the compiler that
a block of code (e.g. using the new option attributes, or a pragma
a la FENV_ACCESS), or maybe even a single operation, depends on a
non-default rounding-mode, hence stopping inexact constant propagation
and other transformations.
As a bonus, it would be great to also have a way to tell the compiler
that the rounding-mode to be used is known at compile-time.
One could add another option e.g. -frounding-math-at-runtime to distinguish
the two behaviors mentioned by Jakub, but IMO this would not be helpful
for the users who want to mix the 2 features in the same translation unit.
My 2 cents.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36912
[Bug libstdc++/23888] should debug mode throw instead of assert?
--- Comment #5 from sylvain dot pion at sophia dot inria dot fr 2008-08-12 14:42 --- What about providing both modes, with for example a global run-time flag to select the mode which is the most appropriate ? And maybe defaulting to assert, since it looks like users might prefer this (?). Also, a side note : throwing an uncaught exception does not seem to destroy the stack, when you are under the debugger. I just made a test, and it seems to work. Here is the typical backtrace that you get: (gdb) bt #0 0x94ed0b9e in __kill () #1 0x94ed0b91 in kill$UNIX2003 () #2 0x94f47ec2 in raise () #3 0x94f5747f in abort () #4 0x91261005 in __gnu_cxx::__verbose_terminate_handler () #5 0x9125f10c in __gxx_personality_v0 () #6 0x9125f14b in std::terminate () #7 0x9125f261 in __cxa_throw () #8 0x1f79 in f (i=1) at test_throw_debug.cpp:3 #9 0x1f8c in main () at test_throw_debug.cpp:9 I agree it is still a problem for programs that catch the exception, thinking no other exception should occur. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23888
[Bug libstdc++/35588] New: parallel std::sort and bind()
, RandomAccessIterator3, Comparator, _DifferenceTp, bool, bool, __gnu_parallel::sequential_tag) [with RandomAccessIteratorIterator = __gnu_cxx::__normal_iteratorstd::pairint*, int**, std::__cxx1998::vectorstd::pairint*, int*, std::allocatorstd::pairint*, int* , RandomAccessIterator3 = int*, _DifferenceTp = int, Comparator = std::tr1::_Bindstd::lessint ()(std::tr1::_Placeholder1, std::tr1::_Placeholder2)]' /Users/spion/GCC/Darwin/lib/gcc/i386-apple-darwin8.11.1/4.4.0/../../../../include/c++/4.4.0/parallel/multiway_mergesort.h:311: instantiated from 'void __gnu_parallel::parallel_sort_mwms_pu(__gnu_parallel::PMWMSSortingDataRandomAccessIterator*, Comparator) [with RandomAccessIterator = int*, Comparator = std::tr1::_Bindstd::lessint ()(std::tr1::_Placeholder1, std::tr1::_Placeholder2)]' /Users/spion/GCC/Darwin/lib/gcc/i386-apple-darwin8.11.1/4.4.0/../../../../include/c++/4.4.0/parallel/multiway_mergesort.h:407: instantiated from 'void __gnu_parallel::parallel_sort_mwms(RandomAccessIterator, RandomAccessIterator, Comparator, typename std::iterator_traits_Iterator::difference_type, int, bool) [with RandomAccessIterator = int*, Comparator = std::tr1::_Bindstd::lessint ()(std::tr1::_Placeholder1, std::tr1::_Placeholder2)]' /Users/spion/GCC/Darwin/lib/gcc/i386-apple-darwin8.11.1/4.4.0/../../../../include/c++/4.4.0/parallel/sort.h:88: instantiated from 'void __gnu_parallel::parallel_sort(RandomAccessIterator, RandomAccessIterator, Comparator, bool) [with RandomAccessIterator = int*, Comparator = std::tr1::_Bindstd::lessint ()(std::tr1::_Placeholder1, std::tr1::_Placeholder2)]' /Users/spion/GCC/Darwin/lib/gcc/i386-apple-darwin8.11.1/4.4.0/../../../../include/c++/4.4.0/parallel/algo.h:1751: instantiated from 'void std::__parallel::sort(_RAIter, _RAIter, _Compare) [with _RAIter = int*, _Compare = std::tr1::_Bindstd::lessint ()(std::tr1::_Placeholder1, std::tr1::_Placeholder2)]' parallel_sort_bug.cpp:12: instantiated from here /Users/spion/GCC/Darwin/lib/gcc/i386-apple-darwin8.11.1/4.4.0/../../../../include/c++/4.4.0/parallel/multiway_merge.h:151: error: no match for call to '(std::tr1::_Bindstd::lessint ()(std::tr1::_Placeholder1, std::tr1::_Placeholder2)) (int, int)' /Users/spion/GCC/Darwin/lib/gcc/i386-apple-darwin8.11.1/4.4.0/../../../../include/c++/4.4.0/tr1_impl/functional:1189: note: candidates are: typename std::tr1::result_of_Functor ()(typename std::tr1::result_ofstd::tr1::_Mu_Bound_args, std::tr1::is_bind_expression::value, (std::tr1::is_placeholder::value 0) ()(_Bound_args, std::tr1::tuple_UElements ...)::type ...)::type std::tr1::_Bind_Functor ()(_Bound_args ...)::operator()(_Args ...) [with _Args = int, int, _Functor = std::lessint, _Bound_args = std::tr1::_Placeholder1, std::tr1::_Placeholder2] /Users/spion/GCC/Darwin/lib/gcc/i386-apple-darwin8.11.1/4.4.0/../../../../include/c++/4.4.0/tr1_impl/functional:1200: note: typename std::tr1::result_ofconst _Functor ()(typename std::tr1::result_ofstd::tr1::_Mu_Bound_args, std::tr1::is_bind_expression::value, (std::tr1::is_placeholder::value 0) ()(_Bound_args, std::tr1::tuple_UElements ...)::type ...)::type std::tr1::_Bind_Functor ()(_Bound_args ...)::operator()(_Args ...) const [with _Args = int, int, _Functor = std::lessint, _Bound_args = std::tr1::_Placeholder1, std::tr1::_Placeholder2] /Users/spion/GCC/Darwin/lib/gcc/i386-apple-darwin8.11.1/4.4.0/../../../../include/c++/4.4.0/tr1_impl/functional:1212: note: typename std::tr1::result_ofvolatile _Functor ()(typename std::tr1::result_ofstd::tr1::_Mu_Bound_args, std::tr1::is_bind_expression::value, (std::tr1::is_placeholder::value 0) ()(_Bound_args, std::tr1::tuple_UElements ...)::type ...)::type std::tr1::_Bind_Functor ()(_Bound_args ...)::operator()(_Args ...) volatile [with _Args = int, int, _Functor = std::lessint, _Bound_args = std::tr1::_Placeholder1, std::tr1::_Placeholder2] /Users/spion/GCC/Darwin/lib/gcc/i386-apple-darwin8.11.1/4.4.0/../../../../include/c++/4.4.0/tr1_impl/functional:1225: note: typename std::tr1::result_ofconst volatile _Functor ()(typename std::tr1::result_ofstd::tr1::_Mu_Bound_args, std::tr1::is_bind_expression::value, (std::tr1::is_placeholder::value 0) ()(_Bound_args, std::tr1::tuple_UElements ...)::type ...)::type std::tr1::_Bind_Functor ()(_Bound_args ...)::operator()(_Args ...) const volatile [with _Args = int, int, _Functor = std::lessint, _Bound_args = std::tr1::_Placeholder1, std::tr1::_Placeholder2] -- Summary: parallel std::sort and bind() Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sylvain dot pion at sophia dot inria dot fr GCC host triplet: i686-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35588
[Bug c++/34834] New: Accepts invalid code for partial specializations.
The following code is accepted by g++ (4.1, 4.3), while I think it is invalid.
-
template class T
struct A {};
template // This line should be removed
template class T
struct AT* {};
int main()
{
Aint a;
Aint * b;
}
--
Note that the Comeau compiler rejects it with the following error message:
ComeauTest.c, line 6: error: this declaration cannot have multiple template
... clauses
struct AT* {};
^
--
Summary: Accepts invalid code for partial specializations.
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sylvain dot pion at sophia dot inria dot fr
GCC host triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34834
[Bug c++/34480] Argument packs treat __null oddly
--- Comment #2 from sylvain dot pion at sophia dot inria dot fr 2008-01-02
21:37 ---
In fact, this is not really an issue with variadic templates,
since you get the same problem with:
void* g(int a) { return new (char*)(a); }
int main() {
g(__null);
}
Nevertheless, I opened an issue for the LWG for the original problem
with std::vector::push_back() which bothers me as well. The preview
of it can be found here:
http://home.twcny.rr.com/hinnant/cpp_extensions/issues_preview/lwg-active.html#767
I suggest that the component for this bug be changed from c++ to libstdc++,
and the title to something like:
[LWG Issue 767] push_back and push_front need overloads for type T
--
sylvain dot pion at sophia dot inria dot fr changed:
What|Removed |Added
CC||sylvain dot pion at sophia
||dot inria dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34480
[Bug libstdc++/34597] New: [C++0x] namespace posix_error is mising
In C++0x mode, the following program:
#include stdexcept
#include system_error
int main()
{
throw std::invalid_argument(foo);
}
fails to compile, as:
error: 'invalid_argument' cannot be used as a function
The problem is that system_error introduces invalid_argument as
an enum value, and the enum is wrongly declared in namespace std,
hence clashes with std::invalid_argument from stdexcept.
--
Summary: [C++0x] namespace posix_error is mising
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sylvain dot pion at sophia dot inria dot fr
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34597
[Bug libstdc++/34538] [DR 697] combination of sstream, invalid_argument and -std=c++0x breaks valid code
--- Comment #5 from sylvain dot pion at sophia dot inria dot fr 2007-12-27 11:36 --- Thank you Paolo, Looking at the current workding draft N2461, the protecting namespace is already there. So maybe the problem has already been dealt with independently, and issue 697 has been forgotten to be updated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34538
[Bug libstdc++/34595] New: std::copy copies the output iterator before assigning
The program below used to print 5. With g++ 4.3, it prints 0.
The program defines an output iterator which stores a counter,
to be incremented on each assignment of the output iterator.
The problem is that std::copy now copies the output iterator before
performing the assignment, so the program does not work anymore.
I am not sure it is a bug, I think it isn't.
Nevertheless, in doubt, I wanted to report the issue, as I think copying
output iterators too many times can also be a source of performance
degradation in some cases.
#include algorithm
#include iostream
class Counting_output_iterator
: public std::iterator std::output_iterator_tag, void, void, void, void
{
std::size_t c;
public:
Counting_output_iterator() : c(0) {}
Counting_output_iterator operator++() { return *this; }
Counting_output_iterator operator*() { return *this; }
template typename T
void operator=(const T) { ++c; }
std::size_t current_counter() const { return c; }
};
int main()
{
int t[10] = {0,};
Counting_output_iterator cnt;
std::size_t res = std::copy(t+0, t+5, cnt).current_counter();
std::cout res std::endl;
}
--
Summary: std::copy copies the output iterator before assigning
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sylvain dot pion at sophia dot inria dot fr
GCC host triplet: i386-apple-darwin8.11.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34595
[Bug c++/34573] New: ICE with nested class
The attached preprocessed source ICEs with current g++ 4.3 : ../../include/CGAL/Visibility_complex_2/Antichain.h:1394: internal compiler error: Bus error I really believe the code is valid, as it works with older g++ releases (although the preprocessed code attached does not, but it is due to library changes). I quickly tried to extract a reduced test case but failed, and prefer to submit a report soon. -- Summary: ICE with nested class Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sylvain dot pion at sophia dot inria dot fr GCC host triplet: i386-apple-darwin8.11.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34573
[Bug c++/34573] ICE with nested class
--- Comment #1 from sylvain dot pion at sophia dot inria dot fr 2007-12-24 16:00 --- Created an attachment (id=14819) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14819action=view) pre-processed test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34573
[Bug middle-end/31268] Non-deterministic bug producing a run-time infinite loop
--- Comment #15 from sylvain dot pion at sophia dot inria dot fr 2007-12-23 13:34 --- I also cannot reproduce it with todays' g++ 4.2. That said, the original code from which the test-case is extracted is still failing. The original code is from the CGAL library. I can give a way to reproduce it if someone is interested in digging this issue. As original submitter, I do not care that much about it, since g++ 4.3 is not affected, and there is an easy workaround for g++ 4.2 (-fno-strict-aliasing). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31268
[Bug c++/33112] ICE : canonical types differ for identical types const _CharT* [14] and const _CharT* [14]
--- Comment #3 from sylvain dot pion at sophia dot inria dot fr 2007-09-11 12:16 --- Hi Doug, I tried your patch, and it seems to have a good effect, since I do not see this error anymore. That said, I now get another one, which looks pretty similar: In file included from /usr/include/boost/type_traits.hpp:62, from /proj/geometrica/home/CGAL/CGAL-I/include/CGAL/Qualified_result_of.h:29, from /proj/geometrica/home/CGAL/CGAL-I/include/CGAL/kernel_basic.h:44, from /proj/geometrica/home/CGAL/CGAL-I/include/CGAL/basic.h:38, from /proj/geometrica/home/CGAL/CGAL-I/include/CGAL/Polynomial/internal/macros.h:31, from /proj/geometrica/home/CGAL/CGAL-I/include/CGAL/Polynomial/basic.h:42, from /proj/geometrica/home/CGAL/CGAL-I/include/CGAL/Polynomial/internal/numeric_solvers_support.h:24, from JAMA_numeric_solver.cpp:22: /usr/include/boost/type_traits/extent.hpp:101: internal compiler error: canonical types differ for identical types const T [] and const T [] Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33112
[Bug c++/33161] New: Undefined symbols at link for referenced static const data member
Compiling the following program, with g++ A.cpp fails to link
with the following error message :
/tmp/ccehheUK.o:(.rodata+0x0): undefined reference to `A::x'
collect2: ld returned 1 exit status
struct A {
static const int x = 0;
};
const int i = A::x;
int main() {}
It can be reproduced with g++ versions ranging from 3.2 to 4.3,
on Linux and Darwin.
Note that changing one int to unsigned makes it pass.
Is this really expected to fail ?
--
Summary: Undefined symbols at link for referenced static const
data member
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sylvain dot pion at sophia dot inria dot fr
GCC host triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33161
[Bug c++/33112] New: ICE : canonical types differ for identical types const _CharT* [14] and const _CharT* [14]
This is with today's g++ 4.3, but has been there for a few weeks: Configured with: /proj/geometrica/home/GCC/trunk/configure --with-gmp=/proj/geometrica/home/MPFR/MPFR-2.2.1/FC5 --disable-shared --disable-nls --enable-languages=c++,fortran --prefix=/proj/geometrica/home/GCC/Linux-fc5-4.3 Thread model: posix gcc version 4.3.0 20070819 (experimental) Compiling the attached preprocessed file with -c -O2 produces the following ICE. Note that it is not deterministic: you usually need to repeat the compile 10-20 times to see it... [EMAIL PROTECTED]:/proj/geometrica/home/CGAL/CGAL-I/src/CGAL while (/proj/geometrica/home/GCC/Linux-fc5-4.3/bin/g++ -c JAMA_numeric_solver.ii -O2 ) ; do ; echo OK ;done; OK OK OK OK OK In file included from /auto/papillon/u/papillon/0/projserver/geometrica/home/GCC/Linux-fc5-4.3/bin/../lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/locale:49, from /proj/geometrica/home/CGAL/CGAL-I/include/CGAL/Quotient.h:41, from /proj/geometrica/home/CGAL/CGAL-I/include/CGAL/Root_of_traits.h:27, from /proj/geometrica/home/CGAL/CGAL-I/include/CGAL/number_type_basic.h:87, from /proj/geometrica/home/CGAL/CGAL-I/include/CGAL/basic.h:36, from /proj/geometrica/home/CGAL/CGAL-I/include/CGAL/Polynomial/internal/macros.h:31, from /proj/geometrica/home/CGAL/CGAL-I/include/CGAL/Polynomial/basic.h:42, from /proj/geometrica/home/CGAL/CGAL-I/include/CGAL/Polynomial/internal/numeric_solvers_support.h:24, from JAMA_numeric_solver.cpp:22: /auto/papillon/u/papillon/0/projserver/geometrica/home/GCC/Linux-fc5-4.3/bin/../lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/locale_facets_nonio.h:176: internal compiler error: canonical types differ for identical types const _CharT* [14] and const _CharT* [14] Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. I have also been able to reproduce it with only -O. -- Summary: ICE : canonical types differ for identical types const _CharT* [14] and const _CharT* [14] Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sylvain dot pion at sophia dot inria dot fr GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33112
[Bug c++/33112] ICE : canonical types differ for identical types const _CharT* [14] and const _CharT* [14]
--- Comment #1 from sylvain dot pion at sophia dot inria dot fr 2007-08-19 12:55 --- Created an attachment (id=14076) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14076action=view) Compressed pre-processed C++ source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33112
[Bug c++/32260] New: too many warning: dereferencing type-punned pointer will break strict-aliasing rules
The following code, compiled with -O2 -Wall (g++ 4.3 as of 20070607),
produces the following unexpected/annoying warning:
test_typeinfo.cpp: In function 'int main()':
test_typeinfo.cpp:5: warning: dereferencing type-punned pointer will break
strict-aliasing rules
test_typeinfo.cpp:5: warning: unused variable 't'
~ cat test_typeinfo.cpp
#include typeinfo
int main()
{
const std::type_info t = typeid(int);
}
Is this really meant to warn for such a code???
--
Summary: too many warning: dereferencing type-punned pointer will
break strict-aliasing rules
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sylvain dot pion at sophia dot inria dot fr
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32260
[Bug c++/31841] New: warning: 'this.0' is used uninitialized in this function
Compiling the code below with -O2 -Wall produces the buggy warning
mentionned in the subject.
g++ 4.1 and 4.3 do not have this problem.
The code below is pretty minimal (extracted from CGAL).
For example, removing the derivation from the Empty_class
removes the buggy warning.
struct Empty_class {};
struct C : Empty_class {};
struct M {
static C f() { return C(); }
};
struct R {
C c;
R()
: c(M::f()) {}
};
int main()
{
R r;
return 0;
}
--
Summary: warning: 'this.0' is used uninitialized in this function
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sylvain dot pion at sophia dot inria dot fr
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31841
[Bug middle-end/31268] Non-deterministic bug producing a run-time infinite loop
--- Comment #13 from sylvain dot pion at sophia dot inria dot fr 2007-04-17 13:17 --- I just built g++ 4.2 yesterday, and the failure is still there. Note that if you want to check for an aliasing violation, even though the preprocessed code is huge, the parts which are executed are relatively small (see comment #4). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31268
[Bug c++/31268] Non-deterministic bug producing a run-time infinite loop
--- Comment #10 from sylvain dot pion at sophia dot inria dot fr 2007-03-26 18:03 --- Let me mention that this is against 4.2. The trunk works well for me. I tried several times during March (including today), and the bug is still here. Note that varrying the conditions slightly (even removing an innocent unused typedef) makes it work, so I'm not surprised that testing on x86_64 or powerpc makes it also work. It sounds like usage of uninitialized memory or some bad non-deterministic bug of this kind, although a quick test with valgrind did not show anything. Here are more details about my configuration: Fedora Core 5 on x86, compiler built with: .../g++ -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /proj/geometrica/home/GCC/gcc-4_2-branch/configure --disable-shared --disable-nls --enable-languages=c++ --prefix=/proj/geometrica/home/GCC/Linux-fc5-4.2 Thread model: posix gcc version 4.2.0 20070324 (prerelease) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31268
[Bug c++/31268] New: Non-deterministic bug producing a run-time infinite loop
It took me several hours to try to extract a usable test-case for this issue, so I hope you will be able to make sense out of it. The problem : compiling with current g++ 4.2, with -O2, makes the attached program loop infinitely, while it is not expected to. It does not loop with g++ 4.3 or older versions than 4.2. It also does not loop when adding -fno-strict-aliasing with g++ 4.2, or when compiling with -O only. Even more strange : it does not loop when I remove some unused bits of the program (which is why I had a hard time shrinking it down), for example unused typedefs (look for limb2). The relevant part of the program is a small class (MP_Float) containing an std::vectorshort, and some code around it, namely the operator_minus() function which is called, and which loops. I attach the pre-processed file, as well as the main small file so that you can see what is the relevant part of it, and decide if it is a compiler bug or an issue with my program. My program does some type conversions, which may be the source of the problem (triggering undefined behavior ?), but they seem fine to me. -- Summary: Non-deterministic bug producing a run-time infinite loop Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sylvain dot pion at sophia dot inria dot fr GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31268
[Bug c++/31268] Non-deterministic bug producing a run-time infinite loop
--- Comment #1 from sylvain dot pion at sophia dot inria dot fr 2007-03-19 16:27 --- I will happily create the attachements when bugzilla will work... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31268
[Bug c++/31268] Non-deterministic bug producing a run-time infinite loop
--- Comment #4 from sylvain dot pion at sophia dot inria dot fr 2007-03-19
16:50 ---
(sorry I still can't create attachments)
-ftrapw makes the program work (no loop).
Let me copy-paste here the non-preprocessed source files which show everything
which is executed, while waiting for bugzilla to allow me to add the large
pre-processed file.
-
#ifndef CGAL_MP_FLOAT_H
#define CGAL_MP_FLOAT_H
#include vector
typedef short limb; // unused
typedef intlimb2; // unused
struct MP_Float
{
typedef std::vectorshort V;
typedef V::iteratoriterator; // unused
V v;
int exp; // unused
MP_Float(short i)
: v(1)
{
v[0] = i;
canonicalize();
}
void remove_leading_zeros()
{
while ((!v.empty()) (v.back() == 0))
v.pop_back();
}
void remove_trailing_zeros()
{
if (v.empty() || (v.front() != 0))
return;
V::iterator i = v.begin();
for (++i; *i == 0; ++i) ;
//v.erase(v.begin(), i);
}
void canonicalize()
{
remove_leading_zeros();
remove_trailing_zeros();
}
// replacing int by std::size_t appears to also fix the loop...
int max_exp() const
{
return v.size();
}
short of_exp(int i) const
{
if (i = max_exp()) return 0;
return v[i];
}
};
// This union is used to convert an unsigned short to a short with
// the same binary representation, without invoking implementation-defined
// behavior (standard 4.7.3).
union to_signed {
unsigned short us;
short s;
};
inline
void split(int l, short high, short low)
{
to_signed l2 = {l};
low = l2.s;
high = (l - low) 16;
}
MP_Float
operator_minus(const MP_Float a, const MP_Float b /* unused */)
{
int max_exp = std::max(a.max_exp(), b.max_exp());
MP_Float r(0);
r.v.resize(2);
for(int i = 0; i max_exp ; ++i)
{
int tmp = r.v[i] + (a.of_exp(i) - b.of_exp(i));
split(tmp, r.v[i+1], r.v[i]);
}
r.canonicalize();
return r;
}
#endif // CGAL_MP_FLOAT_H
// #include CGAL/MP_Float_loop.h
#include CGAL/number_type_basic_loop.h // this one pulls up unrelated stuff
but necessary for the bug to show up
int main()
{
MP_Float a=2, b=1;
MP_Float d= operator_minus(a, a);
}
-
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31268
[Bug c++/31268] Non-deterministic bug producing a run-time infinite loop
--- Comment #5 from sylvain dot pion at sophia dot inria dot fr 2007-03-19 16:55 --- Subject: Re: Non-deterministic bug producing a run-time infinite loop Let me try to attach the pre-processed file through an email attachement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31268
[Bug c++/31268] Non-deterministic bug producing a run-time infinite loop
--- Comment #6 from sylvain dot pion at sophia dot inria dot fr 2007-03-19 19:37 --- Created an attachment (id=13235) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13235action=view) pre-processed source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31268
[Bug libstdc++/31246] New: Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
Compiling the following with -Wunreachable-code -D_GLIBCXX_DEBUG
--
#include vector
int main()
{
std::vectorint::iterator a;
}
--
produces the warning :
--
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/debug/safe_iterator.h:
In constructor __gnu_debug::_Safe_iterator_Iterator,
_Sequence::_Safe_iterator() [with _Iterator =
__gnu_cxx::__normal_iteratorint*, __gnu_norm::vectorint, std::allocatorint
, _Sequence = __gnu_debug_def::vectorint, std::allocatorint ]:
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/debug/safe_iterator.h:103:
warning: will never be executed
--
I tried g++ 4.1, 4.2 and 4.3. They all produce this annoying warning.
Looking at the code in safe_iterator.h shows nothing obviously wrong.
This might even suggest a bug in -Wunreachable-code, although I categorized
it for now in libstdc++, as I have not been able to isolate a small piece
of code that reproduces the problem.
Some other compilers tend to have the equivalent of -Wunreachable-code
by default. It would be nice if it worked well, and if it was enabled
by -Wall or -Wextra.
--
Summary: Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sylvain dot pion at sophia dot inria dot fr
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug libstdc++/31247] New: std::vector::iterator::value_type is accessible
This is an accepts invalid code report. The following code happens to compile with g++ (all versions), whereas the standard does not guarantee it should (I think). #include vector typedef std::vectorint::iterator Iterator; Iterator::value_type v; Iterator::pointer p; Iterator::iterator_category c; The problem is that developing code with g++, and introducing this kind of code by mistake, pops up errors later when other compilers are used (e.g. those which have pointers for std::vector::iterator). Would it be a good idea to make the access to such types somehow non public? For example by making them protected and making std::iterator_traits a friend? Or maybe only available when _GLIBCXX_DEBUG is not defined ? -- Summary: std::vector::iterator::value_type is accessible Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sylvain dot pion at sophia dot inria dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247
[Bug libstdc++/31246] Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
--- Comment #2 from sylvain dot pion at sophia dot inria dot fr 2007-03-17
17:26 ---
Trying further, I noticed that simply default constructing an std::vectorint,
even without the debug mode _GLIBCXX_DEBUG, generates also a bunch (14 !) of
these warnings.
Andrew, I did not follow all the details of your explanation. I don't
understand if there is finally a problem with the libstdc++ code or not.
And if there is, what should be done.
Is this a warning meant to be useful at all, or meant for GCC developers?
How do we get rid of this warning for the simplest C++ code I showed?
Other compilers are able to warn for unreachable code in better conditions.
for example, they warn for int f() { return 1 ; return -1; }, and I
was trying to see if GCC was able to generate the same kind of warnings.
I only found -Wunreachable-code, but so far it proves unusable for C++.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31246
[Bug libstdc++/31247] std::vector::iterator::value_type is accessible
--- Comment #3 from sylvain dot pion at sophia dot inria dot fr 2007-03-17 17:35 --- I'm not sure about the standard requirements. My user question is that I want to develop with GCC as my main compiler, and I want it to catch non-portability bugs as much as possible. @Chris: note that std::iterator_traits would not need to be specialized for std::vector::iterator if it was made a friend of it, so that it would be the only one able to access these types. The compiler I know which still has a pointer for std::vector::iterator is PGCC (the Portland Group Compiler). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247
[Bug c++/25468] New: -g makes g++ loop forever
The attached program compiles fine with g++ (4.0.3 as of 20051217). When adding -g, it looks like it loops forever (at least 15 minutes). Note that the program does not compile with g++ 4.1 (probably invalid). -- Summary: -g makes g++ loop forever Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sylvain dot pion at sophia dot inria dot fr GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25468
[Bug c++/25468] -g makes g++ loop forever
--- Comment #1 from sylvain dot pion at sophia dot inria dot fr 2005-12-17 22:26 --- Created an attachment (id=10522) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10522action=view) preprocessed C++ bzip2 file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25468
[Bug debug/25468] [3.4 Regression] -g makes g++ loop forever
--- Comment #2 from sylvain dot pion at sophia dot inria dot fr 2005-12-17 23:26 --- Created an attachment (id=10523) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10523action=view) Updated test-case I fixed the test-case so that it compiles (without -g) with g++ 4.1. g++ 4.1 shows the same problem (i.e. takes too long with -g). -- sylvain dot pion at sophia dot inria dot fr changed: What|Removed |Added Attachment #10522|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25468
[Bug c++/23797] New: ICE (on invalid)
The attached preprocessed file compiled with g++ produces the ICE : include/CGAL/_test_circles_constructions.h: In function 'void _test_circle_construct(CK2)': include/CGAL/_test_circles_constructions.h:294: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. I have not found the time to simplify/shorten it, but I believe that there is an invalid use of typename in the program. Removing this typename makes the compiler happy. -- Summary: ICE (on invalid) Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sylvain dot pion at sophia dot inria dot fr CC: gcc-bugs at gcc dot gnu dot org,sylvain dot pion at sophia dot inria dot fr GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23797
[Bug c++/23797] ICE (on invalid)
--- Additional Comments From sylvain dot pion at sophia dot inria dot fr 2005-09-09 14:41 --- Created an attachment (id=9702) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9702action=view) gzipped .ii c++ file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23797
[Bug c++/23724] New: name lookup bug
The attached program fails to compile with the following error message : pipo.C: In function 'void f(T) [with T = N::A]': pipo.C:24: instantiated from here pipo.C:15: error: no matching function for call to 'f(N::A, N::T1)' It works with g++ 4.0.1, 3.4.3 and 3.3.4, but fails with g++ 4.1 current CVS. I observed that renaming the 2-arguments f function to g fixes the problem. -- Summary: name lookup bug Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sylvain dot pion at sophia dot inria dot fr CC: gcc-bugs at gcc dot gnu dot org,sylvain dot pion at sophia dot inria dot fr GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23724
[Bug c++/23724] name lookup bug
--- Additional Comments From sylvain dot pion at sophia dot inria dot fr 2005-09-04 18:04 --- Created an attachment (id=9664) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9664action=view) Program that reproduces the error message -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23724
[Bug c++/23293] New: Misleading names in diagnostics for typedefs in functions
Compiling the attached program with g++ -Wall (3.3, 3.4, 4.0 and 4.1) produces : demo.C: In function `void generate_warning() [with U = Punrelated_function()::K]': demo.C:19: instantiated from here demo.C:14: warning: unused variable 'u' The problem here is that the warning names the type PS as Punrelated_function()::K, because it was first instantiated there, and it gives the typedef name. But the warning is generated in the function generate_warning(), which is completely unrelated to unrelated_function(). -- Summary: Misleading names in diagnostics for typedefs in functions Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sylvain dot pion at sophia dot inria dot fr CC: gcc-bugs at gcc dot gnu dot org,sylvain dot pion at sophia dot inria dot fr GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23293
[Bug c++/23293] Misleading names in diagnostics for typedefs in functions
--- Additional Comments From sylvain dot pion at sophia dot inria dot fr 2005-08-08 21:55 --- Created an attachment (id=9448) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9448action=view) c++ program that generates the warning -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23293
[Bug c++/23293] Misleading names in diagnostics for typedefs in functions
-- What|Removed |Added Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23293
[Bug c++/23227] New: SFINAE bug
The following code refuses to compile :
struct C;
template typename T
struct B;
template typename T
struct A;
void f(const C c);// this one is fine
void f(const BC a); // this one is fine
void f(const AC a); // this one triggers the bug
void f(double) {}
template typename T
struct A
{
BT b;
};
int main()
{
f(1.0); // = instantiates AC = instantiates BC = fails.
}
---
The error message is :
instance.C: In instantiation of 'AC':
instance.C:23: instantiated from here
instance.C:17: error: 'AT::b' has incomplete type
instance.C:4: error: declaration of 'struct BC'
I am not 100% sure it is a SFINAE bug, but it looks like one to me.
Note that if you comment the declaration of f(AC), then it works.
Similarly if you comment the definition of A.
So the problem here is probably that if the definition of A is
available, then the compiler instantiates it, which triggers the
instantiation of BT, which fails, but the compiler does not
recover from this instantiation as it should (following SFINAE).
There is the same problem with g++ 3.3, 3.4 and 4.0.1.
--
Summary: SFINAE bug
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sylvain dot pion at sophia dot inria dot fr
CC: gcc-bugs at gcc dot gnu dot org,sylvain dot pion at
sophia dot inria dot fr
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23227
[Bug tree-optimization/22483] [4.1 Regression] ICE : tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:466
--- Additional Comments From sylvain dot pion at sophia dot inria dot fr 2005-07-17 09:51 --- Please let me know if the attached fixes it Yes, it fixes my original report as well as the shorter testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22483
[Bug tree-optimization/22483] New: ICE : tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:466
Compiling the attached file with g++ -O2 produces : MP_Float.C: In function 'std::pairdouble, double CGAL::to_interval(const CGAL::QuotientCGAL::MP_Float)': MP_Float.C:425: internal compiler error: tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:466 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE : tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:466 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sylvain dot pion at sophia dot inria dot fr CC: gcc-bugs at gcc dot gnu dot org,sylvain dot pion at sophia dot inria dot fr GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22483
[Bug tree-optimization/22483] ICE : tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:466
--- Additional Comments From sylvain dot pion at sophia dot inria dot fr 2005-07-14 12:28 --- Created an attachment (id=9269) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9269action=view) gzipped preprocessed c++ file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22483
[Bug c++/20347] New: Long paths in error messages
This is a request for simplification of error messages, not a bug report.
Consider the following incorrect program, which generates an error
from inside the STL :
--
#include algorithm
struct A {};
A a[10];
int main() {
std::find(a, a+10, a[1]);
return 0;
}
--
The error message is :
--
/home/spion/GCC/Linux-4.0-2005-02-27/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_algo.h:
In function '_RandomAccessIterator std::find(_RandomAccessIterator,
_RandomAccessIterator, const _Tp, std::random_access_iterator_tag) [with
_RandomAccessIterator = A*, _Tp = A]':
/home/spion/GCC/Linux-4.0-2005-02-27/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_algo.h:315:
instantiated from '_InputIterator std::find(_InputIterator, _InputIterator,
const _Tp) [with _InputIterator = A*, _Tp = A]'
long_error_message.C:7: instantiated from here
/home/spion/GCC/Linux-4.0-2005-02-27/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_algo.h:207:
error: no match for 'operator==' in '* __first == __val'
/home/spion/GCC/Linux-4.0-2005-02-27/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_algo.h:211:
error: no match for 'operator==' in '* __first == __val'
/home/spion/GCC/Linux-4.0-2005-02-27/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_algo.h:215:
error: no match for 'operator==' in '* __first == __val'
/home/spion/GCC/Linux-4.0-2005-02-27/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_algo.h:219:
error: no match for 'operator==' in '* __first == __val'
/home/spion/GCC/Linux-4.0-2005-02-27/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_algo.h:227:
error: no match for 'operator==' in '* __first == __val'
/home/spion/GCC/Linux-4.0-2005-02-27/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_algo.h:231:
error: no match for 'operator==' in '* __first == __val'
/home/spion/GCC/Linux-4.0-2005-02-27/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_algo.h:235:
error: no match for 'operator==' in '* __first == __val'
---
Notice the useless substring lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../.
So my request is : would it be possible to simplify these paths
in disgnostic messages ?
--
Summary: Long paths in error messages
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sylvain dot pion at sophia dot inria dot fr
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20347
[Bug c++/20162] New: new/delete performance versus std::allocator
I do not understand why new/delete is slower than std::allocator. Is there a fundamental reason why it is so ? The benchmark program attached gives the following timing for series of new/delete versus std::allocator allocations/deallocations. new/delete std::allocator g++ 3.3.2 -O3 : 2.45 s 1.56 s g++ 3.4.3 -O3 : 2.25 s 2.24 s g++ 4.0.0 -O3 : 2.13 s 1.30 s -- Summary: new/delete performance versus std::allocator Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sylvain dot pion at sophia dot inria dot fr CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20162
[Bug c++/20162] new/delete performance versus std::allocator
--- Additional Comments From sylvain dot pion at sophia dot inria dot fr 2005-02-23 14:03 --- Created an attachment (id=8262) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8262action=view) Benchmark program to compare new/delete to std::allocator -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20162
[Bug tree-optimization/19786] [4.0 Regression] Aliasing optimisation bug
--- Additional Comments From sylvain dot pion at sophia dot inria dot fr 2005-02-18 20:48 --- (In reply to comment #13) I can't duplicate this with a tree updated some time earlier today. It has also disappeared for me on Fedora Core 3. But I can still reproduce it on Fedora Core 1, with a g++ which I have just built (20050218). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19786
[Bug tree-optimization/19786] New: Aliasing optimisation bug
The attached C++ program triggers an assertion violation when compiled with -O2 (it should not). The assertion is not triggered when adding -fno-strict-aliasing, or when removing -O2. It is also working when slight changes to the program are made (see comments in the source). It is the smallest version of the program which allowed me to reproduce the bug, but I did not try to look into the vector header. It might be an aliasing bug in vector, I don't know. Note that g++ 3.4 works fine. -- Summary: Aliasing optimisation bug Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sylvain dot pion at sophia dot inria dot fr CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19786
[Bug tree-optimization/19786] Aliasing optimisation bug
--- Additional Comments From sylvain dot pion at sophia dot inria dot fr 2005-02-06 10:20 --- Created an attachment (id=8135) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8135action=view) Compile with -O2 and execute It is not preprocessed, but uses vector (and cassert for illustration). I can send a preprocessed version if needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19786
[Bug c++/18436] New: ICE
I get an ICE with the attached pre-processed code. I get it with g++ 3.4.3, as well as 4.0.0-2004. With no particular command line option (-O2 or nothing produces it). -- Summary: ICE Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sylvain dot pion at sophia dot inria dot fr CC: gcc-bugs at gcc dot gnu dot org,sylvain dot pion at sophia dot inria dot fr GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18436
[Bug c++/18436] ICE
--- Additional Comments From sylvain dot pion at sophia dot inria dot fr 2004-11-12 00:12 --- Created an attachment (id=7523) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7523action=view) preprocessed source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18436
