[SYCL] Add errc to SYCL 1.2.1 exceptions for SYCL 2020 conformance

[cperkinsintel]

adding errc to SYCL 1.2.1 exceptions for SYCL2020 conformance. For some reason, many of our SYCL 1.2.1 exception subclasses inherit from runtime_error, but some from device_error. This, plus the desire to not change the inheritance tree at all, means that more duplicate functions were added than I was originally hoping. But these will all be removed when the SYCL 1.2.1 exception subclasses are dropped.

Signed-off-by: Chris Perkins chris.perkins@intel.com

[cperkinsintel]

@vladimirlaz @romanovvlad , I'm slightly confused by this CI failure on Windows. On Linux, the ABI-change test runs fine. And I even re-output the symbols with our python scripts, and there were no new symbols. But on Windows, there are. Is this to be expected? Also, is there a script to run on Windows to output the symbols there?

[alexbatashev]

@vladimirlaz @romanovvlad , I'm slightly confused by this CI failure on Windows. On Linux, the ABI-change test runs fine. And I even re-output the symbols with our python scripts, and there were no new symbols. But on Windows, there are. Is this to be expected? Also, is there a script to run on Windows to output the symbols there?

On Windows the compiler decided to embed the constructor symbol into the binary. Not the worst idea ever, considering that it has to distinguish between different exceptions no matter what library throws them. I think, if you return the old constructor and add this as an additional one, everything will be fine.

[vladimirlaz]

could you please fix the Windows failure as @alexbatashev mentioned?

[cperkinsintel]

@alexbatashev - I like that theory a lot, and I didn't know that about the constructors on Win, thanks. However, while I think I restored them correctly, I'm still getting this strange failure. ABI test passes on Linux, fails on Windows.

Does anyone see anything obvious here?

[cperkinsintel]

@romanovvlad @vladimirlaz

So the original Windows ABI error for this PR had both a breaking change and a non-breaking change to the ABI. Here it an excerpt:

There are missing symbols in the new library. It is a breaking change. Refer to sycl/doc/ABIPolicyGuide.md for further instructions. Do not forget to update ABI version according to the policy.
The following symbols are missing from the new object file:
??0exception@sycl@cl@@IEAA@AEBV?$basic_string...
??0exception@sycl@cl@@IEAA@PEBDHV?$shared_ptr@Vcontext@...

There are new symbols in the new library. It is a non-breaking change. Refer to sycl/doc/ABIPolicyGuide.md for further instructions.
The following symbols are new to the object file:
??0exception@sycl@cl@@IEAA@Verror_code...
??0exception@sycl@cl@@IEAA@Verror_code...

Following the advice of @alexbatashev I restored the original constructors that are now no longer needed. Now the ABI message we see on Windows is just the non-breaking change.

I investigated this on Windows, and we pretty much have to export the exception class at the top level and there is no way of individually leaving methods out of the export, short of converting the whole thing to a virtual class which would be a bigger ABI change.

So, I think this means that to merge this work will will have to accept this non-breaking change to the Windows ABI. Is that OK? I've updated the PR with the updated windows symbols.

[alexbatashev]

So, I think this means that to merge this work will will have to accept this non-breaking change to the Windows ABI. Is that OK? I've updated the PR with the updated windows symbols.

We only have restrictions on breaking changes. Adding new exported symbols should be fine.

[cperkinsintel]

This PR has picked up a bunch of commits that shouldn't be there. The Win machine I performed the symbol dump on must have had something incorrect on its sycl branch. Closing this PR and will re-attempt fresh.