[Bug debug/90674] [7.1 Regression] ICE in gen_subprogram_die
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90674
--- Comment #1 from Sergey Barannikov ---
Can be further simplified to just
template
struct C {
C() {}
};
template<>
C::C() = default;
with the same result.
[Bug debug/90674] New: [7.1 Regression] ICE in gen_subprogram_die
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90674
Bug ID: 90674
Summary: [7.1 Regression] ICE in gen_subprogram_die
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: barannikov88 at gmail dot com
Target Milestone: ---
Thie is a regression introduced in 7.1.
$ cat test.cpp
#include
struct Base {
virtual ~Base() = default;
};
template
struct Derived : Base {
Derived() {
std::printf("Derived::Derived()\n");
}
};
template<>
Derived::Derived();
extern template class Derived;
template class Derived;
template<>
Derived::Derived() = default;
$ g++ -g test.cpp
test.cpp: In constructor ‘Derived::Derived() [with T = int]’:
test.cpp:22:34: internal compiler error: in gen_subprogram_die, at
dwarf2out.c:22966
Derived::Derived() = default;
^
[Bug libquadmath/87204] New: strtoflt128 produces different results for subnormals with -m32 and -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87204
Bug ID: 87204
Summary: strtoflt128 produces different results for subnormals
with -m32 and -m64
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libquadmath
Assignee: unassigned at gcc dot gnu.org
Reporter: barannikov88 at gmail dot com
Target Milestone: ---
The testcase:
#include
#include
#include
int main ()
{
union {
__float128 f;
uint64_t i64[2];
} u = { .f = strtoflt128("1e-4941", NULL) };
printf("%016" PRIx64 " %016" PRIx64 "\n", u.i64[1], u.i64[0]);
}
$ gcc-7.3.0 t.c -lquadmath -lm -m32 && a.out
00014707 e947d757fbf6f700
$ gcc-7.3.0 t.c -lquadmath -lm -m64 && a.out
00014707 e946d257f2f674b9
The output is for x86-64, haven't tested for other platforms.
[Bug libstdc++/84170] New: std::find_if performance issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84170
Bug ID: 84170
Summary: std::find_if performance issues
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: barannikov88 at gmail dot com
Target Milestone: ---
Hi,
There are two internal implementations of std::find_if in bits/stl_algo.h. One
is for the input iterator case, the other is for the random access iterator
case. They are almost identical, except that the second is somewhat
"optimized".
> /// This is an overload used by find algos for the Input Iterator case.
> template
>inline _InputIterator
>__find_if(_InputIterator __first, _InputIterator __last,
> _Predicate __pred, input_iterator_tag)
>{
> while (__first != __last && !__pred(__first))
> ++__first;
> return __first;
>}
>
> /// This is an overload used by find algos for the RAI case.
> template
>_RandomAccessIterator
>__find_if(_RandomAccessIterator __first, _RandomAccessIterator __last,
> _Predicate __pred, random_access_iterator_tag)
>{
> typename iterator_traits<_RandomAccessIterator>::difference_type
> __trip_count = (__last - __first) >> 2;
>
> for (; __trip_count > 0; --__trip_count)
> {
> if (__pred(__first))
> return __first;
> ++__first;
>
> if (__pred(__first))
> return __first;
> ++__first;
>
> if (__pred(__first))
> return __first;
> ++__first;
>
> if (__pred(__first))
> return __first;
> ++__first;
> }
>
> switch (__last - __first)
> {
> case 3:
> if (__pred(__first))
> return __first;
> ++__first;
> case 2:
> if (__pred(__first))
> return __first;
> ++__first;
> case 1:
> if (__pred(__first))
> return __first;
> ++__first;
> case 0:
> default:
> return __last;
> }
>}
Manual unrolling increases the code size and reduces the chances of this
function to be inlined. Inlining of this function is critical because it can
contain indirect calls to the predicate function, and inlining can change this
calls to direct improving performance.
I would suggest to revert manual unrolling and let the compiler decide which
optimization steps should be taken.
[Bug c/79942] New: Wrong declaration of __builtin_cpu_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79942
Bug ID: 79942
Summary: Wrong declaration of __builtin_cpu_init
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: barannikov88 at gmail dot com
Target Milestone: ---
According to documentation, __builtin_cpu_init has return type 'void', but is
created as returning 'int'.
gcc/config/i386/i386.c
static void
ix86_init_platform_type_builtins (void)
{
make_cpu_type_builtin ("__builtin_cpu_init", IX86_BUILTIN_CPU_INIT,
INT_FTYPE_VOID, false);
make_cpu_type_builtin ("__builtin_cpu_is", IX86_BUILTIN_CPU_IS,
INT_FTYPE_PCCHAR, true);
make_cpu_type_builtin ("__builtin_cpu_supports", IX86_BUILTIN_CPU_SUPPORTS,
INT_FTYPE_PCCHAR, true);
}
This is probably a typo.
[Bug c++/55918] Stack partially unwound when noexcept causes call to std::terminate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55918
Sergey Barannikov changed:
What|Removed |Added
CC||barannikov88 at gmail dot com
--- Comment #4 from Sergey Barannikov ---
This is the ABI problem. The search phase of the unwinding process cannot
distinguish between a case when a true handler found and a case when the search
process should stop, because it has reached a call site that must not pass the
exception through. In both cases _URC_HANDLER_FOUND is returned by the
personality routine, and the second phase of the unwinding process begins (the
actual unwinding).
There is another problem in LSDA format (in action table format to be precise).
Consider the following example:
void bad_guy() noexcept {
try {
Foo foo;
throw 0;
} catch (float) {
// Don't catch int.
}
}
void level1() {
bad_guy();
throw "dead code";
}
int main() {
try {
level1();
} catch (const char *) {
}
}
When you compile and run it you get:
Foo::Foo()
terminate called after throwing an instance of 'int'
Aborted (core dumped)
It works as expected. But (the funny thing) if you change "catch (const char
*)" in main to "catch (int)", you will get this:
Foo::Foo()
Foo::~Foo()
terminate called without an active exception
Aborted (core dumped)
This is because there is currently no way to represent a "Terminate" action in
the action table of LSDA. gcc represents it as a simply cleanup action, that
means that the unwinder does not stop at a noexcept function and continues
searching for a handler up the stack.
In the original example there is no handler for the exception thrown, and the
runtime terminates the program instantly (no stack unwinding done). When one
changes "catch (const char *)" to "catch (int)", the unwinder finds this
handler at the search phase and launches the second, unwinding, phase. The
unwinding process then destroys the local object "foo", checks the exception
type for matching "float", and falls into the code that calls std::terminate
when the matching fails. Since there is no __cxa_begin_catch prior to
std::terminate, we get the error message "terminate called without an active
exception" instead of correct "terminate called after throwing an instance of
'int'".
[Bug libstdc++/71434] New: binomial_distribution operator(): using uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71434 Bug ID: 71434 Summary: binomial_distribution operator(): using uninitialized variable Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: barannikov88 at gmail dot com Target Milestone: --- The variable __x declared at line 1699 of file libstdc++-v3/include/bits/random.tcc may be used uninitialized. This happens when the following conditions are met: __u <= __a1 (line 1724) __y >= __param._M_d1 (line 1728) When both conditions are TRUE, the variable __x is used uninitialized at line 1782: __reject |= __x + __np >= __thr; Seems that it is assumed that __x has a meaningful value only when __reject == FALSE (other uses of __x are under this condition). If __reject is TRUE, then the value of the variable __x doesn't matter: __reject will remain TRUE. But __x is used unconditionally it this context, that leads to execution error on a machine with tagged architecture (this is how I found it). This line should be rewritten as: __reject = __reject || __x + __np >= __thr; (note that if __reject is TRUE, the variable __x is not used.) This applies to all versions of libstdc++. Line numbers provided are for gcc-5.1.
[Bug inline-asm/67448] compiler crash#inline assembly#rvalue operand with constraint "m"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67448 Sergey Barannikov changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #5 from Sergey Barannikov --- Thanks
[Bug c/67448] New: compiler crash#inline assembly#rvalue operand with constraint "m"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67448
Bug ID: 67448
Summary: compiler crash#inline assembly#rvalue operand with
constraint "m"
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: barannikov88 at gmail dot com
Target Milestone: ---
$ cat t1.c
void f(int i)
{
__asm("" : : "m"(i += 1));
}
$gcc t1.c -S
t1.c: In function 'f':
t1.c:3:24: internal compiler error: in expand_gimple_stmt_1, at
cfgexpand.c:3391
__asm("" : : "m"(i += 1));
^
0x82b4249 expand_gimple_stmt_1
../../gcc-5.1.0.src/gcc/cfgexpand.c:3390
0x82b4249 expand_gimple_stmt
../../gcc-5.1.0.src/gcc/cfgexpand.c:3497
0x82b7746 expand_gimple_basic_block
../../gcc-5.1.0.src/gcc/cfgexpand.c:5509
0x82b9356 execute
../../gcc-5.1.0.src/gcc/cfgexpand.c:6127
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.
The operand is an rvalue and should be restricted from using within this
context, like 'i++' is. Strangely enough, 'i = 0' is allowed despite of the
fact that it is also an rvalue.
