[Bug c++/84075] Template parameter not resolved: invalid application of ‘sizeof’ to incomplete type ‘boost::serialization::U’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84075 Christoph Hertzberg changed: What|Removed |Added CC||chtz at informatik dot uni-bremen. ||de --- Comment #8 from Christoph Hertzberg --- Another case where someone hit this problem: https://stackoverflow.com/questions/54534047/eigen-matrix-boostserialization-c17/ Corresponding Bug at the Eigen-library: http://eigen.tuxfamily.org/bz/show_bug.cgi?id=1676
[Bug c++/84075] Template parameter not resolved: invalid application of ‘sizeof’ to incomplete type ‘boost::serialization::U’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84075 --- Comment #9 from Christoph Hertzberg --- Independent of this issue, the forward declaration in boost/serialization/shared_ptr_helper.hpp does not make sense. I created a PR to fix that: https://github.com/boostorg/serialization/pull/144
[Bug c++/89325] [7/8/9/10 Regression] False warnings about "optimization attribute" on operators when -fno-ipa-cp-clone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89325 Christoph Hertzberg changed: What|Removed |Added CC||chtz at informatik dot uni-bremen. ||de --- Comment #6 from Christoph Hertzberg --- Related: http://eigen.tuxfamily.org/bz/show_bug.cgi?id=1724 We just mask the warning for g++-7 at the moment.
[Bug c++/87503] New: Spurious -Wunused-but-set-variable warning in template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87503
Bug ID: 87503
Summary: Spurious -Wunused-but-set-variable warning in template
function
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chtz at informatik dot uni-bremen.de
Target Milestone: ---
Using g++ 8.1.0 and compiling the following minimal example with -Wall
template
Index bar(Index rows, Index cols) {
const bool left = flag;
Index x = left ? rows : cols;
return x;
}
int main() {
return bar(1,2);
}
I'm getting this:
warning: variable ‘left’ set but not used [-Wunused-but-set-variable]
This works fine with g++-7.3 (or earlier) and seems to be fixed in 8.2.0 (I
don't have easy access to 8.1.1. If it has been fixed there already, apologies
for the noise)
Maybe related issue: Bug 85827
[Bug c++/87613] New: Non-reachable default required in switch statement to get optimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87613 Bug ID: 87613 Summary: Non-reachable default required in switch statement to get optimal code Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: chtz at informatik dot uni-bremen.de Target Milestone: --- Created attachment 44841 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44841&action=edit Sample code with non-reachable default case Compiling the attached code with -O2 generates a jump-table, which directly contains the `foo()` function addresses. Removing the (non-reachable) `default` case generates an indirect jump-table which jumps to code that first moves the function address into a register and then jumps. In g++-8.x this always generates optimal code, but without the default-case a warning is generated: warning: control reaches end of non-void function [-Wreturn-type] Godbolt-Link (try around with commenting in/out the default or return 0;) https://godbolt.org/z/itpvL6 Directly returning writing this also leads to an indirect jump-table: case X: return foo();
[Bug c++/53900] [regression] Too optimistic on a alignment assert
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53900 --- Comment #7 from Christoph Hertzberg 2013-01-07 10:19:13 UTC --- (In reply to comment #6) > > __attribute__((aligned(16))) float array[4]; > > Explicitly says the array is aligned to 16 bytes which means it is undefined > by > the C/C++ standard what happens if you a pointer to the struct which contains > this array. As this pointer will always be aligned by definition of the > struct > (and any other use of it is undefined), then by definition > std::ptrdiff_t(array) will always have the lower 8bits be zero. So does that mean that new and std::allocator act undefined for aligned objects? Is there anything wrong with Gael's second test case?
[Bug libstdc++/81599] New: Error in documentation of std::stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81599 Bug ID: 81599 Summary: Error in documentation of std::stack Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: chtz at informatik dot uni-bremen.de Target Milestone: --- I just noticed an error in the documentation of std::stack. It is claimed here: https://gcc.gnu.org/onlinedocs/gcc-7.1.0/libstdc++/api/a01646_source.html#l00087 that the underlying container must support "@c back, @c push_back, and @c pop_front," however, it must of course provide pop_back (instead of pop_front). The error seems to have existed for quite a while, e.g., in version 4.6 is exactly the same paragraph: https://gcc.gnu.org/onlinedocs/gcc-4.6.4/libstdc++/api/a01078_source.html#l00083
[Bug c++/66472] -Wshadow gets confused by using statements in template classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66472
Christoph Hertzberg changed:
What|Removed |Added
CC||chtz at informatik dot
uni-bremen.
||de
--- Comment #1 from Christoph Hertzberg
---
Wouldn't this actually be a valid warning if BaseClass had a constructor taking
a function pointer/member function pointer?
struct BaseClass {
BaseClass(int) { std::cout << "int\n"; }
BaseClass(int () ) { std::cout << "int()\n"; }
BaseClass(int (BaseClass::*)()) {std::cout << "int (BaseClass::*)()\n"; }
static int size() { return 0;}
int size2() { return 0; }
};
struct Foo : public BaseClass {
using BaseClass::size;
using BaseClass::size2;
// size shadows BaseClass::size!
Foo(int size) : BaseClass(size) {}
Foo() : BaseClass(size) {} // uses BaseClass::size
Foo(char) : BaseClass(size2) {} // uses BaseClass::size2
};
[Bug c++/66472] -Wshadow gets confused by using statements in template classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66472
--- Comment #6 from Christoph Hertzberg
---
Ok, good point on shadowing free functions.
Next pathological example: If you have a template specialization of your Base
with a static member variable called `size`, wouldn't the warning make sense?
template
struct Base {
Base(int y) {std::cout << "y=" <
struct Bar : Base {
using Base::size;
Bar(int size) : Base(size) {}
Bar() : Base(size) {} // only works for T==int
};
// Specialization, probably not visible when Bar is defined:
template<>
struct Base {
Base(int x) {std::cout << "x=" <
[Bug c++/46872] New: 'using' in templated inheritance makes protected member public
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46872 Summary: 'using' in templated inheritance makes protected member public Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: c...@informatik.uni-bremen.de Hi, I can compile the attached piece of code, which I think is illegal C++. I checked several other compilers which all reject it. Also, the same programm without templates fails in g++ (as expected), too. I'm not sure if this behaviour is somehow intended but it does not seem logical to me at all. Best regards, Christoph
[Bug c++/46872] 'using' in templated inheritance makes protected member public
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46872 --- Comment #1 from Christoph Hertzberg 2010-12-09 17:21:37 UTC --- Created attachment 22694 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22694 code that should fail to compile
[Bug c++/46872] 'using' in templated inheritance makes protected member public
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46872 Christoph Hertzberg changed: What|Removed |Added Resolution|WORKSFORME |FIXED --- Comment #3 from Christoph Hertzberg 2010-12-09 18:23:32 UTC --- (In reply to comment #2) > Indeed it does, in current 4.5 branch and mainline. 4.3.x is not maintained > anymore. Just checked it on a slightly more up-to-date machine, it seems to have been fixed at least in 4.4.1 already. Sorry for the noise.
[Bug c++/98429] New: Some FMA expressions are evaluated less efficiently when -ffast-math is active
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98429 Bug ID: 98429 Summary: Some FMA expressions are evaluated less efficiently when -ffast-math is active Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: chtz at informatik dot uni-bremen.de Target Milestone: --- If you compile an expression like x - x*y using fast-math optimizations it appears to get re-arranged to x*(1-y) which is (probably) never more efficient than the original expression, especially if the target supports FMA operations. Simple godbolt demonstration: https://godbolt.org/z/4q1oj9 (This is very likely not C++ specific, but I'm not sure what the correct component is -- I also just tried this for AVX-FMA)
