[pushed] wwwdocs: readings: Update MicroBlaze Processor Reference reference
Second link this week that actually shorter - wooo... Pushed. Gerald --- htdocs/readings.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/readings.html b/htdocs/readings.html index 29368a9a..34ba508c 100644 --- a/htdocs/readings.html +++ b/htdocs/readings.html @@ -193,7 +193,7 @@ names. MicroBlace Manufacturer: Xilinx - https://www.xilinx.com/support/documentation/sw_manuals/xilinx11/mb_ref_guide.pdf;> + https://www.xilinx.com/htmldocs/xilinx11/mb_ref_guide.pdf;> MicroBlaze Processor Reference Guide GDB includes a simulator for an earlier version of the processor. -- 2.39.1
Re: [PATCH] ipa: silent -Wodr notes with -w
On 2/9/23 01:10, Jan Hubicka wrote:
>>> On 2/1/23 15:26, Martin Jambor wrote:
Hi,
On Fri, Dec 02 2022, Martin Liška wrote:
> If -w is used, warn_odr properly sets *warned = false and
> so it should be preserved when calling warn_types_mismatch.
>
> Noticed that during a LTO reduction where I used -w.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> * ipa-devirt.cc (odr_types_equivalent_p): Respect *warned
> value if set.
>>>
>>> Hi.
>>>
Sorry for skipping this for so long, usually ODR stuff is... interesting
to the point I gladly leave it to Honza.
>>>
>>> Makes sense, however, he's not much active when it comes to patch review.
>>
>> Sorry, I was confused by the patch and delayed reply to figure out what
>> you are trying to fix. Indeed the dererence is missing here, however
>> every caller that sets warn to true should also set warned to non-NULL.
>> So indeed derefernce is missing, but I think the check for
>> warned == NULL should not be necessary.
>
> This seems to bootstrap with LTO. I am not sure what testcase you
> looked in, but unless there as a good reason to include the NULL check,
> I would rmeove it as it makes it harder to see what is going on.
Hi.
Thanks for the patch. Apparently, I noticed that during reduction of a test-case
where I used -w in order to silent all warnings.
So go ahead with your patch.
Martin
>
> honza
>
> diff --git a/gcc/ipa-devirt.cc b/gcc/ipa-devirt.cc
> index 14cf132c767..819860258d1 100644
> --- a/gcc/ipa-devirt.cc
> +++ b/gcc/ipa-devirt.cc
> @@ -1221,6 +1221,9 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn,
> bool *warned,
> hash_set *visited,
> location_t loc1, location_t loc2)
> {
> + /* If we are asked to warn, we need warned to keep track if warning was
> + output. */
> + gcc_assert (!warn || warned);
>/* Check first for the obvious case of pointer identity. */
>if (t1 == t2)
> return true;
> @@ -1300,7 +1303,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn,
> bool *warned,
> warn_odr (t1, t2, NULL, NULL, warn, warned,
> G_("it is defined as a pointer to different type "
> "in another translation unit"));
> - if (warn && (warned == NULL || *warned))
> + if (warn && *warned)
> warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2),
>loc1, loc2);
> return false;
> @@ -1315,7 +1318,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn,
> bool *warned,
> warn_odr (t1, t2, NULL, NULL, warn, warned,
> G_("a different type is defined "
> "in another translation unit"));
> - if (warn && (warned == NULL || *warned))
> + if (warn && *warned)
> warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2), loc1, loc2);
> return false;
> }
> @@ -1333,7 +1336,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn,
> bool *warned,
> warn_odr (t1, t2, NULL, NULL, warn, warned,
> G_("a different type is defined in another "
>"translation unit"));
> - if (warn && (warned == NULL || *warned))
> + if (warn && *warned)
> warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2), loc1, loc2);
> }
> gcc_assert (TYPE_STRING_FLAG (t1) == TYPE_STRING_FLAG (t2));
> @@ -1375,7 +1378,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn,
> bool *warned,
> warn_odr (t1, t2, NULL, NULL, warn, warned,
> G_("has different return value "
> "in another translation unit"));
> - if (warn && (warned == NULL || *warned))
> + if (warn && *warned)
> warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2), loc1, loc2);
> return false;
> }
> @@ -1398,7 +1401,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn,
> bool *warned,
> warn_odr (t1, t2, NULL, NULL, warn, warned,
> G_("has different parameters in another "
> "translation unit"));
> - if (warn && (warned == NULL || *warned))
> + if (warn && *warned)
> warn_types_mismatch (TREE_VALUE (parms1),
>TREE_VALUE (parms2), loc1, loc2);
> return false;
> @@ -1484,7 +1487,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn,
> bool *warned,
> warn_odr (t1, t2, f1, f2, warn, warned,
> G_("a field of same name but different type "
>"is defined in another translation unit"));
> - if (warn && (warned == NULL || *warned))
> +
Re: [PATCH] testsuite: XFAIL bogus g++.dg/warn/Wstringop-overflow-4.C:144, PR106120
On Tue, Feb 7, 2023 at 7:04 PM Hans-Peter Nilsson via Gcc-patches
wrote:
>
> > From: Aldy Hernandez
> > Date: Tue, 7 Feb 2023 17:52:02 +0100
>
> > Up to the release managers, but I have no objections.
>
> I take it that's for both patches. Thanks!
> (Potential reviewers: these patches are local to the testsuite.)
OK
> brgds, H-P
>
>
> >
> > Aldy
> >
> > On 2/7/23 17:50, Hans-Peter Nilsson wrote:
> > > (sort-of-ping:) Aldy, I missed CC:ing you on the similar
> > > https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611206.html
> > > would you mind having a look?
> > >
> > > Tested native x86_64-pc-linux-gnu (w/wo. -m32) and cris-elf.
> > > Ok to commit?
> > >
> > > 8<
> > > There was a commit r13-2082-gbf13a13c65bd06 "c++: remove some xfails"
> > > (not referencing the PR) that dealt with part of the PR, but didn't
> > > xfail the ilp32-specific (bogus) warning mentioned in the PR.
> > >
> > > PR testsuite/106120
> > > * g++.dg/warn/Wstringop-overflow-4.C:144 XFAIL bogus warning for
> > > ilp32 targets with c++98.
> > > ---
> > > gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C
> > > b/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C
> > > index 3716d2d13be0..35fb59e02320 100644
> > > --- a/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C
> > > +++ b/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C
> > > @@ -141,7 +141,7 @@ void test_strcpy_new_int16_t (size_t n, const size_t
> > > vals[])
> > >
> > > int r_imin_imax = SR (INT_MIN, INT_MAX);
> > > T (S (1), new int16_t[r_imin_imax]);
> > > - T (S (2), new int16_t[r_imin_imax + 1]);
> > > + T (S (2), new int16_t[r_imin_imax + 1]); // { dg-bogus "into a region
> > > of size" "pr106120" { xfail { ilp32 && c++98_only } } }
> > > T (S (9), new int16_t[r_imin_imax * 2 + 1]);
> > >
> > > int r_0_imax = SR (0, INT_MAX);
> >
Re: [RFC/RFT 0/3] Add compiler support for Control Flow Integrity
On Sun, Dec 18, 2022 at 10:06 PM Dan Li wrote: > > This series of patches is mainly used to support the control flow > integrity protection of the linux kernel [1], which is similar to > -fsanitize=kcfi in clang 16.0 [2,3]. > > I hope that this feature will also support user-mode CFI in the > future (at least for developers who can recompile the runtime), > so I use -fsanitize=cfi as a compilation option here. Please don't. The various CFI-related build flags are confusing enough without also having this inconsistency between Clang and GCC. Peter
Re: [Patch] pr65658.c: fix excess warnings on LLP64 targets
ping On Sat, Jan 28, 2023 at 1:16 PM Jonathan Yong <10wa...@gmail.com> wrote: > > Patch OK? > > gcc/testsuite/ChangeLog: > > * gcc.dg/pr65658.c: fix LLP64 test.
[PING 2] [PATCH 0/3] RISC-V: optimize stack manipulation in save-restore
ping. BR Fei On 2023-02-03 16:52 Fei Gao wrote: > > >Gentle ping. > >The patch I previously submitted: >| Date: Wed, 30 Nov 2022 00:38:08 -0800 >| Subject: [PATCH] RISC-V: optimize stack manipulation in save-restore >| Message-ID: > >I split the patches as per Palmer's review comment. > >BR >Fei > >On 2022-12-01 18:03 Fei Gao wrote: >> >>The patches allow less instructions to be used in stack allocation >>and deallocation if save-restore enabled, and also make the stack >>manipulation codes more readable. >> >>Fei Gao (3): >> RISC-V: add a new parameter in riscv_first_stack_step. >> RISC-V: optimize stack manipulation in save-restore >> RISC-V: make the stack manipulation codes more readable. >> >> gcc/config/riscv/riscv.cc | 105 +- >> .../gcc.target/riscv/stack_save_restore.c | 40 +++ >> 2 files changed, 95 insertions(+), 50 deletions(-) >> create mode 100644 gcc/testsuite/gcc.target/riscv/stack_save_restore.c >> >>-- >>2.17.1
[PATCH v2] c++: ICE initing lifetime-extended constexpr var [PR107079]
On Wed, Feb 08, 2023 at 04:00:25PM -0800, Jason Merrill wrote:
> On 2/8/23 13:01, Marek Polacek wrote:
> > (This may not be a complete fix but I got stuck so I'm posting what
> > I have, which at least fixes the ICE.)
> >
> > We ICE on the simple:
> >
> >struct X { const X* x = this; };
> >constexpr const X& x = X{};
> >
> > where store_init_value initializes 'x' with
> >
> >_EXPR > X>}>
> >
> > but we must lifetime-extend via extend_ref_init_temps and we get
> >
> >_ZGR1x_.x = (const struct X *) & >>>;, (const
> > struct X &) &_ZGR1x_;
> >
> > Since 'x' was declared constexpr, we do cxx_constant_init and we hit
> > the preeval code added in r269003 while evaluating the INIT_EXPR:
> >
> >_ZGR1x_.x = (const struct X *) & >>>
> >
> > but we have no ctx.ctor or ctx.object here so lookup_placeholder won't
> > find anything that could replace X and we ICE on
> > 7861 /* A placeholder without a referent. We can get here when
> > 7862 checking whether NSDMIs are noexcept, or in
> > massage_init_elt;
> > 7863 just say it's non-constant for now. */
> > 7864 gcc_assert (ctx->quiet);
> > because cxx_constant_init means !ctx->quiet. It's not correct that
> > there isn't a referent. I think the following patch is a pretty
> > straightforward fix: pass the _ZGR var down to maybe_constant_init so
> > that it can replace the PLACEHOLDER_EXPR with _ZGR1x_.
> >
> > What I wasn't able to make work is the commented assert in the test.
> > It doesn't pass because we complain that _ZGR1x_ isn't a constexpr
> > variable,
>
> That sounds like we aren't (correctly) implementing
>
> https://eel.is/c++draft/expr.const#4.7
Ah yes, this is DR2126 = c++/101588. I wonder if the fix will include
checking startswith (IDENTIFIER_POINTER (DECL_NAME (variable)), "_ZGR")
to see if its lifetime is extended.
> > but making it so would just result in "used in its own
> > initializer" (which is true).
>
> True, but not in the sense it means; its initializer doesn't depend on its
> (uninitialized) value.
...because we're only interested in its address.
> > diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
> > index f7c5d9da94b..a0afab9b26a 100644
> > --- a/gcc/cp/call.cc
> > +++ b/gcc/cp/call.cc
> > @@ -13583,7 +13583,7 @@ set_up_extended_ref_temp (tree decl, tree expr,
> > vec **cleanups,
> > /* If the initializer is constant, put it in DECL_INITIAL so we get
> >static initialization and use in constant expressions. */
> > - init = maybe_constant_init (expr);
> > + init = maybe_constant_init (expr, var);
>
> We should also pass true for manifestly_const_eval as in store_init_value.
Done.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
We ICE on the simple:
struct X { const X* x = this; };
constexpr const X& x = X{};
where store_init_value initializes 'x' with
_EXPR }>
but we must lifetime-extend via extend_ref_init_temps and we get
_ZGR1x_.x = (const struct X *) & >>>;, (const
struct X &) &_ZGR1x_;
Since 'x' was declared constexpr, we do cxx_constant_init and we hit
the preeval code added in r269003 while evaluating the INIT_EXPR:
_ZGR1x_.x = (const struct X *) & >>>
but we have no ctx.ctor or ctx.object here so lookup_placeholder won't
find anything that could replace X and we ICE on
7861 /* A placeholder without a referent. We can get here when
7862 checking whether NSDMIs are noexcept, or in massage_init_elt;
7863 just say it's non-constant for now. */
7864 gcc_assert (ctx->quiet);
because cxx_constant_init means !ctx->quiet. It's not correct that
there isn't a referent. I think the following patch is a pretty
straightforward fix: pass the _ZGR var down to maybe_constant_init so
that it can replace the PLACEHOLDER_EXPR with _ZGR1x_.
The commented assert in the test doesn't pass: we complain that _ZGR1x_
isn't a constexpr variable because we don't implement DR2126 (PR101588).
PR c++/107079
gcc/cp/ChangeLog:
* call.cc (set_up_extended_ref_temp): Pass var to maybe_constant_init.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-nsdmi2.C: New test.
---
gcc/cp/call.cc| 2 +-
gcc/testsuite/g++.dg/cpp0x/constexpr-nsdmi2.C | 9 +
2 files changed, 10 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-nsdmi2.C
diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index f7c5d9da94b..a349d8e79db 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -13583,7 +13583,7 @@ set_up_extended_ref_temp (tree decl, tree expr,
vec **cleanups,
/* If the initializer is constant, put it in DECL_INITIAL so we get
static initialization and use in constant expressions. */
- init = maybe_constant_init (expr);
+ init = maybe_constant_init (expr, var, /*manifestly_const_eval=*/true);
/* As in store_init_value. */
init = cp_fully_fold (init);
if (TREE_CONSTANT (init))
diff --git
Re: Ping: [PATCH v4] rs6000: Fix incorrect RTL for Power LE when removing the UNSPECS [PR106069]
Thanks Kewen!
Ping this again @Segher.
Maybe we could also merge this patch if no objections from Segher as
several reviews and tests taken on this already...
BR,
Xionghu
On 2023/1/18 17:11, Kewen.Lin wrote:
Hi Segher,
I guessed that this patch escaped from your radar. :)
As Jakub asked the status in PR106069, I applied this attached patch from
Xionghu
to the latest trunk, re-tested it and confirmed that it's still bootstrapped and
regtested on powerpc64-linux-gnu P8 and powerpc64le-linux-gnu P9 and P10.
This new version has separated out direct le and be, it's more clear than
before,
it looked good to me. What do you think of this? Looking forward to your
opinion.
btw, the link in archives:
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600169.html
BR,
Kewen
on 2022/8/24 09:24, Xionghu Luo wrote:
主题:
Ping: [PATCH v4] rs6000: Fix incorrect RTL for Power LE when removing the
UNSPECS [PR106069]
From:
Xionghu Luo
日期:
2022/8/24, 09:24
收件人:
"Kewen.Lin" , Segher Boessenkool
抄送:
Xionghu Luo , gcc-patches@gcc.gnu.org, David Edelsohn
, Segher Boessenkool
Hi Segher, I'd like to resend and ping for this patch. Thanks.
v4-0001-rs6000-Fix-incorrect-RTL-for-Power-LE-when-removi.patch
From 23bffdacdf0eb1140c7a3571e6158797f4818d57 Mon Sep 17 00:00:00 2001
From: Xionghu Luo
Date: Thu, 4 Aug 2022 03:44:58 +
Subject: [PATCH v4] rs6000: Fix incorrect RTL for Power LE when removing the
UNSPECS [PR106069]
v4: Update per comments.
v3: rename altivec_vmrghb_direct_le to altivec_vmrglb_direct_le to match
the actual output ASM vmrglb. Likewise for all similar xxx_direct_le
patterns.
v2: Split the direct pattern to be and le with same RTL but different insn.
The native RTL expression for vec_mrghw should be same for BE and LE as
they are register and endian-independent. So both BE and LE need
generate exactly same RTL with index [0 4 1 5] when expanding vec_mrghw
with vec_select and vec_concat.
(set (reg:V4SI 141) (vec_select:V4SI (vec_concat:V8SI
(subreg:V4SI (reg:V16QI 139) 0)
(subreg:V4SI (reg:V16QI 140) 0))
[const_int 0 4 1 5]))
Then combine pass could do the nested vec_select optimization
in simplify-rtx.c:simplify_binary_operation_1 also on both BE and LE:
21: r150:V4SI=vec_select(vec_concat(r141:V4SI,r146:V4SI),parallel [0 4 1 5])
24: {r151:SI=vec_select(r150:V4SI,parallel [const_int 3]);}
=>
21: r150:V4SI=vec_select(vec_concat(r141:V4SI,r146:V4SI),parallel)
24: {r151:SI=vec_select(r146:V4SI,parallel [const_int 1]);}
The endianness check need only once at ASM generation finally.
ASM would be better due to nested vec_select simplified to simple scalar
load.
Regression tested pass for Power8{LE,BE}{32,64} and Power{9,10}LE{32,64}
Linux.
gcc/ChangeLog:
PR target/106069
* config/rs6000/altivec.md (altivec_vmrghb_direct): Remove.
(altivec_vmrghb_direct_be): New pattern for BE.
(altivec_vmrghb_direct_le): New pattern for LE.
(altivec_vmrghh_direct): Remove.
(altivec_vmrghh_direct_be): New pattern for BE.
(altivec_vmrghh_direct_le): New pattern for LE.
(altivec_vmrghw_direct_): Remove.
(altivec_vmrghw_direct__be): New pattern for BE.
(altivec_vmrghw_direct__le): New pattern for LE.
(altivec_vmrglb_direct): Remove.
(altivec_vmrglb_direct_be): New pattern for BE.
(altivec_vmrglb_direct_le): New pattern for LE.
(altivec_vmrglh_direct): Remove.
(altivec_vmrglh_direct_be): New pattern for BE.
(altivec_vmrglh_direct_le): New pattern for LE.
(altivec_vmrglw_direct_): Remove.
(altivec_vmrglw_direct__be): New pattern for BE.
(altivec_vmrglw_direct__le): New pattern for LE.
* config/rs6000/rs6000.cc (altivec_expand_vec_perm_const):
Adjust.
* config/rs6000/vsx.md: Likewise.
gcc/testsuite/ChangeLog:
PR target/106069
* g++.target/powerpc/pr106069.C: New test.
Signed-off-by: Xionghu Luo
---
gcc/config/rs6000/altivec.md| 222 ++--
gcc/config/rs6000/rs6000.cc | 24 +--
gcc/config/rs6000/vsx.md| 28 +--
gcc/testsuite/g++.target/powerpc/pr106069.C | 118 +++
4 files changed, 307 insertions(+), 85 deletions(-)
create mode 100644 gcc/testsuite/g++.target/powerpc/pr106069.C
diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
index 2c4940f2e21..c6a381908cb 100644
--- a/gcc/config/rs6000/altivec.md
+++ b/gcc/config/rs6000/altivec.md
@@ -1144,15 +1144,16 @@ (define_expand "altivec_vmrghb"
(use (match_operand:V16QI 2 "register_operand"))]
"TARGET_ALTIVEC"
{
- rtx (*fun) (rtx, rtx, rtx) = BYTES_BIG_ENDIAN ? gen_altivec_vmrghb_direct
- : gen_altivec_vmrglb_direct;
- if (!BYTES_BIG_ENDIAN)
-std::swap (operands[1], operands[2]);
- emit_insn (fun (operands[0], operands[1], operands[2]));
Re: [RFC/RFT 0/3] Add compiler support for Control Flow Integrity
On Mon, Dec 19, 2022 at 3:59 PM Dan Li via Gcc-patches wrote: > > This series of patches is mainly used to support the control flow > integrity protection of the linux kernel [1], which is similar to > -fsanitize=kcfi in clang 16.0 [2,3]. > > I hope that this feature will also support user-mode CFI in the > future (at least for developers who can recompile the runtime), > so I use -fsanitize=cfi as a compilation option here. > > Any suggestion please let me know :). Do you have this series as a branch somewhere that we could also try for x86? > > Thanks, Dan. > > [1] > https://lore.kernel.org/all/20220908215504.3686827-1-samitolva...@google.com/ > [2] https://clang.llvm.org/docs/ControlFlowIntegrity.html > [3] https://reviews.llvm.org/D119296 > > Dan Li (3): > [PR102768] flag-types.h (enum sanitize_code): Extend sanitize_code to > 64 bits to support more features > [PR102768] Support CFI: Add new pass for Control Flow Integrity > [PR102768] aarch64: Add support for Control Flow Integrity > > Signed-off-by: Dan Li > > --- > gcc/Makefile.in | 1 + > gcc/asan.h| 4 +- > gcc/c-family/c-attribs.cc | 10 +- > gcc/c-family/c-common.h | 2 +- > gcc/c/c-parser.cc | 4 +- > gcc/cgraphunit.cc | 34 +++ > gcc/common.opt| 4 +- > gcc/config/aarch64/aarch64.cc | 106 > gcc/cp/typeck.cc | 2 +- > gcc/doc/invoke.texi | 35 +++ > gcc/doc/passes.texi | 10 + > gcc/doc/tm.texi | 27 +++ > gcc/doc/tm.texi.in| 8 + > gcc/dwarf2asm.cc | 2 +- > gcc/flag-types.h | 67 ++--- > gcc/opt-suggestions.cc| 2 +- > gcc/opts.cc | 26 +- > gcc/opts.h| 8 +- > gcc/output.h | 3 + > gcc/passes.def| 1 + > gcc/target.def| 39 +++ > .../aarch64/control_flow_integrity_1.c| 14 ++ > .../aarch64/control_flow_integrity_2.c| 25 ++ > .../aarch64/control_flow_integrity_3.c| 23 ++ > gcc/toplev.cc | 4 + > gcc/tree-cfg.cc | 2 +- > gcc/tree-cfi.cc | 229 ++ > gcc/tree-pass.h | 1 + > gcc/tree.cc | 144 +++ > gcc/tree.h| 1 + > gcc/varasm.cc | 29 +++ > 31 files changed, 803 insertions(+), 64 deletions(-) > create mode 100644 > gcc/testsuite/gcc.target/aarch64/control_flow_integrity_1.c > create mode 100644 > gcc/testsuite/gcc.target/aarch64/control_flow_integrity_2.c > create mode 100644 > gcc/testsuite/gcc.target/aarch64/control_flow_integrity_3.c > create mode 100644 gcc/tree-cfi.cc > > -- > 2.17.1 > -- BR, Hongtao
Re: [PATCH] ipa: silent -Wodr notes with -w
> > On 2/1/23 15:26, Martin Jambor wrote:
> > > Hi,
> > >
> > > On Fri, Dec 02 2022, Martin Liška wrote:
> > > > If -w is used, warn_odr properly sets *warned = false and
> > > > so it should be preserved when calling warn_types_mismatch.
> > > >
> > > > Noticed that during a LTO reduction where I used -w.
> > > >
> > > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> > > >
> > > > Ready to be installed?
> > > > Thanks,
> > > > Martin
> > > >
> > > > gcc/ChangeLog:
> > > >
> > > > * ipa-devirt.cc (odr_types_equivalent_p): Respect *warned
> > > > value if set.
> > >
> >
> > Hi.
> >
> > > Sorry for skipping this for so long, usually ODR stuff is... interesting
> > > to the point I gladly leave it to Honza.
> >
> > Makes sense, however, he's not much active when it comes to patch review.
>
> Sorry, I was confused by the patch and delayed reply to figure out what
> you are trying to fix. Indeed the dererence is missing here, however
> every caller that sets warn to true should also set warned to non-NULL.
> So indeed derefernce is missing, but I think the check for
> warned == NULL should not be necessary.
This seems to bootstrap with LTO. I am not sure what testcase you
looked in, but unless there as a good reason to include the NULL check,
I would rmeove it as it makes it harder to see what is going on.
honza
diff --git a/gcc/ipa-devirt.cc b/gcc/ipa-devirt.cc
index 14cf132c767..819860258d1 100644
--- a/gcc/ipa-devirt.cc
+++ b/gcc/ipa-devirt.cc
@@ -1221,6 +1221,9 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool
*warned,
hash_set *visited,
location_t loc1, location_t loc2)
{
+ /* If we are asked to warn, we need warned to keep track if warning was
+ output. */
+ gcc_assert (!warn || warned);
/* Check first for the obvious case of pointer identity. */
if (t1 == t2)
return true;
@@ -1300,7 +1303,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool
*warned,
warn_odr (t1, t2, NULL, NULL, warn, warned,
G_("it is defined as a pointer to different type "
"in another translation unit"));
- if (warn && (warned == NULL || *warned))
+ if (warn && *warned)
warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2),
loc1, loc2);
return false;
@@ -1315,7 +1318,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool
*warned,
warn_odr (t1, t2, NULL, NULL, warn, warned,
G_("a different type is defined "
"in another translation unit"));
- if (warn && (warned == NULL || *warned))
+ if (warn && *warned)
warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2), loc1, loc2);
return false;
}
@@ -1333,7 +1336,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool
*warned,
warn_odr (t1, t2, NULL, NULL, warn, warned,
G_("a different type is defined in another "
"translation unit"));
- if (warn && (warned == NULL || *warned))
+ if (warn && *warned)
warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2), loc1, loc2);
}
gcc_assert (TYPE_STRING_FLAG (t1) == TYPE_STRING_FLAG (t2));
@@ -1375,7 +1378,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool
*warned,
warn_odr (t1, t2, NULL, NULL, warn, warned,
G_("has different return value "
"in another translation unit"));
- if (warn && (warned == NULL || *warned))
+ if (warn && *warned)
warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2), loc1, loc2);
return false;
}
@@ -1398,7 +1401,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool
*warned,
warn_odr (t1, t2, NULL, NULL, warn, warned,
G_("has different parameters in another "
"translation unit"));
- if (warn && (warned == NULL || *warned))
+ if (warn && *warned)
warn_types_mismatch (TREE_VALUE (parms1),
TREE_VALUE (parms2), loc1, loc2);
return false;
@@ -1484,7 +1487,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool
*warned,
warn_odr (t1, t2, f1, f2, warn, warned,
G_("a field of same name but different type "
"is defined in another translation unit"));
- if (warn && (warned == NULL || *warned))
+ if (warn && *warned)
warn_types_mismatch (TREE_TYPE (f1), TREE_TYPE (f2),
loc1, loc2);
return false;
}
Re: [PATCH] c++: ICE initing lifetime-extended constexpr var [PR107079]
On 2/8/23 13:01, Marek Polacek wrote:
(This may not be a complete fix but I got stuck so I'm posting what
I have, which at least fixes the ICE.)
We ICE on the simple:
struct X { const X* x = this; };
constexpr const X& x = X{};
where store_init_value initializes 'x' with
_EXPR }>
but we must lifetime-extend via extend_ref_init_temps and we get
_ZGR1x_.x = (const struct X *) & >>>;, (const struct X
&) &_ZGR1x_;
Since 'x' was declared constexpr, we do cxx_constant_init and we hit
the preeval code added in r269003 while evaluating the INIT_EXPR:
_ZGR1x_.x = (const struct X *) & >>>
but we have no ctx.ctor or ctx.object here so lookup_placeholder won't
find anything that could replace X and we ICE on
7861 /* A placeholder without a referent. We can get here when
7862 checking whether NSDMIs are noexcept, or in massage_init_elt;
7863 just say it's non-constant for now. */
7864 gcc_assert (ctx->quiet);
because cxx_constant_init means !ctx->quiet. It's not correct that
there isn't a referent. I think the following patch is a pretty
straightforward fix: pass the _ZGR var down to maybe_constant_init so
that it can replace the PLACEHOLDER_EXPR with _ZGR1x_.
What I wasn't able to make work is the commented assert in the test.
It doesn't pass because we complain that _ZGR1x_ isn't a constexpr
variable,
That sounds like we aren't (correctly) implementing
https://eel.is/c++draft/expr.const#4.7
but making it so would just result in "used in its own
initializer" (which is true).
True, but not in the sense it means; its initializer doesn't depend on
its (uninitialized) value.
I notice that while clang++ compiles
the assert fine, MSVC++/icc reject it as non-constant. So maybe we
don't have to/shouldn't make it work.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
PR c++/107079
gcc/cp/ChangeLog:
* call.cc (set_up_extended_ref_temp): Pass var to maybe_constant_init.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-nsdmi2.C: New test.
---
gcc/cp/call.cc| 2 +-
gcc/testsuite/g++.dg/cpp0x/constexpr-nsdmi2.C | 9 +
2 files changed, 10 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-nsdmi2.C
diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index f7c5d9da94b..a0afab9b26a 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -13583,7 +13583,7 @@ set_up_extended_ref_temp (tree decl, tree expr, vec **cleanups,
/* If the initializer is constant, put it in DECL_INITIAL so we get
static initialization and use in constant expressions. */
- init = maybe_constant_init (expr);
+ init = maybe_constant_init (expr, var);
We should also pass true for manifestly_const_eval as in store_init_value.
/* As in store_init_value. */
init = cp_fully_fold (init);
if (TREE_CONSTANT (init))
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-nsdmi2.C
b/gcc/testsuite/g++.dg/cpp0x/constexpr-nsdmi2.C
new file mode 100644
index 000..6dbb7eb739a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-nsdmi2.C
@@ -0,0 +1,9 @@
+// PR c++/107079
+// { dg-do compile { target c++11 } }
+
+struct X {
+ const X* x = this;
+};
+constexpr const X& x = X{};
+// TODO: Should the assert pass?
+//static_assert(x.x == );
base-commit: 77bb54b1b07add45007c664724b726541d672ef3
Re: [PATCH] c++: Mangle EXCESS_PRECISION_EXPR as fold_convert REAL_CST [PR108698]
On 2/8/23 00:59, Jakub Jelinek wrote:
Hi!
For standard excess precision, like the C FE we parse floating
point constants as EXCESS_PRECISION_EXPR of promoted REAL_CST
rather than the nominal REAL_CST, and as the following testcase
shows the constants might need mangling.
The following patch mangles those as fold_convert of the REAL_CST
to EXCESS_PRECISION_EXPR type, i.e. how they were mangled before.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
I'm not really sure EXCESS_PRECISION_EXPR can appear elsewhere
in expressions that would need mangling, tried various testcases
but haven't managed to come up with one. If that is possible,
we'd keep ICEing on it without/with this patch, and the big question
is how to mangle those; they could be mangled as casts from the
promoted type back to nominal, but then in the mangled expressions
one could see the effects of excess precision. Until we have
a reproducer, that is just theoretical though.
2023-02-08 Jakub Jelinek
PR c++/108698
* mangle.cc (write_expression, write_template_arg): Handle
EXCESS_PRECISION_EXPR with REAL_CST operand as
write_template_arg_literal on fold_convert of the REAL_CST
to EXCESS_PRECISION_EXPR type.
* g++.dg/cpp0x/pr108698.C: New test.
--- gcc/cp/mangle.cc.jj 2023-01-25 15:13:23.220649480 +0100
+++ gcc/cp/mangle.cc2023-02-07 19:27:35.949588461 +0100
@@ -3107,6 +3107,10 @@ write_expression (tree expr)
else if (TREE_CODE_CLASS (code) == tcc_constant
|| code == CONST_DECL)
write_template_arg_literal (expr);
+ else if (code == EXCESS_PRECISION_EXPR
+ && TREE_CODE (TREE_OPERAND (expr, 0)) == REAL_CST)
+write_template_arg_literal (fold_convert (TREE_TYPE (expr),
+ TREE_OPERAND (expr, 0)));
else if (code == PARM_DECL && DECL_ARTIFICIAL (expr))
{
gcc_assert (id_equal (DECL_NAME (expr), "this"));
@@ -3815,6 +3819,10 @@ write_template_arg (tree node)
|| code == CONST_DECL
|| null_member_pointer_value_p (node))
write_template_arg_literal (node);
+ else if (code == EXCESS_PRECISION_EXPR
+ && TREE_CODE (TREE_OPERAND (node, 0)) == REAL_CST)
+write_template_arg_literal (fold_convert (TREE_TYPE (node),
+ TREE_OPERAND (node, 0)));
else if (DECL_P (node))
{
write_char ('L');
--- gcc/testsuite/g++.dg/cpp0x/pr108698.C.jj2023-02-07 20:33:45.365125556
+0100
+++ gcc/testsuite/g++.dg/cpp0x/pr108698.C 2023-02-07 19:55:57.459493456
+0100
@@ -0,0 +1,16 @@
+// PR c++/108698
+// { dg-do compile { target c++11 } }
+
+template
+decltype (T () * T () + 1.0) foo ()
+{
+ return T () * T () + 1.0;
+}
+
+void
+bar ()
+{
+ foo ();
+ foo ();
+ foo ();
+}
Jakub
[committed] c: Update checks on constexpr pointer initializers
WG14 has agreed a change of the rules on constexpr pointer
initializers, so that a (constant) null value that is not a null
pointer constant is accepted in that context, rather than only
accepting null pointer constants. (In particular, this means that a
constexpr variable of pointer type can be used to initializer another
such variable.) Remove the null pointer constant restriction in GCC,
instead checking just whether the value is null.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
gcc/c/
* c-typeck.cc (check_constexpr_init): Remove argument
null_pointer_constant. Only check pointer initializers for being
null.
(digest_init): Update calls to check_constexpr_init.
gcc/testsuite/
* gcc.dg/c2x-constexpr-1.c: Test initialization of constexpr
pointers with null values that are not null pointer constants.
* gcc.dg/c2x-constexpr-3.c: Test initialization of constexpr
pointers with non-null values, not with null values that are not
null pointer constants.
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index 224a9cbdc3d..157b77eda95 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -8186,23 +8186,20 @@ constexpr_init_fits_real_type (tree type, tree init)
/* Check whether INIT (location LOC) is valid as a 'constexpr'
initializer for type TYPE, and give an error if not. INIT has
- already been folded and verified to be constant.
- NULL_POINTER_CONSTANT, INT_CONST_EXPR and ARITH_CONST_EXPR say
- whether it is a null pointer constant, integer constant expression
- or arithmetic constant expression, respectively. If TYPE is not a
- scalar type, this function does nothing. */
+ already been folded and verified to be constant. INT_CONST_EXPR
+ and ARITH_CONST_EXPR say whether it is an integer constant
+ expression or arithmetic constant expression, respectively. If
+ TYPE is not a scalar type, this function does nothing. */
static void
check_constexpr_init (location_t loc, tree type, tree init,
- bool null_pointer_constant, bool int_const_expr,
- bool arith_const_expr)
+ bool int_const_expr, bool arith_const_expr)
{
if (POINTER_TYPE_P (type))
{
- /* The initializer must be a null pointer constant. */
- if (!null_pointer_constant)
- error_at (loc, "% pointer initializer is not a "
- "null pointer constant");
+ /* The initializer must be null. */
+ if (TREE_CODE (init) != INTEGER_CST || !integer_zerop (init))
+ error_at (loc, "% pointer initializer is not null");
return;
}
if (INTEGRAL_TYPE_P (type))
@@ -8582,8 +8579,7 @@ digest_init (location_t init_loc, tree type, tree init,
tree origtype,
"initializer element is not a constant expression");
else if (require_constexpr)
check_constexpr_init (init_loc, type, inside_init,
- null_pointer_constant, int_const_expr,
- arith_const_expr);
+ int_const_expr, arith_const_expr);
/* Added to enable additional -Wsuggest-attribute=format warnings. */
if (TREE_CODE (TREE_TYPE (inside_init)) == POINTER_TYPE)
@@ -8638,8 +8634,7 @@ digest_init (location_t init_loc, tree type, tree init,
tree origtype,
"initializer element is not a constant expression");
else if (require_constexpr)
check_constexpr_init (init_loc, type, unconverted_init,
- null_pointer_constant, int_const_expr,
- arith_const_expr);
+ int_const_expr, arith_const_expr);
return inside_init;
}
diff --git a/gcc/testsuite/gcc.dg/c2x-constexpr-1.c
b/gcc/testsuite/gcc.dg/c2x-constexpr-1.c
index 97b54f17428..898953020e7 100644
--- a/gcc/testsuite/gcc.dg/c2x-constexpr-1.c
+++ b/gcc/testsuite/gcc.dg/c2x-constexpr-1.c
@@ -176,6 +176,12 @@ constexpr int v97[100] = { [v82.x.f] = 7 };
static int v98[v94];
constexpr _Complex double v99 = 1.0;
constexpr _Complex float v100 = 12345;
+constexpr int *v101 = (int *) 0;
+constexpr void *v102 = (void *) (void *) 0;
+constexpr void *v103 = v101;
+constexpr void *v104 = v84;
+struct s105 { void *p; };
+constexpr struct s105 v106 = { (int *) 0 };
void
f0 ()
@@ -251,6 +257,11 @@ f0 ()
(constexpr union u58) { { 0 } }; /* { dg-warning "braces around scalar
initializer" } */
(constexpr _Complex double) { 1.0 };
(constexpr _Complex float) { 12345 };
+ (constexpr int *) { (int *) 0 };
+ (constexpr void *) { (void *) (void *) 0 };
+ (constexpr void *) { v101 };
+ (constexpr void *) { v84 };
+ (constexpr struct s105) { (int *) 0 };
/* It's not entirely clear if constexpr declarations are allowed in this
position in a for loop; presume they are, as implicitly auto just as if no
storage class specifiers were used. */
diff --git
[PATCH] libstdc++: testsuite: Add char8_t to codecvt_unicode
libstdc++-v3/ChangeLog:
* testsuite/22_locale/codecvt/codecvt_unicode.cc: Rename
functions.
* testsuite/22_locale/codecvt/codecvt_unicode.h: Make more
generic so it accepts char8_t.
* testsuite/22_locale/codecvt/codecvt_unicode_wchar_t.cc: Rename
functions.
* testsuite/22_locale/codecvt/codecvt_unicode_char8_t.cc: New test.
---
.../22_locale/codecvt/codecvt_unicode.cc | 16 +-
.../22_locale/codecvt/codecvt_unicode.h | 807 +-
.../codecvt/codecvt_unicode_char8_t.cc| 53 ++
.../codecvt/codecvt_unicode_wchar_t.cc| 6 +-
4 files changed, 484 insertions(+), 398 deletions(-)
create mode 100644
libstdc++-v3/testsuite/22_locale/codecvt/codecvt_unicode_char8_t.cc
diff --git a/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_unicode.cc
b/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_unicode.cc
index df1a2b4cc..eafb53a8c 100644
--- a/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_unicode.cc
+++ b/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_unicode.cc
@@ -27,38 +27,38 @@ void
test_utf8_utf32_codecvts ()
{
using codecvt_c32 = codecvt;
- auto loc_c = locale::classic ();
+ auto _c = locale::classic ();
VERIFY (has_facet (loc_c));
auto = use_facet (loc_c);
- test_utf8_utf32_codecvts (cvt);
+ test_utf8_utf32_cvt (cvt);
codecvt_utf8 cvt2;
- test_utf8_utf32_codecvts (cvt2);
+ test_utf8_utf32_cvt (cvt2);
}
void
test_utf8_utf16_codecvts ()
{
using codecvt_c16 = codecvt;
- auto loc_c = locale::classic ();
+ auto _c = locale::classic ();
VERIFY (has_facet (loc_c));
auto = use_facet (loc_c);
- test_utf8_utf16_cvts (cvt);
+ test_utf8_utf16_cvt (cvt);
codecvt_utf8_utf16 cvt2;
- test_utf8_utf16_cvts (cvt2);
+ test_utf8_utf16_cvt (cvt2);
codecvt_utf8_utf16 cvt3;
- test_utf8_utf16_cvts (cvt3);
+ test_utf8_utf16_cvt (cvt3);
}
void
test_utf8_ucs2_codecvts ()
{
codecvt_utf8 cvt;
- test_utf8_ucs2_cvts (cvt);
+ test_utf8_ucs2_cvt (cvt);
}
int
diff --git a/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_unicode.h
b/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_unicode.h
index fbdc7a35b..690c07215 100644
--- a/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_unicode.h
+++ b/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_unicode.h
@@ -42,33 +42,33 @@ auto constexpr array_size (const T (&)[N]) -> size_t
return N;
}
-template
+template
void
-utf8_to_utf32_in_ok (const std::codecvt )
+utf8_to_utf32_in_ok (const std::codecvt )
{
using namespace std;
// UTF-8 string of 1-byte CP, 2-byte CP, 3-byte CP and 4-byte CP
- const char in[] = "bш\u\U0010";
- const char32_t exp_literal[] = U"bш\u\U0010";
- CharT exp[array_size (exp_literal)] = {};
- std::copy (begin (exp_literal), end (exp_literal), begin (exp));
-
- static_assert (array_size (in) == 11, "");
- static_assert (array_size (exp_literal) == 5, "");
- static_assert (array_size (exp) == 5, "");
- VERIFY (char_traits::length (in) == 10);
- VERIFY (char_traits::length (exp_literal) == 4);
- VERIFY (char_traits::length (exp) == 4);
+ const unsigned char input[] = "bш\u\U0010";
+ const char32_t expected[] = U"bш\u\U0010";
+ static_assert (array_size (input) == 11, "");
+ static_assert (array_size (expected) == 5, "");
+
+ ExternT in[array_size (input)];
+ InternT exp[array_size (expected)];
+ copy (begin (input), end (input), begin (in));
+ copy (begin (expected), end (expected), begin (exp));
+ VERIFY (char_traits::length (in) == 10);
+ VERIFY (char_traits::length (exp) == 4);
test_offsets_ok offsets[] = {{0, 0}, {1, 1}, {3, 2}, {6, 3}, {10, 4}};
for (auto t : offsets)
{
- CharT out[array_size (exp) - 1] = {};
+ InternT out[array_size (exp) - 1] = {};
VERIFY (t.in_size <= array_size (in));
VERIFY (t.out_size <= array_size (out));
auto state = mbstate_t{};
- auto in_next = (const char *) nullptr;
- auto out_next = (CharT *) nullptr;
+ auto in_next = (const ExternT *) nullptr;
+ auto out_next = (InternT *) nullptr;
auto res = codecvt_base::result ();
res = cvt.in (state, in, in + t.in_size, in_next, out, out + t.out_size,
@@ -76,19 +76,19 @@ utf8_to_utf32_in_ok (const std::codecvt )
VERIFY (res == cvt.ok);
VERIFY (in_next == in + t.in_size);
VERIFY (out_next == out + t.out_size);
- VERIFY (char_traits::compare (out, exp, t.out_size) == 0);
+ VERIFY (char_traits::compare (out, exp, t.out_size) == 0);
if (t.out_size < array_size (out))
VERIFY (out[t.out_size] == 0);
}
for (auto t : offsets)
{
- CharT out[array_size (exp)] = {};
+ InternT out[array_size (exp)] = {};
VERIFY (t.in_size <= array_size (in));
VERIFY (t.out_size <= array_size (out));
auto state = mbstate_t{};
- auto in_next = (const char *) nullptr;
- auto out_next = (CharT *) nullptr;
+
Re: [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]
> On Feb 8, 2023, at 2:09 PM, Joseph Myers wrote:
>
> On Wed, 8 Feb 2023, Qing Zhao via Gcc-patches wrote:
>
>> But I noticed that “flexible_array_type_p” later was moved from FE to
>> middle-end and put into tree.cc, tree.h as a general utility routine, and to
>>
>> /* Determine whether TYPE is a structure with a flexible array member,
>> or a union containing such a structure (possibly recursively). */
>>
>> However, since this routine does not cover the cases when the structure
>> with flexible array member was recursively embedded into structures, (which
>> we
>> agreed that it should be considered as a flexible sized type).
>>
>> Therefore, I feel that It might not be proper to include this routine in
>> middle end
>> (and actually no other places In middle end use this routine so far).
>
> I think we've established that diagnostics and at least some middle-end
> purposes need different conditions.
Yes, agreed.
> Diagnostics for nesting a structure
> with a flexible array member inside another structure should only count []
> as a flexible array member,
Diagnostics should be consistent with the documentation.
The use cases that violate what is defined in documentation should be
diagnostics.
This include both C standard and GCC extension.
For C standard violation, -pedantic will report them.
For GCC extension, the corresponding warning message should report them.
And both such warning can be issued either in FE or in Middle end.
Is the above understand correct?
> whereas permitting flexible array uses in the
> middle end should allow [0] and [1] under some circumstances (depending on
> command-line options).
>
>> But:
>>
>> struct flex0 { int n; int data[0]; };
>> struct out_flex_end0 { int m; struct flex0 flex_data; };
>> struct outer_flex_end0 { int p; struct out_flex_end0 out_flex_data; };
>>
>> In the above, only “flex0” is flexible sized type by default.
>> But “out_flex_end0” and “out_flex_end0” are Not considered as flexible sized
>> type by default?
>
> It would be OK (and I'm not saying here that this is necessarily
> desirable), since that's at the end of another structure rather than in
> the middle, to consider them flexible for the purposes of code generation.
This is the part I am still not very clear and not feel very comfortable:
In the documentation on GCC extension of embedding structure with flexible
array member into another structure/union,
Should we include [0], [1] and [n] cases as GCC extension by default? Or we
only include [] for nested struct as an extension?
For example:
struct flex0 { int length; char data[0]; };
struct out_flex0 { int m; struct flex0 flex_data; };
struct out_flex0_mid { struct flex0 flex_data; int m};
Should we treat the above out_flex0->flex_data as flexible array by default?
Should we issue warning for the above out_flex9_mid with a new warning option
-Wgnu-variable-sized-type-at-end?
How about the following:
struct flex1 { int length; char data[1]; };
struct out_flex1 { int m; struct flex1 flex_data; };
struct out_flex1_mid { struct flex1 flex_data; int m};
And:
struct flexn { int length; char data[4]; };
struct out_flexn { int m; struct flexn flex_data; };
struct out_flexn_mid { struct flexn flex_data; int m};
>
> What must be avoided is -pedantic diagnostics for
>
> struct flex1 { int n; int data[1]; };
> struct out_flex_end1 { int m; struct flex1 flex_data; };
>
> regardless of whether considered flexible or not, since that's clearly
> valid in standard C.
Yes, agreed.
Thanks.
Qing
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
Re: [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]
> On Feb 8, 2023, at 2:20 PM, Siddhesh Poyarekar wrote:
>
> On 2023-02-08 14:09, Joseph Myers wrote:
>> What must be avoided is -pedantic diagnostics for
>> struct flex1 { int n; int data[1]; };
>> struct out_flex_end1 { int m; struct flex1 flex_data; };
>> regardless of whether considered flexible or not, since that's clearly
>> valid in standard C.
>
> Are you sure about "regardless of whether considered flexible or not", since
> ISTM the validity of the above in standard C is limited to when it's
> considered a non-flexible array. So with -pedantic it shouldn't warn, but it
> also then shouldn't consider it a flexible array.
>
> In other words, perhaps it makes sense to imply -fstrict-flex-arrays with
> -pedantic?
I think -pedantic might imply -fstrict-flex-arrays=3, but not
-fstrict-flex-arrays=n when n < 3. Right?
Qing
>
> Sid
[pushed] doc: Change fsf.org to www.fsf.org
fsf.org has been serving a 301 (permanent redirect) http response for
a long while.
gcc/ChangeLog:
* doc/include/gpl_v3.texi: Change fsf.org to www.fsf.org.
---
gcc/doc/include/gpl_v3.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/include/gpl_v3.texi b/gcc/doc/include/gpl_v3.texi
index c978f2154d2..4193d6fd55d 100644
--- a/gcc/doc/include/gpl_v3.texi
+++ b/gcc/doc/include/gpl_v3.texi
@@ -20,7 +20,7 @@ license document, but changing it is not allowed.
@c This file is intended to be included in another file.
@display
-Copyright @copyright{} 2007 Free Software Foundation, Inc.
@url{https://fsf.org/}
+Copyright @copyright{} 2007 Free Software Foundation, Inc.
@url{https://www.fsf.org}
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
--
2.39.1
[PATCH] When simplifing BFR of an insert, require a mode precision integral type (PR108688)
The same problem as PR 88739 has crept in but
this time in match.pd when simplifying bit_field_ref of
an bit_insert. That is we are generating a BIT_FIELD_REF
of a non-mode-precision integral type.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
PR tree-optimization/108688
gcc/ChangeLog:
* match.pd (bit_field_ref [bit_insert]):
Avoid generating BIT_FIELD_REFs of non-mode-precision
integral operands
gcc/testsuite/ChangeLog:
* gcc.c-torture/compile/pr108688-1.c: New test.
---
gcc/match.pd | 4 +++-
gcc/testsuite/gcc.c-torture/compile/pr108688-1.c | 15 +++
2 files changed, 18 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.c-torture/compile/pr108688-1.c
diff --git a/gcc/match.pd b/gcc/match.pd
index c9e8bebede2..d8353072822 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -7487,7 +7487,9 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
isize = tree_to_uhwi (TYPE_SIZE (TREE_TYPE (@1)));
}
(switch
- (if (wi::leu_p (wi::to_wide (@ipos), wi::to_wide (@rpos))
+ (if ((!INTEGRAL_TYPE_P (TREE_TYPE (@1))
+ || type_has_mode_precision_p (TREE_TYPE (@1)))
+&& wi::leu_p (wi::to_wide (@ipos), wi::to_wide (@rpos))
&& wi::leu_p (wi::to_wide (@rpos) + wi::to_wide (@rsize),
wi::to_wide (@ipos) + isize))
(BIT_FIELD_REF @1 @rsize { wide_int_to_tree (bitsizetype,
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr108688-1.c
b/gcc/testsuite/gcc.c-torture/compile/pr108688-1.c
new file mode 100644
index 000..43d782d62bd
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr108688-1.c
@@ -0,0 +1,15 @@
+
+
+union U { signed int d : 7; signed int e : 2; } u;
+int a, b;
+
+void
+foo (void)
+{
+ for (int i = 0; i < 64; i++)
+{
+ u.d = a;
+ u.e ^= b;
+}
+}
+
--
2.17.1
[PATCH] c++: ICE initing lifetime-extended constexpr var [PR107079]
(This may not be a complete fix but I got stuck so I'm posting what
I have, which at least fixes the ICE.)
We ICE on the simple:
struct X { const X* x = this; };
constexpr const X& x = X{};
where store_init_value initializes 'x' with
_EXPR }>
but we must lifetime-extend via extend_ref_init_temps and we get
_ZGR1x_.x = (const struct X *) & >>>;, (const
struct X &) &_ZGR1x_;
Since 'x' was declared constexpr, we do cxx_constant_init and we hit
the preeval code added in r269003 while evaluating the INIT_EXPR:
_ZGR1x_.x = (const struct X *) & >>>
but we have no ctx.ctor or ctx.object here so lookup_placeholder won't
find anything that could replace X and we ICE on
7861 /* A placeholder without a referent. We can get here when
7862 checking whether NSDMIs are noexcept, or in massage_init_elt;
7863 just say it's non-constant for now. */
7864 gcc_assert (ctx->quiet);
because cxx_constant_init means !ctx->quiet. It's not correct that
there isn't a referent. I think the following patch is a pretty
straightforward fix: pass the _ZGR var down to maybe_constant_init so
that it can replace the PLACEHOLDER_EXPR with _ZGR1x_.
What I wasn't able to make work is the commented assert in the test.
It doesn't pass because we complain that _ZGR1x_ isn't a constexpr
variable, but making it so would just result in "used in its own
initializer" (which is true). I notice that while clang++ compiles
the assert fine, MSVC++/icc reject it as non-constant. So maybe we
don't have to/shouldn't make it work.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
PR c++/107079
gcc/cp/ChangeLog:
* call.cc (set_up_extended_ref_temp): Pass var to maybe_constant_init.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-nsdmi2.C: New test.
---
gcc/cp/call.cc| 2 +-
gcc/testsuite/g++.dg/cpp0x/constexpr-nsdmi2.C | 9 +
2 files changed, 10 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-nsdmi2.C
diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index f7c5d9da94b..a0afab9b26a 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -13583,7 +13583,7 @@ set_up_extended_ref_temp (tree decl, tree expr,
vec **cleanups,
/* If the initializer is constant, put it in DECL_INITIAL so we get
static initialization and use in constant expressions. */
- init = maybe_constant_init (expr);
+ init = maybe_constant_init (expr, var);
/* As in store_init_value. */
init = cp_fully_fold (init);
if (TREE_CONSTANT (init))
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-nsdmi2.C
b/gcc/testsuite/g++.dg/cpp0x/constexpr-nsdmi2.C
new file mode 100644
index 000..6dbb7eb739a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-nsdmi2.C
@@ -0,0 +1,9 @@
+// PR c++/107079
+// { dg-do compile { target c++11 } }
+
+struct X {
+ const X* x = this;
+};
+constexpr const X& x = X{};
+// TODO: Should the assert pass?
+//static_assert(x.x == );
base-commit: 77bb54b1b07add45007c664724b726541d672ef3
--
2.39.1
[PATCH] RISC-V: Add vmadc/vsbc C/C++ API support
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc (class vmadc): New class.
(class vmsbc): Ditto.
(BASE): Define new class.
* config/riscv/riscv-vector-builtins-bases.h: Ditto.
* config/riscv/riscv-vector-builtins-functions.def (vmadc): New define.
(vmsbc): Ditto.
* config/riscv/riscv-vector-builtins-shapes.cc (struct
return_mask_def): New class.
(SHAPE): Ditto.
* config/riscv/riscv-vector-builtins-shapes.h: Ditto.
* config/riscv/riscv-vector-builtins.cc
(function_expander::use_exact_insn): Adjust for new support
* config/riscv/riscv-vector-builtins.h
(function_base::has_merge_operand_p): New function.
* config/riscv/vector-iterators.md: New iterator.
* config/riscv/vector.md (@pred_madc): New pattern.
(@pred_msbc): Ditto.
(@pred_madc_scalar): Ditto.
(@pred_msbc_scalar): Ditto.
(*pred_madc_scalar): Ditto.
(*pred_madc_extended_scalar): Ditto.
(*pred_msbc_scalar): Ditto.
(*pred_msbc_extended_scalar): Ditto.
(@pred_madc_overflow): Ditto.
(@pred_msbc_overflow): Ditto.
(@pred_madc_overflow_scalar): Ditto.
(@pred_msbc_overflow_scalar): Ditto.
(*pred_madc_overflow_scalar): Ditto.
(*pred_madc_overflow_extended_scalar): Ditto.
(*pred_msbc_overflow_scalar): Ditto.
(*pred_msbc_overflow_extended_scalar): Ditto.
---
.../riscv/riscv-vector-builtins-bases.cc | 62 +++
.../riscv/riscv-vector-builtins-bases.h | 2 +
.../riscv/riscv-vector-builtins-functions.def | 8 +
.../riscv/riscv-vector-builtins-shapes.cc | 28 +
.../riscv/riscv-vector-builtins-shapes.h | 1 +
gcc/config/riscv/riscv-vector-builtins.cc | 34 +-
gcc/config/riscv/riscv-vector-builtins.h | 11 +
gcc/config/riscv/vector-iterators.md | 3 +
gcc/config/riscv/vector.md| 494 ++
9 files changed, 642 insertions(+), 1 deletion(-)
diff --git a/gcc/config/riscv/riscv-vector-builtins-bases.cc
b/gcc/config/riscv/riscv-vector-builtins-bases.cc
index 8bf5bb97ca1..bcf2dfe805a 100644
--- a/gcc/config/riscv/riscv-vector-builtins-bases.cc
+++ b/gcc/config/riscv/riscv-vector-builtins-bases.cc
@@ -338,6 +338,64 @@ public:
}
};
+/* Implements vmadc. */
+class vmadc : public function_base
+{
+public:
+ bool apply_tail_policy_p () const override { return false; }
+ bool apply_mask_policy_p () const override { return false; }
+ bool use_mask_predication_p () const override { return false; }
+ bool has_merge_operand_p () const override { return false; }
+
+ rtx expand (function_expander ) const override
+ {
+switch (e.op_info->op)
+ {
+ case OP_TYPE_vvm:
+ return e.use_exact_insn (code_for_pred_madc (e.vector_mode ()));
+ case OP_TYPE_vxm:
+ return e.use_exact_insn (code_for_pred_madc_scalar (e.vector_mode ()));
+ case OP_TYPE_vv:
+ return e.use_exact_insn (
+ code_for_pred_madc_overflow (e.vector_mode ()));
+ case OP_TYPE_vx:
+ return e.use_exact_insn (
+ code_for_pred_madc_overflow_scalar (e.vector_mode ()));
+ default:
+ gcc_unreachable ();
+ }
+ }
+};
+
+/* Implements vmsbc. */
+class vmsbc : public function_base
+{
+public:
+ bool apply_tail_policy_p () const override { return false; }
+ bool apply_mask_policy_p () const override { return false; }
+ bool use_mask_predication_p () const override { return false; }
+ bool has_merge_operand_p () const override { return false; }
+
+ rtx expand (function_expander ) const override
+ {
+switch (e.op_info->op)
+ {
+ case OP_TYPE_vvm:
+ return e.use_exact_insn (code_for_pred_msbc (e.vector_mode ()));
+ case OP_TYPE_vxm:
+ return e.use_exact_insn (code_for_pred_msbc_scalar (e.vector_mode ()));
+ case OP_TYPE_vv:
+ return e.use_exact_insn (
+ code_for_pred_msbc_overflow (e.vector_mode ()));
+ case OP_TYPE_vx:
+ return e.use_exact_insn (
+ code_for_pred_msbc_overflow_scalar (e.vector_mode ()));
+ default:
+ gcc_unreachable ();
+ }
+ }
+};
+
static CONSTEXPR const vsetvl vsetvl_obj;
static CONSTEXPR const vsetvl vsetvlmax_obj;
static CONSTEXPR const loadstore vle_obj;
@@ -398,6 +456,8 @@ static CONSTEXPR const vwcvt vwcvt_x_obj;
static CONSTEXPR const vwcvt vwcvtu_x_obj;
static CONSTEXPR const vadc vadc_obj;
static CONSTEXPR const vsbc vsbc_obj;
+static CONSTEXPR const vmadc vmadc_obj;
+static CONSTEXPR const vmsbc vmsbc_obj;
static CONSTEXPR const binop vsadd_obj;
static CONSTEXPR const binop vssub_obj;
static CONSTEXPR const binop vsaddu_obj;
@@ -468,6 +528,8 @@ BASE (vwcvt_x)
BASE (vwcvtu_x)
BASE (vadc)
BASE (vsbc)
+BASE (vmadc)
+BASE (vmsbc)
BASE (vsadd)
BASE (vssub)
BASE (vsaddu)
diff --git a/gcc/config/riscv/riscv-vector-builtins-bases.h
Re: [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]
On Wed, 8 Feb 2023, Siddhesh Poyarekar wrote:
> On 2023-02-08 14:09, Joseph Myers wrote:
> > What must be avoided is -pedantic diagnostics for
> >
> > struct flex1 { int n; int data[1]; };
> > struct out_flex_end1 { int m; struct flex1 flex_data; };
> >
> > regardless of whether considered flexible or not, since that's clearly
> > valid in standard C.
> >
>
> Are you sure about "regardless of whether considered flexible or not", since
> ISTM the validity of the above in standard C is limited to when it's
> considered a non-flexible array. So with -pedantic it shouldn't warn, but it
> also then shouldn't consider it a flexible array.
>
> In other words, perhaps it makes sense to imply -fstrict-flex-arrays with
> -pedantic?
There should be no code generation effects from -pedantic.
--
Joseph S. Myers
jos...@codesourcery.com
[PATCH] testsuite: Fix asm-goto-with-outputs tests; limit to lra targets
Sanity-checked for cris-elf with the
check_effective_target_lra correction in
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611531.html
Committed as obvious.
--- 8< ---
These tests spuriously lacked a "lra" limiter. Code using
"asm goto" with outputs gets a:
error: the target does not support 'asm goto' with outputs in 'asm'
compilation error when compiled for a non-LRA target. Limit
to LRA targets as other asm-goto-with-outputs tests.
* gcc.dg/torture/pr100398.c: Limit to lra targets.
* gcc.dg/pr100590.c: Ditto.
---
gcc/testsuite/gcc.dg/pr100590.c | 2 +-
gcc/testsuite/gcc.dg/torture/pr100398.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/pr100590.c b/gcc/testsuite/gcc.dg/pr100590.c
index 5cd36877fa1d..8d1e1a0d3064 100644
--- a/gcc/testsuite/gcc.dg/pr100590.c
+++ b/gcc/testsuite/gcc.dg/pr100590.c
@@ -1,5 +1,5 @@
/* PR rtl-optimization/100590 */
-/* { dg-do compile } */
+/* { dg-do compile { target lra } } */
/* { dg-options "-O1 -fno-dce -w" } */
int
diff --git a/gcc/testsuite/gcc.dg/torture/pr100398.c
b/gcc/testsuite/gcc.dg/torture/pr100398.c
index 41eaddee27e4..4fc1168d22fd 100644
--- a/gcc/testsuite/gcc.dg/torture/pr100398.c
+++ b/gcc/testsuite/gcc.dg/torture/pr100398.c
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-do compile { target lra } } */
int
test5_limit (void)
--
2.30.2
Re: [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]
On 2023-02-08 14:09, Joseph Myers wrote:
What must be avoided is -pedantic diagnostics for
struct flex1 { int n; int data[1]; };
struct out_flex_end1 { int m; struct flex1 flex_data; };
regardless of whether considered flexible or not, since that's clearly
valid in standard C.
Are you sure about "regardless of whether considered flexible or not",
since ISTM the validity of the above in standard C is limited to when
it's considered a non-flexible array. So with -pedantic it shouldn't
warn, but it also then shouldn't consider it a flexible array.
In other words, perhaps it makes sense to imply -fstrict-flex-arrays
with -pedantic?
Sid
[PATCH] tree-optimization: [PR108684] ICE in verify_ssa due to simple_dce_from_worklist
In simple_dce_from_worklist, we were removing an inline-asm which had a vdef
(due to clobbering memory) but not unlinking the statement's vdef.
This fixes that oversight. This was a latent bug exposed recently
by both VRP and removal of stores to static starting to use
simple_dce_from_worklist.
OK for trunk (and for GCC 12 after a week)?
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
PR tree-optimization/108684
gcc/ChangeLog:
* tree-ssa-dce.cc (simple_dce_from_worklist):
Call unlink_stmt_vdef on the statement before
removing it.
gcc/testsuite/ChangeLog:
* gcc.c-torture/compile/dce-inline-asm-1.c: New test.
* gcc.c-torture/compile/dce-inline-asm-2.c: New test.
co-authored-by: Andrew Macleod
---
.../gcc.c-torture/compile/dce-inline-asm-1.c | 15 +++
.../gcc.c-torture/compile/dce-inline-asm-2.c | 16
gcc/tree-ssa-dce.cc | 1 +
3 files changed, 32 insertions(+)
create mode 100644 gcc/testsuite/gcc.c-torture/compile/dce-inline-asm-1.c
create mode 100644 gcc/testsuite/gcc.c-torture/compile/dce-inline-asm-2.c
diff --git a/gcc/testsuite/gcc.c-torture/compile/dce-inline-asm-1.c
b/gcc/testsuite/gcc.c-torture/compile/dce-inline-asm-1.c
new file mode 100644
index 000..a9f02e44bd7
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/dce-inline-asm-1.c
@@ -0,0 +1,15 @@
+/* PR tree-optimization/108684 */
+/* This used to ICE as when we remove the store to
+ `t`, we also would remove the inline-asm which
+ had a VDEF on it but we didn't update the
+ VUSE that was later on. */
+static int t;
+
+int f (int *a)
+{
+ int t1;
+ asm (" " : "=X" (t1) : : "memory");
+ t = t1;
+ return *a;
+}
+
diff --git a/gcc/testsuite/gcc.c-torture/compile/dce-inline-asm-2.c
b/gcc/testsuite/gcc.c-torture/compile/dce-inline-asm-2.c
new file mode 100644
index 000..a41b16e4bd0
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/dce-inline-asm-2.c
@@ -0,0 +1,16 @@
+/* PR tree-optimization/108684 */
+/* This used to ICE as when we removed the
+ __builtin_unreachable in VRP, as we
+ would also remove the branch and the
+ inline-asm. The inline-asm had a VDEF on it,
+ which we didn't update further along and
+ not have the VDEF on the return statement
+ updated. */
+
+int f (int a)
+{
+ asm (" " : "=X" (a) : : "memory");
+ if (a)
+return 0;
+ __builtin_unreachable();
+}
diff --git a/gcc/tree-ssa-dce.cc b/gcc/tree-ssa-dce.cc
index b2fe9f4f55e..752785541e4 100644
--- a/gcc/tree-ssa-dce.cc
+++ b/gcc/tree-ssa-dce.cc
@@ -2140,6 +2140,7 @@ simple_dce_from_worklist (bitmap worklist)
remove_phi_node (, true);
else
{
+ unlink_stmt_vdef (t);
gsi_remove (, true);
release_defs (t);
}
--
2.31.1
Re: [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]
On Wed, 8 Feb 2023, Qing Zhao via Gcc-patches wrote:
> But I noticed that “flexible_array_type_p” later was moved from FE to
> middle-end and put into tree.cc, tree.h as a general utility routine, and to
>
> /* Determine whether TYPE is a structure with a flexible array member,
>or a union containing such a structure (possibly recursively). */
>
> However, since this routine does not cover the cases when the structure
> with flexible array member was recursively embedded into structures, (which
> we
> agreed that it should be considered as a flexible sized type).
>
> Therefore, I feel that It might not be proper to include this routine in
> middle end
> (and actually no other places In middle end use this routine so far).
I think we've established that diagnostics and at least some middle-end
purposes need different conditions. Diagnostics for nesting a structure
with a flexible array member inside another structure should only count []
as a flexible array member, whereas permitting flexible array uses in the
middle end should allow [0] and [1] under some circumstances (depending on
command-line options).
> But:
>
> struct flex0 { int n; int data[0]; };
> struct out_flex_end0 { int m; struct flex0 flex_data; };
> struct outer_flex_end0 { int p; struct out_flex_end0 out_flex_data; };
>
> In the above, only “flex0” is flexible sized type by default.
> But “out_flex_end0” and “out_flex_end0” are Not considered as flexible sized
> type by default?
It would be OK (and I'm not saying here that this is necessarily
desirable), since that's at the end of another structure rather than in
the middle, to consider them flexible for the purposes of code generation.
What must be avoided is -pedantic diagnostics for
struct flex1 { int n; int data[1]; };
struct out_flex_end1 { int m; struct flex1 flex_data; };
regardless of whether considered flexible or not, since that's clearly
valid in standard C.
--
Joseph S. Myers
jos...@codesourcery.com
[pushed] analyzer: fix overzealous state purging with on-stack structs [PR108704]
PR analyzer/108704 reports many false positives seen from
-Wanalyzer-use-of-uninitialized-value on qemu's softfloat.c on code like
the following:
struct st s;
s = foo ();
s = bar (s); // bogusly reports that s is uninitialized here
where e.g. "struct st" is "floatx80" in the qemu examples.
The root cause is overzealous purging of on-stack structs in the code I
added in r12-7718-gfaacafd2306ad7, where at:
s = bar (s);
state_purge_per_decl::process_point_backwards "sees" the assignment to 's'
and stops processing, effectively treating 's' as unneeded before this
stmt, not noticing the use of 's' in the argument.
Fixed thusly.
The patch greatly reduces the number of
-Wanalyzer-use-of-uninitialized-value warnings from my integration tests:
ImageMagick-7.1.0-57: 10 -> 6 (-4)
qemu-7.2: 858 -> 87 (-771)
haproxy-2.7.1: 1 -> 0 (-1)
All of the above that I've examined appear to be false positives.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-5745-g77bb54b1b07add.
gcc/analyzer/ChangeLog:
PR analyzer/108704
* state-purge.cc (state_purge_per_decl::process_point_backwards):
Don't stop processing the decl if it's fully overwritten by
this stmt if it's also used by this stmt.
gcc/testsuite/ChangeLog:
PR analyzer/108704
* gcc.dg/analyzer/uninit-7.c: New test.
* gcc.dg/analyzer/uninit-pr108704.c: New test.
Signed-off-by: David Malcolm
---
gcc/analyzer/state-purge.cc | 15 ++-
gcc/testsuite/gcc.dg/analyzer/uninit-7.c | 127 ++
.../gcc.dg/analyzer/uninit-pr108704.c | 29
3 files changed, 170 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.dg/analyzer/uninit-7.c
create mode 100644 gcc/testsuite/gcc.dg/analyzer/uninit-pr108704.c
diff --git a/gcc/analyzer/state-purge.cc b/gcc/analyzer/state-purge.cc
index 5fa596d98fb..5f2d1f7fefa 100644
--- a/gcc/analyzer/state-purge.cc
+++ b/gcc/analyzer/state-purge.cc
@@ -922,7 +922,20 @@ process_point_backwards (const function_point ,
{
/* This is somewhat equivalent to how the SSA case handles
def-stmts. */
- if (fully_overwrites_p (point.get_stmt (), m_decl, model))
+ if (fully_overwrites_p (point.get_stmt (), m_decl, model)
+ /* ...but we mustn't be at a point that also consumes the
+ current value of the decl when it's generating the new
+ value, for cases such as
+ struct st s;
+ s = foo ();
+ s = bar (s);
+ where we want to make sure that we don't stop at the:
+ s = bar (s);
+ since otherwise we would erroneously purge the state of "s"
+ after:
+ s = foo ();
+ */
+ && !m_points_needing_decl.contains (point))
{
if (logger)
logger->log ("stmt fully overwrites %qE; terminating", m_decl);
diff --git a/gcc/testsuite/gcc.dg/analyzer/uninit-7.c
b/gcc/testsuite/gcc.dg/analyzer/uninit-7.c
new file mode 100644
index 000..cb3e29abe8f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/uninit-7.c
@@ -0,0 +1,127 @@
+typedef struct st
+{
+ char buf[16];
+} st;
+
+extern st foo (st);
+extern st bar (st *);
+extern char baz (st);
+
+void test_1 (st a)
+{
+ st b, c, d, e;
+
+ b = a;
+ c = foo(a);
+ d = bar();
+ c = foo(e); /* { dg-warning "use of uninitialized value 'e'" } */
+}
+
+void test_2 (st a)
+{
+ a = a;
+}
+
+st test_2a (void)
+{
+ st a;
+ a = a; /* { dg-warning "use of uninitialized value 'a'" } */
+ return a;
+}
+
+void test_3 (st a)
+{
+ a = foo (a);
+}
+
+st test_3a (void)
+{
+ st a;
+ a = foo (a); /* { dg-warning "use of uninitialized value 'a'" } */
+ return a;
+}
+
+void test_3b (st a, st b)
+{
+ a = foo (a);
+ foo (b);
+ a = foo (a);
+ foo (b);
+ a = foo (a);
+ foo (b);
+}
+
+void test_4 (st a)
+{
+ a = bar ();
+}
+
+st test_4a (void)
+{
+ st a;
+ a = bar ();
+ return a;
+}
+
+void test_5 (st a)
+{
+ st b;
+ a = bar ();
+ b = b; /* { dg-warning "use of uninitialized value 'b'" } */
+}
+
+st test_6 (st a)
+{
+ st b;
+ a = bar ();
+ b = b;
+ return b;
+}
+
+void test_6a (st a)
+{
+ st b;
+ a = bar ();
+ b = b;
+}
+
+st test_7 (st a)
+{
+ st b;
+ b = bar ();
+ return b;
+}
+
+void test_7a (st a)
+{
+ st b;
+ b = bar ();
+}
+
+st test_8 (void)
+{
+ st b;
+ b = bar ();
+ return b;
+}
+
+void test_8a (void)
+{
+ st b;
+ b = bar ();
+}
+
+char test_9 (st a)
+{
+ char c;
+ c = baz (a);
+ return c;
+}
+
+char test_10 (st a)
+{
+ char c;
+ a = foo (a);
+ c = baz (a);
+ return c;
+}
diff --git a/gcc/testsuite/gcc.dg/analyzer/uninit-pr108704.c
b/gcc/testsuite/gcc.dg/analyzer/uninit-pr108704.c
new file mode 100644
index 000..ebf8151e58f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/uninit-pr108704.c
@@ -0,0 +1,29 @@
+typedef unsigned short int
Re: libquadmath fix for 94756 and 87204
Is it too soon to ping again? :) I think Nixman needs some feedback as to whether he's on the right track in addressing your concerns. On Sun, Feb 5, 2023, 12:39 NightStrike wrote: > Jakub, ping > > On Thu, Jan 26, 2023, 12:50 i.nixman--- via Gcc-patches < > gcc-patches@gcc.gnu.org> wrote: > >> hello, >> >> could someone look at the patch attached please? >> >> https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610392.html >> >
[pushed, wwwdocs] gcc-13: add -Wxor-used-as-pow
--- htdocs/gcc-13/changes.html | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html index 8c0201f2..d70ac1de 100644 --- a/htdocs/gcc-13/changes.html +++ b/htdocs/gcc-13/changes.html @@ -153,7 +153,17 @@ a work-in-progress. - +C family + + New warnings: + + https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wxor-used-as-pow;>-Wxor-used-as-pow + warns about uses of ^, the exclusive or operator, + where it appears the user meant exponentiation + (https://gcc.gnu.org/PR90885;>PR90885) + + + C -- 2.37.1
[pushed, wwwdocs] gcc-13: add SARIF and other diagnostics improvements
--- htdocs/gcc-13/changes.html | 30 +- 1 file changed, 29 insertions(+), 1 deletion(-) diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html index a48ac220..8c0201f2 100644 --- a/htdocs/gcc-13/changes.html +++ b/htdocs/gcc-13/changes.html @@ -128,6 +128,23 @@ a work-in-progress. will no longer add startup code to alter the floating-point environment when producing a shared object with -shared. + +GCC can now emit its diagnostics using https://sarifweb.azurewebsites.net/;>SARIF. +This is a JSON-based format suited for capturing the results of static +analysis tools (like GCC's https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html;>-fanalyzer), +but it can also be used to capture other GCC warnings and errors in a +machine-readable format. +Specifically, the https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Message-Formatting-Options.html#index-fdiagnostics-format;>-fdiagnostics-format= +option has been extended to support these new values: + + -fdiagnostics-format=sarif-stderr + -fdiagnostics-format=sarif-file + -fdiagnostics-format=json-stderr, a synonym for the + existing -fdiagnostics-format=json + -fdiagnostics-format=json-file + +where the json-prefixed variants refer to GCC's own JSON diagnostic format. + @@ -453,7 +470,18 @@ a work-in-progress. - +Improvements for plugin authors + + + GCC diagnostics can now be +https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=0b14f590e3e9d95b8211b77d992589d5ab4c25f0;>associated with rules +such as from coding standards documents, or specifications. +Such rules have a code name and can have a URL, which GCC can print +in text form or capture in its +https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Message-Formatting-Options.html#index-fdiagnostics-format;>SARIF +output when emitting diagnostics. + + Other significant improvements -- 2.37.1
[pushed, wwwdocs] gcc-13: add analyzer improvements
--- htdocs/gcc-13/changes.html | 58 ++ 1 file changed, 58 insertions(+) diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html index d70ac1de..5dbcc229 100644 --- a/htdocs/gcc-13/changes.html +++ b/htdocs/gcc-13/changes.html @@ -50,6 +50,9 @@ a work-in-progress. bounds accesses to trailing struct members of one-element array type anymore. Instead it diagnoses accesses to trailing arrays according to -fstrict-flex-arrays. +https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html;>-fanalyzer + is still only suitable for analyzing C code. + In particular, using it on C++ is unlikely to give meaningful output. @@ -163,6 +166,16 @@ a work-in-progress. (https://gcc.gnu.org/PR90885;>PR90885) + Three new function attributes for documenting int arguments that are file descriptors: + + https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-fd_005farg-function-attribute;>__attribute__((fd_arg(N))) + https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-fd_005farg_005fread-function-attribute;>__attribute__((fd_arg_read(N))) + https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-fd_005farg_005fwrite-function-attribute;>__attribute__((fd_arg_write(N))) + +These are used by +https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html;>-fanalyzer +to detect misuses of file descriptors. + C @@ -479,6 +492,51 @@ a work-in-progress. +Improvements to Static Analyzer + + The analyzer has gained 20 new warnings: + + https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-allocation-size;>-Wanalyzer-allocation-size + https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-deref-before-check;>-Wanalyzer-deref-before-check + https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-exposure-through-uninit-copy;>-Wanalyzer-exposure-through-uninit-copy + Seven new warnings relating to misuse of file descriptors: + + https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-fd-access-mode-mismatch;>-Wanalyzer-fd-access-mode-mismatch + https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-fd-double-close;>-Wanalyzer-fd-double-close + https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-fd-leak;>-Wanalyzer-fd-leak + https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-fd-phase-mismatch;>-Wanalyzer-fd-phase-mismatch + (e.g. calling accept on a socket before calling + listen on it) + https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-fd-type-mismatch;>-Wanalyzer-fd-type-mismatch + (e.g. using a stream socket operation on a datagram socket) + https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-fd-use-after-close;>-Wanalyzer-fd-use-after-close + https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-fd-use-without-check;>-Wanalyzer-fd-use-without-check + + along with special-casing handling of the behavior of + open, close, creat, + dup, dup2, dup3, + pipe, pipe2, read, + and write. + + https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-imprecise-fp-arithmetic;>-Wanalyzer-imprecise-fp-arithmetic + https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-infinite-recursion;>-Wanalyzer-infinite-recursion + https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-jump-through-null;>-Wanalyzer-jump-through-null + https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-out-of-bounds;>-Wanalyzer-out-of-bounds + https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-putenv-of-auto-var;>-Wanalyzer-putenv-of-auto-var + https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-tainted-assertion;>-Wanalyzer-tainted-assertion + Four new warnings for misuses of stdarg.h: + + https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-va-list-leak;>-Wanalyzer-va-list-leak for complaining about missing va_end after a va_start or va_copy + https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-va-list-use-after-va-end;>-Wanalyzer-va-list-use-after-va-end for complaining about va_arg or va_copy used on a va_list that's had va_end called on it + https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html#index-Wanalyzer-va-arg-type-mismatch;>-Wanalyzer-va-arg-type-mismatch for type-checking of va_arg usage in interprocedural execution paths against the
[pushed, wwwdocs] gcc-13: linkify some options
--- htdocs/gcc-13/changes.html | 29 - 1 file changed, 16 insertions(+), 13 deletions(-) diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html index 9ecd115c..a48ac220 100644 --- a/htdocs/gcc-13/changes.html +++ b/htdocs/gcc-13/changes.html @@ -45,7 +45,8 @@ a work-in-progress. supported, either.) Legacy debug info compression option -gz=zlib-gnu was removed and the option is ignored right now. --Warray-bounds=2 will no longer issue warnings for out of +https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Warray-bounds;>-Warray-bounds=2 + will no longer issue warnings for out of bounds accesses to trailing struct members of one-element array type anymore. Instead it diagnoses accesses to trailing arrays according to -fstrict-flex-arrays. @@ -169,7 +170,7 @@ a work-in-progress. Removal of trigraphs Removal of unprototyped functions printf and scanf format checking - with -Wformat for %wN + with https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wformat;>-Wformat for %wN and %wfN format length modifiers https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2836.pdf;>N2836, Identifier Syntax using Unicode Standard Annex 31 @@ -180,8 +181,8 @@ a work-in-progress. with -std=c2x -Wpedantic. New warnings: - -Wenum-int-mismatch warns about mismatches between an - enumerated type and an integer type + https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wenum-int-mismatch;>-Wenum-int-mismatch +warns about mismatches between an enumerated type and an integer type (https://gcc.gnu.org/PR105131;>PR105131) @@ -232,16 +233,18 @@ a work-in-progress. New warnings: - -Wself-move warns when a value is moved to itself with - std::move - (https://gcc.gnu.org/PR81159;>PR81159) - -Wdangling-reference warns when a reference is bound to - a temporary whose lifetime has ended + https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wself-move;>-Wself-move + warns when a value is moved to itself with std::move + (https://gcc.gnu.org/PR81159;>PR81159) + https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-Wdangling-reference;>-Wdangling-reference + warns when a reference is bound to a temporary whose lifetime + has ended (https://gcc.gnu.org/PR106393;>PR106393) - The -Wpessimizing-move and -Wredundant-move - warnings have been extended to warn in more contexts. + The https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-Wpessimizing-move;>-Wpessimizing-move +and https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-Wredundant-move;>-Wredundant-move +warnings have been extended to warn in more contexts. Runtime Library (libstdc++) @@ -463,8 +466,8 @@ a work-in-progress. flexible array member for the purpose of accessing the elements of such an array. By default, all trailing arrays in aggregates are treated as flexible array members. Use the new command-line option - -fstrict-flex-arrays to control which array members are - treated as flexible arrays. + https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstrict-flex-arrays;>-fstrict-flex-arrays + to control which array members are treated as flexible arrays. -- 2.37.1
Re: [PATCH] cgraph: Handle simd clones in cgraph_node::set_{const,pure}_flag [PR106433]
> On Wed, Feb 08, 2023 at 06:10:08PM +0100, Jan Hubicka wrote: > > My understanding of simd clones is bit limited, but I think you are > > right that they should have the same semantics as their caller. > > > > I think const may be one that makes compiler to ICE, but > > there are many other places where function body is analyzed and all its > > aliases/thunks and other variants should be updated too. For exmaple > > set_pure_flag, nothrow, noreturn and analysis done by modref, > > ipa-refernece etc. > > > > I wonder if we want to update them all and hide that in some > > abstraction? Next stage 1 I can work on inventing iterators for those > > kind of things as current approach combinindg direct walkters and > > function wrappers has become bit hard to maintain in cases like this. > > I think it depends on whether we do that analysis or update it post IPA > or not. Because simd clones are created very late during IPA, if say > the nothrow, noreturn, modref etc. analysis is done only during IPA or > before it, we don't need to walk the simd clones. > It is just for late GIMPLE analysis that changes flags that later on > could be used in callers of those functions. > pure/const flag is what I know can happen this late, what else? We have late pure/const (doing pure, const, nothrow, noreturn), modref (which also discovers pure/const attributes and produces its own summaries) and except.c at the very end of copimlation can set notrow flag... This is all I can think of. Honza > > Jakub >
Re: [PATCH] testsuite: Generalize check_effective_target_lra
> From: Richard Sandiford
> Date: Wed, 8 Feb 2023 17:54:15 +0100
> Hans-Peter Nilsson via Gcc-patches writes:
> > Tested native x86_64-pc-linux-gnu and cris-elf (non-LRA and
> > also hacked to switch to LRA).
>
> Since !LRA is hopefully not long for this world, I'd personally
> prefer to keep it simple & obvious (at least for most targets).
> There's a risk that we could lose testing on most targets through
> an innocuous-looking change to one of LRA's fprintfs.
>
> If this is for -mlra-like options, I think it would be OK to guard the
> new code with a target check. So the patch is OK with the existing
> "return 0" replaced by the new return, and with the istarget list
> extended if necessary, but with the outer structure the same.
If you, like me, are aiming for simple and obvious, why then
complicate what already works "for -mlra-like options" with
a target list?
> That might not do what you want though...
That assessment is correct. I'd rather the test-suite
result be consistent for all targets.
brgds, H-P
PS. thanks for the review though
>
> Thanks,
> Richard
>
> >
> > Ok to commit?
> >
> > --- 8< ---
> > The LRA target list is incomplete. Rather than syncing it with actual
> > LRA targets, better use existing infrastructure and look for a
> > LRA-specific pattern in the reload dump (which has the same name, but
> > completely different contents).
> >
> > * lib/target-supports.exp: Replace target list with looking for
> > a LRA-specific string in the reload dump.
> > ---
> > gcc/testsuite/lib/target-supports.exp | 9 +
> > 1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/gcc/testsuite/lib/target-supports.exp
> > b/gcc/testsuite/lib/target-supports.exp
> > index 227e3004077a..e62b7a2c869d 100644
> > --- a/gcc/testsuite/lib/target-supports.exp
> > +++ b/gcc/testsuite/lib/target-supports.exp
> > @@ -12192,10 +12192,11 @@ proc check_effective_target_o_flag_in_section { }
> > {
> > # return 1 if LRA is supported.
> >
> > proc check_effective_target_lra { } {
> > -if { [istarget hppa*-*-*] } {
> > - return 0
> > -}
> > -return 1
> > +# Iterating over extended basic blocks is new with LRA. Also need
> > +# a context to avoid spuriously matching a register name.
> > +return [check_no_messages_and_pattern lra "EBB 2 3" rtl-reload {
> > + void foo (void) { }
> > +}]
> > }
> >
> > # Test whether optimizations are enabled ('__OPTIMIZE__') per the
>
Re: [PATCH] cgraph: Handle simd clones in cgraph_node::set_{const,pure}_flag [PR106433]
On Wed, Feb 08, 2023 at 06:10:08PM +0100, Jan Hubicka wrote: > My understanding of simd clones is bit limited, but I think you are > right that they should have the same semantics as their caller. > > I think const may be one that makes compiler to ICE, but > there are many other places where function body is analyzed and all its > aliases/thunks and other variants should be updated too. For exmaple > set_pure_flag, nothrow, noreturn and analysis done by modref, > ipa-refernece etc. > > I wonder if we want to update them all and hide that in some > abstraction? Next stage 1 I can work on inventing iterators for those > kind of things as current approach combinindg direct walkters and > function wrappers has become bit hard to maintain in cases like this. I think it depends on whether we do that analysis or update it post IPA or not. Because simd clones are created very late during IPA, if say the nothrow, noreturn, modref etc. analysis is done only during IPA or before it, we don't need to walk the simd clones. It is just for late GIMPLE analysis that changes flags that later on could be used in callers of those functions. pure/const flag is what I know can happen this late, what else? Jakub
Re: [PATCH] cgraph: Handle simd clones in cgraph_node::set_{const,pure}_flag [PR106433]
> Hi!
>
> The following testcase ICEs, because we determine only in late pure const
> pass that bar is const (the content of the function loses a store to a
> global var during dse3 and read from it during cddce2) and local-pure-const2
> makes it const. The cgraph ordering is that post IPA (in late IPA simd
> clones are created) bar is processed first, then foo as its caller, then
> foo.simdclone* and finally bar.simdclone*. Conceptually I think that is the
> right ordering which allows for static simd clones to be removed.
>
> The reason for the ICE is that because bar was marked const, the call to
> it lost vops before vectorization, and when we in foo.simdclone* try to
> vectorize the call to bar, we replace it with bar.simdclone* which hasn't
> been marked const and so needs vops, which we don't add.
>
> Now, because the simd clones are created from the same IL, just in a loop
> with different argument/return value passing, I think generally if the base
> function is determined to be const or pure, the simd clones should be too,
> unless e.g. the vectorization causes different optimization decisions, but
> then still the global memory reads if any shouldn't affect what the function
> does and global memory stores shouldn't be reachable at runtime.
My understanding of simd clones is bit limited, but I think you are
right that they should have the same semantics as their caller.
I think const may be one that makes compiler to ICE, but
there are many other places where function body is analyzed and all its
aliases/thunks and other variants should be updated too. For exmaple
set_pure_flag, nothrow, noreturn and analysis done by modref,
ipa-refernece etc.
I wonder if we want to update them all and hide that in some
abstraction? Next stage 1 I can work on inventing iterators for those
kind of things as current approach combinindg direct walkters and
function wrappers has become bit hard to maintain in cases like this.
Honza
>
> So, the following patch changes set_{const,pure}_flag to mark also simd
> clones.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2023-02-07 Jakub Jelinek
>
> PR tree-optimization/106433
> * cgraph.cc (set_const_flag_1): Recurse on simd clones too.
> (cgraph_node::set_pure_flag): Call set_pure_flag_1 on simd clones too.
>
> * gcc.c-torture/compile/pr106433.c: New test.
>
> --- gcc/cgraph.cc.jj 2023-02-02 10:54:44.327473492 +0100
> +++ gcc/cgraph.cc 2023-02-06 12:28:22.040593063 +0100
> @@ -2764,6 +2764,9 @@ set_const_flag_1 (cgraph_node *node, boo
>if (!set_const || alias->get_availability () > AVAIL_INTERPOSABLE)
> set_const_flag_1 (alias, set_const, looping, changed);
> }
> + for (struct cgraph_node *n = node->simd_clones; n != NULL;
> + n = n->simdclone->next_clone)
> +set_const_flag_1 (n, set_const, looping, changed);
>for (cgraph_edge *e = node->callers; e; e = e->next_caller)
> if (e->caller->thunk
> && (!set_const || e->caller->get_availability () > AVAIL_INTERPOSABLE))
> @@ -2876,6 +2879,9 @@ cgraph_node::set_pure_flag (bool pure, b
> {
>struct set_pure_flag_info info = {pure, looping, false};
>call_for_symbol_thunks_and_aliases (set_pure_flag_1, , !pure, true);
> + for (struct cgraph_node *n = simd_clones; n != NULL;
> + n = n->simdclone->next_clone)
> +set_pure_flag_1 (n, );
>return info.changed;
> }
>
> --- gcc/testsuite/gcc.c-torture/compile/pr106433.c.jj 2023-02-06
> 12:37:26.963748811 +0100
> +++ gcc/testsuite/gcc.c-torture/compile/pr106433.c2023-02-06
> 12:37:06.631041918 +0100
> @@ -0,0 +1,24 @@
> +/* PR tree-optimization/106433 */
> +
> +int m, *p;
> +
> +__attribute__ ((simd)) int
> +bar (int x)
> +{
> + if (x)
> +{
> + if (m < 1)
> +for (m = 0; m < 1; ++m)
> + ++x;
> + p =
> + for (;;)
> +++m;
> +}
> + return 0;
> +}
> +
> +__attribute__ ((simd)) int
> +foo (int x)
> +{
> + return bar (x);
> +}
>
> Jakub
>
Re: [PATCH] ipa-split: Don't split returns_twice functions [PR106923]
> Hi!
>
> As discussed in the PR, returns_twice functions are rare/special beasts
> that need special treatment in the cfg, and inside of their bodies
> we don't know which part actually works the weird returns twice way
> (either in the fork/vfork sense, or in the setjmp) and aren't updating
> ab edges to reflect that.
>
> I think easiest is just to never split these, like we already never
> split noreturn or malloc functions.
I think so too - anyone who puts returns twice function on the hot path
should be punished.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2023-02-07 Jakub Jelinek
>
> PR tree-optimization/106923
> * ipa-split.cc (execute_split_functions): Don't split returns_twice
> functions.
>
> * gcc.dg/pr106923.c: New test.
OK,
Thanks!
Honza
>
> --- gcc/ipa-split.cc.jj 2023-01-02 09:32:22.492283737 +0100
> +++ gcc/ipa-split.cc 2023-02-06 14:15:08.343271251 +0100
> @@ -1715,10 +1715,11 @@ execute_split_functions (void)
>struct cgraph_node *node = cgraph_node::get (current_function_decl);
>
>if (flags_from_decl_or_type (current_function_decl)
> - & (ECF_NORETURN|ECF_MALLOC))
> + & (ECF_NORETURN|ECF_MALLOC|ECF_RETURNS_TWICE))
> {
>if (dump_file)
> - fprintf (dump_file, "Not splitting: noreturn/malloc function.\n");
> + fprintf (dump_file, "Not splitting: noreturn/malloc/returns_twice "
> + "function.\n");
>return 0;
> }
>if (MAIN_NAME_P (DECL_NAME (current_function_decl)))
> --- gcc/testsuite/gcc.dg/pr106923.c.jj2023-02-06 14:19:33.464449400
> +0100
> +++ gcc/testsuite/gcc.dg/pr106923.c 2023-02-06 14:18:25.498429162 +0100
> @@ -0,0 +1,23 @@
> +/* PR tree-optimization/106923 */
> +/* { dg-do compile } */
> +/* { dg-options "-O1 -finline-small-functions -fpartial-inlining --param
> max-inline-insns-single=1 --param uninlined-function-insns=1" } */
> +
> +int n;
> +
> +int
> +baz (void);
> +
> +__attribute__ ((returns_twice)) int
> +bar (void)
> +{
> + if (baz ())
> +++n;
> +
> + return 0;
> +}
> +
> +int
> +foo (void)
> +{
> + return bar ();
> +}
>
> Jakub
>
Re: [PATCH] testsuite: Generalize check_effective_target_lra
Hans-Peter Nilsson via Gcc-patches writes:
> Tested native x86_64-pc-linux-gnu and cris-elf (non-LRA and
> also hacked to switch to LRA).
Since !LRA is hopefully not long for this world, I'd personally
prefer to keep it simple & obvious (at least for most targets).
There's a risk that we could lose testing on most targets through
an innocuous-looking change to one of LRA's fprintfs.
If this is for -mlra-like options, I think it would be OK to guard the
new code with a target check. So the patch is OK with the existing
"return 0" replaced by the new return, and with the istarget list
extended if necessary, but with the outer structure the same.
That might not do what you want though...
Thanks,
Richard
>
> Ok to commit?
>
> --- 8< ---
> The LRA target list is incomplete. Rather than syncing it with actual
> LRA targets, better use existing infrastructure and look for a
> LRA-specific pattern in the reload dump (which has the same name, but
> completely different contents).
>
> * lib/target-supports.exp: Replace target list with looking for
> a LRA-specific string in the reload dump.
> ---
> gcc/testsuite/lib/target-supports.exp | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/gcc/testsuite/lib/target-supports.exp
> b/gcc/testsuite/lib/target-supports.exp
> index 227e3004077a..e62b7a2c869d 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -12192,10 +12192,11 @@ proc check_effective_target_o_flag_in_section { } {
> # return 1 if LRA is supported.
>
> proc check_effective_target_lra { } {
> -if { [istarget hppa*-*-*] } {
> - return 0
> -}
> -return 1
> +# Iterating over extended basic blocks is new with LRA. Also need
> +# a context to avoid spuriously matching a register name.
> +return [check_no_messages_and_pattern lra "EBB 2 3" rtl-reload {
> + void foo (void) { }
> +}]
> }
>
> # Test whether optimizations are enabled ('__OPTIMIZE__') per the
Re: [PATCH] vect-patterns: Fix up vect_widened_op_tree [PR108692]
Jakub Jelinek writes:
> Hi!
>
> The following testcase is miscompiled on aarch64-linux since r11-5160.
> Given
>[local count: 955630225]:
> # i_22 = PHI
> # r_23 = PHI
> ...
> a.0_5 = (unsigned char) a_15;
> _6 = (int) a.0_5;
> b.1_7 = (unsigned char) b_17;
> _8 = (int) b.1_7;
> c_18 = _6 - _8;
> _9 = ABS_EXPR ;
> r_19 = _9 + r_23;
> ...
> where SSA_NAMEs 15/17 have signed char, 5/7 unsigned char and rest is int
> we first pattern recognize c_18 as
> patt_34 = (a.0_5) w- (b.1_7);
> which is still correct, 5/7 are unsigned char subtracted in wider type,
> but then vect_recog_sad_pattern turns it into
> SAD_EXPR
> which is incorrect, because 15/17 are signed char and so it is
> sum of absolute signed differences rather than unsigned sum of
> absolute unsigned differences.
> The reason why this happens is that vect_recog_sad_pattern calls
> vect_widened_op_tree with MINUS_EXPR, WIDEN_MINUS_EXPR on the
> patt_34 = (a.0_5) w- (b.1_7); statement's vinfo and vect_widened_op_tree
> calls vect_look_through_possible_promotion on the operands of the
> WIDEN_MINUS_EXPR, which looks through the further casts.
> vect_look_through_possible_promotion has careful code to stop when there
> would be nested casts that need to be preserved, but the problem here
> is that the WIDEN_*_EXPR operation itself has an implicit cast on the
> operands already - in this case of WIDEN_MINUS_EXPR the unsigned char
> 5/7 SSA_NAMEs are widened to unsigned short before the subtraction,
> and vect_look_through_possible_promotion obviously isn't told about that.
>
> Now, I think when we see those WIDEN_{MULT,MINUS,PLUS}_EXPR codes, we had
> to look through possible promotions already when creating those and so
> vect_look_through_possible_promotion again isn't really needed, all we need
> to do is arrange what that function will do if the operand isn't result
> of any cast. Other option would be let vect_look_through_possible_promotion
> know about the implicit promotion from the WIDEN_*_EXPR, but I'm afraid
> that would be much harder.
>
> Bootstrapped/regtested on aarch64-linux, x86_64-linux, i686-linux and
> powerpc64le-linux, ok for trunk?
>
> 2023-02-08 Jakub Jelinek
>
> PR tree-optimization/108692
> * tree-vect-patterns.cc (vect_widened_op_tree): If rhs_code is
> widened_code which is different from code, don't call
> vect_look_through_possible_promotion but instead just check op is
> SSA_NAME with integral type for which vect_is_simple_use is true
> and call set_op on this_unprom.
OK, thanks.
(I think the INTEGRAL_TYPE_P is redundant, but it can't hurt.)
Richard
>
> * gcc.dg/pr108692.c: New test.
>
> --- gcc/tree-vect-patterns.cc.jj 2023-01-02 09:32:45.635949342 +0100
> +++ gcc/tree-vect-patterns.cc 2023-02-07 15:27:33.214608837 +0100
> @@ -601,7 +601,25 @@ vect_widened_op_tree (vec_info *vinfo, s
> if (shift_p && i == 1)
> return 0;
>
> - if (!vect_look_through_possible_promotion (vinfo, op, this_unprom))
> + if (rhs_code != code)
> + {
> + /* If rhs_code is widened_code, don't look through further
> + possible promotions, there is a promotion already embedded
> + in the WIDEN_*_EXPR. */
> + if (TREE_CODE (op) != SSA_NAME
> + || !INTEGRAL_TYPE_P (TREE_TYPE (op)))
> + return 0;
> +
> + stmt_vec_info def_stmt_info;
> + gimple *def_stmt;
> + vect_def_type dt;
> + if (!vect_is_simple_use (op, vinfo, , _stmt_info,
> +_stmt))
> + return 0;
> + this_unprom->set_op (op, dt, NULL);
> + }
> + else if (!vect_look_through_possible_promotion (vinfo, op,
> + this_unprom))
> return 0;
>
> if (TYPE_PRECISION (this_unprom->type) == TYPE_PRECISION (type))
> --- gcc/testsuite/gcc.dg/pr108692.c.jj2023-02-07 15:47:20.329076264
> +0100
> +++ gcc/testsuite/gcc.dg/pr108692.c 2023-02-07 15:46:15.623031983 +0100
> @@ -0,0 +1,31 @@
> +/* PR tree-optimization/108692 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -ftree-vectorize" } */
> +
> +__attribute__((noipa)) int
> +foo (signed char *x, signed char *y, int n)
> +{
> + int i, r = 0;
> + signed char a, b;
> + for (i = 0; i < n; i++)
> +{
> + a = x[i];
> + b = y[i];
> + int c = (unsigned char) a - (unsigned char) b;
> + r = r + (c < 0 ? -c : c);
> +}
> + return r;
> +}
> +
> +int
> +main ()
> +{
> + signed char x[64] = {}, y[64] = {};
> + if (__CHAR_BIT__ != 8 || __SIZEOF_INT__ != 4)
> +return 0;
> + x[32] = -128;
> + y[32] = 1;
> + if (foo (x, y, 64) != 127)
> +__builtin_abort ();
> + return 0;
> +}
>
> Jakub
Re: [V2][PATCH] Handle component_ref to a structre/union field including flexible array member [PR101832]
I found a bug with this patch, will fix it and send out the updated patch.
Please ignore this one.
sorry.
Qing
> On Feb 6, 2023, at 8:47 AM, Qing Zhao wrote:
>
> This is the 2nd version of the patch, compare to the first version, the major
> changes are:
>
> 1. Add a new IR bit in tree_type_common: type_include_flexarray, set this bit
> in FE for struct/union types that include a flexible array member (per
> -fstrict-flex-arrays) at the end.
> 2. Check this new bit in tree-objec-size.cc to decide whether a component_ref
> to a struct/union has flexible size or not.
> 3. Update the testing case per Seddhish's previous change.
>
> Bootstrapped and regression tested on both X86 and aarch64, no issue.
>
> Okay for commit?
>
> thanks.
>
> Qing.
>
>
> GCC extension accepts the case when a struct with a flexible array member
> is embedded into another struct or union (possibly recursively).
> __builtin_object_size should treat such struct as flexible size per
> -fstrict-flex-arrays.
>
> gcc/c/ChangeLog:
>
> PR tree-optimization/101832
> * c-decl.cc (finish_struct): Set TYPE_INCLUDE_FLEXARRAY for
> struct/union type.
>
> gcc/ChangeLog:
>
> PR tree-optimization/101832
> * tree-core.h (struct tree_type_common): New bit
> type_include_flexarray.
> * tree-object-size.cc (addr_object_size): Handle structure/union type
> when it has flexible size.
> * tree.h (TYPE_INCLUDE_FLEXARRAY): New macro
> TYPE_INCLUDE_FLEXARRAY.
>
> gcc/testsuite/ChangeLog:
>
> PR tree-optimization/101832
> * gcc.dg/builtin-object-size-pr101832-2.c: New test.
> * gcc.dg/builtin-object-size-pr101832-3.c: New test.
> * gcc.dg/builtin-object-size-pr101832-4.c: New test.
> * gcc.dg/builtin-object-size-pr101832-5.c: New test.
> * gcc.dg/builtin-object-size-pr101832.c: New test.
> ---
> gcc/c/c-decl.cc | 11 ++
> .../gcc.dg/builtin-object-size-pr101832-2.c | 132 ++
> .../gcc.dg/builtin-object-size-pr101832-3.c | 132 ++
> .../gcc.dg/builtin-object-size-pr101832-4.c | 132 ++
> .../gcc.dg/builtin-object-size-pr101832-5.c | 120
> .../gcc.dg/builtin-object-size-pr101832.c | 115 +++
> gcc/tree-core.h | 4 +-
> gcc/tree-object-size.cc | 79 +++
> gcc/tree.h| 6 +
> 9 files changed, 702 insertions(+), 29 deletions(-)
> create mode 100644 gcc/testsuite/gcc.dg/builtin-object-size-pr101832-2.c
> create mode 100644 gcc/testsuite/gcc.dg/builtin-object-size-pr101832-3.c
> create mode 100644 gcc/testsuite/gcc.dg/builtin-object-size-pr101832-4.c
> create mode 100644 gcc/testsuite/gcc.dg/builtin-object-size-pr101832-5.c
> create mode 100644 gcc/testsuite/gcc.dg/builtin-object-size-pr101832.c
>
> diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
> index 20e7d1855bf..52fef7d84fa 100644
> --- a/gcc/c/c-decl.cc
> +++ b/gcc/c/c-decl.cc
> @@ -9277,6 +9277,17 @@ finish_struct (location_t loc, tree t, tree fieldlist,
> tree attributes,
> /* Set DECL_NOT_FLEXARRAY flag for FIELD_DECL x. */
> DECL_NOT_FLEXARRAY (x) = !is_flexible_array_member_p (is_last_field, x);
>
> + /* Set TYPE_INCLUDE_FLEXARRAY for the context of x,
> + i.e., the RECORD_TYPE of UNION_TYPE, t. */
> + TYPE_INCLUDE_FLEXARRAY (t) = !DECL_NOT_FLEXARRAY (x);
> +
> + /* Recursively set TYPE_INCLUDE_FLEXARRAY for the context of x, t
> + when x is the last field. */
> + if ((TREE_TYPE (x) != error_mark_node)
> +&& TYPE_INCLUDE_FLEXARRAY (TREE_TYPE (x))
> +&& is_last_field)
> + TYPE_INCLUDE_FLEXARRAY (t) = true;
> +
> if (DECL_NAME (x)
> || RECORD_OR_UNION_TYPE_P (TREE_TYPE (x)))
> saw_named_field = true;
> diff --git a/gcc/testsuite/gcc.dg/builtin-object-size-pr101832-2.c
> b/gcc/testsuite/gcc.dg/builtin-object-size-pr101832-2.c
> new file mode 100644
> index 000..af9769d73e0
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/builtin-object-size-pr101832-2.c
> @@ -0,0 +1,132 @@
> +/* PR 101832:
> + GCC extension accepts the case when a struct with a flexible array member
> + is embedded into another struct (possibly recursively).
> + __builtin_object_size will treat such struct as flexible size per
> + -fstrict-flex-arrays. */
> +/* { dg-do run } */
> +/* { dg-options "-O2 -fstrict-flex-arrays=1" } */
> +
> +#include "builtin-object-size-common.h"
> +
> +#define expect(p, _v) do { \
> + size_t v = _v; \
> + if (p == v) \
> +__builtin_printf ("ok: %s == %zd\n", #p, p); \
> + else {\
> +__builtin_printf ("WAT: %s == %zd (expected %zd)\n", #p, p, v); \
> +FAIL (); \
> + } \
> +} while (0);
> +
> +
> +struct A {
> + int n;
> + char data[];
> +};
> +
> +struct B {
> + int m;
> + struct A a;
> +};
> +
> +struct C {
> + int q;
> +
Re: [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]
> On Feb 7, 2023, at 6:37 PM, Joseph Myers wrote:
>
> On Tue, 7 Feb 2023, Qing Zhao via Gcc-patches wrote:
>
>> Then, this routine (flexible_array_type_p) is mainly for diagnostic purpose.
>> It cannot be used to determine whether the structure/union type recursively
>> include a flexible array member at the end.
>>
>> Is my understanding correct?
>
> My comments were about basic principles of what gets diagnosed, and the
> need for different predicates in different contexts; I wasn't trying to
> assert anything about how that maps onto what functions should be used in
> what contexts.
Okay.
But I noticed that “flexible_array_type_p” later was moved from FE to
middle-end and put into tree.cc, tree.h as a general utility routine, and to
/* Determine whether TYPE is a structure with a flexible array member,
or a union containing such a structure (possibly recursively). */
However, since this routine does not cover the cases when the structure
with flexible array member was recursively embedded into structures, (which we
agreed that it should be considered as a flexible sized type).
Therefore, I feel that It might not be proper to include this routine in middle
end
(and actually no other places In middle end use this routine so far).
That’s the reason I asked the previous question.
It might be better to move the routine “flexible_array_type_p” back from
middle-end to
FE for the diagnosis purpose only.
>
2. Only C99 standard flexible array member be included, [0] and [1] are
not included, for example:
>>>
>>> Obviously we can't diagnose use of structures with [1] trailing members,
>>> because it's perfectly valid to embed those structures at any position
>>> inside other structures. And the same is the case for the [0] extension
>>> when it's used to mean "empty array" rather than "flexible array".
>>
>> With the -fstrict-flex-arrays available, we should be able to diagnose
>> the flexible array member per gnu extension (i.e [0] or [1]) the same as [].
>
> There are different sorts of diagnostic that might be involved.
>
> * Simply having [0] or [1] at the end of a structure embedded in another
> structure isn't appropriate to diagnose, because [0] and [1] have
> perfectly good meanings in such a context that aren't trying to be
> flexible array members at all. [0] might be an empty type (possibly one
> that wouldn't be empty when built with a different configuration). [1]
> might be the use of arrays in C to produce a passed-by-reference type.
So, you mean, by default, Only having [] at the end of a structure embedded
in another structure is considered to be flexible sized type?
i.e.
struct flex { int n; int data[ ]; };
struct out_flex_end { int m; struct flex0 flex_data; };
struct outer_flex_end{ int p; struct out_flex_end0 out_flex_data; };
In the above, all “flex”, “out_flex_end” and “outer_flex_end” are flexible
sized type.
But:
struct flex0 { int n; int data[0]; };
struct out_flex_end0 { int m; struct flex0 flex_data; };
struct outer_flex_end0 { int p; struct out_flex_end0 out_flex_data; };
In the above, only “flex0” is flexible sized type by default.
But “out_flex_end0” and “out_flex_end0” are Not considered as flexible sized
type by default?
>
> * Trying to use such an embedded [0] or [1] array as if it were a flexible
> array member - i.e. accessing any member of the [0] array, or any member
> other than the [0] member of the [1] array - *is* a sign of the
> problematic use as a flexible array member, that might be appropriate to
> diagnose.
Yes, this was diagnosed with -Wstrict-flex-arrays + -fstrict-flex-arrays=n.
thanks.
Qing
> (Actually I'd guess the array index tends to be non-constant in
> accesses, and it would be odd to use a non-constant index when you mean
> that constant always to be 0, which it would need to be in the
> non-flexible case.)
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
Re: [PATCH] arm: Implement arm Function target attribute 'branch-protection'
Andrea Corallo writes:
> gcc/
>
> * config/arm/arm.cc (arm_valid_target_attribute_rec): Add ARM function
> attribute 'branch-protection' and parse its options.
> * doc/extend.texi: Document ARM Function attribute 'branch-protection'.
>
> gcc/testsuite/
>
> * gcc.target/arm/acle/pacbti-m-predef-13.c: New test.
>
> Co-Authored-By: Tejas Belagod
> ---
> gcc/config/arm/arm.cc | 16
> gcc/doc/extend.texi | 7
> .../gcc.target/arm/acle/pacbti-m-predef-13.c | 41 +++
> 3 files changed, 64 insertions(+)
> create mode 100644 gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-13.c
>
> diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
> index efc48349dd3..add33090f18 100644
> --- a/gcc/config/arm/arm.cc
> +++ b/gcc/config/arm/arm.cc
> @@ -33568,6 +33568,22 @@ arm_valid_target_attribute_rec (tree args, struct
> gcc_options *opts)
>
> opts->x_arm_arch_string = xstrndup (arch, strlen (arch));
> }
> + else if (startswith (q, "branch-protection="))
> + {
> + char *bp_str = q + strlen ("branch-protection=");
> +
> + opts->x_arm_branch_protection_string
> + = xstrndup (bp_str, strlen (bp_str));
> +
> + /* Capture values from target attribute. */
> + aarch_validate_mbranch_protection
> + (opts->x_arm_branch_protection_string);
> +
> + /* Init function target attr values. */
> + opts->x_aarch_ra_sign_scope = aarch_ra_sign_scope;
> + opts->x_aarch_enable_bti = aarch_enable_bti;
> +
> + }
>else if (q[0] == '+')
> {
> opts->x_arm_arch_string
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index 4a89a3eae7c..23ee43919dd 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -4492,6 +4492,13 @@ Enable or disable calls to out-of-line helpers to
> implement atomic operations.
> This corresponds to the behavior of the command line options
> @option{-moutline-atomics} and @option{-mno-outline-atomics}.
>
> +@item branch-protection=
> +@cindex @code{branch-protection=} function attribute, arm
> +Select the function scope on which branch protection will be applied.
> +The behavior and permissible arguments are the same as for the
> +command-line option @option{-mbranch-protection=}. The default value
> +is @code{none}.
> +
> @end table
>
> The above target attributes can be specified as follows:
> diff --git a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-13.c
> b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-13.c
> new file mode 100644
> index 000..b6d2df53072
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-13.c
> @@ -0,0 +1,41 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target mbranch_protection_ok } */
> +/* { dg-options "-march=armv8.1-m.main+fp -mbranch-protection=pac-ret+leaf
> -mfloat-abi=hard --save-temps" } */
> +/* { dg-final { check-function-bodies "**" "" } } */
> +
> +#if defined (__ARM_FEATURE_BTI_DEFAULT)
> +#error "Feature test macro __ARM_FEATURE_BTI_DEFAULT should be undefined."
> +#endif
> +
> +#if !defined (__ARM_FEATURE_PAC_DEFAULT)
> +#error "Feature test macro __ARM_FEATURE_PAC_DEFAULT should be defined."
> +#endif
> +
> +/*
> +**foo:
> +** bti
> +** ...
> +*/
> +__attribute__((target("branch-protection=pac-ret+bti"), noinline))
> +int foo ()
> +{
> + return 3;
> +}
> +
> +/*
> +**main:
> +** pac ip, lr, sp
> +** ...
> +** aut ip, lr, sp
> +** bx lr
> +*/
> +int
> +main()
> +{
> + return 1 + foo ();
> +}
> +
> +/* { dg-final { scan-assembler "\.eabi_attribute 50, 1" } } */
> +/* { dg-final { scan-assembler "\.eabi_attribute 52, 1" } } */
> +/* { dg-final { scan-assembler-not "\.eabi_attribute 74" } } */
> +/* { dg-final { scan-assembler "\.eabi_attribute 76, 1" } } */
Ping
Andrea
Re: [PATCH] aarch64: Fix return_address_sign_ab_exception.C regression
Richard Sandiford writes: > Andrea Corallo via Gcc-patches writes: >> Hi all, >> >> this is to fix the regression of >> g++.target/aarch64/return_address_sign_ab_exception.C that I >> introduced with d8dadbc9a5199bf7bac1ab7376b0f84f45e94350. >> >> 'aarch_ra_sign_key' for aarch64 ended up being non defined in the opt >> file and the function attribute "branch-protection=pac-ret+leaf+b-key" >> stopped working as expected. >> >> This patch moves the definition of 'aarch_ra_sign_key' to the opt >> files for both Arm back-ends. >> >> Regards >> >> Andera Corallo >> >> gcc/ChangeLog: >> >> * config/aarch64/aarch64-protos.h (aarch_ra_sign_key): Remove >> declaration. >> * config/aarch64/aarch64.cc (aarch_ra_sign_key): Remove >> definition. >> * config/aarch64/aarch64.opt (aarch64_ra_sign_key): Rename >> to 'aarch_ra_sign_key'. >> * config/arm/aarch-common.cc (aarch_ra_sign_key): Remove >> declaration. >> * config/arm/arm-protos.h (aarch_ra_sign_key): Likewise. >> * config/arm/arm.cc (enum aarch_key_type): Remove definition. >> * config/arm/arm.opt: Define. > > OK, thanks. > > Richard Thanks for reviewing, in as b1d26458839. Best Regards Andrea
[pushed] testsuite: Import objc-dg-prune in execute.exp
The GCC-local definition of gcc-dg-prune removes extra error messages,
such as one from the linker warning about executable stacks. This is
then used by tool-specific pruners like objc-dg-prune, defined in
objc-dg.exp. However, objc/execute/execute.exp didn't include
objc-dg.exp, meaning that the linker warning could trigger a
failure in objc/execute/nested-func-1.m.
Tested on aarch64-linux-gnu & x86_64-linux-gnu, pushed as obvious.
Richard
gcc/testsuite/
* objc/execute/execute.exp: Load objc-dg.exp.
---
gcc/testsuite/objc/execute/execute.exp | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/objc/execute/execute.exp
b/gcc/testsuite/objc/execute/execute.exp
index 407b14a91d5..9724c32019e 100644
--- a/gcc/testsuite/objc/execute/execute.exp
+++ b/gcc/testsuite/objc/execute/execute.exp
@@ -23,6 +23,7 @@ if $tracelevel then {
}
# load support procs
+load_lib objc-dg.exp
load_lib objc-torture.exp
load_lib torture-options.exp
--
2.25.1
Re: [pushed] [PR103541] RA: Implement reuse of equivalent memory for caller saves optimization
On 2/7/23 22:48, Andrew Pinski wrote: On Tue, Feb 7, 2023 at 6:08 AM Vladimir Makarov via Gcc-patches wrote: The following patch solves https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103541 The patch was successfully bootstrapped and tested on x86-64, aarch64, and ppc64le. What languages did you test? Because I think I am getting a bootstrap failure while building libgo in 32bit x86 due to this patch. I used c and c++ only. Sorry for all the troubles with the patch. I've just reverted the patch and I will try to resolve the issue with it.
[committed] testsuite: Fix up PR108525 test [PR108525]
Hi!
Seems when committing the PR108525 fix I've missed that a test with
the same name had been added a few hours before for PR108526.
This patch separates the PR108525 test into a new file.
Tested on x86_64-linux, committed to trunk as obvious.
2023-02-08 Jakub Jelinek
PR c++/108525
* g++.dg/cpp23/static-operator-call5.C: Move PR108525 testcase
incorrectly applied into PR108526 testcase ...
* g++.dg/cpp23/static-operator-call6.C: ... here. New test.
--- gcc/testsuite/g++.dg/cpp23/static-operator-call5.C.jj 2023-01-25
15:13:23.653643155 +0100
+++ gcc/testsuite/g++.dg/cpp23/static-operator-call5.C 2023-02-08
13:52:17.273674484 +0100
@@ -1,8 +1,3 @@
-// PR c++/108525
-// { dg-do compile { target c++23 } }
-
-auto b = [](...) static { return 1; };
-auto foo () { return b (); }
// PR c++/108526
// { dg-do compile { target c++23 } }
--- gcc/testsuite/g++.dg/cpp23/static-operator-call6.C.jj 2023-02-08
13:51:53.856022995 +0100
+++ gcc/testsuite/g++.dg/cpp23/static-operator-call6.C 2023-02-08
13:52:06.831829883 +0100
@@ -0,0 +1,5 @@
+// PR c++/108525
+// { dg-do compile { target c++23 } }
+
+auto b = [](...) static { return 1; };
+auto foo () { return b (); }
Jakub
[PATCH] gimplify size expressions in parameters for all types [PR107557] [PR108423]
Here is a fix for PR107557 and PR108423.
Bootstrapped and regression tested on x86-64.
Gimplify more size expression in parameters [PR107557] and [PR108234]
gimplify_parm_type only recursives into pointer type and
size expressions in other types (e.g. function types) were
not reached.
PR c/107557
PR c/108234
gcc/Changelog
* gcc/function.cc (gimplify_parm_type): Also recursive into
non-pointer types.
gcc/testsuite/ChangeLog:
* gcc.dg/pr107557-1.c: New test.
* gcc.dg/pr107557-2.c: New test.
* gcc.dg/pr108423-1.c: New test.
* gcc.dg/pr108423-2.c: New test.
* gcc.dg/pr108423-3.c: New test.
* gcc.dg/pr108423-4.c: New test.
* gcc.dg/pr108423-5.c: New test.
diff --git a/gcc/function.cc b/gcc/function.cc
index cfc4d2f74af..d777348aeb4 100644
--- a/gcc/function.cc
+++ b/gcc/function.cc
@@ -3880,20 +3880,15 @@ static tree
gimplify_parm_type (tree *tp, int *walk_subtrees, void *data)
{
tree t = *tp;
-
*walk_subtrees = 0;
if (TYPE_P (t))
{
- if (POINTER_TYPE_P (t))
- *walk_subtrees = 1;
- else if (TYPE_SIZE (t) && !TREE_CONSTANT (TYPE_SIZE (t))
+ if (TYPE_SIZE (t) && !TREE_CONSTANT (TYPE_SIZE (t))
&& !TYPE_SIZES_GIMPLIFIED (t))
- {
- gimplify_type_sizes (t, (gimple_seq *) data);
- *walk_subtrees = 1;
- }
-}
+ gimplify_type_sizes (t, (gimple_seq *) data);
+ *walk_subtrees = 1;
+}
return NULL;
}
diff --git a/gcc/testsuite/gcc.dg/pr107557-1.c
b/gcc/testsuite/gcc.dg/pr107557-1.c
new file mode 100644
index 000..88c248b6564
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr107557-1.c
@@ -0,0 +1,24 @@
+/* PR107557
+ * { dg-do compile }
+ * { dg-options "-flto -fsanitize=undefined -fexceptions
-Wno-incompatible-pointer-types" }
+ */
+
+
+int c[1][3*2];
+int f(int * const m, int (**v)[*m * 2])
+{
+ return &(c[0][*m]) == &((*v)[0][*m]);
+}
+int test(int n, int (*(*fn)(void))[n])
+{
+ return (*fn())[0];
+}
+int main()
+{
+ int m = 3;
+ int (*d)[3*2] = c;
+ int (*fn[m])(void);
+ return f(, ) + test(m, );
+}
+
+
diff --git a/gcc/testsuite/gcc.dg/pr107557-2.c
b/gcc/testsuite/gcc.dg/pr107557-2.c
new file mode 100644
index 000..2d26bb0b16a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr107557-2.c
@@ -0,0 +1,23 @@
+/* PR107557
+ * { dg-do compile }
+ * { dg-options "-flto -fsanitize=undefined -fexceptions
-Wno-incompatible-pointer-types" }
+ */
+
+
+int c[1][3*2];
+int f(int * const m, int (**(*v))[*m * 2])
+{
+ return &(c[0][*m]) == &((*v)[0][*m]); /* { dg-warning "lacks a cast"
} */
+}
+int test(int n, int (*(*(*fn))(void))[n])
+{
+ return (*(*fn)())[0];
+}
+int main()
+{
+ int m = 3;
+ int (*d)[3*2] = c;
+ int (*fn[m])(void);
+ return f(, ) + test(m, );
+}
+
diff --git a/gcc/testsuite/gcc.dg/pr108423-1.c
b/gcc/testsuite/gcc.dg/pr108423-1.c
new file mode 100644
index 000..0c98d1d46b9
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr108423-1.c
@@ -0,0 +1,16 @@
+/* PR108423
+ * { dg-do compile }
+ * { dg-options "-O2 -Wno-int-conversion -Wno-incompatible-pointer-types" }
+ */
+int f (int n, int (**(*a)(void))[n])
+{
+ return (*a())[0];
+}
+int g ()
+{
+ int m = 3;
+ int (*a[m])(void);
+ return f(m, );
+}
+
+
diff --git a/gcc/testsuite/gcc.dg/pr108423-2.c
b/gcc/testsuite/gcc.dg/pr108423-2.c
new file mode 100644
index 000..006e45a9629
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr108423-2.c
@@ -0,0 +1,16 @@
+/* PR108423
+ * { dg-do compile }
+ * { dg-options "-O2" }
+ */
+
+void f(int n, int (*a(void))[n])
+{
+ (a())[0];
+}
+
+void g(void)
+{
+ int (*a(void))[1];
+ f(1, a);
+}
+
diff --git a/gcc/testsuite/gcc.dg/pr108423-3.c
b/gcc/testsuite/gcc.dg/pr108423-3.c
new file mode 100644
index 000..c1987c42b40
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr108423-3.c
@@ -0,0 +1,17 @@
+/* PR108423
+ * { dg-do compile }
+ * { dg-options "-O2" }
+ */
+
+void f(int n, int (*(*b)(void))[n])
+{
+sizeof (*(*b)());
+}
+
+int (*a(void))[1];
+
+void g(void)
+{
+ f(1, );
+}
+
diff --git a/gcc/testsuite/gcc.dg/pr108423-4.c
b/gcc/testsuite/gcc.dg/pr108423-4.c
new file mode 100644
index 000..91336f3f283
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr108423-4.c
@@ -0,0 +1,17 @@
+/* PR108423
+ * { dg-do compile }
+ * { dg-options "-O2" }
+ */
+
+void f(int n, int (*a(void))[n])
+{
+sizeof (*a());
+}
+
+int (*a(void))[1];
+
+void g(void)
+{
+ f(1, a);
+}
+
diff --git a/gcc/testsuite/gcc.dg/pr108423-5.c
b/gcc/testsuite/gcc.dg/pr108423-5.c
new file mode 100644
index 000..7e4fffb2870
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr108423-5.c
@@ -0,0 +1,17 @@
+/* PR108423
+ * { dg-do compile }
+ * { dg-options "-O2" }
+ */
+
+void f(int n, int (*(*a)(void))[n])
+{
+sizeof ((*a)());
+}
+
+int (*a(void))[1];
+
Re: [PATCH] ada: Fix musl build on Linux
> The commit "ada: Add PIE support to backtraces on Linux" [1] use > _r_debug under Linux unconditionally. It is incorrect since musl[2] > libc not defined _r_debug like glibc [3]: > > extern struct r_debug _r_debug; > > As far as I know, only glibc and uClibc [4] define the global variable > _r_debug. > > > [1] > https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=f2b30a724e6bf7ff8e591b176967d596cee7648e;hp=83e8d37fe39d7c1afce19b61bbc2dd828fa37c6f > [2] https://git.musl-libc.org/cgit/musl/tree/include/link.h#n39 > [3] > https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/link.h;h=3b5954d9818e8ea9f35638c55961f861f6ae6057;hb=HEAD#l66 > [4] https://git.uclibc.org/uClibc/tree/include/link.h#n71 > > OK? Bootstrapped and tested on aarch64-linux-(gnu|musl), > riscv64-linux-(gnu|musl) and x86_64-linux-(gnu|musl) with no regressions. OK, thanks, > gcc/ada/ > > * adaint.c [Linux]: Include . > (__gnat_get_executable_load_address) [Linux]: Enable only for glibc & uClibc > on Linux.
Re: [PATCH] tree.def: Remove outdated comment on SAD_EXPR
> Am 08.02.2023 um 10:17 schrieb Jakub Jelinek via Gcc-patches > : > > Hi! > > While looking at PR108692, I've noticed SAD_EXPR comment mentions that > WIDEN_MINUS_EXPR is missing, which is not true anymore since r11-5160. > > The following patch just removes that part of the comment. > > Ok for trunk? Ok Richard > > 2023-02-08 Jakub Jelinek > >* tree.def (SAD_EXPR): Remove outdated comment about missing >WIDEN_MINUS_EXPR. > > --- gcc/tree.def.jj2023-01-02 09:32:28.118202450 +0100 > +++ gcc/tree.def2023-02-08 10:05:52.795587292 +0100 > @@ -1341,8 +1341,7 @@ DEFTREECODE (WIDEN_SUM_EXPR, "widen_sum_ >The first two arguments are of type t1 which should be integer. >The third argument and the result are of type t2, such that t2 is at least >twice the size of t1. Like DOT_PROD_EXPR, SAD_EXPR (arg1,arg2,arg3) is > - equivalent to (note we don't have WIDEN_MINUS_EXPR now, but we assume its > - behavior is similar to WIDEN_SUM_EXPR): > + equivalent to: >tmp = WIDEN_MINUS_EXPR (arg1, arg2) >tmp2 = ABS_EXPR (tmp) >arg3 = PLUS_EXPR (tmp2, arg3) > >Jakub >
Re: [PATCH] vect: Check gather/scatter offset types [PR108316]
> Am 08.02.2023 um 10:00 schrieb Richard Sandiford via Gcc-patches
> :
>
> The gather/scatter support can over-widen an offset if the target
> requires it, but this relies on using a pattern sequence to add
> the widening conversion. That failed in the testcase because an
> earlier pattern (bool) took priority.
>
> I think we should allow patterns to be applied to other patterns,
> but that's quite an invasive change and isn't suitable for stage 4.
> This patch instead punts if the offset type doesn't match the
> expected one.
>
> If we switched to using the SLP representation for everything,
> we would probably handle both patterns by rewriting the graph,
> which should be much easier.
>
> Tested on aarch64-linux-gnu & x86_64-linux-gnu. OK to install?
Ok.
Richard
> Richard
>
>
> gcc/
>PR tree-optimization/108316
>* tree-vect-stmts.cc (get_load_store_type): When using
>internal functions for gather/scatter, make sure that the type
>of the offset argument is consistent with the offset vector type.
>
> gcc/testsuite/
>PR tree-optimization/108316
>* gcc.dg/vect/pr108316.c: New test.
> ---
> gcc/testsuite/gcc.dg/vect/pr108316.c | 11 +++
> gcc/tree-vect-stmts.cc | 17 +
> 2 files changed, 28 insertions(+)
> create mode 100644 gcc/testsuite/gcc.dg/vect/pr108316.c
>
> diff --git a/gcc/testsuite/gcc.dg/vect/pr108316.c
> b/gcc/testsuite/gcc.dg/vect/pr108316.c
> new file mode 100644
> index 000..540b7f2aed4
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/vect/pr108316.c
> @@ -0,0 +1,11 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O3" } */
> +
> +extern _Bool a[];
> +
> +void
> +foo (short i, int b[][64][1])
> +{
> + for (; i < 64; i += 4)
> +a[i] = b[0][i] != 0;
> +}
> diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
> index eb4ca1f184e..c86249adcc3 100644
> --- a/gcc/tree-vect-stmts.cc
> +++ b/gcc/tree-vect-stmts.cc
> @@ -2474,6 +2474,23 @@ get_load_store_type (vec_info *vinfo, stmt_vec_info
> stmt_info,
> *memory_access_type = VMAT_GATHER_SCATTER;
> if (!vect_check_gather_scatter (stmt_info, loop_vinfo, gs_info))
>gcc_unreachable ();
> + /* When using internal functions, we rely on pattern recognition
> + to convert the type of the offset to the type that the target
> + requires, with the result being a call to an internal function.
> + If that failed for some reason (e.g. because another pattern
> + took priority), just handle cases in which the offset already
> + has the right type. */
> + else if (gs_info->ifn != IFN_LAST
> + && !is_gimple_call (stmt_info->stmt)
> + && !tree_nop_conversion_p (TREE_TYPE (gs_info->offset),
> + TREE_TYPE (gs_info->offset_vectype)))
> +{
> + if (dump_enabled_p ())
> +dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
> + "%s offset requires a conversion\n",
> + vls_type == VLS_LOAD ? "gather" : "scatter");
> + return false;
> +}
> else if (!vect_is_simple_use (gs_info->offset, vinfo,
>_info->offset_dt,
>_info->offset_vectype))
> --
> 2.25.1
>
[PATCH] RISC-V: Fix indent
From: Ju-Zhe Zhong gcc/ChangeLog: * config/riscv/vector.md: Fix indent. --- gcc/config/riscv/vector.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md index aaac32efcce..7da95013156 100644 --- a/gcc/config/riscv/vector.md +++ b/gcc/config/riscv/vector.md @@ -765,7 +765,7 @@ "@ vlm.v\t%0,%3 vsm.v\t%3,%0 -# + # vmclr.m\t%0 vmset.m\t%0" "&& register_operand (operands[0], mode) -- 2.36.3
Re: [PATCH][GCC] arm: Optimize arm-mlib.h header inclusion (pr108505).
On 27/01/2023 17:44, Srinath Parvathaneni via Gcc-patches wrote:
Hello,
I have committed a fix [1] into gcc trunk for a build issue mentioned in
pr108505 and
latter received few upstream comments proposing more robust fix for this issue.
In this patch I'm addressing those comments and sending this as a followup
patch.
Regression tested on arm-none-eabi target and found no regressions.
Ok for master?
OK. But please correct the syntax for the PR in the subject. It should
be "[PR...]" not "(PR...)".
R.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610513.html
Regards,
Srinath.
gcc/ChangeLog:
2023-01-27 Srinath Parvathaneni
PR target/108505
* config.gcc (tm_mlib_file): Define new variable.
### Attachment also inlined for ease of reply###
diff --git a/gcc/config.gcc b/gcc/config.gcc
index
89f56047cfe3126bc6c8e90c8b4840dea13538f9..2aab92bbfd8b4088259ebf9b565af8e8bbef1122
100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -4355,6 +4355,7 @@ case "${target}" in
case ${arm_multilib} in
aprofile|rmprofile)
tmake_profile_file="arm/t-multilib"
+ tm_mlib_file="arm/arm-mlib.h"
;;
@*)
ml=`echo "X$arm_multilib" | sed
'1s,^X@,,'`
@@ -4393,7 +4394,7 @@ case "${target}" in
# through to the multilib selector
with_float="soft"
tmake_file="${tmake_file} ${tmake_profile_file}"
- tm_file="$tm_file arm/arm-mlib.h"
+ tm_file="$tm_file $tm_mlib_file"
TM_MULTILIB_CONFIG="$with_multilib_list"
fi
fi
[PATCH] ada: Fix musl build on Linux
The commit "ada: Add PIE support to backtraces on Linux" [1] use _r_debug under Linux unconditionally. It is incorrect since musl[2] libc not defined _r_debug like glibc [3]: extern struct r_debug _r_debug; As far as I know, only glibc and uClibc [4] define the global variable _r_debug. [1] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=f2b30a724e6bf7ff8e591b176967d596cee7648e;hp=83e8d37fe39d7c1afce19b61bbc2dd828fa37c6f [2] https://git.musl-libc.org/cgit/musl/tree/include/link.h#n39 [3] https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/link.h;h=3b5954d9818e8ea9f35638c55961f861f6ae6057;hb=HEAD#l66 [4] https://git.uclibc.org/uClibc/tree/include/link.h#n71 OK? Bootstrapped and tested on aarch64-linux-(gnu|musl), riscv64-linux-(gnu|musl) and x86_64-linux-(gnu|musl) with no regressions. gcc/ada/ * adaint.c [Linux]: Include . (__gnat_get_executable_load_address) [Linux]: Enable only for glibc & uClibc on Linux. gcc/ada/adaint.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c index 1c23d1584..852209416 100644 --- a/gcc/ada/adaint.c +++ b/gcc/ada/adaint.c @@ -3526,6 +3526,7 @@ __gnat_cpu_set (int cpu, size_t count ATTRIBUTE_UNUSED, cpu_set_t *set) #if defined (__APPLE__) #include #elif defined (__linux__) +#include #include #endif @@ -3535,7 +3536,7 @@ __gnat_get_executable_load_address (void) #if defined (__APPLE__) return _dyld_get_image_header (0); -#elif defined (__linux__) +#elif defined (__linux__) && (defined (__GLIBC__) || defined (__UCLIBC__)) struct link_map *map = _r_debug.r_map; return (const void *)map->l_addr;
[PATCH] tree.def: Remove outdated comment on SAD_EXPR
Hi! While looking at PR108692, I've noticed SAD_EXPR comment mentions that WIDEN_MINUS_EXPR is missing, which is not true anymore since r11-5160. The following patch just removes that part of the comment. Ok for trunk? 2023-02-08 Jakub Jelinek * tree.def (SAD_EXPR): Remove outdated comment about missing WIDEN_MINUS_EXPR. --- gcc/tree.def.jj 2023-01-02 09:32:28.118202450 +0100 +++ gcc/tree.def2023-02-08 10:05:52.795587292 +0100 @@ -1341,8 +1341,7 @@ DEFTREECODE (WIDEN_SUM_EXPR, "widen_sum_ The first two arguments are of type t1 which should be integer. The third argument and the result are of type t2, such that t2 is at least twice the size of t1. Like DOT_PROD_EXPR, SAD_EXPR (arg1,arg2,arg3) is - equivalent to (note we don't have WIDEN_MINUS_EXPR now, but we assume its - behavior is similar to WIDEN_SUM_EXPR): + equivalent to: tmp = WIDEN_MINUS_EXPR (arg1, arg2) tmp2 = ABS_EXPR (tmp) arg3 = PLUS_EXPR (tmp2, arg3) Jakub
[PATCH] vect: Check gather/scatter offset types [PR108316]
The gather/scatter support can over-widen an offset if the target
requires it, but this relies on using a pattern sequence to add
the widening conversion. That failed in the testcase because an
earlier pattern (bool) took priority.
I think we should allow patterns to be applied to other patterns,
but that's quite an invasive change and isn't suitable for stage 4.
This patch instead punts if the offset type doesn't match the
expected one.
If we switched to using the SLP representation for everything,
we would probably handle both patterns by rewriting the graph,
which should be much easier.
Tested on aarch64-linux-gnu & x86_64-linux-gnu. OK to install?
Richard
gcc/
PR tree-optimization/108316
* tree-vect-stmts.cc (get_load_store_type): When using
internal functions for gather/scatter, make sure that the type
of the offset argument is consistent with the offset vector type.
gcc/testsuite/
PR tree-optimization/108316
* gcc.dg/vect/pr108316.c: New test.
---
gcc/testsuite/gcc.dg/vect/pr108316.c | 11 +++
gcc/tree-vect-stmts.cc | 17 +
2 files changed, 28 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/vect/pr108316.c
diff --git a/gcc/testsuite/gcc.dg/vect/pr108316.c
b/gcc/testsuite/gcc.dg/vect/pr108316.c
new file mode 100644
index 000..540b7f2aed4
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr108316.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-O3" } */
+
+extern _Bool a[];
+
+void
+foo (short i, int b[][64][1])
+{
+ for (; i < 64; i += 4)
+a[i] = b[0][i] != 0;
+}
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index eb4ca1f184e..c86249adcc3 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -2474,6 +2474,23 @@ get_load_store_type (vec_info *vinfo, stmt_vec_info
stmt_info,
*memory_access_type = VMAT_GATHER_SCATTER;
if (!vect_check_gather_scatter (stmt_info, loop_vinfo, gs_info))
gcc_unreachable ();
+ /* When using internal functions, we rely on pattern recognition
+to convert the type of the offset to the type that the target
+requires, with the result being a call to an internal function.
+If that failed for some reason (e.g. because another pattern
+took priority), just handle cases in which the offset already
+has the right type. */
+ else if (gs_info->ifn != IFN_LAST
+ && !is_gimple_call (stmt_info->stmt)
+ && !tree_nop_conversion_p (TREE_TYPE (gs_info->offset),
+ TREE_TYPE (gs_info->offset_vectype)))
+ {
+ if (dump_enabled_p ())
+ dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
+"%s offset requires a conversion\n",
+vls_type == VLS_LOAD ? "gather" : "scatter");
+ return false;
+ }
else if (!vect_is_simple_use (gs_info->offset, vinfo,
_info->offset_dt,
_info->offset_vectype))
--
2.25.1
[PATCH] c++: Mangle EXCESS_PRECISION_EXPR as fold_convert REAL_CST [PR108698]
Hi!
For standard excess precision, like the C FE we parse floating
point constants as EXCESS_PRECISION_EXPR of promoted REAL_CST
rather than the nominal REAL_CST, and as the following testcase
shows the constants might need mangling.
The following patch mangles those as fold_convert of the REAL_CST
to EXCESS_PRECISION_EXPR type, i.e. how they were mangled before.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
I'm not really sure EXCESS_PRECISION_EXPR can appear elsewhere
in expressions that would need mangling, tried various testcases
but haven't managed to come up with one. If that is possible,
we'd keep ICEing on it without/with this patch, and the big question
is how to mangle those; they could be mangled as casts from the
promoted type back to nominal, but then in the mangled expressions
one could see the effects of excess precision. Until we have
a reproducer, that is just theoretical though.
2023-02-08 Jakub Jelinek
PR c++/108698
* mangle.cc (write_expression, write_template_arg): Handle
EXCESS_PRECISION_EXPR with REAL_CST operand as
write_template_arg_literal on fold_convert of the REAL_CST
to EXCESS_PRECISION_EXPR type.
* g++.dg/cpp0x/pr108698.C: New test.
--- gcc/cp/mangle.cc.jj 2023-01-25 15:13:23.220649480 +0100
+++ gcc/cp/mangle.cc2023-02-07 19:27:35.949588461 +0100
@@ -3107,6 +3107,10 @@ write_expression (tree expr)
else if (TREE_CODE_CLASS (code) == tcc_constant
|| code == CONST_DECL)
write_template_arg_literal (expr);
+ else if (code == EXCESS_PRECISION_EXPR
+ && TREE_CODE (TREE_OPERAND (expr, 0)) == REAL_CST)
+write_template_arg_literal (fold_convert (TREE_TYPE (expr),
+ TREE_OPERAND (expr, 0)));
else if (code == PARM_DECL && DECL_ARTIFICIAL (expr))
{
gcc_assert (id_equal (DECL_NAME (expr), "this"));
@@ -3815,6 +3819,10 @@ write_template_arg (tree node)
|| code == CONST_DECL
|| null_member_pointer_value_p (node))
write_template_arg_literal (node);
+ else if (code == EXCESS_PRECISION_EXPR
+ && TREE_CODE (TREE_OPERAND (node, 0)) == REAL_CST)
+write_template_arg_literal (fold_convert (TREE_TYPE (node),
+ TREE_OPERAND (node, 0)));
else if (DECL_P (node))
{
write_char ('L');
--- gcc/testsuite/g++.dg/cpp0x/pr108698.C.jj2023-02-07 20:33:45.365125556
+0100
+++ gcc/testsuite/g++.dg/cpp0x/pr108698.C 2023-02-07 19:55:57.459493456
+0100
@@ -0,0 +1,16 @@
+// PR c++/108698
+// { dg-do compile { target c++11 } }
+
+template
+decltype (T () * T () + 1.0) foo ()
+{
+ return T () * T () + 1.0;
+}
+
+void
+bar ()
+{
+ foo ();
+ foo ();
+ foo ();
+}
Jakub
[PATCH] vect-patterns: Fix up vect_widened_op_tree [PR108692]
Hi!
The following testcase is miscompiled on aarch64-linux since r11-5160.
Given
[local count: 955630225]:
# i_22 = PHI
# r_23 = PHI
...
a.0_5 = (unsigned char) a_15;
_6 = (int) a.0_5;
b.1_7 = (unsigned char) b_17;
_8 = (int) b.1_7;
c_18 = _6 - _8;
_9 = ABS_EXPR ;
r_19 = _9 + r_23;
...
where SSA_NAMEs 15/17 have signed char, 5/7 unsigned char and rest is int
we first pattern recognize c_18 as
patt_34 = (a.0_5) w- (b.1_7);
which is still correct, 5/7 are unsigned char subtracted in wider type,
but then vect_recog_sad_pattern turns it into
SAD_EXPR
which is incorrect, because 15/17 are signed char and so it is
sum of absolute signed differences rather than unsigned sum of
absolute unsigned differences.
The reason why this happens is that vect_recog_sad_pattern calls
vect_widened_op_tree with MINUS_EXPR, WIDEN_MINUS_EXPR on the
patt_34 = (a.0_5) w- (b.1_7); statement's vinfo and vect_widened_op_tree
calls vect_look_through_possible_promotion on the operands of the
WIDEN_MINUS_EXPR, which looks through the further casts.
vect_look_through_possible_promotion has careful code to stop when there
would be nested casts that need to be preserved, but the problem here
is that the WIDEN_*_EXPR operation itself has an implicit cast on the
operands already - in this case of WIDEN_MINUS_EXPR the unsigned char
5/7 SSA_NAMEs are widened to unsigned short before the subtraction,
and vect_look_through_possible_promotion obviously isn't told about that.
Now, I think when we see those WIDEN_{MULT,MINUS,PLUS}_EXPR codes, we had
to look through possible promotions already when creating those and so
vect_look_through_possible_promotion again isn't really needed, all we need
to do is arrange what that function will do if the operand isn't result
of any cast. Other option would be let vect_look_through_possible_promotion
know about the implicit promotion from the WIDEN_*_EXPR, but I'm afraid
that would be much harder.
Bootstrapped/regtested on aarch64-linux, x86_64-linux, i686-linux and
powerpc64le-linux, ok for trunk?
2023-02-08 Jakub Jelinek
PR tree-optimization/108692
* tree-vect-patterns.cc (vect_widened_op_tree): If rhs_code is
widened_code which is different from code, don't call
vect_look_through_possible_promotion but instead just check op is
SSA_NAME with integral type for which vect_is_simple_use is true
and call set_op on this_unprom.
* gcc.dg/pr108692.c: New test.
--- gcc/tree-vect-patterns.cc.jj2023-01-02 09:32:45.635949342 +0100
+++ gcc/tree-vect-patterns.cc 2023-02-07 15:27:33.214608837 +0100
@@ -601,7 +601,25 @@ vect_widened_op_tree (vec_info *vinfo, s
if (shift_p && i == 1)
return 0;
- if (!vect_look_through_possible_promotion (vinfo, op, this_unprom))
+ if (rhs_code != code)
+ {
+ /* If rhs_code is widened_code, don't look through further
+possible promotions, there is a promotion already embedded
+in the WIDEN_*_EXPR. */
+ if (TREE_CODE (op) != SSA_NAME
+ || !INTEGRAL_TYPE_P (TREE_TYPE (op)))
+ return 0;
+
+ stmt_vec_info def_stmt_info;
+ gimple *def_stmt;
+ vect_def_type dt;
+ if (!vect_is_simple_use (op, vinfo, , _stmt_info,
+ _stmt))
+ return 0;
+ this_unprom->set_op (op, dt, NULL);
+ }
+ else if (!vect_look_through_possible_promotion (vinfo, op,
+ this_unprom))
return 0;
if (TYPE_PRECISION (this_unprom->type) == TYPE_PRECISION (type))
--- gcc/testsuite/gcc.dg/pr108692.c.jj 2023-02-07 15:47:20.329076264 +0100
+++ gcc/testsuite/gcc.dg/pr108692.c 2023-02-07 15:46:15.623031983 +0100
@@ -0,0 +1,31 @@
+/* PR tree-optimization/108692 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -ftree-vectorize" } */
+
+__attribute__((noipa)) int
+foo (signed char *x, signed char *y, int n)
+{
+ int i, r = 0;
+ signed char a, b;
+ for (i = 0; i < n; i++)
+{
+ a = x[i];
+ b = y[i];
+ int c = (unsigned char) a - (unsigned char) b;
+ r = r + (c < 0 ? -c : c);
+}
+ return r;
+}
+
+int
+main ()
+{
+ signed char x[64] = {}, y[64] = {};
+ if (__CHAR_BIT__ != 8 || __SIZEOF_INT__ != 4)
+return 0;
+ x[32] = -128;
+ y[32] = 1;
+ if (foo (x, y, 64) != 127)
+__builtin_abort ();
+ return 0;
+}
Jakub
