[Bug c++/33911] attribute deprecated vs. templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911
Elias Pipping changed:
What|Removed |Added
CC||pipping at exherbo dot org
--- Comment #18 from Elias Pipping ---
The current status (with gcc 5.3) of these deprecation warnings is quite
surprising: from my point of view there are both false negatives and false
positives. Since clang's behaviour, additionally, differs considerably from
gcc's, it's currently almost impossible to deprecate something in a portable
fashion.
Here's an example. Let's assume I've reimplemented enable_if and want to
deprecated it.
namespace Dune {
template
struct [[deprecated]] enable_if
{};
template
struct enable_if<true,T>
{
typedef T type;
};
}
This generates a warning even if enable_if is never used anywhere, simply
through the template specialisation (if I were to remove the specialisation,
the warning would go away):
% g++ -c -std=c++14 test.cc -Wall -Wextra
test.cc:7:10: warning: ‘template struct Dune::enable_if’ is
deprecated [-Wdeprecated-declarations]
struct enable_if<true,T>
^
test.cc:3:25: note: declared here
struct [[deprecated]] enable_if
^
%
Clang does not emit a warning here.
Fair enough, maybe I should deprecate specialisations rather than the template.
But this does not work as expected, either. The following code surprisingly
does not emit a single warning:
#include
namespace Dune {
template
struct enable_if
{};
template
struct [[deprecated]] enable_if<false,T>
{};
template
struct [[deprecated]] enable_if<true,T>
{
typedef T type;
};
}
int
main()
{
using newint = Dune::enable_if<std::is_integral::value,int>::type;
newint i = 2;
++i;
}
[Bug libstdc++/65329] [C++14] constexpr complex::real(), imag() are non-const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65329
Elias Pipping changed:
What|Removed |Added
CC||pipping at exherbo dot org
--- Comment #4 from Elias Pipping ---
For future reference and anyone else trying to understand this bug, a bit more
info:
The fix in r216258 makes something like the following compile in C++14 mode
again:
#include
int
main()
{
std::complex const x(1,2);
int r = x.real();
}
The fact that int is used as the template parameter of std::complex is
important here: float, double, and long double are handled through a
specialisation that had already been adjusted in r198141.
Since the effect of instantiating std::complex where T is anything other
than one of those three floating point types is unspecified, types like
std::complex are probably hardly ever used except by accident; it thus
makes sense that it took two years for someone to come across this (although I
guess instead of int, users will probably typically plug in custom floating
point types).
[Bug c++/59995] New: constexpr in non-static member function causes segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59995
Bug ID: 59995
Summary: constexpr in non-static member function causes
segmentation fault
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pipping at exherbo dot org
This code
SNIP
class A {
int constexpr twice(int x) {
return 2 * x;
}
int const a = twice(1);
};
SNAP
Causes a segmentation fault for me (with -std=c++0x):
SNIP
gcc-bug.cc:5:24: internal compiler error: Segmentation fault
int const a = twice(1);
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
SNAP
[Bug c++/14258] typename in a using declaration not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14258
Elias Pipping pipping at exherbo dot org changed:
What|Removed |Added
CC||pipping at exherbo dot org
--- Comment #18 from Elias Pipping pipping at exherbo dot org ---
I'm a bit confused here. Please consider the following piece of code:
SNIP
template typename T struct A {
typedef int type;
};
template typename T struct B : public AT {
using typename AT::type;
static const int block_size = type::block_size;
};
SNAP
Compiling it with gcc 4.8.2 yields
foo.hh:9:33: error: ‘type’ is not a class, namespace, or enumeration
whereas clang 3.4 will happily accept it(*).
At a first glance, this bug appears to address issues such as this, so that gcc
4.8.2 should be fine. This does not seem to be the case, however -- the test
case provided by Jim Apple compiles but the one above does not; I'll have to
assume the bug was only partly fixed?
(*) I orginally thought this was not valid and filed a clang bug:
http://llvm.org/bugs/show_bug.cgi?id=18574
[Bug c++/14258] typename in a using declaration not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14258
--- Comment #21 from Elias Pipping pipping at exherbo dot org ---
(In reply to Jonathan Wakely from comment #19)
That example's a bit misleading, because 'int' really isn't a class,
namespace or enumeration, but the error's wrong because there could be a
specialization of A, and the same error is produced even if AT::type is
a class type.
You're right. This will reproduce the problem, too:
SNIP
struct C;
template typename T struct A {
typedef C type;
};
template typename T struct B : public AT {
using typename AT::type;
static const int block_size = type::block_size;
};
SNAP
[Bug c++/14258] typename in a using declaration not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14258 --- Comment #22 from Elias Pipping pipping at exherbo dot org --- I guess my test case is a reduction/duplicate of PR37140.
[Bug c++/53893] New: segfault with invalid c++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53893 Bug #: 53893 Summary: segfault with invalid c++ code Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: pipp...@exherbo.org The following piece of invalid C++0x code yields nannormtest.ii: In member function ‘double std::DenseVector::infinity_norm() const’: nannormtest.ii:8:80: internal compiler error: Segmentation fault
[Bug c++/53893] segfault with invalid c++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53893 --- Comment #1 from Elias Pipping pipping at exherbo dot org 2012-07-08 11:21:57 UTC --- Created attachment 27762 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27762 test case
[Bug c++/53893] segfault with invalid c++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53893 --- Comment #2 from Elias Pipping pipping at exherbo dot org 2012-07-08 11:43:11 UTC --- % g++-4.7 -v Using built-in specs. COLLECT_GCC=g++-4.7 COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/paludis/build/sys-devel-gcc-4.7.1/work/gcc-4.7.1/configure --prefix=/usr --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --enable-fast-install --libdir=/usr/lib64 --disable-multilib --libdir=/usr/lib64 --enable-clocale=gnu --enable-languages=c++,fortran --enable-libstdcxx-pch=yes --enable-nls --program-suffix=-4.7 --with-libelf --with-pkgversion='Exherbo gcc-4.7.1' --with-system-zlib --disable-graphite --disable-cloog-backend --without-cloog --without-ppl --disable-libgomp --disable-libssp Thread model: posix gcc version 4.7.1 (Exherbo gcc-4.7.1) % % g++-4.7 -std=c++0x nannormtest.ii nannormtest.ii: In member function ‘double std::DenseVector::infinity_norm() const’: nannormtest.ii:8:80: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. %
[Bug c++/53893] segfault with invalid c++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53893 Elias Pipping pipping at exherbo dot org changed: What|Removed |Added Attachment #27762|0 |1 is obsolete|| --- Comment #4 from Elias Pipping pipping at exherbo dot org 2012-07-08 14:04:11 UTC --- Created attachment 27764 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27764 test case I've reduced it a bit and tried to get it closer to valid code.
[Bug c++/50390] gcc hangs while compiling invalid c++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50390 Elias Pipping pipping at exherbo dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #5 from Elias Pipping pipping at exherbo dot org 2011-09-16 22:04:55 UTC --- If you say it's a bug, it's a bug. :)
[Bug c++/50390] gcc hangs while compiling invalid c++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50390 --- Comment #6 from Elias Pipping pipping at exherbo dot org 2011-09-16 22:08:16 UTC --- Created attachment 25308 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25308 reduction for gcc 4.6.1 I used gcc 4.5 during reduction, assuming that a reduced test case would hang for all versions since the original code did. Here's a reduced version that makes gcc 4.6 hang (but not 4.4 or 4.5).
[Bug c++/50390] gcc hangs while compiling invalid c++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50390 Elias Pipping pipping at exherbo dot org changed: What|Removed |Added Attachment #25266|0 |1 is obsolete|| --- Comment #1 from Elias Pipping pipping at exherbo dot org 2011-09-15 20:51:37 UTC --- Created attachment 25298 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25298 further reduced
[Bug c++/50390] gcc hangs while compiling invalid c++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50390 Elias Pipping pipping at exherbo dot org changed: What|Removed |Added Attachment #25298|0 |1 is obsolete|| --- Comment #2 from Elias Pipping pipping at exherbo dot org 2011-09-15 23:45:36 UTC --- Created attachment 25300 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25300 further reduced automatically reduced -- by character (so the file makes no effort to make sense anymore. just to make g++ hang)
[Bug c++/50390] gcc hangs while compiling invalid c++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50390 Elias Pipping pipping at exherbo dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Elias Pipping pipping at exherbo dot org 2011-09-16 00:23:07 UTC --- I'm starting to think that gcc is not actually hanging. If I use -ftemplate-depth with values around 100 I can get it to exit after a while. The order of growth is alarming, though (going from depth 100 to 150 makes it take ~6 times as long to exit), so since 1024 is the default it would certainly feel endless with that.
[Bug c++/50388] New: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50388 Bug #: 50388 Summary: Segmentation fault Classification: Unclassified Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: pipp...@exherbo.org Created attachment 25263 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25263 Original dump (xz-compressed) I'm attaching a preprocessor dump of C++ code that manages to make g++ segfault for me. This happens with g++ 4.5.3 but not with 4.4.6 or 4.6.1. The original dump is contained in the file test-edges0-memGKN.ii. % g++ -c test-edges0-memGKN.ii In file included from /home/cocktail/pipping/dune-git-svn/dune-grid/dune/grid/common/genericreferenceelements.hh:10:0, from /home/cocktail/pipping/dune-git-svn/dune-grid/dune/grid/common/geometry.hh:13, from /home/cocktail/pipping/dune-git-svn/dune-grid/dune/grid/genericgeometry/geometry.hh:10, from /home/cocktail/pipping/dune-git-svn/dune-grid/dune/grid/utility/mockgeometry.hh:12, from /home/cocktail/pipping/dune-git-svn/dune-localfunctions/dune/localfunctions/test/test-edges0.5.cc:17, from /home/cocktail/pipping/dune-git-svn/dune-localfunctions/dune/localfunctions/test/test-edges0.5.cc:1: /home/cocktail/pipping/dune-git-svn/dune-grid/dune/grid/genericgeometry/subtopologies.hh: In instantiation of ‘Dune::GenericGeometry::SizeImplDune::GenericGeometry::PyramidDune::GenericGeometry::Point, 1u, 0u’: /home/cocktail/pipping/dune-git-svn/dune-grid/dune/grid/genericgeometry/subtopologies.hh:130:7: instantiated from ‘Dune::GenericGeometry::SizeDune::GenericGeometry::PyramidDune::GenericGeometry::Point, 0u’ /home/cocktail/pipping/dune-git-svn/dune-grid/dune/grid/genericgeometry/subtopologies.hh:97:7: instantiated from ‘Dune::GenericGeometry::SizeImplDune::GenericGeometry::PyramidDune::GenericGeometry::PyramidDune::GenericGeometry::Point , 2u, 1u’ /home/cocktail/pipping/dune-git-svn/dune-grid/dune/grid/genericgeometry/subtopologies.hh:130:7: instantiated from ‘Dune::GenericGeometry::SizeDune::GenericGeometry::PyramidDune::GenericGeometry::PyramidDune::GenericGeometry::Point , 1u’ /home/cocktail/pipping/dune-git-svn/dune-grid/dune/grid/genericgeometry/referencedomain.hh:138:67: instantiated from ‘const unsigned int Dune::GenericGeometry::ReferenceDomainBaseDune::GenericGeometry::PyramidDune::GenericGeometry::PyramidDune::GenericGeometry::Point ::numNormals’ /home/cocktail/pipping/dune-git-svn/dune-grid/dune/grid/genericgeometry/referencedomain.hh:235:44: instantiated from ‘const unsigned int Dune::GenericGeometry::ReferenceDomainDune::GenericGeometry::PyramidDune::GenericGeometry::PyramidDune::GenericGeometry::Point ::numNormals’ /home/cocktail/pipping/dune-git-svn/dune-grid/dune/grid/common/genericreferenceelements.hh:354:7: [ skipping 3 instantiation contexts ] /home/cocktail/pipping/dune-git-svn/dune-grid/dune/grid/common/genericreferenceelements.hh:620:7: instantiated from ‘Dune::GenericReferenceElementContainerctype, dim::GenericReferenceElementContainer() [with ctype = double, int dim = 2]’ /home/cocktail/pipping/dune-git-svn/dune-grid/dune/grid/common/genericreferenceelements.hh:603:47: instantiated from ‘static const Dune::GenericReferenceElementContainerctype, dim Dune::GenericReferenceElementContainerctype, dim::instance() [with ctype = double, int dim = 2, Dune::GenericReferenceElementContainerctype, dim = Dune::GenericReferenceElementContainerdouble, 2]’ /home/cocktail/pipping/dune-git-svn/dune-grid/dune/grid/common/genericreferenceelements.hh:645:79: instantiated from ‘static const Dune::GenericReferenceElementctype, dim Dune::GenericReferenceElementsctype, dim::general(const Dune::GeometryType) [with ctype = double, int dim = 2]’ /home/cocktail/pipping/dune-git-svn/dune-grid/dune/grid/utility/vertexorder.hh:100:36: instantiated from ‘Dune::GeneralVertexOrderdim, Index_::GeneralVertexOrder(const Dune::GeometryType, const InIterator, const InIterator) [with InIterator = long unsigned int*, long unsigned int dim = 2ul, Index_ = long unsigned int]’ /home/cocktail/pipping/dune-git-svn/dune-localfunctions/dune/localfunctions/test/test-edges0.5.cc:47:40: instantiated from ‘void testEdgeS0_5(int) [with long unsigned int dim = 2ul]’ /home/cocktail/pipping/dune-git-svn/dune-localfunctions/dune/localfunctions/test/test-edges0.5.cc:62:27: instantiated from here /home/cocktail/pipping/dune-git-svn/dune-grid/dune/grid/genericgeometry/subtopologies.hh:108:110: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. % Delta allowed me to reduce the size of the input from 2.1M to 20K but not further. The name of the reduced file is
[Bug c++/50388] Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50388 --- Comment #1 from Elias Pipping pipping at exherbo dot org 2011-09-13 21:38:04 UTC --- Created attachment 25264 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25264 delta-reduced dump
[Bug c++/50390] New: gcc hangs while compiling invalid c++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50390 Bug #: 50390 Summary: gcc hangs while compiling invalid c++ code Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: pipp...@exherbo.org Created attachment 25266 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25266 likely hang delta-reduced from a preprocessor dump (that was valid code and did not cause a hang) I'm attaching a preprocessor dump of C++ code that appears to make g++ hang for me. This happens with g++ 4.4.6, 4.5.3, and 4.6.1. This file (likely-hang6-bcpp.ii) is a delta reduction of the file test-edges0-memGKN.ii.xz from bug #50388 (attachment 25263). The differences to the file reduce-gcc-segfault/test-edges0-memGKN-segfault-bcpp.ii (attachment 25264) which is also attached to bug #50388, are marginal. g++ 4.6.1 hangs at this point: % g++- -c likely-hang6-bcpp.ii likely-hang6-bcpp.ii:150:36: warning: variadic templates only available with -std=c++0x or -std=gnu++0x [enabled by default] likely-hang6-bcpp.ii:154:52: warning: variadic templates only available with -std=c++0x or -std=gnu++0x [enabled by default] likely-hang6-bcpp.ii:158:26: warning: variadic templates only available with -std=c++0x or -std=gnu++0x [enabled by default] likely-hang6-bcpp.ii:322:90: error: template instantiation depth exceeds maximum of 1024 (use -ftemplate-depth= to increase the maximum) instantiating ‘class Dune::GenericGeometry::HybridMappingBase2u, Dune::GenericGeometry::DefaultGeometryTraitsdouble, 2, 2, false, 4294966286u’ likely-hang6-bcpp.ii:322:90: recursively instantiated from ‘Dune::GenericGeometry::HybridMappingBase2u, Dune::GenericGeometry::DefaultGeometryTraitsdouble, 2, 2, false, 1u’ likely-hang6-bcpp.ii:322:90: instantiated from ‘Dune::GenericGeometry::HybridMappingBase2u, Dune::GenericGeometry::DefaultGeometryTraitsdouble, 2, 2, false, 2u’ likely-hang6-bcpp.ii:325:70: instantiated from ‘Dune::GenericGeometry::HybridMapping2u, Dune::GenericGeometry::DefaultGeometryTraitsdouble, 2, 2, false ’ likely-hang6-bcpp.ii:335:68: instantiated from ‘Dune::GenericGeometry::VirtualMappingDune::GenericGeometry::PrismDune::GenericGeometry::PrismDune::GenericGeometry::Point , Dune::GenericGeometry::DefaultGeometryTraitsdouble, 2, 2, false ’ likely-hang6-bcpp.ii:345:60: recursively instantiated from ‘const int Dune::GenericGeometry::StaticMaximumDune::GenericGeometry::VirtualMappingFactory2u, Dune::GenericGeometry::DefaultGeometryTraitsdouble, 2, 2, false ::MappingSize1, Dune::GenericForLoopDune::GenericGeometry::StaticMaximum, Dune::GenericGeometry::VirtualMappingFactory2u, Dune::GenericGeometry::DefaultGeometryTraitsdouble, 2, 2, false ::MappingSize, 2, 3 ::v’ likely-hang6-bcpp.ii:345:60: instantiated from ‘const int Dune::GenericGeometry::StaticMaximumDune::GenericGeometry::VirtualMappingFactory2u, Dune::GenericGeometry::DefaultGeometryTraitsdouble, 2, 2, false ::MappingSize0, Dune::GenericForLoopDune::GenericGeometry::StaticMaximum, Dune::GenericGeometry::VirtualMappingFactory2u, Dune::GenericGeometry::DefaultGeometryTraitsdouble, 2, 2, false ::MappingSize, 1, 3 ::v’ likely-hang6-bcpp.ii:360:100: instantiated from ‘const unsigned int Dune::GenericGeometry::VirtualMappingFactory2u, Dune::GenericGeometry::DefaultGeometryTraitsdouble, 2, 2, false ::maxMappingSize’ likely-hang6-bcpp.ii:396:80: instantiated from ‘const unsigned int Dune::GenericGeometry::MappingProviderDune::GenericGeometry::HybridMapping2u, Dune::GenericGeometry::DefaultGeometryTraitsdouble, 2, 2, false , 0u::maxMappingSize’ likely-hang6-bcpp.ii:423:67: instantiated from ‘Dune::GenericGeometry::BasicGeometry2, Dune::GenericGeometry::DefaultGeometryTraitsdouble, 2, 2, false ’ likely-hang6-bcpp.ii:426:76: instantiated from ‘Dune::MockGeometrydouble, 2ul, 2ul’ likely-hang6-bcpp.ii:447:9: instantiated from ‘TestGeometriesctype, 2ul::TestGeometries() [with ctype = double]’ likely-hang6-bcpp.ii:453:27: instantiated from ‘void testEdgeS0_5(int) [with long unsigned int dim = 2ul]’ likely-hang6-bcpp.ii:462:31: instantiated from here likely-hang6-bcpp.ii:322:90: error: invalid use of incomplete type ‘class Dune::GenericGeometry::HybridMappingBase2u, Dune::GenericGeometry::DefaultGeometryTraitsdouble, 2, 2, false, 4294966286u’ likely-hang6-bcpp.ii:322:90: error: declaration of ‘class Dune::GenericGeometry::HybridMappingBase2u, Dune::GenericGeometry::DefaultGeometryTraitsdouble, 2, 2, false, 4294966286u’
