RE: Build failure "/mnt/data/home/software/openjdk/src/hotspot/share/gc/parallel/objectStartArray.cpp:106:56: error: ‘void* memset(void*, int, size_t)’ writing to an object of type ‘class HeapWord’ with ‘private’ member ‘HeapWord::i’ [-Werror=class-memacc

[Andrew Luo]

Actually, it seems both these errors are being tracked by a parent bug:

https://bugs.openjdk.java.net/browse/JDK-8213153

Thanks,

-Andrew

-----Original Message-----
From: David Holmes <david.holmes at oracle.com> 
Sent: Monday, December 31, 2018 3:00 PM
To: Karl-Philipp Richter <krichter at posteo.de>; Andrew Luo <andrewluotechnologies at outlook.com>; jdk-dev at openjdk.java.net
Subject: Re: Build failure "/mnt/data/home/software/openjdk/src/hotspot/share/gc/parallel/objectStartArray.cpp:106:56: error: ‘void* memset(void*, int, size_t)’ writing to an object of type ‘class HeapWord’ with ‘private’ member ‘HeapWord::i’ [-Werror=class-memacc

On 1/01/2019 8:15 am, Karl-Philipp Richter wrote:
> Hi Andrew,
> Thanks for your quick reply.
> 
> Am 31.12.18 um 21:08 schrieb Andrew Luo:
>> Can you run gcc --version and tell us the version of GCC that you are using?
> My version is gcc (Ubuntu 8.2.0-7ubuntu1) 8.2.0.
> 
>> I'm guessing this was added in a newer version of GCC (class-memaccess was added in GCC 8), and can probably be worked around using -Wno-error=class-memaccess.  That's not saying I don't think we should fix this, just suggesting a workaround for now if you want to compile on GCC 8 before this is fixed.  Although I believe that per the C++ standard you are allowed to memcpy/memset trivial classes (clang only warns on non-trivial classes: https://reviews.llvm.org/D45310) so GCC's warning seems to be a bit too broad.
> `env MAKEFLAGS= bash ./configure
> --with-extra-cflags=-Wno-error=class-memaccess
> --with-extra-cxxflags=-Wno-error=class-memaccess && make` avoid the 
> build failure, however the build now fails because of
> 
> ```
> /mnt/data/home/software/openjdk/src/java.base/unix/native/libjli/java_md_solinux.c:
> In function ‘ContinueInNewThread0’:
> /mnt/data/home/software/openjdk/src/java.base/unix/native/libjli/java_md_solinux.c:747:37:
> error: cast between incompatible function types from ‘int (*)(void *)’
> to ‘void * (*)(void *)’ [-Werror=cast-function-type]
>       if (pthread_create(&tid, &attr, (void *(*)(void*))continuation,
> (void*)args) == 0) {
>                                       ^

This is a known issue already being handled under:

https://bugs.openjdk.java.net/browse/JDK-8215009

> cc1: all warnings being treated as errors
> make[3]: *** [CoreLibraries.gmk:212:
> /mnt/data/home/software/openjdk/build/linux-x86_64-server-release/supp
> ort/native/java.base/libjli/java_md_solinux.o]
> Fehler 1
> make[3]: *** Auf noch nicht beendete Prozesse wird gewartet …
> make[2]: *** [make/Main.gmk:215: java.base-libs] Fehler 2
> 
> ERROR: Build failed for target 'default (exploded-image)' in 
> configuration 'linux-x86_64-server-release' (exit code 2) ```
> 
> I agree that the issue should be fixed.
> 
> Since Ubuntu is not among the least popular Linux distributions, I 
> recommend a review of your continuous integration system which might 
> need to include more systems.

OpenJDK has a set of supported compiler versions for building it. While we continually strive to make it build with more recent versions, it's up to the people wanting to build with those compilers to contribute the quick fixes. gcc continually adds new default warnings which lead to build failures; and every new compiler version potentially adds new compiler bugs.

Cheers,
David
-----

> The setup on GitLab is an example to
> perform these tests easily, but you probably already have already a CI 
> set up which you can extend.
> 
> Since I don't need to build OpenJDK urgently, I'd rather see these 
> build issues detected and fixed by CI coverage of the build process 
> than stumbling from one to another - it's probably only these two, but 
> afaik that's a lot of a widely use operating system.
> 
>> Are you interested in contributing a fix to this as well - if not I can work on this later this week as well.
> I have not enough knowledge to provide a good fix.
> 
>> (By the way, your link https://gitlab.com/krichter/openjdk/-/jobs/140219987 requires signing in).
> My bad, fixed.
> 
> -Kalle
>