Skip to content

Commit 90f3314

Browse files
dkljayrm
authored andcommitted
Make Integer/Long mangling consistent on 32bit/64bit
old new 32bit, Integer int long [long] (now consistent with 64bit) 32bit, Long long int (now consistent with 64bit) 64bit, Integer long [long] long [long] (unchanged) 64bit, Long int int (unchanged)
1 parent f081eea commit 90f3314

File tree

2 files changed

+39
-51
lines changed

2 files changed

+39
-51
lines changed

changelog.txt

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,7 @@
11
Version 1.06.0
22

33
[changed]
4+
- Name mangling of Integer/Long parameters was reversed on 32bit to match 64bit, so the same FB and C++ code will be compatible on both 32bit and 64bit. Integer is mangled as C++ long (except on Win64), Long is mangled as C++ int.
45
- Adjusted warning text for "mixed bool/nonbool operands" warning
56
- test-suite uses libfbcunit for unit testing framework
67
- SELECT CASE AS CONST respects data type and will show overflow warnings on out-of-range constants

src/compiler/symb-mangling.bas

Lines changed: 38 additions & 51 deletions
Original file line numberDiff line numberDiff line change
@@ -336,74 +336,61 @@ function hMangleBuiltInType _
336336
return @"8FBSTRING"
337337
end if
338338

339-
if( fbIs64bit( ) ) then
340-
'' By default on x86 we mangle INTEGER to "int", but on 64bit
341-
'' our INTEGER becomes 64bit, while int stays 32bit, so we
342-
'' really shouldn't use the same mangling in that case.
343-
''
344-
'' Mangling the 64bit INTEGER as "long long" would conflict
345-
'' with the LONGINT mangling though (we cannot allow separate
346-
'' INTEGER/LONGINT overloads in code but then generate the same
347-
'' mangled id for them, the assembler/linker would complain).
348-
''
349-
'' Besides that, our LONG stays 32bit always, but "long" on
350-
'' 64bit Linux changes to 64bit, so we shouldn't mangle LONG
351-
'' to "long" in that case. It would still be possible on 64bit
352-
'' Windows, because there "long" stays 32bit, but it seems best
353-
'' to mangle LONG to "int" on 64bit consistently, since "int"
354-
'' stays 32bit on both Linux and Windows.
355-
''
356-
'' That allows 64bit INTEGER to be mangled as 64bit long on
357-
'' Linux & co, making GCC compatibility easier, it's only Win64
358-
'' where we need a custom mangling.
359-
''
360-
'' Itanium C++ ABI compatible mangling of non-C++ built-in
361-
'' types (vendor extended types):
339+
''
340+
'' Integer/Long mangling:
341+
''
342+
'' 32bit 64bit
343+
'' Integer long long (Unix) or INTEGER (Windows)
344+
'' Long int int
345+
'' LongInt long long long long
346+
''
347+
'' - Fundamental problem: FB and C++ types are different, an exact mapping
348+
'' is impossible
349+
''
350+
'' - mangling should match the C/C++ binding recommendations, i.e. use Long
351+
'' for int and Integer for things like ssize_t. On linux-x86_64 Integer
352+
'' can be mangled as long, but on win64 the only 64bit integer type is
353+
'' long long and that's already used for LongInt. So it seems that we have
354+
'' to use a custom mangling for that case (INTEGER).
355+
''
356+
'' - 32bit fbc used to mangle Integer as int and Long as long, but to match
357+
'' 64bit fbc it was reversed, allowing the same FB and C++ code to work
358+
'' together on both 32bit and 64bit.
359+
''
360+
if( fbIs64bit( ) and ((env.target.options and FB_TARGETOPT_UNIX) = 0) ) then
361+
'' Windows 64bit
362+
'' Itanium C++ ABI compatible mangling of non-C++ built-in types (vendor extended types):
362363
'' u <length-of-id> <id>
363-
364-
if( env.target.options and FB_TARGETOPT_UNIX ) then
365-
select case( dtype )
366-
case FB_DATATYPE_INTEGER : return @"l" '' long
367-
case FB_DATATYPE_UINT : return @"m" '' unsigned long
368-
end select
369-
else
370-
select case( dtype )
371-
case FB_DATATYPE_INTEGER : add_abbrev = TRUE : return @"u7INTEGER" '' seems like a good choice
372-
case FB_DATATYPE_UINT : add_abbrev = TRUE : return @"u8UINTEGER"
373-
end select
374-
end if
375-
376364
select case( dtype )
377-
case FB_DATATYPE_LONG : return @"i" '' int
378-
case FB_DATATYPE_ULONG : return @"j" '' unsigned int
365+
case FB_DATATYPE_INTEGER : add_abbrev = TRUE : return @"u7INTEGER" '' seems like a good choice
366+
case FB_DATATYPE_UINT : add_abbrev = TRUE : return @"u8UINTEGER"
379367
end select
380368
else
369+
'' 32bit, Unix 64bit
381370
select case( dtype )
382-
case FB_DATATYPE_INTEGER : return @"i" '' int
383-
case FB_DATATYPE_UINT : return @"j" '' unsigned int
384-
case FB_DATATYPE_LONG : return @"l" '' long
385-
case FB_DATATYPE_ULONG : return @"m" '' unsigned long
371+
case FB_DATATYPE_INTEGER : return @"l" '' long
372+
case FB_DATATYPE_UINT : return @"m" '' unsigned long
386373
end select
387374
end if
388375

389376
static as zstring ptr typecodes(0 to FB_DATATYPES-1) => _
390377
{ _
391378
@"v", _ '' void
392379
@"b", _ '' boolean
393-
@"a", _ '' byte (signed char)
394-
@"h", _ '' ubyte (unsigned char)
380+
@"a", _ '' Byte: signed char
381+
@"h", _ '' UByte: unsigned char
395382
@"c", _ '' char
396383
@"s", _ '' short
397384
@"t", _ '' ushort
398385
@"w", _ '' wchar
399-
NULL, _ '' integer
400-
NULL, _ '' uinteger
386+
NULL, _ '' Integer
387+
NULL, _ '' UInteger
401388
NULL, _ '' enum
402-
NULL, _ '' long
403-
NULL, _ '' ulong
404-
@"x", _ '' longint (long long)
405-
@"y", _ '' ulongint (unsigned long long)
406-
@"f", _ '' single
389+
@"i", _ '' Long: int
390+
@"j", _ '' ULong: unsigned int
391+
@"x", _ '' LongInt: long long
392+
@"y", _ '' ULongInt: unsigned long long
393+
@"f", _ '' Single: float
407394
@"d", _ '' double
408395
NULL, _ '' var-len string
409396
NULL, _ '' fix-len string

0 commit comments

Comments
 (0)