The first thing to note is that a "password hash" is not simply a hash of the password, it is a multi-field structure containing not just the hash itself but an indication of what hashing scheme is used and any parameters needed (in the case of bcrypt a salt and a cost parameter)
So the answer to the question of whether an invalid "password hash" results in no working passwords has nothing to do with hash functions, it boils down to how the checking code handles inputs that do not represent a valid password hash in one of the supported formats. One would hope it would consider an invalid hash as non-matching but the documentation isn't clear so we need to read the source.
Reading the code for php's password_verify we find it first calls "php_password_determine_algo", if the password starts with $2y$ it is considered to be "bcrypt", if it starts with "$argon2i$" it is considered to be argon2, otherwise it is considered to be "unknown".
If the hash is "bcrypt" or "unknown" it then moves onto calling php_crypt passing it the password and the hash, this attempts to hash the provided password using the method and salt from the existing password, it can do this either by using an internal implementation or by calling the operating system's crypt function. It seems given an invalid existing hash the internal code will fallback to old-school DES, not sure what the system implementation will do.
Coming back to the unknown/bcrypt section in password_verify it seems that it will fail to match if any of the following are true.
- php_crypt returns an error.
- the length of the hash returned by php_crypt does not match the length of the hash passwed to password_verify
- the hash passed to password_verify is less than 13 characters in length
- the content of the hash returned by php_crypt does not match the content of the hash passed to password_verify
Your hash of "-" will be rejected by at least rule 3 from this list (likely also rule 1 or 2 but that depends on the behaviour of the crypt implementation used).