Bug maintenance
As part of the work I've done on inline asm, I've been looking thru the bugs for it. There appear to be a number that have been fixed or overtaken by events over the years, but the bug is still open. Is closing some of these old bugs of any value? If so, how do I pursue this? dw
Re: Bug maintenance
On Thu, Apr 28, 2016 at 9:35 AM, David Wohlferd wrote: > As part of the work I've done on inline asm, I've been looking thru the bugs > for it. There appear to be a number that have been fixed or overtaken by > events over the years, but the bug is still open. > > Is closing some of these old bugs of any value? Yes, definitely. > If so, how do I pursue this? I suppose adding a final comment to them will work, people (like me) watching gcc-bugs can then do the actual closing. Richard. > dw >
Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64 - LTP results
Hi, Andrew
On 2016/4/28 5:15, Andrew Pinski wrote:
On Wed, Apr 27, 2016 at 12:30 AM, Andrew Pinski wrote:
On Fri, Apr 22, 2016 at 8:37 PM, Zhangjian (Bamvor)
wrote:
Hi, Yury
On 2016/4/6 6:44, Yury Norov wrote:
There are about 20 failing tests of 782 in lite scenario.
float_bessel
float_exp_log
float_iperb
float_power
float_trigo
pipeio_1
pipeio_3
pipeio_5
pipeio_8
abort01
clone02
kill11
mmap16
open12
pause01
rename11
rmdir02
umount2_01
umount2_02
umount2_03
utime06
mtest06
The list is rough because some tests fail not every time.
Tests abort01 and kill11 fail for lp64 too, so maybe there's
a reason unrelated to ilp32 itself.
float_xxx tests fail because they call unwind() from signal context,
and GCC for ilp32 has problem with it, as Andrew told.
Is there some progress about this issue. When we talk about unwind
functions, do you mean the function in libgcc?
We encountered another issue(abort not segfault) which also called
pthread_cancel(). The test code is in the attachment. Here is the
backtrace:
Yes this was a known issue I knew about. I have a patch GCC to fix
this. Basically REG_VALUE_IN_UNWIND_CONTEXT needs to be defined while
building libgcc to support the correct unwind information.
I will be posting a GCC patch to fix this tomorrow. This was a bug
even in the original set of ilp32 patches. I only finally was able to
sit down and fix it today.
Here is the link to the GCC patch which I said was going to submit today:
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01726.html
It works for me. Both float_xx in ltp and my pthread_cancel testcase is
pass.
Regards
Bamvor
Thanks,
Andrew
Thanks,
Andrew
```
Program received signal SIGABRT, Aborted.
[Switching to Thread 0xf77ee330 (LWP 2958)]
0x0040f5bc in raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:55
55 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x0040f5bc in raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:55
#1 0x0040f884 in abort () at abort.c:89
#2 0x004073b4 in uw_update_context_1 (
context=context@entry=0xf77ec820, fs=fs@entry=0xf77ebec8)
at /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind-dw2.c:1430
#3 0x004078c0 in uw_update_context
(context=context@entry=0xf77ec820,
fs=fs@entry=0xf77ebec8)
at
/home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind-dw2.c:1506
#4 0x00407a9c in uw_advance_context (fs=0xf77ebec8,
context=0xf77ec820)
at
/home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind-dw2.c:1529
#5 _Unwind_ForcedUnwind_Phase2 (exc=exc@entry=0xf77ee580,
context=context@entry=0xf77ec820)
at /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind.inc:185
#6 0x00408228 in _Unwind_ForcedUnwind (exc=0xf77ee580,
stop=stop@entry=0x405440 , stop_argument=0xf77eddd8)
at /home/GCC-Build/p660/p660_build_dir/src/gcc-4.9/libgcc/unwind.inc:207
#7 0x004055c4 in __pthread_unwind (buf=)
at unwind.c:126
#8 0x004050b4 in __do_cancel () at ./pthreadP.h:283
#9 sigcancel_handler (sig=, si=,
ctx=) at nptl-init.c:225
---Type to continue, or q to quit---
#10
#11 0x in ?? ()
#12 0x00423084 in __select (nfds=-1, readfds=,
writefds=, exceptfds=, timeout=0x0)
at ../sysdeps/unix/sysv/linux/generic/select.c:45
#13 0x00400604 in TEST_TaskDelay (
uiMillSecs=)
at test-cancel.c:18
#14 0x00400680 in printids (
s=)
at test-cancel.c:38
#15 0x004006d0 in thr_fn (
arg=)
at test-cancel.c:49
#16 0x00401b28 in start_thread (arg=0x4a3000) at
pthread_create.c:335
#17 0x00401b28 in start_thread (arg=0x4a3000) at
pthread_create.c:335
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
```
Such abort is raise by the following code:
```
static void
uw_update_context_1 (struct _Unwind_Context *context, _Unwind_FrameState
*fs)
{
//...
/* Compute this frame's CFA. */
switch (fs->regs.cfa_how)
{
case CFA_REG_OFFSET:
cfa = _Unwind_GetPtr (&orig_context, fs->regs.cfa_reg);
cfa += fs->regs.cfa_offset;
break;
case CFA_EXP:
{
const unsigned char *exp = fs->regs.cfa_exp;
_uleb128_t len;
exp = read_uleb128 (exp, &len);
cfa = (void *) (_Unwind_Ptr)
execute_stack_op (exp, exp + len, &orig_context, 0);
break;
}
default:
gcc_unreachable ();
}
context->cfa = cfa;
//...
}
``
Any suggestion is appreciated.
CC gcc mailing list. Sorry if it is off topic.
Regards
Bamvor
pipeio_x tests are very unstable and may fail randomly. I strongly
suspect race conditions, as they all work like a charm if pinned to
single CPU with taskset. Probably, race is the reason of clone02 too.
Though I'm not sure, is the race in kernel, glibc or test itself.
But I know for sure tha
Re: Bug maintenance
On 04/28/2016 01:35 AM, David Wohlferd wrote: As part of the work I've done on inline asm, I've been looking thru the bugs for it. There appear to be a number that have been fixed or overtaken by events over the years, but the bug is still open. Is closing some of these old bugs of any value? If so, how do I pursue this? There are nearly 10,000 still unresolved bugs in Bugzilla, almost half of which are New, and a third Unconfirmed, so I'm sure any effort to help reduce the number is of value and appreciated. I can share with you my own approach to dealing with them (others might have better suggestions). In cases where the commit that fixed a bug is known, I mention it in the comment closing the bug. I also try to indicate the version in which the bug was fixed (if I can determine it using the limited number of versions I have built). Otherwise, when a test doesn't already exist (finding out whether or not one does can be tedious), I add one before closing the bug will help avoid a regression. Martin
Re: Bug maintenance
On Thu, Apr 28, 2016 at 12:35 AM, David Wohlferd wrote: > As part of the work I've done on inline asm, I've been looking thru the bugs > for it. There appear to be a number that have been fixed or overtaken by > events over the years, but the bug is still open. > > Is closing some of these old bugs of any value? Yes it is. In fact this is how I got my start into GCC. > > If so, how do I pursue this? If you go through the bug reports and have a low rate of false positives, I (and others) can get you permission to change the bug reports (I started out with a bug report only account too). Thanks, Andrew Pinski > > dw >
relying on static_assert to test constexpr changes
Many GCC tests for constexpr rely on static_assert to verify things
work correctly. While testing some changes of my own, I was surprised
to find the static_asserts pass even though my changes did not (see
below). It took me a while to realize that, and it took printing
the computed constant values via printf() to see they were wrong.
Even a runtime assert() didn't uncover the bug (see below). After
thinking about it a bit, it makes sense that using the tool under
test to verify its own correctness isn't the most reliable way to
do it. I've seen it before when testing other software, but it was
eye opening none-the-less to see it happen with a compiler. Enough
that I think it's worthwhile to share it here.
Martin
$ cat builtin_constexpr.cpp && /home/msebor/build/gcc-70507/gcc/xgcc
-B/home/msebor/build/gcc-70507/gcc -Wall -Wextra -Wpedantic
builtin_constexpr.cpp && ./a.out
constexpr int f (int x, int y)
{
int z = 0;
__builtin_add_overflow (x, y, &z);
return z;
}
constexpr int z = f (12, 34);
int main ()
{
static_assert (z == (123 + 456), "z == (123 + 456)"); // passes
__builtin_printf ("z = %i\n", z);
if (z != (123 + 456)) // passes too
__builtin_abort ();
}
z = 0 << yet the output is zero!
Re: relying on static_assert to test constexpr changes
On Thu, Apr 28, 2016 at 2:49 PM, Martin Sebor wrote:
> Many GCC tests for constexpr rely on static_assert to verify things
> work correctly. While testing some changes of my own, I was surprised
> to find the static_asserts pass even though my changes did not (see
> below). It took me a while to realize that, and it took printing
> the computed constant values via printf() to see they were wrong.
> Even a runtime assert() didn't uncover the bug (see below). After
> thinking about it a bit, it makes sense that using the tool under
> test to verify its own correctness isn't the most reliable way to
> do it. I've seen it before when testing other software, but it was
> eye opening none-the-less to see it happen with a compiler. Enough
> that I think it's worthwhile to share it here.
>
> Martin
>
> $ cat builtin_constexpr.cpp && /home/msebor/build/gcc-70507/gcc/xgcc
> -B/home/msebor/build/gcc-70507/gcc -Wall -Wextra -Wpedantic
> builtin_constexpr.cpp && ./a.out
> constexpr int f (int x, int y)
> {
> int z = 0;
> __builtin_add_overflow (x, y, &z);
> return z;
> }
>
> constexpr int z = f (12, 34);
>
> int main ()
> {
> static_assert (z == (123 + 456), "z == (123 + 456)"); // passes
>
> __builtin_printf ("z = %i\n", z);
>
> if (z != (123 + 456)) // passes too
> __builtin_abort ();
> }
>
> z = 0 << yet the output is zero!
How about this doing something like this:
int main ()
{
int z1 = *(volatile int*)&z;
if (z1 != (123 + 456)) // passes too
__builtin_abort ();
}
Does the above pass now?
Re: relying on static_assert to test constexpr changes
On 04/28/2016 03:54 PM, Andrew Pinski wrote:
On Thu, Apr 28, 2016 at 2:49 PM, Martin Sebor wrote:
Many GCC tests for constexpr rely on static_assert to verify things
work correctly. While testing some changes of my own, I was surprised
to find the static_asserts pass even though my changes did not (see
below). It took me a while to realize that, and it took printing
the computed constant values via printf() to see they were wrong.
Even a runtime assert() didn't uncover the bug (see below). After
thinking about it a bit, it makes sense that using the tool under
test to verify its own correctness isn't the most reliable way to
do it. I've seen it before when testing other software, but it was
eye opening none-the-less to see it happen with a compiler. Enough
that I think it's worthwhile to share it here.
Martin
$ cat builtin_constexpr.cpp && /home/msebor/build/gcc-70507/gcc/xgcc
-B/home/msebor/build/gcc-70507/gcc -Wall -Wextra -Wpedantic
builtin_constexpr.cpp && ./a.out
constexpr int f (int x, int y)
{
int z = 0;
__builtin_add_overflow (x, y, &z);
return z;
}
constexpr int z = f (12, 34);
int main ()
{
static_assert (z == (123 + 456), "z == (123 + 456)"); // passes
__builtin_printf ("z = %i\n", z);
if (z != (123 + 456)) // passes too
__builtin_abort ();
}
z = 0 << yet the output is zero!
How about this doing something like this:
int main ()
{
int z1 = *(volatile int*)&z;
if (z1 != (123 + 456)) // passes too
__builtin_abort ();
}
Does the above pass now?
Yes, I think that should work. I'm hoping for a solution that
doesn't require linking and running the tests. The approach
you suggest and scanning the tree dump(s) for abort might be
the way to go.
Martin
gcc-6-20160428 is now available
Snapshot gcc-6-20160428 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160428/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch revision 235615 You'll find: gcc-6-20160428.tar.bz2 Complete GCC MD5=33ac62e7bd0a5d1071711c3779f7c977 SHA1=ffe4e2f809dea7870f0b3b1bd44a30a9b098618a Diffs from 6-20160421 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
