* [patch] Fortran: fix prototype for class vptr fields
@ 2020-09-06 11:12 FX
2020-09-06 16:11 ` Thomas Koenig
0 siblings, 1 reply; 3+ messages in thread
From: FX @ 2020-09-06 11:12 UTC (permalink / raw)
To: gcc-patches, Iain Sandoe; +Cc: fortran
[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]
Hi,
Attached is a patch fixing the problem at: https://gcc.gnu.org/pipermail/fortran/2020-September/054978.html
the reasoning behind the solution is explained here: https://gcc.gnu.org/pipermail/fortran/2020-September/054997.html
In short, calls to class copy functions are made with wrong function type:
<function_type 0x14461be70
type <void_type 0x14460ff18 void VOID
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x14460ff18
pointer_to_this <pointer_type 0x144617000>>
SI
size <integer_cst 0x144602eb8 type <integer_type 0x14460f0a8 bitsizetype> constant 32>
unit-size <integer_cst 0x144602ed0 type <integer_type 0x14460f000 sizetype> constant 4>
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x14461be70
arg-types <tree_list 0x1446097f8 value <void_type 0x14460ff18 void>>
pointer_to_this <pointer_type 0x14461bf18>>
where the arg-types is (void) instead of being undefined (like K&R functions). This has no apparent consequences on current targets, but it leads to wrong code generation for aarch64-apple-darwin20.
The attached patch fixes this. The patch is regtested on x86_64-apple-darwin19.
I also tested it on aarch64-apple-darwin20 (Iain’s current port based on trunk at https://github.com/iains/gcc-darwin-arm64) where it brings the number of test failures down from 811 to 166!
OK to commit?
FX
[-- Attachment #2: ppc_type.diff --]
[-- Type: application/octet-stream, Size: 408 bytes --]
diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c
index d38aa2865ae..a05633e827c 100644
--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -2435,7 +2435,7 @@ gfc_get_ppc_type (gfc_component* c)
else
t = void_type_node;
- return build_pointer_type (build_function_type_list (t, NULL_TREE));
+ return build_pointer_type (build_function_type (t, NULL_TREE));
}
[-- Attachment #3: ppc_type.ChangeLog --]
[-- Type: application/octet-stream, Size: 108 bytes --]
2020-09-06 Francois-Xavier Coudert <fxcoudert@gcc.gnu.org>
(gfc_get_ppc_type): Fix function arg types.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [patch] Fortran: fix prototype for class vptr fields
2020-09-06 11:12 [patch] Fortran: fix prototype for class vptr fields FX
@ 2020-09-06 16:11 ` Thomas Koenig
2020-09-06 16:37 ` FX
0 siblings, 1 reply; 3+ messages in thread
From: Thomas Koenig @ 2020-09-06 16:11 UTC (permalink / raw)
To: FX, gcc-patches, Iain Sandoe; +Cc: fortran
Am 06.09.20 um 13:12 schrieb FX via Fortran:
Hi FX,
> OK to commit?
The patch is OK in principle, I have also regtested it on POWER (which
is also somethat picky about calling conventions). However, in an
ideal world, this should only be a temporary fix.
Could you maybe put a FIXME at that place, explaining that we are
in fact following K&R conventions there and what we would need
to correc the function decl to use build_function_type_list?
Thanks for the fix!
Best regards
Thomas
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [patch] Fortran: fix prototype for class vptr fields
2020-09-06 16:11 ` Thomas Koenig
@ 2020-09-06 16:37 ` FX
0 siblings, 0 replies; 3+ messages in thread
From: FX @ 2020-09-06 16:37 UTC (permalink / raw)
To: Thomas Koenig; +Cc: gcc-patches, Iain Sandoe, fortran
> Could you maybe put a FIXME at that place, explaining that we are
> in fact following K&R conventions there and what we would need
> to correc the function decl to use build_function_type_list?
Done.
FX
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-09-06 16:37 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-06 11:12 [patch] Fortran: fix prototype for class vptr fields FX
2020-09-06 16:11 ` Thomas Koenig
2020-09-06 16:37 ` FX
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).