Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cherry pick #2075 #2076

Open
wants to merge 1 commit into
base: release/2022.8.0
Choose a base branch
from
Open

cherry pick #2075 #2076

wants to merge 1 commit into from

Conversation

timmiesmith
Copy link
Contributor

Final cherry pick for release notes.

Copy link
Contributor

@mmichel11 mmichel11 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Comment on lines +18 to +19
Intel, the Intel logo, and Arc are the trademarks of Intel Corporation or its subsidiaries.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We already have a very similar claim at the line 10 above. Is it not sufficient?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps we can just add "Arc" to the line 10 if we just want to call it out specifically?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I double-checked the names database, and I made a mistake. This should be a footnote on the page where Arc products are cited, not on the Notices and Disclaimers page.

This line can be removed from the Notices and Disclaimers page and moved to a footnote on the Release Notes.

@@ -20,7 +20,7 @@ New Features
with device policies for large data sizes.
- Improved performance of ``copy``, ``fill``, ``for_each``, ``replace``, ``reverse``, ``rotate``, ``transform`` and 30+
other algorithms with device policies on GPUs.
- Improved oneDPL use with SYCL implementations other than Intel oneDPI DPC++/C++ compiler.
- Improved oneDPL use with SYCL implementations other than Intel® oneAPI DPC++/C++ Compiler.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do not strictly need the trademark symbol here, because the line 7 of the Overview above already contains it, and it's sufficient to do just once for the document.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This suggestion comes from @dcbenito here, so perhaps they can weigh in here?

Copy link
Contributor

@akukanov akukanov Feb 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dcbenito looked at the context presented in the patch, which did not include the overview. The rule is known and confirmed by Dylan before: it is sufficient to have the trademark sign once for a name within the document.

This is in part the reason why the overview mentions both oneDPL and DPC++ by the official names: the trademark sign is already there and can be skipped in all the notes below.

Copy link
Contributor

@dcbenito dcbenito Feb 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not totally correct. The Intel® oneAPI DPC++ Library/oneAPI DPC++ Library (Intel or open source) both have a short name "oneDPL" that can be used after the first instance of the full name, but the compiler Intel® oneAPI DPC++/C++ Compiler or oneAPI DPC++/C++ Compiler does not have a short name and should be used in its complete form. This is legal advice from the names database.

Copy link
Contributor

@akukanov akukanov Feb 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am speaking about the trademark symbol, not about the shorter form.

To make it clear, I do not consider this a critical problem; it can be clarified and resolved later.

Copy link
Contributor

@dcbenito dcbenito Feb 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The latest advice is to cite the name in its completeness:

The approved usage is: Intel® oneAPI DPC++/C++ Compiler or oneAPI DPC++/C++ Compiler

NOTE: “If you are preparing documentation of the Intel-branded version of the product, use “Intel® oneAPI…” If you are documenting the industry specification, the open source project, or are making general references to the technology not specific to either the open source or Intel-branded product, use “oneAPI…”

  • This name has been approved and adopted for internal and external use.
  • This name should be used in its complete form, as noted above.
  • Never abbreviate this name.
  • Do not change the capitalization, unless used in a heading where normal capitalization rules apply.
  • As noted above, the mark "Intel®" in front of this name is optional.
  • No other trademark symbols (such as, ®, ™ or SM) should be used.
  • Appropriate acknowledgement line for this name is “Intel and the Intel logo are trademarks of Intel Corporation or its subsidiaries.”

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding "As noted above, the mark "Intel®" in front of this name is optional." The "optional" is for oneAPI products, in that the open source compiler does not use a (R), but the Intel branded version does.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This whole discussion is kind of strange in the open-source repo of a UXL project, is not it? :) Switching to email.

sizes of 4-8 million elements.
- ``sort``, ``stable_sort``, ``sort_by_key`` and ``stable_sort_by_key`` algorithms fail to compile
when using Clang 17 and earlier versions, as well as compilers based on these versions,
such as Intel(R) oneAPI DPC++/C++ Compiler 2023.2.0.
such as Intel® oneAPI DPC++/C++ Compiler 2023.2.0.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly here we can just omit the trademark.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not correct. See above guidance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants