Re: [PATCH] gfortran.dg/pr32627.f03 prints nul byte

2015-04-17 Thread msebor

Ping. Is this patch okay for trunk?

On 04/09/2015 03:16 PM, Martin Sebor wrote:

Attached is an updated patch that fixes the substr_6.f90
test that also prints a nul character to stdout. I don't
think there are any others.

Besides interfering with the debugging of the log corruption
I mentioned, printing nuls or control characters in tests is
also problematic for tools designed to post-process log files
(e.g., grep) that are intended to work with text files (i.e.,
files not containing nuls). Control characters can cause the
tools to fail in non-C locales (such as UTF-8).

On 04/09/2015 12:54 PM, Martin Sebor wrote:

We've been debugging a problem where nul (and other control)
characters have been randomly appearing in powerpc parallel
build logs. In the process, I noticed that some of the nuls
are readily reproducible. One such case is due to
the pr32627.f03 test which verifies that Fortran programs
can initialize character arrays from C strings. The test
declares an array as big as the C string (including the
terminating nul) and prints its value to stdout. This then
causes the nul to appear in the log files.

The attached patch changes the declaration of the Fortran
array to match the number of non-nul characters. Tested on
powerpc64.

Martin






Re: libgo patch committed: Adjust libbacktrace PC value in runtime_callers callback

2015-04-17 Thread msebor

On 04/17/2015 01:29 PM, Ian Lance Taylor wrote:

The libbacktrace library returns a PC that was (usually) decremented
to be part of the call instruction.  The Go code that uses
runtime.Callers does not expect this, and Go code that adjusts the PC
value, such as libgo/go/runtime/pprof/pprof.go, can get fooled by it.
This leads to GCC PRs 64999 and 65180.


There are a couple of bugs in libsanitizer with symptoms similar to
those noted in 65180: 65749 and the related 65479. I've been looking
into these but don't have a patch yet. What I've found is that using
the decremented PC leads to the wrong line numbers on some targets
(e.g, powerpc) while using the correct PC causes the same problem on
others (such as x86_64) as a result of differences in the DWARF line
programs emitted on these targets.

Martin



This patch from Lynn Boger adjusts the PC value so that the Go code
makes the correct adjustments.

Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline and GCC 5 branch.

Ian