Deprecations don't list replacements, unclear in parts #109

Section A.7. Deprecated Functions lists many deprecated functions that are due to be removed in gcc 11. However it doesn't list the replacement for any of them. It should list the recommended replacement for each.

For some, it's clear you should use the normal operators instead (+ instead of vec_add, - instead of vec_sub), but for many others there is no apparent replacement. E.g. vec_adds, how do you do a saturated add if that function gets removed?

Section A.7. Deprecated Functions lists many deprecated functions that are due to be removed in gcc 11. However it doesn't list the replacement for any of them. It should list the recommended replacement for each. For some, it's clear you should use the normal operators instead (+ instead of vec_add, - instead of vec_sub), but for many others there is no apparent replacement. E.g. vec_adds, how do you do a saturated add if that function gets removed?

It isn't that vec_adds is being removed. The point is to remove a lot
of silly combinations of types that aren't necessary. For example,
mixing unsigned and boolean types in addition and that sort of thing.
It appears that the original developers listed all of these because the
builtin methodology supported them accidentally (it's based more on
modes than on types, so a V4SImode translates to "vector signed int",
"vector unsigned int", and "vector bool int"). They aren't actually
really useful.

In summary, all the function provided by the vec_* builtins remains
available under the same names. If somebody is using one of these
deprecated combinations of types, it would be good to cast the arguments
to supported type combinations. Vector types are freely castable from
one to another, so this isn't burdensome.

If you see examples of important function that you think are being lost,
please let me know. The intent is this is not the case.

On 9/26/20 9:26 AM, clbr wrote:

Section A.7. Deprecated Functions lists many deprecated functions
that are due to be removed in gcc 11. However it doesn't list the
replacement for any of them. It should list the recommended
replacement for each.

For some, it's clear you should use the normal operators instead (+
instead of vec_add, - instead of vec_sub), but for many others there
is no apparent replacement. E.g. vec_adds, how do you do a saturated
add if that function gets removed?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/OpenPOWERFoundation/ELFv2-ABI/issues/109, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABKD4KI3HHH2RTDJVIM35PTSHX22RANCNFSM4R25U4JA.

It isn't that vec_adds is being removed. The point is to remove a lot of silly combinations of types that aren't necessary. For example, mixing unsigned and boolean types in addition and that sort of thing. It appears that the original developers listed all of these because the builtin methodology supported them accidentally (it's based more on modes than on types, so a V4SImode translates to "vector signed int", "vector unsigned int", and "vector bool int"). They aren't actually really useful. In summary, all the function provided by the vec_* builtins remains available under the same names. If somebody is using one of these deprecated combinations of types, it would be good to cast the arguments to supported type combinations. Vector types are freely castable from one to another, so this isn't burdensome. If you see examples of important function that you think are being lost, please let me know. The intent is this is not the case. On 9/26/20 9:26 AM, clbr wrote: > > Section A.7. Deprecated Functions lists many deprecated functions > that are due to be removed in gcc 11. However it doesn't list the > replacement for any of them. It should list the recommended > replacement for each. > > For some, it's clear you should use the normal operators instead (+ > instead of vec_add, - instead of vec_sub), but for many others there > is no apparent replacement. E.g. vec_adds, how do you do a saturated > add if that function gets removed? > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <https://github.com/OpenPOWERFoundation/ELFv2-ABI/issues/109>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABKD4KI3HHH2RTDJVIM35PTSHX22RANCNFSM4R25U4JA>. >

Oh, thanks for the clarification! Could a paragraph be added on that
page, saying it's mostly such weird type combinations, and not a full
removal of anything?

Oh, thanks for the clarification! Could a paragraph be added on that page, saying it's mostly such weird type combinations, and not a full removal of anything?

On 9/27/20 11:31 AM, clbr wrote:

Oh, thanks for the clarification! Could a paragraph be added on that
page, saying it's mostly such weird type combinations, and not a full
removal of anything?

Done. See https://gcc.gnu.org/gcc-10/changes.html for the new
language. Please let me know if you'd like any further changes.

Thanks for identifying this concern! I hope this will be helpful to
others as well.

Bill

On 9/27/20 11:31 AM, clbr wrote: > Oh, thanks for the clarification! Could a paragraph be added on that > page, saying it's mostly such weird type combinations, and not a full > removal of anything? > > Done. See https://gcc.gnu.org/gcc-10/changes.html for the new language. Please let me know if you'd like any further changes. Thanks for identifying this concern! I hope this will be helpful to others as well. Bill

Thanks, closing.

Labels Milestones

Deprecations don't list replacements, unclear in parts #109