[Bug c++/60277] Bogus inline function virtual ... used but never defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60277 Mikhail Maltsev maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #3 from Mikhail Maltsev maltsevm at gmail dot com --- 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 maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #2 from Mikhail Maltsev maltsevm at gmail dot com --- (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 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 maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #3 from Mikhail Maltsev maltsevm at gmail dot com --- 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 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 maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #28 from Mikhail Maltsev maltsevm at gmail dot com --- Created attachment 35455 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35455action=edit testcase, inlining This testcase marks some functions with __attribute__((always_inline/noinline)) when -DINLINE_MANUALLY is defined.
[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 maltsevm at gmail dot com --- 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 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 maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #4 from Mikhail Maltsev maltsevm at gmail dot com --- For the record. Proposed patch (also contains slightly more reduced testcase): https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01558.html
[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 maltsevm at gmail dot com changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment #1 from Mikhail Maltsev maltsevm at gmail dot com ---
Reduced testcase:
template typename class function;
template typename class _Base_manager {
public:
void _M_manager();
template typename _Tp static bool _M_not_empty_function(_Tp);
};
template typename, typename class A;
template typename _Functor, typename... _ArgTypes
class Avoid(_ArgTypes...), _Functor : public _Base_manager_Functor {};
template typename _Res, typename... _ArgTypes
class function_Res(_ArgTypes...) {
template typename, typename using _Requires = int;
public:
template typename _Functor, typename = _Requires_Functor, void
function(_Functor);
};
template typename _Res, typename... _ArgTypes
template typename _Functor, typename
function_Res(_ArgTypes...)::function(_Functor p1) {
A_Res(), _Functor::_M_not_empty_function(p1);
}
struct B {
static void do_things(functionvoid() = [] {}, functionvoid() = [] {});
};
int main() {
B::do_things();
}
[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
templateint
struct duration
{
constexpr duration() : r(0) {}
templateint TPeriod
constexpr duration(durationTPeriod x) : r(x.count()) {}
constexpr int count() { return 0; }
int r;
};
struct Config {
duration1 timeout { duration2() };
};
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 'duration1(duration2())'
./test.cc:7:58: in constexpr expansion of 'x.durationanonymous
::count2()'
./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] 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 = vecivarref_entry,va_gc Type at 0x1e59200: kind = TYPE_USER_STRUCT pointer_to = 0x1e592c0 gc_used = GC_POINTED_TO u.s.tag = vecivarref_entry,va_gc 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 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 maltsevm at gmail dot com --- Created attachment 35350 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35350action=edit Fix Just in case, I also regtested it.
[Bug pch/65550] [5 Regression] ICE (segfault) with pch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65550 --- Comment #5 from Mikhail Maltsev maltsevm at gmail dot com --- 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 maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #4 from Mikhail Maltsev maltsevm at gmail dot com --- Created attachment 35228 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35228action=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 maltsevm at gmail dot com ---
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++/65513] gcc stops with internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65513
Mikhail Maltsev maltsevm at gmail dot com changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment #2 from Mikhail Maltsev maltsevm at gmail dot com ---
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 typename _Tp struct atomic {
atomic() = default;
atomic(_Tp);
};
}
class {
public:
std::atomicbool bReadyToFlush;
}
LogThreadsleLogEntries[10]{};
[Bug c++/65503] g++ string array in struct crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65503
Mikhail Maltsev maltsevm at gmail dot com changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment #2 from Mikhail Maltsev maltsevm at gmail dot com ---
Also, I noticed that in some cases GCC is able to generate a loop for
initialization:
#include string
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 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 maltsevm at gmail dot com changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment #2 from Mikhail Maltsev maltsevm at gmail dot com ---
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 maltsevm at gmail dot com --- For the record: a patch for this PR https://gcc.gnu.org/ml/gcc-patches/2015-02/msg01067.html
[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 maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #2 from Mikhail Maltsev maltsevm at gmail dot com --- 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 maltsevm at gmail dot com changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment #3 from Mikhail Maltsev maltsevm at gmail dot com ---
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 c++/65433] ICE processing lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65433 Mikhail Maltsev maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #2 from Mikhail Maltsev maltsevm at gmail dot com --- 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 tree-optimization/65307] [4.9 Regression] Incorrect optimization breaks basic arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65307
Mikhail Maltsev maltsevm at gmail dot com changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment #8 from Mikhail Maltsev maltsevm at gmail dot com ---
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;
bb 2:
_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 maltsevm at gmail dot com changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment #2 from Mikhail Maltsev maltsevm at gmail dot com ---
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 maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #1 from Mikhail Maltsev maltsevm at gmail dot com --- 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 maltsevm at gmail dot com changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment #2 from Mikhail Maltsev maltsevm at gmail dot com ---
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 maltsevm at gmail dot com changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment #2 from Mikhail Maltsev maltsevm at gmail dot com ---
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];
cleanup_point Unknown tree: expr_stmt
(void) (struct C[1] *) struct C * D.2137;
Unknown tree: expr_stmt
(void) (D.2137 = (struct C *) cs) ;
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 D.2150;
cleanup_point Unknown tree: expr_stmt
(void) (*D.2138 = {TARGET_EXPR D.2140, Unknown tree: aggr_init_expr
4
__comp_ctor
D.2140
(struct ss *) Unknown tree: void_cst }) ;
Unknown tree: expr_stmt
(void) ++D.2138 ;
(void) --D.2139;
}
D.2150:;
Here is a backtrace which leads to construction of such expression:
#0 convert_like_real (convs=0x23f8820, expr=target_expr 0x7618b118,
fn=tree 0x0, 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=record_type
0x762d7690 ss, expr=constructor 0x762ec0d8, complain=3, flags=5) at
/home/miyuki/gcc/src/gcc/cp/call.c:9418
#2 0x00856da8 in convert_for_initialization (exp=tree 0x0,
type=record_type 0x762d7690 ss, rhs=constructor 0x762ec0d8,
flags=5, errtype=ICR_INIT, fndecl=tree 0x0, 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=tree 0x0,
type=record_type 0x762d7690 ss, rhs=constructor 0x762ec0d8,
flags=5, errtype=ICR_INIT, fndecl=tree 0x0, parmnum=0, complain=3)
at /home/miyuki/gcc/src/gcc/cp/typeck.c:8348
#6 0x0078a301 in digest_init_r (type=record_type 0x762d7690 ss,
init=constructor 0x762ec0d8, nested=true, flags=5, complain=3) at
/home/miyuki/gcc/src/gcc/cp/typeck2.c:1126
#7 0x0078a5ef in massage_init_elt (type=record_type 0x762d7690
ss, init=constructor 0x762ec0d8, complain=3) at
/home/miyuki/gcc/src/gcc/cp/typeck2.c:1190
#8 0x0078b4dd in process_init_constructor_record (type=record_type
0x762d7d20 C, init=constructor 0x762dffc0, complain=3) at
/home/miyuki/gcc/src/gcc/cp/typeck2.c:1395
#9 0x0078beb1 in process_init_constructor (type=record_type
0x762d7d20 C, init=constructor 0x762dffc0, complain=3) at
/home/miyuki/gcc/src/gcc/cp/typeck2.c:1562
#10 0x0078a159 in digest_init_r (type=record_type 0x762d7d20 C,
init=constructor 0x762dffc0, nested=false, flags=5, complain=3) at
/home/miyuki/gcc/src/gcc/cp/typeck2.c:1094
#11 0x0078a336 in digest_init (type=record_type 0x762d7d20 C,
init=constructor 0x762dffc0, complain=3) at
/home/miyuki/gcc/src/gcc/cp/typeck2.c:1133
#12 0x0086d81d in expand_default_init (binfo=tree_binfo
0x762da600, true_exp=indirect_ref 0x762ed0a0, exp=indirect_ref
0x762ed0a0, init=constructor 0x762dffc0, flags=1, complain=3)
#13 0x0086e4f3 in expand_aggr_init_1 (binfo=tree_binfo
0x762da600, true_exp=indirect_ref 0x762ed0a0, exp=indirect_ref
0x762ed0a0, init=constructor 0x762dffc0, flags=1, complain=3)
at /home/miyuki/gcc/src/gcc/cp/init.c:1830
#14 0x0086d431 in build_aggr_init (exp=indirect_ref 0x762ed0a0,
init=constructor 0x762dffc0, flags=0, complain=3) at
/home/miyuki/gcc/src/gcc/cp/init.c:1582
#15 0x0087493d in build_vec_init (base=var_decl 0x762eb120,
maxindex=integer_cst 0x762dffd8, init=constructor 0x762dffc0,
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=var_decl 0x762eb000 cs,
init=constructor 0x762dffc0, flags=2049, complain=3) at
/home/miyuki/gcc/src/gcc/cp/init.c:1563
#17 0x006e192d in build_aggr_init_full_exprs (decl=var_decl
0x762eb000 cs, init=constructor 0x762dffc0, 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 constructor 0x762dffc0) as the whole
[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
templateint N
struct array
{
int data[N];
};
templatetemplatetypename class... T1, typename T2
arraysizeof...(T1) make_array(T1T2 ...init)
{
return { 0 };
}
templatetypename T
struct S
{
T a;
};
auto arr = make_array(Sint{1});
==
miyuki@gcc-devel2:~/gcc/test/ice_sizeof$ ../../obj/gcc/cc1plus -std=c++11
ice_sizeof.cc bug_report.txt; cat bug_report.txt
arraysizeof... (T1) make_array(T1T2...) arraysizeof... (T1)
make_array(T1T2...) [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 'arraysizeof... (T1) make_array(T1T2...)
[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
arraysizeof...(T1) make_array(T1T2 ...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
arraysizeof...(T1) make_array(T1T2 ...init)
clang-3.7 compiles the file without errors.
Changing the declaration to
auto make_array_ice(T1T2 ...init) - arraysizeof...(T1)
does not change the behavior, but
auto make_array_ice(T1T2 ...init) - arraysizeof...(init)
gets compiled without errors by all 3 mentioned versions of g++.
[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 maltsevm at gmail dot com ---
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
templateint struct S { };
templatetemplateint class... T, int N
Ssizeof...(T) foo(TN...);
auto x = foo(S2{});
==
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 TN...), 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 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 maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #18 from Mikhail Maltsev maltsevm at gmail dot com --- 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 maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #1 from Mikhail Maltsev maltsevm at gmail dot com --- 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 maltsevm at gmail dot com ---
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 stdint.h
#include stdlib.h
#include stdio.h
#include linux/icmpv6.h
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 maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #5 from Mikhail Maltsev maltsevm at gmail dot com --- (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 c/64639] false negative of -Wunused-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64639 Mikhail Maltsev maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #5 from Mikhail Maltsev maltsevm at gmail dot com --- 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 libgcc/64677] incorrect result with complex division?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64677 --- Comment #10 from Mikhail Maltsev maltsevm at gmail dot com --- 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++/64677] incorrect result with complex division?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64677 Mikhail Maltsev maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #3 from Mikhail Maltsev maltsevm at gmail dot com --- 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 c/64619] No -Wsign-conversion warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64619
Mikhail Maltsev maltsevm at gmail dot com changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment #1 from Mikhail Maltsev maltsevm at gmail dot com ---
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 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 maltsevm at gmail dot com changed:
What|Removed |Added
CC||maltsevm at gmail dot com
--- Comment #3 from Mikhail Maltsev maltsevm at gmail dot com ---
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 maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #2 from Mikhail Maltsev maltsevm at gmail dot com --- 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 maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #4 from Mikhail Maltsev maltsevm at gmail dot com --- 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 maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #11 from Mikhail Maltsev maltsevm at gmail dot com --- Proposing a new patch: https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01925.html
