Hi Martin,
as it breaks build, it definitely has to be fixed. I have filed 8203437. the
obvious fix for this warning would be:
> diff -r 3af6ed2513aa
> test/hotspot/jtreg/vmTestbase/gc/gctests/nativeGC05/libnativeGC05.c
> --- a/test/hotspot/jtreg/vmTestbase/gc/gctests/nativeGC05/libnativeGC05.c
> Thu May 17 21:05:43 2018 -0700
> +++ b/test/hotspot/jtreg/vmTestbase/gc/gctests/nativeGC05/libnativeGC05.c
> Fri May 18 10:02:11 2018 -0700
> @@ -27,7 +27,7 @@
> Java_gc_gctests_nativeGC05_nativeGC05_kickOffRefillers
> (JNIEnv *env, jobject obj, jobject matrix, jobject stack) {
> jclass matrixClass, stackClass, pairClass = 0;
> - jmethodID stack_pop_mid, stack_empty_mid, matrix_repopulate_mid,
> pair_geti_mid, pair_getj_mid;
> + jmethodID stack_pop_mid, stack_empty_mid, matrix_repopulate_mid,
> pair_geti_mid, pair_getj_mid = 0;
> jobject pair;
> jint i, j;
> jboolean b;
while I'm in progress of setting up a linux w/ gcc4.8.5 (which due to different
reasons might take some time), could you please verify whether it fixes this
warning and if there are other warnings from your compilers? if there are, you
can get the whole list by disable warnings as error (configure
--disable-warnings-as-errors) and then grep for ': warning:' in
'build/*/build.log'.
Thanks,
-- Igor
> On May 18, 2018, at 5:03 AM, Doerr, Martin <martin.do...@sap.com> wrote:
>
> Hi Igor,
>
> we get compiler warnings on linux ppc64le (GCC 4.8.5):
>
> libnativeGC05.c:80:19: error: 'pair_getj_mid' may be used uninitialized in
> this function [-Werror=maybe-uninitialized]
> j = (*env)->CallIntMethod(env, pair, pair_getj_mid);
> ^
>
> libnativeGC05.c:78:19: error: 'pair_geti_mid' may be used uninitialized in
> this function [-Werror=maybe-uninitialized]
> i = (*env)->CallIntMethod(env, pair, pair_geti_mid);
> ^
>
> Unfortunately, the files are compiled with warnings as errors. We think this
> should get fixed.
>
> Best regards,
> Martin
>
>
> -----Original Message-----
> From: hotspot-gc-dev [mailto:hotspot-gc-dev-boun...@openjdk.java.net] On
> Behalf Of Igor Ignatyev
> Sent: Dienstag, 15. Mai 2018 20:59
> To: Erik Helin <erik.he...@oracle.com>
> Cc: hotspot-gc-dev <hotspot-gc-...@openjdk.java.net>; build-dev
> <build-dev@openjdk.java.net>; hotspot-dev developers
> <hotspot-...@openjdk.java.net>
> Subject: Re: RFR(L) : 8199370: [TESTBUG] Open source vm testbase GC tests
>
> Hi Erik,
>
> please see my answers inline.
>
> can I consider this RFR as reviewed by you?
>
> Thanks,
> -- Igor
>
>> On May 14, 2018, at 4:23 AM, Erik Helin <erik.he...@oracle.com> wrote:
>>
>> On 05/08/2018 12:35 AM, Igor Ignatyev wrote:
>>> Hi all,
>>
>> Hi Igor,
>>
>> On 05/08/2018 12:35 AM, Igor Ignatyev wrote:
>>> could you please review the patch which open sources GC tests from vm
>>> testbase? it introduces the following test groups:
>>> - vmTestbase_vm_g1classunloading
>>> - vmTestbase_vm_gc_compact
>>> - vmTestbase_vm_gc_concurrent
>>> - vmTestbase_vm_gc_container
>>> - vmTestbase_vm_gc_juggle
>>> - vmTestbase_vm_gc_locker
>>> - vmTestbase_vm_gc_ref
>>> - vmTestbase_vm_gc_misc
>>
>> This is a very welcome, and pretty massive, change :) I won't be able to
>> read through each test, there are simple too many, but I can sample a few of
>> them and have a look.
>>
>> On 05/08/2018 12:35 AM, Igor Ignatyev wrote:
>>> As usually w/ VM testbase code, these tests are old, they have been run in
>>> hotspot testing for a long period of time. Originally, these tests were run
>>> by a test harness different from jtreg and had different build and
>>> execution schemes, some parts couldn't be easily translated to jtreg, so
>>> tests might have actions or pieces of code which look weird. In a long
>>> term, we are planning to rework them.
>>
>> I'm also assuming that to help the open sourcing of these tests, most
>> comments will likely be deferred until later? If so, that is fine with me.
> y, unless it is something very important and cost of delaying changes is
> high, I'd prefer to defer all comments/improvements till later.
>>
>> On 05/08/2018 12:35 AM, Igor Ignatyev wrote:
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8199370
>>> webrev: http://cr.openjdk.java.net/~iignatyev/8199370/webrev.00/index.html
>>
>> Many of the tests are a bit cryptic, but that can be refactored later. Could
>> you please file bugs for the two tests written in shell? Particularly
>> parOld/test.sh should be trivial to rewrite in Java.
> sure, I've filed 8203239 and 8203238.
>>
>> It seems like a lot of tests contains a TEST.properties file with the
>> content `exclusiveAccess.dirs=.`. Could this become the default value
>> somewhere, so we don't need all those TEST.properties files?
> y, but this will require finding a most top directory whose all tests have
> this TEST.properties file and it will also make it harder to understand how a
> test is executed. there was/is ongoing discussing w/ Jon on moving
> 'exclusiveAccess' to test description. anyhow I've filed an RFE to clean that
> up -- 8203241.
>
>>
>> Thanks,
>> Erik
>>
>>> Thanks,
>>> -- Igor
>
