[Bug c++/88857] [7/8/9 Regression] ICE in build_value_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88857 --- Comment #7 from Will Benfold --- I think it's not so much class vs struct: I get an ICE iff 'a' is private. Just changing class -> struct stops the ICE, but then it comes back again if you make 'a' private. Similarly, with a class you can make the ICE go away if you make 'a' public.
[Bug c++/88857] [7/8/9 Regression] ICE in build_value_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88857
--- Comment #3 from Will Benfold ---
(In reply to Marek Polacek from comment #2)
> Started with r202612.
Is that just because before r202612, there was no support for 'auto' in a
function declaration?
I see the ICE with every release down to 4.7.1 (the earliest version I have
access to), if I change g to:
template
void g ()
{
f({});
}
[Bug c++/88857] New: ICE in build_value_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88857
Bug ID: 88857
Summary: ICE in build_value_init
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: will at benfold dot com
Target Milestone: ---
ICE on invalid code (g calls f with the wrong number of args).
class Foo
{
int a;
};
void f (const Foo &, int);
void g (auto)
{
f({});
}
$ g++ test.cpp -o test.o
test.cpp: In function ‘void g(auto:1)’:
test.cpp:10:7: internal compiler error: in build_value_init, at cp/init.c:338
f({});
^
0x6ac21f build_value_init(tree_node*, int)
../../gcc/cp/init.c:337
0x5d8379 convert_like_real
../../gcc/cp/call.c:6702
0x5d80a6 convert_like_real
../../gcc/cp/call.c:6844
0x5e0363 initialize_reference(tree_node*, tree_node*, int, int)
../../gcc/cp/call.c:10437
0x6a055d convert_for_initialization(tree_node*, tree_node*, tree_node*, int,
impl_conv_rhs, tree_node*, int, int)
../../gcc/cp/typeck.c:8679
0x6a178c convert_arguments
../../gcc/cp/typeck.c:3818
0x6a178c cp_build_function_call_vec(tree_node*, vec**, int)
../../gcc/cp/typeck.c:3660
0x5e07e3 build_new_function_call(tree_node*, vec**, bool, int)
../../gcc/cp/call.c:4243
0x6c03a1 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/cp/semantics.c:2454
0x67393c cp_parser_postfix_expression
../../gcc/cp/parser.c:6997
0x67426d cp_parser_unary_expression
../../gcc/cp/parser.c:8108
0x675013 cp_parser_cast_expression
../../gcc/cp/parser.c:8786
0x675787 cp_parser_binary_expression
../../gcc/cp/parser.c:8887
0x675e54 cp_parser_assignment_expression
../../gcc/cp/parser.c:9174
0x67904a cp_parser_expression
../../gcc/cp/parser.c:9343
0x67da78 cp_parser_expression_statement
../../gcc/cp/parser.c:10898
0x66a8b9 cp_parser_statement
../../gcc/cp/parser.c:10714
0x66b71d cp_parser_statement_seq_opt
../../gcc/cp/parser.c:11040
0x66b7c7 cp_parser_compound_statement
../../gcc/cp/parser.c:10994
0x67c550 cp_parser_function_body
../../gcc/cp/parser.c:21455
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug c++/56958] Spurious set but not used variable warning in empty pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56958
Will Benfold changed:
What|Removed |Added
CC||will at benfold dot com
--- Comment #5 from Will Benfold ---
Still present in 7.3.0:
$ cat test.cpp
template
int foo (int n)
{
return (( (n) + Is ) + ... + 0);
}
int main (int, char *[])
{
foo<1>(0);
foo<>(0);
return 0;
}
$ g++ -std=c++17 -Wall -Wextra -o test test.cpp
test.cpp: In instantiation of ‘int foo(int) [with int ...Is = {}]’:
test.cpp:10:10: required from here
test.cpp:2:14: warning: parameter ‘n’ set but not used
[-Wunused-but-set-parameter]
int foo (int n)
The warning goes away if the parentheses are removed from (n), or if it's
changed to (n+0).
[Bug c++/84488] New: Incorrect "set but not used" warning for static_cast(double)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84488
Bug ID: 84488
Summary: Incorrect "set but not used" warning for
static_cast(double)
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: will at benfold dot com
Target Milestone: ---
Test case:
int main ()
{
enum Foo {};
double one = 1.0;
return static_cast(one);
}
Output:
$ g++ -Wall -Wextra -o minimal minimal.cpp && (./minimal; echo $?)
minimal.cpp: In function ‘int main()’:
minimal.cpp:4:10: warning: variable ‘one’ set but not used
[-Wunused-but-set-variable]
double one = 1.0;
^
1
Changing the (one) to (+one) is enough to silence the warning.
[Bug c++/64329] New: Crash when returning reference from lambda with deduced type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64329
Bug ID: 64329
Summary: Crash when returning reference from lambda with
deduced type
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: will at benfold dot com
Created attachment 34289
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34289action=edit
Preprocessed source
I believe the program below is valid and correct, but I see heap corruption at
the end of main() (in std::map::~map) when I allow the compiler to deduce
return type of the lambda.
Both the parameters to apply() are still alive when the returned lambda is
invoked, so fn(arg) should safely return a valid const ref to a tuple. If the
return type for the lambda is given explicitly (see comments in code) then
everything is fine, whether it's returning by value or by const ref.
Compiling with -Wall --std=c++11 -O0 -g3; optimisation level seems to make no
difference.
#include functional
#include map
#include string
#include tuple
typedef std::tuplestd::string, std::string, double Result;
typedef std::mapint, Result Argument;
typedef std::functionconst Result (const Argument ) Function;
std::functionResult () apply (const Argument arg, const Function fn)
{
// No trouble with any of these...
// return [fn, arg]() - Result { return fn(arg); };
// return [fn, arg]() - const Result { return fn(arg); };
// return [fn, arg](){ Result r = fn(arg); return r;
};
// But this causes heap corruption
return [fn, arg](){ return fn(arg); };
}
const Result func (const Argument arg)
{
// std::map::at returns a const ref
return arg.at(0);
}
int main (int argc, char *argv[])
{
Argument arg;
arg[0] = Result(, a, 0);
Function f = func;
auto g = apply(arg, f);
g();
return 0;
}
Using built-in specs.
COLLECT_GCC=/software/thirdparty/gcc/4.9.1-0.el6_64/bin/g++
COLLECT_LTO_WRAPPER=/software/thirdparty/gcc/4.9.1-0.el6_64/libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/software/thirdparty/gcc/4.9.1-0.el6_64
--with-system-zlib --enable-shared --enable-threads=posix --enable-laguages=all
--with-ppl --with-cloog --disable-multilib
Thread model: posix
gcc version 4.9.1 (GCC)
[Bug c++/52985] Postincrement not applied after indexing ternary array expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52985
--- Comment #2 from Will Benfold will at benfold dot com 2012-04-18 18:08:16
UTC ---
Another test case; this one doesn't need any headers and also cuts out the
loop. The exit status should always be 1, but in fact it's 0 if no
command-line args are supplied and 1 otherwise.
struct Counter
{
Counter (int val = 0)
: m_val(val)
{}
int operator* () const
{
return m_val;
}
Counter operator++ (int)
{
return Counter(m_val++);
}
int m_val;
};
int main (int argc, char *[])
{
int a[] = {0};
int b[] = {0};
Counter c;
((argc 1) ? a : b)[*c++];
return *c;
}
[Bug middle-end/52985] New: Postincrement not applied after indexing ternary array expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52985
Bug #: 52985
Summary: Postincrement not applied after indexing ternary array
expression
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: w...@benfold.com
Created attachment 27156
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27156
Preprocessed source
[Component=middle-end was a guess, apologies if it's wrong.]
The code below prints an infinite series of zeros, as if the iterator is never
incremented.
The problem goes away if:
* the ternary expression is replaced by either tableA or tableB
* 'flag' is set to true
* the iterator increment is performed in a separate statement
* the vector and iterators are replaced with an array and (int *)
* tableA and tableB are replaced by vectors.
If the result of the array indexing is actually used, e.g. printed to cerr,
then results are the same at -O1 and above, but I see a segfault with -O0.
#include iostream
#include vector
int main (int argc, char *argv[])
{
std::vectorint v(1);
int tableA[] = { 0 };
int tableB[] = { 0 };
bool flag = false;
for (std::vectorint::const_iterator it = v.begin(); it != v.end();)
{
(flag ? tableA : tableB)[*it++];
std::cerr (it - v.begin()) \n;
}
return 0;
}
