Re: RFR: 8286562: GCC 12 reports some compiler warnings [v8]

> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on > Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should > separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * > src/hotspot/share/jfr/

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]

On Sun, 22 May 2022 03:15:20 GMT, Kim Barrett wrote: >> Like the others, it is caused by `Array::at_put()`. >> >> >> In file included from >> /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/annotations.hpp:28, >> from >> /home/ysuenaga/github-forked/jdk/src/hotspot/sh

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]

On Sun, 22 May 2022 05:00:21 GMT, Kim Barrett wrote: >> I guess GCC cannot understand `assert(dest != NULL` immediately preceding it. >> >> >> In file included from >> /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp:33,

RFR: 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box

This resolves an occasional unit test failure in Path2D.UnitTest. The previous Path2D#getBounds2D(PathIterator) implementation assumed that after a SEG_CLOSE the next segment would always be a SEG_MOVETO to start a new clearly defined segment. But the Path2D.UnitTest created random paths that d

Re: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box

On Sun, 22 May 2022 09:08:03 GMT, Jeremy wrote: > This resolves an occasional unit test failure in Path2D.UnitTest. > > The previous Path2D#getBounds2D(PathIterator) implementation assumed that > after a SEG_CLOSE the next segment would always be a SEG_MOVETO to start a > new clearly defined s

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]

On Sun, 22 May 2022 08:35:54 GMT, Yasumasa Suenaga wrote: >> `Array::_data` is a pseudo flexible array member. "Pseudo" because C++ >> doesn't have flexible array members. The compiler is completely justified in >> complaining about the apparently out-of-bounds accesses. >> >> There is a "well-k

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]

On Sun, 22 May 2022 08:45:48 GMT, Yasumasa Suenaga wrote: >> I don't think this warning has anything to do with that NULL check. But I'm >> still not understanding what it is warning about. The "region of size 0" part >> of the warning message seems important, but I'm not (yet?) seeing how it >>

RFR: 8287102: ImageReaderSPI.canDecode should not throw EOFException

Invoking `ImageReaderSpi.canDecodeInput(Object)` with a stream having less than 8 bytes causes an `EOFException` to be thrown instead of returning `false`. This is caused by BMP, WBMP, GIF, PNG and TIFF reader implementations assuming that those bytes always exist and not checking EOF conditions

Re: Unexpected EOFException in ImageReaderSpi.canDecodeInput

Le 20/05/2022 à 20:00, Philip Race a écrit : OK .. we can probably take the proposed change, but there's no guarantee it won't still happen with 3rd party external plugins. I've filed the bug for you : https://bugs.openjdk.java.net/browse/JDK-8287102 Thanks! I have rebased the pull request

Re: RFR: 8176501: Method Shape.getBounds2D() incorrectly includes Bezier control points in bounding box [v2]

> This resolves an occasional unit test failure in Path2D.UnitTest. > > The previous Path2D#getBounds2D(PathIterator) implementation assumed that > after a SEG_CLOSE the next segment would always be a SEG_MOVETO to start a > new clearly defined segment. But the Path2D.UnitTest created random pat

Re: RFR: 8287102: ImageReaderSpi.canDecodeInput() for standard plugins should return false if a stream is too short

On Fri, 13 May 2022 12:23:24 GMT, Martin Desruisseaux wrote: > Invoking `ImageReaderSpi.canDecodeInput(Object)` with a stream having less > than 8 bytes causes an `EOFException` to be thrown instead of returning > `false`. This is caused by BMP, WBMP, GIF, PNG and TIFF reader > implementation

Debugging Pre-Submit Test Failures

I have a PR that is failing some Linux pre-submit tests, but I don’t have a linux machine handy to test against. I tried running the tests 3 times in case the failure was random, but it pers

Re: Debugging Pre-Submit Test Failures

Where are these files ? I can't see them. Is it something under  "Pre-submit tests - Linux x86" in the list of "Some checks were not successful" ? The reason I see for errors under there is just the odd "Error: Unable to find an artifact with the name: transient_jtreg_mickleness_88346f4d" M

Re: Debugging Pre-Submit Test Failures

Oh and if it "x86" then it really isn't something you need to worry about much since "x64" is passing and maintaining x86 is someone's hobby perhaps .. but not a big issue for mainline. I don't know why we even have that there. -phil On 5/22/22 3:14 PM, Philip Race wrote: Where are these files

Re: RFR: 8279614: The left line of the TitledBorder is not painted on 150 scale factor [v8]

On Wed, 20 Apr 2022 23:35:10 GMT, lukeu wrote: >> Made a small change with the bottom line to match the left line of the border > >> Made a small change with the bottom line to match the left line of the border > > Great, that looks like it'll fix it so I won't test again, I'll defer to the > o

Re: Debugging Pre-Submit Test Failures

Apparently Linux 86 is broken because Loom needs work for that port .. so really completely ignore it for now. -phil On 5/22/22 3:21 PM, Philip Race wrote: Oh and if it "x86" then it really isn't something you need to worry about much since "x64" is passing and maintaining x86 is someone's hob