Re: RFR: 8284932: [Vector API] Incorrect implementation of LSHR operator for negative byte/short elements

On Mon, 18 Apr 2022 05:14:25 GMT, Jie Fu wrote: >>> > However, just image that someone would like to optimize some code >>> > segments of bytes/shorts `>>>` >>> >>> Then that person can just use signed shift (`VectorOperators.ASHR`), right? >>> Shifting on masked shift counts means that the sh

Re: RFR: 8284932: [Vector API] Incorrect implementation of LSHR operator for negative byte/short elements

On Mon, 18 Apr 2022 04:14:39 GMT, Jie Fu wrote: >> Hi, >> >> Because unsigned cast should operate on unsigned types, the more appropriate >> usage is `(src[i] & 0xFF) >>> 3`, with the `&` operation is the cast from >> unsigned byte to int. Actually, I fail to understand the intention of your

Re: RFR: 8266054: VectorAPI rotate operation optimization [v10]

On Mon, 26 Jul 2021 18:56:01 GMT, Jatin Bhateja wrote: >> @jatin-bhateja This question is still pending. > > @sviswa7, SLP flow will either have a constant 8bit shift value or a variable > shift present in vector. So non constant scalar case will not be hit through > this route. It would be b

Re: RFR: 8266054: VectorAPI rotate operation optimization [v9]

On Wed, 30 Jun 2021 11:02:41 GMT, Jatin Bhateja wrote: >> Current VectorAPI Java side implementation expresses rotateLeft and >> rotateRight operation using following operations:- >> >> vec1 = lanewise(VectorOperators.LSHL, n) >> vec2 = lanewise(VectorOperators.LSHR, n) >> res = lan

Re: RFR(S): 8252407: Build failure with gcc-8+ and asan

Hi, Thanks for looking at this. For gcc-10, it's hard to make 'strncpy' all right with asan enabled (approaches we talked previous don't work). I'm trying to find a better way to avoid using compile pragma. I suppose it would be better to use 'memcpy' to replace 'strncpy'. Thanks, Eric

Re: RFR(S): 8252407: Build failure with gcc-8+ and asan

Hi Kim,  Sorry for the delay. This patch removes a redundant string copy in NetworkInterface.c to avoid string-truncation warning. Other warnings we talked before, which are unable to completely fix in different version of gcc, I have to use pragma to suppress them as a workaround. This pat

Re: RFR(S): 8252407: Build failure with gcc-8+ and asan

Hi Kim, > Kim Barrett on Sent: 08 September 2020 20:28   >> On Sep 7, 2020, at 10:56 AM, Eric Liu wrote: >> I have tested 4 cases for those warnings: >> a) Without my patch, without asan, gcc-8 and gcc-10 are OK. >> b) Without my patch, with asan, gcc-8 has warned,

Re: RFR(S): 8252407: Build failure with gcc-8+ and asan

Hi Kim: Thanks for the discussion, this makes more sense to me now. > Kim Barrett on 06 September 2020 19:35 wrote: > > Can you be (very) specific about this.  Do all of these changes cause gcc10 > to warn?  Or > do only some of them.  If only some, specifically which ones? I have a > conjec

Re: RFR(S): 8252407: Build failure with gcc-8+ and asan

Hi Daniel, Kim, Thanks for your review. > Kim Barrett on Tue Sep 1 09:46:26 UTC 2020 > > Changes look good, subject to that caveat. I think these changes conform > better to the documented description of the warning than did the recent > NetworkInterface.c change mentioned above, so I’m hopeful

Re: RFR(S): 8252407: Build failure with gcc-8+ and asan

Hi all, Please review this simple change to fix some compile warnings. The newer gcc (gcc-8 or higher) would warn for calls to bounded string manipulation functions such as 'strncpy' that may either truncate the copied string or leave the destination unchanged. This patch fixed stringop-truncati