Yes and no. They are slightly different things.
concat() is a built-in. The signature in system.fpd is how it is visible to the programmer:
Function Concat (Const S1,S2,S3,Sn : String) : String;
Afaik the implementation of it is mostly done in compiler units ninl and pinline
Compilerprocs are functions called by code generated by the compiler.
There is a relation of course, since code for built-ins are generated by the compiler, and the more complex ones need to call helpers which are compilerprocs.
Concat is such function, and grepping for it in combo with compilerproc will give you prototypes like (partial grep output:)
sstrings.inc:fpc_AnsiStr_ShortStr_Concat (Var S1: AnsiString; Var S2 : ShortString); compilerproc;
compproc.inc:Procedure fpc_WideStr_Concat (Var DestS : Widestring;const S1,S2 : WideString); compilerproc;
compproc.inc:Procedure fpc_WideStr_Concat_multi (Var DestS : Widestring;const sarr:array of Widestring); compilerproc;
compproc.inc:Procedure fpc_UnicodeStr_Concat (Var DestS : Unicodestring;const S1,S2 : UnicodeString); compilerproc;
compproc.inc:Procedure fpc_UnicodeStr_Concat_multi (Var DestS : Unicodestring;const sarr:array of Unicodestring); compilerproc;
generic.inc:procedure fpc_shortstr_concat(var dests:shortstring;const s1,s2:shortstring);compilerproc;
generic.inc:procedure fpc_shortstr_concat_multi(var dests:shortstring;const sarr:array of pshortstring);compilerproc;
Note that the compilerproc helper might only be part of the built-in implementation, code may also have been generated inline.
Note also that the built-in declaration is declared as "string", while in reality accepts all string types. That is the limitation of system.fpd (or actually, fpdoc that must process it). Grepping the compilerprocs is then a way to get a feel what is really supported.