diff --git a/.gitattributes b/.gitattributes
index eb70025a08..e64417f761 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -6213,6 +6213,7 @@ tests/tbs/tb0524.pp svneol=native#text/x-pascal
 tests/tbs/tb0525.pp svneol=native#text/plain
 tests/tbs/tb0526.pp -text
 tests/tbs/tb0527.pp svneol=native#text/plain
+tests/tbs/tb0528.pp svneol=native#text/x-pascal
 tests/tbs/ub0060.pp svneol=native#text/plain
 tests/tbs/ub0069.pp svneol=native#text/plain
 tests/tbs/ub0119.pp svneol=native#text/plain
diff --git a/tests/tbs/tb0528.pp b/tests/tbs/tb0528.pp
new file mode 100644
index 0000000000..940dd6fa8f
--- /dev/null
+++ b/tests/tbs/tb0528.pp
@@ -0,0 +1,26 @@
+{%CPU=x86_64,ppc64}
+program tb0528;
+
+{This program tests if huge arrays work on 64-bit systems. I got the idea
+ testing this because today I had a Fortran program that didn't work. After
+ inspection it appeared the mad scientist was using arrays > 2GB.
+
+ So, I did a test how well FPC handled such code. Disappointment, FPC
+ did generate wrong code.
+
+ Note that this test does not use huge amounts of memory, as the operating
+ system should allocate a page on write.
+ does not get allocated.}
+
+type huge_array=array[0..$ffffffff] of word;
+
+var a,b,c:huge_array;
+
+begin
+  a[$ffffffff]:=1;
+  b[$ffffffff]:=2;
+  c[$ffffffff]:=3;
+  writeln(a[$ffffffff]);
+  writeln(b[$ffffffff]);
+  writeln(c[$ffffffff]);
+end.
\ No newline at end of file