* [PATCH] Handle OPAQUE_TYPE specially in verify_type [PR106833] @ 2022-09-08 5:53 Kewen.Lin 2022-09-08 7:36 ` Richard Biener 0 siblings, 1 reply; 8+ messages in thread From: Kewen.Lin @ 2022-09-08 5:53 UTC (permalink / raw) To: GCC Patches; +Cc: Richard Biener, Segher Boessenkool, Peter Bergner Hi, As PR106833 shows, cv-qualified opaque type can cause ICE during LTO. It exposes that we missd to handle OPAQUE_TYPE well in type verification. As Richi pointed out, also assuming that target will always define TYPE_MAIN_VARIANT and TYPE_CANONICAL for opaque type, this patch is to check both are OPAQUE_TYPE_P. Besides, it also checks the only available size and alignment information as well as type mode for TYPE_MAIN_VARIANT. Bootstrapped and regtested on powerpc64-linux-gnu P7 and powerpc64le-linux-gnu P9 and P10. Is it ok for trunk? BR, Kewen ----- PR middle-end/106833 gcc/ChangeLog: * tree.cc (verify_opaque_type): New function. (verify_match): New macro. (verify_type): Call verify_opaque_type for OPAQUE_TYPE. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr106833.c: New test. --- gcc/testsuite/gcc.target/powerpc/pr106833.c | 14 +++++++ gcc/tree.cc | 45 ++++++++++++++++++++- 2 files changed, 58 insertions(+), 1 deletion(-) create mode 100644 gcc/testsuite/gcc.target/powerpc/pr106833.c diff --git a/gcc/testsuite/gcc.target/powerpc/pr106833.c b/gcc/testsuite/gcc.target/powerpc/pr106833.c new file mode 100644 index 00000000000..968d75184ff --- /dev/null +++ b/gcc/testsuite/gcc.target/powerpc/pr106833.c @@ -0,0 +1,14 @@ +/* { dg-do link } */ +/* { dg-require-effective-target power10_ok } */ +/* { dg-require-effective-target lto } */ +/* { dg-options "-flto -mdejagnu-cpu=power10" } */ + +/* Verify there is no ICE in LTO mode. */ + +int main () +{ + float *b; + const __vector_quad c; + __builtin_mma_disassemble_acc (b, &c); + return 0; +} diff --git a/gcc/tree.cc b/gcc/tree.cc index fed1434d141..e67caa8f85d 100644 --- a/gcc/tree.cc +++ b/gcc/tree.cc @@ -13670,6 +13670,42 @@ gimple_canonical_types_compatible_p (const_tree t1, const_tree t2, } } +/* For OPAQUE_TYPE T, it has only size and alignment information, so verify + these properties of T match TV which is the main variant of T. Also + verify the type of TC, which is the canonical of T, is OPAQUE_TYPE. */ + +static void +verify_opaque_type (const_tree t, tree tv, tree tc) +{ + gcc_assert (OPAQUE_TYPE_P (t)); + gcc_assert (tv && tv == TYPE_MAIN_VARIANT (tv)); + gcc_assert (tc && tc == TYPE_CANONICAL (tc)); + +#define verify_match(flag, t, tv) \ + do \ + { \ + if (flag (t) != flag (tv)) \ + { \ + error ("opaque type differs by %s", #flag); \ + debug_tree (tv); \ + } \ + } \ + while (false) + + if (t != tv) + { + verify_match (TREE_CODE, t, tv); + verify_match (TYPE_MODE, t, tv); + verify_match (TYPE_SIZE, t, tv); + verify_match (TYPE_ALIGN, t, tv); + verify_match (TYPE_USER_ALIGN, t, tv); + } + + if (t != tc) + verify_match (TREE_CODE, t, tc); +#undef verify_match +} + /* Verify type T. */ void @@ -13677,6 +13713,14 @@ verify_type (const_tree t) { bool error_found = false; tree mv = TYPE_MAIN_VARIANT (t); + tree ct = TYPE_CANONICAL (t); + + if (OPAQUE_TYPE_P (t)) + { + verify_opaque_type (t, mv, ct); + return; + } + if (!mv) { error ("main variant is not defined"); @@ -13691,7 +13735,6 @@ verify_type (const_tree t) else if (t != mv && !verify_type_variant (t, mv)) error_found = true; - tree ct = TYPE_CANONICAL (t); if (!ct) ; else if (TYPE_CANONICAL (ct) != ct) -- 2.27.0 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] Handle OPAQUE_TYPE specially in verify_type [PR106833] 2022-09-08 5:53 [PATCH] Handle OPAQUE_TYPE specially in verify_type [PR106833] Kewen.Lin @ 2022-09-08 7:36 ` Richard Biener 2022-09-09 6:51 ` [PATCH v2] " Kewen.Lin 0 siblings, 1 reply; 8+ messages in thread From: Richard Biener @ 2022-09-08 7:36 UTC (permalink / raw) To: Kewen.Lin; +Cc: GCC Patches, Segher Boessenkool, Peter Bergner > Am 08.09.2022 um 07:53 schrieb Kewen.Lin <linkw@linux.ibm.com>: > > Hi, > > As PR106833 shows, cv-qualified opaque type can cause ICE > during LTO. It exposes that we missd to handle OPAQUE_TYPE > well in type verification. As Richi pointed out, also > assuming that target will always define TYPE_MAIN_VARIANT > and TYPE_CANONICAL for opaque type, this patch is to check > both are OPAQUE_TYPE_P. Besides, it also checks the only > available size and alignment information as well as type > mode for TYPE_MAIN_VARIANT. > > Bootstrapped and regtested on powerpc64-linux-gnu P7 and > powerpc64le-linux-gnu P9 and P10. > > Is it ok for trunk? > > BR, > Kewen > ----- > PR middle-end/106833 > > gcc/ChangeLog: > > * tree.cc (verify_opaque_type): New function. > (verify_match): New macro. > (verify_type): Call verify_opaque_type for OPAQUE_TYPE. > > gcc/testsuite/ChangeLog: > > * gcc.target/powerpc/pr106833.c: New test. > --- > gcc/testsuite/gcc.target/powerpc/pr106833.c | 14 +++++++ > gcc/tree.cc | 45 ++++++++++++++++++++- > 2 files changed, 58 insertions(+), 1 deletion(-) > create mode 100644 gcc/testsuite/gcc.target/powerpc/pr106833.c > > diff --git a/gcc/testsuite/gcc.target/powerpc/pr106833.c b/gcc/testsuite/gcc.target/powerpc/pr106833.c > new file mode 100644 > index 00000000000..968d75184ff > --- /dev/null > +++ b/gcc/testsuite/gcc.target/powerpc/pr106833.c > @@ -0,0 +1,14 @@ > +/* { dg-do link } */ > +/* { dg-require-effective-target power10_ok } */ > +/* { dg-require-effective-target lto } */ > +/* { dg-options "-flto -mdejagnu-cpu=power10" } */ > + > +/* Verify there is no ICE in LTO mode. */ > + > +int main () > +{ > + float *b; > + const __vector_quad c; > + __builtin_mma_disassemble_acc (b, &c); > + return 0; > +} > diff --git a/gcc/tree.cc b/gcc/tree.cc > index fed1434d141..e67caa8f85d 100644 > --- a/gcc/tree.cc > +++ b/gcc/tree.cc > @@ -13670,6 +13670,42 @@ gimple_canonical_types_compatible_p (const_tree t1, const_tree t2, > } > } > > +/* For OPAQUE_TYPE T, it has only size and alignment information, so verify > + these properties of T match TV which is the main variant of T. Also > + verify the type of TC, which is the canonical of T, is OPAQUE_TYPE. */ > + > +static void > +verify_opaque_type (const_tree t, tree tv, tree tc) > +{ > + gcc_assert (OPAQUE_TYPE_P (t)); > + gcc_assert (tv && tv == TYPE_MAIN_VARIANT (tv)); > + gcc_assert (tc && tc == TYPE_CANONICAL (tc)); > + > +#define verify_match(flag, t, tv) \ > + do \ > + { \ > + if (flag (t) != flag (tv)) \ > + { \ > + error ("opaque type differs by %s", #flag); \ > + debug_tree (tv); \ > + } \ > + } \ > + while (false) > + > + if (t != tv) > + { > + verify_match (TREE_CODE, t, tv); > + verify_match (TYPE_MODE, t, tv); > + verify_match (TYPE_SIZE, t, tv); TYPE_SIZE is a tree, you should probably Compare this with operand_equal_p. It’s Not documented to be a constant size? Thus some VLA vector mode might be allowed ( a poly_int size), BLKmode Is ruled out(?), the docs say we have ‚An MODE_Opaque‘ here but I don’t see This being verified? The macro makes this a bit unworldly For the only benefit of elaborate diagnostic Which I think isn’t really necessary > + verify_match (TYPE_ALIGN, t, tv); > + verify_match (TYPE_USER_ALIGN, t, tv); > + } > + > + if (t != tc) > + verify_match (TREE_CODE, t, tc); > +#undef verify_match > +} > + > /* Verify type T. */ > > void > @@ -13677,6 +13713,14 @@ verify_type (const_tree t) > { > bool error_found = false; > tree mv = TYPE_MAIN_VARIANT (t); > + tree ct = TYPE_CANONICAL (t); > + > + if (OPAQUE_TYPE_P (t)) > + { > + verify_opaque_type (t, mv, ct); > + return; > + } > + > if (!mv) > { > error ("main variant is not defined"); > @@ -13691,7 +13735,6 @@ verify_type (const_tree t) > else if (t != mv && !verify_type_variant (t, mv)) > error_found = true; > > - tree ct = TYPE_CANONICAL (t); > if (!ct) > ; > else if (TYPE_CANONICAL (ct) != ct) > -- > 2.27.0 > ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v2] Handle OPAQUE_TYPE specially in verify_type [PR106833] 2022-09-08 7:36 ` Richard Biener @ 2022-09-09 6:51 ` Kewen.Lin 2022-09-09 7:25 ` Richard Biener 0 siblings, 1 reply; 8+ messages in thread From: Kewen.Lin @ 2022-09-09 6:51 UTC (permalink / raw) To: Richard Biener; +Cc: GCC Patches, Segher Boessenkool, Peter Bergner [-- Attachment #1: Type: text/plain, Size: 2147 bytes --] Hi Richi, Thanks for the review comments! on 2022/9/8 15:36, Richard Biener wrote: > > >> Am 08.09.2022 um 07:53 schrieb Kewen.Lin <linkw@linux.ibm.com>: >> >> Hi, >> >> As PR106833 shows, cv-qualified opaque type can cause ICE >> during LTO. It exposes that we missd to handle OPAQUE_TYPE >> well in type verification. As Richi pointed out, also >> assuming that target will always define TYPE_MAIN_VARIANT >> and TYPE_CANONICAL for opaque type, this patch is to check >> both are OPAQUE_TYPE_P. Besides, it also checks the only >> available size and alignment information as well as type >> mode for TYPE_MAIN_VARIANT. >> ... >> + >> + if (t != tv) >> + { >> + verify_match (TREE_CODE, t, tv); >> + verify_match (TYPE_MODE, t, tv); >> + verify_match (TYPE_SIZE, t, tv); > > TYPE_SIZE is a tree, you should probably > Compare this with operand_equal_p. It’s > Not documented to be a constant size? > Thus some VLA vector mode might be allowed ( a poly_int size), Thanks for catching, I was referencing the code in function verify_type_variant, that corresponding part seems imperfect: if (TREE_CODE (TYPE_SIZE (t)) != PLACEHOLDER_EXPR && TREE_CODE (TYPE_SIZE (tv)) != PLACEHOLDER_EXPR) verify_variant_match (TYPE_SIZE); I agree poly_int size is allowed, the patch was updated for it. BLKmode > Is ruled out(?), Yes, it requires a mode of MODE_OPAQUE class. the docs say we have > ‚An MODE_Opaque‘ here but I don’t see > This being verified? > There is a MODE equality check, I assumed the given t already has one MODE_OPAQUE mode, but the patch was updated to make it explicit as you concerned. > The macro makes this a bit unworldly > For the only benefit of elaborate diagnostic > Which I think isn’t really necessary OK, fixed! The previous version makes just one check on TYPE_CANONICAL to be cheap as gimple_canonical_types_compatible_p said, but since there are just several fields to be check, this updated version adjusted it to be the same as what's for TYPE_MAIN_VARIANT. Hope it's fine. :) Tested as before. Does this updated patch look good to you? BR, Kewen ------ [-- Attachment #2: 0001-Handle-OPAQUE_TYPE-specially-in-verify_type-PR106833.patch --] [-- Type: text/plain, Size: 4401 bytes --] From 4a905fcb2abcc4e488d90011dd2c2125fb9e14b2 Mon Sep 17 00:00:00 2001 From: Kewen Lin <linkw@linux.ibm.com> Date: Thu, 8 Sep 2022 21:34:29 -0500 Subject: [PATCH] Handle OPAQUE_TYPE specially in verify_type [PR106833] As PR106833 shows, cv-qualified opaque type can cause ICE during LTO. It exposes that we missd to handle OPAQUE_TYPE well in type verification. As Richi pointed out, also assuming that target will always define TYPE_MAIN_VARIANT TYPE_CANONICAL for opaque type, this patch is to check both are OPAQUE_TYPE_P and their modes are of MODE_OPAQUE class. Besides, it also checks the only available size and alignment information. PR middle-end/106833 gcc/ChangeLog: * tree.cc (verify_opaque_type): New function. (verify_type): Call verify_opaque_type for OPAQUE_TYPE. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr106833.c: New test. --- gcc/testsuite/gcc.target/powerpc/pr106833.c | 14 ++++ gcc/tree.cc | 74 ++++++++++++++++++++- 2 files changed, 87 insertions(+), 1 deletion(-) create mode 100644 gcc/testsuite/gcc.target/powerpc/pr106833.c diff --git a/gcc/testsuite/gcc.target/powerpc/pr106833.c b/gcc/testsuite/gcc.target/powerpc/pr106833.c new file mode 100644 index 00000000000..968d75184ff --- /dev/null +++ b/gcc/testsuite/gcc.target/powerpc/pr106833.c @@ -0,0 +1,14 @@ +/* { dg-do link } */ +/* { dg-require-effective-target power10_ok } */ +/* { dg-require-effective-target lto } */ +/* { dg-options "-flto -mdejagnu-cpu=power10" } */ + +/* Verify there is no ICE in LTO mode. */ + +int main () +{ + float *b; + const __vector_quad c; + __builtin_mma_disassemble_acc (b, &c); + return 0; +} diff --git a/gcc/tree.cc b/gcc/tree.cc index fed1434d141..b755cd5083a 100644 --- a/gcc/tree.cc +++ b/gcc/tree.cc @@ -13670,6 +13670,71 @@ gimple_canonical_types_compatible_p (const_tree t1, const_tree t2, } } +/* For OPAQUE_TYPE T, it should have only size and alignment information + and its mode should be of class MODE_OPAQUE. This function verifies + these properties of T match TV which is the main variant of T and TC + which is the canonical of T. */ + +static void +verify_opaque_type (const_tree t, tree tv, tree tc) +{ + gcc_assert (OPAQUE_TYPE_P (t)); + gcc_assert (tv && tv == TYPE_MAIN_VARIANT (tv)); + gcc_assert (tc && tc == TYPE_CANONICAL (tc)); + + /* For an opaque type T1, check if some of its properties match + the corresponding ones of the other opaque type T2, emit some + error messages for those inconsistent ones. */ + auto check_properties_for_opaque_type = [](const_tree t1, tree t2, + const char *kind_msg) + { + if (!OPAQUE_TYPE_P (t2)) + { + error ("type %s is not an opaque type", kind_msg); + debug_tree (t2); + return; + } + if (!OPAQUE_MODE_P (TYPE_MODE (t2))) + { + error ("type %s is not with opaque mode", kind_msg); + debug_tree (t2); + return; + } + if (TYPE_MODE (t1) != TYPE_MODE (t2)) + { + error ("type %s differs by %<TYPE_MODE%>", kind_msg); + debug_tree (t2); + return; + } + poly_uint64 t1_size = tree_to_poly_uint64 (TYPE_SIZE (t1)); + poly_uint64 t2_size = tree_to_poly_uint64 (TYPE_SIZE (t2)); + if (maybe_ne (t1_size, t2_size)) + { + error ("type %s differs by %<TYPE_SIZE%>", kind_msg); + debug_tree (t2); + return; + } + if (TYPE_ALIGN (t1) != TYPE_ALIGN (t2)) + { + error ("type %s differs by %<TYPE_ALIGN%>", kind_msg); + debug_tree (t2); + return; + } + if (TYPE_USER_ALIGN (t1) != TYPE_USER_ALIGN (t2)) + { + error ("type %s differs by %<TYPE_USER_ALIGN%>", kind_msg); + debug_tree (t2); + return; + } + }; + + if (t != tv) + check_properties_for_opaque_type (t, tv, "variant"); + + if (t != tc) + check_properties_for_opaque_type (t, tc, "canonical"); +} + /* Verify type T. */ void @@ -13677,6 +13742,14 @@ verify_type (const_tree t) { bool error_found = false; tree mv = TYPE_MAIN_VARIANT (t); + tree ct = TYPE_CANONICAL (t); + + if (OPAQUE_TYPE_P (t)) + { + verify_opaque_type (t, mv, ct); + return; + } + if (!mv) { error ("main variant is not defined"); @@ -13691,7 +13764,6 @@ verify_type (const_tree t) else if (t != mv && !verify_type_variant (t, mv)) error_found = true; - tree ct = TYPE_CANONICAL (t); if (!ct) ; else if (TYPE_CANONICAL (ct) != ct) -- 2.27.0 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2] Handle OPAQUE_TYPE specially in verify_type [PR106833] 2022-09-09 6:51 ` [PATCH v2] " Kewen.Lin @ 2022-09-09 7:25 ` Richard Biener 2022-09-09 13:27 ` Kewen.Lin 0 siblings, 1 reply; 8+ messages in thread From: Richard Biener @ 2022-09-09 7:25 UTC (permalink / raw) To: Kewen.Lin; +Cc: GCC Patches, Segher Boessenkool, Peter Bergner On Fri, Sep 9, 2022 at 8:51 AM Kewen.Lin <linkw@linux.ibm.com> wrote: > > Hi Richi, > > Thanks for the review comments! > > on 2022/9/8 15:36, Richard Biener wrote: > > > > > >> Am 08.09.2022 um 07:53 schrieb Kewen.Lin <linkw@linux.ibm.com>: > >> > >> Hi, > >> > >> As PR106833 shows, cv-qualified opaque type can cause ICE > >> during LTO. It exposes that we missd to handle OPAQUE_TYPE > >> well in type verification. As Richi pointed out, also > >> assuming that target will always define TYPE_MAIN_VARIANT > >> and TYPE_CANONICAL for opaque type, this patch is to check > >> both are OPAQUE_TYPE_P. Besides, it also checks the only > >> available size and alignment information as well as type > >> mode for TYPE_MAIN_VARIANT. > >> > ... > >> + > >> + if (t != tv) > >> + { > >> + verify_match (TREE_CODE, t, tv); > >> + verify_match (TYPE_MODE, t, tv); > >> + verify_match (TYPE_SIZE, t, tv); > > > > TYPE_SIZE is a tree, you should probably > > Compare this with operand_equal_p. It’s > > Not documented to be a constant size? > > Thus some VLA vector mode might be allowed ( a poly_int size), > > Thanks for catching, I was referencing the code in function > verify_type_variant, that corresponding part seems imperfect: > > if (TREE_CODE (TYPE_SIZE (t)) != PLACEHOLDER_EXPR > && TREE_CODE (TYPE_SIZE (tv)) != PLACEHOLDER_EXPR) > verify_variant_match (TYPE_SIZE); > > I agree poly_int size is allowed, the patch was updated for it. > > BLKmode > > Is ruled out(?), > > Yes, it requires a mode of MODE_OPAQUE class. > > the docs say we have > > ‚An MODE_Opaque‘ here but I don’t see > > This being verified? > > > > There is a MODE equality check, I assumed the given t already > has one MODE_OPAQUE mode, but the patch was updated to make > it explicit as you concerned. > > > The macro makes this a bit unworldly > > For the only benefit of elaborate diagnostic > > Which I think isn’t really necessary > > OK, fixed! > > The previous version makes just one check on TYPE_CANONICAL to > be cheap as gimple_canonical_types_compatible_p said, but > since there are just several fields to be check, this updated > version adjusted it to be the same as what's for TYPE_MAIN_VARIANT. > Hope it's fine. :) I think we'll call verify_type on the main variant as well so that would be redundant (ensured by transitivity), can you check? > Tested as before. > > Does this updated patch look good to you? Yes, please remove the checks against the main variant if the above holds, OK with or without that change depending on this outcome. Thanks, Richard. > > BR, > Kewen > ------ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2] Handle OPAQUE_TYPE specially in verify_type [PR106833] 2022-09-09 7:25 ` Richard Biener @ 2022-09-09 13:27 ` Kewen.Lin 2022-09-10 0:56 ` Peter Bergner 0 siblings, 1 reply; 8+ messages in thread From: Kewen.Lin @ 2022-09-09 13:27 UTC (permalink / raw) To: Richard Biener; +Cc: GCC Patches, Segher Boessenkool, Peter Bergner on 2022/9/9 15:25, Richard Biener wrote: > On Fri, Sep 9, 2022 at 8:51 AM Kewen.Lin <linkw@linux.ibm.com> wrote: >> >> Hi Richi, >> >> Thanks for the review comments! >> >> on 2022/9/8 15:36, Richard Biener wrote: >>> >>> >>>> Am 08.09.2022 um 07:53 schrieb Kewen.Lin <linkw@linux.ibm.com>: >>>> >>>> Hi, >>>> >>>> As PR106833 shows, cv-qualified opaque type can cause ICE >>>> during LTO. It exposes that we missd to handle OPAQUE_TYPE >>>> well in type verification. As Richi pointed out, also >>>> assuming that target will always define TYPE_MAIN_VARIANT >>>> and TYPE_CANONICAL for opaque type, this patch is to check >>>> both are OPAQUE_TYPE_P. Besides, it also checks the only >>>> available size and alignment information as well as type >>>> mode for TYPE_MAIN_VARIANT. >>>> >> ... >>>> + >>>> + if (t != tv) >>>> + { >>>> + verify_match (TREE_CODE, t, tv); >>>> + verify_match (TYPE_MODE, t, tv); >>>> + verify_match (TYPE_SIZE, t, tv); >>> >>> TYPE_SIZE is a tree, you should probably >>> Compare this with operand_equal_p. It’s >>> Not documented to be a constant size? >>> Thus some VLA vector mode might be allowed ( a poly_int size), >> >> Thanks for catching, I was referencing the code in function >> verify_type_variant, that corresponding part seems imperfect: >> >> if (TREE_CODE (TYPE_SIZE (t)) != PLACEHOLDER_EXPR >> && TREE_CODE (TYPE_SIZE (tv)) != PLACEHOLDER_EXPR) >> verify_variant_match (TYPE_SIZE); >> >> I agree poly_int size is allowed, the patch was updated for it. >> >> BLKmode >>> Is ruled out(?), >> >> Yes, it requires a mode of MODE_OPAQUE class. >> >> the docs say we have >>> ‚An MODE_Opaque‘ here but I don’t see >>> This being verified? >>> >> >> There is a MODE equality check, I assumed the given t already >> has one MODE_OPAQUE mode, but the patch was updated to make >> it explicit as you concerned. >> >>> The macro makes this a bit unworldly >>> For the only benefit of elaborate diagnostic >>> Which I think isn’t really necessary >> >> OK, fixed! >> >> The previous version makes just one check on TYPE_CANONICAL to >> be cheap as gimple_canonical_types_compatible_p said, but >> since there are just several fields to be check, this updated >> version adjusted it to be the same as what's for TYPE_MAIN_VARIANT. >> Hope it's fine. :) > > I think we'll call verify_type on the main variant as well so that would be > redundant (ensured by transitivity), can you check? I just had a check and found that we don't always call verify_type on the main variant. For example, with one case like: __attribute__((noipa)) int foo(c){ return 0; } int main () { const __vector_quad c; int r = foo(c); return r; } Checking during LTO WPA, verify_type only gets type "const __vector_quad", no type "__vector_quad". btw, it needs some hacking in rs6000_function_arg to make this opaque type valid for function arg. > >> Tested as before. >> >> Does this updated patch look good to you? > > Yes, please remove the checks against the main variant if the above holds, > OK with or without that change depending on this outcome. > Committed in r13-2562, thanks! BR, Kewen ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2] Handle OPAQUE_TYPE specially in verify_type [PR106833] 2022-09-09 13:27 ` Kewen.Lin @ 2022-09-10 0:56 ` Peter Bergner 2022-09-10 1:47 ` Segher Boessenkool 0 siblings, 1 reply; 8+ messages in thread From: Peter Bergner @ 2022-09-10 0:56 UTC (permalink / raw) To: Kewen.Lin, Richard Biener; +Cc: GCC Patches, Segher Boessenkool On 9/9/22 8:27 AM, Kewen.Lin wrote: > __attribute__((noipa)) > int foo(c){ > return 0; > } > > int main () > { > const __vector_quad c; > int r = foo(c); > return r; > } > > Checking during LTO WPA, verify_type only gets type "const > __vector_quad", no type "__vector_quad". > > btw, it needs some hacking in rs6000_function_arg to make this > opaque type valid for function arg. We don't allow (at this time) __vector_pair or __vector_quad to be used as actual arguments to non-builtin functions. We do allow pointers to those types though. Peter ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2] Handle OPAQUE_TYPE specially in verify_type [PR106833] 2022-09-10 0:56 ` Peter Bergner @ 2022-09-10 1:47 ` Segher Boessenkool 2022-09-10 3:16 ` Peter Bergner 0 siblings, 1 reply; 8+ messages in thread From: Segher Boessenkool @ 2022-09-10 1:47 UTC (permalink / raw) To: Peter Bergner; +Cc: Kewen.Lin, Richard Biener, GCC Patches On Fri, Sep 09, 2022 at 07:56:42PM -0500, Peter Bergner wrote: > On 9/9/22 8:27 AM, Kewen.Lin wrote: > > btw, it needs some hacking in rs6000_function_arg to make this > > opaque type valid for function arg. > > We don't allow (at this time) __vector_pair or __vector_quad to be > used as actual arguments to non-builtin functions. We do allow > pointers to those types though. It would be nice to support that, if it isn't too hard. It won't be digging us into a hole, experience has taught us :-) Segher ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2] Handle OPAQUE_TYPE specially in verify_type [PR106833] 2022-09-10 1:47 ` Segher Boessenkool @ 2022-09-10 3:16 ` Peter Bergner 0 siblings, 0 replies; 8+ messages in thread From: Peter Bergner @ 2022-09-10 3:16 UTC (permalink / raw) To: Segher Boessenkool; +Cc: Kewen.Lin, Richard Biener, GCC Patches On 9/9/22 8:47 PM, Segher Boessenkool wrote: > On Fri, Sep 09, 2022 at 07:56:42PM -0500, Peter Bergner wrote: >> On 9/9/22 8:27 AM, Kewen.Lin wrote: >>> btw, it needs some hacking in rs6000_function_arg to make this >>> opaque type valid for function arg. >> >> We don't allow (at this time) __vector_pair or __vector_quad to be >> used as actual arguments to non-builtin functions. We do allow >> pointers to those types though. > > It would be nice to support that, if it isn't too hard. It won't be > digging us into a hole, experience has taught us :-) Sure, but we didn't need it at the time (and still don't) and if we do add support for that, we'll have to update the ABIs to describe how they are passed and returned and that is no small feat in itself. It's just a fair amount of work when no one is actually asking for that support and we have a lot of other things to work on. Peter ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-09-10 3:16 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-09-08 5:53 [PATCH] Handle OPAQUE_TYPE specially in verify_type [PR106833] Kewen.Lin 2022-09-08 7:36 ` Richard Biener 2022-09-09 6:51 ` [PATCH v2] " Kewen.Lin 2022-09-09 7:25 ` Richard Biener 2022-09-09 13:27 ` Kewen.Lin 2022-09-10 0:56 ` Peter Bergner 2022-09-10 1:47 ` Segher Boessenkool 2022-09-10 3:16 ` Peter Bergner
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).