incorporate latest rkruppe feedback

Author: gnzlbg

text/0000-ppv.md

@@ -551,8 +551,8 @@ implementations:
 ##### Integer vector semantics
 
 The behavior of these operations for integer vectors is the same as that of the
-scalar integer types. That is: `panic!` on both overflow and division by zero in
-debug mode.
+scalar integer types. That is: `panic!` on both overflow and division by zero if
+`-C overflow-checks=on`.
 
 ##### Floating-point semantics
 
@@ -600,13 +600,7 @@ pub fn max(self, other: Self) -> Self;
 ##### Floating-point semantics
 
 The floating-point semantics follow the semantics of `min` and `max` for the
-scalar `f32` and `f64` types. That is:
-
-If either operand is a `NaN`, returns the other non-NaN operand. Returns `NaN`
-only if both operands are `NaN`. If the operands compare equal, returns a value
-that compares equal to both operands. This means that `min(+/-0.0, +/-0.0)`
-could return either `-0.0` or `0.0`. Otherwise, `min` and `max` return the
-smallest and largest operand, respectively.
+scalar `f32` and `f64` types.
 
 #### Arithmetic reductions 
 
@@ -1287,13 +1281,13 @@ that have withstood the test of time, and it adapts these designs to Rust.
 # Unresolved questions
 [unresolved]: #unresolved-questions
 
-### Interaction with scalable vectors
+### Interaction with Cray vectors
 
 The vector types proposed in this RFC are packed, that is, their size is fixed
 at compile-time.
 
 Many modern architectures support vector operations of run-time size, often
-called scalable Vectors or scalable vectors. These include, amongst others,
+called Cray Vectors or scalable vectors. These include, amongst others,
 NecSX, ARM SVE, and RISC-V's Vector Extension Proposal. These architectures have
 traditionally relied on auto-vectorization combined with support for explicit
 vectorization annotations, but newer architectures like ARM SVE introduce
@@ -1337,24 +1331,24 @@ fn add_constant(dst: &mut [f64], src: &[f64], c: f64) {
 The RISC-V vector extension proposal introduces a model similar in spirit to ARM
 SVE. These extensions are, however, not official yet, and it is currently
 unknown whether GCC and LLVM will expose explicit intrinsics for them. It would
-not be surprising if they do, and it would not be surprising if similar scalable
+not be surprising if they do, and it would not be surprising if similar Cray
 vector extensions are introduced in other architectures in the future.
 
-The main differences between scalable and portable vectors are that:
+The main differences between Cray vectors and portable vectors are that:
 
-* the number of lanes of scalable vectors is a run-time dynamic value 
-* the scalable vector "objects" are like magical compiler token values
+* the number of lanes of Cray vectors is a run-time dynamic value 
+* the Cray vector "objects" are like magical compiler token values
 * the induction loop variable must be incremented by the dynamic number of lanes
   of the vector type
-* most scalable vector operations require a mask indicating which elements of
+* most Cray vector operations require a mask indicating which elements of
   the vector the operation applies to
 
-These differences will probably force the API of scalable vector types to be
+These differences will probably force the API of Cray vector types to be
 slightly different than that of packed vector types.
 
-The current RFC, therefore, assumes no interaction with scalable vector types. 
+The current RFC, therefore, assumes no interaction with Cray vector types. 
 
-It does not prevent for portable scalable vector types to be added to Rust in
+It does not prevent for portable Cray vector types to be added to Rust in
 the future via an orthogonal API, nor it does prevent adding a way to interact
 between both of them (e.g. through memory). But at this point in time whether
 these things are possible are open research problems.