The PCLK can be the system clock which is on L4 up to 80MHz. Multiply 80MHz by 256 is larger than 2**32. Is there a better way to solve this problem?

If this is the only location where 64-bit integer arith is used, then it would be good to find an alternative. For example, pre-dividing the clock by 8 and post-multiplying the answer by 8 should work.

I modified stm32l4xx_hal_uart.h in the way you proposed and therefore removed the inclusion of libgcc in the stm32l4 build. With a little python program I calculated the devision of the calculations:
Old:
(((__PCLK__)*256)/((__BAUD__)))
New:
((((__PCLK__)<<5)/((__BAUD__)))<<3)
With the old code the maximal deviation (expected Baud)/(real Baud) is about 0.06%. For the new code we will raise up to 0.523%. So do not transmit more than 11 Bytes in one go.

This modification is put in a separate commit to see the changes done to the vanilla HAL (as proposed by dhylands).

If the maximum for PCLK is 80MHz, would it be better to do (PCLK<<7 / BAUD) <<1? Less error and no overflow?

2**32/80E6=53.6870912. So the maximal shift up is floor(log(2**32/80E6 )/log(2)) = 5 or factor 32.

This is not a good solution, we don't want to lose precision like this. The BRR register is actually only 20-bits wide, and one can write a custom division routine, something like:

uint32_t div = pclk / 0x1000000 + 1;
pclk /= div;
baud /= div;
brr = 256 * pclk / baud; // won't overflow

This code removes a common factor between pclk and baud before doing the large division. For pclk=80MHz it'll divide the two variables through by 5, which is enough to make sure 256 * pclk doesn't overflow an unsigned 32-bit int.

Solution which works for any frequency from 32768...4294967295 (2**32-1) is checked in to #1890.

Merged in 69f26c6.