Le 08/01/2025 à 14:13, Jakub Jelinek a écrit :
On Wed, Jan 08, 2025 at 01:40:20PM +0100, Mikael Morin wrote:
Le 08/01/2025 à 11:42, Jakub Jelinek a écrit :
The full list of changes with the posted patches is
(first a.mod, then b.mod, 14 -> 15) below.
I have no idea what adds those __copy_* elts etc. and whether they could be
forced to be in the middle rather than at the end and what is an ABI break
and what is not.
I think the numbers starting symbol definitions don't matter, the numbers
represent pointers, so what matters is the structure, not the value; that is
the number can change, and in that case it should be changed everywhere it
is used.
This is only true for numbers representing pointers and especially
symbol pointers, that is number that start a symbol definition (like 10
in front of 'C_funptr' or 30 in front of
'__copy__iso_c_binding_C_funptr' in your excerpt below), or other places
with symbol pointers.
All I know is that
--- xc_f03_lib_m.mod 2025-01-07 18:47:44.155602052 +0100
+++ xc_f03_lib_m.mod 2025-01-07 18:47:53.307400792 +0100
@@ -647,12 +647,12 @@ UNKNOWN-PROC UNKNOWN IMPLICIT-SAVE 0 0)
UNKNOWN UNKNOWN 0 0 IS_BIND_C IS_C_INTEROP PRIVATE_COMP) ((818 'c_address'
(INTEGER 8 0 1 0 INTEGER ()) () () () (UNKNOWN-FL UNKNOWN-INTENT
UNKNOWN-PROC UNKNOWN UNKNOWN 0 0) PRIVATE ())) PRIVATE (DERIVED 6 0 1 1
-VOID ()) 0 0 () () 0 () () () 2 42 0)
+VOID ()) 0 0 () () 0 () () () 2 63 0)
10 'C_funptr' '__iso_c_binding' '' 1 ((DERIVED UNKNOWN-INTENT
UNKNOWN-PROC UNKNOWN UNKNOWN 0 0 IS_BIND_C IS_C_INTEROP PRIVATE_COMP) (
(819 'c_address' (INTEGER 8 0 1 0 INTEGER ()) () () () (UNKNOWN-FL
UNKNOWN-INTENT UNKNOWN-PROC UNKNOWN UNKNOWN 0 0) PRIVATE ())) PRIVATE (
-DERIVED 10 0 1 1 VOID ()) 0 0 () () 0 () () () 2 44 0)
+DERIVED 10 0 1 1 VOID ()) 0 0 () () 0 () () () 2 65 0)
30 '__copy___iso_c_binding_C_funptr' 'xc_f03_lib_m' '' 820 ((PROCEDURE
UNKNOWN-INTENT UNKNOWN-PROC DECL UNKNOWN 0 0 ARTIFICIAL SUBROUTINE
ELEMENTAL PURE ALWAYS_EXPLICIT) () (UNKNOWN 0 0 0 0 UNKNOWN ()) 0 0 (
changes in libxc-devel xc_f03_lib_m.mod cause various ICEs as I wrote in the
PR when using the GCC 14 compiled mod file with GCC 15.
Sure, but here, the modified value doesn't represent a symbol pointer,
so what I said above doesn't apply. I think it is the int_mod_sym_id
value that changed, and we should try to avoid that for compatibility
(which your patch does).
I think your patch is enough, we don't need to target same-bytes formats
between module versions.
