[Bug c++/103057] [11/12 Regression] Internal compiler error: Error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103057 --- Comment #5 from Dennis Lubert --- Created attachment 51759 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51759=edit cvise generated compling testcase This one is pretty big but compiles with -w but ICEs without it. Differently to my original code, here there is no unused argument that when being used silences the warning and so circumvents the ICE. So I am not totally sure if there maybe a third bug lurking somewhere... Currently our code to be able to not ICE disables Wunused-parameter and Wunused-value for the functions in question.
[Bug c++/103057] Internal compiler error: Error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103057 --- Comment #3 from Dennis Lubert --- Yes, the original testcase is valid code that compiles fine with -w
[Bug c++/103057] New: Internal compiler error: Error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103057 Bug ID: 103057 Summary: Internal compiler error: Error reporting routines re-entered Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: plasmahh at gmx dot net Target Milestone: --- Created attachment 51728 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51728=edit cvise generated testcase Compiling the attached testcase (generated with cvise out of a "real world" piece of code, where supressing an "unused parameter" warning makes this go away, due to the testcase being an error now, the error will trigger it too I guess) with -std=gnu++2b (and likely some others) will ICE out: Internal compiler error: Error reporting routines re-entered. 0xbd474d cxx_incomplete_type_diagnostic(unsigned int, tree_node const*, tree_node const*, diagnostic_t) ../../gcc/cp/typeck2.c:330 0xb6629c cxx_incomplete_type_diagnostic(tree_node const*, tree_node const*, diagnostic_t) ../../gcc/cp/cp-tree.h:8016 0xb6629c cxx_incomplete_type_error(tree_node const*, tree_node const*) ../../gcc/cp/cp-tree.h:8025 0xb6629c instantiate_class_template_1 ../../gcc/cp/pt.c:12106 0xb66cd2 instantiate_class_template(tree_node*) ../../gcc/cp/pt.c:12302 0xbb58d9 complete_type(tree_node*) ../../gcc/cp/typeck.c:143 0xbb5a94 complete_type(tree_node*) ../../gcc/cp/typeck.c:169 0xbb5a94 complete_type_or_maybe_complain(tree_node*, tree_node*, int) ../../gcc/cp/typeck.c:156 0xb4ddb2 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.c:16069 0xb4ef9b tsubst_template_args(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.c:13411 0xb4caa2 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.c:15449 0xa3266c dump_template_bindings ../../gcc/cp/error.c:482 0xa2bbba dump_function_decl ../../gcc/cp/error.c:1796 0xa33e0d decl_to_string ../../gcc/cp/error.c:3216 0xa33e0d cp_printer ../../gcc/cp/error.c:4387 0x1f9317c pp_format(pretty_printer*, text_info*) ../../gcc/pretty-print.c:1475 0x1f76b92 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) ../../gcc/diagnostic.c:1342 0x1f770f6 diagnostic_impl ../../gcc/diagnostic.c:1504 0x1f7787f permerror(unsigned int, char const*, ...) ../../gcc/diagnostic.c:1771 0xa26072 c_parse_final_cleanups() ../../gcc/cp/decl2.c:5255
[Bug c++/88761] [8/9 Regression] ICE in tsubst_copy, at cp/pt.c:15478 when chaining lambda calls & fold-expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88761
Dennis Lubert changed:
What|Removed |Added
CC||plasmahh at gmx dot net
--- Comment #3 from Dennis Lubert ---
I was just about to report the same bug (internal compiler error: in
tsubst_copy, at cp/pt.c:15478) but with different code, maybe this can shed
more light on why it is happening, if not, just ignore it:
#include
#include
#include
int main(int argc, const char *argv[])
{
const size_t nf = 10'000'000;
auto loop = [&]( auto& vector )
{
long double cy = 0;
auto per = cy/nf;
};
std::vector pv;
loop( pv );
}
[Bug target/82418] Division on a constant is suboptimal because of not using imul instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82418
Dennis Lubert changed:
What|Removed |Added
CC||plasmahh at gmx dot net
--- Comment #5 from Dennis Lubert ---
Was about to open a bug for this very same thing myself.
I came from another route, noticing that our own implementation of /100
uint32_t divx( uint32_t r)
{
uint32_t u = r * 1374389535uLL;
u >>= 5u;
return u;
}
produces
imull $1374389535, %edi, %eax
shrl$5, %eax
ret
whereas the code generated by gcc above is (depending on actual circumstances)
making our int to string function run 13-15% slower.
I was hoping I could reduce the use of magic numbers and instead use readable
code.
For some reason clang moves edi to eax and then calls imul, whereas the above
divx directly uses edi, this might be worth adding too.
[Bug c++/54011] missed optimization opportunities for bool struct/class members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54011 Dennis Lubert changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE |--- --- Comment #2 from Dennis Lubert --- The duplicate has been closed as resolved, however the compilation of this example has not changed and is imho still a good opportunity for optimization. Have a look on the gcc explorer with -O3 and gcc 7.3 : https://godbolt.org/g/qWvpSg
[Bug c++/61229] New: warn_unused_result fails to work with member functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61229
Bug ID: 61229
Summary: warn_unused_result fails to work with member functions
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: plasmahh at gmx dot net
Since gcc 4.5 (4.4 is fine) the following code will not emit any warning:
struct A
{
__attribute__((warn_unused_result)) int callme( ) { return 42; }
};
struct B
{
void foo( A a )
{
a.callme();
}
};
[Bug c++/61229] warn_unused_result fails to work with member functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61229
Dennis Lubert plasmahh at gmx dot net changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |---
--- Comment #2 from Dennis Lubert plasmahh at gmx dot net ---
Since someone else pointed out that there is a bug talking about duplicates
already, now how my real code is more like the following. Also note that it
warns when I remove the dtor of evr.
struct evr
{
~evr( );
};
struct evd
{
virtual __attribute__((warn_unused_result)) evr rs( ) = 0;
};
class sd
{
[[gnu::warn_unused_result]] evr callme( evd );
};
evr sd::callme( evd edis )
{
edis.rs();
}
[Bug libstdc++/60421] std::this_thread::sleep_for doesn't sleep for all arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60421 Dennis Lubert plasmahh at gmx dot net changed: What|Removed |Added CC||plasmahh at gmx dot net --- Comment #1 from Dennis Lubert plasmahh at gmx dot net --- Note that for me to reproduce this, _GLIBCXX_USE_NANOSLEEP must be defined. In that case it uses directly the nanosleep call, casting the uint64max value to time_t which is signed (which is unfortunately not visible in strace), gets negative and this is what the nonsleep manpage says for glibc: EINVAL The value in the tv_nsec field was not in the range 0 to 9 or tv_sec was negative.
[Bug c++/59457] New: name mangling in presence of variadic templates seems wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59457
Bug ID: 59457
Summary: name mangling in presence of variadic templates seems
wrong
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: plasmahh at gmx dot net
With the program below, the output is
1hI1AI2hhIiEEE
hAhhint
hA, hhint
where the hA, hhint part is from my hand-mangled idea how it should
look like. It seems to be only present when variadic templates are there, e.g.
when you replace class... with class, it goes away. Clang btw. seems to mangle
it correctly, that is with J in place of I.
#include iostream
#include typeinfo
#include cxxabi.h
struct A{};
templateclass,class... struct h{};
templateclass struct hh{};
int main() {
typedef hA,hhint hx;
const char* name = typeid(hx).name();
std::cout name \n;
char db[4096];
size_t size = 4096;
int st;
abi::__cxa_demangle(name,db,size,st);
std::cout db \n;
// now what I think the symbol should look like (exchange
abi::__cxa_demangle(1hI1AJ2hhIiEEE,db,size,st);
std::cout db \n;
return 0;
}
[Bug c++/57887] New: nested non-type template parameters not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57887
Bug ID: 57887
Summary: nested non-type template parameters not declared in
this scope
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: plasmahh at gmx dot net
Hi, when trying to compile the following:
struct B
{
templateint N
struct A
{
int X = N;
};
};
I get the error:
g.cxx:6:11: error: 'N' was not declared in this scope
Things work fine when I make X a static const(expr), or when I move A outside
B. The above code however works fine within clang, and I could not find any
wording that would make N suddenly not being available within A, especially
since when you add teh following member function to A (but remove X), it
compiles fine:
void foo( ) { int x = N; }
so it /somehow/ is in scope.
[Bug c++/57888] New: using non-type template parameter in constexpr function for non static data member intializer segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57888
Bug ID: 57888
Summary: using non-type template parameter in constexpr
function for non static data member intializer
segfaults
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: plasmahh at gmx dot net
While trying to find workaronuds for Bug #57887 I tried the following code:
struct B
{
templateint N
struct A
{
constexpr int get_N() { return N; }
// int X = N;
int X = get_N();
void foo( )
{
int x = N;
}
};
};
Which made gcc segfault. Whatever the validity of #57887 is, I don't think it
should segfault here...
[Bug c++/57526] New: use of X before deduction of auto error for seemingly good code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57526
Bug ID: 57526
Summary: use of X before deduction of auto error for seemingly
good code
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: plasmahh at gmx dot net
Hi,
for the following code
templateclass T
struct A
{
void bar( ) { }
void foo( )
{
auto* this_ptr = this;
auto lc = []( )
{
this_ptr-bar();
};
lc();
}
};
int main(int argc, const char *argv[])
{
Aint a;
a.foo();
}
I get gcc 4.8.{0,1} error me out with:
auto.cxx:12:4: error: use of 'AT::foo() [with T =
int]::__lambda0::__this_ptr' before deduction of 'auto'
this_ptr-bar();
which for one was not the case with gcc 4.7. There are two (strange) ways to
make it go away: Either make it be auto isntead of auto* or make A not
being a template. I also could not find anything in the standard that would
disallow this.
[Bug libstdc++/54296] New: using the object in the map to erase element from the map crashes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54296
Bug #: 54296
Summary: using the object in the map to erase element from the
map crashes
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: plasm...@gmx.net
I found a crash in my program, which boils down to the following code. (Note
that this does usually not crash, but will be reported by valgrind with invalid
read after free. Also note that depending no possible internals of the bucket
hashing stuff, the value for i where it crashes might change, so you can use
the random part multiple times to figure out a new one)
#include unordered_map
#include cstddef
#include cstdlib
#include cassert
#include ctime
#include iostream
struct A
{
int x;
};
int main ( )
{
srand(time(0));
std::unordered_mapint,A map;
map.max_load_factor(2.0);
for (size_t i = 0; i 50; ++i)
{
A a;
a.x = i;
map.insert({i,a});
}
// int i = rand() % map.size();
int i = 47;
std::cout i = i \n;
const A a = map[i];
map.erase(a.x);
}
// vim: tabstop=4 shiftwidth=4 noexpandtab ft=cpp
This seems to be due to the while condition in hashtable.h:1526 accessing __k
after the _M_deallocate_node(__p) of line 1517
while (__next_bkt == __bkt this-_M_equals(__k, __code, __next_n));
I think it is better that after the erase of the node, __k should not be
touched anymore as it migh be part of the object being erased.
[Bug libstdc++/54075] [4.7.1] unordered_map insert 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #22 from Dennis Lubert plasmahh at gmx dot net 2012-07-27 19:20:54 UTC --- Am on vacation so I don't have the testcase at hand, but it is the same as likan posted in the original bugreport, minus the reserve. The main difference is that without reserve I see 21 rehashes in gcc 4.6 and 155 rehashes. I have added some code that after each insert tests if the bucket count has changed, I think that should be trivial to add for yourselves without me providing it.
[Bug libstdc++/54075] [4.7.1] unordered_map 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 --- Comment #12 from Dennis Lubert plasmahh at gmx dot net 2012-07-26 12:30:00 UTC --- I can confirm that now the reserve works as I would expect it (causing no further rehashes). However the amount of rehashes done in the testcase is still 155 (needing 4.5s), while gcc 4.6 only needs 21 (needing 1.5s). Monitoring the bucket counts on resizes it seems that gcc 4.8 is now much more fine grained than gcc 4.6. I am unsure if this is expected, deliberate and/or a good idea.
[Bug c++/54076] New: wrong/misleading warning with -Wsign-promo and enums with underlying type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54076
Bug #: 54076
Summary: wrong/misleading warning with -Wsign-promo and enums
with underlying type
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: plasm...@gmx.net
When compiling with -Wsign-promo
#include cstddef
void vs( const char*, long ) { }
void vs( const char*, size_t ) { }
templatesize_t H, size_t L
struct dt
{
enum : size_t { h = H };
enum : size_t { l = L };
};
int main(int /*argc*/, const char * /*argv*/[])
{
typedef dt3,4 d_t;
const char* x = Hello World;
vs(x+d_t::h,d_t::l);
}
I get the warning:
promo.cxx: In function 'int main(int, const char**)':
promo.cxx:16:20: warning: passing 'dt3ul, 4ul::anonymous enum' chooses
'size_t {aka long unsigned int}' over 'long int' [-Wsign-promo]
vs(x+d_t::h,d_t::l);
^
promo.cxx:16:20: warning: in call to 'void vs(const char*, size_t)'
[-Wsign-promo]
From the manpage of gcc it says for -Wsign-promo :
Warn when overload resolution chooses a promotion from unsigned or enumerated
type to a signed type, over a conversion to an unsigned type of the same size.
Previous versions of G++ would try to preserve unsignedness, but the standard
mandates the current behavior.
First of all, intuitively I would not at all expect such a warning, since the
underlying type is set, the enum should behave like that underlying type for
overload resoltion (I would think 4.5-4 applies here).
Secondly the description says that it warns for [...]a promotion from unsigned
or enumerated type to a signed type, over a conversion to an unsigned
type[...] and here it did not chose to promote to a signed type. If the
warning was intentional, then its documentation is misleading.
[Bug libstdc++/54075] [4.7.1] unordered_map 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075 Dennis Lubert plasmahh at gmx dot net changed: What|Removed |Added CC||plasmahh at gmx dot net --- Comment #8 from Dennis Lubert plasmahh at gmx dot net 2012-07-24 10:41:54 UTC --- I just stumbled over this bug while searching for something related to the max load factor (it seems that since 4.7 the hashtable also shrinks when you set the load factor higher, which is at least for me unfortunate). I did just change the testcase to count the number of rehashes (by checking bucket count before and after insert) and found: gcc4.6 without reserve: 21 gcc4.6 with reserve: 1 gcc4.7 without reserve: 155 gcc4.7 with reserve: 160 Then in callgrind I had a look and most time seems to be spend in rehashing. So I would assume that when the 4.7 version gets the number of rehashing down to where it was, then we also get the speed down to where it was. I would say that the reserve behaviour though is definetly broken, as it even increases the amount of rehashings. I personally would just not have the hashtable ever shrink on insert and/or load factor setting, just only ever on explicit rehash() calls...
[Bug c++/54046] New: wrong control reaches end of non-void function for switch case with throw and default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54046
Bug #: 54046
Summary: wrong control reaches end of non-void function for
switch case with throw and default
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: plasm...@gmx.net
Hi, somehow gcc gets confused in its control flow analysis when a default case
in a switch has a throw and break, and a variable with user defined dtor.
struct A
{
~A() { }
};
bool check( int x )
{
A z;
switch( x )
{
case 0:
return false;
default:
throw X;
break;
}
}
When I either remove the break or the variable z, the warning will not issued
anymore.
[Bug c++/54047] New: unused variable warning not for std::string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54047
Bug #: 54047
Summary: unused variable warning not for std::string
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: plasm...@gmx.net
Compiling the following code:
#include string
struct A { };
void foo()
{
A z;
std::string z0;
}
I get a warning for unused variable z, but not for variable z0. It seems that
std::string is somehow magical here, but I can't see how or why.
