RFR(S): 8247732: validate user-input intrinsic_ids in ControlIntrinsic
Liu, Xin
xxinliu at amazon.com
Tue Aug 4 06:39:52 UTC 2020
hi, Nils,
Tobias would like to keep the parser behavior consistency. I think it means that the hotspot need to suppress the warning if the intrinsic_id doesn't exists in compiler directive.
eg. -XX:CompileCommand=option,<pattern>,ControlIntrinsic=-_nonexist.
What do you think about it?
Here is the latest webrev:
http://cr.openjdk.java.net/~xliu/8247732/01/webrev/
thanks,
--lx
________________________________________
From: Tobias Hartmann <tobias.hartmann at oracle.com>
Sent: Friday, July 24, 2020 2:52 AM
To: Liu, Xin; Nils Eliasson; hotspot-compiler-dev at openjdk.java.net; hotspot-runtime-dev
Subject: RE: [EXTERNAL] RFR(S): 8247732: validate user-input intrinsic_ids in ControlIntrinsic
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
Hi Liu,
On 23.07.20 18:02, Liu, Xin wrote:
> That is my intention too, but CompilerOracle doesn't exit JVM when it encounters parsing errors.
> It just exacts information from CompileCommand as many as possible. That makes sense because compiler "directives" are supposed to be optional for program execution.
>
> I do put the error message in parser's errorbuf. I set a flag "exit_on_error" to quit JVM after it dumps parser errors. yes, I treat undefined intrinsics as fatal errors.
> This behavior is from Nils comment: "I want to see an error on startup if the user has specified unknown intrinsic names." It is also consistent with JVM option -XX:ControlIntrinsic=.
Okay, thanks for the explanation! I would prefer consistency in error handling of compiler
directives, i.e., handle all parser failures the same way. But I leave it to Nils to decide.
Best regards,
Tobias
More information about the hotspot-compiler-dev
mailing list