Explanation

Prec. denotes operator precedence, where group 1 has the highest precedence and group 17 the lowest.

Assoc. denotes operator associativity, where such is applicable. Associativity can be either left-to-right or right-to-left.

Sources

My ambition with this post is to provide a operator precedence table on-site at Stack Overflow, which is correct and canonical. This operator precedence table corresponds directly to chapter 6.5 of ISO 9899:2011, where we can read (6.5/3):

The grouping of operators and operands is indicated by the syntax. 85)

And then as a comment, in the informative (not normative) foot note:

85) The syntax specifies the precedence of operators in the evaluation of an expression, which is the same as the order of the major subclauses of this subclause, highest precedence first. /--/

Within each major subclause, the operators have the same precedence. Left- or right-associativity is indicated in each subclause by the syntax for the expressions discussed therein.

All formal operator names from the table are taken from chapter 6.5, where such a name could be found in normative text. Informal names were included in the cases where the programmer community might be more familiar with another name than the one given in the standard.

The precedence should be the same as it is in C, for several reasons.

C got it right

C got the relative precedences for these operators right*, so there's nothing to fix by changing it:

• ~ has the highest precedence, by analogy with logical operators. It's also very common to use ~ to invert a mask that you want to apply with &, so ~ should have higher precedence than &.
• Shifts have the next-highest because usually one or both sides are literals or other fixed constants, i.e. things which require no bitwise operations to compute. Shifts are also analogous to exponentiation (1 << n equals 2 ** n) which has a high precedence in arithmetic.
• & has lower precedence than shifts because often you want to shift something to the correct position, and then use & to keep just some of the bits, like x >> offset & mask. If the mask is something like 0xFF then you can clearly see that the result will only have the lowest 8 bits; this is more readable than (x & mask) >> offset because the mask no longer shows which bits might be set in the result.
• ^ and | have lower precedence than & both by analogy to logical operators, and because it's common to use them to combine the results of multiple shifts or masked-shifts. The relative precedence of ^ and | doesn't have much practical importance because there are few reasons to use them together.

*By "right", I mean C avoids requiring parentheses as much as possible for the most common uses of bitwise operators, and also matches the relative precedences of analogous operators in mathematics. Of course there's some room for debate over which uses are most common and which mathematical operators are more analogous, but no design rationale can be perfectly objective.

Compatibility with C is important

There are a lot of clever things you can do with bitwise operators, but most programmers will not invent their own new clever things. If people use bitwise operators, it's mostly in code they copy-paste from Stack Overflow, or popular articles such as this one.

These sources will invariably assume C's precedence rules for bitwise operators, either because they are written in C, or because they are written in other languages with the same precedence rules for bitwise operators (and that's every other popular language with bitwise operators, as far as I know).

Therefore, your users' interests are best served by not adding an extra step that must be taken when translating such code into your language, particularly an extra step which users don't necessarily know they need to take.

Users won't learn the precedences

For bitwise operators (and sometimes even boolean logical operators!) it's often recommended to use parentheses to clarify the order of operations, even when parentheses would be redundant. Because even if you know the bitwise operator precedences, most of the people who will read your code do not.

The vast majority of programmers do not use these operators very often, and will not spend the effort to memorise their precedences. (This is especially the case for the relative precedences of bitwise and non-bitwise operators, like << and +.) So, if people will use brackets anyway, you don't gain anything by giving them different precedences. Put another way, this isn't an efficient use of your language's strangeness budget.