[Bug c/96009] New: missed optimization with floating point operations and integer literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96009
Bug ID: 96009
Summary: missed optimization with floating point operations and
integer literals
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sshannin at gmail dot com
Target Milestone: ---
Consider the two variants below:
double foo(char i) {
double f = i * 100;
return f / 100;
}
double bar(char i) {
return i;
}
Compiled under -Ofast with gcc 9.1.0, we get the following:
foo:
movsbl %dil, %edi
pxor %xmm0, %xmm0
imull $100, %edi, %edi
cvtsi2sdl %edi, %xmm0
mulsd .LC0(%rip), %xmm0
ret
bar:
movsbl %dil, %edi
pxor %xmm0, %xmm0
cvtsi2sdl %edi, %xmm0
ret
.LC0:
.long 1202590843
.long 1065646817
But I think foo should be to be simplified to the same as bar, right?
This seems somewhat similar to PR91739 and PR84997, although not quite the same
as far as I can discern.
(Also, separately, aren't the first two instructions of bar unnecessary? Can't
we just cvtsi2sdl and ret?)
seth@dev4:$ /toolchain14/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/toolchain14/bin/g++
COLLECT_LTO_WRAPPER=/toolchain14/libexec/gcc/x86_64-pc-linux-gnu/9.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc_9_1_0/configure --prefix=/toolchain14
--enable-languages=c,c++,fortran --enable-lto --disable-plugin
--program-suffix=-9.1.0 --disable-multi-lib
Thread model: posix
gcc version 9.1.0 (GCC)
[Bug tree-optimization/96034] New: missed optimization with extended registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96034
Bug ID: 96034
Summary: missed optimization with extended registers
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sshannin at gmail dot com
Target Milestone: ---
Noticed in example for PR96009.
Consider this simple function:
double bar(char i) {
return i;
}
Compiled with -O3, we get:
movsbl %dil, %edi
pxor %xmm0, %xmm0
cvtsi2sdl %edi, %xmm0
ret
But aren't the movsb and pxor unnecessary? I think we should be able to just
cvtsi2sd and then ret.
Interestingly, compiling with -OS instead of -O3 manages to remove the pxor:
movsbl %dil, %edi
cvtsi2sdl %edi, %xmm0
ret
Which is a one instruction better (unless -O3 is trying to keep the pxor for
alignment?), but even here I think the movsb could still go too.
Closest thing I find is PR48701, in that it also doesn't seem to understand
which registers are the same.
seth@fr-dev3:$ /toolchain14/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/toolchain14/bin/gcc
COLLECT_LTO_WRAPPER=/toolchain14/libexec/gcc/x86_64-pc-linux-gnu/9.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc_9_1_0/configure --prefix=/toolchain14
--enable-languages=c,c++,fortran --enable-lto --disable-plugin
--program-suffix=-9.1.0 --disable-multilib
Thread model: posix
gcc version 9.1.0 (GCC)
[Bug tree-optimization/96034] missed optimization with extended registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96034 sshannin at gmail dot com changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from sshannin at gmail dot com --- Ah, yes, you're correct on both counts. For future reference if anybody comes across this, I can confirm on both a sandy bridge and skylake that the pxor does actually make it faster. I should've checked first; I got too excited by "fewer instructions = better". As far as the ABI, I'm certainly not an expert and if you claim that the upper bits are undefined I certainly defer to you. As you intuited, I was checking against llvm output (and it does omit the sign extend). Sorry for the bother and thanks for such a helpful response.
[Bug libstdc++/96269] New: optional comparison with nullopt fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96269
Bug ID: 96269
Summary: optional comparison with nullopt fails
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: sshannin at gmail dot com
Target Milestone: ---
Consider the following:
seth@dev6:~/tmp$ cat opt.cpp
#include
struct X {
template
bool operator==(const T&) {
return false;
}
};
bool foo() {
std::optional x;
#ifndef FLIP
return x == std::nullopt;
#else
return std::nullopt == x;
#endif
}
With gcc 9.1.0, this compiles regardless of whether or not FLIP is defined.
With gcc 10.1.0 however, the FLIP variant does not compile.
seth@dev6:~/tmp$ /toolchain15/bin/g++ -c -o opt.o opt.cpp --std=c++20
seth@dev6:~/tmp$ /toolchain15/bin/g++ -c -o opt.o opt.cpp --std=c++20 -DFLIP
In file included from opt.cpp:1:
/toolchain15/include/c++/10.1.0/optional: In instantiation of ‘constexpr
std::__optional_relop_t() == declval<_Tp>()))>
std::operator==(const _Up&, const std::optional<_Tp>&) [with _Tp = X; _Up =
std::nullopt_t; std::__optional_relop_t() ==
declval<_Tp>()))> = bool; decltype ((declval<_Up>() == declval<_Tp>())) =
bool]’
...etc...
It's a tad hard for me to keep track of which overloads are supposed to
exist/how they're supposed to resolve and I think introduction of <=> was
expected to change behavior here a bit, so I'm not actually sure if this is
supposed to compile still.
seth@dev6:~/tmp$ /toolchain15/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/toolchain15/bin/g++
COLLECT_LTO_WRAPPER=/toolchain15/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc_10_1_0/configure --prefix=/toolchain15
--enable-languages=c,c++,fortran --enable-lto --disable-plugin
--program-suffix=-10.1.0 --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.1.0 (GCC)
[Bug libstdc++/96269] optional comparison with nullopt fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96269
--- Comment #2 from sshannin at gmail dot com ---
(In reply to Jonathan Wakely from comment #1)
> Your operator== should be const-qualified.
I don't disagree. I can also fully remove the operator== and it compiles as
well (why should the presence of the non-const operator== cause the comparison
with nullopt in one direction to instantiate it).
But yeah, I lost something in my reduction in there. I think the main point is
that one direction of the comparison instantiates the templated operator== and
the other doesn't.
Consider this version of X instead, which avoids the const issues:
struct X {
int y;
template
bool operator==(const T&o) const {
return y == o.summary();
}
};
We again end up instantiating X's operator== (even though we wouldn't call it)
in the FLIP case (and thus fail to compile), but in the non-flip case
everything seems fine.
[Bug c++/58948] New: c++0x support for enums in namespaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58948 Bug ID: 58948 Summary: c++0x support for enums in namespaces Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: sshannin at gmail dot com Host: gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) Target: x86_64-linux-gnu Build: Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bug s --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker Created attachment 31128 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31128&action=edit Preprocessed source compiled with: g++ -std=c++0x sample.cpp Error message: sample.cpp:3:1: error: ‘G’ in ‘enum G::A’ does not name a type Compiles without complaint if 'std=c++0x' argument is omitted.
[Bug c++/58948] c++0x support for enums in namespaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58948 --- Comment #2 from sshannin at gmail dot com --- Ahh, good call. I forgot that it would parse like that. I wonder if there's any way to declare it such that the namespaces/types are unambiguous that will parse correctly in both the c++11 and c++03 modes.
[Bug c++/85761] New: ICE on invalid in rtl with uncaptured constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85761
Bug ID: 85761
Summary: ICE on invalid in rtl with uncaptured constexpr
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sshannin at gmail dot com
Target Milestone: ---
Reduced test case shown below. Easily resolved by fixing the code (capturing
COUNT or just moving its decl into the lambda), so not that interesting, but
still an ICE.
Compiled fine with 7.1.0.
Stacktrace looks similar to pr85594, but a tad different and doesn't involve
OpenMP.
seth@dev9:~$ cat tmp.cpp
template
void out(const T& value);
struct foo {
void bar();
};
void foo::bar()
{
constexpr int COUNT = 1;
auto run = []() {
out(COUNT);
};
run();
}
seth@dev9:~$ /build/toolchain13/bin/g++ tmp.cpp
during RTL pass: expand
tmp.cpp: In lambda function:
tmp.cpp:12:13: internal compiler error: in make_decl_rtl, at varasm.c:1322
out(COUNT);
^
0x429b54 make_decl_rtl(tree_node*)
../../gcc_8_1_0/gcc/varasm.c:1318
0x715721 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc_8_1_0/gcc/expr.c:9962
0x71e3ee expand_expr
../../gcc_8_1_0/gcc/expr.h:280
0x71e3ee expand_expr_addr_expr_1
../../gcc_8_1_0/gcc/expr.c:7943
0x714135 expand_expr_addr_expr
../../gcc_8_1_0/gcc/expr.c:8064
0x714135 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc_8_1_0/gcc/expr.c:11236
0x71ea7b store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
../../gcc_8_1_0/gcc/expr.c:5635
0x71fd84 expand_assignment(tree_node*, tree_node*, bool)
../../gcc_8_1_0/gcc/expr.c:5403
0x623eb0 expand_gimple_stmt_1
../../gcc_8_1_0/gcc/cfgexpand.c:3692
0x623eb0 expand_gimple_stmt
../../gcc_8_1_0/gcc/cfgexpand.c:3790
0x6255ff expand_gimple_basic_block
../../gcc_8_1_0/gcc/cfgexpand.c:5819
0x62a996 execute
../../gcc_8_1_0/gcc/cfgexpand.c:6425
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.
seth@dev9:~$ /build/toolchain13/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/build/toolchain13/bin/g++
COLLECT_LTO_WRAPPER=/build/toolchain13/libexec/gcc/x86_64-pc-linux-gnu/8.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc_8_1_0/configure --prefix=/build/toolchain13
--enable-languages=c,c++ --enable-lto --disable-plugin --program-suffix=-8.1.0
--disable-multilib --disable-shared
Thread model: posix
gcc version 8.1.0 (GCC)
[Bug libstdc++/85792] New: #include triggers Wctor-dtor-privcay
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85792 Bug ID: 85792 Summary: #include triggers Wctor-dtor-privcay Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: sshannin at gmail dot com Target Milestone: --- seth@dev9:~$ cat tmp.cpp #include seth@dev9:~$ /build/toolchain13/bin/g++ tmp.cpp -Wctor-dtor-privacy -std=c++17 -c In file included from tmp.cpp:1: /build/toolchain13/include/c++/8.1.0/variant:463:7: note: ‘std::__detail::__variant::_Copy_ctor_base<, _Types>::_Copy_ctor_base(const std::__detail::__variant::_Copy_ctor_base<, _Types>&)’ is public, but requires an existing ‘struct std::__detail::__variant::_Copy_ctor_base<, _Types>’ object _Copy_ctor_base(const _Copy_ctor_base& __rhs) ^~~ /build/toolchain13/include/c++/8.1.0/variant:497:7: note: ‘std::__detail::__variant::_Move_ctor_base<, _Types>::_Move_ctor_base(std::__detail::__variant::_Move_ctor_base<, _Types>&&)’ is public, but requires an existing ‘struct std::__detail::__variant::_Move_ctor_base<, _Types>’ object _Move_ctor_base(_Move_ctor_base&& __rhs) ^~~ /build/toolchain13/include/c++/8.1.0/variant:562:7: note: ‘std::__detail::__variant::_Copy_assign_base<, _Types>::_Copy_assign_base(const std::__detail::__variant::_Copy_assign_base<, _Types>&)’ is public, but requires an existing ‘struct std::__detail::__variant::_Copy_assign_base<, _Types>’ object _Copy_assign_base(const _Copy_assign_base&) = default; ^ /build/toolchain13/include/c++/8.1.0/variant:631:7: note: ‘std::__detail::__variant::_Move_assign_base<, _Types>::_Move_assign_base(const std::__detail::__variant::_Move_assign_base<, _Types>&)’ is public, but requires an existing ‘struct std::__detail::__variant::_Move_assign_base<, _Types>’ object _Move_assign_base(const _Move_assign_base&) = default; ^ seth@dev9:~$ /build/toolchain13/bin/g++ -v Using built-in specs. COLLECT_GCC=/build/toolchain13/bin/g++ COLLECT_LTO_WRAPPER=/build/toolchain13/libexec/gcc/x86_64-pc-linux-gnu/8.1.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc_8_1_0/configure --prefix=/build/toolchain13 --enable-languages=c,c++ --enable-lto --disable-plugin --program-suffix=-8.1.0 --disable-multilib --disable-shared Thread model: posix gcc version 8.1.0 (GCC) seth@dev9:~$
[Bug other/86095] New: stale documentation for -Wunsafe-loop-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86095 Bug ID: 86095 Summary: stale documentation for -Wunsafe-loop-optimizations Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: sshannin at gmail dot com Target Milestone: --- For the man page shipped with 8.1.0, the description of -Wunsafe-loop-optimizations still references the -funsafe-loop-optimizations option, however that optimization is neither described nor referenced anywhere else in the documentation. I dug up https://gcc.gnu.org/ml/gcc-patches/2016-07/threads.html#00956, which seems to indicate the option was removed. It does not appear however that the documentation for the warning was updated to reflect this (nor was Richard's suggested alias added, which may have also cleared up confusion).
[Bug sanitizer/90865] New: ubsan causes coverage branch errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90865
Bug ID: 90865
Summary: ubsan causes coverage branch errors
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: sshannin at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Code compiled with gcov and ubsan produces bad coverage results. It seems that
ubsan inserts some branches which are visible to gcov as part of its
instrumentation.
In the following snippet below you can observe that gcov has flagged "int res =
5 / argc;" as containing uncovered branches (checking for division by 0?).
seth@dev11:~/covsan$ ls
covsan.cpp
seth@dev11:~/covsan$ cat covsan.cpp
int main(int argc, char **argv) {
int res = 5 / argc;
return res;
}
seth@dev11:~/covsan$ /toolchain/14/bin/g++ covsan.cpp -o covsan --coverage
-fsanitize=undefined -static-libubsan
seth@dev11:~/covsan$ ./covsan
seth@dev11:~/covsan$ /toolchain/14/bin/gcov covsan
File 'covsan.cpp'
Lines executed:100.00% of 3
Creating 'covsan.cpp.gcov'
seth@dev11:~/covsan$ cat covsan.cpp.gcov
-:0:Source:covsan.cpp
-:0:Graph:covsan.gcno
-:0:Data:covsan.gcda
-:0:Runs:1
1:1:int main(int argc, char **argv) {
1*:2:int res = 5 / argc;
1:3:return res;
-:4:}
seth@dev11:~/covsan$ /toolchain/14/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/toolchain/14/bin/g++
COLLECT_LTO_WRAPPER=/toolchain/14/libexec/gcc/x86_64-pc-linux-gnu/9.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc_9_1_0/configure --prefix=/toolchain/14
--enable-languages=c,c++,fortran --enable-lto --disable-plugin
--program-suffix=-9.1.0 --disable-multilib
Thread model: posix
gcc version 9.1.0 (GCC)
seth@dev11:~/covsan$
[Bug sanitizer/90865] ubsan causes coverage branch errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90865 --- Comment #2 from sshannin at gmail dot com --- Thanks for such a quick reply. I just wanted to make sure I'm understanding you correctly about what you mean when you say this is expected. Are you indicating that it's desirable that the ubsan instrumentation is visible to gcov and thus shows up as coverage gaps? That seems to be what you're indicating, but seems surprising to me, as it roughly makes the gcov output useless. Certainly I'm not trying to get coverage about code that the compiler inserted as an implementation detail of checking division. Is there way to mark the ubsan-generated code as such so that gcov ignores it instead of marking every division operation as having an uncovered branch?
[Bug sanitizer/90865] ubsan causes coverage branch errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90865 --- Comment #6 from sshannin at gmail dot com --- Since we all agree that the current behavior is undesirable and since Jakub proposes a possible solution, would it be reasonable to reopen this? For large (multi-hour) test suites, it would be meaningfully helpful to be able to run a single time using a binary instrumented for both sanitizers and coverage rather than having to run through the tests multiple times with different binaries because ubsan makes gcov's output useless.
[Bug sanitizer/90865] ubsan causes coverage branch errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90865 sshannin at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #8 from sshannin at gmail dot com --- Thanks. Changing back to UNCONFIRMED.
[Bug c++/69600] New: Incorrect use of copy-assignment instead of move assignment from function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69600 Bug ID: 69600 Summary: Incorrect use of copy-assignment instead of move assignment from function Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: sshannin at gmail dot com Target Milestone: --- Created attachment 37541 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37541&action=edit preprocessed source In some cases, it looks like the copy assignment operator is being used to store return values from a function instead of the move assignment operator. This causes the compilation to fail because it tries to use the copy-assignment operator of some classes which may be movable only (unique_ptr). Note that changing data_t to be either 'std::map' or 'std::map' allows the code to compile. Let me know if I can provide any more details that would be helpful. gcc-5.3.0 x86_64-unknown-linux-gnu
[Bug c++/69600] Incorrect use of copy-assignment instead of move assignment from function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69600 --- Comment #1 from sshannin at gmail dot com --- Created attachment 37542 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37542&action=edit Error output Error output from compiler. Note it also fails to indicate which line the problematic instantiation is on.
[Bug c++/69600] Incorrect use of copy-assignment instead of move assignment from function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69600 --- Comment #3 from sshannin at gmail dot com --- (In reply to Jonathan Wakely from comment #2) > The value_type of your map is pair an you > can't move the first part of that pair, and you can't copy the second part > of that pair, so you can't move or copy it. I'm not sure exactly what you mean/what the value_type typedef inside the map has to do with this. Note that std::map> does seem to work here (where presumably value_type is pair>). Also, I just confirmed this did previously work on gcc-4.8.2
[Bug c++/66999] Missing comma in lambda capture causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66999
sshannin at gmail dot com changed:
What|Removed |Added
CC||sshannin at gmail dot com
--- Comment #1 from sshannin at gmail dot com ---
Confirmed still present in gcc 5.3.0.
I got a smaller example with a slightly different flavor if it helps:
---
#include
struct foo {
void bar() {
std::function f = std::function(
[&this]() {
int x;
});
}
};
[Bug libstdc++/69600] [5 Regression] Incorrect use of copy-assignment instead of move assignment from function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69600 --- Comment #6 from sshannin at gmail dot com --- Thanks for the update : )
[Bug c++/69600] Incorrect use of copy-assignment instead of move assignment from function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69600 --- Comment #4 from sshannin at gmail dot com --- FWIW, this seems to be fixed on trunk. Still fails for at least 6.2, 5.4, and 4.9.4, but does compile with 7/trunk and 4.8.5 https://godbolt.org/g/hx9q4S
[Bug c++/60750] New: double free after std::move on string inside throw when compiled with optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60750 Bug ID: 60750 Summary: double free after std::move on string inside throw when compiled with optimization Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: sshannin at gmail dot com Host: Linux hostname 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Target: x86_64-unknown-linux-gnu Build: ../gcc-4.8.2/configure --disable-multilib --enable-languages=c++ --program-suffix=-4.8.2 Created attachment 32535 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32535&action=edit Source If I compile the attached source without optimization and run it (g++-4.8.2 --std=c++11 -o sample sample.cpp; ./sample), it behaves as expected. If I compile with even O1 (g++-4.8.2 --std=c++11 -O1 -o sample sample.cpp), I get the glibc double free warning dump. I considered this source small enough (with standard headers) to not require the preprocessed to be attached. Let me know if that, or any other info, is desired as well
[Bug c++/60750] double free after std::move on string inside throw when compiled with optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60750 --- Comment #3 from sshannin at gmail dot com --- As a note that may help pin things down, removing either call to std::move() or removing the concatenation with err_prefix done in call to the std::runtime_error constructor seems to resolve this (or mask it).
[Bug c++/59760] New: use_thunk internal error on default destructor declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59760
Bug ID: 59760
Summary: use_thunk internal error on default destructor
declarations
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sshannin at gmail dot com
Host: Linux hostname 3.2.0-29-generic #46-Ubuntu SMP Fri Jul
27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Target: x86_64-unknown-linux-gnu
Build: ../gcc-4.8.2/configure --disable-multilib
--enable-languages=c++ --program-suffix=-4.8.2
Compile line (sans includes):
g++-4.8.2 -std=c++0x -O0 -g3 -Wall -c \
-MMD -MP -MF"build/./example_dir/example.d"
-MT"build/./example_dir/example.o" \
-o build/./example_dir/example.o example_dir/example.cpp
I'm getting an internal compiler error. Details which are likely of note:
1. templated class
2. inherits privately from two other templated classes
3. all three classes have virtual destructor declarations set to '= default'
4. changing the destructor declaration in the derived class from '= default'
to '{}' resolves the issue
5. changing the destructor declarations in either/both base classes appears to
have no effect
I am not able to generate a condensed example at the moment and as such am
refraining from attaching the preprocessed source (large). I'm hoping that the
gcc backtrace along with point #4 above may be enough.
internal compiler error: in use_thunk, at cp/method.c:338
virtual ~twenty_three_char_name_() = default;
^
0x599594 use_thunk(tree_node*, bool)
../../gcc-4.8.2/gcc/cp/method.c:338
0x5a44ec emit_associated_thunks(tree_node*)
../../gcc-4.8.2/gcc/cp/semantics.c:3774
0x5a47a7 expand_or_defer_fn(tree_node*)
../../gcc-4.8.2/gcc/cp/semantics.c:3901
0x5bc0bd maybe_clone_body(tree_node*)
../../gcc-4.8.2/gcc/cp/optimize.c:428
0x5a459d expand_or_defer_fn_1(tree_node*)
../../gcc-4.8.2/gcc/cp/semantics.c:3825
0x5a4778 expand_or_defer_fn(tree_node*)
../../gcc-4.8.2/gcc/cp/semantics.c:3895
0x59a70f synthesize_method(tree_node*)
../../gcc-4.8.2/gcc/cp/method.c:809
0x5471ea mark_used(tree_node*)
../../gcc-4.8.2/gcc/cp/decl2.c:4677
0x4f3d4c build_over_call
../../gcc-4.8.2/gcc/cp/call.c:7055
0x4f11f8 build_new_method_call_1
../../gcc-4.8.2/gcc/cp/call.c:7715
0x4f11f8 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc-4.8.2/gcc/cp/call.c:7785
0x4f1a9e build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../gcc-4.8.2/gcc/cp/call.c:7352
0x591dcf expand_cleanup_for_base
../../gcc-4.8.2/gcc/cp/init.c:1217
0x596301 expand_cleanup_for_base
../../gcc-4.8.2/gcc/cp/init.c:1112
0x596301 emit_mem_initializers(tree_node*)
../../gcc-4.8.2/gcc/cp/init.c:1097
0x56e16c cp_parser_mem_initializer_list
../../gcc-4.8.2/gcc/cp/parser.c:11736
0x56e16c cp_parser_ctor_initializer_opt
../../gcc-4.8.2/gcc/cp/parser.c:11647
0x56e16c cp_parser_ctor_initializer_opt_and_function_body
../../gcc-4.8.2/gcc/cp/parser.c:17858
0x56e7bf cp_parser_function_definition_after_declarator
../../gcc-4.8.2/gcc/cp/parser.c:21853
0x56f3c3 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-4.8.2/gcc/cp/parser.c:21774
[Bug c++/59760] use_thunk internal error on default destructor declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59760 --- Comment #1 from sshannin at gmail dot com --- For a simpler example, see https://lists.debian.org/debian-gcc/2013/12/msg00107.html
[Bug c++/59760] use_thunk internal error on default destructor declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59760
--- Comment #3 from sshannin at gmail dot com ---
Created attachment 31821
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31821&action=edit
Preprocessed source
Preprocessed source of compilation from example in previous link.
Source (no includes):
template struct A {
virtual ~A();
};
template struct B : A... {
~B() = default;
};
struct C : B {
C() {}
};
int main( int , char **)
{
C c;
}
Compiled with:
g++-4.8.2 -std=c++0x -O0 -g3 -Wall -c -o sample.o sample.cpp
[Bug libstdc++/96269] optional comparison with nullopt fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96269 --- Comment #6 from sshannin at gmail dot com --- Thanks to you both for your analysis. As I said, I wasn't sure if it was an issue, so I'm certainly willing to accept that it's not. The one point I wanted to emphasize though just to make sure we're talking about the same thing is that it seems to odd to me that we're instantiating any form of comparison function for type T. We're comparing optional to nullopt_t, so it would seem that it shouldn't matter whether T itself is even comparable. More specifically, header defines operator<=>(const optional &x, nullopt_t), with the very simple body of bool(x) <=> false, as expected (circa line 1050, gated by #ifdef __cpp_lib_three_way_comparsion). This is why the non-flip case works, it hits the spaceship overload for (optional, null_opt_t). But there is no such operator in the other direction: (null_opt_t, optional). So we end up hitting optional's plain templated operator==() at ~line 1120, which of course ultimately instantiates the T's (broken/weird) operator. I guess to rephrase, should there also be a specialized spaceship overload for the (nullopt_t, optional) direction to complement the (optional, nullopt) one?
[Bug c++/98980] New: Very slow compilation with -Wduplicated-branches and ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98980 Bug ID: 98980 Summary: Very slow compilation with -Wduplicated-branches and ubsan Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: sshannin at gmail dot com Target Milestone: --- Created attachment 50136 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50136&action=edit the code I have attached a heavily reduced example which encounters excessively slow compilation. I was not able to remove the stringstream include without the degenerate behavior disappearing, unfortunately; I hope that's ok. It seems to be mostly exponential in the number of operator<< invocations, with a couple interesting behaviors - s/long/int/g on the code allows it to compile almost instantly - removing any of the longs being streamed seems to halve the time, but so does replacing the variable with a literal - removing any of the string literals also halves the time. Compiled with flags: /toolchain14/bin/g++ -std=c++2a -Wduplicated-branches -c -fsanitize=undefined -o dup.o dup.cpp /toolchain14/bin/g++ -v Using built-in specs. COLLECT_GCC=/toolchain14/bin/g++ COLLECT_LTO_WRAPPER=/toolchain14/libexec/gcc/x86_64-pc-linux-gnu/9.1.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc_9_1_0/configure --prefix=/toolchain14 --enable-languages=c,c++,fortran --enable-lto --disable-plugin --program-suffix=-9.1.0 --disable-multilib Thread model: posix gcc version 9.1.0 (GCC)
[Bug libstdc++/69600] [5 Regression] Incorrect use of copy-assignment instead of move assignment from function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69600
--- Comment #7 from sshannin at gmail dot com ---
Comment on attachment 37541
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37541
preprocessed source
> #include
> #include
> #include
>typedef std::unique_ptr inner_value_t;
>typedef std::map inner_data_t;
>
>typedef std::map data_t;
>
>
>data_t foo() {
>return data_t{};
>}
>
>int main(int argc, char **argv)
>{
>
>data_t d;
>d = foo();
>return 0;
>}
[Bug c/118194] New: spurious warning with -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118194
Bug ID: 118194
Summary: spurious warning with -Wmaybe-uninitialized
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sshannin at gmail dot com
Target Milestone: ---
There are a number of other open bug reports about this warning, but none of
them seemed quite the same. This is different in that:
- doesn't rely on C++ constructs such as lambdas
- occurs at all optimization levels -O0 through -O3
- very simple path with no control flow
#include
#include
void *foo(int sz) {
void *p = malloc(sz);
mlock(p, sz);
return p;
}
The above minimal example triggers a maybe-uninitialized warning:
: In function 'foo':
:6:5: warning: 'p' may be used uninitialized [-Wmaybe-uninitialized]
6 | mlock(p, sz);
| ^~~~
In file included from :2:
/usr/include/x86_64-linux-gnu/sys/mman.h:103:12: note: by argument 1 of type
'const void *' to 'mlock' declared here
103 | extern int mlock (const void *__addr, size_t __len) __THROW;
|^
It looks like this was introduced starting in 11.1 and is present up through
trunk.
[Bug tree-optimization/118194] [12/13/14/15 regression] spurious warning with -Wmaybe-uninitialized with mlock since r11-959-gb825a22890740f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118194 --- Comment #3 from sshannin at gmail dot com --- > The wording is also quite confusing - it should probably say 'dereferencing 'p' would access uninitialized memory'. Oh, indeed. I can certainly confirm that's how I interpreted it when filing this bug. I didn't even realize until your reply just now that it was talking about the (assumed) deref instead of p itself.
