Re: [PATCH] vect: Check that vector factor is a compile-time constant

[Richard Biener via Gcc-patches]

On Wed, Mar 1, 2023 at 10:00 PM Michael Collison  wrote:
>
> Okay there seems to be consensus on using constant_lower_bound (vf), but
> I don't understand how that is a replacement for "vf.is_constant ()"? In
> one case we are checking if "vf" is a constant, on the other we are
> asking for the lower bound. For the crash in question
> "constant_lower_bound (vf) " returns the integer value of two.

Use the result of constant_lower_bound (vf) in place of 'vf' when
build_int_cst.  That should be correct for both poly and non-poly int VF.

> On 2/27/23 09:51, Richard Sandiford wrote:
> > FWIW, this patch looks good to me.  I'd argue it's a regression fix
> > of kinds, in that the current code was correct before variable VF and
> > became incorrect after variable VF.  It might be possible to trigger
> > the problem on SVE too, with a sufficiently convoluted test case.
> > (Haven't tried though.)
> >
> > Richard Biener  writes:
> >> On Wed, Feb 22, 2023 at 12:03 AM Michael Collison  
> >> wrote:
> >>> While working on autovectorizing for the RISCV port I encountered an
> >>> issue where vect_do_peeling assumes that the vectorization factor is a
> >>> compile-time constant. The vectorization is not a compile-time constant
> >>> on RISCV.
> >>>
> >>> Tested on RISCV and x86_64-linux-gnu. Okay?
> >> I wonder how you arrive at prologue peeling with a non-constant VF?
> > Not sure about the RVV case, but I think it makes sense in principle.
> > E.g. if some ISA takes the LOAD_LEN rather than fully-predicated
> > approach, it can't easily use the first iteration of the vector loop
> > to do peeling for alignment.  (At least, the IV steps would then
> > no longer match VF for all iterations.)  I guess it could use a
> > *different* vector loop, but we don't support that yet.
> >
> > There are also some corner cases for which we still don't support
> > predicated loops and instead fall back on an unpredicated VLA loop
> > followed by a scalar epilogue.  Peeling for alignment would then
> > require a scalar prologue too.
> >
> >> In any case it would probably be better to use constant_lower_bound (vf)
> >> here?  Also it looks wrong to apply this limit in case we are using
> >> a fully masked main vector loop.  But as said, the specific case of
> >> non-constant VF and prologue peeling probably wasn't supposed to happen,
> >> instead the prologue usually is applied via an offset to a fully masked 
> >> loop?
> > Hmm, yeah, agree constant_lower_bound should work too.
> >
> > Thanks,
> > Richard
> >
> >> Richard?
> >>
> >> Thanks,
> >> Richard.
> >>
> >>> Michael
> >>>
> >>> gcc/
> >>>
> >>>   * tree-vect-loop-manip.cc (vect_do_peeling): Verify
> >>>   that vectorization factor is a compile-time constant.
> >>>
> >>> ---
> >>>gcc/tree-vect-loop-manip.cc | 2 +-
> >>>1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/gcc/tree-vect-loop-manip.cc b/gcc/tree-vect-loop-manip.cc
> >>> index 6aa3d2ed0bf..1ad1961c788 100644
> >>> --- a/gcc/tree-vect-loop-manip.cc
> >>> +++ b/gcc/tree-vect-loop-manip.cc
> >>> @@ -2930,7 +2930,7 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree
> >>> niters, tree nitersm1,
> >>>  niters = vect_build_loop_niters (loop_vinfo, &new_var_p);
> >>>  /* It's guaranteed that vector loop bound before vectorization 
> >>> is at
> >>> least VF, so set range information for newly generated var. */
> >>> -  if (new_var_p)
> >>> +  if (new_var_p && vf.is_constant ())
> >>>{
> >>>  value_range vr (type,
> >>>  wi::to_wide (build_int_cst (type, vf)),
> >>> --
> >>> 2.34.1
> >>>

Re: [PATCH] debug/108772 - ICE with late debug generated with -flto

[Richard Biener via Gcc-patches]

On Wed, 1 Mar 2023, Jason Merrill wrote:

> On 3/1/23 08:09, Jakub Jelinek wrote:
> > On Wed, Mar 01, 2023 at 01:07:02PM +, Richard Biener wrote:
> >> When combining -g1 with -flto we run into the DIE location annotation
> >> machinery for globals calling dwarf2out_late_global_decl but not
> >> having any early generated DIE for function scope statics.  In
> >> this process we'd generate a limbo DIE since also the function scope
> >> doesn't have any early generated DIE.  The limbo handling then tries
> >> to force a DIE for the context chain which ultimatively fails and
> >> ICEs at the std namespace decl because at -g1 we don't represent that.
> >>
> >> The following avoids this situation by making sure to never generate
> >> any limbo DIEs from dwarf2out_late_global_decl in the in_lto_p path
> >> but instead for function scope globals rely on DIE generation for
> >> the function to output a DIE for the local static (which doesn't
> >> happen for -g1).
> 
> So the issue is that we're trying to force out a DIE for a decl that we
> wouldn't have generated without -flto?  How is it avoided in the non-LTO case?

When we go rest_of_decl_compilation for this decl we defer to the
containing function to generate an early DIE but that doesn't
(because of -g1).  The call to late_global_decl that's done by
assemble_decl then does nothing because there's no early DIE.  But with
-flto we cannot completely rely on early DIE presence (not even without,
in case of cloning - but we don't clone global variables), esp. because
there's still the "supported" non-early-LTO path for non-ELF targets.

So at this point it seems to be the best thing to mimic what
rest_of_decl_compilation does and defer to dwarf2out of the
containing function to generate the DIE (or not).  For the reason
of the least amount of changes at this point in stage4 I went for
querying the DECL_CONTEXT DIE instead of right-out not handling
local_function_static () decls in this path.

If you'd prefer that, so

  if (! die && in_lto_p
  /* Function scope variables are emitted when emitting the
 DIE for the function.  */
  && ! local_function_static (decl))
dwarf2out_decl (decl);

then I can test that variant as well which feels a bit more
consistent.

Thanks,
Richard.

> >> I explored a lot of other options to fix this but in the end this
> >> seems to be the most spot-on fix with the least risk of unwanted
> >> effects.
> >>
> >> LTO bootstrapped on x86_64-unknown-linux-gnu (running into PR108984),
> >> bootstrapped and tested on x86_64-unknown-linux-gnu.
> >>
> >> OK?
> >>
> >> Thanks,
> >> Richard.
> >>
> >>  PR debug/108772
> >>  * dwarf2out.cc (dwarf2out_late_global_decl): Do not
> >>  generate a DIE for a function scope static when we do
> >>  not have a DIE for the function already.
> >>
> >>  * g++.dg/lto/pr108772_0.C: New testcase.
> > 
> > LGTM, but please give Jason a day to chime in if he disagrees.
> > 
> >  Jakub
> > 
> 
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)

[pushed] wwwdocs: testing: Avoid a duplicate link

[Gerald Pfeifer]

This came up in a conversation with Jan. (We already have a link a bit 
earlier on that page.)

Pushed.

Gerald
---
 htdocs/testing/index.html | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/htdocs/testing/index.html b/htdocs/testing/index.html
index bd6219ab..012ac287 100644
--- a/htdocs/testing/index.html
+++ b/htdocs/testing/index.html
@@ -115,10 +115,8 @@ the testsuite directories.
   Build and test packages that are normally available on your
   platform and for which you have access to source.
   Run benchmarks regularly and report performance regressions.
-  Extend the
-  http://toolchain.lug-owl.de/buildbot/";>build robot to also
-  do local builds, run the testsuite, visualize test result differences
-  and probably use something like
+  Extend the build robot to also do local builds, run the testsuite,
+  visualize test result differences and probably use something like
   http://buildbot.net/";>BuildBot. Some of the
   https://gcc.gnu.org/wiki/CompileFarm";>Compile Farm machines
   could also be used.
-- 
2.39.1

Re: [PATCH] libiberty: fix memory leak in pex-win32.c and refactor

[Richard Biener via Gcc-patches]

On Wed, Mar 1, 2023 at 7:14 PM Costas Argyris via Gcc-patches
 wrote:
>
> Hi
>
> It seems that the win32_spawn function in libiberty/pex-win32.c is leaking
> the cmdline buffer in 2/3 exit scenarios (it is only free'd in 1/3).The
> problem here is that the cleanup code is written 3 times, one at each exit
> scenario.
>
> The proposed attached refactoring has the cleanup code appearing just once
> and is executed for all exit scenarios, reducing the likelihood of such
> leaks in the future.

One could imagine that CreateProcess in case of success takes ownership of
the buffer pointed to by cmdline?  If you can confirm it is not then the patch
looks OK to me.

Thanks,
Richard.

> Thanks,
> Costas

RE: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

[Li, Pan2 via Gcc-patches]

Thanks all for help.

I tried and validated the way Richard mentioned, it works well as expected.
Meanwhile, I updated the PR as below (I take the in-reply-to option for 
send-email but looks failed).
Could you please help to review continuously?

Additionally, I would like to learn if we can land this patch for the GCC 13 
release (RVV release included).

https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613149.html

Pan

From: juzhe.zh...@rivai.ai 
Sent: Thursday, March 2, 2023 6:54 AM
To: richard.sandiford ; Li, Pan2 
Cc: rguenther ; gcc-patches ; Pan 
Li ; kito.cheng 
Subject: Re: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

>> Does the eventual value set by ADJUST_BYTESIZE equal the real number of
>> bytes loaded by vlm.v and stored by vstm.v (after the appropriate vsetvl)?
>> Or is the GCC size larger in some cases than the number of bytes
>> loaded and stored?
For VNx1BI,VNx2BI,VNx4BI,VNx8BI, we allocate the larger size of memory or stack 
for register spillling
according to ADJUST_BYTESIZE.
After appropriate vsetvl, VNx1BI is loaded/stored 1/8 of ADJUST_BYTESIZE 
(vsetvl e8mf8).
After appropriate vsetvl, VNx2BI is loaded/stored 2/8 of ADJUST_BYTESIZE 
(vsetvl e8mf2).
After appropriate vsetvl, VNx4BI is loaded/stored 4/8 of ADJUST_BYTESIZE 
(vsetvl e8mf4).
After appropriate vsetvl, VNx8BI is loaded/stored 8/8 of ADJUST_BYTESIZE 
(vsetvl e8m1).

Note: except these 4 machine modes, all other machine modes of RVV, 
ADJUST_BYTESIZE
are equal to the real number of bytes of load/store instruction that RVV ISA 
define.

Well, as I said, it's fine that we allocated larger memory for 
VNx1BI,VNx2BI,VNx4BI,
we can emit appropriate vsetvl to gurantee the correctness in RISC-V backward 
according
to the machine_mode as long as long GCC didn't do the incorrect elimination in 
middle-end.

Besides, poly (1,1) is 1/8 of machine vector-length which is already really a 
small number,
which is the real number bytes loaded/stored for VNx8BI.
You can say VNx1BI, VNx2BI, VNx4BI are consuming larger memory than we actually 
load/stored by appropriate vsetvl
since they are having same ADJUST_BYTESIZE as VNx8BI. However, I think it's 
totally fine so far as long as we can
gurantee the correctness and I think optimizing such memory storage consuming 
is trivial.

>> And does it equal the size of the corresponding LLVM machine type?

Well, for some reason, in case of register spilling, LLVM consume much more 
memory than GCC.
And they always do whole register load/store (a single vector register 
vector-length) for register spilling.
That's another story (I am not going to talk too much about this since it's a 
quite ugly implementation).
They don't model the types accurately according RVV ISA for register spilling.

In case of normal load/store like:
vbool8_t v2 = *(vbool8_t*)in;  *(vbool8_t*)(out + 100) = v2;
This kind of load/store, their load/stores instructions of codegen are accurate.
Even though their instructions are accurate for load/store accessing behavior, 
I am not sure whether size
of their machine type is accurate.

For example, in IR presentation: VNx1BI of GCC is represented as vscale x 1 x i1
  VNx2BI of GCC is represented as vscale x 2 x i1
in LLVM IR.
I am not sure the bytesize of  vscale x 1 x i1 and vscale x 2 x i1.
I didn't take a deep a look at it.

I think this question is not that important, no matter whether VNx1BI and 
VNx2BI are modeled accurately in case of ADUST_BYTESIZE
in GCC or  vscale x 1 x i1 and vscale x 2 x i1 are modeled accurately in case 
of  their bytesize,
I think as long as we can emit appropriate vsetvl + vlm/vsm, it's totally fine 
for RVV  even though in some case, their memory allocation
is not accurate in compiler.

juzhe.zh...@rivai.ai

From: Richard Sandiford
Date: 2023-03-02 00:14
To: Li\, Pan2
CC: juzhe.zhong\@rivai.ai; 
rguenther; 
gcc-patches; Pan 
Li; 
kito.cheng
Subject: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment
"Li, Pan2" mailto:pan2...@intel.com>> writes:
> Thanks all for so much valuable and helpful materials.
>
> As I understand (Please help to correct me if any mistake.), for the VNx*BI 
> (aka, 1, 2, 4, 8, 16, 32, 64),
> the precision and mode size need to be adjusted as below.
>
> Precision size [1, 2, 4, 8, 16, 32, 64]
> Mode size [1, 1, 1, 1, 2, 4, 8]
>
> Given that, if we ignore the self-test failure, only the adjust_precision 
> part is able to fix the bug I mentioned.
> The genmode will first get the precision, and then leverage the mode_size = 
> exact_div / 8 to generate.
> Meanwhile, it also provides the adjust_mode_size after the mode_size 
> generation.
>
> The riscv parts has the mode_size_adjust already and the value of mod

[PATCH v2] RISC-V: Bugfix for rvv bool mode precision adjustment

[pan2.li--- via Gcc-patches]

From: Pan Li 

Fix the bug of the rvv bool mode precision with the adjustment.
The bits size of vbool*_t will be adjusted to
[1, 2, 4, 8, 16, 32, 64] according to the rvv spec 1.0 isa. The
adjusted mode precison of vbool*_t will help underlying pass to
make the right decision for both the correctness and optimization.

Given below sample code:
void test_1(int8_t * restrict in, int8_t * restrict out)
{
  vbool8_t v2 = *(vbool8_t*)in;
  vbool16_t v5 = *(vbool16_t*)in;
  *(vbool16_t*)(out + 200) = v5;
  *(vbool8_t*)(out + 100) = v2;
}

Before the precision adjustment:
addia4,a1,100
vsetvli a5,zero,e8,m1,ta,ma
addia1,a1,200
vlm.v   v24,0(a0)
vsm.v   v24,0(a4)
// Need one vsetvli and vlm.v for correctness here.
vsm.v   v24,0(a1)

After the precision adjustment:
csrrt0,vlenb
sllit1,t0,1
csrra3,vlenb
sub sp,sp,t1
sllia4,a3,1
add a4,a4,sp
sub a3,a4,a3
vsetvli a5,zero,e8,m1,ta,ma
addia2,a1,200
vlm.v   v24,0(a0)
vsm.v   v24,0(a3)
addia1,a1,100
vsetvli a4,zero,e8,mf2,ta,ma
csrrt0,vlenb
vlm.v   v25,0(a3)
vsm.v   v25,0(a2)
sllit1,t0,1
vsetvli a5,zero,e8,m1,ta,ma
vsm.v   v24,0(a1)
add sp,sp,t1
jr  ra

However, there may be some optimization opportunates after
the mode precision adjustment. It can be token care of in
the RISC-V backend in the underlying separted PR(s).

PR 108185
PR 108654

gcc/ChangeLog:

* config/riscv/riscv-modes.def (ADJUST_PRECISION):
* config/riscv/riscv.cc (riscv_v_adjust_precision):
* config/riscv/riscv.h (riscv_v_adjust_precision):
* genmodes.cc (ADJUST_PRECISION):
(emit_mode_adjustments):

gcc/testsuite/ChangeLog:

* gcc.target/riscv/pr108185-1.c: New test.
* gcc.target/riscv/pr108185-2.c: New test.
* gcc.target/riscv/pr108185-3.c: New test.
* gcc.target/riscv/pr108185-4.c: New test.
* gcc.target/riscv/pr108185-5.c: New test.
* gcc.target/riscv/pr108185-6.c: New test.
* gcc.target/riscv/pr108185-7.c: New test.
* gcc.target/riscv/pr108185-8.c: New test.

Signed-off-by: Pan Li 
---
 gcc/config/riscv/riscv-modes.def|  8 +++
 gcc/config/riscv/riscv.cc   | 12 
 gcc/config/riscv/riscv.h|  1 +
 gcc/genmodes.cc | 20 +-
 gcc/testsuite/gcc.target/riscv/pr108185-1.c | 68 ++
 gcc/testsuite/gcc.target/riscv/pr108185-2.c | 68 ++
 gcc/testsuite/gcc.target/riscv/pr108185-3.c | 68 ++
 gcc/testsuite/gcc.target/riscv/pr108185-4.c | 68 ++
 gcc/testsuite/gcc.target/riscv/pr108185-5.c | 68 ++
 gcc/testsuite/gcc.target/riscv/pr108185-6.c | 68 ++
 gcc/testsuite/gcc.target/riscv/pr108185-7.c | 68 ++
 gcc/testsuite/gcc.target/riscv/pr108185-8.c | 77 +
 12 files changed, 592 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/pr108185-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/pr108185-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/pr108185-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/pr108185-4.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/pr108185-5.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/pr108185-6.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/pr108185-7.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/pr108185-8.c

diff --git a/gcc/config/riscv/riscv-modes.def b/gcc/config/riscv/riscv-modes.def
index d5305efa8a6..110bddce851 100644
--- a/gcc/config/riscv/riscv-modes.def
+++ b/gcc/config/riscv/riscv-modes.def
@@ -72,6 +72,14 @@ ADJUST_BYTESIZE (VNx16BI, riscv_vector_chunks * 
riscv_bytes_per_vector_chunk);
 ADJUST_BYTESIZE (VNx32BI, riscv_vector_chunks * riscv_bytes_per_vector_chunk);
 ADJUST_BYTESIZE (VNx64BI, riscv_v_adjust_nunits (VNx64BImode, 8));
 
+ADJUST_PRECISION (VNx1BI, riscv_v_adjust_precision (VNx1BImode, 1));
+ADJUST_PRECISION (VNx2BI, riscv_v_adjust_precision (VNx2BImode, 2));
+ADJUST_PRECISION (VNx4BI, riscv_v_adjust_precision (VNx4BImode, 4));
+ADJUST_PRECISION (VNx8BI, riscv_v_adjust_precision (VNx8BImode, 8));
+ADJUST_PRECISION (VNx16BI, riscv_v_adjust_precision (VNx16BImode, 16));
+ADJUST_PRECISION (VNx32BI, riscv_v_adjust_precision (VNx32BImode, 32));
+ADJUST_PRECISION (VNx64BI, riscv_v_adjust_precision (VNx64BImode, 64));
+
 /*
| Mode| MIN_VLEN=32 | MIN_VLEN=32 | MIN_VLEN=64 | MIN_VLEN=64 |
| | LMUL| SEW/LMUL| LMUL| SEW/LMUL|
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index f11b7949a49

Re: [PATCH] libstdc++: Limit allocations in _Rb_tree 2/2

[François Dumont via Gcc-patches]

Just forget about this patch, bad idea.

The key_type might have additional data not used for the comparison. 
This data would not be preserved if we were inserting the already stored 
equivalent key instead of the user provided.



On 22/02/23 07:08, François Dumont wrote:

This one is a refinement for multimap/multiset.

It allows to have share the same key if managed with ref counting like 
the cow string.


    libstdc++: [_Rb_tree] Limit allocations on equal insertions [PR 
96088]


    When inserting the same key several times prefer to insert the new 
entry using the
    current stored key_type instance if this copy is noexcept. 
Otherwise create a new

    key instance from input argument.

    libstdc++-v3/ChangeLog:

    PR libstdc++/96088
    * include/bits/cow_string.h 
(basic_string<>::basic_string(const basic_string&)):

    Add noexcept qualification when allocator is always equal.
    * include/bits/stl_tree.h 
(_Rb_tree<>::_M_get_insert_equal_pos_tr): New.

    (_Rb_tree<>::_M_emplace_equal_tr): New, use latter.
    (_Rb_tree<>::_M_emplace_equal_aux): New, use latter.
(_Rb_tree<>::_M_emplace_equal<_Arg>(_Arg&&)): New, use latter.
    * testsuite/23_containers/multimap/96088.cc (test01): Add 
check on redundant

    insertion.
    (test02): Likewise.
    * testsuite/23_containers/multiset/96088.cc (test01, 
test02): Likewise.


François

Re: [PATCH][stage1] Remove conditionals around free()

[Ian Lance Taylor]

Bernhard Reutner-Fischer  writes:

>  libgo/runtime/go-setenv.c|6 ++
>  libgo/runtime/go-unsetenv.c  |3 +--

Files in the libgo directory are mirrored from upstream sources, as
described in libgo/README.gcc.  Please don't change them in the gcc
repository.  Thanks.

Ian

[PATCH 2/2] gcov: Fix incorrect gimple line LOCATION [PR97923]

[Xionghu Luo via Gcc-patches]

For case like belowi test.c:

1:int foo(char c)
2:{
3:  return ((c >= 'A' && c <= 'Z')
4:   || (c >= 'a' && c <= 'z')
5:   || (c >= '0' && c <='0'));}

the generated line number is incorrect for condition c>='A' of block 2:
Thus correct the condition op0 location.

gcno diff before and with this patch:

test.gcno:  575:  block 11: 1:0001(tree)
test.gcno:  583:0145:  35:LINES
-test.gcno:  595:  block 2:`test.c':1, 5
+test.gcno:  595:  block 2:`test.c':1, 3
test.gcno:  626:0145:  31:LINES
test.gcno:  638:  block 3:`test.c':3
test.gcno:  665:0145:  31:LINES
test.gcno:  677:  block 4:`test.c':4
test.gcno:  704:0145:  31:LINES
test.gcno:  716:  block 5:`test.c':4
test.gcno:  743:0145:  31:LINES
test.gcno:  755:  block 6:`test.c':5

Also save line id in line vector for gcov debug use.

Regression tested pass on x86_64-linux-gnu and aarch64-linux-gnu, OK for
master?

gcc/ChangeLog:

PR gcov/97923
* gcov.cc (line_info::line_info): Init id.
(solve_flow_graph): Fix typo.
(add_line_counts): Set line->id.
* gimplify.cc (shortcut_cond_r): Correct cond expr op0 location.

gcc/testsuite/ChangeLog:

PR gcov/97923
* gcc.misc-tests/gcov-pr97923.c: New test.

Signed-off-by: Xionghu Luo 
---
 gcc/gcov.cc |  9 ++---
 gcc/gimplify.cc |  6 --
 gcc/testsuite/gcc.misc-tests/gcov-pr97923.c | 13 +
 3 files changed, 23 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/gcc.misc-tests/gcov-pr97923.c

diff --git a/gcc/gcov.cc b/gcc/gcov.cc
index 2ec7248cc0e..77ca94c71c4 100644
--- a/gcc/gcov.cc
+++ b/gcc/gcov.cc
@@ -205,6 +205,8 @@ public:
   /* Execution count.  */
   gcov_type count;
 
+  unsigned id;
+
   /* Branches from blocks that end on this line.  */
   vector branches;
 
@@ -216,8 +218,8 @@ public:
   unsigned has_unexecuted_block : 1;
 };
 
-line_info::line_info (): count (0), branches (), blocks (), exists (false),
-  unexceptional (0), has_unexecuted_block (0)
+line_info::line_info (): count (0), id (0), branches (), blocks (),
+  exists (false), unexceptional (0), has_unexecuted_block (0)
 {
 }
 
@@ -2370,7 +2372,7 @@ solve_flow_graph (function_info *fn)
 
   /* If the graph has been correctly solved, every block will have a
  valid count.  */
-  for (unsigned i = 0; ix < fn->blocks.size (); i++)
+  for (unsigned i = 0; i < fn->blocks.size (); i++)
 if (!fn->blocks[i].count_valid)
   {
fnotice (stderr, "%s:graph is unsolvable for '%s'\n",
@@ -2730,6 +2732,7 @@ add_line_counts (coverage_info *coverage, function_info 
*fn)
}
  line->count += block->count;
}
+ line->id = ln;
}
 
  has_any_line = true;
diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index ade6e335da7..341a27b033e 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -3915,7 +3915,8 @@ shortcut_cond_r (tree pred, tree *true_label_p, tree 
*false_label_p,
false_label_p = &local_label;
 
   /* Keep the original source location on the first 'if'.  */
-  t = shortcut_cond_r (TREE_OPERAND (pred, 0), NULL, false_label_p, locus);
+  tree op0 = TREE_OPERAND (pred, 0);
+  t = shortcut_cond_r (op0, NULL, false_label_p, EXPR_LOCATION (op0));
   append_to_statement_list (t, &expr);
 
   /* Set the source location of the && on the second 'if'.  */
@@ -3938,7 +3939,8 @@ shortcut_cond_r (tree pred, tree *true_label_p, tree 
*false_label_p,
true_label_p = &local_label;
 
   /* Keep the original source location on the first 'if'.  */
-  t = shortcut_cond_r (TREE_OPERAND (pred, 0), true_label_p, NULL, locus);
+  tree op0 = TREE_OPERAND (pred, 0);
+  t = shortcut_cond_r (op0, true_label_p, NULL, EXPR_LOCATION (op0));
   append_to_statement_list (t, &expr);
 
   /* Set the source location of the || on the second 'if'.  */
diff --git a/gcc/testsuite/gcc.misc-tests/gcov-pr97923.c 
b/gcc/testsuite/gcc.misc-tests/gcov-pr97923.c
new file mode 100644
index 000..ad4f7d40817
--- /dev/null
+++ b/gcc/testsuite/gcc.misc-tests/gcov-pr97923.c
@@ -0,0 +1,13 @@
+/* { dg-options "-fprofile-arcs -ftest-coverage" } */
+/* { dg-do run { target native } } */
+
+int foo(int c)
+{
+  return ((c >= 'A' && c <= 'Z') /* count(1*) */
+  || (c >= 'a' && c <= 'z') /* count(1*) */
+  || (c >= '0' && c <= '0')); /* count(1*) */
+}
+
+int main() { foo(0); }
+
+/* { dg-final { run-gcov gcov-pr97923-1.c } } */
-- 
2.27.0

[PATCH 1/2] gcov: Fix "do-while" structure in case statement leads to incorrect code coverage [PR93680]

[Xionghu Luo via Gcc-patches]

When spliting edge with self loop, the split edge should be placed just next to
the edge_in->src, otherwise it may generate different position latch bbs for
two consecutive self loops.  For details, please refer to:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93680#c4

Regression tested pass on x86_64-linux-gnu and aarch64-linux-gnu, OK for
master?

gcc/ChangeLog:

PR gcov/93680
* tree-cfg.cc (split_edge_bb_loc): Return edge_in->src for self loop.

gcc/testsuite/ChangeLog:

PR gcov/93680
* gcc.misc-tests/gcov-pr93680.c: New test.

Signed-off-by: Xionghu Luo 
---
 gcc/testsuite/gcc.misc-tests/gcov-pr93680.c | 24 +
 gcc/tree-cfg.cc |  2 +-
 2 files changed, 25 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.misc-tests/gcov-pr93680.c

diff --git a/gcc/testsuite/gcc.misc-tests/gcov-pr93680.c 
b/gcc/testsuite/gcc.misc-tests/gcov-pr93680.c
new file mode 100644
index 000..b2bf9e626fc
--- /dev/null
+++ b/gcc/testsuite/gcc.misc-tests/gcov-pr93680.c
@@ -0,0 +1,24 @@
+/* { dg-options "-fprofile-arcs -ftest-coverage" } */
+/* { dg-do run { target native } } */
+
+int f(int s, int n)
+{
+  int p = 0;
+
+  switch (s)
+  {
+case 0: /* count(5) */
+  do { p++; } while (--n); /* count(5) */
+  return p; /* count(1) */
+
+case 1: /* count(5) */
+  do { p++; } while (--n); /* count(5) */
+  return p; /* count(1) */
+  }
+
+  return 0;
+}
+
+int main() { f(0, 5); f(1, 5); return 0; }
+
+/* { dg-final { run-gcov gcov-pr93680.c } } */
diff --git a/gcc/tree-cfg.cc b/gcc/tree-cfg.cc
index a9fcc7fd050..6fa1d83d366 100644
--- a/gcc/tree-cfg.cc
+++ b/gcc/tree-cfg.cc
@@ -3009,7 +3009,7 @@ split_edge_bb_loc (edge edge_in)
   if (dest_prev)
 {
   edge e = find_edge (dest_prev, dest);
-  if (e && !(e->flags & EDGE_COMPLEX))
+  if ((e && !(e->flags & EDGE_COMPLEX)) || edge_in->src == edge_in->dest)
return edge_in->src;
 }
   return dest_prev;
-- 
2.27.0

Re: [PATCH, gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628]

[Kewen.Lin via Gcc-patches]

Hi Haochen,

on 2023/3/1 15:09, HAO CHEN GUI wrote:
> Hi,
>   The patch escalates the failure when Hollerith constant to real conversion
> fails in native_interpret_expr. It finally reports an "Unclassifiable
> statement" error.
> 
>   The patch of pr95450 added a verification for decoding/encoding checking
> in native_interpret_expr. native_interpret_expr may fail on real type
> conversion and returns a NULL tree then. But upper layer calls don't handle
> the failure so that an ICE is reported when the verification fails.
> 
>   IBM long double is an example. It doesn't have a unique memory presentation
> for some real values. So it may not pass the verification. The new test
> case shows the problem.
> 
>   Bootstrapped and tested on powerpc64-linux BE and LE with no regressions.
> 
> Thanks
> Gui Haochen
> 
> ChangeLog
> 2023-03-01  Haochen Gui 
> 
> gcc/
>   PR target/103628
>   * fortran/target-memory.cc (gfc_interpret_float): Return FAIL when
>   native_interpret_expr gets a NULL tree.
>   * fortran/arith.cc (gfc_hollerith2real): Return NULL when
>   gfc_interpret_float fails.
> 
> gcc/testsuite/
>   PR target/103628
>   * gfortran.dg/pr103628.f90: New.
> 
> 
> patch.diff
> diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
> index c0d12cfad9d..d3d38c7eb6a 100644
> --- a/gcc/fortran/arith.cc
> +++ b/gcc/fortran/arith.cc
> @@ -2752,10 +2752,12 @@ gfc_hollerith2real (gfc_expr *src, int kind)
>result = gfc_get_constant_expr (BT_REAL, kind, &src->where);
> 
>hollerith2representation (result, src);
> -  gfc_interpret_float (kind, (unsigned char *) result->representation.string,
> -result->representation.length, result->value.real);
> -
> -  return result;
> +  if (gfc_interpret_float (kind,
> +(unsigned char *) result->representation.string,
> +result->representation.length, result->value.real))
> +return result;
> +  else
> +return NULL;
>  }
> 
>  /* Convert character to real.  The constant will be padded or truncated.  */
> diff --git a/gcc/fortran/target-memory.cc b/gcc/fortran/target-memory.cc
> index 7ce7d736629..04afc357e3c 100644
> --- a/gcc/fortran/target-memory.cc
> +++ b/gcc/fortran/target-memory.cc
> @@ -417,10 +417,13 @@ gfc_interpret_float (int kind, unsigned char *buffer, 
> size_t buffer_size,
>  {
>gfc_set_model_kind (kind);
>mpfr_init (real);
> -  gfc_conv_tree_to_mpfr (real,
> -  native_interpret_expr (gfc_get_real_type (kind),
> - buffer, buffer_size));
> 
> +  tree source  = native_interpret_expr (gfc_get_real_type (kind), buffer,
> + buffer_size);
> +  if (!source)
> +return 0;
> +
> +  gfc_conv_tree_to_mpfr (real, source);
>return size_float (kind);
>  }
> 
> diff --git a/gcc/testsuite/gfortran.dg/pr103628.f90 
> b/gcc/testsuite/gfortran.dg/pr103628.f90
> new file mode 100644
> index 000..e49aefc18fd
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/pr103628.f90
> @@ -0,0 +1,14 @@
> +! { dg-do compile { target powerpc*-*-* } }
> +! { dg-options "-O2 -mabi=ibmlongdouble" }

Since this test case is powerpc only, I think it can be moved to 
gcc/testsuite/gcc.target/powerpc/ppc-fortran.

BR,
Kewen

[COMMITTED] testsuite: Fix g++.dg/ext/attr-copy-2.C for default_packed targets

[Hans-Peter Nilsson via Gcc-patches]

Committed as obvious.  FWIW, I'm on the side that emitting
the warning when the reason is just that it's the default
layout, is bad.  A discussion took place years ago when the
warning was added.

-- >8 --
For targets where the byte-wise structure element layout is
the same as for attribute-packed, you get a warning when
that's specified.  Thus, expect a warning for such targets.
Note the exclusion of bitfields.

* g++.dg/ext/attr-copy-2.C: Fix for default_packed targets.
---
 gcc/testsuite/g++.dg/ext/attr-copy-2.C | 60 +-
 1 file changed, 30 insertions(+), 30 deletions(-)

diff --git a/gcc/testsuite/g++.dg/ext/attr-copy-2.C 
b/gcc/testsuite/g++.dg/ext/attr-copy-2.C
index 7776959d9f6b..ffd6f22ef56d 100644
--- a/gcc/testsuite/g++.dg/ext/attr-copy-2.C
+++ b/gcc/testsuite/g++.dg/ext/attr-copy-2.C
@@ -27,51 +27,51 @@ extern B &rb;
 
 typedef struct C
 {
-  ATTR (copy ((struct A *)0)) short m_pa_0;
-  ATTR (copy ((struct A *)(1, 0))) int m_pa_1_0;
-  ATTR (copy ((struct A *)(0, 1))) long m_pa_0_1;
+  ATTR (copy ((struct A *)0)) short m_pa_0; // { dg-warning "attribute 
ignored" "" { target default_packed } }
+  ATTR (copy ((struct A *)(1, 0))) int m_pa_1_0; // { dg-warning "attribute 
ignored" "" { target default_packed } }
+  ATTR (copy ((struct A *)(0, 1))) long m_pa_0_1; // { dg-warning "attribute 
ignored" "" { target default_packed } }
 
-  ATTR (copy (*(struct A *)0)) short m_xpa_0;
-  ATTR (copy (*(struct A *)(1, 0))) int m_xpa_1_0;
-  ATTR (copy (*(struct A *)(0, 1))) long m_xpa_0_1;
+  ATTR (copy (*(struct A *)0)) short m_xpa_0; // { dg-warning "attribute 
ignored" "" { target default_packed } }
+  ATTR (copy (*(struct A *)(1, 0))) int m_xpa_1_0; // { dg-warning "attribute 
ignored" "" { target default_packed } }
+  ATTR (copy (*(struct A *)(0, 1))) long m_xpa_0_1; // { dg-warning "attribute 
ignored" "" { target default_packed } }
 
-  ATTR (copy (((struct A *)0)[0])) short m_arpa_0;
-  ATTR (copy (((struct A *)(1, 0))[0])) int m_arpa_1_0;
-  ATTR (copy (((struct A *)(0, 1))[0])) long m_arpa_0_1;
+  ATTR (copy (((struct A *)0)[0])) short m_arpa_0; // { dg-warning "attribute 
ignored" "" { target default_packed } }
+  ATTR (copy (((struct A *)(1, 0))[0])) int m_arpa_1_0; // { dg-warning 
"attribute ignored" "" { target default_packed } }
+  ATTR (copy (((struct A *)(0, 1))[0])) long m_arpa_0_1; // { dg-warning 
"attribute ignored" "" { target default_packed } }
 
-  ATTR (copy (a)) short m_a;
-  ATTR (copy (b.a)) int m_b_a;
-  ATTR (copy (b.pa)) long m_b_pa;
-  ATTR (copy (b.ra)) long m_b_ra;
+  ATTR (copy (a)) short m_a; // { dg-warning "attribute ignored" "" { target 
default_packed } }
+  ATTR (copy (b.a)) int m_b_a; // { dg-warning "attribute ignored" "" { target 
default_packed } }
+  ATTR (copy (b.pa)) long m_b_pa; // { dg-warning "attribute ignored" "" { 
target default_packed } }
+  ATTR (copy (b.ra)) long m_b_ra; // { dg-warning "attribute ignored" "" { 
target default_packed } }
 
-  ATTR (copy (&a)) short m_ara;
-  ATTR (copy (&b.a)) int m_arb_a;
-  ATTR (copy (*b.pa)) long m_xb_pa;
-  ATTR (copy (b.pa[0])) long m_arb_pa;
+  ATTR (copy (&a)) short m_ara; // { dg-warning "attribute ignored" "" { 
target default_packed } }
+  ATTR (copy (&b.a)) int m_arb_a; // { dg-warning "attribute ignored" "" { 
target default_packed } }
+  ATTR (copy (*b.pa)) long m_xb_pa; // { dg-warning "attribute ignored" "" { 
target default_packed } }
+  ATTR (copy (b.pa[0])) long m_arb_pa; // { dg-warning "attribute ignored" "" 
{ target default_packed } }
 
-  ATTR (copy (*pa)) short m_xpa;
-  ATTR (copy (pa[0])) short m_arpa;
+  ATTR (copy (*pa)) short m_xpa; // { dg-warning "attribute ignored" "" { 
target default_packed } }
+  ATTR (copy (pa[0])) short m_arpa; // { dg-warning "attribute ignored" "" { 
target default_packed } }
 
-  ATTR (copy (ra)) short m_ra;
+  ATTR (copy (ra)) short m_ra; // { dg-warning "attribute ignored" "" { target 
default_packed } }
 
-  ATTR (copy (ab[0].a)) int m_arab_a;
-  ATTR (copy (ab[1].pa)) long m_arab_pa;
-  ATTR (copy (*ab[2].pa)) int m_xarab_pa;
+  ATTR (copy (ab[0].a)) int m_arab_a; // { dg-warning "attribute ignored" "" { 
target default_packed } }
+  ATTR (copy (ab[1].pa)) long m_arab_pa; // { dg-warning "attribute ignored" 
"" { target default_packed } }
+  ATTR (copy (*ab[2].pa)) int m_xarab_pa; // { dg-warning "attribute ignored" 
"" { target default_packed } }
   ATTR (copy (ab[3].pa->bf)) unsigned int m_arab_pa_bf: 1;
   ATTR (copy (ab[4].ra.bf)) unsigned int m_arab_ra_bf: 1;
 
-  ATTR (copy (pb->a)) int m_pb_a;
-  ATTR (copy (pb->pa)) long m_pb_pa;
-  ATTR (copy (*pb->pa)) int m_xpb_pa;
+  ATTR (copy (pb->a)) int m_pb_a; // { dg-warning "attribute ignored" "" { 
target default_packed } }
+  ATTR (copy (pb->pa)) long m_pb_pa; // { dg-warning "attribute ignored" "" { 
target default_packed } }
+  ATTR (copy (*pb->pa)) int m_xpb_pa; // { dg-warning "attribute ignored" "" { 
target default_packed } }
   ATTR (copy (pb->pa->bf)) unsigned int

Re: [PATCH][stage1] Remove conditionals around free()

[Jerry D via Gcc-patches]

On 3/1/23 4:07 PM, Steve Kargl via Fortran wrote:

On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via Fortran 
wrote:

  libgfortran/caf/single.c |6 ++
  libgfortran/io/async.c   |6 ++
  libgfortran/io/format.c  |3 +--
  libgfortran/io/transfer.c|6 ++
  libgfortran/io/unix.c|3 +--


The Fortran ones are OK.



The only question I have: Is free posix compliant on all platforms?

For example ming64 or mac?  It seems sometimes we run into things like 
this once in a while.


Otherwise I have no issue at all.  It is a lot cleaner.

Jerry

[COMMITTED] testsuite: Fix gcc.dg/attr-copy-6.c for user-label-prefixed targets

[Hans-Peter Nilsson via Gcc-patches]

Trivia: I copied that ASMNAME construct from the
18-year-minus-a-month old commit of r0-66993-gc5221531453e02,
where it fixed a similar testsuite error.  Committed as obvious.

-- >8 --
This fixes:
 Running /x/gcc/testsuite/gcc.dg/dg.exp ...
 ...
 FAIL: gcc.dg/attr-copy-6.c (test for excess errors)
for cris-elf, where gcc.log has:
Excess errors:
/x/gcc/testsuite/gcc.dg/attr-copy-6.c:91:3: error: 'fnoreturn_alias' aliased to 
undefined symbol 'fnoreturn_name'

Asm-declared identifiers need to prepend __USER_LABEL_PREFIX__
to the asm-name, something which is often overlooked because
it's empty for most targets.  N.B: attribute-alias does not need
the same treatment.  The identical construct added here, is in
several tests.

* gcc.dg/attr-copy-6.c: Prefix asm-declared name with
__USER_LABEL_PREFIX__.
---
 gcc/testsuite/gcc.dg/attr-copy-6.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/attr-copy-6.c 
b/gcc/testsuite/gcc.dg/attr-copy-6.c
index cf578bddb1b0..30a1317bf928 100644
--- a/gcc/testsuite/gcc.dg/attr-copy-6.c
+++ b/gcc/testsuite/gcc.dg/attr-copy-6.c
@@ -9,6 +9,10 @@
 #define ATTR(...)   __attribute__ ((__VA_ARGS__))
 #define ASRT(expr)   _Static_assert (expr, #expr)
 
+#define ASMNAME(cname)  ASMNAME2 (__USER_LABEL_PREFIX__, cname)
+#define ASMNAME2(prefix, cname) STRING (prefix) cname
+#define STRING(x)#x
+
 /* Variable that is local to this translation unit but that can
be modified from other units by calling reset_unit_local().  */
 static int unit_local;
@@ -79,7 +83,7 @@ extern _Noreturn void fnoreturn (void);
 
 extern __typeof (fnoreturn)
   ATTR (visibility ("hidden"))
-  fnoreturn __asm__ ("fnoreturn_name");
+  fnoreturn __asm__ (ASMNAME ("fnoreturn_name"));
 
 void fnoreturn (void)
 {
-- 
2.30.2

Re: [PATCH, gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628]

[Steve Kargl via Gcc-patches]

On Thu, Mar 02, 2023 at 01:07:32AM +0100, Bernhard Reutner-Fischer wrote:
> On Wed, 1 Mar 2023 07:39:40 -0800
> Steve Kargl via Gcc-patches  wrote:
> 
> > In fact, Hollerith should be hidden behind a -fallow-hollerith
> > option and added to -std=legacy.
> 
> While i'd be all for that, in my mind this will block off literally all
> consultants and quite some scientists unless we error out
> with a specific hint to an option that re-enable this.
> 
> So yea, but please forgivingly for the decades to come?
> 

It has already been decades.  It seems to me that only
way to motivate people to fix their code is to nag.

Hollerith is pre-F77 era code.  gfortran already provide a
warning.  The warning should be made into an error, and yes,
it can point to -fallow-hollerith.  The option would downgrade
the error to a warning.  The only way to suppress the warning
is to suppress all warnings with -w.   See -fallow-invalid-boz.

% cat > a.f90
program foo! free-form source code is post-f77.
   real :: b = 4H1234  ! No code, in particular, legacy has 
   print *, b  ! initialization expressions.
end program foo
% gfcx -o z a.f90
a.f90:2:14:

2 |real :: b = 4H1234
  |  1
Warning: Extension: Conversion from HOLLERITH to REAL(4) at (1)
a.f90:2:18:

2 |real :: b = 4H1234
  |  1
Warning: Legacy Extension: Hollerith constant at (1)

-- 
Steve

Re: [PATCH 1/2] testsuite: Fix analyzer errors for newlib-errno

[Hans-Peter Nilsson via Gcc-patches]

> Date: Thu, 2 Mar 2023 01:37:12 +0100
> From: Bernhard Reutner-Fischer 

> On Thu, 2 Mar 2023 00:54:33 +0100
> Hans-Peter Nilsson  wrote:
> 
> > > Date: Thu, 2 Mar 2023 00:23:36 +0100
> > > From: Bernhard Reutner-Fischer   
> > 
> > > On Wed, 1 Mar 2023 17:02:31 +0100
> > > Hans-Peter Nilsson via Gcc-patches  wrote:
> > >   
> > > > > From: Hans-Peter Nilsson 
> > > > > Date: Wed, 1 Mar 2023 16:36:46 +0100
> > > >   
> > > > > ... this is what I intend to commit later
> > > > > today, just keeping the added comment as brief as
> > > > > reasonable:
> > > > 
> > > > Except I see the hook for errno magic took care of
> > > > gcc.dg/analyzer/flex-without-call-summaries.c so I'll add
> > > > that to the list of handled "FAIL"s in the commit log.  Yay.  
> > > 
> > > But in the end it means we'll have to keep _[_]+errno{,_location} 'til
> > > we bump requirements or 10, 20 years or the end of the universe,
> > > doesn't it.
> > > Way fancy.  
> > 
> > Not sure I see your point?  The (other) identifiers are already there.
> 
> I'm certainly not opposed to this partiular identifier, no.
> 
> > 
> > (And you do realize that this is in the analyzer part of gcc, right?)
> 
> And yes, i'm well aware this is "just" the analyzer -- which is unfair
> to state like that and does not mean to imply any inferiority --
> particular in this spot.

(Your statement and values; it can be read as you putting
that as mine, which I hope was not intended.)  My point is
that the presence of those identifiers does not affects an
ABI or code-generating parts of gcc.  All the identifiers
are present for all targets - for all invocation of the
analyzer.  If that passes a nuisance threshold, it seems it
can be changed easily, say by moving it to a target-hook by
someone who cares deeply enough.

> Just let's ditch any specialcased identifier which was superseded
> reliably ASAP?

I'm certainly not opposed to *that*
brgds, H-P

Re: [PATCH][stage1] Remove conditionals around free()

[Andrew Pinski via Gcc-patches]

On Wed, Mar 1, 2023 at 3:52 PM Bernhard Reutner-Fischer
 wrote:
>
> On Wed, 1 Mar 2023 14:59:44 -0800
> Andrew Pinski  wrote:
>
> > On Wed, Mar 1, 2023 at 1:31 PM Bernhard Reutner-Fischer via Fortran
> >  wrote:
> > >
> > > Hi!
> > >
> > > Mere cosmetics.
> > >
> > > - if (foo != NULL)
> > > free (foo);
> > >
> > > With the caveat that coccinelle ruins replacement whitespace or i'm
> > > uneducated enough to be unable to _not_ run the diff through
> > >  sed -e 's/^+\([[:space:]]*\)free(/+\1free (/'
> > > at least. If anybody knows how to improve replacement whitespace,
> > > i'd be interrested but didn't look nor ask. ISTM that leading
> > > whitespace is somewhat ruined, too, so beware (8 spaces versus tab as
> > > far as i have spot-checked).
> > >
> > > Would touch
> > >  gcc/ada/rtinit.c |3 +--
> >
> >
>
> It's funny how you apparently did not comment that hunk in the end ;)

No, I was just trying to make it look seperate from the intl hunk really.


>
> > >  intl/bindtextdom.c   |3 +--
> > >  intl/loadmsgcat.c|6 ++
> > >  intl/localcharset.c  |3 +--
> >
> > intl is imported from glibc, though I don't know we have updated it in
> > recent years from glibc.
>
> i don't think we did, overdue, as we (probably) all know.
> OTOH i'm thankful that we don't have submodules but a plain, manageable
> repo. Of course that comes with a burden, which is nil if ignored
> throughout. Doesn't always pay out too well longterm if nobody
> (voluntarily) is in due charge.

I looked and nobody has filed a bug report about merging from recent
glibc sources for intl. Most likely because not many folks use code
from intl any more as glibc is main libc that people use for
development these days in GCC world.

>
> > >  zlib/contrib/minizip/unzip.c |2 +-
> > >  zlib/contrib/minizip/zip.c   |2 +-
> > >  zlib/examples/enough.c   |6 ++
> > >  zlib/examples/gun.c  |2 +-
> > >  zlib/examples/gzjoin.c   |3 +--
> > >  zlib/examples/gzlog.c|6 ++
> >
> > zlib is definitely imported from zlib upstream.
> > So it might be good to check if we could import a new version and see
> > if it still works instead.

updating zlib is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105404 .

Thanks,
Andrew

>
> From a meta POV, i wonder where the trailing space in the subject comes
> from, looking at e.g.:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/date.html#613110
> I think and hope that the newer(?) ones by
> https://inbox.sourceware.org/gcc-patches/?t=xyz do not exhibit these
> invented trailing blanks nobody ever wrote for real, does it.
>
> Thanks for reminding me of intl and it's outdatedness, although i
> certainly don't have ambition to do anything about it for sure.
> I didn't care 15 or 20 years ago and nowadays i'd call that attitude a
> tradition, at least ATM ;) TBH i initially had only considered gcc/ but
> somehow found that unfair. Great idea that inclusion was.
>
> thanks,
>
> > > 4) i most likely will not remember to split it apart and send proper
> > >patches, tested patches, in stage 1 to maintainers proper, so if
> > >anyone feels like pursuing this, be my guest. I thought i'd just
> > >mention it.
> > >
> > > cheers,
>

Re: [PATCH 1/2] testsuite: Fix analyzer errors for newlib-errno

[Bernhard Reutner-Fischer via Gcc-patches]

On Thu, 2 Mar 2023 00:54:33 +0100
Hans-Peter Nilsson  wrote:

> > Date: Thu, 2 Mar 2023 00:23:36 +0100
> > From: Bernhard Reutner-Fischer   
> 
> > On Wed, 1 Mar 2023 17:02:31 +0100
> > Hans-Peter Nilsson via Gcc-patches  wrote:
> >   
> > > > From: Hans-Peter Nilsson 
> > > > Date: Wed, 1 Mar 2023 16:36:46 +0100
> > >   
> > > > ... this is what I intend to commit later
> > > > today, just keeping the added comment as brief as
> > > > reasonable:
> > > 
> > > Except I see the hook for errno magic took care of
> > > gcc.dg/analyzer/flex-without-call-summaries.c so I'll add
> > > that to the list of handled "FAIL"s in the commit log.  Yay.  
> > 
> > But in the end it means we'll have to keep _[_]+errno{,_location} 'til
> > we bump requirements or 10, 20 years or the end of the universe,
> > doesn't it.
> > Way fancy.  
> 
> Not sure I see your point?  The (other) identifiers are already there.

I'm certainly not opposed to this partiular identifier, no.

> 
> (And you do realize that this is in the analyzer part of gcc, right?)

And yes, i'm well aware this is "just" the analyzer -- which is unfair
to state like that and does not mean to imply any inferiority --
particular in this spot.

Just let's ditch any specialcased identifier which was superseded
reliably ASAP?

thanks,

Re: [PATCH, gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628]

[Bernhard Reutner-Fischer via Gcc-patches]

On Wed, 1 Mar 2023 07:39:40 -0800
Steve Kargl via Gcc-patches  wrote:

> In fact, Hollerith should be hidden behind a -fallow-hollerith
> option and added to -std=legacy.

While i'd be all for that, in my mind this will block off literally all
consultants and quite some scientists unless we error out
with a specific hint to an option that re-enable this.

So yea, but please forgivingly for the decades to come?

HTH,

Re: [PATCH][stage1] Remove conditionals around free()

[Steve Kargl via Gcc-patches]

On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via Fortran 
wrote:
>  libgfortran/caf/single.c |6 ++
>  libgfortran/io/async.c   |6 ++
>  libgfortran/io/format.c  |3 +--
>  libgfortran/io/transfer.c|6 ++
>  libgfortran/io/unix.c|3 +--

The Fortran ones are OK.

-- 
Steve

Re: [PATCH, gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628]

[Bernhard Reutner-Fischer via Gcc-patches]

On Wed, 1 Mar 2023 10:40:15 +0100
Tobias Burnus  wrote:

> Hi,
> 
> Please CC fortran@gcc for Fortran patches.

> > --- a/gcc/fortran/target-memory.cc
> > +++ b/gcc/fortran/target-memory.cc
> > @@ -417,10 +417,13 @@ gfc_interpret_float (int kind, unsigned char *buffer, 
> > size_t buffer_size,
> >   {
> > gfc_set_model_kind (kind);
> > mpfr_init (real);
> > -  gfc_conv_tree_to_mpfr (real,
> > -  native_interpret_expr (gfc_get_real_type (kind),
> > - buffer, buffer_size));
> >
> > +  tree source  = native_interpret_expr (gfc_get_real_type (kind), buffer,

s/source  = native/source = native/

additionally to moving mpfr_init around and the other comments.
Please send an updated, regtested patch?
thanks && cheers,

Re: [PATCH 1/2] testsuite: Fix analyzer errors for newlib-errno

[Hans-Peter Nilsson via Gcc-patches]

> Date: Thu, 2 Mar 2023 00:23:36 +0100
> From: Bernhard Reutner-Fischer 

> On Wed, 1 Mar 2023 17:02:31 +0100
> Hans-Peter Nilsson via Gcc-patches  wrote:
> 
> > > From: Hans-Peter Nilsson 
> > > Date: Wed, 1 Mar 2023 16:36:46 +0100  
> > 
> > > ... this is what I intend to commit later
> > > today, just keeping the added comment as brief as
> > > reasonable:  
> > 
> > Except I see the hook for errno magic took care of
> > gcc.dg/analyzer/flex-without-call-summaries.c so I'll add
> > that to the list of handled "FAIL"s in the commit log.  Yay.
> 
> But in the end it means we'll have to keep _[_]+errno{,_location} 'til
> we bump requirements or 10, 20 years or the end of the universe,
> doesn't it.
> Way fancy.

Not sure I see your point?  The (other) identifiers are already there.

(And you do realize that this is in the analyzer part of gcc, right?)

brgds, H-P

Re: [PATCH][stage1] Remove conditionals around free()

[Bernhard Reutner-Fischer via Gcc-patches]

On Wed, 1 Mar 2023 14:59:44 -0800
Andrew Pinski  wrote:

> On Wed, Mar 1, 2023 at 1:31 PM Bernhard Reutner-Fischer via Fortran
>  wrote:
> >
> > Hi!
> >
> > Mere cosmetics.
> >
> > - if (foo != NULL)
> > free (foo);
> >
> > With the caveat that coccinelle ruins replacement whitespace or i'm
> > uneducated enough to be unable to _not_ run the diff through
> >  sed -e 's/^+\([[:space:]]*\)free(/+\1free (/'
> > at least. If anybody knows how to improve replacement whitespace,
> > i'd be interrested but didn't look nor ask. ISTM that leading
> > whitespace is somewhat ruined, too, so beware (8 spaces versus tab as
> > far as i have spot-checked).
> >
> > Would touch
> >  gcc/ada/rtinit.c |3 +--  
> 
> 

It's funny how you apparently did not comment that hunk in the end ;)

> >  intl/bindtextdom.c   |3 +--
> >  intl/loadmsgcat.c|6 ++
> >  intl/localcharset.c  |3 +--  
> 
> intl is imported from glibc, though I don't know we have updated it in
> recent years from glibc.

i don't think we did, overdue, as we (probably) all know.
OTOH i'm thankful that we don't have submodules but a plain, manageable
repo. Of course that comes with a burden, which is nil if ignored
throughout. Doesn't always pay out too well longterm if nobody
(voluntarily) is in due charge.

> >  zlib/contrib/minizip/unzip.c |2 +-
> >  zlib/contrib/minizip/zip.c   |2 +-
> >  zlib/examples/enough.c   |6 ++
> >  zlib/examples/gun.c  |2 +-
> >  zlib/examples/gzjoin.c   |3 +--
> >  zlib/examples/gzlog.c|6 ++  
> 
> zlib is definitely imported from zlib upstream.
> So it might be good to check if we could import a new version and see
> if it still works instead.

From a meta POV, i wonder where the trailing space in the subject comes
from, looking at e.g.:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/date.html#613110
I think and hope that the newer(?) ones by
https://inbox.sourceware.org/gcc-patches/?t=xyz do not exhibit these
invented trailing blanks nobody ever wrote for real, does it.

Thanks for reminding me of intl and it's outdatedness, although i
certainly don't have ambition to do anything about it for sure.
I didn't care 15 or 20 years ago and nowadays i'd call that attitude a
tradition, at least ATM ;) TBH i initially had only considered gcc/ but
somehow found that unfair. Great idea that inclusion was.

thanks,

> > 4) i most likely will not remember to split it apart and send proper
> >patches, tested patches, in stage 1 to maintainers proper, so if
> >anyone feels like pursuing this, be my guest. I thought i'd just
> >mention it.
> >
> > cheers,  

Re: [PATCH] Fix PR 108980: note without warning due to array bounds check

[Jakub Jelinek via Gcc-patches]

On Wed, Mar 01, 2023 at 03:25:00PM -0800, Andrew Pinski via Gcc-patches wrote:
> The problem here is after r13-4748-g2a27ae32fabf85, in some
> cases we were calling inform without a corresponding warning.
> This changes the logic such that we only cause that to happen
> if there was a warning happened before hand.
> 
> OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
> 
> gcc/ChangeLog:
> 
>   PR tree-optmization/108980

s/optmization/optimization/

>   * gimple-array-bounds.cc (array_bounds_checker::check_array_ref):
>   Reorgnize the call to warning for not strict flexible arrays
>   to be before the check of warned.
> ---
>  gcc/gimple-array-bounds.cc | 41 --
>  1 file changed, 26 insertions(+), 15 deletions(-)
> 
> diff --git a/gcc/gimple-array-bounds.cc b/gcc/gimple-array-bounds.cc
> index 66fd46e9b6c..469baecaa1a 100644
> --- a/gcc/gimple-array-bounds.cc
> +++ b/gcc/gimple-array-bounds.cc
> @@ -397,27 +397,38 @@ array_bounds_checker::check_array_ref (location_t 
> location, tree ref,
>  "of an interior zero-length array %qT")),
>low_sub, artype);
>  
> -  if (warned || out_of_bound)
> +  if (warned && dump_file && (dump_flags & TDF_DETAILS))
>  {
> -  if (warned && dump_file && (dump_flags & TDF_DETAILS))
> +  fprintf (dump_file, "Array bound warning for ");
> +  dump_generic_expr (MSG_NOTE, TDF_SLIM, ref);
> +  fprintf (dump_file, "\n");
> +}
> +
> +   /* Issue warnings for -Wstrict-flex-arrays according to the level of
> +  flag_strict_flex_arrays.  */
> +  if (out_of_bound && warn_strict_flex_arrays
> +  && (sam == special_array_member::trail_0
> +   || sam == special_array_member::trail_1
> +   || sam == special_array_member::trail_n)
> +  && DECL_NOT_FLEXARRAY (afield_decl))
> +{
> +  bool warned1;
> +  warned1 = warning_at (location, OPT_Wstrict_flex_arrays,

Why the separate declaration and assignment?
  bool warned1
= warning_at (location, OPT_Wstrict_flex_arrays,
  "trailing array %qT should not be used as a flexible "
  "array member", artype);
looks better.

> +"trailing array %qT should not be used as "
> +"a flexible array member",
> +artype);
> +
> +  if (warned1 && dump_file && (dump_flags & TDF_DETAILS))
>   {
> -   fprintf (dump_file, "Array bound warning for ");
> +   fprintf (dump_file, "Not Flexible array bound warning for ");

Why the capitalization of F ?
Though, I think the wording isn't best anyway.
Perhaps
"Trailing non flexible-like array bound warning for"
?  That is what DECL_NOT_FLEXARRAY is after all, trailing array which
isn't handled like flexible array.

> dump_generic_expr (MSG_NOTE, TDF_SLIM, ref);
> fprintf (dump_file, "\n");
>   }
> +  warned |= warned1;
> +}
>  

Jakub

[PATCH] Fix PR 108980: note without warning due to array bounds check

[Andrew Pinski via Gcc-patches]

The problem here is after r13-4748-g2a27ae32fabf85, in some
cases we were calling inform without a corresponding warning.
This changes the logic such that we only cause that to happen
if there was a warning happened before hand.

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

gcc/ChangeLog:

PR tree-optmization/108980
* gimple-array-bounds.cc (array_bounds_checker::check_array_ref):
Reorgnize the call to warning for not strict flexible arrays
to be before the check of warned.
---
 gcc/gimple-array-bounds.cc | 41 --
 1 file changed, 26 insertions(+), 15 deletions(-)

diff --git a/gcc/gimple-array-bounds.cc b/gcc/gimple-array-bounds.cc
index 66fd46e9b6c..469baecaa1a 100644
--- a/gcc/gimple-array-bounds.cc
+++ b/gcc/gimple-array-bounds.cc
@@ -397,27 +397,38 @@ array_bounds_checker::check_array_ref (location_t 
location, tree ref,
   "of an interior zero-length array %qT")),
 low_sub, artype);
 
-  if (warned || out_of_bound)
+  if (warned && dump_file && (dump_flags & TDF_DETAILS))
 {
-  if (warned && dump_file && (dump_flags & TDF_DETAILS))
+  fprintf (dump_file, "Array bound warning for ");
+  dump_generic_expr (MSG_NOTE, TDF_SLIM, ref);
+  fprintf (dump_file, "\n");
+}
+
+   /* Issue warnings for -Wstrict-flex-arrays according to the level of
+  flag_strict_flex_arrays.  */
+  if (out_of_bound && warn_strict_flex_arrays
+  && (sam == special_array_member::trail_0
+ || sam == special_array_member::trail_1
+ || sam == special_array_member::trail_n)
+  && DECL_NOT_FLEXARRAY (afield_decl))
+{
+  bool warned1;
+  warned1 = warning_at (location, OPT_Wstrict_flex_arrays,
+  "trailing array %qT should not be used as "
+  "a flexible array member",
+  artype);
+
+  if (warned1 && dump_file && (dump_flags & TDF_DETAILS))
{
- fprintf (dump_file, "Array bound warning for ");
+ fprintf (dump_file, "Not Flexible array bound warning for ");
  dump_generic_expr (MSG_NOTE, TDF_SLIM, ref);
  fprintf (dump_file, "\n");
}
+  warned |= warned1;
+}
 
-  /* issue warnings for -Wstrict-flex-arrays according to the level of
-flag_strict_flex_arrays.  */
-  if ((out_of_bound && warn_strict_flex_arrays)
- && (((sam == special_array_member::trail_0)
-   || (sam == special_array_member::trail_1)
-   || (sam == special_array_member::trail_n))
- && DECL_NOT_FLEXARRAY (afield_decl)))
- warned = warning_at (location, OPT_Wstrict_flex_arrays,
-  "trailing array %qT should not be used as "
-  "a flexible array member",
-  artype);
-
+  if (warned)
+{
   /* Avoid more warnings when checking more significant subscripts
 of the same expression.  */
   ref = TREE_OPERAND (ref, 0);
-- 
2.31.1

Re: [PATCH 1/2] testsuite: Fix analyzer errors for newlib-errno

[Bernhard Reutner-Fischer via Gcc-patches]

On Wed, 1 Mar 2023 17:02:31 +0100
Hans-Peter Nilsson via Gcc-patches  wrote:

> > From: Hans-Peter Nilsson 
> > Date: Wed, 1 Mar 2023 16:36:46 +0100  
> 
> > ... this is what I intend to commit later
> > today, just keeping the added comment as brief as
> > reasonable:  
> 
> Except I see the hook for errno magic took care of
> gcc.dg/analyzer/flex-without-call-summaries.c so I'll add
> that to the list of handled "FAIL"s in the commit log.  Yay.

But in the end it means we'll have to keep _[_]+errno{,_location} 'til
we bump requirements or 10, 20 years or the end of the universe,
doesn't it.
Way fancy.

Re: [PATCH][stage1] Remove conditionals around free()

[Andrew Pinski via Gcc-patches]

On Wed, Mar 1, 2023 at 1:31 PM Bernhard Reutner-Fischer via Fortran
 wrote:
>
> Hi!
>
> Mere cosmetics.
>
> - if (foo != NULL)
> free (foo);
>
> With the caveat that coccinelle ruins replacement whitespace or i'm
> uneducated enough to be unable to _not_ run the diff through
>  sed -e 's/^+\([[:space:]]*\)free(/+\1free (/'
> at least. If anybody knows how to improve replacement whitespace,
> i'd be interrested but didn't look nor ask. ISTM that leading
> whitespace is somewhat ruined, too, so beware (8 spaces versus tab as
> far as i have spot-checked).
>
> Would touch
>  gcc/ada/rtinit.c |3 +--


>  intl/bindtextdom.c   |3 +--
>  intl/loadmsgcat.c|6 ++
>  intl/localcharset.c  |3 +--

intl is imported from glibc, though I don't know we have updated it in
recent years from glibc.

>  libbacktrace/xztest.c|9 +++--
>  libbacktrace/zstdtest.c  |9 +++--
>  libbacktrace/ztest.c |9 +++--
>  libgfortran/caf/single.c |6 ++
>  libgfortran/io/async.c   |6 ++
>  libgfortran/io/format.c  |3 +--
>  libgfortran/io/transfer.c|6 ++
>  libgfortran/io/unix.c|3 +--
>  libgo/runtime/go-setenv.c|6 ++
>  libgo/runtime/go-unsetenv.c  |3 +--
>  libgomp/target.c |3 +--


>  libiberty/concat.c   |3 +--
This code is really old and only has gotten some modernization in
recent years (post 8 years ago).

>  zlib/contrib/minizip/unzip.c |2 +-
>  zlib/contrib/minizip/zip.c   |2 +-
>  zlib/examples/enough.c   |6 ++
>  zlib/examples/gun.c  |2 +-
>  zlib/examples/gzjoin.c   |3 +--
>  zlib/examples/gzlog.c|6 ++

zlib is definitely imported from zlib upstream.
So it might be good to check if we could import a new version and see
if it still works instead.

Thanks,
Andrew Pinski

>
> coccinelle script and invocation inline.
> Would need to be split for the respective maintainers and run through
> mklog with subject changelog and should of course be compiled and
> tested before that.
>
> Remarks:
> 1) We should do this in if-conversion (?) on our own.
>I suppose. Independently of -fdelete-null-pointer-checks
> 2) Maybe not silently, but raise language awareness nowadays.
>By now it's been a long time since this was first mandated.
> 3) fallout from looking at something completely different
> 4) i most likely will not remember to split it apart and send proper
>patches, tested patches, in stage 1 to maintainers proper, so if
>anyone feels like pursuing this, be my guest. I thought i'd just
>mention it.
>
> cheers,

Re: [PATCH][stage1] Remove conditionals around free()

[Bernhard Reutner-Fischer via Gcc-patches]

On Wed, 1 Mar 2023 22:58:59 +0100
Bernhard Reutner-Fischer  wrote:

> On Wed, 1 Mar 2023 22:28:56 +0100
> Bernhard Reutner-Fischer  wrote:
> 
> > Remarks:
> > 1) We should do this in if-conversion (?) on our own.
> >I suppose. Independently of -fdelete-null-pointer-checks  
> 
> and iff we can prove that ptr was NULL when passed to free(ptr) then we
> can elide the call, of course. Likewise for realloc(ptr, 0), obviously.
> [or reallocarray -- yikes -- if nmemb == 0 || size == 0]
> 
> But that would probably be a ranger call in DCE, i guess. Didn't look.
> thanks,

And, if under C, we rule out validity of a life ptr as a return value of
malloc(0),
---8<---
 If size is 0, either:

A null pointer shall be returned [CX] [Option Start]  and errno may be set to 
an implementation-defined value, [Option End] or

A pointer to the allocated space shall be returned. The application shall 
ensure that the pointer is not used to access an object.
---8<---
Where CX == "Extension to the ISO C standard" 
https://pubs.opengroup.org/onlinepubs/9699919799/help/codes.html#CX

then one might be baffled that malloc(0) still is underspecified or
at least unpleasantly specified WRT realloc(NULL,0) after all these
years in the wild.

The exact quote from CX is
---8<---
[CX] [Option Start] Extension to the ISO C standard [Option End]
The functionality described is an extension to the ISO C standard. Application 
developers may make use of an extension as it is supported on all 
POSIX.1-2017-conforming systems.

With each function or header from the ISO C standard, a statement to the effect 
that "any conflict is unintentional" is included. That is intended to refer to 
a direct conflict. POSIX.1-2017 acts in part as a profile of the ISO C 
standard, and it may choose to further constrain behaviors allowed to vary by 
the ISO C standard. Such limitations and other compatible differences are not 
considered conflicts, even if a CX mark is missing. The markings are for 
information only.

Where additional semantics apply to a function or header, the material is 
identified by use of the CX margin legend.

---8<---
So, what in the end this all gives is IMHO that natural stuff like valid
C or C++ can only borderline elide any of these calls which hinders
everyone and helps nobody for real IMHO. Doesn't it.

That's how conceptually devirt does it's thing for just a very
particular flavour of the family and rightfully leaves the rest alone,
which really is a pity IMHO.

But that's enough as far as an unfounded rant goes for today and should
probably be addressed elsewhere either way.

So, please remind me, why, again, does C do it's life ptr thing, short
of an optimisation barrier?

thanks,

Re: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

[juzhe.zhong]

>> Does the eventual value set by ADJUST_BYTESIZE equal the real number of
>> bytes loaded by vlm.v and stored by vstm.v (after the appropriate vsetvl)?
>> Or is the GCC size larger in some cases than the number of bytes
>> loaded and stored?
For VNx1BI,VNx2BI,VNx4BI,VNx8BI, we allocate the larger size of memory or stack 
for register spillling
according to ADJUST_BYTESIZE. 
After appropriate vsetvl, VNx1BI is loaded/stored 1/8 of ADJUST_BYTESIZE 
(vsetvl e8mf8).
After appropriate vsetvl, VNx2BI is loaded/stored 2/8 of ADJUST_BYTESIZE 
(vsetvl e8mf2).
After appropriate vsetvl, VNx4BI is loaded/stored 4/8 of ADJUST_BYTESIZE 
(vsetvl e8mf4).
After appropriate vsetvl, VNx8BI is loaded/stored 8/8 of ADJUST_BYTESIZE 
(vsetvl e8m1).

Note: except these 4 machine modes, all other machine modes of RVV, 
ADJUST_BYTESIZE
are equal to the real number of bytes of load/store instruction that RVV ISA 
define.

Well, as I said, it's fine that we allocated larger memory for 
VNx1BI,VNx2BI,VNx4BI, 
we can emit appropriate vsetvl to gurantee the correctness in RISC-V backward 
according 
to the machine_mode as long as long GCC didn't do the incorrect elimination in 
middle-end.

Besides, poly (1,1) is 1/8 of machine vector-length which is already really a 
small number,
which is the real number bytes loaded/stored for VNx8BI.
You can say VNx1BI, VNx2BI, VNx4BI are consuming larger memory than we actually 
load/stored by appropriate vsetvl
since they are having same ADJUST_BYTESIZE as VNx8BI. However, I think it's 
totally fine so far as long as we can
gurantee the correctness and I think optimizing such memory storage consuming 
is trivial.

>> And does it equal the size of the corresponding LLVM machine type?

Well, for some reason, in case of register spilling, LLVM consume much more 
memory than GCC.
And they always do whole register load/store (a single vector register 
vector-length) for register spilling.
That's another story (I am not going to talk too much about this since it's a 
quite ugly implementation). 
They don't model the types accurately according RVV ISA for register spilling.

In case of normal load/store like:
vbool8_t v2 = *(vbool8_t*)in;  *(vbool8_t*)(out + 100) = v2;
This kind of load/store, their load/stores instructions of codegen are accurate.
Even though their instructions are accurate for load/store accessing behavior, 
I am not sure whether size 
of their machine type is accurate.

For example, in IR presentation: VNx1BI of GCC is represented as vscale x 1 x i1
  VNx2BI of GCC is represented as vscale x 2 x i1
in LLVM IR.
I am not sure the bytesize of  vscale x 1 x i1 and vscale x 2 x i1.
I didn't take a deep a look at it.

I think this question is not that important, no matter whether VNx1BI and 
VNx2BI are modeled accurately in case of ADUST_BYTESIZE
in GCC or  vscale x 1 x i1 and vscale x 2 x i1 are modeled accurately in case 
of  their bytesize,
I think as long as we can emit appropriate vsetvl + vlm/vsm, it's totally fine 
for RVV  even though in some case, their memory allocation
is not accurate in compiler.


juzhe.zh...@rivai.ai
 
From: Richard Sandiford
Date: 2023-03-02 00:14
To: Li\, Pan2
CC: juzhe.zhong\@rivai.ai; rguenther; gcc-patches; Pan Li; kito.cheng
Subject: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment
"Li, Pan2"  writes:
> Thanks all for so much valuable and helpful materials.
>
> As I understand (Please help to correct me if any mistake.), for the VNx*BI 
> (aka, 1, 2, 4, 8, 16, 32, 64),
> the precision and mode size need to be adjusted as below.
>
> Precision size [1, 2, 4, 8, 16, 32, 64]
> Mode size [1, 1, 1, 1, 2, 4, 8]
>
> Given that, if we ignore the self-test failure, only the adjust_precision 
> part is able to fix the bug I mentioned.
> The genmode will first get the precision, and then leverage the mode_size = 
> exact_div / 8 to generate.
> Meanwhile, it also provides the adjust_mode_size after the mode_size 
> generation.
>
> The riscv parts has the mode_size_adjust already and the value of mode_size 
> will be overridden by the adjustments.
 
Ah, OK!  In that case, would the following help:
 
Turn:
 
  mode_size[E_%smode] = exact_div (mode_precision[E_%smode], BITS_PER_UNIT);
 
into:
 
  if (!multiple_p (mode_precision[E_%smode], BITS_PER_UNIT,
   &mode_size[E_%smode]))
mode_size[E_%smode] = -1;
 
where -1 is an "obviously wrong" value.
 
Ports that might hit the -1 are then responsible for setting the size
later, via ADJUST_BYTESIZE.
 
After all the adjustments are complete, genmodes asserts that no size is
known_eq to -1.
 
That way, target-independent code doesn't need to guess what the
correct behaviour is.
 
Does the eventual value set by ADJUST_BYTESIZE equal the real number of
bytes loaded by vlm.v and stored by vstm.v (after the appropriate vsetvl)?
And does it equal the size of the corresponding LLVM machine type?
Or is the GCC size larger in some cases than the number of bytes
loaded and stored?
 
(You and Juzhe have prob

Re: [PATCH] c++: Add target hook for emit_support_tinfos [PR108883]

[Jason Merrill via Gcc-patches]

On 2/27/23 18:51, Jakub Jelinek wrote:

On Mon, Feb 27, 2023 at 06:26:04PM -0500, Jason Merrill wrote:

The following patch instead adds a target hook which allows the backend
to temporarily tweak registered types such that emit_support_tinfos
emits whatever is needed.


Why handle these types differently from the DFP handling at the end of
emit_support_tinfos?


One thing is that the fallback_* nodes look like a waste to me,
the tinfo decls are mangled right away, and the fallback_* nodes need to be
walked by GC, so I think we could get away even for the decimal tinfos
to just do:
   dfloat32_type_node = make_node (REAL_TYPE);
   emit_support_tinfo_1 (dfloat32_type_node);
   dfloat32_type_node = NULL_TREE;
etc. and drop the fallback stuff.


I think you're right.


If we wanted to do fallback_* even for the _Float*/decltype(0.0bf16)
nodes, which are at least sometimes mangled in target hooks it would
make stuff harder because fallback_* is C++ FE private.

And then there is a question whether we want to emit rtti for
_Float{16,32,64,128}, _Float{32,64,128}x and decltype(0.0bf16) regardless
of whether the target supports them at all or not.
Emitting them always would have an advantage, if say bfloat16_t support
isn't added for aarch64 for GCC 13 (it is still pending review), we wouldn't
need to deal with symbol versioning for it in GCC 14 or later.
On the other side, on some arches some types are very unlikely to be
supported.  And e.g. _Float128x isn't supported on any arch right now.


A good point.  Incidentally, it seems problematic for embedded users 
that all the fundamental type_infos are emitted in the same .o, making 
it hard to link in only the ones you care about.  And new floating-point 
variants add to that problem.  So perhaps until that is addressed, it's 
better to avoid adding a bunch more on targets that don't support them.


Hmm.


Though, if we can get rid of the fallback_* stuff and we wanted to emit
all _Float{16,32,64,128}, _Float{32,64,128}x and decltype(0.0bf16) tinfos
on all arches (or say for now all but _Float128x), we could do it simply
by splitting the fundamentals array in emit_support_tinfos into
one without fallback and one with fallback, put say
 &dfloat32_type_node, &dfloat64_type_node, &dfloat128_type_node,
 &bfloat16_type_node, &float16_type_node, &float32_type_node,
 &float64_type_node, &float128_type_node, &float32x_type_node,
 &float64x_type_node, &float128x_type_node, 0
into the latter and simply handle the NULL case with a temporary fallback,
like:
   tree fallback = NULL_TREE;
   for (ix = 0; fundamentals_with_fallback[ix]; ix++)
 if (*fundamentals_with_fallback[ix])
   emit_support_tinfo_1 (*fundamentals_with_fallback[ix]);
 else
   {
if (fallback == NULL_TREE)
  fallback = make_node (REAL_TYPE);
*fundamentals_with_fallback[ix] = fallback;
emit_support_tinfo_1 (fallback);
*fundamentals_with_fallback[ix] = NULL_TREE;
   }

Jakub

Re: [PATCH] c++: ICE with -Wmismatched-tags and member template [PR106259]

[Marek Polacek via Gcc-patches]

On Wed, Mar 01, 2023 at 04:44:12PM -0500, Jason Merrill wrote:
> On 3/1/23 16:40, Marek Polacek wrote:
> > On Wed, Mar 01, 2023 at 04:30:16PM -0500, Jason Merrill wrote:
> > > On 3/1/23 15:33, Marek Polacek wrote:
> > > > -Wmismatched-tags warns about the (harmless) struct/class mismatch.
> > > > For, e.g.,
> > > > 
> > > > template struct A { };
> > > > class A a;
> > > > 
> > > > it works by adding A to the class2loc hash table while parsing the
> > > > class-head and then, while parsing the elaborate type-specifier, we
> > > > add A.  At the end of c_parse_file we go through the table and
> > > > warn about the class-key mismatches.  In this PR we crash though; we
> > > > have
> > > > 
> > > > template struct A {
> > > >   template struct W { };
> > > > };
> > > > struct A::W w; // #1
> > > > 
> > > > where while parsing A and #1 we've stashed
> > > >  A
> > > >  A::W
> > > >  A::W
> > > > into class2loc.  Then in class_decl_loc_t::diag_mismatched_tags TYPE
> > > > is A::W, and specialization_of gets us A::W, which
> > > > is not in class2loc, so we crash on gcc_assert (cdlguide).  But it's
> > > > OK not to have found A::W, we should just look one "level" up,
> > > > that is, A::W.
> > > > 
> > > > It's important to handle class specializations, so e.g.
> > > > 
> > > > template<>
> > > > struct A {
> > > >   template
> > > >   class W { };
> > > > };
> > > > 
> > > > where W's class-key is different than in the primary template above,
> > > > so we should warn depending on whether we're looking into A
> > > > or into a different instantiation.
> > > > 
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > > > 
> > > > PR c++/106259
> > > > 
> > > > gcc/cp/ChangeLog:
> > > > 
> > > > * parser.cc (class_decl_loc_t::diag_mismatched_tags): If the 
> > > > first
> > > > lookup of SPEC didn't find anything, try to look for
> > > > most_general_template.
> > > > 
> > > > gcc/testsuite/ChangeLog:
> > > > 
> > > > * g++.dg/warn/Wmismatched-tags-11.C: New test.
> > > > ---
> > > >gcc/cp/parser.cc  | 30 
> > > > +++
> > > >.../g++.dg/warn/Wmismatched-tags-11.C | 23 ++
> > > >2 files changed, 47 insertions(+), 6 deletions(-)
> > > >create mode 100644 gcc/testsuite/g++.dg/warn/Wmismatched-tags-11.C
> > > > 
> > > > diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
> > > > index 1a124f5395e..b528ee7b1d9 100644
> > > > --- a/gcc/cp/parser.cc
> > > > +++ b/gcc/cp/parser.cc
> > > > @@ -34473,14 +34473,32 @@ class_decl_loc_t::diag_mismatched_tags (tree 
> > > > type_decl)
> > > >  be (and inevitably is) at index zero.  */
> > > >  tree spec = specialization_of (type);
> > > >  cdlguide = class2loc.get (spec);
> > > > +  /* It's possible that we didn't find SPEC.  Consider:
> > > > +
> > > > +  template struct A {
> > > > +template struct W { };
> > > > +  };
> > > > +  struct A::W w; // #1
> > > > +
> > > > +where while parsing A and #1 we've stashed
> > > > +  A
> > > > +  A::W
> > > > +  A::W
> > > > +into CLASS2LOC.  If TYPE is A::W, specialization_of
> > > > +will yield A::W which may be in CLASS2LOC if we had
> > > > +an A class specialization, but otherwise won't be in it.
> > > > +So try to look up A::W.  */
> > > > +  if (!cdlguide)
> > > > +   {
> > > > + spec = DECL_TEMPLATE_RESULT (most_general_template (spec));
> > > 
> > > Would it make sense to only look at most_general_template, not 
> > > A::W
> > > at all?
> > 
> > I think that would break with class specialization, as in...
> > 
> > > > +template struct A {
> > > > +  template
> > > > +  struct W { };
> > > > +};
> > > > +
> > > > +template<>
> > > > +struct A {
> > > > +  template
> > > > +  class W { };
> > > > +};
> > > > +
> > > > +void
> > > > +g ()
> > > > +{
> > > > +  struct A::W w1; // { dg-warning "mismatched" }
> > 
> > ...this, where we should first look into A, and only if not
> > found, go to A.
> 
> I'd expect the
> 
> >   /* Stop if we run into an explicitly specialized class template.  */
> 
> code in most_general_template to avoid that problem.

Ah, I had no idea it does that.  The unconditional most_general_template
works fine for the new test, but some of the existing tests then fail.
Reduced:

templatestruct S2; // #1
template  class S2; // #2

extern class  S2 s2ci; // #3
extern struct S2 s2ci; // { dg-warning "\\\[-Wmismatched-tags" }

where the unconditional most_general_template changes spec from
"class S2" to "struct S2" (both of which are in class2loc).
So it regresses the diagnostic, complaining that #3 should have "struct"
since #1 has "struct".  I think we want to keep the current diagnostic,
saying that the last line should have "class" since the specialization
in line #2 has "

[pushed] analyzer: fixes to side-effects for built-in functions [PR107565]

[David Malcolm via Gcc-patches]

Previously, if the analyzer saw a call to a non-pure and non-const
built-in function that it didn't have explicit knowledge of the behavior
of, it would fall back to assuming that the builtin could have arbitrary
behavior, similar to a function defined outside of the current TU.

However, this only worked for BUILTIN_NORMAL functions that matched
gimple_builtin_call_types_compatible_p; for BUILT_IN_FRONTEND and
BUILT_IN_MD, and for mismatched types the analyzer would erroneously
assume that the builtin had no side-effects, leading e.g. to
PR analyzer/107565, where the analyzer falsely reported that x
was still uninitialized after this target-specific builtin:

  _1 = __builtin_ia32_rdrand64_step (&x);

This patch generalizes the handling to cover all classes of builtin,
fixing the above false positive.

Unfortunately this patch regresses gcc.dg/analyzer/pr99716-1.c due to
the:
  fprintf (fp, "hello");
being optimized to:
   __builtin_fwrite ("hello", 1, (ssizetype)5, fp_6);
and the latter has gimple_builtin_call_types_compatible_p return false,
whereas the original call had it return true.  I'm assuming that this is
an optimization bug, and have filed it as PR middle-end/108988.  The
effect on the analyzer is that it fails to recognize the call to
__builtin_fwrite and instead assumes arbitraty side-effects (including
that it could call fclose on fp, hence the report about the leak goes
away).

I tried various more involved fixes with new heuristics for handling
built-ins that aren't explicitly covered by the analyzer, but those
fixes tended to introduce many more regressions, so I'm going with this
simpler fix.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Integration testing shows no change in results.

Pushed to trunk as r13-6398-g24ebc5404b88b7.

gcc/analyzer/ChangeLog:
PR analyzer/107565
* region-model.cc (region_model::on_call_pre): Flatten logic by
returning early.  Consolidate logic for detecting const and pure
functions.  When considering whether an unhandled built-in
function has side-effects, consider all kinds of builtin, rather
than just BUILT_IN_NORMAL, and don't require
gimple_builtin_call_types_compatible_p.

gcc/testsuite/ChangeLog:
PR analyzer/107565
* gcc.dg/analyzer/builtins-pr107565.c: New test.
* gcc.dg/analyzer/pr99716-1.c (test_2): Mark the leak as xfailing.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/region-model.cc  | 44 ---
 .../gcc.dg/analyzer/builtins-pr107565.c   | 29 
 gcc/testsuite/gcc.dg/analyzer/pr99716-1.c |  6 ++-
 3 files changed, 53 insertions(+), 26 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/builtins-pr107565.c

diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
index f844b519f61..2187aecbe91 100644
--- a/gcc/analyzer/region-model.cc
+++ b/gcc/analyzer/region-model.cc
@@ -1477,8 +1477,6 @@ region_model::on_call_pre (const gcall *call, 
region_model_context *ctxt)
 {
   call_details cd (call, this, ctxt);
 
-  bool unknown_side_effects = false;
-
   /* Special-case for IFN_DEFERRED_INIT.
  We want to report uninitialized variables with -fanalyzer (treating
  -ftrivial-auto-var-init= as purely a mitigation feature).
@@ -1487,7 +1485,7 @@ region_model::on_call_pre (const gcall *call, 
region_model_context *ctxt)
  view of the analyzer.  */
   if (gimple_call_internal_p (call)
   && gimple_call_internal_fn (call) == IFN_DEFERRED_INIT)
-return false;
+return false; /* No side effects.  */
 
   /* Get svalues for all of the arguments at the callsite, to ensure that we
  complain about any uninitialized arguments.  This might lead to
@@ -1532,33 +1530,29 @@ region_model::on_call_pre (const gcall *call, 
region_model_context *ctxt)
  = get_known_function (gimple_call_internal_fn (call)))
   {
kf->impl_call_pre (cd);
-   return false;
+   return false; /* No further side effects.  */
   }
 
-  if (callee_fndecl)
-{
-  int callee_fndecl_flags = flags_from_decl_or_type (callee_fndecl);
+  if (!callee_fndecl)
+return true; /* Unknown side effects.  */
 
-  if (const known_function *kf = get_known_function (callee_fndecl, cd))
-   {
- kf->impl_call_pre (cd);
- return false;
-   }
-  else if (fndecl_built_in_p (callee_fndecl, BUILT_IN_NORMAL)
- && gimple_builtin_call_types_compatible_p (call, callee_fndecl))
-   {
- if (!(callee_fndecl_flags & (ECF_CONST | ECF_PURE)))
-   unknown_side_effects = true;
-   }
-  else if (!fndecl_has_gimple_body_p (callee_fndecl)
-  && (!(callee_fndecl_flags & (ECF_CONST | ECF_PURE)))
-  && !fndecl_built_in_p (callee_fndecl))
-   unknown_side_effects = true;
+  if (const known_function *kf = get_known_function (callee_fndecl, cd))
+{
+  kf->impl_call_pre (cd);
+  return false; /* No 

Re: [PATCH][stage1] Remove conditionals around free()

[Bernhard Reutner-Fischer via Gcc-patches]

On Wed, 1 Mar 2023 22:28:56 +0100
Bernhard Reutner-Fischer  wrote:

> Remarks:
> 1) We should do this in if-conversion (?) on our own.
>I suppose. Independently of -fdelete-null-pointer-checks

and iff we can prove that ptr was NULL when passed to free(ptr) then we
can elide the call, of course. Likewise for realloc(ptr, 0), obviously.
[or reallocarray -- yikes -- if nmemb == 0 || size == 0]

But that would probably be a ranger call in DCE, i guess. Didn't look.
thanks,

Re: [PATCH v4] c++: -Wdangling-reference with reference wrapper [PR107532]

[Jason Merrill via Gcc-patches]

On 2/7/23 11:46, Marek Polacek wrote:

On Sun, Feb 05, 2023 at 05:25:25PM -0800, Jason Merrill wrote:

On 1/24/23 17:49, Marek Polacek wrote:

On Fri, Jan 20, 2023 at 03:19:54PM -0500, Jason Merrill wrote:

On 1/19/23 21:03, Marek Polacek wrote:

On Thu, Jan 19, 2023 at 01:02:02PM -0500, Jason Merrill wrote:

On 1/18/23 20:13, Marek Polacek wrote:

On Wed, Jan 18, 2023 at 04:07:59PM -0500, Jason Merrill wrote:

On 1/18/23 12:52, Marek Polacek wrote:

Here, -Wdangling-reference triggers where it probably shouldn't, causing
some grief.  The code in question uses a reference wrapper with a member
function returning a reference to a subobject of a non-temporary object:

   const Plane & meta = fm.planes().inner();

I've tried a few approaches, e.g., checking that the member function's
return type is the same as the type of the enclosing class (which is
the case for member functions returning *this), but that then breaks
Wdangling-reference4.C with std::optional.

So I figured that perhaps we want to look at the object we're invoking
the member function(s) on and see if that is a temporary, as in, don't
warn about

   const Plane & meta = fm.planes().inner();

but do warn about

   const Plane & meta = FrameMetadata().planes().inner();

It's ugly, but better than asking users to add #pragmas into their code.


Hmm, that doesn't seem right; the former is only OK because Ref is in fact a
reference-like type.  If planes() returned a class that held data, we would
want to warn.


Sure, it's always some kind of tradeoff with warnings :/.

In this case, we might recognize the reference-like class because it has a
reference member and a constructor taking the same reference type.


That occurred to me too, but then I found out that std::reference_wrapper
actually uses T*, not T&, as you say.  But here's a patch to do that
(I hope).

That wouldn't help with std::reference_wrapper or std::ref_view because they
have pointer members instead of references, but perhaps loosening the check
to include that case would make sense?


Sorry, I don't understand what you mean by loosening the check.  I could
hardcode std::reference_wrapper and std::ref_view but I don't think that's
what you meant.


Indeed that's not what I meant, but as I was saying in our meeting I think
it's worth doing; the compiler has various tweaks to handle specific
standard-library classes better.

Okay, done in the patch below.  Except that I'm not including a test for
std::ranges::ref_view because I don't really know how that works.


Surely I cannot _not_ warn for any class that contains a T*.


I was thinking if a constructor takes a T& and the class has a T* that would
be close enough, though this also wouldn't handle the standard library
classes so the benefit is questionable.


Here's the patch so that we have some actual code to discuss...  Thanks.

-- >8 --
Here, -Wdangling-reference triggers where it probably shouldn't, causing
some grief.  The code in question uses a reference wrapper with a member
function returning a reference to a subobject of a non-temporary object:

  const Plane & meta = fm.planes().inner();

I've tried a few approaches, e.g., checking that the member function's
return type is the same as the type of the enclosing class (which is
the case for member functions returning *this), but that then breaks
Wdangling-reference4.C with std::optional.

Perhaps we want to look at the member function's enclosing class
to see if it's a reference wrapper class (meaning, has a reference
member and a constructor taking the same reference type) and don't
warn if so, supposing that the member function returns a reference
to a non-temporary object.

It's ugly, but better than asking users to add #pragmas into their code.

PR c++/107532

gcc/cp/ChangeLog:

* call.cc (do_warn_dangling_reference): Don't warn when the
member function comes from a reference wrapper class.


Let's factor the new code out into e.g. reference_like_class_p


Done.  Thanks,

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

-- >8 --
Here, -Wdangling-reference triggers where it probably shouldn't, causing
some grief.  The code in question uses a reference wrapper with a member
function returning a reference to a subobject of a non-temporary object:

 const Plane & meta = fm.planes().inner();

I've tried a few approaches, e.g., checking that the member function's
return type is the same as the type of the enclosing class (which is
the case for member functions returning *this), but that then breaks
Wdangling-reference4.C with std::optional.

Perhaps we want to look at the member function's enclosing class
to see if it's a reference wrapper class (meaning, has a reference
member and a constructor taking the same reference type, or is
std::reference_wrapper or std::ranges::ref_view) and don't warn if so,
supposing that the member function returns a reference to a non-temporary
object.

It's ugly, but better than askin

Re: [PATCH] c++: ICE with -Wmismatched-tags and member template [PR106259]

[Jason Merrill via Gcc-patches]

On 3/1/23 16:40, Marek Polacek wrote:

On Wed, Mar 01, 2023 at 04:30:16PM -0500, Jason Merrill wrote:

On 3/1/23 15:33, Marek Polacek wrote:

-Wmismatched-tags warns about the (harmless) struct/class mismatch.
For, e.g.,

template struct A { };
class A a;

it works by adding A to the class2loc hash table while parsing the
class-head and then, while parsing the elaborate type-specifier, we
add A.  At the end of c_parse_file we go through the table and
warn about the class-key mismatches.  In this PR we crash though; we
have

template struct A {
  template struct W { };
};
struct A::W w; // #1

where while parsing A and #1 we've stashed
 A
 A::W
 A::W
into class2loc.  Then in class_decl_loc_t::diag_mismatched_tags TYPE
is A::W, and specialization_of gets us A::W, which
is not in class2loc, so we crash on gcc_assert (cdlguide).  But it's
OK not to have found A::W, we should just look one "level" up,
that is, A::W.

It's important to handle class specializations, so e.g.

template<>
struct A {
  template
  class W { };
};

where W's class-key is different than in the primary template above,
so we should warn depending on whether we're looking into A
or into a different instantiation.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

PR c++/106259

gcc/cp/ChangeLog:

* parser.cc (class_decl_loc_t::diag_mismatched_tags): If the first
lookup of SPEC didn't find anything, try to look for
most_general_template.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wmismatched-tags-11.C: New test.
---
   gcc/cp/parser.cc  | 30 +++
   .../g++.dg/warn/Wmismatched-tags-11.C | 23 ++
   2 files changed, 47 insertions(+), 6 deletions(-)
   create mode 100644 gcc/testsuite/g++.dg/warn/Wmismatched-tags-11.C

diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 1a124f5395e..b528ee7b1d9 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -34473,14 +34473,32 @@ class_decl_loc_t::diag_mismatched_tags (tree 
type_decl)
 be (and inevitably is) at index zero.  */
 tree spec = specialization_of (type);
 cdlguide = class2loc.get (spec);
+  /* It's possible that we didn't find SPEC.  Consider:
+
+  template struct A {
+template struct W { };
+  };
+  struct A::W w; // #1
+
+where while parsing A and #1 we've stashed
+  A
+  A::W
+  A::W
+into CLASS2LOC.  If TYPE is A::W, specialization_of
+will yield A::W which may be in CLASS2LOC if we had
+an A class specialization, but otherwise won't be in it.
+So try to look up A::W.  */
+  if (!cdlguide)
+   {
+ spec = DECL_TEMPLATE_RESULT (most_general_template (spec));


Would it make sense to only look at most_general_template, not A::W
at all?


I think that would break with class specialization, as in...


+template struct A {
+  template
+  struct W { };
+};
+
+template<>
+struct A {
+  template
+  class W { };
+};
+
+void
+g ()
+{
+  struct A::W w1; // { dg-warning "mismatched" }


...this, where we should first look into A, and only if not
found, go to A.


I'd expect the


  /* Stop if we run into an explicitly specialized class template.  */


code in most_general_template to avoid that problem.

Jason

Re: [PATCH] c++: ICE with -Wmismatched-tags and member template [PR106259]

[Marek Polacek via Gcc-patches]

On Wed, Mar 01, 2023 at 04:30:16PM -0500, Jason Merrill wrote:
> On 3/1/23 15:33, Marek Polacek wrote:
> > -Wmismatched-tags warns about the (harmless) struct/class mismatch.
> > For, e.g.,
> > 
> >template struct A { };
> >class A a;
> > 
> > it works by adding A to the class2loc hash table while parsing the
> > class-head and then, while parsing the elaborate type-specifier, we
> > add A.  At the end of c_parse_file we go through the table and
> > warn about the class-key mismatches.  In this PR we crash though; we
> > have
> > 
> >template struct A {
> >  template struct W { };
> >};
> >struct A::W w; // #1
> > 
> > where while parsing A and #1 we've stashed
> > A
> > A::W
> > A::W
> > into class2loc.  Then in class_decl_loc_t::diag_mismatched_tags TYPE
> > is A::W, and specialization_of gets us A::W, which
> > is not in class2loc, so we crash on gcc_assert (cdlguide).  But it's
> > OK not to have found A::W, we should just look one "level" up,
> > that is, A::W.
> > 
> > It's important to handle class specializations, so e.g.
> > 
> >template<>
> >struct A {
> >  template
> >  class W { };
> >};
> > 
> > where W's class-key is different than in the primary template above,
> > so we should warn depending on whether we're looking into A
> > or into a different instantiation.
> > 
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > 
> > PR c++/106259
> > 
> > gcc/cp/ChangeLog:
> > 
> > * parser.cc (class_decl_loc_t::diag_mismatched_tags): If the first
> > lookup of SPEC didn't find anything, try to look for
> > most_general_template.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * g++.dg/warn/Wmismatched-tags-11.C: New test.
> > ---
> >   gcc/cp/parser.cc  | 30 +++
> >   .../g++.dg/warn/Wmismatched-tags-11.C | 23 ++
> >   2 files changed, 47 insertions(+), 6 deletions(-)
> >   create mode 100644 gcc/testsuite/g++.dg/warn/Wmismatched-tags-11.C
> > 
> > diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
> > index 1a124f5395e..b528ee7b1d9 100644
> > --- a/gcc/cp/parser.cc
> > +++ b/gcc/cp/parser.cc
> > @@ -34473,14 +34473,32 @@ class_decl_loc_t::diag_mismatched_tags (tree 
> > type_decl)
> >  be (and inevitably is) at index zero.  */
> > tree spec = specialization_of (type);
> > cdlguide = class2loc.get (spec);
> > +  /* It's possible that we didn't find SPEC.  Consider:
> > +
> > +  template struct A {
> > +template struct W { };
> > +  };
> > +  struct A::W w; // #1
> > +
> > +where while parsing A and #1 we've stashed
> > +  A
> > +  A::W
> > +  A::W
> > +into CLASS2LOC.  If TYPE is A::W, specialization_of
> > +will yield A::W which may be in CLASS2LOC if we had
> > +an A class specialization, but otherwise won't be in it.
> > +So try to look up A::W.  */
> > +  if (!cdlguide)
> > +   {
> > + spec = DECL_TEMPLATE_RESULT (most_general_template (spec));
> 
> Would it make sense to only look at most_general_template, not A::W
> at all?

I think that would break with class specialization, as in...

> > +template struct A {
> > +  template
> > +  struct W { };
> > +};
> > +
> > +template<>
> > +struct A {
> > +  template
> > +  class W { };
> > +};
> > +
> > +void
> > +g ()
> > +{
> > +  struct A::W w1; // { dg-warning "mismatched" }

...this, where we should first look into A, and only if not
found, go to A.

class2loc will be filled with A::W, added while parsing
the specialization.

> > +  struct A::W w2;
> > +  class A::W w3;
> > +  class A::W w4; // { dg-warning "mismatched" }
> > +}
> > 
> > base-commit: 096f034a8f5df41f610e62c1592fb90a3f551cd5
> 

Marek

Re: [PATCH 1/2] c++: factor out TYPENAME_TYPE substitution

[Jason Merrill via Gcc-patches]

On 2/21/23 19:05, Patrick Palka wrote:

On Sun, 19 Feb 2023, Jason Merrill wrote:


On 2/15/23 12:11, Patrick Palka wrote:

On Wed, 15 Feb 2023, Jason Merrill wrote:


On 2/15/23 09:21, Patrick Palka wrote:

On Tue, 14 Feb 2023, Jason Merrill wrote:


On 2/13/23 09:23, Patrick Palka wrote:

[N.B. this is a corrected version of
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607443.html
]

This patch factors out the TYPENAME_TYPE case of tsubst into a
separate
function tsubst_typename_type.  It also factors out the two tsubst
flags
controlling TYPENAME_TYPE substitution, tf_keep_type_decl and
tf_tst_ok,
into distinct boolean parameters of this new function (and of
make_typename_type).  Consequently, callers which used to pass
tf_tst_ok
to tsubst now instead must directly call tsubst_typename_type when
appropriate.


Hmm, I don't love how that turns 4 lines into 8 more complex lines in
each
caller.  And the previous approach of saying "a CTAD placeholder is
OK"
seem
like better abstraction than repeating the specific TYPENAME_TYPE
handling
in
each place.


Ah yeah, I see what you mean.  I was thinking since tf_tst_ok is
specific to TYPENAME_TYPE handling and isn't propagated (i.e. it only
affects top-level TYPENAME_TYPEs), it seemed cleaner to encode the flag
as a bool parameter "template_ok" of tsubst_typename_type instead of as
a global tsubst_flag that gets propagated freely.




In a subsequent patch we'll add another flag to
tsubst_typename_type controlling whether we want to ignore non-types
during the qualified lookup.


As mentioned above, the second patch in this series would just add
another flag "type_only" alongside "template_ok", since this flag will
also only affects top-level TYPENAME_TYPEs and doesn't need to propagate
like tsubst_flags.

Except, it turns it, this new flag _does_ need to propagate, namely when
expanding a variadic using:

 using typename Ts::type::m...; // from typename25a.C below

Here we have a USING_DECL whose USING_DECL_SCOPE is a
TYPE_PACK_EXPANSION over TYPENAME_TYPE.  In order to correctly
substitute this TYPENAME_TYPE, the USING_DECL case of tsubst_decl needs
to pass an appropriate tsubst_flag to tsubst_pack_expansion to be
propagated to tsubst (to be propagated to make_typename_type).

So in light of this case it seems adding a new tsubst_flag is the
way to go, which means we can avoid this refactoring patch entirely.

Like so?  Bootstrapped and regtested on x86_64-pc-linux-gnu.


OK, though I still wonder about adding a tsubst_scope function that would
add
the tf_qualifying_scope.


Hmm, but we need to add tf_qualifying_scope to two tsubst_copy calls,
one tsubst call and one tsubst_aggr_type call (with entering_scope=true).
Would tsubst_scope call tsubst, tsubst_copy or tsubst_aggr_type?


In general it would call tsubst.

It's odd that anything is calling tsubst_copy with a type, that seems like a
copy/paste error.  But it just hands off to tsubst anyway, so the effect is
the same.


Ah, makes sense.  And if we make tsubst_copy hand off to tsubst
immediately for TYPE_P trees we can make tsubst_copy oblivious to the
tf_qualifying_scope flag.  I experimented with going a step further and
fixing callers that pass a type to tsubst_copy, but that sort of clean
up might be in vain given that we might be getting rid of tsubst_copy
in the next stage 1.



tsubst_aggr_type is needed when pushing into the scope of a declarator; I
don't know offhand why we would need that when substituting the scope of a
TYPENAME_TYPE.


Apparently if we don't do entering_scope=true here then it breaks

   g++.dg/template/friend61.C
   g++.dg/template/memfriend12.C
   g++.dg/template/memfriend17.C

I think it's because without entering_scope=true, dependent substitution
yields a dependent specialization A instead of the primary template
type A, but we need the latter to perform qualified name lookup from
such a substituted dependent scope.  I left that call alone for now.

How does this look?  Bootstrapped and regtested on x86_64-pc-linux-gnu.


OK.


-- >8 --

Subject: [PATCH] c++: clean up tf_qualifying_scope usage

This patch introduces a convenience wrapper tsubst_scope for tsubst'ing
into a type with tf_qualifying_scope set, and makes suitable callers use
it instead of explicitly setting tf_qualifying_scope.  This also makes
tsubst_copy immediately delegate to tsubst for all type trees, which
allows tsubst_copy to be oblivious to the tf_qualifying_scope flag.

gcc/cp/ChangeLog:

* pt.cc (tsubst_scope): Define.
(tsubst_decl) : Call tsubst_scope instead of
calling tsubst_scope with tf_qualifying_scope set.
(tsubst_qualified_id): Call tsubst_scope instead of
calling tsubst with tf_qualifying_scope set.
(tsubst_copy): Immediately delegate to tsubst for all TYPE_P
trees.  Remove tf_qualifying_scope manipulation.
: Call tsubst_scope instead of calling
tsubst with tf_qualifying_scope set.
---
  gcc/cp/pt.cc | 4

Re: [PATCH] c++: ICE with -Wmismatched-tags and member template [PR106259]

[Jason Merrill via Gcc-patches]

On 3/1/23 15:33, Marek Polacek wrote:

-Wmismatched-tags warns about the (harmless) struct/class mismatch.
For, e.g.,

   template struct A { };
   class A a;

it works by adding A to the class2loc hash table while parsing the
class-head and then, while parsing the elaborate type-specifier, we
add A.  At the end of c_parse_file we go through the table and
warn about the class-key mismatches.  In this PR we crash though; we
have

   template struct A {
 template struct W { };
   };
   struct A::W w; // #1

where while parsing A and #1 we've stashed
A
A::W
A::W
into class2loc.  Then in class_decl_loc_t::diag_mismatched_tags TYPE
is A::W, and specialization_of gets us A::W, which
is not in class2loc, so we crash on gcc_assert (cdlguide).  But it's
OK not to have found A::W, we should just look one "level" up,
that is, A::W.

It's important to handle class specializations, so e.g.

   template<>
   struct A {
 template
 class W { };
   };

where W's class-key is different than in the primary template above,
so we should warn depending on whether we're looking into A
or into a different instantiation.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

PR c++/106259

gcc/cp/ChangeLog:

* parser.cc (class_decl_loc_t::diag_mismatched_tags): If the first
lookup of SPEC didn't find anything, try to look for
most_general_template.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wmismatched-tags-11.C: New test.
---
  gcc/cp/parser.cc  | 30 +++
  .../g++.dg/warn/Wmismatched-tags-11.C | 23 ++
  2 files changed, 47 insertions(+), 6 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/warn/Wmismatched-tags-11.C

diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 1a124f5395e..b528ee7b1d9 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -34473,14 +34473,32 @@ class_decl_loc_t::diag_mismatched_tags (tree 
type_decl)
 be (and inevitably is) at index zero.  */
tree spec = specialization_of (type);
cdlguide = class2loc.get (spec);
+  /* It's possible that we didn't find SPEC.  Consider:
+
+  template struct A {
+template struct W { };
+  };
+  struct A::W w; // #1
+
+where while parsing A and #1 we've stashed
+  A
+  A::W
+  A::W
+into CLASS2LOC.  If TYPE is A::W, specialization_of
+will yield A::W which may be in CLASS2LOC if we had
+an A class specialization, but otherwise won't be in it.
+So try to look up A::W.  */
+  if (!cdlguide)
+   {
+ spec = DECL_TEMPLATE_RESULT (most_general_template (spec));


Would it make sense to only look at most_general_template, not 
A::W at all?



+ cdlguide = class2loc.get (spec);
+   }
+  /* Now we really should have found something.  */
gcc_assert (cdlguide != NULL);
  }
-  else
-{
-  /* Skip declarations that consistently use the same class-key.  */
-  if (def_class_key != none_type)
-   return;
-}
+  /* Skip declarations that consistently use the same class-key.  */
+  else if (def_class_key != none_type)
+return;
  
/* Set if a definition for the class has been seen.  */

const bool def_p = cdlguide->def_p ();
diff --git a/gcc/testsuite/g++.dg/warn/Wmismatched-tags-11.C 
b/gcc/testsuite/g++.dg/warn/Wmismatched-tags-11.C
new file mode 100644
index 000..6c4e571726a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wmismatched-tags-11.C
@@ -0,0 +1,23 @@
+// PR c++/106259
+// { dg-do compile }
+// { dg-options "-Wmismatched-tags" }
+
+template struct A {
+  template
+  struct W { };
+};
+
+template<>
+struct A {
+  template
+  class W { };
+};
+
+void
+g ()
+{
+  struct A::W w1; // { dg-warning "mismatched" }
+  struct A::W w2;
+  class A::W w3;
+  class A::W w4; // { dg-warning "mismatched" }
+}

base-commit: 096f034a8f5df41f610e62c1592fb90a3f551cd5

[PATCH][stage1] Remove conditionals around free()

[Bernhard Reutner-Fischer via Gcc-patches]

Hi!

Mere cosmetics.

- if (foo != NULL)
free (foo);

With the caveat that coccinelle ruins replacement whitespace or i'm
uneducated enough to be unable to _not_ run the diff through
 sed -e 's/^+\([[:space:]]*\)free(/+\1free (/'
at least. If anybody knows how to improve replacement whitespace,
i'd be interrested but didn't look nor ask. ISTM that leading
whitespace is somewhat ruined, too, so beware (8 spaces versus tab as
far as i have spot-checked).

Would touch
 gcc/ada/rtinit.c |3 +--
 intl/bindtextdom.c   |3 +--
 intl/loadmsgcat.c|6 ++
 intl/localcharset.c  |3 +--
 libbacktrace/xztest.c|9 +++--
 libbacktrace/zstdtest.c  |9 +++--
 libbacktrace/ztest.c |9 +++--
 libgfortran/caf/single.c |6 ++
 libgfortran/io/async.c   |6 ++
 libgfortran/io/format.c  |3 +--
 libgfortran/io/transfer.c|6 ++
 libgfortran/io/unix.c|3 +--
 libgo/runtime/go-setenv.c|6 ++
 libgo/runtime/go-unsetenv.c  |3 +--
 libgomp/target.c |3 +--
 libiberty/concat.c   |3 +--
 zlib/contrib/minizip/unzip.c |2 +-
 zlib/contrib/minizip/zip.c   |2 +-
 zlib/examples/enough.c   |6 ++
 zlib/examples/gun.c  |2 +-
 zlib/examples/gzjoin.c   |3 +--
 zlib/examples/gzlog.c|6 ++

coccinelle script and invocation inline.
Would need to be split for the respective maintainers and run through
mklog with subject changelog and should of course be compiled and
tested before that.

Remarks:
1) We should do this in if-conversion (?) on our own.
   I suppose. Independently of -fdelete-null-pointer-checks
2) Maybe not silently, but raise language awareness nowadays.
   By now it's been a long time since this was first mandated.
3) fallout from looking at something completely different
4) i most likely will not remember to split it apart and send proper
   patches, tested patches, in stage 1 to maintainers proper, so if
   anyone feels like pursuing this, be my guest. I thought i'd just
   mention it.

cheers,
# cat ~/coccinelle/free-without-if-null.0.cocci ; echo EOF
// POSIX: free(NULL) is perfectly valid
// quote: If ptr is a null pointer, no action shall occur.
@ rule1 @
expression e;
@@

- if (e != NULL)
-  { free(e); }
+ free (e);

EOF
# find ./ \( -name "*.[ch]" -o -name "*.cpp" \) -a \( ! -path "./gcc/testsuite/*" -a ! -path "./gcc/contrib/*" \) -exec spatch --sp-file ~/coccinelle/free-without-if-null.0.cocci --in-place 
diff --git a/gcc/ada/rtinit.c b/gcc/ada/rtinit.c
index f1607b3c8b0..bbf02b1c2ae 100644
--- a/gcc/ada/rtinit.c
+++ b/gcc/ada/rtinit.c
@@ -481,8 +481,7 @@ __gnat_runtime_initialize (int install_handler)
 
 		 FindClose (hDir);
 
-		 if (dir != NULL)
-		   free (dir);
+		 free (dir);
 		   }
 	   }
 	 else
diff --git a/intl/bindtextdom.c b/intl/bindtextdom.c
index 6faac5756a3..c71c728401b 100644
--- a/intl/bindtextdom.c
+++ b/intl/bindtextdom.c
@@ -204,8 +204,7 @@ set_binding_values (domainname, dirnamep, codesetp)
 
 		  if (__builtin_expect (result != NULL, 1))
 		{
-		  if (binding->codeset != NULL)
-			free (binding->codeset);
+		  free (binding->codeset);
 
 		  binding->codeset = result;
 		  binding->codeset_cntr++;
diff --git a/intl/loadmsgcat.c b/intl/loadmsgcat.c
index 536ee12621d..e55d095ec56 100644
--- a/intl/loadmsgcat.c
+++ b/intl/loadmsgcat.c
@@ -1273,8 +1273,7 @@ _nl_load_domain (domain_file, domainbinding)
   /* This is an invalid revision.  */
 invalid:
   /* This is an invalid .mo file.  */
-  if (domain->malloced)
-	free (domain->malloced);
+  free (domain->malloced);
 #ifdef HAVE_MMAP
   if (use_mmap)
 	munmap ((caddr_t) data, size);
@@ -1307,8 +1306,7 @@ _nl_unload_domain (domain)
 
   _nl_free_domain_conv (domain);
 
-  if (domain->malloced)
-free (domain->malloced);
+  free (domain->malloced);
 
 # ifdef _POSIX_MAPPED_FILES
   if (domain->use_mmap)
diff --git a/intl/localcharset.c b/intl/localcharset.c
index 8ece6e39f69..8d34dcb0918 100644
--- a/intl/localcharset.c
+++ b/intl/localcharset.c
@@ -199,8 +199,7 @@ get_charset_aliases ()
 	}
 	}
 
-  if (file_name != NULL)
-	free (file_name);
+  free (file_name);
 
 #else
 
diff --git a/libbacktrace/xztest.c b/libbacktrace/xztest.c
index ed90066470a..6f4a5c73a00 100644
--- a/libbacktrace/xztest.c
+++ b/libbacktrace/xztest.c
@@ -479,12 +479,9 @@ test_large (struct backtrace_state *state ATTRIBUTE_UNUSED)
   printf ("FAIL: lzma large\n");
   ++failures;
 
-  if (orig_buf != NULL)
-free (orig_buf);
-  if (compressed_buf != NULL)
-free (compressed_buf);
-  if (uncompressed_buf != NULL)
-free (uncompressed_buf);
+  free (orig_buf);
+  free (compressed_buf);
+  free (uncompressed_buf);
 
 #else /* !HAVE_LIBLZMA */
 
diff --git a/libbacktrace/zstdtest.c b/libbacktrace/zstdtest.c
index 1b4158a50eb..8a0b27977b5 100644
--- a/libbackt

[committed] libstdc++: Fix typo in comment in bits/cow_string.h

[Jonathan Wakely via Gcc-patches]

Pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

* include/bits/cow_string.h: Fix typo in comment.
---
 libstdc++-v3/include/bits/cow_string.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/include/bits/cow_string.h 
b/libstdc++-v3/include/bits/cow_string.h
index ad9929c4ad3..1ee84e60678 100644
--- a/libstdc++-v3/include/bits/cow_string.h
+++ b/libstdc++-v3/include/bits/cow_string.h
@@ -26,7 +26,7 @@
  *  This is an internal header file, included by other library headers.
  *  Do not attempt to use it directly. @headername{string}
  *
- *  Defines the reference-counted COW string implentation.
+ *  Defines the reference-counted COW string implementation.
  */
 
 #ifndef _COW_STRING_H
@@ -3406,7 +3406,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 }
else
 {
-  // Todo: overlapping case.
+  // TODO: overlapping case.
   const basic_string __tmp(__s, __n2);
   return _M_replace_safe(__pos, __n1, __tmp._M_data(), __n2);
 }
-- 
2.39.2

[committed] libstdc++: Make std::chrono::current_zone() default to UTC

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux and powerpc-aix. Pushed to trunk.

-- >8 --

This is consistent with the behaviour of glibc, which assumes UTC when
/etc/localtime and TZ do not identify a valid time zone. The fallback
tzdb used when no valid tzdata exists always contains the UTC zone, so
this change means we have a valid tzdb and valid current zone even in
the degenerate case.

With this default we no longer need the AIX-specific kluge to try and
identify TZ values specifying a 0-offset zone. We can just use the UTC
default for those, as it has the same effect.

It's still possible for chrono::current_zone() to fail, because the user
could have provided a custom tzdata.zi file which doesn't contain the
UTC time zone, so the "UTC" default would fail to find a valid zone, and
throw an exception. That's just user error, they should not provide bad
data and expect reasonable behaviour.

libstdc++-v3/ChangeLog:

* src/c++20/tzdb.cc (chrono::tzdb::current_zone()) Use "UTC" if
current time zone cannot be determined.
* testsuite/std/time/tzdb/1.cc: Remove conditions based on
HAVE_TZDB macro and test all members unconditionally.
---
 libstdc++-v3/src/c++20/tzdb.cc| 15 ++-
 libstdc++-v3/testsuite/std/time/tzdb/1.cc | 22 +++---
 2 files changed, 17 insertions(+), 20 deletions(-)

diff --git a/libstdc++-v3/src/c++20/tzdb.cc b/libstdc++-v3/src/c++20/tzdb.cc
index 2e7e173f0ef..2b6e3b9 100644
--- a/libstdc++-v3/src/c++20/tzdb.cc
+++ b/libstdc++-v3/src/c++20/tzdb.cc
@@ -1692,19 +1692,16 @@ namespace std::chrono
 // https://www.ibm.com/support/pages/managing-time-zone-variable-posix
 if (const char* env = std::getenv("TZ"))
   {
-   string_view s(env);
-   if (s == "GMT0")
- s = "Etc/GMT";
-   else if (s.size() == 4 && s[3] == '0')
- s = "Etc/UTC";
-
-   // This will fail unless TZ contains an IANA time zone name,
-   // or one of the special cases above.
-   if (auto tz = do_locate_zone(this->zones, this->links, s))
+   // This will fail unless TZ contains an IANA time zone name.
+   if (auto tz = do_locate_zone(this->zones, this->links, env))
  return tz;
   }
 #endif
 
+// Default to UTC.
+if (auto tz = do_locate_zone(this->zones, this->links, "UTC"))
+  return tz;
+
 __throw_runtime_error("tzdb: cannot determine current zone");
   }
 
diff --git a/libstdc++-v3/testsuite/std/time/tzdb/1.cc 
b/libstdc++-v3/testsuite/std/time/tzdb/1.cc
index 64e42701d3b..877a55b8d31 100644
--- a/libstdc++-v3/testsuite/std/time/tzdb/1.cc
+++ b/libstdc++-v3/testsuite/std/time/tzdb/1.cc
@@ -1,7 +1,6 @@
 // { dg-options "-std=gnu++20" }
 // { dg-do run { target c++20 } }
 // { dg-require-effective-target cxx11_abi }
-// { dg-additional-options "-DHAVE_TZDB" { target tzdb } }
 
 #include 
 #include 
@@ -14,22 +13,25 @@ test_version()
   const tzdb& db = get_tzdb();
   VERIFY( &db == &get_tzdb_list().front() );
 
-#ifdef HAVE_TZDB
-  VERIFY( db.version == remote_version() );
-  const tzdb& reloaded = reload_tzdb();
-  if (reloaded.version == db.version)
-VERIFY( &reloaded == &db );
-#endif
+  const char* func;
+  try {
+func = "remote_version";
+VERIFY( db.version == remote_version() );
+func = "reload_tzdb";
+const tzdb& reloaded = reload_tzdb();
+if (reloaded.version == db.version)
+  VERIFY( &reloaded == &db );
+  } catch (const std::exception&) {
+std::printf("std::chrono::%s() failed\n", func);
+  }
 }
 
 void
 test_current()
 {
-#ifdef HAVE_TZDB
   const tzdb& db = get_tzdb();
   const time_zone* tz = db.current_zone();
   VERIFY( tz == std::chrono::current_zone() );
-#endif
 }
 
 void
@@ -43,9 +45,7 @@ test_locate()
   VERIFY( tz == db.locate_zone("Etc/GMT") );
   VERIFY( tz == db.locate_zone("Etc/GMT+0") );
 
-#ifdef HAVE_TZDB
   VERIFY( db.locate_zone(db.current_zone()->name()) == db.current_zone() );
-#endif
 }
 
 int main()
-- 
2.39.2

Re: [PATCH] c++: can't eval PTRMEM_CST in incomplete class [PR107574]

[Jason Merrill via Gcc-patches]

On 2/2/23 19:28, Marek Polacek wrote:

Here we're attempting to evaluate a PTRMEM_CST in a class that hasn't
been completed yet, but that doesn't work:

 /* We can't lower this until the class is complete.  */
 if (!COMPLETE_TYPE_P (DECL_CONTEXT (member)))
   return cst;

and then this unlowered PTRMEM_CST is used as EXPR in

 tree op1 = build_nop (ptrdiff_type_node, expr);

and we crash in a subsequent cp_fold_convert which gets type=ptrdiff_type_node,
expr=PTRMEM_CST and does

   else if (TREE_CODE (expr) == PTRMEM_CST
&& same_type_p (TYPE_PTRMEM_CLASS_TYPE (type),
PTRMEM_CST_CLASS (expr)))

where TYPE_PTRMEM_CLASS_TYPE (type) is going to crash since the type
is ptrdiff_type_node.  We could just add a TYPE_PTRMEM_P check before
accessing TYPE_PTRMEM_CLASS_TYPE but I think it's nicer to explain why
we couldn't evaluate the expression.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

PR c++/107574

gcc/cp/ChangeLog:

* constexpr.cc (cxx_eval_constant_expression): Emit an error when
a PTRMEM_CST cannot be evaluated.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/ptrmem-cst1.C: New test.
---
  gcc/cp/constexpr.cc  |  9 +
  gcc/testsuite/g++.dg/cpp0x/ptrmem-cst1.C | 11 +++
  2 files changed, 20 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/ptrmem-cst1.C

diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index 5b31f9c27d1..2c03988b097 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -7691,6 +7691,15 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx, 
tree t,
if (!same_type_ignoring_top_level_qualifiers_p (type, TREE_TYPE 
(op))
&& !can_convert_qual (type, op))
  op = cplus_expand_constant (op);
+   if (TREE_CODE (op) == PTRMEM_CST && !TYPE_PTRMEM_P (type))
+ {
+   if (!ctx->quiet)
+ error_at (loc, "%qE is not a constant expression when the "
+   "class %qT is still incomplete", op,
+   PTRMEM_CST_CLASS (op));
+   *non_constant_p = true;
+   return t;
+ }


Hmm, maybe handle this a few lines higher, in this existing if:


if (TREE_CODE (op) == PTRMEM_CST && !TYPE_PTRMEM_P (type))
  op = cplus_expand_constant (op);


?  OK with that change.

Re: [PATCH] vect: Check that vector factor is a compile-time constant

[Michael Collison]

Okay there seems to be consensus on using constant_lower_bound (vf), but 
I don't understand how that is a replacement for "vf.is_constant ()"? In 
one case we are checking if "vf" is a constant, on the other we are 
asking for the lower bound. For the crash in question 
"constant_lower_bound (vf) " returns the integer value of two.


On 2/27/23 09:51, Richard Sandiford wrote:

FWIW, this patch looks good to me.  I'd argue it's a regression fix
of kinds, in that the current code was correct before variable VF and
became incorrect after variable VF.  It might be possible to trigger
the problem on SVE too, with a sufficiently convoluted test case.
(Haven't tried though.)

Richard Biener  writes:

On Wed, Feb 22, 2023 at 12:03 AM Michael Collison  wrote:

While working on autovectorizing for the RISCV port I encountered an
issue where vect_do_peeling assumes that the vectorization factor is a
compile-time constant. The vectorization is not a compile-time constant
on RISCV.

Tested on RISCV and x86_64-linux-gnu. Okay?

I wonder how you arrive at prologue peeling with a non-constant VF?

Not sure about the RVV case, but I think it makes sense in principle.
E.g. if some ISA takes the LOAD_LEN rather than fully-predicated
approach, it can't easily use the first iteration of the vector loop
to do peeling for alignment.  (At least, the IV steps would then
no longer match VF for all iterations.)  I guess it could use a
*different* vector loop, but we don't support that yet.

There are also some corner cases for which we still don't support
predicated loops and instead fall back on an unpredicated VLA loop
followed by a scalar epilogue.  Peeling for alignment would then
require a scalar prologue too.


In any case it would probably be better to use constant_lower_bound (vf)
here?  Also it looks wrong to apply this limit in case we are using
a fully masked main vector loop.  But as said, the specific case of
non-constant VF and prologue peeling probably wasn't supposed to happen,
instead the prologue usually is applied via an offset to a fully masked loop?

Hmm, yeah, agree constant_lower_bound should work too.

Thanks,
Richard


Richard?

Thanks,
Richard.


Michael

gcc/

  * tree-vect-loop-manip.cc (vect_do_peeling): Verify
  that vectorization factor is a compile-time constant.

---
   gcc/tree-vect-loop-manip.cc | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/tree-vect-loop-manip.cc b/gcc/tree-vect-loop-manip.cc
index 6aa3d2ed0bf..1ad1961c788 100644
--- a/gcc/tree-vect-loop-manip.cc
+++ b/gcc/tree-vect-loop-manip.cc
@@ -2930,7 +2930,7 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree
niters, tree nitersm1,
 niters = vect_build_loop_niters (loop_vinfo, &new_var_p);
 /* It's guaranteed that vector loop bound before vectorization is at
least VF, so set range information for newly generated var. */
-  if (new_var_p)
+  if (new_var_p && vf.is_constant ())
   {
 value_range vr (type,
 wi::to_wide (build_int_cst (type, vf)),
--
2.34.1

Re: [PATCH] c++: can't eval PTRMEM_CST in incomplete class [PR107574]

[Marek Polacek via Gcc-patches]

Ping.

On Thu, Feb 02, 2023 at 07:28:25PM -0500, Marek Polacek via Gcc-patches wrote:
> Here we're attempting to evaluate a PTRMEM_CST in a class that hasn't
> been completed yet, but that doesn't work:
> 
> /* We can't lower this until the class is complete.  */
> if (!COMPLETE_TYPE_P (DECL_CONTEXT (member)))
>   return cst;
> 
> and then this unlowered PTRMEM_CST is used as EXPR in
> 
> tree op1 = build_nop (ptrdiff_type_node, expr);
> 
> and we crash in a subsequent cp_fold_convert which gets 
> type=ptrdiff_type_node,
> expr=PTRMEM_CST and does
> 
>   else if (TREE_CODE (expr) == PTRMEM_CST
>&& same_type_p (TYPE_PTRMEM_CLASS_TYPE (type),
>PTRMEM_CST_CLASS (expr)))
> 
> where TYPE_PTRMEM_CLASS_TYPE (type) is going to crash since the type
> is ptrdiff_type_node.  We could just add a TYPE_PTRMEM_P check before
> accessing TYPE_PTRMEM_CLASS_TYPE but I think it's nicer to explain why
> we couldn't evaluate the expression.
> 
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> 
>   PR c++/107574
> 
> gcc/cp/ChangeLog:
> 
>   * constexpr.cc (cxx_eval_constant_expression): Emit an error when
>   a PTRMEM_CST cannot be evaluated.
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/cpp0x/ptrmem-cst1.C: New test.
> ---
>  gcc/cp/constexpr.cc  |  9 +
>  gcc/testsuite/g++.dg/cpp0x/ptrmem-cst1.C | 11 +++
>  2 files changed, 20 insertions(+)
>  create mode 100644 gcc/testsuite/g++.dg/cpp0x/ptrmem-cst1.C
> 
> diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
> index 5b31f9c27d1..2c03988b097 100644
> --- a/gcc/cp/constexpr.cc
> +++ b/gcc/cp/constexpr.cc
> @@ -7691,6 +7691,15 @@ cxx_eval_constant_expression (const constexpr_ctx 
> *ctx, tree t,
>   if (!same_type_ignoring_top_level_qualifiers_p (type, TREE_TYPE 
> (op))
>   && !can_convert_qual (type, op))
> op = cplus_expand_constant (op);
> + if (TREE_CODE (op) == PTRMEM_CST && !TYPE_PTRMEM_P (type))
> +   {
> + if (!ctx->quiet)
> +   error_at (loc, "%qE is not a constant expression when the "
> + "class %qT is still incomplete", op,
> + PTRMEM_CST_CLASS (op));
> + *non_constant_p = true;
> + return t;
> +   }
>   return cp_fold_convert (type, op);
> }
>  
> diff --git a/gcc/testsuite/g++.dg/cpp0x/ptrmem-cst1.C 
> b/gcc/testsuite/g++.dg/cpp0x/ptrmem-cst1.C
> new file mode 100644
> index 000..0d6a6b6445d
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp0x/ptrmem-cst1.C
> @@ -0,0 +1,11 @@
> +// PR c++/107574
> +// { dg-do compile { target c++11 } }
> +
> +struct A { int i; };
> +struct B:A { int j; };
> +struct C:B {
> +  int k;
> +  static_assert((int B::*) &C::k, ""); // { dg-error "non-constant|still 
> incomplete" }
> +};
> +
> +static_assert((int B::*) &C::k, "");
> 
> base-commit: 07c87fce63541846ca2951e22dac04fcaa66475f
> -- 
> 2.39.1
> 

Marek

Re: [PATCH v4] c++: -Wdangling-reference with reference wrapper [PR107532]

[Marek Polacek via Gcc-patches]

Ping.

On Tue, Feb 07, 2023 at 11:46:10AM -0500, Marek Polacek wrote:
> On Sun, Feb 05, 2023 at 05:25:25PM -0800, Jason Merrill wrote:
> > On 1/24/23 17:49, Marek Polacek wrote:
> > > On Fri, Jan 20, 2023 at 03:19:54PM -0500, Jason Merrill wrote:
> > > > On 1/19/23 21:03, Marek Polacek wrote:
> > > > > On Thu, Jan 19, 2023 at 01:02:02PM -0500, Jason Merrill wrote:
> > > > > > On 1/18/23 20:13, Marek Polacek wrote:
> > > > > > > On Wed, Jan 18, 2023 at 04:07:59PM -0500, Jason Merrill wrote:
> > > > > > > > On 1/18/23 12:52, Marek Polacek wrote:
> > > > > > > > > Here, -Wdangling-reference triggers where it probably 
> > > > > > > > > shouldn't, causing
> > > > > > > > > some grief.  The code in question uses a reference wrapper 
> > > > > > > > > with a member
> > > > > > > > > function returning a reference to a subobject of a 
> > > > > > > > > non-temporary object:
> > > > > > > > > 
> > > > > > > > >   const Plane & meta = fm.planes().inner();
> > > > > > > > > 
> > > > > > > > > I've tried a few approaches, e.g., checking that the member 
> > > > > > > > > function's
> > > > > > > > > return type is the same as the type of the enclosing class 
> > > > > > > > > (which is
> > > > > > > > > the case for member functions returning *this), but that then 
> > > > > > > > > breaks
> > > > > > > > > Wdangling-reference4.C with std::optional.
> > > > > > > > > 
> > > > > > > > > So I figured that perhaps we want to look at the object we're 
> > > > > > > > > invoking
> > > > > > > > > the member function(s) on and see if that is a temporary, as 
> > > > > > > > > in, don't
> > > > > > > > > warn about
> > > > > > > > > 
> > > > > > > > >   const Plane & meta = fm.planes().inner();
> > > > > > > > > 
> > > > > > > > > but do warn about
> > > > > > > > > 
> > > > > > > > >   const Plane & meta = FrameMetadata().planes().inner();
> > > > > > > > > 
> > > > > > > > > It's ugly, but better than asking users to add #pragmas into 
> > > > > > > > > their code.
> > > > > > > > 
> > > > > > > > Hmm, that doesn't seem right; the former is only OK because Ref 
> > > > > > > > is in fact a
> > > > > > > > reference-like type.  If planes() returned a class that held 
> > > > > > > > data, we would
> > > > > > > > want to warn.
> > > > > > > 
> > > > > > > Sure, it's always some kind of tradeoff with warnings :/.
> > > > > > > > In this case, we might recognize the reference-like class 
> > > > > > > > because it has a
> > > > > > > > reference member and a constructor taking the same reference 
> > > > > > > > type.
> > > > > > > 
> > > > > > > That occurred to me too, but then I found out that 
> > > > > > > std::reference_wrapper
> > > > > > > actually uses T*, not T&, as you say.  But here's a patch to do 
> > > > > > > that
> > > > > > > (I hope).
> > > > > > > > That wouldn't help with std::reference_wrapper or std::ref_view 
> > > > > > > > because they
> > > > > > > > have pointer members instead of references, but perhaps 
> > > > > > > > loosening the check
> > > > > > > > to include that case would make sense?
> > > > > > > 
> > > > > > > Sorry, I don't understand what you mean by loosening the check.  
> > > > > > > I could
> > > > > > > hardcode std::reference_wrapper and std::ref_view but I don't 
> > > > > > > think that's
> > > > > > > what you meant.
> > > > > > 
> > > > > > Indeed that's not what I meant, but as I was saying in our meeting 
> > > > > > I think
> > > > > > it's worth doing; the compiler has various tweaks to handle specific
> > > > > > standard-library classes better.
> > > > > Okay, done in the patch below.  Except that I'm not including a test 
> > > > > for
> > > > > std::ranges::ref_view because I don't really know how that works.
> > > > > 
> > > > > > > Surely I cannot _not_ warn for any class that contains a T*.
> > > > > > 
> > > > > > I was thinking if a constructor takes a T& and the class has a T* 
> > > > > > that would
> > > > > > be close enough, though this also wouldn't handle the standard 
> > > > > > library
> > > > > > classes so the benefit is questionable.
> > > > > > 
> > > > > > > Here's the patch so that we have some actual code to discuss...  
> > > > > > > Thanks.
> > > > > > > 
> > > > > > > -- >8 --
> > > > > > > Here, -Wdangling-reference triggers where it probably shouldn't, 
> > > > > > > causing
> > > > > > > some grief.  The code in question uses a reference wrapper with a 
> > > > > > > member
> > > > > > > function returning a reference to a subobject of a non-temporary 
> > > > > > > object:
> > > > > > > 
> > > > > > >  const Plane & meta = fm.planes().inner();
> > > > > > > 
> > > > > > > I've tried a few approaches, e.g., checking that the member 
> > > > > > > function's
> > > > > > > return type is the same as the type of the enclosing class (which 
> > > > > > > is
> > > > > > > the case for member functions returning *this), but that then 
> > > > > > > breaks
> > > > > > > Wdangling-reference4.C with std::optional.
> > > > > > > 
>

[PATCH] c++: ICE with -Wmismatched-tags and member template [PR106259]

[Marek Polacek via Gcc-patches]

-Wmismatched-tags warns about the (harmless) struct/class mismatch.
For, e.g.,

  template struct A { };
  class A a;

it works by adding A to the class2loc hash table while parsing the
class-head and then, while parsing the elaborate type-specifier, we
add A.  At the end of c_parse_file we go through the table and
warn about the class-key mismatches.  In this PR we crash though; we
have

  template struct A {
template struct W { };
  };
  struct A::W w; // #1

where while parsing A and #1 we've stashed
   A
   A::W
   A::W
into class2loc.  Then in class_decl_loc_t::diag_mismatched_tags TYPE
is A::W, and specialization_of gets us A::W, which
is not in class2loc, so we crash on gcc_assert (cdlguide).  But it's
OK not to have found A::W, we should just look one "level" up,
that is, A::W.

It's important to handle class specializations, so e.g.

  template<>
  struct A {
template
class W { };
  };

where W's class-key is different than in the primary template above,
so we should warn depending on whether we're looking into A
or into a different instantiation.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

PR c++/106259

gcc/cp/ChangeLog:

* parser.cc (class_decl_loc_t::diag_mismatched_tags): If the first
lookup of SPEC didn't find anything, try to look for
most_general_template.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wmismatched-tags-11.C: New test.
---
 gcc/cp/parser.cc  | 30 +++
 .../g++.dg/warn/Wmismatched-tags-11.C | 23 ++
 2 files changed, 47 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/warn/Wmismatched-tags-11.C

diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 1a124f5395e..b528ee7b1d9 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -34473,14 +34473,32 @@ class_decl_loc_t::diag_mismatched_tags (tree 
type_decl)
 be (and inevitably is) at index zero.  */
   tree spec = specialization_of (type);
   cdlguide = class2loc.get (spec);
+  /* It's possible that we didn't find SPEC.  Consider:
+
+  template struct A {
+template struct W { };
+  };
+  struct A::W w; // #1
+
+where while parsing A and #1 we've stashed
+  A
+  A::W
+  A::W
+into CLASS2LOC.  If TYPE is A::W, specialization_of
+will yield A::W which may be in CLASS2LOC if we had
+an A class specialization, but otherwise won't be in it.
+So try to look up A::W.  */
+  if (!cdlguide)
+   {
+ spec = DECL_TEMPLATE_RESULT (most_general_template (spec));
+ cdlguide = class2loc.get (spec);
+   }
+  /* Now we really should have found something.  */
   gcc_assert (cdlguide != NULL);
 }
-  else
-{
-  /* Skip declarations that consistently use the same class-key.  */
-  if (def_class_key != none_type)
-   return;
-}
+  /* Skip declarations that consistently use the same class-key.  */
+  else if (def_class_key != none_type)
+return;
 
   /* Set if a definition for the class has been seen.  */
   const bool def_p = cdlguide->def_p ();
diff --git a/gcc/testsuite/g++.dg/warn/Wmismatched-tags-11.C 
b/gcc/testsuite/g++.dg/warn/Wmismatched-tags-11.C
new file mode 100644
index 000..6c4e571726a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wmismatched-tags-11.C
@@ -0,0 +1,23 @@
+// PR c++/106259
+// { dg-do compile }
+// { dg-options "-Wmismatched-tags" }
+
+template struct A {
+  template
+  struct W { };
+};
+
+template<>
+struct A {
+  template
+  class W { };
+};
+
+void
+g ()
+{
+  struct A::W w1; // { dg-warning "mismatched" }
+  struct A::W w2;
+  class A::W w3;
+  class A::W w4; // { dg-warning "mismatched" }
+}

base-commit: 096f034a8f5df41f610e62c1592fb90a3f551cd5
-- 
2.39.2

Re: [PATCH] debug/108772 - ICE with late debug generated with -flto

[Jason Merrill via Gcc-patches]

On 3/1/23 08:09, Jakub Jelinek wrote:

On Wed, Mar 01, 2023 at 01:07:02PM +, Richard Biener wrote:

When combining -g1 with -flto we run into the DIE location annotation
machinery for globals calling dwarf2out_late_global_decl but not
having any early generated DIE for function scope statics.  In
this process we'd generate a limbo DIE since also the function scope
doesn't have any early generated DIE.  The limbo handling then tries
to force a DIE for the context chain which ultimatively fails and
ICEs at the std namespace decl because at -g1 we don't represent that.

The following avoids this situation by making sure to never generate
any limbo DIEs from dwarf2out_late_global_decl in the in_lto_p path
but instead for function scope globals rely on DIE generation for
the function to output a DIE for the local static (which doesn't
happen for -g1).


So the issue is that we're trying to force out a DIE for a decl that we 
wouldn't have generated without -flto?  How is it avoided in the non-LTO 
case?



I explored a lot of other options to fix this but in the end this
seems to be the most spot-on fix with the least risk of unwanted
effects.

LTO bootstrapped on x86_64-unknown-linux-gnu (running into PR108984),
bootstrapped and tested on x86_64-unknown-linux-gnu.

OK?

Thanks,
Richard.

PR debug/108772
* dwarf2out.cc (dwarf2out_late_global_decl): Do not
generate a DIE for a function scope static when we do
not have a DIE for the function already.

* g++.dg/lto/pr108772_0.C: New testcase.


LGTM, but please give Jason a day to chime in if he disagrees.

Jakub

Re: [PATCH] RISC-V: costs: miscomputed shiftadd_cost triggering synth_mult [PR/108987]

[Philipp Tomsich]

On Wed, 1 Mar 2023 at 20:53, Vineet Gupta  wrote:
>
> This showed up as dynamic icount regression in SPEC 531.deepsjeng with 
> upstream
> gcc (vs. gcc 12.2). gcc was resorting to synthetic multiply using shift+add(s)
> even when multiply had clear cost benefit.
>
> |000133b8  .constprop.0]+0x382>:
> |   133b8:  srl a3,a1,s6
> |   133bc:  and a3,a3,s5
> |   133c0:  sllia4,a3,0x9
> |   133c4:  add a4,a4,a3
> |   133c6:  sllia4,a4,0x9
> |   133c8:  add a4,a4,a3
> |   133ca:  sllia3,a4,0x1b
> |   133ce:  add a4,a4,a3
>
> vs. gcc 12 doing something lke below.
>
> |000131c4  .constprop.0]+0x35c>:
> |   131c4:  ld  s1,8(sp)
> |   131c6:  srl a3,a1,s4
> |   131ca:  and a3,a3,s11
> |   131ce:  mul a3,a3,s1
>
> Bisected this to f90cb39235c4 ("RISC-V: costs: support shift-and-add in
> strength-reduction"). The intent was to optimize cost for
> shift-add-pow2-{1,2,3} corresponding to bitmanip insns SH*ADD, but ended
> up doing that for all shift values which seems to favor synthezing
> multiply among others.
>
> The bug itself is trivial, IN_RANGE() calling pow2p_hwi() which returns bool
> vs. exact_log2() returning power of 2.
>
> This fix also requires update to the test introduced by the same commit
> which now generates MUL vs. synthesizing it.
>
> gcc/Changelog:
>
> * config/riscv/riscv.cc (riscv_rtx_costs): Fixed IN_RANGE() to
>   use exact_log2().
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/zba-shNadd-07.c: f2(i*783) now generates MUL vs.
>   5 insn sh1add+slli+add+slli+sub.
> * gcc.target/riscv/pr108987.c: New test.
>
> Signed-off-by: Vineet Gupta 

Reviewed-by: Philipp Tomsich 

[PATCH] RISC-V: costs: miscomputed shiftadd_cost triggering synth_mult [PR/108987]

[Vineet Gupta]

This showed up as dynamic icount regression in SPEC 531.deepsjeng with upstream
gcc (vs. gcc 12.2). gcc was resorting to synthetic multiply using shift+add(s)
even when multiply had clear cost benefit.

|000133b8 :
|   133b8:  srl a3,a1,s6
|   133bc:  and a3,a3,s5
|   133c0:  sllia4,a3,0x9
|   133c4:  add a4,a4,a3
|   133c6:  sllia4,a4,0x9
|   133c8:  add a4,a4,a3
|   133ca:  sllia3,a4,0x1b
|   133ce:  add a4,a4,a3

vs. gcc 12 doing something lke below.

|000131c4 :
|   131c4:  ld  s1,8(sp)
|   131c6:  srl a3,a1,s4
|   131ca:  and a3,a3,s11
|   131ce:  mul a3,a3,s1

Bisected this to f90cb39235c4 ("RISC-V: costs: support shift-and-add in
strength-reduction"). The intent was to optimize cost for
shift-add-pow2-{1,2,3} corresponding to bitmanip insns SH*ADD, but ended
up doing that for all shift values which seems to favor synthezing
multiply among others.

The bug itself is trivial, IN_RANGE() calling pow2p_hwi() which returns bool
vs. exact_log2() returning power of 2.

This fix also requires update to the test introduced by the same commit
which now generates MUL vs. synthesizing it.

gcc/Changelog:

* config/riscv/riscv.cc (riscv_rtx_costs): Fixed IN_RANGE() to
  use exact_log2().

gcc/testsuite/ChangeLog:

* gcc.target/riscv/zba-shNadd-07.c: f2(i*783) now generates MUL vs.
  5 insn sh1add+slli+add+slli+sub.
* gcc.target/riscv/pr108987.c: New test.

Signed-off-by: Vineet Gupta 
---
 gcc/config/riscv/riscv.cc  | 3 ++-
 gcc/testsuite/gcc.target/riscv/pr108987.c  | 9 +
 gcc/testsuite/gcc.target/riscv/zba-shNadd-07.c | 6 +++---
 3 files changed, 14 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/pr108987.c

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index e36ff05695a6..2cf172f59c28 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -2496,7 +2496,8 @@ riscv_rtx_costs (rtx x, machine_mode mode, int 
outer_code, int opno ATTRIBUTE_UN
  && GET_CODE (XEXP (x, 0)) == MULT
  && REG_P (XEXP (XEXP (x, 0), 0))
  && CONST_INT_P (XEXP (XEXP (x, 0), 1))
- && IN_RANGE (pow2p_hwi (INTVAL (XEXP (XEXP (x, 0), 1))), 1, 3))
+ && pow2p_hwi (INTVAL (XEXP (XEXP (x, 0), 1)))
+ && IN_RANGE (exact_log2 (INTVAL (XEXP (XEXP (x, 0), 1))), 1, 3))
{
  *total = COSTS_N_INSNS (1);
  return true;
diff --git a/gcc/testsuite/gcc.target/riscv/pr108987.c 
b/gcc/testsuite/gcc.target/riscv/pr108987.c
new file mode 100644
index ..6179c7e13a45
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/pr108987.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gc_zba -mabi=lp64 -O2" } */
+
+unsigned long long f5(unsigned long long i)
+{
+  return i * 0x0202020202020202ULL;
+}
+
+/* { dg-final { scan-assembler-times "mul" 1 } } */
diff --git a/gcc/testsuite/gcc.target/riscv/zba-shNadd-07.c 
b/gcc/testsuite/gcc.target/riscv/zba-shNadd-07.c
index 98d35e1da9b4..93da241c9b60 100644
--- a/gcc/testsuite/gcc.target/riscv/zba-shNadd-07.c
+++ b/gcc/testsuite/gcc.target/riscv/zba-shNadd-07.c
@@ -26,6 +26,6 @@ f4 (unsigned long i)
 }
 
 /* { dg-final { scan-assembler-times "sh2add" 2 } } */
-/* { dg-final { scan-assembler-times "sh1add" 2 } } */
-/* { dg-final { scan-assembler-times "slli" 5 } } */
-/* { dg-final { scan-assembler-times "mul" 1 } } */
+/* { dg-final { scan-assembler-times "sh1add" 1 } } */
+/* { dg-final { scan-assembler-times "slli" 3 } } */
+/* { dg-final { scan-assembler-times "mul" 2 } } */
-- 
2.34.1

Re: [PATCH] c++: unevaluated array new-expr size constantness [PR108219]

[Patrick Palka via Gcc-patches]

On Wed, 1 Mar 2023, Jason Merrill wrote:

> On 3/1/23 12:20, Patrick Palka wrote:
> > On Wed, 1 Mar 2023, Jason Merrill wrote:
> > 
> > > On 3/1/23 10:32, Patrick Palka wrote:
> > > > On Mon, 27 Feb 2023, Jason Merrill wrote:
> > > > 
> > > > > On 2/22/23 14:45, Patrick Palka wrote:
> > > > > > Here we're mishandling the unevaluated array new-expressions due to
> > > > > > a
> > > > > > supposed non-constant array size ever since
> > > > > > r12-5253-g4df7f8c79835d569,
> > > > > > made us no longer perform constant evaluation of
> > > > > > non-manifestly-constant
> > > > > > expressions within unevaluated contexts.  This shouldn't make a
> > > > > > difference here since the array sizes are constant literals, except
> > > > > > they're actually NON_LVALUE_EXPR location wrappers wrapping
> > > > > > INTEGER_CST,
> > > > > > wrappers which used to get stripped as part of constant evaluation
> > > > > > and
> > > > > > now no longer do.  Moreover it means build_vec_init can't constant
> > > > > > fold
> > > > > > the 'maxindex' passed from build_new_1 (since it uses
> > > > > > maybe_constant_value
> > > > > > with mce_unknown).
> > > > > 
> > > > > Hmm, now that you mention it I think the
> > > > > 
> > > > > if (manifestly_const_eval != mce_unknown)
> > > > > 
> > > > > change in maybe_constant_value isn't quite right, we don't want to
> > > > > force
> > > > > evaluation in unevaluated mce_false context either.
> > > > 
> > > > Ah, makes sense.  Fixed in the below patch.
> > > > 
> > > > > 
> > > > > > This patch fixes the first issue by making maybe_constant_value and
> > > > > > fold_non_dependent_expr_template shortcut handling location wrappers
> > > > > > around constant nodes, and the second issue by using fold_build2_loc
> > > > > > instead of cp_build_binary_op when computing the maxindex to pass to
> > > > > > build_vec_init.
> > > > > 
> > > > > Maybe in unevaluated mce_unknown/false context maybe_constant_value
> > > > > should
> > > > > call fold?
> > > > 
> > > > That seems like a good compromise between proper constant evaluation
> > > > and not constant evaluating at all, though I wonder how 'fold' behaves
> > > > w.r.t. to undefined behavior such as division by zero and signed
> > > > overflow?
> > > 
> > > 'fold' doesn't fold division by zero, but I think we should only return
> > > the
> > > result of 'fold' at this point if it is in fact constant, not if it's a
> > > non-constant simplification.
> > 
> > Sounds good, I wasn't sure if 'fold' could return a non-constant
> > simplification.
> 
> Yep, it also folds e.g. x*1 to x.
> 
> > I suppose we want to be pretty conservative with the
> > constantness test, so I went with CONSTANT_CLASS_P && !TREE_OVERFLOW.
> 
> Makes sense.
> 
> > Like so?  Smoke tested so far, bootstrap and regtest on
> > x86_64-pc-linu-xgnu in progress.
> > 
> > -- >8 --
> > 
> > Subject: [PATCH] c++: unevaluated array new-expr size constantness
> > [PR108219]
> > 
> > Here we're mishandling the unevaluated array new-expressions due to a
> > supposed non-constant array size ever since r12-5253-g4df7f8c79835d569
> > made us no longer perform constant evaluation of non-manifestly-constant
> > expressions within unevaluated contexts.  This shouldn't make a
> > difference here since the array sizes are constant literals, except
> > these sizes are expressed as NON_LVALUE_EXPR location wrappers around
> > INTEGER_CST, wrappers which used to get stripped as part of constant
> > evaluation and now no longer do.  Moreover it means build_vec_init can't
> > constant fold the 'maxindex' passed from build_new_1 (since it uses
> > maybe_constant_value with mce_unknown).
> > 
> > This patch fixes this by making maybe_constant_value and
> > fold_non_dependent_expr at least try folding simple unevaluated operands
> > via fold(), which will evaluate simple arithmetic, look through location
> > wrappers, perform integral conversions, etc.
> > 
> > Co-authored-by: Jason Merrill 
> > 
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk/12?
> > 
> > PR c++/108219
> > PR c++/108218
> > 
> > gcc/cp/ChangeLog:
> > 
> > * constexpr.cc (maybe_constant_value): Move up early exit
> > test for unevaluated operands.  Try reducing an unevaluated
> > operand to a constant via fold.
> > (fold_non_dependent_expr_template): Add early exit test for
> > CONSTANT_CLASS_P nodes.  Try reducing an unevaluated operand
> > to a constant via fold.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * g++.dg/cpp0x/new6.C: New test.
> > * g++.dg/cpp2a/concepts-new1.C: New test.
> > ---
> >   gcc/cp/constexpr.cc| 23 +-
> >   gcc/testsuite/g++.dg/cpp0x/new6.C  | 13 
> >   gcc/testsuite/g++.dg/cpp2a/concepts-new1.C | 13 
> >   3 files changed, 44 insertions(+), 5 deletions(-)
> >   create mode 100644 gcc/testsuite/g++.dg/cpp0x/new6.C
> >   create mode 100644 gcc/testsuite

Re: libquadmath fix for 94756 and 87204

[Jakub Jelinek via Gcc-patches]

On Sat, Jan 21, 2023 at 04:31:52PM +, i.nixman--- via Gcc-patches wrote:
> > Why?
> 
> could you explain which of the nine lines are you talking about?

All the uselessly changed ones.

> > As for the rest, it would help if you could list the exact glibc commits
> > which you've ported to libquadmath and indicate if it is solely those
> > and nothing else.
> 
> I'm sorry but it was not my intention to remember exactly which commits I
> was looking at...
> I didn't think about it.

Because this isn't a complete update to latest glibc source, I think it is
quite important to document what has been merged for reproducibility etc.

> --- a/libquadmath/printf/gmp-impl.h
> +++ b/libquadmath/printf/gmp-impl.h
> @@ -33,15 +33,24 @@ MA 02111-1307, USA. */
>  #define MAX(h,i) ((h) > (i) ? (h) : (i))
>  #endif
>  
> -#define BITS_PER_MP_LIMB (__SIZEOF_LONG__ * __CHAR_BIT__)
> -#define BYTES_PER_MP_LIMB (BITS_PER_MP_LIMB / __CHAR_BIT__)
> -typedef unsigned long intmp_limb_t;
> -typedef long int mp_limb_signed_t;
> +#ifdef __MINGW32__ && defined(__x86_64__)

This isn't valid in C, so it is unclear how it was actually tested.
Furthermore, as I said earlier, I think we should change only the
absolute minimum, not reformat stuff, etc.
And, I really don't like to base this on mingw32, doesn't say cygwin
want to do the same?  So, I think it is much better to base this
on LLP64.

> --- a/libquadmath/strtod/strtod_l.c
> +++ b/libquadmath/strtod/strtod_l.c

As for the strtod_l.c changes, I went through all of them, found
the corresponding glibc commits and backported them one by one
(plus one follow-up).  Changes in this file from your version to
mine are in the second hunk which was weirdly indented compared to
surrounding code, and some comments.

So, here is what I'd like to commit instead.
I've tested on x86_64-linux -m32/-m64 the testcases from both of the
PRs without/with the patch and while without the patch the output
differed between -m32/-m64, with the patch it doesn't.

I'll bootstrap/regtest this tonight on x86_64-linux and i686-linux,
though I don't have a way to test this on mingw32 nor cygwin.

2023-03-01  niXman  
Jakub Jelinek  

PR libquadmath/87204
PR libquadmath/94756
* printf/gmp-impl.h (mp_limb_t, mp_limb_signed_t, BITS_PER_MP_LIMB):
Use 64-bit limbs on LLP64 targets.
* strtod/strtod_l.c (round_and_return): Cherry-pick glibc
9310c284ae9 BZ #16151, 4406c41c1d6 BZ #16965 and fcd6b5ac36a
BZ #23279 fixes.
(STRTOF_INTERNAL): Cherry-pick glibc b0debe14fcf BZ #23007,
5556d30caee BZ #18247, 09555b9721d and c6aac3bf366 BZ #26137 and
d84f25c7d87 fixes.

--- libquadmath/printf/gmp-impl.h.jj2020-01-12 11:54:39.787362505 +0100
+++ libquadmath/printf/gmp-impl.h   2023-03-01 18:40:07.696374919 +0100
@@ -33,10 +33,18 @@ MA 02111-1307, USA. */
 #define MAX(h,i) ((h) > (i) ? (h) : (i))
 #endif
 
+#if __SIZEOF_LONG__ == 4 && __SIZEOF_LONG_LONG__ == 8 \
+&& __SIZEOF_POINTER__ == 8
+/* Use 64-bit limbs on LLP64 targets.  */
+#define BITS_PER_MP_LIMB (__SIZEOF_LONG_LONG__ * __CHAR_BIT__)
+typedef unsigned long long int mp_limb_t;
+typedef long long int  mp_limb_signed_t;
+#else
 #define BITS_PER_MP_LIMB (__SIZEOF_LONG__ * __CHAR_BIT__)
-#define BYTES_PER_MP_LIMB (BITS_PER_MP_LIMB / __CHAR_BIT__)
 typedef unsigned long int  mp_limb_t;
 typedef long int   mp_limb_signed_t;
+#endif
+#define BYTES_PER_MP_LIMB (BITS_PER_MP_LIMB / __CHAR_BIT__)
 
 typedef mp_limb_t * mp_ptr;
 typedef const mp_limb_t *  mp_srcptr;
--- libquadmath/strtod/strtod_l.c.jj2020-01-12 11:54:39.788362490 +0100
+++ libquadmath/strtod/strtod_l.c   2023-03-01 18:59:49.490151048 +0100
@@ -200,7 +200,7 @@ round_and_return (mp_limb_t *retval, int
 
  round_limb = retval[RETURN_LIMB_SIZE - 1];
  round_bit = (MANT_DIG - 1) % BITS_PER_MP_LIMB;
- for (i = 0; i < RETURN_LIMB_SIZE; ++i)
+ for (i = 0; i < RETURN_LIMB_SIZE - 1; ++i)
more_bits |= retval[i] != 0;
  MPN_ZERO (retval, RETURN_LIMB_SIZE);
}
@@ -215,9 +215,14 @@ round_and_return (mp_limb_t *retval, int
  more_bits |= ((round_limb & mp_limb_t) 1) << round_bit) - 1))
!= 0);
 
- (void) mpn_rshift (retval, &retval[shift / BITS_PER_MP_LIMB],
-RETURN_LIMB_SIZE - (shift / BITS_PER_MP_LIMB),
-shift % BITS_PER_MP_LIMB);
+ /* mpn_rshift requires 0 < shift < BITS_PER_MP_LIMB.  */
+ if ((shift % BITS_PER_MP_LIMB) != 0)
+   (void) mpn_rshift (retval, &retval[shift / BITS_PER_MP_LIMB],
+  RETURN_LIMB_SIZE - (shift / BITS_PER_MP_LIMB),
+  shift % BITS_PER_MP_LIMB);
+ else
+   for (i = 0; i < RETURN_LIMB_SIZE - (shift / BITS_PER_MP_LIMB); i++)
+ retval[i] = retval[i + (shift / BITS_PER_MP_LIMB

RE: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583]

[Tamar Christina via Gcc-patches]

> -Original Message-
> From: Andrew Carlotti 
> Sent: Wednesday, March 1, 2023 4:58 PM
> To: Andrew MacLeod 
> Cc: Tamar Christina ; Richard Biener
> ; Richard Sandiford ;
> Tamar Christina via Gcc-patches ; nd
> ; j...@ventanamicro.com
> Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask
> by using new optabs [PR108583]
> 
> On Thu, Feb 23, 2023 at 11:39:51AM -0500, Andrew MacLeod via Gcc-
> patches wrote:
> >
> >
> > Inheriting from operator_mult is also going to be hazardous because it
> > also has an op1_range and op2_range...� you should at least define
> > those and return VARYING to avoid other issues.� Same thing applies
> > to widen_plus I think, and it has relation processing and other things
> > as well.� Your widen operands are not what those classes expect, so
> > I think you probably just want a fresh range operator.
> >
> > It also looks like the mult operation is sign/zero extending both
> > upper bounds, and neither lower bound..�� I think that should be
> > the LH upper and lower bound?
> >
> > I've attached a second patch� (newversion.patch) which incorporates
> > my fix, the fix to the sign of only op1's bounds,� as well as a
> > simplification of the classes to not inherit from
> > operator_mult/plus..�� I think this still does what you want?�
> > and it wont get you into unexpected trouble later :-)
> >
> > let me know if this is still doing what you are expecting...
> >
> > Andrew
> >
> 
> Hi,
> 
> This patch still uses the wrong signedness for some of the extensions in
> WIDEN_MULT_EXPR. It currently bases it's promotion decisions on whether
> there is any signed argument, and whether the result is signed - i.e.:
> 
>   Patch extends as:
> UUU   UU
> UUS -> USU
> USU   SU
> USS   SU  wrong
> SUU   US  wrong
> SUS -> SSU
> SSU   SS  wrong
> SSS   SS
> 
> The documentation in tree.def is unclear about whether the output
> signedness is linked to the input signedness, but at least the SSU case seems
> valid, and is mishandled here.

Hi,

Thanks for the concern, but I don't think those "wrong" cases are valid.
There's only one explicit carve-out for this mismatch that I'm aware of which is
for constants that fit in the source type.  convert_mult_to_widen doesn't accept
them otherwise.

For every other mismatched sign it will fold an explicit convert into the 
sequence
to ensure all three types match.

i.e. 

long unsigned d1(int x, int y)
{
return (long unsigned)x * y;
}

Requires a cast.

long unsigned d1(int x, int y)
{
return (long unsigned)x * 4;
}

Does not, and

long unsigned d1(int x, int y)
{
return (long unsigned)x * -4;
}

Does not fit and so is not accepted.  The reason it can happen is that the 
unsigned
cast on a positive constant is discarded.

Further more, the operation that introduces this widening only looks at the 
sign of the left
most operand and that of the result.

So this is correctly handling the normal cases and the abnormal ones the 
compiler introduces
as specific optimizations.

Tamar.


> 
> I think it would be clearer and simpler to have four (or three) different 
> versions
> for each combnation of signedness of the input operands. This could be
> implemented without extra code duplication by creating four different
> instances of an operator_widen_mult class (perhaps extending a
> range_operator_mixed_sign class), with the signedness indicated by two
> additional class members.
> 
> The documentation for WIDEN_PLUS_EXPR (and several other expressions
> added in the same commit) is completely missing. If the signs are required to
> be matching, then this should be clarified; otherwise it would need the same
> special handling as WIDEN_MULT_EXPR.
> 
> Andrew
> 
> > diff --git a/gcc/gimple-range-op.cc b/gcc/gimple-range-op.cc index
> > d9dfdc56939..824e0338f34 100644
> > --- a/gcc/gimple-range-op.cc
> > +++ b/gcc/gimple-range-op.cc
> > @@ -179,6 +179,8 @@
> gimple_range_op_handler::gimple_range_op_handler (gimple *s)
> >// statements.
> >if (is_a  (m_stmt))
> >  maybe_builtin_call ();
> > +  else
> > +maybe_non_standard ();
> >  }
> >
> >  // Calculate what we can determine of the range of this unary @@
> > -764,6 +766,36 @@ public:
> >}
> >  } op_cfn_parity;
> >
> > +// Set up a gimple_range_op_handler for any nonstandard function
> > +which can be // supported via range-ops.
> > +
> > +void
> > +gimple_range_op_handler::maybe_non_standard () {
> > +  if (gimple_code (m_stmt) == GIMPLE_ASSIGN)
> > +switch (gimple_assign_rhs_code (m_stmt))
> > +  {
> > +   case WIDEN_MULT_EXPR:
> > +   {
> > + m_valid = true;
> > + m_op1 = gimple_assign_rhs1 (m_stmt);
> > + m_op2 = gimple_assign_rhs2 (m_stmt);
> > + bool signed1 = TYPE_SIGN (TREE_TYPE (m_op1)) == SIGNED;
> > + bool signed2 = TYPE_SIGN (TREE_TYPE (m_op2)) == SIGNED;
> > + if (signed2 && !signed1)
> > +   std::swap (m_op1

[PATCH 8/8] aarch64: testsuite: disable stack protector for tests relying on stack offset

[Xi Ruoyao via Gcc-patches]

Stack protector needs a guard value on the stack and change the stack
layout.  So we need to disable it for those tests, to avoid test failure
with --enable-default-ssp.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/shrink_wrap_1.c (dg-options): Add
-fno-stack-protector.
* gcc.target/aarch64/stack-check-cfa-1.c (dg-options): Add
-fno-stack-protector.
* gcc.target/aarch64/stack-check-cfa-2.c (dg-options): Add
-fno-stack-protector.
* gcc.target/aarch64/test_frame_17.c (dg-options): Add
-fno-stack-protector.
---
 gcc/testsuite/gcc.target/aarch64/shrink_wrap_1.c | 2 +-
 gcc/testsuite/gcc.target/aarch64/stack-check-cfa-1.c | 2 +-
 gcc/testsuite/gcc.target/aarch64/stack-check-cfa-2.c | 2 +-
 gcc/testsuite/gcc.target/aarch64/test_frame_17.c | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/gcc.target/aarch64/shrink_wrap_1.c 
b/gcc/testsuite/gcc.target/aarch64/shrink_wrap_1.c
index ab7cd74ec3b..067220c04a0 100644
--- a/gcc/testsuite/gcc.target/aarch64/shrink_wrap_1.c
+++ b/gcc/testsuite/gcc.target/aarch64/shrink_wrap_1.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target { aarch64*-*-* } } } */
-/* { dg-options "-O2" } */
+/* { dg-options "-O2 -fno-stack-protector" } */
 /* { dg-final { check-function-bodies "**" "" } } */
 
 /*
diff --git a/gcc/testsuite/gcc.target/aarch64/stack-check-cfa-1.c 
b/gcc/testsuite/gcc.target/aarch64/stack-check-cfa-1.c
index 6885894a97e..412a9ed1aab 100644
--- a/gcc/testsuite/gcc.target/aarch64/stack-check-cfa-1.c
+++ b/gcc/testsuite/gcc.target/aarch64/stack-check-cfa-1.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fstack-clash-protection --param 
stack-clash-protection-guard-size=16 -funwind-tables" } */
+/* { dg-options "-O2 -fstack-clash-protection --param 
stack-clash-protection-guard-size=16 -funwind-tables -fno-stack-protector" } */
 /* { dg-require-effective-target supports_stack_clash_protection } */
 
 #define SIZE 128*1024
diff --git a/gcc/testsuite/gcc.target/aarch64/stack-check-cfa-2.c 
b/gcc/testsuite/gcc.target/aarch64/stack-check-cfa-2.c
index 5796a53be06..e440569a078 100644
--- a/gcc/testsuite/gcc.target/aarch64/stack-check-cfa-2.c
+++ b/gcc/testsuite/gcc.target/aarch64/stack-check-cfa-2.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fstack-clash-protection --param 
stack-clash-protection-guard-size=16 -funwind-tables" } */
+/* { dg-options "-O2 -fstack-clash-protection --param 
stack-clash-protection-guard-size=16 -funwind-tables -fno-stack-protector" } */
 /* { dg-require-effective-target supports_stack_clash_protection } */
 
 #define SIZE 1280*1024 + 512
diff --git a/gcc/testsuite/gcc.target/aarch64/test_frame_17.c 
b/gcc/testsuite/gcc.target/aarch64/test_frame_17.c
index 44f13291128..5d432ad0854 100644
--- a/gcc/testsuite/gcc.target/aarch64/test_frame_17.c
+++ b/gcc/testsuite/gcc.target/aarch64/test_frame_17.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2" } */
+/* { dg-options "-O2 -fno-stack-protector" } */
 
 /* Test reuse of stack adjustment temporaries.  */
 
-- 
2.39.2

[PATCH 5/8] aarch64: testsuite: disable stack protector for pr103147-10 tests

[Xi Ruoyao via Gcc-patches]

Stack protector influence code generation and cause function body checks
fail.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/pr103147-10.c (dg-options): Add
-fno-stack-protector.
* g++.target/aarch64/pr103147-10.C: Likewise.
---
 gcc/testsuite/g++.target/aarch64/pr103147-10.C | 2 +-
 gcc/testsuite/gcc.target/aarch64/pr103147-10.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/g++.target/aarch64/pr103147-10.C 
b/gcc/testsuite/g++.target/aarch64/pr103147-10.C
index 914fdf9c692..e12771533f7 100644
--- a/gcc/testsuite/g++.target/aarch64/pr103147-10.C
+++ b/gcc/testsuite/g++.target/aarch64/pr103147-10.C
@@ -1,4 +1,4 @@
-/* { dg-options "-O2 -fpack-struct -mstrict-align" } */
+/* { dg-options "-O2 -fpack-struct -mstrict-align -fno-stack-protector" } */
 /* { dg-final { check-function-bodies "**" "" "" } } */
 
 #include 
diff --git a/gcc/testsuite/gcc.target/aarch64/pr103147-10.c 
b/gcc/testsuite/gcc.target/aarch64/pr103147-10.c
index b2c34e4155d..57942bfd10a 100644
--- a/gcc/testsuite/gcc.target/aarch64/pr103147-10.c
+++ b/gcc/testsuite/gcc.target/aarch64/pr103147-10.c
@@ -1,4 +1,4 @@
-/* { dg-options "-O2 -fpack-struct -mstrict-align" } */
+/* { dg-options "-O2 -fpack-struct -mstrict-align -fno-stack-protector" } */
 /* { dg-final { check-function-bodies "**" "" "" } } */
 
 #include 
-- 
2.39.2

[PATCH] libiberty: fix memory leak in pex-win32.c and refactor

[Costas Argyris via Gcc-patches]

Hi

It seems that the win32_spawn function in libiberty/pex-win32.c is leaking
the cmdline buffer in 2/3 exit scenarios (it is only free'd in 1/3).The
problem here is that the cleanup code is written 3 times, one at each exit
scenario.

The proposed attached refactoring has the cleanup code appearing just once
and is executed for all exit scenarios, reducing the likelihood of such
leaks in the future.

Thanks,
Costas
From ca1ff7b48db2e30963bd4c0e08ecd6653214a5db Mon Sep 17 00:00:00 2001
From: Costas Argyris 
Date: Sun, 26 Feb 2023 16:34:11 +
Subject: [PATCH] libiberty: fix memory leak in pex-win32.c and refactor

Fix memory leak of cmdline buffer and refactor to have
cleanup code appear once for all exit cases.
---
 libiberty/pex-win32.c | 33 +++--
 1 file changed, 11 insertions(+), 22 deletions(-)

diff --git a/libiberty/pex-win32.c b/libiberty/pex-win32.c
index 02d3a3e839b..82303947de4 100644
--- a/libiberty/pex-win32.c
+++ b/libiberty/pex-win32.c
@@ -577,14 +577,12 @@ win32_spawn (const char *executable,
 	 LPSTARTUPINFO si,
 	 LPPROCESS_INFORMATION pi)
 {
-  char *full_executable;
-  char *cmdline;
+  char *full_executable = NULL;
+  char *cmdline = NULL;
+  pid_t pid = (pid_t) -1;
   char **env_copy;
   char *env_block = NULL;
 
-  full_executable = NULL;
-  cmdline = NULL;
-
   if (env)
 {
   int env_size;
@@ -622,13 +620,13 @@ win32_spawn (const char *executable,
 
   full_executable = find_executable (executable, search);
   if (!full_executable)
-goto error;
+goto exit;
   cmdline = argv_to_cmdline (argv);
   if (!cmdline)
-goto error;
+goto exit;
 
   /* Create the child process.  */  
-  if (!CreateProcess (full_executable, cmdline, 
+  if (CreateProcess (full_executable, cmdline, 
 		  /*lpProcessAttributes=*/NULL,
 		  /*lpThreadAttributes=*/NULL,
 		  /*bInheritHandles=*/TRUE,
@@ -638,26 +636,17 @@ win32_spawn (const char *executable,
 		  si,
 		  pi))
 {
-  free (env_block);
-
-  free (full_executable);
-
-  return (pid_t) -1;
+  CloseHandle (pi->hThread);
+  pid = (pid_t) pi->hProcess;
 }
-
+  
+ exit:
   /* Clean up.  */
-  CloseHandle (pi->hThread);
-  free (full_executable);
-  free (env_block);
-
-  return (pid_t) pi->hProcess;
-
- error:
   free (env_block);
   free (cmdline);
   free (full_executable);
 
-  return (pid_t) -1;
+  return pid;
 }
 
 /* Spawn a script.  This simulates the Unix script execution mechanism.
-- 
2.30.2

[PATCH 2/8] aarch64: testsuite: disable PIE for tests with large code model [PR70150]

[Xi Ruoyao via Gcc-patches]

These tests set large code model with -mcmodel=large or target pragma for
AArch64.  But if GCC is configured with --enable-default-pie, it triggers
"sorry: unimplemented: code model large with -fpic".  Disable PIE to make
avoid the issue.

gcc/testsuite/ChangeLog:

PR testsuite/70150
* gcc.dg/tls/pr78796.c (dg-additional-options): Add -fno-pie
-no-pie for aarch64-*-*.
* gcc.target/aarch64/pr63304_1.c (dg-options): Add -fno-pie.
* gcc.target/aarch64/pr70120-2.c (dg-options): Add -fno-pie.
* gcc.target/aarch64/pr78733.c (dg-options): Add -fno-pie.
* gcc.target/aarch64/pr79041-2.c (dg-options): Add -fno-pie.
* gcc.target/aarch64/pr94530.c (dg-options): Add -fno-pie.
* gcc.target/aarch64/pr94577.c (dg-options): Add -fno-pie.
* gcc.target/aarch64/reload-valid-spoff.c (dg-options): Add
-fno-pie.
---
 gcc/testsuite/gcc.dg/tls/pr78796.c| 2 +-
 gcc/testsuite/gcc.target/aarch64/pr63304_1.c  | 2 +-
 gcc/testsuite/gcc.target/aarch64/pr70120-2.c  | 2 +-
 gcc/testsuite/gcc.target/aarch64/pr78733.c| 2 +-
 gcc/testsuite/gcc.target/aarch64/pr79041-2.c  | 2 +-
 gcc/testsuite/gcc.target/aarch64/pr94530.c| 2 +-
 gcc/testsuite/gcc.target/aarch64/pr94577.c| 2 +-
 gcc/testsuite/gcc.target/aarch64/reload-valid-spoff.c | 2 +-
 8 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/tls/pr78796.c 
b/gcc/testsuite/gcc.dg/tls/pr78796.c
index 038e5366e41..96f87d47ba4 100644
--- a/gcc/testsuite/gcc.dg/tls/pr78796.c
+++ b/gcc/testsuite/gcc.dg/tls/pr78796.c
@@ -1,7 +1,7 @@
 /* PR target/78796 */
 /* { dg-do run } */
 /* { dg-options "-O2" } */
-/* { dg-additional-options "-mcmodel=large" { target aarch64-*-* } } */
+/* { dg-additional-options "-mcmodel=large -fno-pie -no-pie" { target 
aarch64-*-* } } */
 /* { dg-require-effective-target tls_runtime } */
 /* { dg-add-options tls } */
 
diff --git a/gcc/testsuite/gcc.target/aarch64/pr63304_1.c 
b/gcc/testsuite/gcc.target/aarch64/pr63304_1.c
index 9f1ed947806..5d519d817cc 100644
--- a/gcc/testsuite/gcc.target/aarch64/pr63304_1.c
+++ b/gcc/testsuite/gcc.target/aarch64/pr63304_1.c
@@ -1,6 +1,6 @@
 /* { dg-do assemble } */
 /* { dg-require-effective-target lp64 } */
-/* { dg-options "-O1 --save-temps" } */
+/* { dg-options "-O1 --save-temps -fno-pie" } */
 #pragma GCC push_options
 #pragma GCC target ("+nothing+simd,cmodel=small")
 
diff --git a/gcc/testsuite/gcc.target/aarch64/pr70120-2.c 
b/gcc/testsuite/gcc.target/aarch64/pr70120-2.c
index 663bf2ed147..8f5cdc93fe3 100644
--- a/gcc/testsuite/gcc.target/aarch64/pr70120-2.c
+++ b/gcc/testsuite/gcc.target/aarch64/pr70120-2.c
@@ -1,6 +1,6 @@
 /* { dg-do compile } */
 /* { dg-require-effective-target lp64 } */
-/* { dg-options "-Og -freorder-functions -g3 -mcmodel=large" } */
+/* { dg-options "-Og -freorder-functions -g3 -mcmodel=large -fno-pie" } */
 
 typedef short v32u16 __attribute__ ((vector_size (32)));
 typedef int v32u32 __attribute__ ((vector_size (32)));
diff --git a/gcc/testsuite/gcc.target/aarch64/pr78733.c 
b/gcc/testsuite/gcc.target/aarch64/pr78733.c
index 4695b5c1b2b..8556ef3f371 100644
--- a/gcc/testsuite/gcc.target/aarch64/pr78733.c
+++ b/gcc/testsuite/gcc.target/aarch64/pr78733.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -mcmodel=large -mpc-relative-literal-loads" } */
+/* { dg-options "-O2 -mcmodel=large -mpc-relative-literal-loads -fno-pie" } */
 /* { dg-require-effective-target lp64 } */
 /* { dg-skip-if "-mcmodel=large, no support for -fpic" { aarch64-*-* }  { 
"-fpic" } { "" } } */
 
diff --git a/gcc/testsuite/gcc.target/aarch64/pr79041-2.c 
b/gcc/testsuite/gcc.target/aarch64/pr79041-2.c
index 4695b5c1b2b..8556ef3f371 100644
--- a/gcc/testsuite/gcc.target/aarch64/pr79041-2.c
+++ b/gcc/testsuite/gcc.target/aarch64/pr79041-2.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -mcmodel=large -mpc-relative-literal-loads" } */
+/* { dg-options "-O2 -mcmodel=large -mpc-relative-literal-loads -fno-pie" } */
 /* { dg-require-effective-target lp64 } */
 /* { dg-skip-if "-mcmodel=large, no support for -fpic" { aarch64-*-* }  { 
"-fpic" } { "" } } */
 
diff --git a/gcc/testsuite/gcc.target/aarch64/pr94530.c 
b/gcc/testsuite/gcc.target/aarch64/pr94530.c
index 2797d116dcf..5dfdbe3311d 100644
--- a/gcc/testsuite/gcc.target/aarch64/pr94530.c
+++ b/gcc/testsuite/gcc.target/aarch64/pr94530.c
@@ -1,6 +1,6 @@
 /* { dg-do compile } */
 /* { dg-require-effective-target lp64 } */
-/* { dg-options "-Os -mcpu=falkor -mpc-relative-literal-loads -mcmodel=large" 
} */
+/* { dg-options "-Os -mcpu=falkor -mpc-relative-literal-loads -mcmodel=large 
-fno-pie" } */
 
 extern void bar(const char *);
 
diff --git a/gcc/testsuite/gcc.target/aarch64/pr94577.c 
b/gcc/testsuite/gcc.target/aarch64/pr94577.c
index 6f2d3612c26..d51799fb0bb 100644
--- a/gcc/testsuite/gcc.target/aarch64/pr94577.c
+++ b/gcc/testsuite/gcc.target/aarch64/pr94

[PATCH 7/8] aarch64: testsuite: disable stack protector for pr104005.c

[Xi Ruoyao via Gcc-patches]

Storing stack guarding variable need one stp instruction, breaking the
scan-assembler-not pattern in the test.  Disable stack protector to
avoid a test failure with --enable-default-ssp.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/pr104005.c (dg-options): Add
-fno-stack-protector.
---
 gcc/testsuite/gcc.target/aarch64/pr104005.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/aarch64/pr104005.c 
b/gcc/testsuite/gcc.target/aarch64/pr104005.c
index 09dd81910eb..9f1ef2dc308 100644
--- a/gcc/testsuite/gcc.target/aarch64/pr104005.c
+++ b/gcc/testsuite/gcc.target/aarch64/pr104005.c
@@ -1,4 +1,4 @@
-/* { dg-options "-O2 -funroll-loops" } */
+/* { dg-options "-O2 -funroll-loops -fno-stack-protector" } */
 
 typedef int v2 __attribute__((vector_size(8)));
 
-- 
2.39.2

[PATCH 3/8] aarch64: testsuite: disable PIE for fuse_adrp_add_1.c [PR70150]

[Xi Ruoyao via Gcc-patches]

In PIE, symbol "fixed_regs" is addressed via GOT.  It will break the
scan-assembler pattern and cause test failure with --enable-default-pie.

gcc/testsuite/ChangeLog:

PR testsuite/70150
* gcc.target/aarch64/fuse_adrp_add_1.c (dg-options): Add
-fno-pie.
---
 gcc/testsuite/gcc.target/aarch64/fuse_adrp_add_1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/aarch64/fuse_adrp_add_1.c 
b/gcc/testsuite/gcc.target/aarch64/fuse_adrp_add_1.c
index e49aadaa639..d66fe3a4b23 100644
--- a/gcc/testsuite/gcc.target/aarch64/fuse_adrp_add_1.c
+++ b/gcc/testsuite/gcc.target/aarch64/fuse_adrp_add_1.c
@@ -1,6 +1,6 @@
 /* { dg-do compile } */
 /* { dg-require-effective-target aarch64_small } */
-/* { dg-options "-O3 -mcpu=cortex-a57" } */
+/* { dg-options "-O3 -mcpu=cortex-a57 -fno-pie" } */
 
 enum reg_class { NO_REGS, AP_REG, XRF_REGS, GENERAL_REGS, AGRF_REGS,
  XGRF_REGS, ALL_REGS, LIM_REG_CLASSES };
-- 
2.39.2

[PATCH 6/8] aarch64: testsuite: disable stack protector for auto-init-7.c

[Xi Ruoyao via Gcc-patches]

The test scans for "const_int 0" in the RTL dump, but stack protector
can produce more "const_int 0".  To avoid a failure with
--enable-default-ssp, disable stack protector for this.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/auto-init-7.c (dg-options): Add
-fno-stack-protector.
---
 gcc/testsuite/gcc.target/aarch64/auto-init-7.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/aarch64/auto-init-7.c 
b/gcc/testsuite/gcc.target/aarch64/auto-init-7.c
index ac27fbe92f4..fde6e568532 100644
--- a/gcc/testsuite/gcc.target/aarch64/auto-init-7.c
+++ b/gcc/testsuite/gcc.target/aarch64/auto-init-7.c
@@ -1,6 +1,6 @@
 /* Verify zero initialization for array, union, and structure type automatic 
variables.  */
 /* { dg-do compile } */
-/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand" } */
+/* { dg-options "-ftrivial-auto-var-init=zero -fdump-rtl-expand 
-fno-stack-protector" } */
 
 struct S
 {
-- 
2.39.2

[PATCH 4/8] aarch64: testsuite: disable stack protector for sve-pcs tests

[Xi Ruoyao via Gcc-patches]

If GCC is configured with --enable-default-ssp, the stack protector can
make many sve-pcs tests fail.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/sve/pcs/aarch64-sve-pcs.exp (sve_flags):
Add -fno-stack-protector.
---
 .../gcc.target/aarch64/sve/pcs/aarch64-sve-pcs.exp | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/gcc.target/aarch64/sve/pcs/aarch64-sve-pcs.exp 
b/gcc/testsuite/gcc.target/aarch64/sve/pcs/aarch64-sve-pcs.exp
index 5562502cc07..3dbf73f67c9 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/pcs/aarch64-sve-pcs.exp
+++ b/gcc/testsuite/gcc.target/aarch64/sve/pcs/aarch64-sve-pcs.exp
@@ -37,11 +37,12 @@ if ![info exists DEFAULT_CFLAGS] then {
 # Initialize `dg'.
 dg-init
 
-# Force SVE if we're not testing it already.
+# Force SVE if we're not testing it already.  And, disable stack protector
+# to avoid test failures with --enable-default-ssp.
 if { [check_effective_target_aarch64_sve] } {
-set sve_flags ""
+set sve_flags "-fno-stack-protector"
 } else {
-set sve_flags "-march=armv8.2-a+sve"
+set sve_flags "-march=armv8.2-a+sve -fno-stack-protector"
 }
 
 # Main loop.
-- 
2.39.2

[PATCH 1/8] aarch64: testsuite: disable PIE for aapcs64 tests [PR70150]

[Xi Ruoyao via Gcc-patches]

If GCC is built with --enable-default-pie, a lot of aapcs64 tests fail
because relocation unsupported in PIE is used.

gcc/testsuite/ChangeLog:

PR testsuite/70150
* gcc.target/aarch64/aapcs64/aapcs64.exp (additional_flags):
Add -fno-pie -no-pie.
---
 gcc/testsuite/gcc.target/aarch64/aapcs64/aapcs64.exp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/aapcs64.exp 
b/gcc/testsuite/gcc.target/aarch64/aapcs64/aapcs64.exp
index fc6b3e8ada9..8cf9cc1e8e5 100644
--- a/gcc/testsuite/gcc.target/aarch64/aapcs64/aapcs64.exp
+++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/aapcs64.exp
@@ -27,7 +27,7 @@ if { ![istarget aarch64*-*-*] } then {
 
 torture-init
 set-torture-options $C_TORTURE_OPTIONS
-set additional_flags "-W -Wall -Wno-abi"
+set additional_flags "-W -Wall -Wno-abi -fno-pie -no-pie"
 
 # Test parameter passing.  This uses abitest.S which relies on weak
 # symbols.
-- 
2.39.2

[PATCH 0/8] aarch64: testsuite: Fix test failures with --enable-default-pie or --enable-default-ssp

[Xi Ruoyao via Gcc-patches]

Hi,

This patch series fixes a lot of test failures with --enable-default-pie
or --enable-default-ssp for AArch64 target.  Only test files are changed
to disable PIE or SSP to satisify the expectation of the developer who
programmed the test.

Bootstrapped and regtested on aarch64-linux-gnu.  Ok for trunk?

Xi Ruoyao (8):
  aarch64: testsuite: disable PIE for aapcs64 tests [PR70150]
  aarch64: testsuite: disable PIE for tests with large code model
[PR70150]
  aarch64: testsuite: disable PIE for fuse_adrp_add_1.c [PR70150]
  aarch64: testsuite: disable stack protector for sve-pcs tests
  aarch64: testsuite: disable stack protector for pr103147-10 tests
  aarch64: testsuite: disable stack protector for auto-init-7.c
  aarch64: testsuite: disable stack protector for pr104005.c
  aarch64: testsuite: disable stack protector for tests relying on stack
offset

 gcc/testsuite/g++.target/aarch64/pr103147-10.C | 2 +-
 gcc/testsuite/gcc.dg/tls/pr78796.c | 2 +-
 gcc/testsuite/gcc.target/aarch64/aapcs64/aapcs64.exp   | 2 +-
 gcc/testsuite/gcc.target/aarch64/auto-init-7.c | 2 +-
 gcc/testsuite/gcc.target/aarch64/fuse_adrp_add_1.c | 2 +-
 gcc/testsuite/gcc.target/aarch64/pr103147-10.c | 2 +-
 gcc/testsuite/gcc.target/aarch64/pr104005.c| 2 +-
 gcc/testsuite/gcc.target/aarch64/pr63304_1.c   | 2 +-
 gcc/testsuite/gcc.target/aarch64/pr70120-2.c   | 2 +-
 gcc/testsuite/gcc.target/aarch64/pr78733.c | 2 +-
 gcc/testsuite/gcc.target/aarch64/pr79041-2.c   | 2 +-
 gcc/testsuite/gcc.target/aarch64/pr94530.c | 2 +-
 gcc/testsuite/gcc.target/aarch64/pr94577.c | 2 +-
 gcc/testsuite/gcc.target/aarch64/reload-valid-spoff.c  | 2 +-
 gcc/testsuite/gcc.target/aarch64/shrink_wrap_1.c   | 2 +-
 gcc/testsuite/gcc.target/aarch64/stack-check-cfa-1.c   | 2 +-
 gcc/testsuite/gcc.target/aarch64/stack-check-cfa-2.c   | 2 +-
 .../gcc.target/aarch64/sve/pcs/aarch64-sve-pcs.exp | 7 ---
 gcc/testsuite/gcc.target/aarch64/test_frame_17.c   | 2 +-
 19 files changed, 22 insertions(+), 21 deletions(-)

-- 
2.39.2

Re: [PATCH] c++: unevaluated array new-expr size constantness [PR108219]

[Jason Merrill via Gcc-patches]

On 3/1/23 12:20, Patrick Palka wrote:

On Wed, 1 Mar 2023, Jason Merrill wrote:


On 3/1/23 10:32, Patrick Palka wrote:

On Mon, 27 Feb 2023, Jason Merrill wrote:


On 2/22/23 14:45, Patrick Palka wrote:

Here we're mishandling the unevaluated array new-expressions due to a
supposed non-constant array size ever since r12-5253-g4df7f8c79835d569,
made us no longer perform constant evaluation of non-manifestly-constant
expressions within unevaluated contexts.  This shouldn't make a
difference here since the array sizes are constant literals, except
they're actually NON_LVALUE_EXPR location wrappers wrapping INTEGER_CST,
wrappers which used to get stripped as part of constant evaluation and
now no longer do.  Moreover it means build_vec_init can't constant fold
the 'maxindex' passed from build_new_1 (since it uses
maybe_constant_value
with mce_unknown).


Hmm, now that you mention it I think the

if (manifestly_const_eval != mce_unknown)

change in maybe_constant_value isn't quite right, we don't want to force
evaluation in unevaluated mce_false context either.


Ah, makes sense.  Fixed in the below patch.




This patch fixes the first issue by making maybe_constant_value and
fold_non_dependent_expr_template shortcut handling location wrappers
around constant nodes, and the second issue by using fold_build2_loc
instead of cp_build_binary_op when computing the maxindex to pass to
build_vec_init.


Maybe in unevaluated mce_unknown/false context maybe_constant_value should
call fold?


That seems like a good compromise between proper constant evaluation
and not constant evaluating at all, though I wonder how 'fold' behaves
w.r.t. to undefined behavior such as division by zero and signed overflow?


'fold' doesn't fold division by zero, but I think we should only return the
result of 'fold' at this point if it is in fact constant, not if it's a
non-constant simplification.


Sounds good, I wasn't sure if 'fold' could return a non-constant
simplification.


Yep, it also folds e.g. x*1 to x.


I suppose we want to be pretty conservative with the
constantness test, so I went with CONSTANT_CLASS_P && !TREE_OVERFLOW.


Makes sense.


Like so?  Smoke tested so far, bootstrap and regtest on
x86_64-pc-linu-xgnu in progress.

-- >8 --

Subject: [PATCH] c++: unevaluated array new-expr size constantness [PR108219]

Here we're mishandling the unevaluated array new-expressions due to a
supposed non-constant array size ever since r12-5253-g4df7f8c79835d569
made us no longer perform constant evaluation of non-manifestly-constant
expressions within unevaluated contexts.  This shouldn't make a
difference here since the array sizes are constant literals, except
these sizes are expressed as NON_LVALUE_EXPR location wrappers around
INTEGER_CST, wrappers which used to get stripped as part of constant
evaluation and now no longer do.  Moreover it means build_vec_init can't
constant fold the 'maxindex' passed from build_new_1 (since it uses
maybe_constant_value with mce_unknown).

This patch fixes this by making maybe_constant_value and
fold_non_dependent_expr at least try folding simple unevaluated operands
via fold(), which will evaluate simple arithmetic, look through location
wrappers, perform integral conversions, etc.

Co-authored-by: Jason Merrill 

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/12?

PR c++/108219
PR c++/108218

gcc/cp/ChangeLog:

* constexpr.cc (maybe_constant_value): Move up early exit
test for unevaluated operands.  Try reducing an unevaluated
operand to a constant via fold.
(fold_non_dependent_expr_template): Add early exit test for
CONSTANT_CLASS_P nodes.  Try reducing an unevaluated operand
to a constant via fold.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/new6.C: New test.
* g++.dg/cpp2a/concepts-new1.C: New test.
---
  gcc/cp/constexpr.cc| 23 +-
  gcc/testsuite/g++.dg/cpp0x/new6.C  | 13 
  gcc/testsuite/g++.dg/cpp2a/concepts-new1.C | 13 
  3 files changed, 44 insertions(+), 5 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/new6.C
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-new1.C

diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index b4d3e95bbd5..324968050ba 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -8523,6 +8523,14 @@ maybe_constant_value (tree t, tree decl /* = NULL_TREE 
*/,
  /* No caching or evaluation needed.  */
  return t;
  
+  /* Don't constant evaluate an unevaluated non-manifestly-constant operand,

+ but at least try folding simple expressions to a constant.  */
+  if (cp_unevaluated_operand && manifestly_const_eval != mce_true)
+{
+  tree r = fold (t);
+  return CONSTANT_CLASS_P (r) && !TREE_OVERFLOW (r) ? r : t;
+}
+
if (manifestly_const_eval != mce_unknown)
  return cxx_eval_outermost_constant_expr (t, true, true

Re: [PATCH] c++: unevaluated array new-expr size constantness [PR108219]

[Patrick Palka via Gcc-patches]

On Wed, 1 Mar 2023, Jason Merrill wrote:

> On 3/1/23 10:32, Patrick Palka wrote:
> > On Mon, 27 Feb 2023, Jason Merrill wrote:
> > 
> > > On 2/22/23 14:45, Patrick Palka wrote:
> > > > Here we're mishandling the unevaluated array new-expressions due to a
> > > > supposed non-constant array size ever since r12-5253-g4df7f8c79835d569,
> > > > made us no longer perform constant evaluation of non-manifestly-constant
> > > > expressions within unevaluated contexts.  This shouldn't make a
> > > > difference here since the array sizes are constant literals, except
> > > > they're actually NON_LVALUE_EXPR location wrappers wrapping INTEGER_CST,
> > > > wrappers which used to get stripped as part of constant evaluation and
> > > > now no longer do.  Moreover it means build_vec_init can't constant fold
> > > > the 'maxindex' passed from build_new_1 (since it uses
> > > > maybe_constant_value
> > > > with mce_unknown).
> > > 
> > > Hmm, now that you mention it I think the
> > > 
> > >if (manifestly_const_eval != mce_unknown)
> > > 
> > > change in maybe_constant_value isn't quite right, we don't want to force
> > > evaluation in unevaluated mce_false context either.
> > 
> > Ah, makes sense.  Fixed in the below patch.
> > 
> > > 
> > > > This patch fixes the first issue by making maybe_constant_value and
> > > > fold_non_dependent_expr_template shortcut handling location wrappers
> > > > around constant nodes, and the second issue by using fold_build2_loc
> > > > instead of cp_build_binary_op when computing the maxindex to pass to
> > > > build_vec_init.
> > > 
> > > Maybe in unevaluated mce_unknown/false context maybe_constant_value should
> > > call fold?
> > 
> > That seems like a good compromise between proper constant evaluation
> > and not constant evaluating at all, though I wonder how 'fold' behaves
> > w.r.t. to undefined behavior such as division by zero and signed overflow?
> 
> 'fold' doesn't fold division by zero, but I think we should only return the
> result of 'fold' at this point if it is in fact constant, not if it's a
> non-constant simplification.

Sounds good, I wasn't sure if 'fold' could return a non-constant
simplification.  I suppose we want to be pretty conservative with the
constantness test, so I went with CONSTANT_CLASS_P && !TREE_OVERFLOW.

Like so?  Smoke tested so far, bootstrap and regtest on
x86_64-pc-linu-xgnu in progress.

-- >8 --

Subject: [PATCH] c++: unevaluated array new-expr size constantness [PR108219]

Here we're mishandling the unevaluated array new-expressions due to a
supposed non-constant array size ever since r12-5253-g4df7f8c79835d569
made us no longer perform constant evaluation of non-manifestly-constant
expressions within unevaluated contexts.  This shouldn't make a
difference here since the array sizes are constant literals, except
these sizes are expressed as NON_LVALUE_EXPR location wrappers around
INTEGER_CST, wrappers which used to get stripped as part of constant
evaluation and now no longer do.  Moreover it means build_vec_init can't
constant fold the 'maxindex' passed from build_new_1 (since it uses
maybe_constant_value with mce_unknown).

This patch fixes this by making maybe_constant_value and
fold_non_dependent_expr at least try folding simple unevaluated operands
via fold(), which will evaluate simple arithmetic, look through location
wrappers, perform integral conversions, etc.

Co-authored-by: Jason Merrill 

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/12?

PR c++/108219
PR c++/108218

gcc/cp/ChangeLog:

* constexpr.cc (maybe_constant_value): Move up early exit
test for unevaluated operands.  Try reducing an unevaluated
operand to a constant via fold.
(fold_non_dependent_expr_template): Add early exit test for
CONSTANT_CLASS_P nodes.  Try reducing an unevaluated operand
to a constant via fold.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/new6.C: New test.
* g++.dg/cpp2a/concepts-new1.C: New test.
---
 gcc/cp/constexpr.cc| 23 +-
 gcc/testsuite/g++.dg/cpp0x/new6.C  | 13 
 gcc/testsuite/g++.dg/cpp2a/concepts-new1.C | 13 
 3 files changed, 44 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/new6.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-new1.C

diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index b4d3e95bbd5..324968050ba 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -8523,6 +8523,14 @@ maybe_constant_value (tree t, tree decl /* = NULL_TREE 
*/,
 /* No caching or evaluation needed.  */
 return t;
 
+  /* Don't constant evaluate an unevaluated non-manifestly-constant operand,
+ but at least try folding simple expressions to a constant.  */
+  if (cp_unevaluated_operand && manifestly_const_eval != mce_true)
+{
+  tree r = fold (t);
+  return CONSTANT_CLASS_P (r) && !TREE_OVERFLO

Re: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583]

[Andrew Carlotti via Gcc-patches]

On Thu, Feb 23, 2023 at 11:39:51AM -0500, Andrew MacLeod via Gcc-patches wrote:
> 
> 
> Inheriting from operator_mult is also going to be hazardous because it also
> has an op1_range and op2_range...� you should at least define those and
> return VARYING to avoid other issues.� Same thing applies to widen_plus I
> think, and it has relation processing and other things as well.� Your widen
> operands are not what those classes expect, so I think you probably just
> want a fresh range operator.
> 
> It also looks like the mult operation is sign/zero extending both upper
> bounds, and neither lower bound..�� I think that should be the LH upper 
> and
> lower bound?
> 
> I've attached a second patch� (newversion.patch) which incorporates my fix,
> the fix to the sign of only op1's bounds,� as well as a simplification of
> the classes to not inherit from operator_mult/plus..�� I think this still
> does what you want?� and it wont get you into unexpected trouble later :-)
> 
> let me know if this is still doing what you are expecting...
> 
> Andrew
> 

Hi,

This patch still uses the wrong signedness for some of the extensions in
WIDEN_MULT_EXPR. It currently bases it's promotion decisions on whether there
is any signed argument, and whether the result is signed - i.e.:

Patch extends as:
UUU UU
UUS -> USU
USU SU
USS SU  wrong
SUU US  wrong
SUS -> SSU
SSU SS  wrong
SSS SS

The documentation in tree.def is unclear about whether the output signedness is
linked to the input signedness, but at least the SSU case seems valid, and is
mishandled here.

I think it would be clearer and simpler to have four (or three) different
versions for each combnation of signedness of the input operands. This could be
implemented without extra code duplication by creating four different instances
of an operator_widen_mult class (perhaps extending a range_operator_mixed_sign
class), with the signedness indicated by two additional class members.

The documentation for WIDEN_PLUS_EXPR (and several other expressions added in
the same commit) is completely missing. If the signs are required to be
matching, then this should be clarified; otherwise it would need the same
special handling as WIDEN_MULT_EXPR.

Andrew

> diff --git a/gcc/gimple-range-op.cc b/gcc/gimple-range-op.cc
> index d9dfdc56939..824e0338f34 100644
> --- a/gcc/gimple-range-op.cc
> +++ b/gcc/gimple-range-op.cc
> @@ -179,6 +179,8 @@ gimple_range_op_handler::gimple_range_op_handler (gimple 
> *s)
>// statements.
>if (is_a  (m_stmt))
>  maybe_builtin_call ();
> +  else
> +maybe_non_standard ();
>  }
>  
>  // Calculate what we can determine of the range of this unary
> @@ -764,6 +766,36 @@ public:
>}
>  } op_cfn_parity;
>  
> +// Set up a gimple_range_op_handler for any nonstandard function which can be
> +// supported via range-ops.
> +
> +void
> +gimple_range_op_handler::maybe_non_standard ()
> +{
> +  if (gimple_code (m_stmt) == GIMPLE_ASSIGN)
> +switch (gimple_assign_rhs_code (m_stmt))
> +  {
> + case WIDEN_MULT_EXPR:
> + {
> +   m_valid = true;
> +   m_op1 = gimple_assign_rhs1 (m_stmt);
> +   m_op2 = gimple_assign_rhs2 (m_stmt);
> +   bool signed1 = TYPE_SIGN (TREE_TYPE (m_op1)) == SIGNED;
> +   bool signed2 = TYPE_SIGN (TREE_TYPE (m_op2)) == SIGNED;
> +   if (signed2 && !signed1)
> + std::swap (m_op1, m_op2);
> +
> +   if (signed1 || signed2)
> + m_int = ptr_op_widen_mult_signed;
> +   else
> + m_int = ptr_op_widen_mult_unsigned;
> +   break;
> + }
> + default:
> +   break;
> +  }
> +}
> +
>  // Set up a gimple_range_op_handler for any built in function which can be
>  // supported via range-ops.
>  
> diff --git a/gcc/gimple-range-op.h b/gcc/gimple-range-op.h
> index 743b858126e..1bf63c5ce6f 100644
> --- a/gcc/gimple-range-op.h
> +++ b/gcc/gimple-range-op.h
> @@ -41,6 +41,7 @@ public:
>relation_trio = TRIO_VARYING);
>  private:
>void maybe_builtin_call ();
> +  void maybe_non_standard ();
>gimple *m_stmt;
>tree m_op1, m_op2;
>  };
> diff --git a/gcc/range-op.cc b/gcc/range-op.cc
> index 5c67bce6d3a..7cd19a92d00 100644
> --- a/gcc/range-op.cc
> +++ b/gcc/range-op.cc
> @@ -1556,6 +1556,34 @@ operator_plus::op2_range (irange &r, tree type,
>return op1_range (r, type, lhs, op1, rel.swap_op1_op2 ());
>  }
>  
> +class operator_widen_plus : public range_operator
> +{
> +public:
> +  virtual void wi_fold (irange &r, tree type,
> + const wide_int &lh_lb,
> + const wide_int &lh_ub,
> + const wide_int &rh_lb,
> + const wide_int &rh_ub) const;
> +} op_widen_plus;
> +
> +void
> +operator_widen_plus::wi_fold (irange &r, tree type,
> + const wide_int &lh_lb, const wide_int &lh_ub,
> + const wide_int &rh_lb,

[PATCH] amdgcn: Add instruction patterns for conditional min/max operations

[Paul-Antoine Arras]

This patch introduces instruction patterns for conditional min and max
operations (cond_{f|s|u}{max|min}) in the GCN machine description. It 
also allows the exec register to be saved in SGPRs to avoid spilling to 
memory.

Tested on GCN3 Fiji gfx803.

OK for trunk?
--
PA
From 1cd86b4420d9d42bcde83d0ac52a03a07d4aa819 Mon Sep 17 00:00:00 2001
From: Paul-Antoine Arras 
Date: Wed, 1 Mar 2023 17:20:21 +0100
Subject: [PATCH] amdgcn: Add instruction patterns for conditional min/max
 operations

gcc/ChangeLog:

	* config/gcn/gcn-valu.md (3_exec): Add patterns for
	{s|u}{max|min} in QI, HI and DI modes.
	(3): Add pattern for {s|u}{max|min} in DI mode.
	(cond_): Add pattern for cond_f{max|min}.
	(cond_): Add pattern for cond_{s|u}{max|min}.
	* config/gcn/gcn.cc (gcn_spill_class): Allow the exec register to be
	saved in SGPRs.

gcc/testsuite/ChangeLog:

	* gcc.target/gcn/cond_fmaxnm_1.c: New test.
	* gcc.target/gcn/cond_fmaxnm_1_run.c: New test.
	* gcc.target/gcn/cond_fmaxnm_2.c: New test.
	* gcc.target/gcn/cond_fmaxnm_2_run.c: New test.
	* gcc.target/gcn/cond_fmaxnm_3.c: New test.
	* gcc.target/gcn/cond_fmaxnm_3_run.c: New test.
	* gcc.target/gcn/cond_fmaxnm_4.c: New test.
	* gcc.target/gcn/cond_fmaxnm_4_run.c: New test.
	* gcc.target/gcn/cond_fmaxnm_5.c: New test.
	* gcc.target/gcn/cond_fmaxnm_5_run.c: New test.
	* gcc.target/gcn/cond_fmaxnm_6.c: New test.
	* gcc.target/gcn/cond_fmaxnm_6_run.c: New test.
	* gcc.target/gcn/cond_fmaxnm_7.c: New test.
	* gcc.target/gcn/cond_fmaxnm_7_run.c: New test.
	* gcc.target/gcn/cond_fmaxnm_8.c: New test.
	* gcc.target/gcn/cond_fmaxnm_8_run.c: New test.
	* gcc.target/gcn/cond_fminnm_1.c: New test.
	* gcc.target/gcn/cond_fminnm_1_run.c: New test.
	* gcc.target/gcn/cond_fminnm_2.c: New test.
	* gcc.target/gcn/cond_fminnm_2_run.c: New test.
	* gcc.target/gcn/cond_fminnm_3.c: New test.
	* gcc.target/gcn/cond_fminnm_3_run.c: New test.
	* gcc.target/gcn/cond_fminnm_4.c: New test.
	* gcc.target/gcn/cond_fminnm_4_run.c: New test.
	* gcc.target/gcn/cond_fminnm_5.c: New test.
	* gcc.target/gcn/cond_fminnm_5_run.c: New test.
	* gcc.target/gcn/cond_fminnm_6.c: New test.
	* gcc.target/gcn/cond_fminnm_6_run.c: New test.
	* gcc.target/gcn/cond_fminnm_7.c: New test.
	* gcc.target/gcn/cond_fminnm_7_run.c: New test.
	* gcc.target/gcn/cond_fminnm_8.c: New test.
	* gcc.target/gcn/cond_fminnm_8_run.c: New test.
	* gcc.target/gcn/cond_smax_1.c: New test.
	* gcc.target/gcn/cond_smax_1_run.c: New test.
	* gcc.target/gcn/cond_smin_1.c: New test.
	* gcc.target/gcn/cond_smin_1_run.c: New test.
	* gcc.target/gcn/cond_umax_1.c: New test.
	* gcc.target/gcn/cond_umax_1_run.c: New test.
	* gcc.target/gcn/cond_umin_1.c: New test.
	* gcc.target/gcn/cond_umin_1_run.c: New test.
	* gcc.target/gcn/smax_1.c: New test.
	* gcc.target/gcn/smax_1_run.c: New test.
	* gcc.target/gcn/smin_1.c: New test.
	* gcc.target/gcn/smin_1_run.c: New test.
	* gcc.target/gcn/umax_1.c: New test.
	* gcc.target/gcn/umax_1_run.c: New test.
	* gcc.target/gcn/umin_1.c: New test.
	* gcc.target/gcn/umin_1_run.c: New test.
---
 gcc/config/gcn/gcn-valu.md| 134 +-
 gcc/config/gcn/gcn.cc |   2 +-
 gcc/testsuite/gcc.target/gcn/cond_fmaxnm_1.c  |  36 +
 .../gcc.target/gcn/cond_fmaxnm_1_run.c|  32 +
 gcc/testsuite/gcc.target/gcn/cond_fmaxnm_2.c  |  35 +
 .../gcc.target/gcn/cond_fmaxnm_2_run.c|  31 
 gcc/testsuite/gcc.target/gcn/cond_fmaxnm_3.c  |  37 +
 .../gcc.target/gcn/cond_fmaxnm_3_run.c|  32 +
 gcc/testsuite/gcc.target/gcn/cond_fmaxnm_4.c  |  37 +
 .../gcc.target/gcn/cond_fmaxnm_4_run.c|  32 +
 gcc/testsuite/gcc.target/gcn/cond_fmaxnm_5.c  |   9 ++
 .../gcc.target/gcn/cond_fmaxnm_5_run.c|   4 +
 gcc/testsuite/gcc.target/gcn/cond_fmaxnm_6.c  |   9 ++
 .../gcc.target/gcn/cond_fmaxnm_6_run.c|   4 +
 gcc/testsuite/gcc.target/gcn/cond_fmaxnm_7.c  |   9 ++
 .../gcc.target/gcn/cond_fmaxnm_7_run.c|   4 +
 gcc/testsuite/gcc.target/gcn/cond_fmaxnm_8.c  |   9 ++
 .../gcc.target/gcn/cond_fmaxnm_8_run.c|   4 +
 gcc/testsuite/gcc.target/gcn/cond_fminnm_1.c  |  10 ++
 .../gcc.target/gcn/cond_fminnm_1_run.c|   5 +
 gcc/testsuite/gcc.target/gcn/cond_fminnm_2.c  |  10 ++
 .../gcc.target/gcn/cond_fminnm_2_run.c|   5 +
 gcc/testsuite/gcc.target/gcn/cond_fminnm_3.c  |  12 ++
 .../gcc.target/gcn/cond_fminnm_3_run.c|   5 +
 gcc/testsuite/gcc.target/gcn/cond_fminnm_4.c  |  12 ++
 .../gcc.target/gcn/cond_fminnm_4_run.c|   5 +
 gcc/testsuite/gcc.target/gcn/cond_fminnm_5.c  |  10 ++
 .../gcc.target/gcn/cond_fminnm_5_run.c|   4 +
 gcc/testsuite/gcc.target/gcn/cond_fminnm_6.c  |  10 ++
 .../gcc.target/gcn/cond_fminnm_6_run.c|   4 +
 gcc/testsuite/gcc.target/gcn/cond_fminnm_7.c  |  10 ++
 .../gcc.target/gcn/cond_fminnm_7_run.c|   4 +
 gcc/testsuite/gcc.target/gcn/cond_fminnm_8.c  |  10 ++
 .../gcc.target/gcn/cond_fminnm_8_run.c|   4 +
 gcc/testsuite/gcc.targ

Re: [PATCH] c++: unevaluated array new-expr size constantness [PR108219]

[Jason Merrill via Gcc-patches]

On 3/1/23 10:32, Patrick Palka wrote:

On Mon, 27 Feb 2023, Jason Merrill wrote:


On 2/22/23 14:45, Patrick Palka wrote:

Here we're mishandling the unevaluated array new-expressions due to a
supposed non-constant array size ever since r12-5253-g4df7f8c79835d569,
made us no longer perform constant evaluation of non-manifestly-constant
expressions within unevaluated contexts.  This shouldn't make a
difference here since the array sizes are constant literals, except
they're actually NON_LVALUE_EXPR location wrappers wrapping INTEGER_CST,
wrappers which used to get stripped as part of constant evaluation and
now no longer do.  Moreover it means build_vec_init can't constant fold
the 'maxindex' passed from build_new_1 (since it uses maybe_constant_value
with mce_unknown).


Hmm, now that you mention it I think the

   if (manifestly_const_eval != mce_unknown)

change in maybe_constant_value isn't quite right, we don't want to force
evaluation in unevaluated mce_false context either.


Ah, makes sense.  Fixed in the below patch.




This patch fixes the first issue by making maybe_constant_value and
fold_non_dependent_expr_template shortcut handling location wrappers
around constant nodes, and the second issue by using fold_build2_loc
instead of cp_build_binary_op when computing the maxindex to pass to
build_vec_init.


Maybe in unevaluated mce_unknown/false context maybe_constant_value should
call fold?


That seems like a good compromise between proper constant evaluation
and not constant evaluating at all, though I wonder how 'fold' behaves
w.r.t. to undefined behavior such as division by zero and signed overflow?


'fold' doesn't fold division by zero, but I think we should only return 
the result of 'fold' at this point if it is in fact constant, not if 
it's a non-constant simplification.



IIUC proper constant evaluation treats UB as non-constant, so it might
be potentially problematic if 'fold' instea dtakes advantage of UB.  Or
maybe since we're in an unevaluated context it doesn't matter?

-- >8 --

Subject: [PATCH] c++: unevaluated array new-expr size constantness [PR108219]

Here we're mishandling the unevaluated array new-expressions due to a
supposed non-constant array size ever since r12-5253-g4df7f8c79835d569
made us no longer perform constant evaluation of non-manifestly-constant
expressions within unevaluated contexts.  This shouldn't make a
difference here since the array sizes are constant literals, except
these sizes are expressed as NON_LVALUE_EXPR location wrappers around
INTEGER_CST, wrappers which used to get stripped as part of constant
evaluation and now no longer do.  Moreover it means build_vec_init can't
constant fold the 'maxindex' passed from build_new_1 (since it uses
maybe_constant_value with mce_unknown).

This patch fixes this by making maybe_constant_value and
fold_non_dependent_expr at least try folding simple unevaluated operands
via fold(), which will evaluate simple arithmetic, look through location
wrappers, perform integral conversions, etc.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/12?

PR c++/108219
PR c++/108218

gcc/cp/ChangeLog:

* constexpr.cc (maybe_constant_value): Move up early exit
test for unevaluated operands.  Call fold on unevaluated
operands.
(fold_non_dependent_expr_template): Add early exit test for
CONSTANT_CLASS_P nodes.  Call fold on unevaluated operands.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/new6.C: New test.
* g++.dg/cpp2a/concepts-new1.C: New test.
---
  gcc/cp/constexpr.cc| 17 -
  gcc/testsuite/g++.dg/cpp0x/new6.C  | 13 +
  gcc/testsuite/g++.dg/cpp2a/concepts-new1.C | 13 +
  3 files changed, 38 insertions(+), 5 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/new6.C
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-new1.C

diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index b4d3e95bbd5..d71abe6beed 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -8523,6 +8523,11 @@ maybe_constant_value (tree t, tree decl /* = NULL_TREE 
*/,
  /* No caching or evaluation needed.  */
  return t;
  
+  /* Don't constant evaluate an unevaluated non-manifestly-constant operand,

+ but at least try folding simple expressions.  */
+  if (cp_unevaluated_operand && manifestly_const_eval != mce_true)
+return fold (t);
+
if (manifestly_const_eval != mce_unknown)
  return cxx_eval_outermost_constant_expr (t, true, true,
 manifestly_const_eval, false, 
decl);
@@ -8544,10 +8549,6 @@ maybe_constant_value (tree t, tree decl /* = NULL_TREE 
*/,
return r;
  }
  
-  /* Don't evaluate an unevaluated operand.  */

-  if (cp_unevaluated_operand)
-return t;
-
uid_sensitive_constexpr_evaluation_checker c;
r = cxx_eval_outermost_constant_expr (t, true, true,
   

Re: [PATCH] ubsan: Honor -fstrict-flex-arrays= in -fsanitize=bounds [PR108894]

[Qing Zhao via Gcc-patches]

> On Feb 28, 2023, at 4:59 PM, Jakub Jelinek  wrote:
> 
> On Tue, Feb 28, 2023 at 07:19:40PM +, Qing Zhao wrote:
>> Understood.  
>> So, your patch fixed this bug, and then [0] arrays are instrumented by 
>> default with this patch.
>> 
>>> Well, it would complain about
>>> struct S { int a; int b[0]; int c; } s;
>>> ... &s.b[1] ...
>>> for C++, but not for C.
>> 
>> A little confused here: [0] arrays were instrumented by default for C++ if 
>> it’s not a trailing array, but not for C?
> 
> Given say
> struct S { int a; int b[0]; int c; } s;
> 
> int
> main ()
> {
>  int *volatile p = &s.b[0];
>  p = &s.b[1];
>  int volatile q = s.b[0];
> }
> both -fsanitize=bounds and -fsanitize=bounds-strict behaved the same way,
> in C nothing was reported, in C++ the p = &s.b[1]; statement.
> The reasons for s.b[0] not being reported in C++ was that for
> !ignore_off_by_one, bounds was ~(size_t)0, and so index > ~(size_t)0
> is always false.  While with the committed patch it is
> index >= (~(size_t)0)+1 and so always true.  And in C additionally, we
> punted early because TYPE_MAX_VALUE (domain) was NULL.

Thanks for the explanation.

With your patch, both C and C++ will report for the middle [0] arrays. That’s 
nice.

Qing
> 
>   Jakub
> 

Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

[Richard Sandiford via Gcc-patches]

"Li, Pan2"  writes:
> Thanks all for so much valuable and helpful materials.
>
> As I understand (Please help to correct me if any mistake.), for the VNx*BI 
> (aka, 1, 2, 4, 8, 16, 32, 64),
> the precision and mode size need to be adjusted as below.
>
> Precision size [1, 2, 4, 8, 16, 32, 64]
> Mode size [1, 1, 1, 1, 2, 4, 8]
>
> Given that, if we ignore the self-test failure, only the adjust_precision 
> part is able to fix the bug I mentioned.
> The genmode will first get the precision, and then leverage the mode_size = 
> exact_div / 8 to generate.
> Meanwhile, it also provides the adjust_mode_size after the mode_size 
> generation.
>
> The riscv parts has the mode_size_adjust already and the value of mode_size 
> will be overridden by the adjustments.

Ah, OK!  In that case, would the following help:

Turn:

  mode_size[E_%smode] = exact_div (mode_precision[E_%smode], BITS_PER_UNIT);

into:

  if (!multiple_p (mode_precision[E_%smode], BITS_PER_UNIT,
   &mode_size[E_%smode]))
mode_size[E_%smode] = -1;

where -1 is an "obviously wrong" value.

Ports that might hit the -1 are then responsible for setting the size
later, via ADJUST_BYTESIZE.

After all the adjustments are complete, genmodes asserts that no size is
known_eq to -1.

That way, target-independent code doesn't need to guess what the
correct behaviour is.

Does the eventual value set by ADJUST_BYTESIZE equal the real number of
bytes loaded by vlm.v and stored by vstm.v (after the appropriate vsetvl)?
And does it equal the size of the corresponding LLVM machine type?
Or is the GCC size larger in some cases than the number of bytes
loaded and stored?

(You and Juzhe have probably answered that question before, sorry,
but I'm still not 100% sure of the answer.  Personally, I think I would
find the ISA behaviour easier to understand if the explanation doesn't
involve poly_ints.  It would be good to understand things "as the
architecture sees then" rather than in terms of GCC concepts.)

Thanks,
Richard

> Unfortunately, the early stage mode_size generation leveraged exact_div, 
> which doesn't honor precision size < 8
> with the adjustment and fails on exact_div assertions.
>
> Besides the precision adjustment, I am not sure if we can narrow down the 
> problem to.
>
>
>   1.  Defined the real size of both the precision and mode size to align the 
> riscv ISA.
>   2.  Besides, make the general mode_size = precision_size / 8 is able to 
> take care of both the exact_div and the dividend less than the divisor (like 
> 1/8 or 2/8) cases.
>
> Could you please share your professional suggestions about this? Thank you 
> all again and have a nice day!
>
> Pan
>
> From: juzhe.zh...@rivai.ai 
> Sent: Wednesday, March 1, 2023 10:19 PM
> To: rguenther 
> Cc: richard.sandiford ; gcc-patches 
> ; Pan Li ; Li, Pan2 
> ; kito.cheng 
> Subject: Re: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment
>
>>> So given the above I think that modeling the size as being the same
>>> but with accurate precision would work.  It's then only the size of the
>>> padding in bytes we cannot represent with poly-int which should be fine.
>
>>> Correct?
> Yes.
>
>>> Btw, is storing a VNx1BI and then loading a VNx2BI from the same
>>> memory address well-defined?  That is, how is the padding handled
>>> by the machine load/store instructions?
>
> storing VNx1BI is storing the data from addr 0 ~ 1/8 poly (1,1) and keep addr 
> 1/8  poly (1,1) ~ 2/8  poly (1,1) memory data unchange.
> load VNx2BI will load 0 ~ 2/8  poly (1,1), note that 0 ~ 1/8 poly (1,1) is 
> the date that we store above, 1/8  poly (1,1) ~ 2/8  poly (1,1)  is the 
> orignal memory data.
> You can see here for this case (LLVM):
> https://godbolt.org/z/P9e1adrd3
> foo:# @foo
> vsetvli a2, zero, e8, mf8, ta, ma
> vsm.v   v0, (a0)
> vsetvli a2, zero, e8, mf4, ta, ma
> vlm.v   v8, (a0)
> vsm.v   v8, (a1)
> ret
>
> We can also doing like this in GCC as long as we can differentiate VNx1BI and 
> VNx2BI, and GCC do not eliminate statement according precision even though
> they have same bytesize.
>
> First we emit vsetvl e8mf8 +vsm for VNx1BI
> Then we emit vsetvl e8mf8 + vlm for VNx2BI
>
> Thanks.
> 
> juzhe.zh...@rivai.ai
>
> From: Richard Biener
> Date: 2023-03-01 22:03
> To: juzhe.zhong
> CC: richard.sandiford; 
> gcc-patches; Pan 
> Li; pan2.li; 
> kito.cheng
> Subject: Re: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment
> On Wed, 1 Mar 2023, Richard Biener wrote:
>
>> On Wed, 1 Mar 2023, juzhe.zh...@rivai.ai wrote:
>>
>> > Let's me first introduce RVV load/store basics  and stack al

Re: [PATCH 1/2] testsuite: Fix analyzer errors for newlib-errno

[Hans-Peter Nilsson via Gcc-patches]

> From: Hans-Peter Nilsson 
> Date: Wed, 1 Mar 2023 16:36:46 +0100

> ... this is what I intend to commit later
> today, just keeping the added comment as brief as
> reasonable:

Except I see the hook for errno magic took care of
gcc.dg/analyzer/flex-without-call-summaries.c so I'll add
that to the list of handled "FAIL"s in the commit log.  Yay.

brgds, H-P

Re: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

[Pan Li via Gcc-patches]

Sorry for the typo and inconvenience.

The below
"The genmode will first get the precision, and then leverage the mode_size = 
exact_div / 8 to generate"

should be:
"The genmode will first get the precision, and then leverage mode_size = 
mode_precision / 8 to generate"

Pan



From: Li, Pan2 
Sent: Wednesday, March 1, 2023 23:42
To: juzhe.zh...@rivai.ai ; rguenther 
Cc: richard.sandiford ; gcc-patches 
; Pan Li ; kito.cheng 

Subject: RE: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment


Thanks all for so much valuable and helpful materials.



As I understand (Please help to correct me if any mistake.), for the VNx*BI 
(aka, 1, 2, 4, 8, 16, 32, 64),

the precision and mode size need to be adjusted as below.



Precision size [1, 2, 4, 8, 16, 32, 64]

Mode size [1, 1, 1, 1, 2, 4, 8]



Given that, if we ignore the self-test failure, only the adjust_precision part 
is able to fix the bug I mentioned.

The genmode will first get the precision, and then leverage the mode_size = 
exact_div / 8 to generate.

Meanwhile, it also provides the adjust_mode_size after the mode_size generation.



The riscv parts has the mode_size_adjust already and the value of mode_size 
will be overridden by the adjustments.



Unfortunately, the early stage mode_size generation leveraged exact_div, which 
doesn’t honor precision size < 8

with the adjustment and fails on exact_div assertions.



Besides the precision adjustment, I am not sure if we can narrow down the 
problem to.



  1.  Defined the real size of both the precision and mode size to align the 
riscv ISA.
  2.  Besides, make the general mode_size = precision_size / 8 is able to take 
care of both the exact_div and the dividend less than the divisor (like 1/8 or 
2/8) cases.



Could you please share your professional suggestions about this? Thank you all 
again and have a nice day!



Pan



From: juzhe.zh...@rivai.ai 
Sent: Wednesday, March 1, 2023 10:19 PM
To: rguenther 
Cc: richard.sandiford ; gcc-patches 
; Pan Li ; Li, Pan2 
; kito.cheng 
Subject: Re: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment



>> So given the above I think that modeling the size as being the same

>> but with accurate precision would work.  It's then only the size of the

>> padding in bytes we cannot represent with poly-int which should be fine.



>> Correct?

Yes.



>> Btw, is storing a VNx1BI and then loading a VNx2BI from the same

>> memory address well-defined?  That is, how is the padding handled

>> by the machine load/store instructions?



storing VNx1BI is storing the data from addr 0 ~ 1/8 poly (1,1) and keep addr 
1/8  poly (1,1) ~ 2/8  poly (1,1) memory data unchange.

load VNx2BI will load 0 ~ 2/8  poly (1,1), note that 0 ~ 1/8 poly (1,1) is the 
date that we store above, 1/8  poly (1,1) ~ 2/8  poly (1,1)  is the orignal 
memory data.

You can see here for this case (LLVM):

https://godbolt.org/z/P9e1adrd3

foo:# @foo

vsetvli a2, zero, e8, mf8, ta, ma

vsm.v   v0, (a0)

vsetvli a2, zero, e8, mf4, ta, ma

vlm.v   v8, (a0)

vsm.v   v8, (a1)

ret



We can also doing like this in GCC as long as we can differentiate VNx1BI and 
VNx2BI, and GCC do not eliminate statement according precision even though

they have same bytesize.



First we emit vsetvl e8mf8 +vsm for VNx1BI

Then we emit vsetvl e8mf8 + vlm for VNx2BI



Thanks.



juzhe.zh...@rivai.ai



From: Richard Biener

Date: 2023-03-01 22:03

To: juzhe.zhong

CC: richard.sandiford; 
gcc-patches; Pan 
Li; pan2.li; 
kito.cheng

Subject: Re: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

On Wed, 1 Mar 2023, Richard Biener wrote:



> On Wed, 1 Mar 2023, juzhe.zh...@rivai.ai wrote:

>

> > Let's me first introduce RVV load/store basics  and stack allocation.

> > For scalable vector memory allocation, we allocate memory according to 
> > machine vector-length.

> > To get this CPU vector-length value (runtime invariant but compile time 
> > unknown), we have an instruction call csrr vlenb.

> > For example, csrr a5,vlenb (store CPU a single register vector-length value 
> > (describe as bytesize) in a5 register).

> > A single register size in bytes (GET_MODE_SIZE) is poly value (8,8) bytes. 
> > That means csrr a5,vlenb, a5 has the value of size poly (8,8) bytes.

> >

> > Now, our problem is that VNx1BI, VNx2BI, VNx4BI, VNx8BI has the same 
> > bytesize poly (1,1). So their storage consumes the same size.

> > Meaning when we want to allocate a memory storge or stack for register 
> > spillings, we should first csrr a5, vlenb, then slli a5,a5,3 (mea

Re: [PATCH, gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628]

[Steve Kargl via Gcc-patches]

On Wed, Mar 01, 2023 at 10:40:15AM +0100, Tobias Burnus wrote:
> > --- /dev/null
> > +++ b/gcc/testsuite/gfortran.dg/pr103628.f90
> > @@ -0,0 +1,14 @@
> > +! { dg-do compile { target powerpc*-*-* } }
> > +! { dg-options "-O2 -mabi=ibmlongdouble" }
> > +
> > +! Test to ensure that it reports an "Unclassifiable statement" error
> > +! instead of throwing an ICE when the memory represent of the HOLLERITH
> > +! string is not unique with ibm long double encoding.
> > ...
> > +  real(kind = k):: b = 4h1234

This should be rejected with an error message.  Hollerith was 
deleted from Fortran in Appendix C-1 of the Fortran 77 standard.
The appearance of a Hollerith entity in an initialization
expression has never be conforming.

In fact, Hollerith should be hidden behind a -fallow-hollerith
option and added to -std=legacy.

> diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc
> index 64821c84543..b60d92a0665 100644
> --- a/gcc/fortran/intrinsic.cc
> +++ b/gcc/fortran/intrinsic.cc
> @@ -27,2 +27,3 @@ along with GCC; see the file COPYING3.  If not see
>  #include "intrinsic.h"
> +#include "diagnostic.h" /* For errorcount.  */
> 
> @@ -4622,2 +4623,3 @@ do_simplify (gfc_intrinsic_sym *specific, gfc_expr *e)
>gfc_actual_arglist *arg;
> +  int old_errorcount = errorcount;
> 
> @@ -4710,3 +4712,7 @@ finish:
>if (result == &gfc_bad_expr)
> -return false;
> +{
> +  if (errorcount == old_errorcount)
> +   gfc_error ("Cannot simplify expression at %L", &e->where);
> +  return false;
> +}

I'm okay with this suggestion.  

-- 
Steve

RE: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

[Li, Pan2 via Gcc-patches]

Thanks all for so much valuable and helpful materials.

As I understand (Please help to correct me if any mistake.), for the VNx*BI 
(aka, 1, 2, 4, 8, 16, 32, 64),
the precision and mode size need to be adjusted as below.

Precision size [1, 2, 4, 8, 16, 32, 64]
Mode size [1, 1, 1, 1, 2, 4, 8]

Given that, if we ignore the self-test failure, only the adjust_precision part 
is able to fix the bug I mentioned.
The genmode will first get the precision, and then leverage the mode_size = 
exact_div / 8 to generate.
Meanwhile, it also provides the adjust_mode_size after the mode_size generation.

The riscv parts has the mode_size_adjust already and the value of mode_size 
will be overridden by the adjustments.

Unfortunately, the early stage mode_size generation leveraged exact_div, which 
doesn't honor precision size < 8
with the adjustment and fails on exact_div assertions.

Besides the precision adjustment, I am not sure if we can narrow down the 
problem to.


  1.  Defined the real size of both the precision and mode size to align the 
riscv ISA.
  2.  Besides, make the general mode_size = precision_size / 8 is able to take 
care of both the exact_div and the dividend less than the divisor (like 1/8 or 
2/8) cases.

Could you please share your professional suggestions about this? Thank you all 
again and have a nice day!

Pan

From: juzhe.zh...@rivai.ai 
Sent: Wednesday, March 1, 2023 10:19 PM
To: rguenther 
Cc: richard.sandiford ; gcc-patches 
; Pan Li ; Li, Pan2 
; kito.cheng 
Subject: Re: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

>> So given the above I think that modeling the size as being the same
>> but with accurate precision would work.  It's then only the size of the
>> padding in bytes we cannot represent with poly-int which should be fine.

>> Correct?
Yes.

>> Btw, is storing a VNx1BI and then loading a VNx2BI from the same
>> memory address well-defined?  That is, how is the padding handled
>> by the machine load/store instructions?

storing VNx1BI is storing the data from addr 0 ~ 1/8 poly (1,1) and keep addr 
1/8  poly (1,1) ~ 2/8  poly (1,1) memory data unchange.
load VNx2BI will load 0 ~ 2/8  poly (1,1), note that 0 ~ 1/8 poly (1,1) is the 
date that we store above, 1/8  poly (1,1) ~ 2/8  poly (1,1)  is the orignal 
memory data.
You can see here for this case (LLVM):
https://godbolt.org/z/P9e1adrd3
foo:# @foo
vsetvli a2, zero, e8, mf8, ta, ma
vsm.v   v0, (a0)
vsetvli a2, zero, e8, mf4, ta, ma
vlm.v   v8, (a0)
vsm.v   v8, (a1)
ret

We can also doing like this in GCC as long as we can differentiate VNx1BI and 
VNx2BI, and GCC do not eliminate statement according precision even though
they have same bytesize.

First we emit vsetvl e8mf8 +vsm for VNx1BI
Then we emit vsetvl e8mf8 + vlm for VNx2BI

Thanks.

juzhe.zh...@rivai.ai

From: Richard Biener
Date: 2023-03-01 22:03
To: juzhe.zhong
CC: richard.sandiford; 
gcc-patches; Pan 
Li; pan2.li; 
kito.cheng
Subject: Re: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment
On Wed, 1 Mar 2023, Richard Biener wrote:

> On Wed, 1 Mar 2023, juzhe.zh...@rivai.ai wrote:
>
> > Let's me first introduce RVV load/store basics  and stack allocation.
> > For scalable vector memory allocation, we allocate memory according to 
> > machine vector-length.
> > To get this CPU vector-length value (runtime invariant but compile time 
> > unknown), we have an instruction call csrr vlenb.
> > For example, csrr a5,vlenb (store CPU a single register vector-length value 
> > (describe as bytesize) in a5 register).
> > A single register size in bytes (GET_MODE_SIZE) is poly value (8,8) bytes. 
> > That means csrr a5,vlenb, a5 has the value of size poly (8,8) bytes.
> >
> > Now, our problem is that VNx1BI, VNx2BI, VNx4BI, VNx8BI has the same 
> > bytesize poly (1,1). So their storage consumes the same size.
> > Meaning when we want to allocate a memory storge or stack for register 
> > spillings, we should first csrr a5, vlenb, then slli a5,a5,3 (means a5 = 
> > a5/8)
> > Then, a5 has the bytesize value of poly (1,1). All VNx1BI, VNx2BI, VNx4BI, 
> > VNx8BI are doing the same process as I described above. They all consume
> > the same memory storage size since we can't model them accurately according 
> > to precision or you bitsize.
> >
> > They consume the same storage (I am agree it's better to model them more 
> > accurately in case of memory storage comsuming).
> >
> > Well, even though they are consuming same size memory storage, I can make 
> > their memory accessing behavior (load/store) accurately by
> > emiting  the accurate RVV instruction for the

Re: [PATCH 1/2] testsuite: Fix analyzer errors for newlib-errno

[Hans-Peter Nilsson via Gcc-patches]

> From: David Malcolm 
> Cc: gcc-patches@gcc.gnu.org
> Date: Wed, 01 Mar 2023 08:32:13 -0500

> Also, the analyzer uses region_model::set_errno in various
> known_function implementations, e.g. for functions that can succeed or
> fail, to set errno on the "failure" execution path to a new symbolic
> value that tests as > 0.

Ha, there's indeed errno-analyzing magic. :)

(That's the level you get when your first impression of
source code is by tracing through failing test-cases...)

> > So, how's this instead, pending full testing (only
> > analyzer.exp spot-tested)?
> 
> Looks good, though how about adding a mention of newlib to the comment
> immediately above (the one that talks about Solaris and OS X)?

I deliberately didn't, as the format of that comment seemed
to ask for redundantly repeating the definition for each
system (telling exactly how the #define looks etc.), and I
thought the heading "Other implementations of C standard
library" should have been sufficient, assuming access to the
git log when there's interest in more than the first lines.

But I hear you so this is what I intend to commit later
today, just keeping the added comment as brief as
reasonable:

"analyzer: Support errno for newlib

Without this definition, the errno definition for newlib
isn't recognized as such, and these tests fail for newlib
targets:

FAIL: gcc.dg/analyzer/call-summaries-errno.c  (test for warnings, line 16)
FAIL: gcc.dg/analyzer/call-summaries-errno.c (test for excess errors)
FAIL: gcc.dg/analyzer/errno-1.c  (test for warnings, line 20)
FAIL: gcc.dg/analyzer/errno-1.c (test for excess errors)
FAIL: gcc.dg/analyzer/isatty-1.c  (test for warnings, line 31)
FAIL: gcc.dg/analyzer/isatty-1.c  (test for warnings, line 35)
FAIL: gcc.dg/analyzer/isatty-1.c  (test for warnings, line 46)
FAIL: gcc.dg/analyzer/isatty-1.c  (test for warnings, line 56)
FAIL: gcc.dg/analyzer/isatty-1.c (test for excess errors)

gcc/analyzer:
* kf.cc (register_known_functions): Add __errno function for newlib.
---
 gcc/analyzer/kf.cc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gcc/analyzer/kf.cc b/gcc/analyzer/kf.cc
index 3a91b6bd6ebb..ed5f70398e1d 100644
--- a/gcc/analyzer/kf.cc
+++ b/gcc/analyzer/kf.cc
@@ -1033,9 +1033,11 @@ register_known_functions (known_function_manager &kfm)
and OS X like this:
 extern int * __error(void);
 #define errno (*__error())
+   and similarly __errno for newlib.
Add these as synonyms for "__errno_location".  */
 kfm.add ("___errno", make_unique ());
 kfm.add ("__error", make_unique ());
+kfm.add ("__errno", make_unique ());
   }
 
   /* Language-specific support functions.  */
-- 
2.30.2

> Thanks for fixing this

Thank *you* for the review!

brgds, H-P

Re: [PATCH] c++: unevaluated array new-expr size constantness [PR108219]

[Patrick Palka via Gcc-patches]

On Mon, 27 Feb 2023, Jason Merrill wrote:

> On 2/22/23 14:45, Patrick Palka wrote:
> > Here we're mishandling the unevaluated array new-expressions due to a
> > supposed non-constant array size ever since r12-5253-g4df7f8c79835d569,
> > made us no longer perform constant evaluation of non-manifestly-constant
> > expressions within unevaluated contexts.  This shouldn't make a
> > difference here since the array sizes are constant literals, except
> > they're actually NON_LVALUE_EXPR location wrappers wrapping INTEGER_CST,
> > wrappers which used to get stripped as part of constant evaluation and
> > now no longer do.  Moreover it means build_vec_init can't constant fold
> > the 'maxindex' passed from build_new_1 (since it uses maybe_constant_value
> > with mce_unknown).
> 
> Hmm, now that you mention it I think the
> 
>   if (manifestly_const_eval != mce_unknown)
> 
> change in maybe_constant_value isn't quite right, we don't want to force
> evaluation in unevaluated mce_false context either.

Ah, makes sense.  Fixed in the below patch.

> 
> > This patch fixes the first issue by making maybe_constant_value and
> > fold_non_dependent_expr_template shortcut handling location wrappers
> > around constant nodes, and the second issue by using fold_build2_loc
> > instead of cp_build_binary_op when computing the maxindex to pass to
> > build_vec_init.
> 
> Maybe in unevaluated mce_unknown/false context maybe_constant_value should
> call fold?

That seems like a good compromise between proper constant evaluation
and not constant evaluating at all, though I wonder how 'fold' behaves
w.r.t. to undefined behavior such as division by zero and signed overflow?
IIUC proper constant evaluation treats UB as non-constant, so it might
be potentially problematic if 'fold' instea dtakes advantage of UB.  Or
maybe since we're in an unevaluated context it doesn't matter?

-- >8 --

Subject: [PATCH] c++: unevaluated array new-expr size constantness [PR108219]

Here we're mishandling the unevaluated array new-expressions due to a
supposed non-constant array size ever since r12-5253-g4df7f8c79835d569
made us no longer perform constant evaluation of non-manifestly-constant
expressions within unevaluated contexts.  This shouldn't make a
difference here since the array sizes are constant literals, except
these sizes are expressed as NON_LVALUE_EXPR location wrappers around
INTEGER_CST, wrappers which used to get stripped as part of constant
evaluation and now no longer do.  Moreover it means build_vec_init can't
constant fold the 'maxindex' passed from build_new_1 (since it uses
maybe_constant_value with mce_unknown).

This patch fixes this by making maybe_constant_value and
fold_non_dependent_expr at least try folding simple unevaluated operands
via fold(), which will evaluate simple arithmetic, look through location
wrappers, perform integral conversions, etc.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/12?

PR c++/108219
PR c++/108218

gcc/cp/ChangeLog:

* constexpr.cc (maybe_constant_value): Move up early exit
test for unevaluated operands.  Call fold on unevaluated
operands.
(fold_non_dependent_expr_template): Add early exit test for
CONSTANT_CLASS_P nodes.  Call fold on unevaluated operands.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/new6.C: New test.
* g++.dg/cpp2a/concepts-new1.C: New test.
---
 gcc/cp/constexpr.cc| 17 -
 gcc/testsuite/g++.dg/cpp0x/new6.C  | 13 +
 gcc/testsuite/g++.dg/cpp2a/concepts-new1.C | 13 +
 3 files changed, 38 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/new6.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-new1.C

diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index b4d3e95bbd5..d71abe6beed 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -8523,6 +8523,11 @@ maybe_constant_value (tree t, tree decl /* = NULL_TREE 
*/,
 /* No caching or evaluation needed.  */
 return t;
 
+  /* Don't constant evaluate an unevaluated non-manifestly-constant operand,
+ but at least try folding simple expressions.  */
+  if (cp_unevaluated_operand && manifestly_const_eval != mce_true)
+return fold (t);
+
   if (manifestly_const_eval != mce_unknown)
 return cxx_eval_outermost_constant_expr (t, true, true,
 manifestly_const_eval, false, 
decl);
@@ -8544,10 +8549,6 @@ maybe_constant_value (tree t, tree decl /* = NULL_TREE 
*/,
   return r;
 }
 
-  /* Don't evaluate an unevaluated operand.  */
-  if (cp_unevaluated_operand)
-return t;
-
   uid_sensitive_constexpr_evaluation_checker c;
   r = cxx_eval_outermost_constant_expr (t, true, true,
manifestly_const_eval, false, decl);
@@ -8612,8 +8613,14 @@ fold_non_dependent_expr_template (tree t, tsubst_flags_t 
complain,
  

Re: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

[juzhe.zhong]

>> So given the above I think that modeling the size as being the same
>> but with accurate precision would work.  It's then only the size of the
>> padding in bytes we cannot represent with poly-int which should be fine.

>> Correct?
Yes.

>> Btw, is storing a VNx1BI and then loading a VNx2BI from the same
>> memory address well-defined?  That is, how is the padding handled
>> by the machine load/store instructions?

storing VNx1BI is storing the data from addr 0 ~ 1/8 poly (1,1) and keep addr 
1/8  poly (1,1) ~ 2/8  poly (1,1) memory data unchange.
load VNx2BI will load 0 ~ 2/8  poly (1,1), note that 0 ~ 1/8 poly (1,1) is the 
date that we store above, 1/8  poly (1,1) ~ 2/8  poly (1,1)  is the orignal 
memory data.
You can see here for this case (LLVM):
https://godbolt.org/z/P9e1adrd3
foo:# @foo
vsetvli a2, zero, e8, mf8, ta, ma
vsm.v   v0, (a0)
vsetvli a2, zero, e8, mf4, ta, ma
vlm.v   v8, (a0)
vsm.v   v8, (a1)
ret

We can also doing like this in GCC as long as we can differentiate VNx1BI and 
VNx2BI, and GCC do not eliminate statement according precision even though
they have same bytesize.

First we emit vsetvl e8mf8 +vsm for VNx1BI
Then we emit vsetvl e8mf8 + vlm for VNx2BI

Thanks.


juzhe.zh...@rivai.ai
 
From: Richard Biener
Date: 2023-03-01 22:03
To: juzhe.zhong
CC: richard.sandiford; gcc-patches; Pan Li; pan2.li; kito.cheng
Subject: Re: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment
On Wed, 1 Mar 2023, Richard Biener wrote:
 
> On Wed, 1 Mar 2023, juzhe.zh...@rivai.ai wrote:
> 
> > Let's me first introduce RVV load/store basics  and stack allocation.
> > For scalable vector memory allocation, we allocate memory according to 
> > machine vector-length.
> > To get this CPU vector-length value (runtime invariant but compile time 
> > unknown), we have an instruction call csrr vlenb.
> > For example, csrr a5,vlenb (store CPU a single register vector-length value 
> > (describe as bytesize) in a5 register).
> > A single register size in bytes (GET_MODE_SIZE) is poly value (8,8) bytes. 
> > That means csrr a5,vlenb, a5 has the value of size poly (8,8) bytes.
> > 
> > Now, our problem is that VNx1BI, VNx2BI, VNx4BI, VNx8BI has the same 
> > bytesize poly (1,1). So their storage consumes the same size.
> > Meaning when we want to allocate a memory storge or stack for register 
> > spillings, we should first csrr a5, vlenb, then slli a5,a5,3 (means a5 = 
> > a5/8)
> > Then, a5 has the bytesize value of poly (1,1). All VNx1BI, VNx2BI, VNx4BI, 
> > VNx8BI are doing the same process as I described above. They all consume
> > the same memory storage size since we can't model them accurately according 
> > to precision or you bitsize.
> > 
> > They consume the same storage (I am agree it's better to model them more 
> > accurately in case of memory storage comsuming).
> > 
> > Well, even though they are consuming same size memory storage, I can make 
> > their memory accessing behavior (load/store) accurately by
> > emiting  the accurate RVV instruction for them according to RVV ISA.
> > 
> > VNx1BI,VNx2BI, VNx4BI, VNx8BI are consuming same memory storage with size  
> > poly (1,1)
> > The instruction for these modes as follows:
> > VNx1BI: vsevl e8mf8 + vlm,  loading 1/8 of poly (1,1) storage.
> > VNx2BI: vsevl e8mf8 + vlm,  loading 1/4 of poly (1,1) storage.
> > VNx4BI: vsevl e8mf8 + vlm,  loading 1/2 of poly (1,1) storage.
> > VNx8BI: vsevl e8mf8 + vlm,  loading 1 of poly (1,1) storage.
> > 
> > So base on these, It's fine that we don't model VNx1BI,VNx2BI, VNx4BI, 
> > VNx8BI accurately according to precision or bitsize.
> > This implementation is fine even though their memory storage is not 
> > accurate.
> > 
> > However, the problem is that since they have the same bytesize, GCC will 
> > think they are the same and do some incorrect statement elimination:
> > 
> > (Note: Load same memory base)
> > load v0 VNx1BI from base0
> > load v1 VNx2BI from base0
> > load v2 VNx4BI from base0
> > load v3 VNx8BI from base0
> > 
> > store v0 base1
> > store v1 base2
> > store v2 base3
> > store v3 base4
> > 
> > This program sequence, in GCC, it will eliminate the last 3 load 
> > instructions.
> > 
> > Then it will become:
> > 
> > load v0 VNx1BI from base0 ===> vsetvl e8mf8 + vlm (only load 1/8 of poly 
> > size (1,1) memory data)
> > 
> > store v0 base1
> > store v0 base2
> > store v0 base3
> > store v0 base4
> > 
> > This is what we want to fix. I think as long as we can have the way to 
> > differentiate VNx1BI,VNx2BI, VNx4BI, VNx8BI
> > and GCC will not do th incorrect elimination for RVV. 
> > 
> > I think it can work fine  even though these 4 modes consume inaccurate 
> > memory storage size
> > but accurate data memory access load store behavior.
> 
> So given the above I think that modeling the size as being the same
> but with accurate precision would work.  It's then only the size of the
> padding in 

[pushed] analyzer: fix infinite recursion false +ves [PR108935]

[David Malcolm via Gcc-patches]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-6393-g070523b9d4c6cf.

gcc/analyzer/ChangeLog:
PR analyzer/108935
* infinite-recursion.cc (contains_unknown_p): New.
(sufficiently_different_region_binding_p): New function, splitting
out inner loop from...
(sufficiently_different_p): ...here.  Extend detection of unknown
svalues to also include svalues that contain unknown.  Treat
changes in frames below the entry to the recursion as being
sufficiently different to reject being an infinite recursion.

gcc/testsuite/ChangeLog:
PR analyzer/108935
* gcc.dg/analyzer/infinite-recursion-pr108935-1.c: New test.
* gcc.dg/analyzer/infinite-recursion-pr108935-1a.c: New test.
* gcc.dg/analyzer/infinite-recursion-pr108935-2.c: New test.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/infinite-recursion.cc| 151 --
 .../analyzer/infinite-recursion-pr108935-1.c  |  17 ++
 .../analyzer/infinite-recursion-pr108935-1a.c |  17 ++
 .../analyzer/infinite-recursion-pr108935-2.c  |  18 +++
 4 files changed, 152 insertions(+), 51 deletions(-)
 create mode 100644 
gcc/testsuite/gcc.dg/analyzer/infinite-recursion-pr108935-1.c
 create mode 100644 
gcc/testsuite/gcc.dg/analyzer/infinite-recursion-pr108935-1a.c
 create mode 100644 
gcc/testsuite/gcc.dg/analyzer/infinite-recursion-pr108935-2.c

diff --git a/gcc/analyzer/infinite-recursion.cc 
b/gcc/analyzer/infinite-recursion.cc
index 1886534313e..c262e391953 100644
--- a/gcc/analyzer/infinite-recursion.cc
+++ b/gcc/analyzer/infinite-recursion.cc
@@ -394,12 +394,108 @@ remap_enclosing_frame (const region *base_reg,
 }
 }
 
+/* Return true iff SVAL is unknown, or contains an unknown svalue.  */
+
+static bool
+contains_unknown_p (const svalue *sval)
+{
+  if (sval->get_kind () == SK_UNKNOWN)
+return true;
+  if (const compound_svalue *compound_sval
+   = sval->dyn_cast_compound_svalue ())
+for (auto iter : *compound_sval)
+  if (iter.second->get_kind () == SK_UNKNOWN)
+   return true;
+  return false;
+}
+
+/* Subroutine of sufficiently_different_p.  Compare the store bindings
+   for BASE_REG within NEW_ENTRY_ENODE and PREV_ENTRY_ENODE.
+
+   Return true if the state of NEW_ENTRY_ENODE is sufficiently different
+   from PREV_ENTRY_ENODE within BASE_REG to suggest that some variant is
+   being modified, and thus the recursion isn't infinite.
+
+   Return false if the states for BASE_REG are effectively the same.  */
+
+static bool
+sufficiently_different_region_binding_p (exploded_node *new_entry_enode,
+exploded_node *prev_entry_enode,
+const region *base_reg)
+{
+  /* Compare the stores of the two enodes.  */
+  const region_model &new_model
+= *new_entry_enode->get_state ().m_region_model;
+  const region_model &prev_model
+= *prev_entry_enode->get_state ().m_region_model;
+
+  /* Get the value within the new frame.  */
+  const svalue *new_sval
+= new_model.get_store_value (base_reg, NULL);
+
+  /* If any part of the value is UNKNOWN (e.g. due to hitting
+ complexity limits) assume that it differs from the previous
+ value.  */
+  if (contains_unknown_p (new_sval))
+return true;
+
+  /* Get the equivalent value within the old enode.  */
+  const svalue *prev_sval;
+
+  if (const frame_region *enclosing_frame
+  = base_reg->maybe_get_frame_region ())
+{
+  /* We have a binding within a frame in the new entry enode.  */
+
+  /* Consider changes in bindings below the original entry
+to the recursion.  */
+  const int old_stack_depth = prev_entry_enode->get_stack_depth ();
+  if (enclosing_frame->get_stack_depth () < old_stack_depth)
+   prev_sval = prev_model.get_store_value (base_reg, NULL);
+  else
+   {
+ /* Ignore bindings within frames below the new entry node.  */
+ const int new_stack_depth = new_entry_enode->get_stack_depth ();
+ if (enclosing_frame->get_stack_depth () < new_stack_depth)
+   return false;
+
+ /* We have a binding within the frame of the new entry node,
+presumably a parameter.  */
+
+ /* Get the value within the equivalent frame of
+the old entrypoint; typically will be the initial_svalue
+of the parameter.  */
+ const frame_region *equiv_prev_frame
+   = prev_model.get_current_frame ();
+ const region *equiv_prev_base_reg
+   = remap_enclosing_frame (base_reg,
+enclosing_frame,
+equiv_prev_frame,
+new_model.get_manager ());
+ prev_sval
+   = prev_model.get_store_value (equiv_prev_base_reg, NULL);
+   }
+}
+  else
+prev_sval = prev_model.get_store_value (base_reg, NULL);
+
+  /* If the 

Re: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

[Richard Biener via Gcc-patches]

On Wed, 1 Mar 2023, Richard Biener wrote:

> On Wed, 1 Mar 2023, juzhe.zh...@rivai.ai wrote:
> 
> > Let's me first introduce RVV load/store basics  and stack allocation.
> > For scalable vector memory allocation, we allocate memory according to 
> > machine vector-length.
> > To get this CPU vector-length value (runtime invariant but compile time 
> > unknown), we have an instruction call csrr vlenb.
> > For example, csrr a5,vlenb (store CPU a single register vector-length value 
> > (describe as bytesize) in a5 register).
> > A single register size in bytes (GET_MODE_SIZE) is poly value (8,8) bytes. 
> > That means csrr a5,vlenb, a5 has the value of size poly (8,8) bytes.
> > 
> > Now, our problem is that VNx1BI, VNx2BI, VNx4BI, VNx8BI has the same 
> > bytesize poly (1,1). So their storage consumes the same size.
> > Meaning when we want to allocate a memory storge or stack for register 
> > spillings, we should first csrr a5, vlenb, then slli a5,a5,3 (means a5 = 
> > a5/8)
> > Then, a5 has the bytesize value of poly (1,1). All VNx1BI, VNx2BI, VNx4BI, 
> > VNx8BI are doing the same process as I described above. They all consume
> > the same memory storage size since we can't model them accurately according 
> > to precision or you bitsize.
> > 
> > They consume the same storage (I am agree it's better to model them more 
> > accurately in case of memory storage comsuming).
> > 
> > Well, even though they are consuming same size memory storage, I can make 
> > their memory accessing behavior (load/store) accurately by
> > emiting  the accurate RVV instruction for them according to RVV ISA.
> > 
> > VNx1BI,VNx2BI, VNx4BI, VNx8BI are consuming same memory storage with size  
> > poly (1,1)
> > The instruction for these modes as follows:
> > VNx1BI: vsevl e8mf8 + vlm,  loading 1/8 of poly (1,1) storage.
> > VNx2BI: vsevl e8mf8 + vlm,  loading 1/4 of poly (1,1) storage.
> > VNx4BI: vsevl e8mf8 + vlm,  loading 1/2 of poly (1,1) storage.
> > VNx8BI: vsevl e8mf8 + vlm,  loading 1 of poly (1,1) storage.
> > 
> > So base on these, It's fine that we don't model VNx1BI,VNx2BI, VNx4BI, 
> > VNx8BI accurately according to precision or bitsize.
> > This implementation is fine even though their memory storage is not 
> > accurate.
> > 
> > However, the problem is that since they have the same bytesize, GCC will 
> > think they are the same and do some incorrect statement elimination:
> > 
> > (Note: Load same memory base)
> > load v0 VNx1BI from base0
> > load v1 VNx2BI from base0
> > load v2 VNx4BI from base0
> > load v3 VNx8BI from base0
> > 
> > store v0 base1
> > store v1 base2
> > store v2 base3
> > store v3 base4
> > 
> > This program sequence, in GCC, it will eliminate the last 3 load 
> > instructions.
> > 
> > Then it will become:
> > 
> > load v0 VNx1BI from base0 ===> vsetvl e8mf8 + vlm (only load 1/8 of poly 
> > size (1,1) memory data)
> > 
> > store v0 base1
> > store v0 base2
> > store v0 base3
> > store v0 base4
> > 
> > This is what we want to fix. I think as long as we can have the way to 
> > differentiate VNx1BI,VNx2BI, VNx4BI, VNx8BI
> > and GCC will not do th incorrect elimination for RVV. 
> > 
> > I think it can work fine  even though these 4 modes consume inaccurate 
> > memory storage size
> > but accurate data memory access load store behavior.
> 
> So given the above I think that modeling the size as being the same
> but with accurate precision would work.  It's then only the size of the
> padding in bytes we cannot represent with poly-int which should be fine.
> 
> Correct?

Btw, is storing a VNx1BI and then loading a VNx2BI from the same
memory address well-defined?  That is, how is the padding handled
by the machine load/store instructions?

Richard.

Re: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

[Richard Biener via Gcc-patches]

On Wed, 1 Mar 2023, juzhe.zh...@rivai.ai wrote:

> Let's me first introduce RVV load/store basics  and stack allocation.
> For scalable vector memory allocation, we allocate memory according to 
> machine vector-length.
> To get this CPU vector-length value (runtime invariant but compile time 
> unknown), we have an instruction call csrr vlenb.
> For example, csrr a5,vlenb (store CPU a single register vector-length value 
> (describe as bytesize) in a5 register).
> A single register size in bytes (GET_MODE_SIZE) is poly value (8,8) bytes. 
> That means csrr a5,vlenb, a5 has the value of size poly (8,8) bytes.
> 
> Now, our problem is that VNx1BI, VNx2BI, VNx4BI, VNx8BI has the same bytesize 
> poly (1,1). So their storage consumes the same size.
> Meaning when we want to allocate a memory storge or stack for register 
> spillings, we should first csrr a5, vlenb, then slli a5,a5,3 (means a5 = a5/8)
> Then, a5 has the bytesize value of poly (1,1). All VNx1BI, VNx2BI, VNx4BI, 
> VNx8BI are doing the same process as I described above. They all consume
> the same memory storage size since we can't model them accurately according 
> to precision or you bitsize.
> 
> They consume the same storage (I am agree it's better to model them more 
> accurately in case of memory storage comsuming).
> 
> Well, even though they are consuming same size memory storage, I can make 
> their memory accessing behavior (load/store) accurately by
> emiting  the accurate RVV instruction for them according to RVV ISA.
> 
> VNx1BI,VNx2BI, VNx4BI, VNx8BI are consuming same memory storage with size  
> poly (1,1)
> The instruction for these modes as follows:
> VNx1BI: vsevl e8mf8 + vlm,  loading 1/8 of poly (1,1) storage.
> VNx2BI: vsevl e8mf8 + vlm,  loading 1/4 of poly (1,1) storage.
> VNx4BI: vsevl e8mf8 + vlm,  loading 1/2 of poly (1,1) storage.
> VNx8BI: vsevl e8mf8 + vlm,  loading 1 of poly (1,1) storage.
> 
> So base on these, It's fine that we don't model VNx1BI,VNx2BI, VNx4BI, VNx8BI 
> accurately according to precision or bitsize.
> This implementation is fine even though their memory storage is not accurate.
> 
> However, the problem is that since they have the same bytesize, GCC will 
> think they are the same and do some incorrect statement elimination:
> 
> (Note: Load same memory base)
> load v0 VNx1BI from base0
> load v1 VNx2BI from base0
> load v2 VNx4BI from base0
> load v3 VNx8BI from base0
> 
> store v0 base1
> store v1 base2
> store v2 base3
> store v3 base4
> 
> This program sequence, in GCC, it will eliminate the last 3 load instructions.
> 
> Then it will become:
> 
> load v0 VNx1BI from base0 ===> vsetvl e8mf8 + vlm (only load 1/8 of poly size 
> (1,1) memory data)
> 
> store v0 base1
> store v0 base2
> store v0 base3
> store v0 base4
> 
> This is what we want to fix. I think as long as we can have the way to 
> differentiate VNx1BI,VNx2BI, VNx4BI, VNx8BI
> and GCC will not do th incorrect elimination for RVV. 
> 
> I think it can work fine  even though these 4 modes consume inaccurate memory 
> storage size
> but accurate data memory access load store behavior.

So given the above I think that modeling the size as being the same
but with accurate precision would work.  It's then only the size of the
padding in bytes we cannot represent with poly-int which should be fine.

Correct?

Richard.

> Thanks.
> 
> 
> juzhe.zh...@rivai.ai
>  
> From: Richard Sandiford
> Date: 2023-03-01 21:19
> To: Pan Li via Gcc-patches
> CC: Richard Biener; Pan Li; juzhe.zhong\@rivai.ai; pan2.li; Kito.cheng
> Subject: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment
> Pan Li via Gcc-patches  writes:
> > I am not very familiar with the memory pattern, maybe juzhe can provide 
> > more information or correct me if anything is misleading.
> >
> > The different precision try to resolve the below bugs, the second vlm(with 
> > different size of load bytes compared to first one)
> > is eliminated because vbool8 and vbool16 have the same precision size, aka 
> > [8, 8].
> >
> > vbool8_t v2 = *(vbool8_t*)in;
> > vbool16_t v5 = *(vbool16_t*)in;
> > *(vbool16_t*)(out + 200) = v5;
> > *(vbool8_t*)(out + 100) = v2;
> >
> > addia4,a1,100
> > vsetvli a5,zero,e8,m1,ta,ma
> > addia1,a1,200
> > vlm.v   v24,0(a0)
> > vsm.v   v24,0(a4)
> > // Need one vsetvli and vlm.v for correctness here.
> > vsm.v   v24,0(a1)
>  
> But I think it's important to think about the patch as more than a way
> of fixing the bug above.  The aim has to be to describe the modes as they
> really are.
>  
> I don't think there's a way for GET_MODE_SIZE to be "conservatively wrong".
> A GET_MODE_SIZE that is too small would cause problems.  So would a
> GET_MODE_SIZE that is too big.
>  
> Like Richard says, I think the question comes down to the amount of padding.
> Is it the case that for 4+4X ([4,4]), the memory representation has 4 bits
> of padding for even X and 0 bits of padding for odd X?
>  
> I agree getting rid of GET_MODE_SIZE and representin

Re: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

[juzhe.zhong]

Sorry for missleading typo.

>> VNx1BI: vsevl e8mf8 + vlm,  loading 1/8 of poly (1,1) storage.
>> VNx2BI: vsevl e8mf8 + vlm,  loading 1/4 of poly (1,1) storage.
>> VNx4BI: vsevl e8mf8 + vlm,  loading 1/2 of poly (1,1) storage.
>> VNx8BI: vsevl e8mf8 + vlm,  loading 1 of poly (1,1) storage.

It should be:
 VNx1BI: vsevl e8mf8 + vlm,  loading 1/8 of poly (1,1) storage.
 VNx2BI: vsevl e8mf4 + vlm,  loading 1/4 of poly (1,1) storage.
 VNx4BI: vsevl e8mf2 + vlm,  loading 1/2 of poly (1,1) storage.
 VNx8BI: vsevl e8m1 + vlm,  loading 1 of poly (1,1) storage.

Plz be aware of this . Thanks. 


juzhe.zh...@rivai.ai
 
From: juzhe.zh...@rivai.ai
Date: 2023-03-01 21:50
To: richard.sandiford; gcc-patches
CC: rguenther; Pan Li; pan2.li; kito.cheng
Subject: Re: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment
Let's me first introduce RVV load/store basics  and stack allocation.
For scalable vector memory allocation, we allocate memory according to machine 
vector-length.
To get this CPU vector-length value (runtime invariant but compile time 
unknown), we have an instruction call csrr vlenb.
For example, csrr a5,vlenb (store CPU a single register vector-length value 
(describe as bytesize) in a5 register).
A single register size in bytes (GET_MODE_SIZE) is poly value (8,8) bytes. That 
means csrr a5,vlenb, a5 has the value of size poly (8,8) bytes.

Now, our problem is that VNx1BI, VNx2BI, VNx4BI, VNx8BI has the same bytesize 
poly (1,1). So their storage consumes the same size.
Meaning when we want to allocate a memory storge or stack for register 
spillings, we should first csrr a5, vlenb, then slli a5,a5,3 (means a5 = a5/8)
Then, a5 has the bytesize value of poly (1,1). All VNx1BI, VNx2BI, VNx4BI, 
VNx8BI are doing the same process as I described above. They all consume
the same memory storage size since we can't model them accurately according to 
precision or you bitsize.

They consume the same storage (I am agree it's better to model them more 
accurately in case of memory storage comsuming).

Well, even though they are consuming same size memory storage, I can make their 
memory accessing behavior (load/store) accurately by
emiting  the accurate RVV instruction for them according to RVV ISA.

VNx1BI,VNx2BI, VNx4BI, VNx8BI are consuming same memory storage with size  poly 
(1,1)
The instruction for these modes as follows:
VNx1BI: vsevl e8mf8 + vlm,  loading 1/8 of poly (1,1) storage.
VNx2BI: vsevl e8mf8 + vlm,  loading 1/4 of poly (1,1) storage.
VNx4BI: vsevl e8mf8 + vlm,  loading 1/2 of poly (1,1) storage.
VNx8BI: vsevl e8mf8 + vlm,  loading 1 of poly (1,1) storage.

So base on these, It's fine that we don't model VNx1BI,VNx2BI, VNx4BI, VNx8BI 
accurately according to precision or bitsize.
This implementation is fine even though their memory storage is not accurate.

However, the problem is that since they have the same bytesize, GCC will think 
they are the same and do some incorrect statement elimination:

(Note: Load same memory base)
load v0 VNx1BI from base0
load v1 VNx2BI from base0
load v2 VNx4BI from base0
load v3 VNx8BI from base0

store v0 base1
store v1 base2
store v2 base3
store v3 base4

This program sequence, in GCC, it will eliminate the last 3 load instructions.

Then it will become:

load v0 VNx1BI from base0 ===> vsetvl e8mf8 + vlm (only load 1/8 of poly size 
(1,1) memory data)

store v0 base1
store v0 base2
store v0 base3
store v0 base4

This is what we want to fix. I think as long as we can have the way to 
differentiate VNx1BI,VNx2BI, VNx4BI, VNx8BI
and GCC will not do th incorrect elimination for RVV. 

I think it can work fine  even though these 4 modes consume inaccurate memory 
storage size
but accurate data memory access load store behavior.

Thanks.


juzhe.zh...@rivai.ai
 
From: Richard Sandiford
Date: 2023-03-01 21:19
To: Pan Li via Gcc-patches
CC: Richard Biener; Pan Li; juzhe.zhong\@rivai.ai; pan2.li; Kito.cheng
Subject: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment
Pan Li via Gcc-patches  writes:
> I am not very familiar with the memory pattern, maybe juzhe can provide more 
> information or correct me if anything is misleading.
>
> The different precision try to resolve the below bugs, the second vlm(with 
> different size of load bytes compared to first one)
> is eliminated because vbool8 and vbool16 have the same precision size, aka 
> [8, 8].
>
> vbool8_t v2 = *(vbool8_t*)in;
> vbool16_t v5 = *(vbool16_t*)in;
> *(vbool16_t*)(out + 200) = v5;
> *(vbool8_t*)(out + 100) = v2;
>
> addia4,a1,100
> vsetvli a5,zero,e8,m1,ta,ma
> addia1,a1,200
> vlm.v   v24,0(a0)
> vsm.v   v24,0(a4)
> // Need one vsetvli and vlm.v for correctness here.
> vsm.v   v24,0(a1)
 
But I think it's important to think about the patch as more than a way
of fixing the bug above.  The aim has to be to describe the modes as they
really are.
 
I don't think there's a way for GET_MODE_SIZE to be "conservatively wrong".
A GET_MODE_SIZE that is too small would cause problem

Re: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

[juzhe.zhong]

Let's me first introduce RVV load/store basics  and stack allocation.
For scalable vector memory allocation, we allocate memory according to machine 
vector-length.
To get this CPU vector-length value (runtime invariant but compile time 
unknown), we have an instruction call csrr vlenb.
For example, csrr a5,vlenb (store CPU a single register vector-length value 
(describe as bytesize) in a5 register).
A single register size in bytes (GET_MODE_SIZE) is poly value (8,8) bytes. That 
means csrr a5,vlenb, a5 has the value of size poly (8,8) bytes.

Now, our problem is that VNx1BI, VNx2BI, VNx4BI, VNx8BI has the same bytesize 
poly (1,1). So their storage consumes the same size.
Meaning when we want to allocate a memory storge or stack for register 
spillings, we should first csrr a5, vlenb, then slli a5,a5,3 (means a5 = a5/8)
Then, a5 has the bytesize value of poly (1,1). All VNx1BI, VNx2BI, VNx4BI, 
VNx8BI are doing the same process as I described above. They all consume
the same memory storage size since we can't model them accurately according to 
precision or you bitsize.

They consume the same storage (I am agree it's better to model them more 
accurately in case of memory storage comsuming).

Well, even though they are consuming same size memory storage, I can make their 
memory accessing behavior (load/store) accurately by
emiting  the accurate RVV instruction for them according to RVV ISA.

VNx1BI,VNx2BI, VNx4BI, VNx8BI are consuming same memory storage with size  poly 
(1,1)
The instruction for these modes as follows:
VNx1BI: vsevl e8mf8 + vlm,  loading 1/8 of poly (1,1) storage.
VNx2BI: vsevl e8mf8 + vlm,  loading 1/4 of poly (1,1) storage.
VNx4BI: vsevl e8mf8 + vlm,  loading 1/2 of poly (1,1) storage.
VNx8BI: vsevl e8mf8 + vlm,  loading 1 of poly (1,1) storage.

So base on these, It's fine that we don't model VNx1BI,VNx2BI, VNx4BI, VNx8BI 
accurately according to precision or bitsize.
This implementation is fine even though their memory storage is not accurate.

However, the problem is that since they have the same bytesize, GCC will think 
they are the same and do some incorrect statement elimination:

(Note: Load same memory base)
load v0 VNx1BI from base0
load v1 VNx2BI from base0
load v2 VNx4BI from base0
load v3 VNx8BI from base0

store v0 base1
store v1 base2
store v2 base3
store v3 base4

This program sequence, in GCC, it will eliminate the last 3 load instructions.

Then it will become:

load v0 VNx1BI from base0 ===> vsetvl e8mf8 + vlm (only load 1/8 of poly size 
(1,1) memory data)

store v0 base1
store v0 base2
store v0 base3
store v0 base4

This is what we want to fix. I think as long as we can have the way to 
differentiate VNx1BI,VNx2BI, VNx4BI, VNx8BI
and GCC will not do th incorrect elimination for RVV. 

I think it can work fine  even though these 4 modes consume inaccurate memory 
storage size
but accurate data memory access load store behavior.

Thanks.


juzhe.zh...@rivai.ai
 
From: Richard Sandiford
Date: 2023-03-01 21:19
To: Pan Li via Gcc-patches
CC: Richard Biener; Pan Li; juzhe.zhong\@rivai.ai; pan2.li; Kito.cheng
Subject: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment
Pan Li via Gcc-patches  writes:
> I am not very familiar with the memory pattern, maybe juzhe can provide more 
> information or correct me if anything is misleading.
>
> The different precision try to resolve the below bugs, the second vlm(with 
> different size of load bytes compared to first one)
> is eliminated because vbool8 and vbool16 have the same precision size, aka 
> [8, 8].
>
> vbool8_t v2 = *(vbool8_t*)in;
> vbool16_t v5 = *(vbool16_t*)in;
> *(vbool16_t*)(out + 200) = v5;
> *(vbool8_t*)(out + 100) = v2;
>
> addia4,a1,100
> vsetvli a5,zero,e8,m1,ta,ma
> addia1,a1,200
> vlm.v   v24,0(a0)
> vsm.v   v24,0(a4)
> // Need one vsetvli and vlm.v for correctness here.
> vsm.v   v24,0(a1)
 
But I think it's important to think about the patch as more than a way
of fixing the bug above.  The aim has to be to describe the modes as they
really are.
 
I don't think there's a way for GET_MODE_SIZE to be "conservatively wrong".
A GET_MODE_SIZE that is too small would cause problems.  So would a
GET_MODE_SIZE that is too big.
 
Like Richard says, I think the question comes down to the amount of padding.
Is it the case that for 4+4X ([4,4]), the memory representation has 4 bits
of padding for even X and 0 bits of padding for odd X?
 
I agree getting rid of GET_MODE_SIZE and representing everything in bits
would avoid the problem at this point, but I think it would just be pushing
the difficulty elsewhere.  E.g. stack layout will be "interesting" if we
can't work in byte sizes.
 
Thanks,
Richard
 

Re: [Patch] OpenMP: Ignore side-effects when finding struct comps [PR108545]

[Tobias Burnus]

On 01.03.23 14:03, Jakub Jelinek wrote:

On Tue, Feb 28, 2023 at 02:06:43PM +0100, Tobias Burnus wrote:
[...]
Do we use that hashing even say for ARRAY_REFs with array indexes?
Using OEP_MATCH_SIDE_EFFECTS will mean that
volatile int idx;
a.b[idx] and a.b[idx] will compare equal.  On the other side,
if idx yielded different values on the same construct between the two,
I think it would be invalid OpenMP (trying to map the two different
array elements from the same array section), so perhaps we are ok.


I think we are also okay because the sorting is for grouping and not
for combining. I think you mean code like:

struct t { int b[10]; } a;
void f() {
  volatile int i = 1;
  #pragma omp target enter data map(to: a.b[i], a.b[i])
}

This produces (independent of the patch) in the omplower dump:
 #pragma omp target enter data \
  map(struct:a [len: 2]) \
  map(to:a.b[i.0] [len: 4]) \
  map(to:a.b[i.1] [len: 4])

(Same result when removing the 'volatile' on 'i'.)

Without the patch, adding the 'volatile' to 'a' will break the
analysis such that two  'struct:a [len: 1]'  appear – causing the ICE.
With the patch, we are back to the initial result as shown above.


+/* Hash for trees based on operand_equal_p.
+   Like tree_operand_hash but accepts side effects.  */
+struct tree_operand_sideeff_hash : ggc_ptr_hash 

Not sure about the name, it isn't about that it accepts side effects,
but that it ignores them in the equality comparisons.
OEP_MATCH_SIDE_EFFECTS is probably misnamed too.

I concur.

So perhaps struct tree_operand_hash_no_se (+ adjust the comment)?

OK.

Also, can't you derive it from tree_operand_hash?
Than you wouldn't need to provide your own hash, you could
inherit tree_operand_hash::hash and just override equal.

That would work as well - and done so.

Otherwise LGTM.


Updated version attached. Once build + quick test has succeeded, I
intent to commit it, unless more comments come up.

Thanks for the review/suggestions,

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
OpenMP: Ignore side-effects when finding struct comps [PR108545]

With volatile, two 'x.data' comp refs aren't regarded as identical,
causing that the two items in the first map of
  map(to:x.a, x.a.data) map(pset: x.a.data)
end up in separate 'map(struct:x)', which will cause a later ICE.

Solution: Ignore side effects when checking the operands in the hash
for being equal. (Do so by creating a variant of tree_operand_hash
that calls operand_equal_p with OEP_MATCH_SIDE_EFFECTS.)

gcc/ChangeLog:

	PR middle-end/108545
	* gimplify.cc (struct tree_operand_hash_no_se): New.
	omp_index_mapping_groups_1, omp_index_mapping_groups,
	omp_reindex_mapping_groups, omp_mapped_by_containing_struct,
	omp_tsort_mapping_groups_1, omp_tsort_mapping_groups,
	oacc_resolve_clause_dependencies, omp_build_struct_sibling_lists,
	gimplify_scan_omp_clauses): Use tree_operand_hash_no_se instead
	of tree_operand_hash.

gcc/testsuite/ChangeLog:

	PR middle-end/108545
	* c-c++-common/gomp/map-8.c: New test.
	* gfortran.dg/gomp/map-9.f90: New test.

 gcc/gimplify.cc  | 51 +---
 gcc/testsuite/c-c++-common/gomp/map-8.c  | 19 
 gcc/testsuite/gfortran.dg/gomp/map-9.f90 | 13 
 3 files changed, 65 insertions(+), 18 deletions(-)

diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index 35d1ea22623..ade6e335da7 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -8958,6 +8958,22 @@ enum omp_tsort_mark {
   PERMANENT
 };
 
+/* Hash for trees based on operand_equal_p.  Like tree_operand_hash
+   but ignores side effects in the equality comparisons.  */
+
+struct tree_operand_hash_no_se : tree_operand_hash
+{
+  static inline bool equal (const value_type &,
+			const compare_type &);
+};
+
+inline bool
+tree_operand_hash_no_se::equal (const value_type &t1,
+const compare_type &t2)
+{
+  return operand_equal_p (t1, t2, OEP_MATCH_SIDE_EFFECTS);
+}
+
 /* A group of OMP_CLAUSE_MAP nodes that correspond to a single "map"
clause.  */
 
@@ -9400,10 +9416,10 @@ omp_group_base (omp_mapping_group *grp, unsigned int *chained,
 }
 
 /* Given a vector of omp_mapping_groups, build a hash table so we can look up
-   nodes by tree_operand_hash.  */
+   nodes by tree_operand_hash_no_se.  */
 
 static void
-omp_index_mapping_groups_1 (hash_map *grpmap,
 			vec *groups,
 			tree reindex_sentinel)
@@ -9432,7 +9448,6 @@ omp_index_mapping_groups_1 (hash_map *
+static hash_map *
 omp_index_mapping_groups (vec *groups)
 {
-  hash_map *grpmap
-= new hash_map;
+  hash_map *grpmap
+= new hash_map;
 
   omp_index_mapping_groups_1 (grpmap, groups, NULL_TREE);
 
@@ -9502,14 +9517,14 @@ omp_index_mapping_groups (vec *groups)
so, we can do the reindex operatio

Re: [PATCH] gcc: Remove size limit of PCH for *-*-mingw32 hosts

[Jonathan Yong via Gcc-patches]

On 3/1/23 09:21, Richard Biener wrote:

On Wed, Mar 1, 2023 at 9:52 AM NightStrike via Gcc-patches
 wrote:


On Thu, Feb 16, 2023, 11:10 LIU Hao via Gcc-patches 
wrote:



--
Best regards,
LIU Hao



Ping


OK.





Done, pushed to master branch.

Re: [Patch] harden-sls-6.c: fix warning on LLP64

[Jonathan Yong via Gcc-patches]

On 2/28/23 18:15, Jakub Jelinek wrote:

On Wed, Feb 15, 2023 at 01:44:08PM +, Jonathan Yong via Gcc-patches wrote:

gcc/testsuite/ChangeLog:

 * gcc.target/i386/harden-sls-6.c: fix warning on LLP64
 targets.

Attached patch OK?



 From c0572a1e95c6f569980d6b7454c8dc293f07389e Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Wed, 15 Feb 2023 13:42:12 +
Subject: [PATCH] harden-sls-6.c: fix warning on LLP64

gcc/testsuite/ChangeLog:

* gcc.target/i386/harden-sls-6.c: fix warning on LLP64
targets.


s/fix/Fix/

Otherwise LGTM.


Pushed to master branch, thanks.

Re: [Patch] gcc.dg/memchr-3.c: fix for LLP64

[Jonathan Yong via Gcc-patches]

On 2/27/23 16:55, Richard Sandiford wrote:

Jonathan Yong via Gcc-patches  writes:

Attached patch OK?

  gcc.dg/memchr-3.c: fix for LLP64

  gcc/testsuite/ChangeLog:

  PR middle-end/97956
  * gcc.dg/memchr-3.c (memchr): fix long to size_t in
  prototype.

 From 194eb3d43964276beeaea14ebee4b241799cd966 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Mon, 27 Feb 2023 10:02:32 +
Subject: [PATCH] gcc.dg/memchr-3.c: fix for LLP64

gcc/testsuite/ChangeLog:

PR middle-end/97956
* gcc.dg/memchr-3.c (memchr): fix long to size_t in
prototype.


It looks like the current type signature could have been a deliberate
part of the test.  I think we should just skip it for LLP64 instead.
Preapproved if you agree.

Thanks,
Richard



Revised, account for the warning in LLP64.


From 2dbfa538fe11c65914b28f94d066daee789f881a Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Mon, 27 Feb 2023 10:02:32 +
Subject: [PATCH 6/7] gcc.dg/memchr-3.c: Account for LLP64 warnings

	gcc/testsuite/ChangeLog:

	PR middle-end/97956
	* gcc.dg/memchr-3.c (memchr): Account for LLP64 warnings.

Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
 gcc/testsuite/gcc.dg/memchr-3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/memchr-3.c b/gcc/testsuite/gcc.dg/memchr-3.c
index c38d9cf3349..af1b26ef3ae 100644
--- a/gcc/testsuite/gcc.dg/memchr-3.c
+++ b/gcc/testsuite/gcc.dg/memchr-3.c
@@ -6,7 +6,7 @@
 typedef __INT8_TYPE__  int8_t;
 typedef __INT32_TYPE__ int32_t;
 
-extern void* memchr (const void*, int, long);
+extern void* memchr (const void*, int, long); /* { dg-warning "-Wbuiltin-declaration-mismatch" { target llp64 } } */
 
 struct SX
 {
-- 
2.39.2

Re: [PATCH 1/2] testsuite: Fix analyzer errors for newlib-errno

[David Malcolm via Gcc-patches]

On Wed, 2023-03-01 at 04:01 +0100, Hans-Peter Nilsson wrote:
> > From: David Malcolm 
> > Date: Tue, 28 Feb 2023 21:25:34 -0500
> 
> > On Wed, 2023-03-01 at 01:59 +0100, Hans-Peter Nilsson wrote:
> > > > From: David Malcolm 
> > > > Date: Tue, 28 Feb 2023 14:12:47 -0500
> > > 
> > > > On Tue, 2023-02-28 at 19:47 +0100, Hans-Peter Nilsson wrote:
> > > > > Ok to commit?
> > > > > -- >8 --
> > > > > Investigating analyzer tesstsuite errors for cris-elf.  The
> > > > > same
> > > > > are
> > > > > seen for pru-elf according to posts to gcc-testresults@.
> > > > > 
> > > > > For glibc, errno is #defined as:
> > > > >  extern int *__errno_location (void) __THROW
> > > > > __attribute_const__;
> > > > >  # define errno (*__errno_location ())
> > > > > while for newlib in its default configuration, it's:
> > > > >  #define errno (*__errno())
> > > > >  extern int *__errno (void);
> > > > 
> > > > We're already handling ___errno (three underscores) for Solaris
> > > > as
> > > > of
> > > > 7c9717fcb5cf94ce1e7ef5c903058adf9980ff28; does it fix the issue
> > > > if
> > > > you 
> > > > add __errno (two underscores) to analyzer/kf.cc's 
> > > > register_known_functions in an analogous way to that commit? 
> > > > (i.e.
> > > > wiring it up to kf_errno_location, "teaching" the analyzer that
> > > > that
> > > > function returns a pointer to the "errno region")
> > > 
> > > But...there's already "support" for two underscores since
> > > the commit you quote, so I guess not.  
> > 
> > Is there?  That commit adds support for:
> >   __error
> > but not for:
> >   __errno
> > unless there's something I'm missing.
> 
> No, it's me.  Apparently I can't spot the difference between
> error and errno.  Sorry.
> 
> It's nice to know that the const-attribute (to signal that
> the pointer points to a constant location) works
> automatically, i.e. the Solaris and glibc definitions should
> not (no longer?) be needed - unless there's other
> errno-analyzing magic elsewhere too.  

With the const-attribute, the analyzer "knows" that the pointer it gets
back always points to the same thing, but it doesn't know what it
points to, and so has to assume that any writes to errno could modify
anything that has escaped.

Also, the analyzer uses region_model::set_errno in various
known_function implementations, e.g. for functions that can succeed or
fail, to set errno on the "failure" execution path to a new symbolic
value that tests as > 0.

> Either way, since
> there's specific support for this errno kind of thing, that
> certainly works for me.  The patch gets smaller too. :)

:)

> 
> So, how's this instead, pending full testing (only
> analyzer.exp spot-tested)?

Looks good, though how about adding a mention of newlib to the comment
immediately above (the one that talks about Solaris and OS X)?

Thanks for fixing this
Dave

Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

[Richard Biener via Gcc-patches]

On Wed, 1 Mar 2023, Richard Sandiford wrote:

> Pan Li via Gcc-patches  writes:
> > I am not very familiar with the memory pattern, maybe juzhe can provide 
> > more information or correct me if anything is misleading.
> >
> > The different precision try to resolve the below bugs, the second vlm(with 
> > different size of load bytes compared to first one)
> > is eliminated because vbool8 and vbool16 have the same precision size, aka 
> > [8, 8].
> >
> > vbool8_t v2 = *(vbool8_t*)in;
> > vbool16_t v5 = *(vbool16_t*)in;
> > *(vbool16_t*)(out + 200) = v5;
> > *(vbool8_t*)(out + 100) = v2;
> >
> > addia4,a1,100
> > vsetvli a5,zero,e8,m1,ta,ma
> > addia1,a1,200
> > vlm.v   v24,0(a0)
> > vsm.v   v24,0(a4)
> > // Need one vsetvli and vlm.v for correctness here.
> > vsm.v   v24,0(a1)
> 
> But I think it's important to think about the patch as more than a way
> of fixing the bug above.  The aim has to be to describe the modes as they
> really are.
> 
> I don't think there's a way for GET_MODE_SIZE to be "conservatively wrong".
> A GET_MODE_SIZE that is too small would cause problems.  So would a
> GET_MODE_SIZE that is too big.
> 
> Like Richard says, I think the question comes down to the amount of padding.
> Is it the case that for 4+4X ([4,4]), the memory representation has 4 bits
> of padding for even X and 0 bits of padding for odd X?
> 
> I agree getting rid of GET_MODE_SIZE and representing everything in bits
> would avoid the problem at this point, but I think it would just be pushing
> the difficulty elsewhere.  E.g. stack layout will be "interesting" if we
> can't work in byte sizes.

I suppose the backend could ensure when it performs setvl, that we only
ever end up with the even or odd case and also restrict vectorization
that way?  So we could implement the working half and leave the not
working half never happening at runtime ...

Richard.

Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

[Richard Sandiford via Gcc-patches]

Pan Li via Gcc-patches  writes:
> I am not very familiar with the memory pattern, maybe juzhe can provide more 
> information or correct me if anything is misleading.
>
> The different precision try to resolve the below bugs, the second vlm(with 
> different size of load bytes compared to first one)
> is eliminated because vbool8 and vbool16 have the same precision size, aka 
> [8, 8].
>
> vbool8_t v2 = *(vbool8_t*)in;
> vbool16_t v5 = *(vbool16_t*)in;
> *(vbool16_t*)(out + 200) = v5;
> *(vbool8_t*)(out + 100) = v2;
>
> addia4,a1,100
> vsetvli a5,zero,e8,m1,ta,ma
> addia1,a1,200
> vlm.v   v24,0(a0)
> vsm.v   v24,0(a4)
> // Need one vsetvli and vlm.v for correctness here.
> vsm.v   v24,0(a1)

But I think it's important to think about the patch as more than a way
of fixing the bug above.  The aim has to be to describe the modes as they
really are.

I don't think there's a way for GET_MODE_SIZE to be "conservatively wrong".
A GET_MODE_SIZE that is too small would cause problems.  So would a
GET_MODE_SIZE that is too big.

Like Richard says, I think the question comes down to the amount of padding.
Is it the case that for 4+4X ([4,4]), the memory representation has 4 bits
of padding for even X and 0 bits of padding for odd X?

I agree getting rid of GET_MODE_SIZE and representing everything in bits
would avoid the problem at this point, but I think it would just be pushing
the difficulty elsewhere.  E.g. stack layout will be "interesting" if we
can't work in byte sizes.

Thanks,
Richard

Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

[Richard Biener via Gcc-patches]

On Wed, 1 Mar 2023, Pan Li wrote:

> I am not very familiar with the memory pattern, maybe juzhe can provide more 
> information or correct me if anything is misleading.
> 
> The different precision try to resolve the below bugs, the second 
> vlm(with different size of load bytes compared to first one) is 
> eliminated because vbool8 and vbool16 have the same precision size, aka 
> [8, 8].

That's because the corresponding data vectors to vbool8 and vbool16
have the same number of lanes, right?  (another RVV pecularity)

> vbool8_t v2 = *(vbool8_t*)in;
> vbool16_t v5 = *(vbool16_t*)in;
> *(vbool16_t*)(out + 200) = v5;
> *(vbool8_t*)(out + 100) = v2;
> 
> addia4,a1,100
> vsetvli a5,zero,e8,m1,ta,ma
> addia1,a1,200
> vlm.v   v24,0(a0)
> vsm.v   v24,0(a4)
> // Need one vsetvli and vlm.v for correctness here.
> vsm.v   v24,0(a1)
> 
> Pan
> 
> From: Richard Biener 
> Sent: Wednesday, March 1, 2023 20:33
> To: Richard Sandiford 
> Cc: 盼 李 via Gcc-patches ; 盼 李 
> ; juzhe.zh...@rivai.ai ; 
> pan2.li ; Kito.cheng 
> Subject: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment
> 
> On Wed, 1 Mar 2023, Richard Sandiford wrote:
> 
> > 盼 李 via Gcc-patches  writes:
> > > Just have a test with the below code, the [0x4, 0x4] test comes from 
> > > VNx4BI. You can notice that the mode size is unchanged.
> > >
> > > printf ("can_div_away_from_zero_p (mode_precision[E_%smode], "
> > >   "BITS_PER_UNIT, &mode_size[E_%smode]);\n", m->name, m->name);
> > >
> > > VNx4BI Before precision [0x4, 0x4], size [0x4, 0]
> > > VNx4BI After precision [0x4, 0x4], size [0x4, 0]
> >
> > Yeah, the result is expected to be unchanged if the division fails.
> > That's a deliberate part of the interface.  The can_* functions
> > should never be used without testing the boolean return value.
> >
> > But this precision of [4,4] for VNx4BI is different from what you
> > listed below.  Like I say, if the precision really is [4,4], and if
> > the size really is ceil([4,4]/8), then I don't think we can represent
> > that with current infrastructure.
> 
> The size of VNx4BI is (4*N + 7) / 8 bytes.  I suppose we could simply
> not store the size in bytes but only the size in bits then?
> 
> I see the problem, but I also don't see a good solution since
> for VNx4BI with N == 3 we have one and a half byte of storage.
> 
> How do memory access patterns work with poly-int sizes?
> 
> >
> > Thanks,
> > Richard
> >
> > >
> > > Pan
> > > 
> > > From: Richard Sandiford 
> > > Sent: Wednesday, March 1, 2023 19:11
> > > To: 盼 李 via Gcc-patches 
> > > Cc: juzhe.zh...@rivai.ai ; pan2.li 
> > > ; 盼 李 ; Kito.cheng 
> > > ; rguenther 
> > > Subject: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment
> > >
> > > 盼 李 via Gcc-patches  writes:
> > >> Thank you all for your quick response.
> > >>
> > >> As juzhe mentioned, the memory access of RISC-V will be always aligned 
> > >> to the bytes boundary with the compact mode, aka ceil(vl / 8) bytes for 
> > >> vbool*.
> > >
> > > OK, thanks to both of you.  This is what I'd have expected.
> > >
> > > In that case, I think both the can_div_away_from_zero_p and the
> > > original patch (using size_one) will give the wrong results.
> > > There isn't a way of representing ceil([4,4]/8) as a poly_int.
> > > The result is (4+4X)/8 when X is odd and (8+4X)/8 when X is even.
> > >
> > >> Actually, the data [4,4] comes from the self-test, the RISC-V precision 
> > >> mode as below.
> > >>
> > >> VNx64BI precision [0x40, 0x40].
> > >> VNx32BI precision [0x20, 0x20].
> > >> VNx16BI precision [0x10, 0x10].
> > >> VNx8BI precision [0x8, 0x8].
> > >> VNx4BI precision [0x8, 0x8].
> > >> VNx2BI precision [0x8, 0x8].
> > >> VNx1BI precision [0x8, 0x8].
> > >
> > > Ah, OK.  Which self-test causes this?
> > >
> > > Richard
> > >
> > >> The impact of data [4, 4] will impact the genmode part, we cannot write 
> > >> like below as the gcc_unreachable will be hitten.
> > >>
> > >> if (!can_div_away_from_zero_p (mode_precision[E_%smode], BITS_PER_UNIT,  
> > >> &mode_size[E_%smode]))
> > >>   gcc_unreachable (); // Hit on [4, 4] of the self-test.
> > >>
> > >> Pan
> > >> 
> > >> From: juzhe.zh...@rivai.ai 
> > >> Sent: Wednesday, March 1, 2023 18:46
> > >> To: richard.sandiford ; pan2.li 
> > >> 
> > >> Cc: incarnation.p.lee ; gcc-patches 
> > >> ; Kito.cheng ; rguenther 
> > >> 
> > >> Subject: Re: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision 
> > >> adjustment
> > >>
> >  Is it right that, for RVV, a load or store of [4,4] will access [8,8]
> > bits, even when that means accessing fully-unused bytes?  E.g. 4+4X
> > when X=3 would be 16 bits/2 bytes of useful data, but a bitsize of
> > 8+8X would be 32 bits/4 bytes.  So a store of [8,8] for a precision
> > of [4,4] would store 2 bytes beyond the end of the useful data when 
> > X==3?
> > >>
> > >> Hi, Richard. Thank you for hel

Re: [PATCH] debug/108772 - ICE with late debug generated with -flto

[Jakub Jelinek via Gcc-patches]

On Wed, Mar 01, 2023 at 01:07:02PM +, Richard Biener wrote:
> When combining -g1 with -flto we run into the DIE location annotation
> machinery for globals calling dwarf2out_late_global_decl but not
> having any early generated DIE for function scope statics.  In
> this process we'd generate a limbo DIE since also the function scope
> doesn't have any early generated DIE.  The limbo handling then tries
> to force a DIE for the context chain which ultimatively fails and
> ICEs at the std namespace decl because at -g1 we don't represent that.
> 
> The following avoids this situation by making sure to never generate
> any limbo DIEs from dwarf2out_late_global_decl in the in_lto_p path
> but instead for function scope globals rely on DIE generation for
> the function to output a DIE for the local static (which doesn't
> happen for -g1).
> 
> I explored a lot of other options to fix this but in the end this
> seems to be the most spot-on fix with the least risk of unwanted
> effects.
> 
> LTO bootstrapped on x86_64-unknown-linux-gnu (running into PR108984),
> bootstrapped and tested on x86_64-unknown-linux-gnu.
> 
> OK?
> 
> Thanks,
> Richard.
> 
>   PR debug/108772
>   * dwarf2out.cc (dwarf2out_late_global_decl): Do not
>   generate a DIE for a function scope static when we do
>   not have a DIE for the function already.
> 
>   * g++.dg/lto/pr108772_0.C: New testcase.

LGTM, but please give Jason a day to chime in if he disagrees.

Jakub

[PATCH] debug/108772 - ICE with late debug generated with -flto

[Richard Biener via Gcc-patches]

When combining -g1 with -flto we run into the DIE location annotation
machinery for globals calling dwarf2out_late_global_decl but not
having any early generated DIE for function scope statics.  In
this process we'd generate a limbo DIE since also the function scope
doesn't have any early generated DIE.  The limbo handling then tries
to force a DIE for the context chain which ultimatively fails and
ICEs at the std namespace decl because at -g1 we don't represent that.

The following avoids this situation by making sure to never generate
any limbo DIEs from dwarf2out_late_global_decl in the in_lto_p path
but instead for function scope globals rely on DIE generation for
the function to output a DIE for the local static (which doesn't
happen for -g1).

I explored a lot of other options to fix this but in the end this
seems to be the most spot-on fix with the least risk of unwanted
effects.

LTO bootstrapped on x86_64-unknown-linux-gnu (running into PR108984),
bootstrapped and tested on x86_64-unknown-linux-gnu.

OK?

Thanks,
Richard.

PR debug/108772
* dwarf2out.cc (dwarf2out_late_global_decl): Do not
generate a DIE for a function scope static when we do
not have a DIE for the function already.

* g++.dg/lto/pr108772_0.C: New testcase.
---
 gcc/dwarf2out.cc  | 12 ++-
 gcc/testsuite/g++.dg/lto/pr108772_0.C | 46 +++
 2 files changed, 57 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/lto/pr108772_0.C

diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
index 1f39df3b1e2..6f457ed4472 100644
--- a/gcc/dwarf2out.cc
+++ b/gcc/dwarf2out.cc
@@ -27283,7 +27283,17 @@ dwarf2out_late_global_decl (tree decl)
  was not enabled at compile-time or the target doesn't support
 the LTO early debug scheme.  */
   if (! die && in_lto_p)
-   dwarf2out_decl (decl);
+   {
+ /* Avoid relying on the ability to force context DIEs for
+local entities.  Instead if the function context was not
+instantiated yet defer to it producing its local DIEs.
+See PR108772.  */
+ dw_die_ref context_die = comp_unit_die ();
+ if (local_function_static (decl))
+   context_die = lookup_decl_die (DECL_CONTEXT (decl));
+ if (context_die)
+   dwarf2out_decl (decl);
+   }
   else if (die)
{
  /* We get called via the symtab code invoking late_global_decl
diff --git a/gcc/testsuite/g++.dg/lto/pr108772_0.C 
b/gcc/testsuite/g++.dg/lto/pr108772_0.C
new file mode 100644
index 000..81f15a90a3e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/lto/pr108772_0.C
@@ -0,0 +1,46 @@
+// { dg-lto-do link }
+// { dg-require-effective-target shared }
+// { dg-require-effective-target fpic }
+// { dg-lto-options { "-flto -fPIC -shared -O1 -fimplicit-constexpr -g1" } }
+// { dg-extra-ld-options "-shared" }
+
+namespace std {
+struct _Sp_counted_base {
+  virtual void *_M_get_deleter(const int &);
+};
+bool _S_eq(int);
+struct _Sp_make_shared_tag {
+  static const int &_S_ti() {
+static constexpr char __tag{};
+return reinterpret_cast(__tag);
+  }
+};
+struct _Impl {
+  _Impl(int);
+};
+int _Sp_counted_ptr_inplace___a;
+struct _Sp_counted_ptr_inplace : _Sp_counted_base {
+  _Sp_counted_ptr_inplace() : _M_impl(_Sp_counted_ptr_inplace___a) {}
+  void *_M_get_deleter(const int &__ti) {
+auto __ptr(_M_ptr());
+&__ti == &_Sp_make_shared_tag::_S_ti() || _S_eq(__ti);
+return __ptr;
+  }
+  int *_M_ptr();
+  _Impl _M_impl;
+};
+struct __shared_count {
+  __shared_count(int, int) { _Sp_counted_ptr_inplace(); }
+};
+int _M_ptr;
+struct __shared_ptr {
+  template 
+  __shared_ptr(_Alloc __tag) : _M_refcount(_M_ptr, __tag) {}
+  __shared_count _M_refcount;
+};
+int shared_ptr___tag;
+struct shared_ptr : __shared_ptr {
+  shared_ptr() : __shared_ptr(shared_ptr___tag) {}
+};
+void ArgEq() { shared_ptr(); }
+} // namespace std
-- 
2.35.3

Re: [Patch] OpenMP: Ignore side-effects when finding struct comps [PR108545]

[Jakub Jelinek via Gcc-patches]

On Tue, Feb 28, 2023 at 02:06:43PM +0100, Tobias Burnus wrote:
> (This is marked as P1 regression)
> 
> Since the structure handling updates, a hash is now used to find expressions 
> which are identical;
> unfortunately, this mishandles 'volatile' vars as expressions involving them 
> are not regarded
> as identical. This leads to spurious *multiple* 'map(struct:x' that later 
> causes an ICE.
> (For details, see also the PR, https://gcc.gnu.org/PR108545 )

Do we use that hashing even say for ARRAY_REFs with array indexes?
Using OEP_MATCH_SIDE_EFFECTS will mean that
volatile int idx;
a.b[idx] and a.b[idx] will compare equal.  On the other side,
if idx yielded different values on the same construct between the two,
I think it would be invalid OpenMP (trying to map the two different
array elements from the same array section), so perhaps we are ok.

> --- a/gcc/gimplify.cc
> +++ b/gcc/gimplify.cc
> @@ -8958,6 +8958,28 @@ enum omp_tsort_mark {
>PERMANENT
>  };
>  
> +/* Hash for trees based on operand_equal_p.
> +   Like tree_operand_hash but accepts side effects.  */
> +struct tree_operand_sideeff_hash : ggc_ptr_hash 

Not sure about the name, it isn't about that it accepts side effects,
but that it ignores them in the equality comparisons.
OEP_MATCH_SIDE_EFFECTS is probably misnamed too.

So perhaps struct tree_operand_hash_no_se (+ adjust the comment)?

Also, can't you derive it from tree_operand_hash?
Than you wouldn't need to provide your own hash, you could
inherit tree_operand_hash::hash and just override equal.

> +  return iterative_hash_expr (t, 0);
> +}
> +
> +inline bool
> +tree_operand_sideeff_hash::equal (const value_type &t1,
> +   const compare_type &t2)
> +{
> +  return operand_equal_p (t1, t2, OEP_MATCH_SIDE_EFFECTS);
> +}
> +
>  /* A group of OMP_CLAUSE_MAP nodes that correspond to a single "map"
> clause.  */
>  
> @@ -9432,7 +9454,6 @@ omp_index_mapping_groups_1 (hash_map  node = OMP_CLAUSE_CHAIN (node), j++)
>   {
> tree decl = OMP_CLAUSE_DECL (node);
> -
> /* Sometimes we see zero-offset MEM_REF instead of INDIRECT_REF,
>meaning node-hash lookups don't work.  This is a workaround for
>that, but ideally we should just create the INDIRECT_REF at

Why?  No change around this and I think it is nicer to have empty line
separating start of block declarations from the rest.

> @@ -9590,7 +9611,7 @@ omp_mapped_by_containing_struct 
> (hash_map  static bool
>  omp_tsort_mapping_groups_1 (omp_mapping_group ***outlist,
>   vec *groups,
> - hash_map
> + hash_map omp_mapping_group *>

This is too long, even with the shorter name.

> *grpmap,
>   omp_mapping_group *grp)
>  {
> @@ -9670,7 +9691,7 @@ omp_tsort_mapping_groups_1 (omp_mapping_group 
> ***outlist,
>  
>  static omp_mapping_group *
>  omp_tsort_mapping_groups (vec *groups,
> -   hash_map
> +   hash_map *>

This could fit after the change though.

Otherwise LGTM.

Jakub

Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

[Pan Li via Gcc-patches]

I am not very familiar with the memory pattern, maybe juzhe can provide more 
information or correct me if anything is misleading.

The different precision try to resolve the below bugs, the second vlm(with 
different size of load bytes compared to first one)
is eliminated because vbool8 and vbool16 have the same precision size, aka [8, 
8].

vbool8_t v2 = *(vbool8_t*)in;
vbool16_t v5 = *(vbool16_t*)in;
*(vbool16_t*)(out + 200) = v5;
*(vbool8_t*)(out + 100) = v2;

addia4,a1,100
vsetvli a5,zero,e8,m1,ta,ma
addia1,a1,200
vlm.v   v24,0(a0)
vsm.v   v24,0(a4)
// Need one vsetvli and vlm.v for correctness here.
vsm.v   v24,0(a1)

Pan

From: Richard Biener 
Sent: Wednesday, March 1, 2023 20:33
To: Richard Sandiford 
Cc: 盼 李 via Gcc-patches ; 盼 李 
; juzhe.zh...@rivai.ai ; 
pan2.li ; Kito.cheng 
Subject: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

On Wed, 1 Mar 2023, Richard Sandiford wrote:

> 盼 李 via Gcc-patches  writes:
> > Just have a test with the below code, the [0x4, 0x4] test comes from 
> > VNx4BI. You can notice that the mode size is unchanged.
> >
> > printf ("can_div_away_from_zero_p (mode_precision[E_%smode], "
> >   "BITS_PER_UNIT, &mode_size[E_%smode]);\n", m->name, m->name);
> >
> > VNx4BI Before precision [0x4, 0x4], size [0x4, 0]
> > VNx4BI After precision [0x4, 0x4], size [0x4, 0]
>
> Yeah, the result is expected to be unchanged if the division fails.
> That's a deliberate part of the interface.  The can_* functions
> should never be used without testing the boolean return value.
>
> But this precision of [4,4] for VNx4BI is different from what you
> listed below.  Like I say, if the precision really is [4,4], and if
> the size really is ceil([4,4]/8), then I don't think we can represent
> that with current infrastructure.

The size of VNx4BI is (4*N + 7) / 8 bytes.  I suppose we could simply
not store the size in bytes but only the size in bits then?

I see the problem, but I also don't see a good solution since
for VNx4BI with N == 3 we have one and a half byte of storage.

How do memory access patterns work with poly-int sizes?

>
> Thanks,
> Richard
>
> >
> > Pan
> > 
> > From: Richard Sandiford 
> > Sent: Wednesday, March 1, 2023 19:11
> > To: 盼 李 via Gcc-patches 
> > Cc: juzhe.zh...@rivai.ai ; pan2.li 
> > ; 盼 李 ; Kito.cheng 
> > ; rguenther 
> > Subject: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment
> >
> > 盼 李 via Gcc-patches  writes:
> >> Thank you all for your quick response.
> >>
> >> As juzhe mentioned, the memory access of RISC-V will be always aligned to 
> >> the bytes boundary with the compact mode, aka ceil(vl / 8) bytes for 
> >> vbool*.
> >
> > OK, thanks to both of you.  This is what I'd have expected.
> >
> > In that case, I think both the can_div_away_from_zero_p and the
> > original patch (using size_one) will give the wrong results.
> > There isn't a way of representing ceil([4,4]/8) as a poly_int.
> > The result is (4+4X)/8 when X is odd and (8+4X)/8 when X is even.
> >
> >> Actually, the data [4,4] comes from the self-test, the RISC-V precision 
> >> mode as below.
> >>
> >> VNx64BI precision [0x40, 0x40].
> >> VNx32BI precision [0x20, 0x20].
> >> VNx16BI precision [0x10, 0x10].
> >> VNx8BI precision [0x8, 0x8].
> >> VNx4BI precision [0x8, 0x8].
> >> VNx2BI precision [0x8, 0x8].
> >> VNx1BI precision [0x8, 0x8].
> >
> > Ah, OK.  Which self-test causes this?
> >
> > Richard
> >
> >> The impact of data [4, 4] will impact the genmode part, we cannot write 
> >> like below as the gcc_unreachable will be hitten.
> >>
> >> if (!can_div_away_from_zero_p (mode_precision[E_%smode], BITS_PER_UNIT,  
> >> &mode_size[E_%smode]))
> >>   gcc_unreachable (); // Hit on [4, 4] of the self-test.
> >>
> >> Pan
> >> 
> >> From: juzhe.zh...@rivai.ai 
> >> Sent: Wednesday, March 1, 2023 18:46
> >> To: richard.sandiford ; pan2.li 
> >> 
> >> Cc: incarnation.p.lee ; gcc-patches 
> >> ; Kito.cheng ; rguenther 
> >> 
> >> Subject: Re: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision 
> >> adjustment
> >>
>  Is it right that, for RVV, a load or store of [4,4] will access [8,8]
> bits, even when that means accessing fully-unused bytes?  E.g. 4+4X
> when X=3 would be 16 bits/2 bytes of useful data, but a bitsize of
> 8+8X would be 32 bits/4 bytes.  So a store of [8,8] for a precision
> of [4,4] would store 2 bytes beyond the end of the useful data when X==3?
> >>
> >> Hi, Richard. Thank you for helping us.
> >> My understanding of RVV ISA:
> >>
> >> In RVV, we have mask mode (VNx1BI, VNx2BI,etc), data mode 
> >> (VNx1QI,VNx4QI, VNx2DI,...etc)
> >> For data mode, we fully access the data and we don't have unused bytes, so 
> >> we don't need to adjust precision.
> >> However, for mask mode we access mask bit in compact model (since each 
> >> mask bit for corresponding element are consecutive).
> >> for example, current co

Fwd: [PATCHJ]: Bugzilla 88860 - Clarify online manual infelicities

[Jonny Grant]

Hello
I don't have write access, could someone review and apply this please?
Kind regards
Jonny



 Forwarded Message 
Subject: [PATCHJ]: Bugzilla 88860 - Clarify online manual infelicities
Date: Mon, 26 Dec 2022 21:00:05 +
From: Jonny Grant 
To: gcc-patches@gcc.gnu.org


2022-12-26  Jonathan Grant 
* gcc/doc/extend.texi: Bugzilla 88860 - Clarify online manual 
infelicities


>From 8b142ad8973dc67289e197e30966490a944e4819 Mon Sep 17 00:00:00 2001
From: Jonathan Grant 
Date: Mon, 26 Dec 2022 20:58:29 +
Subject: [PATCH] Bugzilla 88860 - Clarify gcc online manual infelicities

Signed-off-by: Jonathan Grant 
---
 gcc/doc/extend.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index adba057c190..88fc625050b 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -9190,7 +9190,7 @@ have to optimize it to just @code{return 42 + 42;}.
 This section describes the syntax with which @code{__attribute__} may be
 used, and the constructs to which attribute specifiers bind, for the C
 language.  Some details may vary for C++ and Objective-C@.  Because of
-infelicities in the grammar for attributes, some forms described here
+limitations in the grammar for attributes, some forms described here
 may not be successfully parsed in all cases.
 
 There are some problems with the semantics of attributes in C++.  For
-- 
2.37.2

Fwd: Bugzilla Bug 81649 [PATCH]: Clarify LeakSanitizer in documentation

[Jonny Grant]

Hello
I don't have write access, could someone review and apply this please?
Kind regards
Jonny




 Forwarded Message 
Subject: Bugzilla Bug 81649 [PATCH]: Clarify LeakSanitizer in documentation
Date: Mon, 26 Dec 2022 20:50:23 +
From: Jonny Grant 
To: gcc-patches@gcc.gnu.org

My ticket, but text change proposed by Jakub Jelinek.

2022-12-26  Jonathan Grant 
* gcc/doc/invoke.texi: Clarify LeakSanitizer in documentation


>From 2d70a3728536151c4c2f78b6c5d5281ce2233d43 Mon Sep 17 00:00:00 2001
From: Jonathan Grant 
Date: Mon, 26 Dec 2022 20:46:23 +
Subject: [PATCH] Bugzilla 81649 clarify LeakSanitizer onlinedocs

Signed-off-by: Jonathan Grant 
---
 gcc/doc/invoke.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index da9ad1068fb..6743204adc0 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -16668,8 +16668,8 @@ operating on invalid memory addresses with non-call 
exceptions
 @item -fsanitize=leak
 @opindex fsanitize=leak
 Enable LeakSanitizer, a memory leak detector.
-This option only matters for linking of executables and
-the executable is linked against a library that overrides @code{malloc}
+This option only matters for linking of executables.
+The executable is linked against a library that overrides @code{malloc}
 and other allocator functions.  See
 @uref{https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer} 
for more
 details.  The run-time behavior can be influenced using the
-- 
2.37.2

Fwd: [PATCH] update copyright year in libstdcc++ manual

[Jonny Grant]

Hello
I don't have write access, could someone review and apply this?
Kind regards
Jonny


 Forwarded Message 
Subject: [PATCH] update copyright year in libstdcc++ manual
Date: Fri, 30 Dec 2022 10:30:22 +
From: Jonny Grant 
To: gcc-patches@gcc.gnu.org
CC: Jonny Grant 

2022-12-30  Jonathan Grant 
* libstdc++-v3/doc/xml/faq.xml: update copyright year in libstdcc++ 
manual


>From 60789c24fa54301135dff1c3d0b1514d77b90a82 Mon Sep 17 00:00:00 2001
From: Jonathan Grant 
Date: Fri, 30 Dec 2022 10:28:34 +
Subject: [PATCH] update copyright year date

---
 libstdc++-v3/doc/xml/faq.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/doc/xml/faq.xml b/libstdc++-v3/doc/xml/faq.xml
index 9ae4966ecea..42354f87af7 100644
--- a/libstdc++-v3/doc/xml/faq.xml
+++ b/libstdc++-v3/doc/xml/faq.xml
@@ -7,7 +7,7 @@
 
   
 
-  2008-2018
+  2008-2023
 
 
   http://www.w3.org/1999/xlink"; 
xlink:href="https://www.fsf.org";>FSF
-- 
2.37.2

Re: [Patch] OpenMP/Fortran: Fix handling of optional is_device_ptr + bind(C) [PR108546]

[Jakub Jelinek via Gcc-patches]

On Tue, Feb 28, 2023 at 05:18:25PM +0100, Tobias Burnus wrote:
> OpenMP/Fortran: Fix handling of optional is_device_ptr + bind(C) [PR108546]
> 
> For is_device_ptr, optional checks should only be done before calling
> libgomp, afterwards they are NULL either because of absent or, by
> chance, because it is unallocated or unassociated (for pointers/allocatables).
> 
> Additionally, it fixes an issue with explicit mapping for 'type(c_ptr)'.
> 
>   PR middle-end/108546
> 
> gcc/fortran/ChangeLog:
> 
>   * trans-openmp.cc (gfc_trans_omp_clauses): Fix mapping of
>   type(C_ptr) variables.
> 
> gcc/ChangeLog:
> 
>   * omp-low.cc (lower_omp_target): Remove optional handling
>   on the receiver side, i.e. inside target (data), for
>   use_device_ptr.
> 
> libgomp/ChangeLog:
> 
>   * testsuite/libgomp.fortran/is_device_ptr-3.f90: New test.
>   * testsuite/libgomp.fortran/use_device_ptr-optional-4.f90: New test.

Ok, thanks.

Jakub

Unreviewed libstdc++ patch

[Rainer Orth]

The following patch

libstdc++: Update Solaris baselines for GCC 13.0
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612379.html

has remained unreviewed for a week.

Thanks.
Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

[Richard Biener via Gcc-patches]

On Wed, 1 Mar 2023, Richard Sandiford wrote:

> 盼 李 via Gcc-patches  writes:
> > Just have a test with the below code, the [0x4, 0x4] test comes from 
> > VNx4BI. You can notice that the mode size is unchanged.
> >
> > printf ("can_div_away_from_zero_p (mode_precision[E_%smode], "
> >   "BITS_PER_UNIT, &mode_size[E_%smode]);\n", m->name, m->name);
> >
> > VNx4BI Before precision [0x4, 0x4], size [0x4, 0]
> > VNx4BI After precision [0x4, 0x4], size [0x4, 0]
> 
> Yeah, the result is expected to be unchanged if the division fails.
> That's a deliberate part of the interface.  The can_* functions
> should never be used without testing the boolean return value.
> 
> But this precision of [4,4] for VNx4BI is different from what you
> listed below.  Like I say, if the precision really is [4,4], and if
> the size really is ceil([4,4]/8), then I don't think we can represent
> that with current infrastructure.

The size of VNx4BI is (4*N + 7) / 8 bytes.  I suppose we could simply
not store the size in bytes but only the size in bits then?

I see the problem, but I also don't see a good solution since
for VNx4BI with N == 3 we have one and a half byte of storage.

How do memory access patterns work with poly-int sizes?

> 
> Thanks,
> Richard
> 
> >
> > Pan
> > 
> > From: Richard Sandiford 
> > Sent: Wednesday, March 1, 2023 19:11
> > To: 盼 李 via Gcc-patches 
> > Cc: juzhe.zh...@rivai.ai ; pan2.li 
> > ; 盼 李 ; Kito.cheng 
> > ; rguenther 
> > Subject: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment
> >
> > 盼 李 via Gcc-patches  writes:
> >> Thank you all for your quick response.
> >>
> >> As juzhe mentioned, the memory access of RISC-V will be always aligned to 
> >> the bytes boundary with the compact mode, aka ceil(vl / 8) bytes for 
> >> vbool*.
> >
> > OK, thanks to both of you.  This is what I'd have expected.
> >
> > In that case, I think both the can_div_away_from_zero_p and the
> > original patch (using size_one) will give the wrong results.
> > There isn't a way of representing ceil([4,4]/8) as a poly_int.
> > The result is (4+4X)/8 when X is odd and (8+4X)/8 when X is even.
> >
> >> Actually, the data [4,4] comes from the self-test, the RISC-V precision 
> >> mode as below.
> >>
> >> VNx64BI precision [0x40, 0x40].
> >> VNx32BI precision [0x20, 0x20].
> >> VNx16BI precision [0x10, 0x10].
> >> VNx8BI precision [0x8, 0x8].
> >> VNx4BI precision [0x8, 0x8].
> >> VNx2BI precision [0x8, 0x8].
> >> VNx1BI precision [0x8, 0x8].
> >
> > Ah, OK.  Which self-test causes this?
> >
> > Richard
> >
> >> The impact of data [4, 4] will impact the genmode part, we cannot write 
> >> like below as the gcc_unreachable will be hitten.
> >>
> >> if (!can_div_away_from_zero_p (mode_precision[E_%smode], BITS_PER_UNIT,  
> >> &mode_size[E_%smode]))
> >>   gcc_unreachable (); // Hit on [4, 4] of the self-test.
> >>
> >> Pan
> >> 
> >> From: juzhe.zh...@rivai.ai 
> >> Sent: Wednesday, March 1, 2023 18:46
> >> To: richard.sandiford ; pan2.li 
> >> 
> >> Cc: incarnation.p.lee ; gcc-patches 
> >> ; Kito.cheng ; rguenther 
> >> 
> >> Subject: Re: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision 
> >> adjustment
> >>
>  Is it right that, for RVV, a load or store of [4,4] will access [8,8]
> bits, even when that means accessing fully-unused bytes?  E.g. 4+4X
> when X=3 would be 16 bits/2 bytes of useful data, but a bitsize of
> 8+8X would be 32 bits/4 bytes.  So a store of [8,8] for a precision
> of [4,4] would store 2 bytes beyond the end of the useful data when X==3?
> >>
> >> Hi, Richard. Thank you for helping us.
> >> My understanding of RVV ISA:
> >>
> >> In RVV, we have mask mode (VNx1BI, VNx2BI,etc), data mode 
> >> (VNx1QI,VNx4QI, VNx2DI,...etc)
> >> For data mode, we fully access the data and we don't have unused bytes, so 
> >> we don't need to adjust precision.
> >> However, for mask mode we access mask bit in compact model (since each 
> >> mask bit for corresponding element are consecutive).
> >> for example, current configuration: VNx1BI, VNx2BI, VNx4BI, VNx8BI, these 
> >> 4 modes have same bytesize (1,1)  but different bitsize.
> >>
> >> VNx8BI is accessed fully, but VNx4BI is only accessed 1/2, VNx2BI 1/4, 
> >> VNx1BI 1/8 but byte alignment (I am not sure whether RVV support bit 
> >> alignment, I guess it can not).
> >>
> >> If VNx8BI only occupy 1 byte (Depend on machine vector-length), so 
> >> VNx2BI,VN4BI, VNx1BI, are 2/8 byte, 4/8 byte, 1/8 bytes. I think we can't 
> >> access in bit alignment. so they will the same in the access.
> >> However, if VNx8BI occupty 8 byte, Well, VNx2BI,VN4BI, VNx1BI are 1byte, 
> >> 2bytes, 4bytes. They are accessing different size.
> >>
> >> This is my comprehension of RVV ISA, feel free to correct me.
> >> Thanks.
> >>
> >> 
> >> juzhe.zh...@rivai.ai
> >>
> >> From: Richard Sandiford
> >> Date: 2023-03-0

Patch ping: Re: [PATCH] libgcc, i386, optabs, v2: Add __float{, un}tibf to libgcc and expand BF -> integral through SF intermediate [PR107703]

[Jakub Jelinek via Gcc-patches]

Hi!

On Wed, Nov 16, 2022 at 12:51:14PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Wed, Nov 16, 2022 at 10:06:17AM +0100, Jakub Jelinek via Gcc-patches wrote:
> > Thoughts on this?  I guess my preference would be the BF -> SF -> TI
> > path because we won't need to waste
> > 32: 00015e10   321 FUNCGLOBAL DEFAULT   13 
> > __fixbfti@@GCC_13.0.0
> > 89: 00015f60   299 FUNCGLOBAL DEFAULT   13 
> > __fixunsbfti@@GCC_13.0.0
> > If so, I'd need to cut the fix parts of the patch below and
> > do something in the middle-end.
> 
> Here is adjusted patch that does that.
> 
> 2022-11-16  Jakub Jelinek  
> 
>   PR target/107703
>   * optabs.cc (expand_fix): For conversions from BFmode to integral,
>   use shifts to convert it to SFmode first and then convert SFmode
>   to integral.
> 
>   * soft-fp/floattibf.c: New file.
>   * soft-fp/floatuntibf.c: New file.
>   * config/i386/libgcc-glibc.ver: Export __float{,un}tibf @ GCC_13.0.0.
>   * config/i386/64/t-softfp (softfp_extras): Add floattibf and
>   floatuntibf.
>   (CFLAGS-floattibf.c, CFLAGS-floatunstibf.c): Add -msse2.

I'd like to ping the libgcc non-i386 part of this patch, Uros said the i386
part is ok but that one depends on the generic libgcc changes.
I'll ping the optabs.cc change separately.

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606398.html
with more info in
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606382.html

Thanks.

Jakub