Julian Seward [Thu, 31 May 2018 15:03:08 +0000 (17:03 +0200)]
arm64-linux: VG_(sigframe_destroy): restore int regs, PC and SP from the sigcontext previously presented to the handler. n-i-bz.
So as to correctly (well, less incorrectly) simulate handlers that change
register state in the sigcontext they are given in the expectation that the
change will take effect immediately upon the handler returning.
http://kcachegrind.sourceforge.net/cgi-bin/show.cgi/KcacheGrindIndex
page indicates to rather go to
https://kcachegrind.github.io/html/Home.html
so update the doc accordingly.
callgrind: fix setting call counter to zero if requested
We did not set the call cost counters in CLG_(zero_bbcc) to zero,
which gets called by requests to set counters to zero
- via client request
- when entering a function if configured so
- via gdb monitor command (used by callgrind_control -z)
Counters are also set to zero after they are dumped out to a file.
This does not use CLG_(zero_bbcc), and was doing the right thing.
Julian Seward [Sat, 5 May 2018 08:03:26 +0000 (10:03 +0200)]
emit_ARM64Instr: fix assertion failures associated with chaining patching (ARM64in_XDirect). n-i-bz.
This has happened because (I think!) this has never before been tested with
guest code addresses >= 2^48. This in turn means that this is the first
time that
p = imm64_to_ireg(p, /*x*/9, i->ARM64in.XDirect.dstGA);
has been called upon to emit a constant which is non-zero in all four 16-bit
chunks, so it generates 4 instructions rather than (at most, in all previous
runs) 3, and so the "how many insns at max" assertions failed. This commit
fixes the assertions.
Skip the phdrs when we have to search the shdrs. In separate
.debug files the phdrs might not be valid (they are a copy of
the main ELF file) and might trigger assertions when getting
image notes based on them.
Fix 393023 - callgrind_control risks using the wrong vgdb
Search for a vgdb executable in the same dir as callgrind_control perl file.
If not found, search for a vgdb executable in a sibling coregrind dir
(covers the case of : perl callgrind/callgrind_control)
Otherwise, just hope we find a vgdb executable in PATH
Carl Love [Wed, 11 Apr 2018 19:03:29 +0000 (14:03 -0500)]
Fix 393017 - Add missing support for xsmaxcdp instruction, bug fixes for xsm
Missed the update to none/tests/ppc64/Makefile.am to remove the
expected output files test_isa_3_0_altivec.stdout.exp and
test_isa_3_0_other.stdout.exp.
Carl Love [Wed, 11 Apr 2018 17:51:21 +0000 (12:51 -0500)]
Fix 393017 - Add missing support for xsmaxcdp instruction, bug fixes for xsmincdp, lxssp, stxssp and stxvl instructions.
Add support for instruction xsmaxcdp in VEX/priv/guest_ppc_toIR.c.
Fixes in file VEX/priv/guest_ppc_toIR.c for xsmaxcdp, xsmincdp, lxssp,
stxssp and stxvl instructions.
Fix compiler issues with optimization option -O2 for test
none/tests/ppc64/test_isa_3_0.c.
Add test case test_xsmaxcdpi to test file none/tests/ppc64/test_isa_3_0.c.
Fixes to test none/tests/ppc64/test_isa_3_0.c for compiling inline functions
with optimization -O0. Assembly instruction fixes, test argument array size
fixes, max loop index fixes. Condition code register fixes to fix control
flow issues when compiled with optimization.
Update expected results for test_isa_3_0_altivec.stdout.exp-LE and
test_isa_3_0_other.stdout.exp-LE.
Petar Jovanovic [Tue, 10 Apr 2018 12:09:08 +0000 (14:09 +0200)]
Introduce RegWord type
On majority of architectures size of long matches register width.
On mips n32 size of long is 32 bits and register width is 64 bits.
Valgrind is written with assumption that long size matches register
width. This is the reason why both UWord for Valgrind and HWord for VEX
match size of long. Long size differs from register size on mips n32 ABI.
Introducing RegWord type that will match size of registers.
Part of the changes required for BZ issue - #345763.
Contributed by:
Tamara Vlahovic and Dimitrije Nikolic.
Petar Jovanovic [Wed, 4 Apr 2018 09:51:05 +0000 (11:51 +0200)]
mips64: use register numbers instead of aliases for inline assembly
There is an inconsistency in MIPS tools for N32/N64 related to register
aliases. To avoid ambiguity, use register numbers instead of aliases where
needed.
n-i-bz Fix possible stack trashing by semctl syscall wrapping
The modified test none/tests/sem crashes with a SEGV when valgrind is compiled
with lto on various amd64 platforms (debian/gcc 6.3, RHEL7/gcc 6.4,
Ubuntu/gcc 7.2)
The problem is that the vki_semid_ds buf is not what is expected by the kernel:
the kernel expects a bigger structure vki_semid64_ds (at least on
these platforms).
Getting the sem_nsems seems to work by chance, as sem_nsems is at
the same offset in both vki_semid_ds and vki_semid64_ds.
However, e.g. the ctime was not set properly after syscall return,
and 2 words after sem_nsems were set to 0 by the kernel, causing
the SEGV, as a spilled register became 0.
Fix consists in using the 64 bit version for __NR_semctl.
Tested on debian/amd64 and s390x.
Sometimes, at least on arm platforms, we get a stack trace with
only one function.
When this happens and massif removes the top fn, we end up trying
to create an execontext of 0 ips, as the only fn is removed,
and an execontext of 0 ips causes the assert in m_execontext.c
So, do whatever to avoid to crash when having a single fn stacktrace.
The whatever means use a null execontext, which is an execontext
of one single address 0x0.
Note that this is just to bypass the crash.
What is shown by massif is not very nice (but what could we show ?).
Note that instead of using such a null execontext, we could rather
just keep the single ips. But that might create a lot of single fn
entries in the xtree and/or show undesired functions.
So, we the null execontext, which is shown as 0xFFFFFFFFFFFFFFFF ???
in the massif output.
Tested on amd64 by artificially creating stacktrace of one fn.
Fix 338252 - building valgrind with -flto (link time optimisation) fails
* Addition of a new configure option --enable-lto=yes or --enable-lto=no
Default value is --enable-lto=no, as the build is significantly slower,
so is not appropriate for valgrind development : this should be used
only on buildbots and/or by packagers.
* Some files containins asm functions have to be compiled without lto:
coregrind/m_libcsetjmp.c
coregrind/m_main.c
If these are compiled with lto, that gives undefined symbols at link time.
The files to compile without lto are
coregrind/m_libcsetjmp.c
coregrind/m_main.c
To compile these files with other options, a noinst target lib is defined.
The objects of this library are then added to the libcoregrind.
* memcheck/mc_main.c : move the handwritten asm helpers to mc_main_asm.c.
This avoids undefined symbols on some toolchains. Due to this,
the preprocessor symbols that activate the fast or asm memcheck helpers
are moved to mc_include.h
Platforms with handwritten helpers will also have the memcheck primary
map defined non static.
* In VEX, auxprogs/genoffsets.c also has to be compiled without lto,
as the asm produced by the compiler is post-processed to produce
pub/libvex_guest_offsets.h. lto not producing asm means the generation
fails if we used -flto to compile this file.
* all the various Makefile*am are modified to use LTO_CFLAGS for
(most) targets. LTO_CFLAGS is empty when --enable-lto=no,
otherwise is set to the flags needed for gcc.
If --enable-lto=no, LTO_AR and LTO_RANLIB are the standard AR and RANLIB,
otherwise they are the lto capable versions (gcc-ar and gcc-ranlib).
* This has been tested on:
debian 9.4/gcc 6.3.0/amd64+x86
rhel 7.4/gcc 6.4.0/amd64
ubuntu 17.10/gcc 7.2.0/amd64+x86
fedora26/gcc 7.3.1/s390x
Bart Van Assche [Thu, 8 Mar 2018 20:57:41 +0000 (12:57 -0800)]
Linux: Add support for the zoned block device ioctls
Shingled magnetic recording drives support a command set called ZBC
(Zoned Block Commands). Two new ioctls have been added to the Linux
kernel to support such drives, namely VKI_BLKREPORTZONE and
VKI_BLKRESETZONE. Add support to Valgrind for these ioctls.
Julian Seward [Fri, 9 Mar 2018 18:03:26 +0000 (19:03 +0100)]
coregrind/m_debuglog.c: fix incorrect inline assembly for amd64-linux.
This adds rcx and r11 to the trash lists for inline assembly in
local_sys_write_stderr and local_sys_getpid, since those registers are not
preserved across the embedded syscall that takes us into the kernel. I
believe this to be the root cause of the apparent code generation bug
addressed in 53faacfda4ad6a27bc0e8ab859c1cc5388a61a5e (16 Nov 2017). This
commit also undoes that commit, because I think it is no longer necessary.
Carl Love [Thu, 1 Mar 2018 19:50:56 +0000 (13:50 -0600)]
PPC64, Fix tests for mtvsrwa and mtfprd.
Fix the register constraints for the vtvsrwa and mtfprd instructions
in test_isa_2_07_part2.c. Update the expected output in
none/tests/jm_vec_isa_2_07.stdout.exp.
Carl Love [Tue, 27 Feb 2018 18:41:43 +0000 (12:41 -0600)]
Bug 391164: constraint bug in tests/ppc64/test_isa_2_07_part1.c for mtfprwa
Fix destination register constraint in assembly code in function
test_mtfprwa in file none/tests/ppc64/test_isa_2_07_part1.c. Constraint
changed from "=ws" to "=d".
Handle properly the case of an inlined call that has no abstract origin attribute.
Normally, an inlined call has a dwarf entry that points at the abstract origin, i.e. the
function that was inlined.
However, in some cases, the abstract origin tag is not present (observed with gcc 6.3.0, when
compiling with link time optimisation).
Such missing abstract origin was then causing an error message when reading the dwarf debug info.
This patch ensures we handle this case more gracefully, by using UnknownInlinedFun as inlined
function name for such a missing abstract origin;
Julian Seward [Fri, 16 Feb 2018 07:02:00 +0000 (08:02 +0100)]
Bug 384930 - Valgrind fails to compute correctly some code using the GMP library.
For the ADCX and ADOX instructions, the VEX front end failed to create a PUT to
the result register in the case where one of the operands is from memory, for
example in
adoxq 48(%rdi),%r12
where %r12 is never written. This commit fixes it.
Julian Seward [Tue, 6 Feb 2018 11:54:03 +0000 (12:54 +0100)]
Bug 384631 - Sanitise client args as printed with -v
umsg_arg, xml_arg: sanitise the guest's command line arguments that we print
in a "Command: " line as part of the preamble, when -v is given. This
changes any character outside the range 32 .. 127 to '_'. Printing
unsanitised command line args has been observed to cause xfce4-terminal to
assert. Of course the command line args actually given to the guest aren't
changed -- this just changes how they are printed.
Petar Jovanovic [Sat, 3 Feb 2018 22:28:30 +0000 (23:28 +0100)]
mips: remove several compiler warnings
A few warnings have showed up with recent changes on trunk:
warning: parameter names (without types) in function declaration
warning: no previous prototype for 'showRotxOp'
warning: unused variable 'src1' [-Wunused-variable]
Fixing it.
Thanks Paul Floyd for reporting one of the issues.
Mark Wielaard [Thu, 18 Jan 2018 10:28:11 +0000 (11:28 +0100)]
Don't cast an initializer to the struct type in power_insn_available.c.
In C99 mode casting the initializer to the struct type will cause gcc
to report an error like:
power_insn_available.c:38:1: error: initializer element is not constant
Simply removing the unnecessary cast fixes this (and is also valid C90).
Mark Wielaard [Wed, 17 Jan 2018 12:30:35 +0000 (13:30 +0100)]
Make sure we can compile in C99 mode.
Use AC_PROG_CC_C99 in configure.ac to make sure the compiler we use is
always in C99 mode. If we detect the compiler doesn't support C99 then
error out.
Julian Seward [Mon, 15 Jan 2018 10:25:12 +0000 (11:25 +0100)]
Bug 79362 - Debug info is lost for .so files when they are dlclose'd. Followup fix to avoid assertion failure when dlopening an object that has previously been dlclosed.
As reported by Matthias Schwarzott <zzam@gentoo.org>. Testcase patch from him. The fix is
for check_CFSI_related_invariants() to avoid checking for overlaps against DebugInfos that are
in 'archived' status, since -- if a previously dlopened-and-then-dlclosed object is later
re-dlopened -- this may cause an overlap between the active and archived DebugInfos, which
is of no consequence. If the kernel maps the object to the same VMA the second time around
then there will *certainly* be an overlap.
Petar Jovanovic [Fri, 12 Jan 2018 17:15:36 +0000 (18:15 +0100)]
mips: fix build failure introduced with "Bug 79362 - Debug info ..."
Previous commit (cceed053ce876560b9a7512125dd93c7fa059778) broke the build
for MIPS architecture.
Update the code in VG_(get_StackTrace_wrk) to reflect the changes made in
the previous commit.
Julian Seward [Thu, 11 Jan 2018 17:20:27 +0000 (18:20 +0100)]
Bug 385408 - s390x: z13 vector "support" instructions not implemented. Patch from Vadim Barkov (vbrkov@gmail.com).
(from bug 385408 comment 0):
Valgrind currently lacks support for the z/Architecture vector "support"
instructions introduced with z13. These are documented in the
z/Architecture Principles of Operation, Eleventh Edition (March, 2015),
chapter 21: "Vector Overview and Support Instructions".
Julian Seward [Wed, 3 Jan 2018 10:55:44 +0000 (11:55 +0100)]
Fix memcheck/tests/vbit-test (the vbit test program) to track changes in bug 387664.
Bug 387664 changes the default settings for accurate definedness checking
for {Add,Sub}{32,64} and {CmpEQ,CmpNE}{8,16,32,64}. This fix updates the
vbit tester (memcheck/tests/vbit-test) to test the accurate versions of
these, and thereby fixes a regression caused by e847cb5429927317023d8410c3c56952aa47fb08 as committed for bug 387664.
Mark Wielaard [Sat, 9 Dec 2017 22:01:29 +0000 (23:01 +0100)]
Fix gnu debug alt file resolving.
https://bugs.kde.org/show_bug.cgi?id=387773
The path to the alt file is relative to the actual debug file.
Make sure that we got the real file, not a (build-id) symlink.
Also handle the case where a debug or alt file is an absolute path.
Julian Seward [Tue, 12 Dec 2017 21:31:54 +0000 (22:31 +0100)]
Fix false positive with s390x cgijnl instruction testing against sign bit.
https://bugs.kde.org/show_bug.cgi?id=387712
When the cgij "compare immediate and branch relative" instruction
compares 0 <=signed dep1, that means dep1 >=signed 0, so it is a test
against the most significant bit of dep1. So only that bit needs
to be defined.
Julian Seward [Tue, 12 Dec 2017 09:22:51 +0000 (10:22 +0100)]
Bug 387664 - Memcheck: make expensive-definedness-checks be the default
Memcheck tries to accurately track definedness at the bit level, at least
for scalar integer operations. For many operations it is good enough to use
approximations which may overstate the undefinedness of the result of an
operation, provided that fully defined inputs still produce a fully defined
output. For example, the standard analysis for an integer add is
Add#(x#, y#) = Left(UifU(x#, y#))
which (as explained in the USENIX 05 paper
http://valgrind.org/docs/memcheck2005.pdf) means: for an add, worst-case
carry propagation is assumed. So all bits to the left of, and including,
the rightmost undefined bit in either operand, are assumed to be undefined.
As compilers have become increasingly aggressive, some of these
approximations are no longer good enough. For example, LLVM for some years
has used Add operations with partially undefined inputs, when it knows that
the carry propagation will not pollute important parts of the result.
Similarly, both GCC and LLVM will generate integer equality comparisons with
partially undefined inputs in situations where it knows the result of the
comparison will be defined. In both cases, Memcheck's default strategies
give rise to false uninitialised-value errors, and the problem is getting
worse as time goes by.
Memcheck already has expensive (non-default) instrumentation for integer
adds, subtracts, and equality comparisons. Currently these are only used if
you specify --expensive-definedness-checks=yes, and in some rare cases to do
with inlined string operations, as determined by analysing the block to be
instrumented, and by default on MacOS. The performance hit from them can be
quite high, up to 30% lossage.
This patch makes the following changes:
* During instrumentation, there is much finer control over which IROps get
expensive instrumentation. The following groups can now be selected
independently for expensive or cheap instrumentation:
Iop_Add32
Iop_Add64
Iop_Sub32
Iop_Sub64
Iop_CmpEQ32 and Iop_CmpNE32
Iop_CmpEQ64 and Iop_CmpNE64
This makes it possible to only enable, on a given platform, only the minimal
necessary set of expensive cases.
* The default set of expensive cases can be set on a per-platform basis.
This is set up in the first part of MC_(instrument).
* There is a new pre-instrumentation analysis pass. It identifies Iop_Add32
and Iop_Add64 uses for which the expensive handling will give the same
results as the cheap handling. This includes all adds that are used only
to create memory addresses. Given that the expensive handling of adds is,
well, expensive, and that most adds merely create memory addresses, this
more than halves the extra costs of expensive Add handling.
* The pre-existing "bogus literal" detection (0x80808080, etc) pass
has been rolled into the new pre-instrumentation analysis.
* The --expensive-definedness-checks= flag has been changed. Before, it
had two settings, "no" and "yes", with "no" being the default. Now, it
has three settings:
no -- always use the cheapest handling
auto -- use the minimum set of expensive handling needed to get
reasonable results on this platform, and perform
pre-instrumentation analysis so as to minimise the costs thereof
yes -- always use the most expensive handling
The default setting is now "auto". The user-visible effect of the new
default is that there should (hopefully) be a drop in false positive rates
but (unfortunately) also some drop in performance.
Julian Seward [Thu, 7 Dec 2017 12:31:38 +0000 (13:31 +0100)]
Fix this test to work properly with accurate CmpEQ/NE definedness tracking
Memcheck reports an error on "if (n == 42)" in this test. Unless, that is,
accurate CmpEQ/NE definedness tracking is enabled. If you stare at this
long enough it is possible to see that the test "n == 42" isn't actually
undefined, because |n| is only ever zero or one, and only its least
significant bit is undefined. So the equality comparison against 42 is
defined because there are corresponding bits in the two operands that are
different and are both defined.
This commit fixes that by comparing with 1, which forces the result to
really depend on the only undefined bit in |n|.
I also added robustification:
* return arbitrary values from gcc_cant_inline_me(), so as to avoid gcc
simply copying the input to the output or otherwise deleting the
conditional branch.
* marking gcc_cant_inline_me() as un-inlineable
* Putting compiler barriers in the second conditional in main(), so gcc
can't simply ignore the result of the call to gcc_cant_inline_me() and
then delete the call entirely.
Julian Seward [Tue, 5 Dec 2017 11:35:09 +0000 (12:35 +0100)]
amd64: Add a new spec rule for SUBL then Cond{B,NB} in the case where the RHS is a constant power of two.
LLVM 5.0 appears to have started generating such constructions in order to
find out whether the top N bits of a value are all zero. This currently
generates Iop_CmpLE32U on partially uninitialised data, causing false
positives in Memcheck. It seems simplest and most efficient to remove such
constructions at this point.
Julian Seward [Tue, 5 Dec 2017 11:04:17 +0000 (12:04 +0100)]
Rearrange sections in mc_translate.c. No functional change.
Rearrange big sections in mc_translate.c, so that the "main" instrumentation
function is at the end of the file rather than in the middle. The previous
layout never made much sense. The new layout is, roughly:
* stuff for baseline (level 2, non-origin tracking) instrumentation
* stuff for origin tracking (level 3) instrumentation
* the "final tidying" pass
* the main instrumentation function (and soon, a new pre-instrumentation
analysis pass)
When user asks enough verbosity, also give the full version in preamble
so that e.g.
valgrind -v date
produces
==7639== Using Valgrind-3.14.0.GIT-c470e0c23c-20171120X and LibVEX; rerun with -h for copyright info
to give the verbose version.
This triggers a code generation bug in gcc 6.3.0
(at least with gcc version 6.3.0 20170516 (Debian 6.3.0-18)).
(this bug can be reproduced e.g. on gcc67, which is a debian 9.2 system)
The bad code causes the debug trace to be indented by more than 500 characters,
giving e.g. for the first debug line produced by stage 2:
--12305:1:launcher launching /home/philippe/valgrind/git/smallthing/./.in_place/memcheck-amd64-linux
--12305:1:debuglog DebugLog system started by Stage 2 (main), level 1 logging requested
This commit bypasses the code generation bug, by moving the indent calculation
just before its usage.
Note: on amd64/x86, the code size of memcheck tool increases by about 12%
with -finline-functions.
In terms of perf impact (using perf/vg_perf) this gives mixed results :
memcheck is usually slightly faster, but some tests are slower (e.g. heap_pdb4)
callgrind is usually slower, but some tests are faster
helgrind : some tests are slowed down, some tests are faster (some significantly faster such as sarp and ffbench).
See below 2 runs of comparing trunk (with -finline-functions) with fixes
(which does not have -finline-functions).
Petar Jovanovic [Mon, 13 Nov 2017 12:12:25 +0000 (13:12 +0100)]
synchronize access to vgdb_interrupted_tid
Delay writing to the global vgdb_interrupted_tid until all the threads are
in interruptible state. This ensures that valgrind_wait() will see correct
value.
This solves occasional failures of gdbserver_tests/hgtls test.
Improve efficiency of SP tracking in helgrind (and incidentally in exp-sgheck)
Helgrind (and incidentally exp-sgcheck) does not need both of
tracking new mem stack and die mem stack:
Helgrind only tracks new mem stack. exp-sgcheck only tracks die mem stack.
Currently, m_translate.c vg_SP_update_pass inserts helpers calls
for new and die mem stack, even if the tool only needs new mem stack (helgrind)
or die mem stack (exp-sgcheck).
The optimisation consists in not inserting helpers calls when the tool
does not need to see new (or die) mem stack.
Also, for helgrind, implement specialised new_mem_stack for known SP updates
with small values (like memcheck).
This reduces the size of the generated code for helgrind and exp-sgcheck.
(see below the diffs on perf/memrw). This does not impact the code generation
for tools that tracks both new and die mem stack (such as memcheck).
trunk:
exp-sgcheck: --28481-- transtab: new 2,256 (44,529 -> 581,402; ratio 13.1) [0 scs] avg tce size 257
helgrind: --28496-- transtab: new 2,299 (46,667 -> 416,575; ratio 8.9) [0 scs] avg tce size 181
memcheck: --28501-- transtab: new 2,220 (50,038 -> 777,139; ratio 15.5) [0 scs] avg tce size 350
with this patch:
exp-sgcheck: --28516-- transtab: new 2,254 (44,479 -> 567,196; ratio 12.8) [0 scs] avg tce size 251
helgrind: --28512-- transtab: new 2,297 (46,620 -> 399,799; ratio 8.6) [0 scs] avg tce size 174
memcheck: --28507-- transtab: new 2,219 (49,991 -> 776,028; ratio 15.5) [0 scs] avg tce size 349
More in details, the changes consist in:
pub_core_tooliface.h:
* add 2 booleans any_new_mem_stack and any_die_mem_stack to the tdict struct
* renamed VG_(sanity_check_needs) to VG_(finish_needs_init), as it
does now more than sanity checks : it derives the 2 above booleans.
m_tooliface.c:
* change VG_(sanity_check_needs) to VG_(finish_needs_init)
m_main.c:
* update call to VG_(sanity_check_needs)
hg_main.c:
* add a few inlines for functions just calling another function
* define the functions evh__new_mem_stack_[4|8|12|16|32|112|128|144|160]
(using the macro DCL_evh__new_mem_stack).
* call the VG_(track_new_mem_stack_[4|8|12|16|32|112|128|144|160])
m_translate.c
* n_SP_updates_* stats are now maintained separately for the new and die
fast and known cases.
* need_to_handle_SP_assignment can now check only the 2 booleans
any_new_mem_stack and any_die_mem_stack
* DO_NEW macro: does not insert anymore a helper call if the tool does
not track 'new' mem_stack.
In case there is no new tracking, it however still does update the
SP aliases (and the n_SP_updates_new_fast).
* similar changes for DO_DIE macro.
* a bunch of white spaces changes
Note: it is easier to look at the changes in this file using
git diff -w
to ignore the white spaces changes (e.g. due to DO_NEW/DO_DIE indentation
changes).
Move or conditionalise on CHECK_CEM some expensive asserts
* Some RCEC related asserts checking there was no corruption are on hot paths
=> make these checks only when CHECK_CEM is set.
* Move an expensive assert where the event is inserted, as it is useless
to check this when searching for an already existing event :
it is enough to ensure that an invalid szB cannot be inserted,
and so will not be found, and so assert will trigger in the insertion logic.
Julian Seward [Tue, 7 Nov 2017 14:01:51 +0000 (15:01 +0100)]
s390_irgen_EX_SS: add initialisations so as to remove (false positive) warnings from gcc-7.x.
When compiling guest_s390_toIR.c for a 32-bit target (a configuration in which
it will never be used, but never mind), gcc-7.x notices that sizeof(ss.dec) is
larger than sizeof(ss.bytes), so the initialisation of ss.bytes leaves ss.dec.b2
and ss.dec.d2 uninitialised. This patch causes both variants to be initialised.
When built for a 64 bit target, the existing initialisation of ss.bytes covers
ss.dec completely, so there is no error.
projects / thirdparty / valgrind.git / log
