[Bug c++/92590] [10 Regression] Cannot expose protected default constructor with "using" keyword in gcc 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92590 --- Comment #5 from Pavel Roskin --- Confirming fix on the original code. Thank you!
[Bug c++/92590] New: Cannot expose protected default constructor with "using" keyword in gcc 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92590
Bug ID: 92590
Summary: Cannot expose protected default constructor with
"using" keyword in gcc 10
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: proski at gnu dot org
Target Milestone: ---
This code fails to compile with the current gcc (commit
d9be9f34fbb018c448dc5a02aaa95d6a6932135c)
class Base {
protected:
Base();
};
class Derived : public Base {
public:
using Base::Base;
};
Derived d;
test.ii:11:9: error: ‘Base::Base()’ is protected within this context
11 | Derived d;
| ^
test.ii:3:5: note: declared protected here
3 | Base();
| ^~~~
The error is emitted for any standard from c++11 to c++2a. No optimization or
other flags are needed.
The same code is compiled without any errors by gcc 9.2.1. Testing on
godbolt.org shows that all other compilers accept it - all recent versions of
clang, msvc, icc.
I don't see any relevant changes mentioned in the GCC 10 release notes
https://gcc.gnu.org/gcc-10/changes.html
An inline implementation of the protected constructor fails too:
class Base {
protected:
Base() {}
};
class Derived : public Base {
public:
using Base::Base;
};
Derived d;
However, the code compiles with the default constructor:
class Base {
protected:
Base() = default;
};
class Derived : public Base {
public:
using Base::Base;
};
Derived d;
[Bug c++/88664] False positive -Waddress-of-packed-member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88664
Pavel Roskin changed:
What|Removed |Added
CC||proski at gnu dot org
--- Comment #2 from Pavel Roskin ---
C is also affected.
int* fun()
{
struct data {
void *ptr;
} __attribute__((packed)) var;
return (int*)(var.ptr);
}
With today's gcc, git master branch:
test.c: In function ‘fun’:
test.c:7:22: warning: taking address of packed member of ‘struct data’ may
result in an unaligned pointer value [-Waddress-of-packed-member]
7 | return (int*)(var.ptr);
| ^
[Bug c++/88528] [7 Regression] ICE with templated operator bool() in gcc 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88528 --- Comment #4 from Pavel Roskin --- The trivial backport of PR c++/85032 fixes both my testcase and the original issue with my code. Please include the fix in gcc 7.5.
[Bug c++/88528] [7 Regression] ICE with templated operator bool() in gcc 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88528 --- Comment #3 from Pavel Roskin --- I ran "git bisect" between gcc 7.1.0 (affected) and gcc 8.1.0 (unaffected). Following commit fixed the issue: https://github.com/gcc-mirror/gcc/commit/e0ccd4807edc919735b4d86590b5a9def529f91c 2018-04-11 Marek Polacek PR c++/85032 * constexpr.c (potential_constant_expression_1): Consider conversions from classes to literal types potentially constant. The original issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85032 It's a short fix that also adds a similar testcase. The fix can be applied to gcc-7-branch. Let's see if it fixes my testcase and also my "real world" issue.
[Bug c++/88528] ICE with templated operator bool() in gcc 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88528 Pavel Roskin changed: What|Removed |Added Summary|Regression in gcc 7.4 |ICE with templated operator ||bool() in gcc 7 --- Comment #1 from Pavel Roskin --- I turns out I was wrong about the previous version of gcc. I've just tested gcc 7.1, 7.2 and 7.3 compiled from the source. They all are affected.
[Bug c++/88528] New: Regression in gcc 7.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88528
Bug ID: 88528
Summary: Regression in gcc 7.4
Product: gcc
Version: 7.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: proski at gnu dot org
Target Milestone: ---
gcc 7.4.0 fails to compile some code that could be compiled with earlier
version of gcc 7.x. I don't see that issue with gcc 4.9.4, 5.5.0, 6.5.0 and
8.1.0. The issue still exists with the current gcc-7-branch (git revision
c51441f7f92fe9f4a0a452c1f8d283751ad463c5, timestamp 20181217).
The code:
template
struct A
{
const bool is_valid;
operator bool() const
{
return is_valid;
}
};
template
bool check_a()
{
const A<0> a {};
const bool a_valid {a};
return a_valid;
}
The output with the current gcc from the gcc-7-branch:
$ /opt/gcc/bin/gcc -std=c++14 -c test.cpp
test.cpp: In function ‘bool check_a()’:
test.cpp:15:24: internal compiler error: unexpected expression ‘(bool)a’ of
kind implicit_conv_expr
const bool a_valid {a};
^
0x6e2a5d cxx_eval_constant_expression
/home/roskinp/src/gcc/gcc/cp/constexpr.c:4697
0x6e4454 cxx_eval_outermost_constant_expr
/home/roskinp/src/gcc/gcc/cp/constexpr.c:4755
0x6e6391 maybe_constant_init(tree_node*, tree_node*)
/home/roskinp/src/gcc/gcc/cp/constexpr.c:5082
0x603c2f store_init_value(tree_node*, tree_node*, vec**, int)
/home/roskinp/src/gcc/gcc/cp/typeck2.c:832
0x5c105d check_initializer
/home/roskinp/src/gcc/gcc/cp/decl.c:6377
0x5c5691 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/home/roskinp/src/gcc/gcc/cp/decl.c:6953
0x654d7f cp_parser_init_declarator
/home/roskinp/src/gcc/gcc/cp/parser.c:19468
0x6555cd cp_parser_simple_declaration
/home/roskinp/src/gcc/gcc/cp/parser.c:12844
0x656295 cp_parser_block_declaration
/home/roskinp/src/gcc/gcc/cp/parser.c:12669
0x656bb9 cp_parser_declaration_statement
/home/roskinp/src/gcc/gcc/cp/parser.c:12279
0x638247 cp_parser_statement
/home/roskinp/src/gcc/gcc/cp/parser.c:10754
0x63900d cp_parser_statement_seq_opt
/home/roskinp/src/gcc/gcc/cp/parser.c:11098
0x6390b7 cp_parser_compound_statement
/home/roskinp/src/gcc/gcc/cp/parser.c:11052
0x649f00 cp_parser_function_body
/home/roskinp/src/gcc/gcc/cp/parser.c:21521
0x649f00 cp_parser_ctor_initializer_opt_and_function_body
/home/roskinp/src/gcc/gcc/cp/parser.c:21559
0x6508f0 cp_parser_function_definition_after_declarator
/home/roskinp/src/gcc/gcc/cp/parser.c:26353
0x6551dd cp_parser_function_definition_from_specifiers_and_declarator
/home/roskinp/src/gcc/gcc/cp/parser.c:26265
0x6551dd cp_parser_init_declarator
/home/roskinp/src/gcc/gcc/cp/parser.c:19247
0x63430a cp_parser_single_declaration
/home/roskinp/src/gcc/gcc/cp/parser.c:26811
0x6501ec cp_parser_template_declaration_after_parameters
/home/roskinp/src/gcc/gcc/cp/parser.c:26415
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++/85569] [8 Regression] is_invocable(F, decltype(objs)...) fails with "not supported by dump_expr#" unless via indirection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85569 Pavel Roskin changed: What|Removed |Added CC||proski at gnu dot org --- Comment #11 from Pavel Roskin --- I confirm the issue described in Bug 87897 has been fixed for my case, a project that used Boost.Spirit. The project compiles, the unit tests pass.
[Bug c++/87897] [9 Regression] ICE in maybe_constant_value, at cp/constexpr.c:5255 since r265788
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87897 Pavel Roskin changed: What|Removed |Added CC||proski at gnu dot org --- Comment #3 from Pavel Roskin --- Confirmed with the current revision. Compiling a program using Boost.Spirit, Boost 1.61. /usr/local/include/boost/spirit/home/support/argument.hpp:202:5: internal compiler error: in maybe_constant_value, at cp/constexpr.c:5260 202 | BOOST_PP_REPEAT_FROM_TO( | ^~~ 0x5c9842 maybe_constant_value(tree_node*, tree_node*) /home/roskinp/src/gcc/gcc/cp/constexpr.c:5260 0xa03aec store_init_value(tree_node*, tree_node*, vec**, int) /home/roskinp/src/gcc/gcc/cp/typeck2.c:825 0x897b62 check_initializer /home/roskinp/src/gcc/gcc/cp/decl.c:6486
[Bug c++/86465] C++17 triggers: ‘’ may be used uninitialized in this function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86465 --- Comment #3 from Pavel Roskin --- Created attachment 44770 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44770=edit Futher reduced example I was able to reduce the example to just 55 lines, removing almost all the code that came from the standard headers. The code complies with C++ standards all the way back to C++03. As I suspected, the implementation of std::optional in libstdc++ uses a trick to avoid initializing the payload when the optional value default initialized, and that code turns out to be essential for reproducing the issue. Try uncommenting _empty_char, and the warning goes away.
[Bug c++/86465] C++17 triggers: ‘’ may be used uninitialized in this function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86465 --- Comment #2 from Pavel Roskin --- Created attachment 44761 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44761=edit Heavily simplified example, g++-5 compatible I'm attaching a dumbed down version of the previous example, which compiles with gcc 5.5.0 and newer. gcc 5.5.0 and gcc 6.4.0 don't produce any warning. gcc 7.3.0, 8.1.0 and the today's gcc from the git master branch all produce the warning. That suggests that the issue is indeed related to the one described in bug #86485. The implementation of optional in libstdc++ 7 doesn't trigger a warning, it's the changes in libstdc++ 8 that started triggering it. However, gcc 7 appears to have the same compiler issue.
[Bug c++/81513] __has_cpp_attribute returns non-zero in C++03 mode, but attributes don't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81513 Pavel Roskin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Pavel Roskin --- After reading the discussion, it became clear to me that it's a corner case that is not really worth spending more time on. I'm marking the issue as resolved.
[Bug c++/86465] New: C++17 triggers: ‘’ may be used uninitialized in this function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86465
Bug ID: 86465
Summary: C++17 triggers: ‘’ may be used
uninitialized in this function
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: proski at gnu dot org
Target Milestone: ---
Created attachment 44378
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44378=edit
Preprocessed test case
The attached file triggers a warning:
$ g++ -std=c++17 -Wall -O2 -c optional.cpp -save-temps
optional.cpp: In member function ‘virtual std::optional
Child::get_hairy_value()’:
optional.cpp:20:25: warning: ‘’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
return {};
^
The issue is observed with gcc 8 as packaged by Fedora
(gcc-8.1.1-1.fc28.x86_64) and with the current gcc trunk (commit
c85ec25b97e485c6f3493fc42c473db2a11ac9ea). gcc 7.3.0 doesn't exhibit the bug.
Interestingly, the preprocessed file generated by gcc 7.3.0 doesn't trigger the
warning in gcc 8 or 9.
Also, the warning goes away if experimental/optional is used, so C++17 is
required to reproduce it.
Optimization (at least -O1) is required to trigger the warning.
[Bug c++/85092] [8 Regression] ICE under -std=gnu++1z in build_over_call under, at cp/call.c:8149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85092 --- Comment #7 from Pavel Roskin --- I confirm that the issue has been fixed in the project I'm working on. Thank you!
[Bug c++/85092] [8 Regression] ICE under -std=gnu++1z in build_over_call under, at cp/call.c:8149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85092
Pavel Roskin changed:
What|Removed |Added
CC||proski at gnu dot org
--- Comment #1 from Pavel Roskin ---
Possibly even simpler case:
#include
struct IntSet {
IntSet(int value) : value_{std::set{value}} {}
std::set value_;
};
I'm testing gcc-8 on a large project that compiled with an older gcc-8 snapshot
and this bug is triggered on many files. The workaround is to use () rather
than {} for constructor calls.
[Bug c++/85101] C++17 ICE in build_over_call, at cp/call.c:8149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85101 --- Comment #1 from Pavel Roskin --- Created attachment 43779 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43779=edit Preprocessed source
[Bug c++/85101] New: C++17 ICE in build_over_call, at cp/call.c:8149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85101 Bug ID: 85101 Summary: C++17 ICE in build_over_call, at cp/call.c:8149 Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: proski at gnu dot org Target Milestone: --- Today's gcc source from git. C++17 and C++2a are affected, C++14 is not. I was able to compile that code with the latest (at the time) gcc snapshot about a month ago, so it's probably a recent regression. gcc 7.3.1 can compile the code. Fedora 27 x86_64, all up-to-date, gcc compiled from git and installed to /opt/gcc $ /opt/gcc/bin/g++ -v Using built-in specs. COLLECT_GCC=/opt/gcc/bin/g++ COLLECT_LTO_WRAPPER=/opt/gcc/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/roskinp/src/gcc/configure --enable-languages=c++ --disable-multilib --prefix=/opt/gcc : (reconfigured) /home/roskinp/src/gcc/configure --enable-languages=c++ --disable-multilib --prefix=/opt/gcc : (reconfigured) /home/roskinp/src/gcc/configure --enable-languages=c++ --disable-multilib --prefix=/opt/gcc : (reconfigured) /home/roskinp/src/gcc/configure --enable-languages=c++ --disable-multilib --prefix=/opt/gcc : (reconfigured) /home/roskinp/src/gcc/configure --enable-languages=c++ --disable-multilib --prefix=/opt/gcc : (reconfigured) /home/roskinp/src/gcc/configure --enable-languages=c++ --disable-multilib --prefix=/opt/gcc Thread model: posix gcc version 8.0.1 20180327 (experimental) (GCC) $ /opt/gcc/bin/g++ -c Chrono.ii -std=c++17 /home/roskinp/chrono/Source/Utility/Chrono.cpp: In function ‘std::__cxx11::string VG::Utility::to_string(VG::Utility::Milliseconds)’: /home/roskinp/chrono/Source/Utility/Chrono.cpp:63:73: internal compiler error: in build_over_call, at cp/call.c:8149 "00" + to_string(milliseconds.count() % milliseconds::period::den)}; ^ 0x5a84d1 build_over_call /home/roskinp/src/gcc/gcc/cp/call.c:8143 0x7fa263 build_new_method_call_1 /home/roskinp/src/gcc/gcc/cp/call.c:9363 0x7fa263 build_new_method_call(tree_node*, tree_node*, vec<tree_node*, va_gc, vl_embed>**, tree_node*, int, tree_node**, int) /home/roskinp/src/gcc/gcc/cp/call.c:9438 0x7fadc3 build_special_member_call(tree_node*, tree_node*, vec<tree_node*, va_gc, vl_embed>**, tree_node*, int, int) /home/roskinp/src/gcc/gcc/cp/call.c:8966 0x8a99e3 expand_default_init /home/roskinp/src/gcc/gcc/cp/init.c:1887 0x8a99e3 expand_aggr_init_1 /home/roskinp/src/gcc/gcc/cp/init.c:2002 0x8aa349 build_aggr_init(tree_node*, tree_node*, int, int) /home/roskinp/src/gcc/gcc/cp/init.c:1742 0x85eebf build_aggr_init_full_exprs /home/roskinp/src/gcc/gcc/cp/decl.c:6273 0x85eebf check_initializer /home/roskinp/src/gcc/gcc/cp/decl.c:6422 0x876cbc cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int) /home/roskinp/src/gcc/gcc/cp/decl.c:7127 0x91331b cp_parser_init_declarator /home/roskinp/src/gcc/gcc/cp/parser.c:19741 0x91a788 cp_parser_simple_declaration /home/roskinp/src/gcc/gcc/cp/parser.c:13059 0x91b598 cp_parser_block_declaration /home/roskinp/src/gcc/gcc/cp/parser.c:12884 0x91bfc9 cp_parser_declaration_statement /home/roskinp/src/gcc/gcc/cp/parser.c:12478 0x8fa533 cp_parser_statement /home/roskinp/src/gcc/gcc/cp/parser.c:10927 0x8fb4a0 cp_parser_statement_seq_opt /home/roskinp/src/gcc/gcc/cp/parser.c:11276 0x8fb577 cp_parser_compound_statement /home/roskinp/src/gcc/gcc/cp/parser.c:11230 0x91c615 cp_parser_implicitly_scoped_statement /home/roskinp/src/gcc/gcc/cp/parser.c:12533 0x8fae5a cp_parser_selection_statement /home/roskinp/src/gcc/gcc/cp/parser.c:11416 0x8fae5a cp_parser_statement /home/roskinp/src/gcc/gcc/cp/parser.c:10818
[Bug c++/81513] __has_cpp_attribute returns non-zero in C++03 mode, but attributes don't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81513 --- Comment #2 from Pavel Roskin --- __has_cpp_attribute is not supposed to check if the functionality is available somehow using some other approaches and keywords. It is supposed to check if the functionality is available as an attribute. Even is there is some alternative notation for C++03, I expect the attribute name to be the same. If __has_cpp_attribute(maybe_unused) is set to a non-zero value, I expect to use "maybe_unused", not "unused".
[Bug c++/81513] New: __has_cpp_attribute returns non-zero in C++03 mode, but attributes don't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81513
Bug ID: 81513
Summary: __has_cpp_attribute returns non-zero in C++03 mode,
but attributes don't work
Product: gcc
Version: 7.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: proski at gnu dot org
Target Milestone: ---
Following compiles with "g++ -Wall -std=c++03 test.cpp -o test" and outputs
"200809 201603 199711"
#include
int main()
{
std::cout << __has_cpp_attribute(noreturn) << ' ' <<
__has_cpp_attribute(maybe_unused) << ' ' << __cplusplus << '\n';
}
[[maybe_unused]] doesn't work in C++03 mode in g++. It does work in C++11 mode,
despite it being a C++17 feature. In C++11 mode, __cplusplus would be less than
__has_cpp_attribute(maybe_unused), yet [[maybe_unused]] would work.
With clang-4.0 in C++03 mode, the output is "0 0 199711". I believe GCC should
do the same. If attributes are not supported at all, __has_cpp_attribute()
should return 0.
I want to do following without special casing GCC or older standards:
#if defined(__has_cpp_attribute) && __has_cpp_attribute(maybe_unused)
#define __maybe_unused [[maybe_unused]]
#endif
[Bug tree-optimization/53239] [4.7 Regression] VRP vs named value return opt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53239 --- Comment #10 from proski at gnu dot org 2012-05-07 12:35:40 UTC --- I applied the patch to gcc 4.7.0 and tested it with my example and GNU Lilypond. Both are fixed. Thanks!
[Bug middle-end/53239] [4.7 Regression] VRP vs named value return opt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53239 --- Comment #6 from proski at gnu dot org 2012-05-07 02:50:04 UTC --- Created attachment 27330 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27330 Self-contained test case Run the compile script. The output would be: return = 2/1 return = 1/1 It means that the output depends on whether -fno-tree-vrp is used.
[Bug c++/53239] New: [4.7 Regression] -ftree-vrp breaks min()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53239 Bug #: 53239 Summary: [4.7 Regression] -ftree-vrp breaks min() Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: pro...@gnu.org GNU Lilypond is miscompiled on Fedora 17. It manifests as a failure to process any non-trivial input. Both i386 and x86_64 are affected. $ gcc --version gcc (GCC) 4.7.0 20120502 (Red Hat 4.7.0-3) It turns out that adding -fno-tree-vrp fixes the problem. A call to min() is affected. Comparing the assembly output without and with -fno-tree-vrp shows that the generated assembly code wrongly eliminates a conditional register move after calling the compare (_ZN6Moment7compareERKS_S1_) function. The attached file was generated on i386. Credit for finding a problem in the assembly goes to David Kastrup.
[Bug c++/53239] [4.7 Regression] -ftree-vrp breaks min()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53239 --- Comment #1 from proski at gnu dot org 2012-05-04 21:43:11 UTC --- Created attachment 27310 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27310 Example (made on i386) This line is miscompiled: next = min (next, it-pending_moment ()); The result of comparison in min() is unused unless the -fno-tree-vrp option is used.
