That really depends on the hack. Maybe it's fragile because it is building based on a bug, and if the library changes, the code will have to be updated. Or perhaps it's there based on bad behavior of a chip and a hardware update could change the nature of the issue (say, it relies on a particular instruction that's generated by the particular compiler in use to happen just before the code in question).

A hack could be completely reliable (for the same hardware, library versions, and compiler), but still be a "dirty hack". And whether a hack is "dirty" is very subjective and, IMO, based more on how obvious the fix is (e.g. radians -> degrees -> function -> back to radians because the library documentation is wrong is less bad than a non-obvious hack like multiplying by 1 or something to avoid a compiler codegen bug because of a hardware bug).

I think this horse has been thoroughly beaten, so I'll leave it here.