Re: RFR: JDK-8239139 testmake fail with warning about strncpy using gcc version 8

2020-02-16 Thread Magnus Ihse Bursie

On 2020-02-17 08:48, linzang(臧琳) wrote:

Hi,
  May I ask help to review one tiny fix of build failure described at 
https://bugs.openjdk.java.net/browse/JDK-8239139
  Root cause is gcc version 8 prints warning for strncpy.
  The fix simply replace strncpy with snprintf.
  Thanks!
  Bug: https://bugs.openjdk.java.net/browse/JDK-8239139
  webrev: http://cr.openjdk.java.net/~lzang/8239139/webrev/

BRs,
Lin


Hi Lin,

This is not a build issue. I'm redirecting this to core-libs.

/Magnus


RFR: JDK-8239139 testmake fail with warning about strncpy using gcc version 8

2020-02-16 Thread 臧琳
Hi,
 May I ask help to review one tiny fix of build failure described at 
https://bugs.openjdk.java.net/browse/JDK-8239139
 Root cause is gcc version 8 prints warning for strncpy.
 The fix simply replace strncpy with snprintf.
 Thanks!
 Bug: https://bugs.openjdk.java.net/browse/JDK-8239139
 webrev: http://cr.openjdk.java.net/~lzang/8239139/webrev/

BRs,
Lin


Re: RFR: 8239001: Hotspot build broken on linux-sparc after 8238281

2020-02-16 Thread John Paul Adrian Glaubitz
Hi Kim!

On 2/15/20 10:30 PM, Kim Barrett wrote:
> I prefer the approach using a non-ODR-used dummy to the approach of
> casting of some random number to an address.  Non-ODR-used
> declarations are well supported by the standard (C++03 3.2) and widely
> used; that's the basis for the "sizeof trick" metaprogramming idiom,
> for example.

I've now understood that approach and implemented it. Please see my patch in 
[1].

FWIW, I have tried to put the declaration of RegistersForDebugging outside
the X_offset() functions but that doesn't work. Hope the change is now
okay as is :).

Adrian

> [1] http://cr.openjdk.java.net/~glaubitz/8239001/webrev.02/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


Re: RFR: 8239001: Hotspot build broken on linux-sparc after 8238281

2020-02-16 Thread John Paul Adrian Glaubitz
Hi Andrew!

On 2/16/20 12:07 PM, Andrew Haley wrote:
> On 2/15/20 6:33 PM, John Paul Adrian Glaubitz wrote:
>>
>> Here is another approach for fixing 8238281 [1]. Please review.
>>
>>> [1] http://cr.openjdk.java.net/~glaubitz/8239001/webrev.01/
> 
> Can you give us a bit more explanation about why 8238281 broke linux-sparc,
> and why your proposal is valid? This doesn't look valid to me:

The problem is that i[j] is a non-const expression which is not allowed
when using offsetof(). I have included the GCC error message in the
bug report [1].

>   (((RegistersForDebugging*)16)->f[0])
> 

This basically just calculates the offset within the array f with the
offset j, hence the factor j.

I have to admit though that I haven't fully understood Kim's non-odr-used
approach yet.

Thanks,
Adrian

> [1] https://bugs.openjdk.java.net/browse/JDK-8239001

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


Re: RFR: 8239001: Hotspot build broken on linux-sparc after 8238281

2020-02-16 Thread Andrew Haley
On 2/16/20 11:07 AM, Andrew Haley wrote:
> Can you give us a bit more explanation about why 8238281 broke linux-sparc,
> and why your proposal is valid? This doesn't look valid to me:
> 
>   (((RegistersForDebugging*)16)->f[0])

Sorry, I didn't see the other thread.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671



Re: RFR: 8239001: Hotspot build broken on linux-sparc after 8238281

2020-02-16 Thread Andrew Haley
On 2/15/20 6:33 PM, John Paul Adrian Glaubitz wrote:
> 
> Here is another approach for fixing 8238281 [1]. Please review.
> 
>> [1] http://cr.openjdk.java.net/~glaubitz/8239001/webrev.01/

Can you give us a bit more explanation about why 8238281 broke linux-sparc,
and why your proposal is valid? This doesn't look valid to me:

  (((RegistersForDebugging*)16)->f[0])

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671