Vertex shader stops passing values on AMD Hardware

Hey,

we stumbled into a strange issue with our software and AMD hardware/drivers.

We are rendering large amounts of point cloud data and noticed that on our AMD system (R7 370 with Radeon v18.3.1, Win10) most of the point cloud will be flickering or black.
Closer examination via Renderdoc showed that the color data is copied and passed to the the Vertex shader, but after the 4096th element in the memory it just stops outputting the color attribute data it receives.
It also surfaced the two following warnings (VERTEX_ATTRIB[0] is the color attribute):

Neither of that is present when the program is run on our Nvidia GPU (Gtx 980, Win10).
Changing the stride to 4 "solves" the problem in the way that the color values are passed and the flickering stops, but passing an additional byte for every color and increasing the data size seems a bit excessive to me. Especially as passing colors in RBG888 as a vertex attribute doesn't seem very exotic to me.

Are we doing something wrong in OpenGL and encountering unspecified behaviour (that works with Nvidia by chance) or is there some issue with the AMD driver?
Has any of you encountered something similiar?

We wrote a minimal version demonstrating the problem. I will post the relevant code for rendering below, but if you want to have a closer look or build it yourself you can find it here. If it shows a white dot everything is fine, if the dot flickers you've got the same problem as us.

we stumbled into a strange issue with our software and AMD hardware/drivers.

We are rendering large amounts of point cloud data and noticed that on our AMD system (R7 370 with Radeon v18.3.1, Win10)
most of the point cloud will be flickering or black.
...
It also surfaced the two following warnings (VERTEX_ATTRIB[0] is the color attribute):

Neither of that is present when the program is run on our Nvidia GPU (Gtx 980, Win10).
Changing the stride to 4 "solves" the problem in the way that the color values are passed and the flickering stops, but passing an additional byte for every color and increasing the data size seems a bit excessive to me. ...

Are we doing something wrong in OpenGL and encountering unspecified behaviour (that works with Nvidia by chance) or is there some issue with the AMD driver?
...
Additional Information:
GLVendor: ATI Technologies Inc.
GLVersion: 3.2.13507 Core Profile Forward-Compatible Context 23.20.15027.1004
GLRenderer:AMD Radeon (TM) R7 370 Series

That's interesting. Sure looks like a driver bug in its reading of normalized UBYTE[3] vertex attributes (what you're doing with the color attrib looks reasonable to me). A perf warning that this format might be suboptimal for the driver seems reasonable, but failing to convert the format properly? Not cool.

I see that this came up with the AMD/ATI drivers 9 years ago with glColorPointer LINK), but there was a comment that this was fixed.

You might generate a short stand-alone repro case and submit it to the AMD driver folks for a fix.

If we change the OpenGL profile from Core to Compatibility everything works as expected.
No real solution, but probably a reasonable workaround for us and everyone else who experiences this behaviour, till it is fixed.