[Bug c++/60277] Bogus "inline function virtual ..." used but never defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60277 Mikhail Maltsev changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #3 from Mikhail Maltsev --- I also wanted to report this bug (it reproduces on trunk), but found this report and an old duplicate: PR11067 which is resolved as WONTFIX. IMHO it's not too difficult to fix, including the case "f->Foo::func();" (though I did not regtest the fix, so I can't say for sure). The question is: should this warning be emitted or not? Clang does not produce such warning.
[Bug c++/65966] "sorry, unimplemented: unexpected AST of kind try_block" when initializing a 2D array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65966 Mikhail Maltsev changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #2 from Mikhail Maltsev --- (In reply to Lewis Hyatt from comment #1) > This seems to be an unrelated issue. It did not start failing at the above > revision, rather it ICEs in that revision and the few prior to it that I > checked. It also happens whether you have -std=c++11 or -std=c++14, and I > see the same behavior in gcc 4.7, 4.8 and 4.9 as well (in those releases, it > works, does not ICE, but does output the huge number of instructions). So it > seems that over time, it has changed several times whether it ICEs or > compiles, but it has always generated this unexpected code. > > Should I file this as a separate bug? Perhaps, no. This problem is known: PR65591, PR65503
[Bug rtl-optimization/53533] [4.8/4.9/5/6 regression] vectorization causes loop unrolling test slowdown as measured by Adobe's C++Benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533 --- Comment #29 from Mikhail Maltsev --- Results for attached testcase: Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz (Haswell) g++ -O3 -march=native -mtune=native 1 iterations Clang 3.7 Total absolute time for int32_t for loop unrolling: 0.99 sec Total absolute time for int32_t do loop unrolling: 1.00 sec Total absolute time for double for loop unrolling: 1.37 sec Total absolute time for double do loop unrolling: 1.37 sec GCC 4.7.4 Total absolute time for int32_t for loop unrolling: 5.88 sec Total absolute time for int32_t do loop unrolling: 7.57 sec Total absolute time for double for loop unrolling: 2.29 sec Total absolute time for double do loop unrolling: 2.45 sec GCC 4.8.4 Total absolute time for int32_t for loop unrolling: 3.12 sec Total absolute time for int32_t do loop unrolling: 3.29 sec Total absolute time for double for loop unrolling: 1.13 sec Total absolute time for double do loop unrolling: 1.14 sec GCC 4.9.2 Total absolute time for int32_t for loop unrolling: 3.02 sec Total absolute time for int32_t do loop unrolling: 3.29 sec Total absolute time for double for loop unrolling: 1.10 sec Total absolute time for double do loop unrolling: 1.13 sec GCC 6 Total absolute time for int32_t for loop unrolling: 5.95 sec Total absolute time for int32_t do loop unrolling: 6.95 sec Total absolute time for double for loop unrolling: 2.39 sec Total absolute time for double do loop unrolling: 2.39 sec g++ -DINLINE_MANUALLY -O3 -march=native -mtune=native 5 iterations Clang 3.7 Total absolute time for int32_t for loop unrolling: 2.43 sec Total absolute time for int32_t do loop unrolling: 2.32 sec Total absolute time for double for loop unrolling: 6.38 sec Total absolute time for double do loop unrolling: 6.38 sec GCC 4.9.2 Total absolute time for int32_t for loop unrolling: 10.17 sec Total absolute time for int32_t do loop unrolling: 10.16 sec Total absolute time for double for loop unrolling: 3.89 sec Total absolute time for double do loop unrolling: 3.90 sec GCC 6 Total absolute time for int32_t for loop unrolling: 10.10 sec Total absolute time for int32_t do loop unrolling: 10.12 sec Total absolute time for double for loop unrolling: 3.90 sec Total absolute time for double do loop unrolling: 3.89 sec g++ -DINLINE_MANUALLY -Ofast -march=native -mtune=native GCC 6 Total absolute time for int32_t for loop unrolling: 10.11 sec Total absolute time for int32_t do loop unrolling: 10.11 sec Total absolute time for double for loop unrolling: 1.14 sec Total absolute time for double do loop unrolling: 1.15 sec So, IMHO there is no regression here (at least w.r.t. vectorization). Floating point loop gets constant-folded, if reassociation is allowed. Also, GCC6 is able to infer that "for" and "while" tests are semantically equivalent and unifies them.
[Bug rtl-optimization/53533] [4.8/4.9/5/6 regression] vectorization causes loop unrolling test slowdown as measured by Adobe's C++Benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533 Mikhail Maltsev changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #28 from Mikhail Maltsev --- Created attachment 35455 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35455&action=edit testcase, inlining This testcase marks some functions with __attribute__((always_inline/noinline)) when -DINLINE_MANUALLY is defined.
[Bug c++/66001] [5/6 regression] ICE when NSDMI in a literal class uses a destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66001 Mikhail Maltsev changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #3 from Mikhail Maltsev --- The second testcase is similar to PR65966 (same error message and it is also caused by implicitly constexpr constructor in a class with non-constexpr-NSDMI)
[Bug c++/65919] Regression - GCC 5.1 with options "-g -std=c++14" fails to compile multiple lambdas used as default function parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65919
Mikhail Maltsev changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment #1 from Mikhail Maltsev ---
Reduced testcase:
template class function;
template class _Base_manager {
public:
void _M_manager();
template static bool _M_not_empty_function(_Tp);
};
template class A;
template
class A : public _Base_manager<_Functor> {};
template
class function<_Res(_ArgTypes...)> {
template using _Requires = int;
public:
template >
function(_Functor);
};
template
template
function<_Res(_ArgTypes...)>::function(_Functor p1) {
A<_Res(), _Functor>::_M_not_empty_function(p1);
}
struct B {
static void do_things(function = [] {}, function = [] {});
};
int main() {
B::do_things();
}
[Bug c++/65882] [5/6 Regression] Internal compiler error: Error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65882 Mikhail Maltsev changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #4 from Mikhail Maltsev --- For the record. Proposed patch (also contains slightly more reduced testcase): https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01558.html
[Bug c++/65876] New: [5/6 Regression] [C++11] ICE in cxx_eval_call_expression, at cp/constexpr.c:1358
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65876
Bug ID: 65876
Summary: [5/6 Regression] [C++11] ICE in
cxx_eval_call_expression, at cp/constexpr.c:1358
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: maltsevm at gmail dot com
Consider the following code:
$ cat test.cc
template
struct duration
{
constexpr duration() : r(0) {}
template
constexpr duration(duration x) : r(x.count()) {}
constexpr int count() { return 0; }
int r;
};
struct Config {
duration<1> timeout { duration<2>() };
};
Config make_config()
{
return {};
}
struct ConfigArray {
ConfigArray();
Config all_configs[1];
};
ConfigArray::ConfigArray()
{
}
When trying to compile it with GCC 5.1 or trunk r222403 using the following
options:
$ g++ -c -std=c++11 ./test.cc
I get the following error:
./test.cc: In constructor 'ConfigArray::ConfigArray()':
./test.cc:28:26: in constexpr expansion of 'Config()'
./test.cc:28:26: in constexpr expansion of 'duration<1>(duration<2>())'
./test.cc:7:58: in constexpr expansion of 'x.duration<
>::count<2>()'
./test.cc:28:26: internal compiler error: in cxx_eval_call_expression, at
cp/constexpr.c:1331
ConfigArray::ConfigArray()
^
0x7eb08e cxx_eval_call_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:1331
0x7ebf0c cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3038
0x7ef0ca cxx_eval_store_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:2651
0x7ec869 cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3112
0x7ec052 cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3365
0x7ec310 cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3229
0x7ec310 cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3229
0x7ebf64 cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3406
0x7f229e cxx_eval_statement_list
/home/miyuki/gcc/src/gcc/cp/constexpr.c:2828
0x7ec76c cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3400
0x7eb188 cxx_eval_call_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:1365
0x7ebf0c cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3038
0x7ecc94 cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3097
0x7ef0ca cxx_eval_store_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:2651
0x7ec869 cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3112
0x7ec052 cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3365
0x7ec310 cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3229
0x7ec310 cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3229
0x7ebf64 cxx_eval_constant_expression
/home/miyuki/gcc/src/gcc/cp/constexpr.c:3406
0x7f229e cxx_eval_statement_list
/home/miyuki/gcc/src/gcc/cp/constexpr.c:2828
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug other/65800] gengtype aborts when run with -d (debug dump)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65800 --- Comment #1 from Mikhail Maltsev --- Created attachment 35350 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35350&action=edit Fix Just in case, I also regtested it.
[Bug other/65800] New: gengtype aborts when run with -d (debug dump)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65800 Bug ID: 65800 Summary: gengtype aborts when run with -d (debug dump) Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: maltsevm at gmail dot com Running gengtype with the following parameters (from GCC build directory): $ ./gcc/gengtype -r ./gcc/gtype.state -d Triggers assertion failure: typedefs: pair: name = vec Type at 0x1e59200: kind = TYPE_USER_STRUCT pointer_to = 0x1e592c0 gc_used = GC_POINTED_TO u.s.tag = vec fileloc: file = /home/miyuki/gcc/src/gcc/objc/objc-next-runtime-abi-02.c, line = 2776 u.s.fields = pair: name = va_gc Type at 0x1e59520: kind = TYPE_UNDEFINED pointer_to = (nil) gc_used = GC_UNUSED gengtype: Internal error: abort in dump_type, at gengtype.c:4956 I noticed two situations, where this (i.e. presence of TYPE_UNDEFINED in dumps) is possible: first, a combination of templates and typedefs (see comment for function gengtype.c:set_gc_used_type). Second is rtl expressions with optional fields (struct block_symbol in SYMBOL_REF).
[Bug pch/65550] [5 Regression] ICE (segfault) with pch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65550 --- Comment #5 from Mikhail Maltsev --- Or even simpler: #!/bin/bash mkdir -p ./src mkdir -p ./build/src/preproc.h.gch touch ./src/preproc.h cat << EOF >./src/include.h #include "src/preproc.h" /* line 1 */ /* line 2 */ EOF cat << EOF >./src/source.cpp #include "include.h" /* a single line with at least 128 columns and one token */ token EOF cd ./build cc1plus ../src/preproc.h --output-pch=src/preproc.h.gch/pch_file cc1plus -I . ../src/source.cpp
[Bug pch/65550] [5 Regression] ICE (segfault) with pch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65550 Mikhail Maltsev changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #4 from Mikhail Maltsev --- Created attachment 35228 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35228&action=edit Reproducer Reduced testcase. The script should be invoked like this: CXX=/path/to/gcc-5.0/bin/g++ ice_pch.sh It creates 3 files and invokes GCC 2 times (one for PCH creation, one for compilation which causes ICE on current trunk). Note, that whitespaces in source files matter.
[Bug c++/65154] [4.8/4.9/5 Regression] ICE with {} initialized array with string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65154
--- Comment #5 from Mikhail Maltsev ---
I have posted a patch for this bug:
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00026.html
But it reveals some latent bug (PR65503). In the following case (after applying
the patch):
struct ss {
ss() {};
};
struct C {
ss s[1000];
};
int main() {
C cs[5]{};
}
We'll get 1000 calls to ss() in main instead of calling default c-tor of struct
C. (which is probably not what we want).
[Bug c++/65503] g++ string array in struct crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65503
Mikhail Maltsev changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment #2 from Mikhail Maltsev ---
Also, I noticed that in some cases GCC is able to generate a loop for
initialization:
#include
int main() {
std::string m[1000] {"x", "y"};
std::string n[1000] = {"x", "y"};
}
That is done in cp/init.c:build_vec_init. But for the original testcase, the
loop is not created. Is it a bug?
[Bug c++/65513] gcc stops with "internal compiler error"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65513
Mikhail Maltsev changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment #2 from Mikhail Maltsev ---
Reproduced on current commit in branch 4.9, fixed on trunk.
What is interesting about this bug, is that when I reduced it, I got a testcase
identical to PR65154 (which also gives ICE on 5.0). So, here is a testcase
reduced in such way, that it's behavior differs (ICE on 4.9, OK for 5.0):
namespace std {
template struct atomic {
atomic() = default;
atomic(_Tp);
};
}
class {
public:
std::atomic bReadyToFlush;
}
LogThreadsleLogEntries[10]{};
[Bug target/65507] avr-gcc -f-merge-all-constants causes internal compiler error in get_section, at varasm.c:312
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65507
Mikhail Maltsev changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment #2 from Mikhail Maltsev ---
On current trunk GCC does not ICE, but still sort-of-rejects the valid code.
Reduced testcase:
$ cat ./reduced2.c
void foobar() {
static const char c1[] __attribute__((__progmem__)) = "1",
c2[] __attribute__((__progmem__)) = "2",
c3[] = "3";
}
/opt/binutils-avr/bin/avr-gcc -c -fmerge-all-constants ./reduced2.c
./reduced2.c:5:1: error: section type conflict
}
Despite the error, assembly code (and object file) are still produced, though
it seems to me, that section information gets trashed, but I'm not sure. Looks
like this:
.section.rodata.str1.1,"aMS",@progbits,1
.type c3.1570, @object
.size c3.1570, 2
c3.1570:
.string "3"
.section.progmem.data.str1.1
.type c2.1569, @object
.size c2.1569, 2
c2.1569:
.string "2"
.type c1.1568, @object
.size c1.1568, 2
c1.1568:
.string "1"
Without "-fmerge-all-constants" I get the following:
.size foobar, .-foobar
.section.rodata
.type c3.1570, @object
.size c3.1570, 2
c3.1570:
.string "3"
.section.progmem.data,"a",@progbits
.type c2.1569, @object
.size c2.1569, 2
c2.1569:
.string "2"
.type c1.1568, @object
.size c1.1568, 2
c1.1568:
.string "1"
The problem occurs when GCC tries to get the section for c1 and calls
avr_asm_select_section. This function changes the section name from
".rodata.data.str1.1" to ".progmem.data.str1.1", it then turns out that this
section already exists and the check in varasm.c:get_section fails (both
sections have same flags, SECTION_DECLARED is true, SECTION_OVERRIDE is false,
SECTION_WRITE is false - this all triggers an error).
This comment seems relevant:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43746#c8.
[Bug c++/65071] ICE on valid, sizeof...() of template template parameter pack in return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65071 --- Comment #3 from Mikhail Maltsev --- For the record: a patch for this PR https://gcc.gnu.org/ml/gcc-patches/2015-02/msg01067.html
[Bug c++/65433] ICE processing lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65433 Mikhail Maltsev changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #2 from Mikhail Maltsev --- Does not reproduce on trunk $ /opt/gcc-5.0.0/bin/g++ -v Using built-in specs. COLLECT_GCC=/opt/gcc-5.0.0/bin/g++ COLLECT_LTO_WRAPPER=/opt/gcc-5.0.0/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/miyuki/gcc/src/configure --prefix=/opt/gcc-5.0.0 --enable-clocale=gnu --disable-nls --with-system-zlib --with-demangler-in-ld --enable-plugins --enable-shared --enable-bootstrap --with-fpmath=sse --enable-languages=c,c++,lto Thread model: posix gcc version 5.0.0 20150315 (experimental) (GCC) $ /opt/gcc-5.0.0/bin/g++ -std=gnu++1y -g -Wall -Werror -fvisibility=hidden -pthread -O2 -c fail.i
[Bug c/65423] No warning on always-true/false predicates containing bitwise operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65423 Mikhail Maltsev changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #2 from Mikhail Maltsev --- Probably this one: PR17534
[Bug c++/65143] [C++11] missing devirtualization for virtual base in "final" classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65143
Mikhail Maltsev changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment #3 from Mikhail Maltsev ---
This optimization is still missing in current trunk:
$ cat ./test.cc
struct A
{
int j;
};
struct B : public virtual A
{
};
struct C final : public B
{
int get();
};
int C::get()
{
return A::j;
}
$ /opt/gcc-5.0.0/bin/g++ -O -std=c++11 -c -S ./test.cc -o test_gcc.s && cat
./test_gcc.s
.file "test.cc"
.text
.align 2
.globl _ZN1C3getEv
.type _ZN1C3getEv, @function
_ZN1C3getEv:
.LFB0:
.cfi_startproc
movq(%rdi), %rax
movq-24(%rax), %rax
movl(%rdi,%rax), %eax
ret
.cfi_endproc
.LFE0:
.size _ZN1C3getEv, .-_ZN1C3getEv
.ident "GCC: (GNU) 5.0.0 20150315 (experimental)"
.section.note.GNU-stack,"",@progbits
(Note: optimization flags like -O3 and -fdevirtualize-speculatively don't
affect this behavior; neither method calls nor data member accesses get
devirtualized)
$ clang++ -O -std=c++11 -c -S ./test.cc -o test_clang.s && cat ./test_clang.s
.text
.file "./test.cc"
.globl _ZN1C3getEv
.align 16, 0x90
.type _ZN1C3getEv,@function
_ZN1C3getEv:# @_ZN1C3getEv
.cfi_startproc
# BB#0: # %entry
movl8(%rdi), %eax
retq
.Ltmp0:
.size _ZN1C3getEv, .Ltmp0-_ZN1C3getEv
.cfi_endproc
.ident "clang version 3.7.0 (trunk 228487)"
.section".note.GNU-stack","",@progbits
So, I can confirm it in sense "reproduce" (I don't have a right to change the
status of PR)
[Bug tree-optimization/65307] [4.9 Regression] Incorrect optimization breaks basic arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65307
Mikhail Maltsev changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment #8 from Mikhail Maltsev ---
A simpler testcase:
static inline unsigned cp(unsigned x)
{
return x;
}
unsigned f(unsigned x)
{
return cp(x * 2) * 2 + cp(cp(x * 2) * 3) * 5;
}
$ cat ./test1.c.085t.phiopt2
;; Function f (f, funcdef_no=1, decl_uid=1393, symbol_order=1)
f (unsigned int x)
{
unsigned int _2;
unsigned int _3;
unsigned int _4;
unsigned int _5;
unsigned int _6;
:
_2 = x_1(D) * 2;
_5 = 15;
_3 = _5 + 2;
_4 = _2 * _3;
_6 = _4;
return _6;
}
$ cat ./test1.c.087t.ccp3
;; Function f (f, funcdef_no=1, decl_uid=1393, symbol_order=1)
Pass statistics:
Immediate_uses:
x_1(D) : --> single use.
_2 = x_1(D) * 2;
_2 : --> single use.
_4 = _2 * _3;
_3 : --> single use.
_4 = _2 * _3;
_4 : --> single use.
_6 = _4;
_5 : --> single use.
_3 = _5 + 2;
_6 : --> single use.
return _6;
.MEM_7(D) : --> single use.
# VUSE <.MEM_7(D)>
return _6;
Adding Destination of edge (0 -> 2) to worklist
Simulating block 2
Visiting statement:
# RANGE [0, 4294967295] NONZERO 0x0fffe
_2 = x_1(D) * 2;
which is likely CONSTANT
Lattice value changed to CONSTANT 0x0 (0x0fffe).
Adding SSA edges to worklist.
Visiting statement:
# RANGE [0, 4294967295] NONZERO 0x0fffe
_5 = 15;
which is likely CONSTANT
Lattice value changed to CONSTANT 14. Adding SSA edges to worklist.
Visiting statement:
_3 = _5 + 2;
which is likely CONSTANT
Lattice value changed to CONSTANT 16. Adding SSA edges to worklist.
Visiting statement:
_4 = _2 * _3;
which is likely CONSTANT
Lattice value changed to CONSTANT 0x0 (0x0ffe0).
Adding SSA edges to worklist.
Visiting statement:
# RANGE [0, 4294967295] NONZERO 0x0fffe
_6 = _4;
Lattice value changed to CONSTANT 0x0 (0x0ffe0).
Adding SSA edges to worklist.
Visiting statement:
# VUSE <.MEM_7(D)>
return _6;
No interesting values produced. Marked VARYING.
Substituting values and folding statements
Folding statement: return _6;
Not folded
Folding statement: _6 = _4;
Not folded
Folding statement: _4 = _2 * _3;
Folded into: _4 = _2 * 16;
Removing dead stmt _3 = 16;
Removing dead stmt _5 = 14;
Folding statement: _2 = x_1(D) * 2;
Not folded
Pass statistics:
Constants propagated: 1
Statements deleted: 2
f (unsigned intD.4 xD.1392)
{
unsigned intD.4 _2;
unsigned intD.4 _4;
unsigned intD.4 _6;
;; basic block 2, loop depth 0, count 0, freq 1, maybe hot
;;prev block 0, next block 1, flags: (NEW, REACHABLE)
;;pred: ENTRY [100.0%] (FALLTHRU,EXECUTABLE)
# RANGE [0, 4294967295] NONZERO 0x0fffe
_2 = x_1(D) * 2;
# RANGE [0, 4294967295] NONZERO 0x0ffe0
_4 = _2 * 16;
# RANGE [0, 4294967295] NONZERO 0x0ffe0
_6 = _4;
# VUSE <.MEM_7(D)>
return _6;
;;succ: EXIT [100.0%]
}
[Bug middle-end/65289] [5.0 regression] ICE when compiling libjpegturbo with -floop-nest-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65289
Mikhail Maltsev changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment #2 from Mikhail Maltsev ---
Reduced test case, reproduces ICE for both sets of options (-O2
-fgraphite-identity and -O2 -floop-nest-optimize):
tjCompress2(srcBuf, height) {
int i, *row_pointer;
if (_setjmp())
for (; i < height; i++)
row_pointer[i] = srcBuf;
jpeg_abort_compress();
}
Of course, this program now involves undefined behavior, but the error message
is still the same as in the original one.
Here is another example:
void bar ();
int foo (char *dest, int i)
{
_setjmp();
while (i)
dest[--i] = 0;
bar();
}
./test1.c: In function 'foo':
./test1.c:2:5: error: loop 2's latch is marked as part of irreducible region
int foo (char *dest, int i)
^
./test1.c:2:5: error: edge from 16 to 19 should be marked irreducible
./test1.c:2:5: error: basic block 19 should be marked irreducible
./test1.c:2:5: error: edge from 19 to 17 should be marked irreducible
./test1.c:2:5: error: basic block 20 should not be marked irreducible
./test1.c:2:5: error: edge from 20 to 25 should not be marked irreducible
./test1.c:2:5: error: basic block 25 should not be marked irreducible
./test1.c:2:5: error: edge from 25 to 23 should not be marked irreducible
./test1.c:2:5: error: basic block 23 should not be marked irreducible
./test1.c:2:5: error: edge from 23 to 24 should be marked irreducible
./test1.c:2:5: error: basic block 21 should not be marked irreducible
./test1.c:2:5: error: edge from 21 to 20 should not be marked irreducible
./test1.c:2:5: error: basic block 24 should be marked irreducible
./test1.c:2:5: error: edge from 24 to 18 should be marked irreducible
./test1.c:2:5: internal compiler error: in verify_loop_structure, at
cfgloop.c:1652
[Bug lto/65274] Internal compiler error: should die in combat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65274 Mikhail Maltsev changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #1 from Mikhail Maltsev --- Actually, I'm not very familiar with debug information-related stuff, but there are two other bug reports, PR57664 and PR63505 involving ICE in the same function - both reproduce on 4.9.x, but not on trunk. The function used to contain an assertion (but it's on line 6837, not 6846), https://github.com/gcc-mirror/gcc/blob/gcc-4_9_2-release/gcc/dwarf2out.c#L6837 which later became a check: https://github.com/michaelforney/arbor/blob/11cfe14a4c9048e5b742c794a5b14bb25b08a373/packages/sys-devel/gcc/files/gcc-4.7.2-should_move_die_to_comdat.patch Perhaps, you could try to perform the build with current version of GCC and tell, if it still reproduces? P.S. Nice title for bug report :).
[Bug c++/65201] range-for range-init containing variable named like for-range-declaration iterates over uninitialized for-range-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65201
Mikhail Maltsev changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment #2 from Mikhail Maltsev ---
Reduced testcase, miscompilation, works on clang 3.5.0, but causes segfault on
trunk (r221132) and on g++ 4.8.2 20140120, x86_64-unknown-linux-gnu:
$ cat ./range-for30_r2.cc
struct str
{
str () : v(0) {}
str (const str &s) : v(s.v) {}
~str () { v = 0; }
int v;
};
str data[1];
struct vec
{
str *begin () { return data; }
str *end () { return data + 1; }
};
vec split (str &s)
{
s = str();
return vec();
}
int main ()
{
str foo;
for (str &foo : split(foo))
foo = str();
return foo.v;
}
And here is an even more minimized testcase (technically it's a different kind
of bug, "accepts invalid") - but I suppose that these bugs are related.
$ cat ./range-for30_r.cc
struct str { };
struct vec {
str *begin () {}
str *end () {}
};
vec split (str) {}
int main () {
for (str foo : split(foo))
;
}
Clang rejects this with the following error:
./range-for30_r.cc:8:24: error: use of undeclared identifier 'foo'; did you
mean 'for'?
for (str foo : split(foo))
[Bug c++/65154] ICE with {} initialized array with string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65154
Mikhail Maltsev changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment #2 from Mikhail Maltsev ---
I did some analysis of this bug, and want to share my results, though I still
don't known, which part of the code should be fixed (and I'm asking for
advice).
ICE happens, when gimplifier tries to lower the constructor but gets some
language specific expression. The function body looks like this (for the second
test case, slightly modified: array contains one element):
struct C cs[1];
struct C cs[1];
<>>;
struct C * D.2138;
<<< Unknown tree: expr_stmt
(void) (D.2138 = D.2137) >>>;
long int D.2139;
<<< Unknown tree: expr_stmt
(void) (D.2139 = 0) >>>;
while (1)
{
if (D.2139 == -1) goto ;
<>> >>>>}) >>>>>;
<<< Unknown tree: expr_stmt
(void) ++D.2138 >>>;
(void) --D.2139;
}
:;
Here is a backtrace which leads to construction of such expression:
#0 convert_like_real (convs=0x23f8820, expr=,
fn=, argnum=0, inner=0, issue_conversion_warnings=true,
c_cast_p=false, complain=3) at /home/miyuki/gcc/src/gcc/cp/call.c:6440
#1 0x006c2e41 in perform_implicit_conversion_flags (type=, expr=, complain=3, flags=5) at
/home/miyuki/gcc/src/gcc/cp/call.c:9418
#2 0x00856da8 in convert_for_initialization (exp=,
type=, rhs=,
flags=5, errtype=ICR_INIT, fndecl=, parmnum=0, complain=3)
at /home/miyuki/gcc/src/gcc/cp/typeck.c:8348
(continued, same call to convert_for_initialization as in previous backtrace)
#5 0x00856da8 in convert_for_initialization (exp=,
type=, rhs=,
flags=5, errtype=ICR_INIT, fndecl=, parmnum=0, complain=3)
at /home/miyuki/gcc/src/gcc/cp/typeck.c:8348
#6 0x0078a301 in digest_init_r (type=,
init=, nested=true, flags=5, complain=3) at
/home/miyuki/gcc/src/gcc/cp/typeck2.c:1126
#7 0x0078a5ef in massage_init_elt (type=, init=, complain=3) at
/home/miyuki/gcc/src/gcc/cp/typeck2.c:1190
#8 0x0078b4dd in process_init_constructor_record (type=, init=, complain=3) at
/home/miyuki/gcc/src/gcc/cp/typeck2.c:1395
#9 0x0078beb1 in process_init_constructor (type=, init=, complain=3) at
/home/miyuki/gcc/src/gcc/cp/typeck2.c:1562
#10 0x0078a159 in digest_init_r (type=,
init=, nested=false, flags=5, complain=3) at
/home/miyuki/gcc/src/gcc/cp/typeck2.c:1094
#11 0x0078a336 in digest_init (type=,
init=, complain=3) at
/home/miyuki/gcc/src/gcc/cp/typeck2.c:1133
#12 0x0086d81d in expand_default_init (binfo=, true_exp=, exp=, init=, flags=1, complain=3)
#13 0x0086e4f3 in expand_aggr_init_1 (binfo=, true_exp=, exp=, init=, flags=1, complain=3)
at /home/miyuki/gcc/src/gcc/cp/init.c:1830
#14 0x0086d431 in build_aggr_init (exp=,
init=, flags=0, complain=3) at
/home/miyuki/gcc/src/gcc/cp/init.c:1582
#15 0x0087493d in build_vec_init (base=,
maxindex=, init=,
explicit_value_init_p=false, from_array=0, complain=3)
at /home/miyuki/gcc/src/gcc/cp/init.c:3777
#16 0x0086d271 in build_aggr_init (exp=,
init=, flags=2049, complain=3) at
/home/miyuki/gcc/src/gcc/cp/init.c:1563
#17 0x006e192d in build_aggr_init_full_exprs (decl=, init=, flags=2049) at
/home/miyuki/gcc/src/gcc/cp/decl.c:5811
build_vec_init creates the loop, which performs elemtwise initialization of the
array. It is initialized with the same entity (direct initializer - here it is
seen as ) as the whole array. Then some strange
overload resolution is performed, which eventually gets resolved to the
user-defined default constructor (If I understood that right) and conversion is
applied to initializer before the call (which does not make sence).
Obviously the initializer must become "void" somewhere, but I don't known
what's the appropriate place for it. For example, some similar code (for
handling zero-initialization) is present in build_aggr_init, but this case
can't be handled there (because overload resolution must be performed, for a
case when class s has a constructor which accepts std::initializer_list).
[Bug c++/65071] ICE on valid, sizeof...() of template template parameter pack in return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65071
--- Comment #1 from Mikhail Maltsev ---
A few more comments. I wrote that GCC 5.0 segfaults. That's actually not true,
I could not reproduce segfault on checked builds (only release version of
4.9.2), but never the less it's still ICE.
So, here is a bit more minimized example:
$ cat ice_sizeof.cc
template struct S { };
template class... T, int N>
S foo(T...);
auto x = foo(S<2>{});
==
The problem occurs during name mangling. I defined
#define DEBUG_MANGLE 1
The debug output (before ICE happens) ends with this:
identifier : S
++ add_substitution (template_decl at 0x7fb804560100)
++ substitutions S-1_ = foo (template_decl at 0x7fb804560400)
S0_ = S (template_decl at 0x7fb804560100)
template-arg: integer_cst (0x7fb80441c570)
type: integer_type (0x7fb8043fe690)
++ find_substitution (integer_type at 0x7fb8043fe690)
bare-function-type : function_type(0x7fb804552c78)
type: record_type (0x7fb804552930)
++ find_substitution (record_type at 0x7fb804552930)
name: type_decl(0x7fb80454e5f0)
unscoped-template-name : template_decl(0x7fb804560100)
++ find_substitution (template_decl at 0x7fb804560100)
substitution:
template-args : tree_vec (0x7fb80455cca0)
template-arg: sizeof_expr (0x7fb80455cc60)
type: type_pack_expansion (0x7fb804552888)
++ find_substitution (type_pack_expansion at 0x7fb804552888)
type: template_decl(0x7fb804560280)
++ find_substitution (template_decl at 0x7fb804560280)
If I understand correctly, tree_class_check fails when we attempt to mangle the
argument of sizeof...(T). It is (probably) represented through parameter pack
expansion (sizeof...(T) must have the same value as the number of parameters in
the pack "T..."), which in turn depends on substitution of template template
parameter T. Template template parameters are represented using TEMPLATE_DECL:
...
else if (code == TEMPLATE_DECL)
/* A template appearing as a template arg is a template template arg. */
write_template_template_arg (node);
...
And write_CV_qualifiers_for_type rejects it.
[Bug c++/65071] New: ICE on valid, sizeof...() of template template parameter pack in return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65071
Bug ID: 65071
Summary: ICE on valid, sizeof...() of template template
parameter pack in return type
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: maltsevm at gmail dot com
The following (presumably valid) code causes segfault on trunk r220715 and
4.9.2:
$ cat ./ice_sizeof.cc
template
struct array
{
int data[N];
};
template class... T1, typename T2>
array make_array(T1 ...init)
{
return { 0 };
}
template
struct S
{
T a;
};
auto arr = make_array(S{1});
==
miyuki@gcc-devel2:~/gcc/test/ice_sizeof$ ../../obj/gcc/cc1plus -std=c++11
ice_sizeof.cc &> bug_report.txt; cat bug_report.txt
array make_array(T1...) array
make_array(T1...) [with T1 = {S}; T2 = int] void
__static_initialization_and_destruction_0(int, int) void _GLOBAL__sub_I_arr()
Analyzing compilation unit
ice_sizeof.cc: In instantiation of 'array make_array(T1...)
[with T1 = {S}; T2 = int]':
ice_sizeof.cc:8:22: internal compiler error: tree check: expected class 'type',
have 'declaration' (template_decl) in write_CV_qualifiers_for_type, at
cp/mangle.c:2154
array make_array(T1 ...init)
^
0xefd737 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/home/miyuki/gcc/src/gcc/tree.c:9341
0x7c9e9b tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/home/miyuki/gcc/src/gcc/tree.h:2969
0x7c9e9b write_CV_qualifiers_for_type
/home/miyuki/gcc/src/gcc/cp/mangle.c:2154
0x7d03b3 write_type
/home/miyuki/gcc/src/gcc/cp/mangle.c:1876
0x7d07e1 write_type
/home/miyuki/gcc/src/gcc/cp/mangle.c:2049
0x7cf5b8 write_template_arg
/home/miyuki/gcc/src/gcc/cp/mangle.c:3158
0x7cfcb8 write_template_args
/home/miyuki/gcc/src/gcc/cp/mangle.c:2546
0x7ced2a write_name
/home/miyuki/gcc/src/gcc/cp/mangle.c:831
0x7d09e6 write_class_enum_type
/home/miyuki/gcc/src/gcc/cp/mangle.c:2517
0x7d09e6 write_type
/home/miyuki/gcc/src/gcc/cp/mangle.c:1974
0x7d2d04 write_bare_function_type
/home/miyuki/gcc/src/gcc/cp/mangle.c:2440
0x7d7b39 mangle_decl_string
/home/miyuki/gcc/src/gcc/cp/mangle.c:3411
0x7d7d77 get_mangled_id
/home/miyuki/gcc/src/gcc/cp/mangle.c:3433
0x7d7d77 mangle_decl(tree_node*)
/home/miyuki/gcc/src/gcc/cp/mangle.c:3478
0xefdd10 decl_assembler_name(tree_node*)
/home/miyuki/gcc/src/gcc/tree.c:697
0x910d77 symtab_node::get_comdat_group_id()
/home/miyuki/gcc/src/gcc/cgraph.h:207
0x910d77 analyze_functions
/home/miyuki/gcc/src/gcc/cgraphunit.c:973
0x9120e5 symbol_table::finalize_compilation_unit()
/home/miyuki/gcc/src/gcc/cgraphunit.c:2427
0x6f3037 cp_write_global_declarations()
/home/miyuki/gcc/src/gcc/cp/decl2.c:4750
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
==
GCC 4.9.2 20141030 (Red Hat 4.9.2-5.ac1), i386, also crashes.
GCC 4.8.2 20140120 (Red Hat 4.8.2-16) rejects the code with the following
error:
./ice_sizeof.cc:8:20: error: template argument 1 is invalid
array make_array(T1 ...init)
clang-3.7 compiles the file without errors.
Changing the declaration to
"auto make_array_ice(T1 ...init) -> array"
does not change the behavior, but
"auto make_array_ice(T1 ...init) -> array"
gets compiled without errors by all 3 mentioned versions of g++.
[Bug target/64953] Compiling sourcecode for STM32F103 causes USB errors with some optimization settings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64953 Mikhail Maltsev changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #18 from Mikhail Maltsev --- Is your firmware (or some similar one, which also has this bug) suitable for STM32F20x MCUs? I have a development board with such controller (specifically, this one: http://www.wvshare.com/product/Open207Z-Standard.htm). Perhaps, I could assist with debugging.
[Bug c/64743] minor issue with the location of -Wlong-long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64743 Mikhail Maltsev changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #1 from Mikhail Maltsev --- It's very easy to fix. In fact, I've already written a patch. But just one clarification. Consider: typedef void (*pf_t)(const long unsigned long *); typedef unsigned long long int long_t; clang always puts warnings at first "long". Same behavior for C89 and C++98. Should we do the same or, maybe, point the warning to the beginning of type specifiers/qualifiers list?
[Bug c++/64704] software crashed when using vectorizing optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64704
--- Comment #9 from Mikhail Maltsev ---
>what can i do to make the ptr aligned by 16-byte.
Well, you may skip first few bytes (of course not just discard them, but
process one-by-one).
Fortunately, you don't need to do it manually, it can be done by the compiler.
The problem is that when you use a pointer to uint16, GCC assumes that it's
already aligned by 2 byte boundary (if it's not true, the behavior is
undefined). Consider this program:
#include
#include
#include
#include
typedef uint8_t uint8;
typedef uint16_t uint16;
typedef uint32_t uint32;
uint8 buf[1024] = { 0xFF, 0x01, 0x00, 0x02, 0x00 };
class MessageBuffer
{
public:
MessageBuffer(uint8 *data, uint16 len) :
data_(data), len_(len) { }
uint16 getLength() { return len_ - 1; }
uint16 __attribute__((noinline)) icmp6Checksum_ub (int update);
uint16 __attribute__((noinline)) icmp6Checksum_naive (int update);
uint8 __attribute__((noinline)) findPayloadType (void **payloadStart)
{
uint8 *p;
asm volatile ("leaq 1(%0), %1" : "=r"(p) : "r"(data_) : );
/* p = data_ + 1; GCC will not use this information during tree
optimization */
*payloadStart = p;
return ICMPV6_ECHO_REQUEST;
}
private:
uint8 *data_;
uint16 len_;
};
uint16 MessageBuffer::icmp6Checksum_ub(int)
{
register uint32 sum = 0x;
struct icmp6_hdr *icmp6Ptr = NULL;
uint8 type = findPayloadType((void**)&icmp6Ptr);
(void)type; /* inhibit warning */
register int i;
uint16 len = getLength();
register uint16 *ptr = (uint16 *)icmp6Ptr;
for (i = 0; i < len - 1; i += 2) {
sum += *ptr++;
}
return (sum);
}
uint16 MessageBuffer::icmp6Checksum_naive(int)
{
register uint32 sum = 0x;
uint8 *data;
findPayloadType((void**)&data);
uint16 len = getLength();
for (int i = 0; i < len - 1; i += 2) {
sum += data[i] | (data[i + 1] << 8);
}
return (sum);
}
int main()
{
MessageBuffer buffer(buf, 1000);
printf("0x%.4x\n", buffer.icmp6Checksum_naive(0));
printf("0x%.4x\n", buffer.icmp6Checksum_ub(0));
}
icmp6Checksum_naive calculates the checksum (I hope at least) and
icmp6Checksum_ub causes segfault (I tried on g++ -O3 -funroll-loops -msse2, GCC
4.8.2).
>i heard of that it is not necesary to aligned by 16-byte in x86
Maybe you confuse movdqa and movdqu (or some other instruction)?
Here is a universal implementation from Linux kernel (there are also
platform-specific versions):
http://lxr.free-electrons.com/source/lib/checksum.c
Notice that the case when address is odd is handled separately (especially in
platform-specific code).
[Bug c++/64704] software crashed when using vectorizing optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64704 Mikhail Maltsev changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #5 from Mikhail Maltsev --- (In reply to kathy from comment #3) > i think, form line:13082c7 to 1308348, the code is to doing something with > align? Yes 13082f0: 66 41 0f 6f 0b movdqa (%r11),%xmm1 Address in %r11 is expected to be aligned by 16-byte boundary.
[Bug libgcc/64677] incorrect result with complex division?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64677 --- Comment #10 from Mikhail Maltsev --- > 1. Why does the answer change based on the -std? I could reproduce the same result on GCC 4.8.2. I suppose that the most significant difference is that C++11 supports constexpr (and std::complex has constexpr constructor). Also, at higher optimization level, e.g. -O3, C++98 version will also get folded (it just requires more inlining than C++11). > Is Wolfram Alpha considered the authoritative answer? It's unlikely that it will give incorrect answer, but of course is cannot be considered a reference implementation, like, for example the C++ standard. By the way, according to C++ standard, precision of floating point numbers is implementation-defined.
[Bug c/64639] false negative of -Wunused-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64639 Mikhail Maltsev changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #5 from Mikhail Maltsev --- > gets somehow transformed into > b = (a = 0B) != 0B;, 0; Probably folding works this way. Anyway, I think, I can explain how the warning is [not] generated (I stepped through the code using GDB). So: We start parsing RHS of assignment expression (the outermost one). After parsing two operands of comma, we get into build_compound_expr function (in c-typeck.c) and this function generates a warning because "left-hand operand of comma expression" (i.e. 0) "has no effect" (that's true, but the wording is a bit strange). Then we parse the next comma expression and get into the same function. The code of build_compound_expr looks like this: ... if (!TREE_SIDE_EFFECTS (expr1)) ... else if (TREE_CODE (expr1) == COMPOUND_EXPR && warn_unused_value) ... /* With -Wunused, we should also warn if the left-hand operand does have side-effects, but computes a value which is not used. For example, in `foo() + bar(), baz()' the result of the `+' operator is not used, so we should issue a warning. */ else if (warn_unused_value) warn_if_unused_value (expr1, loc); Unfortunately, we don't get into warn_if_unused_value because the condition of previous branch is true. That's why there is no warning about the result of comparison. P.S. I know, that it all might be obvious for most of you, but I'm just trying to get acquainted with GCC sources and (hopefully) do something useful for the project, while waiting for next stage1 (bugs being fixed during stage 4 are obviously not for newcomers).
[Bug c/64619] No -Wsign-conversion warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64619
Mikhail Maltsev changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment #1 from Mikhail Maltsev ---
Indeed, confirmed on recent revision, r219801.
FWIW: it affects only bitwise operations with constants and only in case when
result is wider than non-constant operand. They are handled specially in
unsafe_conversion_p (I guess, that's because bitwise AND is used frequently, so
false positives involving it should be avoided).
$ cat ./test.c
int a;
unsigned long b;
void foo()
{
a ^ b;
a ^ 0x1U;
a ^ 0x1UL;
a + 0x1U;
a + 0x1UL;
a & 0xULL;
a & 0x7FFFULL;
}
$ ../obj/gcc/xgcc -B../obj/gcc -c ./test.c -Wconversion
./test.c: In function 'foo':
./test.c:6:5: warning: conversion to 'long unsigned int' from 'int' may change
the sign of the result [-Wsign-conversion]
a ^ b;
^
./test.c:7:5: warning: conversion to 'unsigned int' from 'int' may change the
sign of the result [-Wsign-conversion]
a ^ 0x1U;
^
./test.c:9:5: warning: conversion to 'unsigned int' from 'int' may change the
sign of the result [-Wsign-conversion]
a + 0x1U;
^
./test.c:10:5: warning: conversion to 'long unsigned int' from 'int' may change
the sign of the result [-Wsign-conversion]
a + 0x1UL;
^
./test.c:11:5: warning: conversion to 'long long unsigned int' from 'int' may
change the sign of the result [-Wsign-conversion]
a & 0xULL;
^
[Bug c++/64677] incorrect result with complex division?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64677 Mikhail Maltsev changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #3 from Mikhail Maltsev --- Probably calculating with higher precision will give correct result. Output of Wolfram Alpha: -O0: convert -0.0083223357032193145 to binary -1.000110110100110011010101100001010110111001110010010010111001000111111001011011000..._2×2^-7 | hexadecimal value IEEE double-precision number | 578f5ffd4c0b81bf (assuming little-endian byte ordering) -O1: convert -0.0083223357032193128 to binary -1.0001101101001100110101011000010101110100011001001110010111010110100111010111010010011..._2×2^-7 | hexadecimal value IEEE double-precision number | 568f5ffd4c0b81bf (assuming little-endian byte ordering) Wolfram Alpha's calculation: binary(re(1/(-61.887073591767951 -60.052083270252012i))) -1.00011011010011001101010110000101011011001010101000110101101101101101000101101010..._2×2^-7 | hexadecimal value IEEE double-precision number | 568f5ffd4c0b81bf (assuming little-endian byte ordering) So, compile-time result is more precise. BTW, what does the disassembly look like?
[Bug other/64370] [5 Regression] sreal.c:125:23: error: 'exp2' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64370
Mikhail Maltsev changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment #3 from Mikhail Maltsev ---
In libgfortran/intrinsics/c99_functions.c, scalbn is implemented like this:
double
scalbn (double x, int y)
{
#if (FLT_RADIX == 2) && defined(HAVE_LDEXP)
return ldexp (x, y);
#else
return x * pow (FLT_RADIX, y);
#endif
}
Maybe something similar could be used here. If pow is not OK, something like
this could be used:
return (y >= 0) ? x * (1 << y) : x / (1 << (-y)); (assuming that shift will not
cause overflow).
BTW, what if FLT_RADIX != 2?
[Bug ipa/64481] [5 Regression] r219076 breaks bootstrap (x86_64-unknown-linux-gnu)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64481 Mikhail Maltsev changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #2 from Mikhail Maltsev --- Reproduced on recent revision (219345). Indeed, --disable-checking causes comparison to fail. Bootstrap fails: configure --prefix=/usr/local/gcc-5.0.0 --enable-clocale=gnu --with-system-zlib --enable-shared --enable-bootstrap --disable-checking --disable-multilib --disable-nls --with-demangler-in-ld --with-fpmath=sse --enable-languages=c,c++ Bootstrap passes: configure --prefix=/usr/local/gcc-5.0.0 --enable-clocale=gnu --with-system-zlib --enable-shared --enable-bootstrap --disable-multilib --disable-nls --with-demangler-in-ld --with-fpmath=sse --enable-languages=c,c++
[Bug c++/64524] gcc can't detect same expression in both parts of ternary operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64524 Mikhail Maltsev changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #4 from Mikhail Maltsev --- > int k = cond ? sizeof (x) : sizeof (y); By the way, this is a good example of probable "false positives". Consider: constexpr std::size_t max_size = (sizeof(T1) > sizeof(T2)) ? sizeof(T1) : sizeof(T2); This is an example of "legal" code, it could be used for allocating a buffer which could hold either object of type T1 or type T2. These sizes may be platform-dependent (or they may depend on template parameters), so this code makes sence, but it will produce a warning when sizes are equal. So, probably this warning only makes sence, if ASTs' would be compared, not the values.
[Bug web/64468] New: Incorrect indentation in Doxygen-generated sources of libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64468 Bug ID: 64468 Summary: Incorrect indentation in Doxygen-generated sources of libstdc++ Product: gcc Version: 5.0 URL: https://gcc.gnu.org/onlinedocs/libstdc++/latest-doxyge n/a00971_source.html Status: UNCONFIRMED Severity: trivial Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: maltsevm at gmail dot com See the attached URL. The indentation is broken (it is best visible near line 150 and further). The URL is given as an example, the problem affects other sources and versions (at least, 4.9.2 and 4.6.4 are affected; previous versions don't include libstd++ docs). Probably the reason is incorrect configuration of Doxygen: libstdc++ sources use tab size equal to 8 spaces, and in libstdc++-v3/doc/doxygen/user.cfg.in this value is set to be equal to 4: TAB_SIZE = 4 Some parts of the library are indented using only spaces, without tabs.
[Bug c/48956] -Wconversion should warn when a complex value is assigned to a real result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48956 Mikhail Maltsev changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #11 from Mikhail Maltsev --- Proposing a new patch: https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01925.html
