Re: [PATCH] i386 testsuite: cope with --enable-default-pie

[Alexandre Oliva via Gcc-patches]

On Jul 11, 2022, Mike Stump  wrote:

> On Jul 11, 2022, at 6:47 PM, Alexandre Oliva  wrote:
>> 
>> Running the testsuite on a toolchain build with --enable-default-pie
>> had some unexpected fails.

>> Regstrapped on x86_64-linux-gnu, and also tested on i686-linux-gnu, with
>> and without --enable-default-pie on both platforms.  Ok to install?

> Ok.

Here's some more:


i386 PIE: testsuite: cope with default pie on ia32

This patch continues the effort of cleaning up the testsuite for
--enable-default-pie; the focus herein is mostly 32-bit x86.

As much as I tried to avoid it, most of the changes to the testsuite
simply disable PIC/PIE, for reasons I'm going to detail below.

static-cdtor1.C gets new patterns to match PIE output.  Some
avx512fp16 tests change only in register allocation, because of the
register used to hold the GOT base address.  Interrupt tests changed
in this regard as well, but here it also affected register saving and
restoring.

The previous patch modified cet-sjlj tests, mentioning a single regexp
covering PIC and nonPIC got incorrect match counts.  I found out that
adding ?: to parenthesized subpatterns avoids miscounting matches.
Other tests that count certain kinds of insns needed adjustment over
insns in get_pc_thunk, extra loads from the GOT, or extra adds to
compute addresses.  In one case, namely stack-check-12, it is nonPIC
that had extra insns, that PIC gets rid of, or rather, pushing and
popping the PIC register obviates the dummy push and matching pop used
for stack probing in nonpic.

pr95126 tests were supposed to optimize loads into known constants,
but the @GOTOFF addresses prevent that for reasons I have not
investigated, but that would be clearly desirable, so I've XFAILed
these.  pr95852 is another case of missed optimization: sibcalls are
not possible when the PIC register needs to be set up for the call,
which prevents the expected constant propagation to the return block;
I have adjusted the codegen expectations of these tests.

As for tests that disable PIE...  Some are judgment calls, that fail
for similar reasons as tests described above, but I chose not to
adjust their expectations; others are just not possible with PIC, or
not worth the effort of adjusting.

anon[14].C check for no global or comdat symbols, respectively, but
-fPIE outputs get_pc_thunk, as global hidden comdat.
initlist-const1.C wants .rodata and checks for no .data, but PIC
outputs constant data that needs relocations in .data.rel.ro.local.
no-stack-protector-attr-3.C and stackprotectexplicit2.C count
stack_check_fail matches; -fPIE calls stack_check_fail_local instead,
which matches the pattern, but this symbol is also marked as .hidden,
so the match count needs to be adjusted.

pr71694.C checks for no movl, but get_pc_thunk contains one.
pr102892-1.c is a missed optimization, ivopts creates an induction
variable because the array address can't be part of an indexing base
address with PIE, and that ends up stopping a load from being resolved
to a constant as expected.  sibcall-11.c needs @PLT for the call,
which requires the PIC register, which makes sibcalling impossible.
builtin-self.c, in turn, expects no calls, but PIC calls get_pc_thunk.

avx* vector tests that had PIE disabled were affected in that the need
for GOT-based addressing modes changed instruction selection in ways
that deviated from the expectations of the tests.  Ditto other vector
tests: pr100865*, pr101796-1, pr101846, pr101989-broadcast-1, and
pr102021, pr54855-[37], and pr90773-17.

pr15184* tests need a PIC register to access global variables, which
affects register allocation, so the patterns would have to be
adjusted.  pr27971 can't use the expected addressing mode to
dereference the array with PIC, so it ends up selecting an indexed
addressing mode, obviating the expected separate shift insn.

pr70263-2 is another case that implicitly expects a sibcall,
impossible because of the need for the PIC register; without a
sibcall, the expected REG_EQUIV for the reuse of the stack slot of an
incoming argument does not occur.  pr78035 duplicates the final
compare in both then and else blocks with PIE, which deviates from the
expected cmp count.  pr81736-[57] test for no frame pointer, but the
PIC register assignment to a call-saved register forces a frame; the
former ends up not using the PIC register, but it's only optimized out
after committing to a stack frame to preserve it.  pr85620-6 also
expects a tail call in a situation that is impossible on ia32 PIC.

pr85667-6 doesn't expect the movl in get_pc_thunk.  pr93492-5 tests
-mfentry, not available with PIC on ia32.  pr96539 expects a
tail-call, to avoid copying a large-ish struct argument, but the call
requires the PIC register, so no tail-call.  stack-prot-sym.c expects
a nonpic addressing mode.

Regstrapped on x86_64-linux-gnu; also tested, along with other patches
I'm posting today with "i386 PIE" in the subject, and compared
default-PIE and default-nonPIE results 

[PATCH] [PR83782] i386 PIE: avoid @GOTOFF for ifuncs and their aliases

[Alexandre Oliva via Gcc-patches]

g++.dg/ext/attr-ifunc-3.C and gcc.target/i386/mvc10.c, not changed,
have made it clear that there were problems in the optimizations to
use @GOTOFF to refer to locally-bound ifuncs.  GNU ld as recently as
May 2018 would reject such constructs, whereas later versions will
silently accept but generate incorrect PIE with them (attr-ifunc-3.C)
or still reject them if referenced through aliases (mvc10.c).  The use
of @GOTOFF for locally-bound but externally-visible symbols
(e.g. protected visibility) also breaks pointer identity if the
canonical address ends up preempted by a PLT entry.  This patch
modifies the local_symbolic_operand predicate to disable @GOTOFF for
locally-bound symbols that would require @PLT for calls, restoring
earlier behavior and disabling the optimization that has proven
problematic even on amd64.  Eventually we may reintroduce the
optimization, when the linker is fixed and we test for the fix before
enabling it, and we exclude symbols whose canonical addresses may be
preempted even when the symbol definition can't.  pr83782 tests have
been adjusted to expect @GOT instead of @GOTOFF.

Regstrapped on x86_64-linux-gnu; also tested, along with other patches
I'm posting today with "i386 PIE" in the subject, and compared
default-PIE and default-nonPIE results on it, and on i686-linux-gnu.  Ok
to install?


for  gcc/ChangeLog

PR target/83782
* config/i386/predicates.md (local_symbolic_operand): Disable
GOTOFF even for locally-bound ifuncs.
* config/i386/i386.cc (ix86_call_use_plt_p): Follow the alias
chain looking for an ifunc, as in gcc.target/i386/mvc10.c.

for  gcc/testsuite/ChangeLog

PR target/83782
* gcc.target/i386/pr83782-1.c: Adjust to require GOT rather
than GOTOFF on ia32.
* gcc.target/i386/pr83782-2.c: Likewise.
---
 gcc/config/i386/i386.cc   |   16 ++--
 gcc/config/i386/predicates.md |4 +++-
 gcc/testsuite/gcc.target/i386/pr83782-1.c |4 ++--
 gcc/testsuite/gcc.target/i386/pr83782-2.c |4 ++--
 4 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index aab28da4b5d4b..5c5dc8d2373ff 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -16058,13 +16058,17 @@ ix86_call_use_plt_p (rtx call_op)
 {
   if (SYMBOL_REF_DECL (call_op)
  && TREE_CODE (SYMBOL_REF_DECL (call_op)) == FUNCTION_DECL)
-   {
- /* NB: All ifunc functions must be called via PLT.  */
- cgraph_node *node
-   = cgraph_node::get (SYMBOL_REF_DECL (call_op));
- if (node && node->ifunc_resolver)
+   /* NB: All ifunc functions must be called via PLT, and we have
+  to explicitly iterate over an alias chain looking for a
+  node marked as an ifunc(_resolver) to tell.  That node is
+  itself aliased to the actual resolver function, so
+  ultimate_alias_target would skip the marker, and the call
+  may be to another declaration aliased to the ifunc.  */
+   for (cgraph_node *node
+  = cgraph_node::get (SYMBOL_REF_DECL (call_op));
+node && node->alias; node = node->get_alias_target ())
+ if (node->ifunc_resolver)
return true;
-   }
   return false;
 }
   return true;
diff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md
index 42053ea7209f6..411c06e22e600 100644
--- a/gcc/config/i386/predicates.md
+++ b/gcc/config/i386/predicates.md
@@ -596,7 +596,9 @@ (define_predicate "local_symbolic_operand"
   if (TARGET_DLLIMPORT_DECL_ATTRIBUTES && SYMBOL_REF_DLLIMPORT_P (op))
 return false;
   if (SYMBOL_REF_LOCAL_P (op))
-return true;
+/* ifuncname@GOTOFF was rejected by the x86 linker before May
+   2018, and silently generated wrong code for PIE afterwards.  */
+return !ix86_call_use_plt_p (op);
 
   /* There is, however, a not insubstantial body of code in the rest of
  the compiler that assumes it can just stick the results of
diff --git a/gcc/testsuite/gcc.target/i386/pr83782-1.c 
b/gcc/testsuite/gcc.target/i386/pr83782-1.c
index ce97b12e65d58..af52278ec4df2 100644
--- a/gcc/testsuite/gcc.target/i386/pr83782-1.c
+++ b/gcc/testsuite/gcc.target/i386/pr83782-1.c
@@ -20,7 +20,7 @@ bar(void)
   return foo;
 }
 
-/* { dg-final { scan-assembler {leal[ \t]foo@GOTOFF\(%[^,]*\),[ \t]%eax} { 
target ia32 } } } */
+/* { dg-final { scan-assembler-not {leal[ \t]foo@GOTOFF\(%[^,]*\),[ \t]%eax} { 
target ia32 } } } */
 /* { dg-final { scan-assembler {lea(?:l|q)[ \t]foo\(%rip\),[ \t]%(?:e|r)ax} { 
target { ! ia32 } } } } */
-/* { dg-final { scan-assembler-not "foo@GOT\\\(" { target ia32 } } } */
+/* { dg-final { scan-assembler "foo@GOT\\\(" { target ia32 } } } */
 /* { dg-final { scan-assembler-not "foo@GOTPCREL\\\(" { target { ! ia32 } } } 
} */
diff --git a/gcc/testsuite/gcc.target/i386/pr83782-2.c 
b/gcc/testsuite/gcc.target/i386/pr83782-2.c
index 

[PATCH] i386 PIE: accept @GOTOFF in load/store multi base address

[Alexandre Oliva via Gcc-patches]

Looking at the code generated for sse2-{load,store}-multi.c with PIE,
I realized we could use UNSPEC_GOTOFF as a base address, and that this
would enable the test to use the vector insns expected by the tests
even with PIC, so I extended the base + offset logic used by the SSE2
multi-load/store peepholes to accept reg + symbolic base + offset too,
so that the test generated the expected insns even with PIE.

Regstrapped on x86_64-linux-gnu; also tested, along with other patches
I'm posting today with "i386 PIE" in the subject, and compared
default-PIE and default-nonPIE results on it, and on i686-linux-gnu.  Ok
to install?


for  gcc/ChangeLog

* config/i386/i386.cc (symbolic_base_address_p,
base_address_p): New, factored out from...
(extract_base_offset_in_addr): ... here and extended to
recognize REG+GOTOFF, as in gcc.target/i386/sse2-load-multi.c
and sse2-store-multi.c with PIE enabled by default.
---
 gcc/config/i386/i386.cc |   89 ---
 1 file changed, 75 insertions(+), 14 deletions(-)

diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index e03f86d4a2386..aab28da4b5d4b 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -23910,11 +23910,40 @@ ix86_reloc_rw_mask (void)
 }
 #endif
 
-/* If MEM is in the form of [base+offset], extract the two parts
-   of address and set to BASE and OFFSET, otherwise return false.  */
+/* Return true iff ADDR can be used as a symbolic base address.  */
 
 static bool
-extract_base_offset_in_addr (rtx mem, rtx *base, rtx *offset)
+symbolic_base_address_p (rtx addr)
+{
+  if (GET_CODE (addr) == SYMBOL_REF)
+return true;
+
+  if (GET_CODE (addr) == UNSPEC && XINT (addr, 1) == UNSPEC_GOTOFF)
+return true;
+
+  return false;
+}
+
+/* Return true iff ADDR can be used as a base address.  */
+
+static bool
+base_address_p (rtx addr)
+{
+  if (REG_P (addr))
+return true;
+
+  if (symbolic_base_address_p (addr))
+return true;
+
+  return false;
+}
+
+/* If MEM is in the form of [(base+symbase)+offset], extract the three
+   parts of address and set to BASE, SYMBASE and OFFSET, otherwise
+   return false.  */
+
+static bool
+extract_base_offset_in_addr (rtx mem, rtx *base, rtx *symbase, rtx *offset)
 {
   rtx addr;
 
@@ -23925,21 +23954,52 @@ extract_base_offset_in_addr (rtx mem, rtx *base, rtx 
*offset)
   if (GET_CODE (addr) == CONST)
 addr = XEXP (addr, 0);
 
-  if (REG_P (addr) || GET_CODE (addr) == SYMBOL_REF)
+  if (base_address_p (addr))
 {
   *base = addr;
+  *symbase = const0_rtx;
   *offset = const0_rtx;
   return true;
 }
 
   if (GET_CODE (addr) == PLUS
-  && (REG_P (XEXP (addr, 0))
- || GET_CODE (XEXP (addr, 0)) == SYMBOL_REF)
-  && CONST_INT_P (XEXP (addr, 1)))
+  && base_address_p (XEXP (addr, 0)))
 {
-  *base = XEXP (addr, 0);
-  *offset = XEXP (addr, 1);
-  return true;
+  rtx addend = XEXP (addr, 1);
+
+  if (GET_CODE (addend) == CONST)
+   addend = XEXP (addend, 0);
+
+  if (CONST_INT_P (addend))
+   {
+ *base = XEXP (addr, 0);
+ *symbase = const0_rtx;
+ *offset = addend;
+ return true;
+   }
+
+  /* Also accept REG + symbolic ref, with or without a CONST_INT
+offset.  */
+  if (REG_P (XEXP (addr, 0)))
+   {
+ if (symbolic_base_address_p (addend))
+   {
+ *base = XEXP (addr, 0);
+ *symbase = addend;
+ *offset = const0_rtx;
+ return true;
+   }
+
+ if (GET_CODE (addend) == PLUS
+ && symbolic_base_address_p (XEXP (addend, 0))
+ && CONST_INT_P (XEXP (addend, 1)))
+   {
+ *base = XEXP (addr, 0);
+ *symbase = XEXP (addend, 0);
+ *offset = XEXP (addend, 1);
+ return true;
+   }
+   }
 }
 
   return false;
@@ -23954,7 +24014,8 @@ ix86_operands_ok_for_move_multiple (rtx *operands, bool 
load,
machine_mode mode)
 {
   HOST_WIDE_INT offval_1, offval_2, msize;
-  rtx mem_1, mem_2, reg_1, reg_2, base_1, base_2, offset_1, offset_2;
+  rtx mem_1, mem_2, reg_1, reg_2, base_1, base_2,
+symbase_1, symbase_2, offset_1, offset_2;
 
   if (load)
 {
@@ -23977,13 +24038,13 @@ ix86_operands_ok_for_move_multiple (rtx *operands, 
bool load,
 return false;
 
   /* Check if the addresses are in the form of [base+offset].  */
-  if (!extract_base_offset_in_addr (mem_1, _1, _1))
+  if (!extract_base_offset_in_addr (mem_1, _1, _1, _1))
 return false;
-  if (!extract_base_offset_in_addr (mem_2, _2, _2))
+  if (!extract_base_offset_in_addr (mem_2, _2, _2, _2))
 return false;
 
   /* Check if the bases are the same.  */
-  if (!rtx_equal_p (base_1, base_2))
+  if (!rtx_equal_p (base_1, base_2) || !rtx_equal_p (symbase_1, symbase_2))
 return false;
 
   offval_1 = INTVAL (offset_1);


-- 

[PATCH 0/1] middle-end: Fix bit position comparison

[juzhe . zhong]

From: zhongjuzhe 

Hi, variable "bitpos" is compute using bitsize. I think it makes
sense for bit position checking whether it is out-of-bounds to
array using GET_MODE_BITSIZE instead of GET_MODE_PRECISION.

This patch is useful for RVV (RISC-V 'V') support that I am
going to push upstream. Thanks!

*** BLURB HERE ***

zhongjuzhe (1):
  Fix bit-position comparison

 gcc/expr.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.36.1

[PATCH 1/1] Fix bit-position comparison

[juzhe . zhong]

From: zhongjuzhe 

gcc/ChangeLog:

* expr.cc (expand_assignment): Change GET_MODE_PRECISION to 
GET_MODE_BITSIZE

---
 gcc/expr.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/expr.cc b/gcc/expr.cc
index 80bb1b8a4c5..ac2b3c07df6 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -5574,7 +5574,7 @@ expand_assignment (tree to, tree from, bool nontemporal)
 code contains an out-of-bounds access to a small array.  */
   if (!MEM_P (to_rtx)
  && GET_MODE (to_rtx) != BLKmode
- && known_ge (bitpos, GET_MODE_PRECISION (GET_MODE (to_rtx
+ && known_ge (bitpos, GET_MODE_BITSIZE (GET_MODE (to_rtx
{
  expand_normal (from);
  result = NULL;
-- 
2.36.1

Re: [PATCH] LoongArch: adjust the default of -mexplicit-relocs by checking gas feature

[Xi Ruoyao via Gcc-patches]

On Wed, 2022-07-27 at 09:34 +0800, Lulu Cheng wrote:

> > -- >8 --
> > 
> > The assembly produced with -mexplicit-relocs is not supported by gas
> > <=
> > 2.39.  Check if the assembler supports explicit relocations and set
> > the
> > default accordingly.
> Looks good to me.

Pushed r13-1851.

Re: [PATCH] LoongArch: adjust the default of -mexplicit-relocs by checking gas feature

[Lulu Cheng]

在 2022/7/26 下午10:15, Xi Ruoyao 写道:


The following should work.  I've tested it locally by building GCC with
both old (2.38 with patch) and new (trunk) Binutils. Ok for trunk?

I simply checked as instead of ld.  If as supports explicitly
relocations, the produced .o file won't be supported by an old ld even
if we use -mno-explicit-relocs (because as will generate new relocation
types for la.local etc).  So such a mismatch between as and ld can be
considered "completely broken" and we don't need to support it.  And,
the Alpha port also check the assembler for the default of -mexplicit-
relocs.

This should be documented in invoke.texi, but currently it does not
mention -mexplicit-relocs for LoongArch at all.  So I'll submit the
doclater in another patch.

-- >8 --

The assembly produced with -mexplicit-relocs is not supported by gas <=
2.39.  Check if the assembler supports explicit relocations and set the
default accordingly.

Looks good to me.

Re: libstdc++: Minor codegen improvement for atomic wait spinloop

[Thomas Rodgers via Gcc-patches]

This is now committed to trunk, backported to releases/gcc-12 and
releases/gcc-11.

Apologies for the delay, it's been a wild couple of weeks.

Tom.

On Thu, Jul 7, 2022 at 2:31 AM Jonathan Wakely  wrote:

> On Wed, 6 Jul 2022 at 22:42, Thomas Rodgers  wrote:
> >
> > Ok for trunk? backport?
>
> Yes, for all branches that have the atomic wait code.
>
>
> >
> > On Wed, Jul 6, 2022 at 1:56 PM Jonathan Wakely 
> wrote:
> >>
> >> On Wed, 6 Jul 2022 at 02:05, Thomas Rodgers via Libstdc++
> >>  wrote:
> >> >
> >> > This patch merges the spin loops in the atomic wait implementation
> which is
> >> > a
> >> > minor codegen improvement.
> >> >
> >> > libstdc++-v3/ChangeLog:
> >> >  * include/bits/atomic_wait.h (__atomic_spin): Merge spin
> loops.
> >>
> >> OK, thanks.
> >>
>
>

Re: [PATCH] Add new target hook: simplify_modecc_const.

[Segher Boessenkool]

Hi!

On Tue, Jul 26, 2022 at 10:04:45PM +0100, Roger Sayle wrote:
> It's very important to distinguish the invariants that exist for the RTL
> data structures as held in memory (rtx),

"In memory"?  What does that mean here?  RTX are just RTL expressions,
nothing more, nothing less.

> vs. the use of "enum rtx_code"s,
> "machine_mode"s and operands in the various processing functions
> of the middle-end.

Of course.

> Yes, it's very true that RTL integer constants don't specify a mode
> (are VOIDmode), so therefore operations like ZERO_EXTEND or EQ
> don't make sense with all constant operands.

ZERO_EXTEND makes sense for all non-negative operands and no negative
operands.  Anything with some integer mode (so not VOIDmode!) can be
the first argument to EQ, at least structurally.

> This is (one reason)
> why constant-only operands are disallowed from RTL (data structures),
> and why in APIs that perform/simplify these operations, the original
> operand mode (of the const_int(s)) must be/is always passed as a
> parameter.
> 
> Hence, for say simplify_const_binary_operation, op0 and op1 can
> both be const_int, as the mode argument specifies the mode of the
> "code" operation. Likewise, in simplify_relational_operation, both
> op0 and op1 may be CONST_INT as "cmp_mode" explicitly specifies
> the mode that the operation is performed in and "mode" specifies
> the mode of the result.

> Your comment that "comparing two integer constants is invalid
> RTL *in all contexts*" is a serious misunderstanding of what's
> going on.

Not at all.  I showed the quote from the documentation: it is always
invalid to have two VOIDmode arguments to COMPARE.

> At no point is a RTL rtx node ever allocated with two
> integer constant operands.  RTL simplification is for hypothetical
> "what if" transformations (just like try_combine calls recog with
> RTL that may not be real instructions), and these simplifcations
> are even sometimes required to preserve the documented RTL
> invariants.  Comparisons of two integers must be simplified to
> true/false precisely to ensure that they never appear in an actual
> COMPARE node.

As the function documentation clearly states, two VOIDmode args (and
MODE that as well) is a special case for infinite precision arithmetic.

> I worry this fundamental misunderstanding is the same issue that
> has been holding up understanding/approving a previous patch:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578848.html

https://patchwork.ozlabs.org/project/gcc/patch/001401d7a2a5$5bf07db0$13d17910$@nextmovesoftware.com/

Let's not discuss this in this thread though.

> For a related bug, consider PR rtl-optimization/67382, that's assigned
> to you in bugzilla.  In this case, the RTL optimizers know that both
> operands to a COMPARE are integer constants (both -2), yet the
> compiler still performs a run-time comparison and conditional jump:
> 
> movl$-2, %eax
> movl%eax, 12(%rsp)
> cmpl$-2, %eax
> je  .L1
> 
> Failing to optimize/consider a comparison between two integer
> constants *in any context* just leads to poor code.

If combine would ever generate invalid RTL, the resulting insn does not
pass recog(), making the combine attempt fail.  This is not the way.

The simplifier (part of combine) has a function to actually simplify
tautologies and contradictions, the simplify_const_relational_operation
function you edited here.

> Hopefully, this clears up that the documented constraints on RTL rtx
> aren't exactly the same as the constraints on the use of rtx_codes in
> simplify-rtx's functional APIs.  So simplify_subreg really gets called
> on operands that are neither REG nor MEM, as this is unrelated to
> what the documentation of the SUBREG rtx specifies.

Thank you for telling the maintainer of combine the basics of what all
of this does!  I hadn't noticed any of that before.

> If you don't believe that op0 and op1 can ever both be const_int
> in this function, perhaps consider it harmless dead code and humor
> me.

They can be, as clearly documented (and obvious from the code), but you
can not ever have that in the RTL stream, which is needed for your patch
to do anything.

I consider it harmful, and not dead.  Sorry.


Do you have comments on the rest?


Segher

Re: [PATCH] btf: do not use the CHAR `encoding' bit for BTF

[Indu Bhagat via Gcc-patches]

On 7/22/22 4:23 AM, Jose E. Marchesi via Gcc-patches wrote:


Contrary to CTF and our previous expectations, as per [1], turns out
that in BTF:

1) The `encoding' field in integer types shall not be treated as a
bitmap, but as an enumerated, i.e. these bits are exclusive to each
other.

2) The CHAR bit in `encoding' shall _not_ be set when emitting types
for char nor `unsigned char'.



Hmm...well.  At this time, I suggest we make a note of this in the btf.h 
for posterity that BTF_INT_CHAR is to not be used (i.e., BTF_INT_CHAR 
should not be set for char / unsigned char).



Consequently this patch clears the CHAR bit before emitting the
variable part of BTF integral types.  It also updates the testsuite
accordingly, expanding it to check for BOOL bits.

[1] https://lore.kernel.org/bpf/a73586ad-f2dc-0401-1eba-2004357b7...@fb.com/T/#t

gcc/ChangeLog:

* btfout.cc (output_asm_btf_vlen_bytes): Do not use the CHAR
encoding bit in BTF.

gcc/testsuite/ChangeLog:

* gcc.dg/debug/btf/btf-int-1.c: Do not check for char bits in
bti_encoding and check for bool bits.
---
  gcc/btfout.cc  |  4 
  gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c | 18 +++---
  2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index 31af50521da..576f73d47cf 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -914,6 +914,10 @@ output_asm_btf_vlen_bytes (ctf_container_ref ctfc, 
ctf_dtdef_ref dtd)
if (dtd->dtd_data.ctti_size < 1)
break;
  
+  /* In BTF the CHAR `encoding' seems to not be used, so clear it

+ here.  */
+  dtd->dtd_u.dtu_enc.cte_format &= ~BTF_INT_CHAR;
+


[Added David Faust]

What do you think about doing this in btf_dtd_emit_preprocess_cb () for 
types where kind == BTF_KIND_INT. This is the place where BTF specific 
massaging of type info takes place.



encoding = BTF_INT_DATA (dtd->dtd_u.dtu_enc.cte_format,
   dtd->dtd_u.dtu_enc.cte_offset,
   dtd->dtd_u.dtu_enc.cte_bits);
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c 
b/gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c
index 2381decd6ff..87d9758e9cb 100644
--- a/gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c
@@ -4,7 +4,8 @@
 | 0 | encoding | offset | 00 | bits |
 encoding:
   signed  1 << 24
- char2 << 24
+ char2 << 24  (not used)
+ bool4 << 24
  
 All offsets in this test should be 0.

 This test does _not_ check number of bits, as it may vary between targets.
@@ -13,13 +14,14 @@
  /* { dg-do compile } */
  /* { dg-options "-O0 -gbtf -dA" } */
  
-/* Check for 8 BTF_KIND_INT types.  */

-/* { dg-final { scan-assembler-times "\[\t \]0x100\[\t 
\]+\[^\n\]*btt_info" 8 } } */
+/* Check for 9 BTF_KIND_INT types.  */
+/* { dg-final { scan-assembler-times "\[\t \]0x100\[\t 
\]+\[^\n\]*btt_info" 9 } } */
  
-/* Check the signed/char flags, but not bit size. */

-/* { dg-final { scan-assembler-times "\[\t \]0x1..\[\t 
\]+\[^\n\]*bti_encoding" 3 } } */
-/* { dg-final { scan-assembler-times "\[\t \]0x2..\[\t 
\]+\[^\n\]*bti_encoding" 1 } } */
-/* { dg-final { scan-assembler-times "\[\t \]0x3..\[\t 
\]+\[^\n\]*bti_encoding" 1 } } */
+/* Check the signed flags, but not bit size. */
+/* { dg-final { scan-assembler-times "\[\t \]0x1..\[\t 
\]+\[^\n\]*bti_encoding" 4 } } */
+/* { dg-final { scan-assembler-times "\[\t \]0x..\[\t \]+\[^\n\]*bti_encoding" 
3 } } */
+/* { dg-final { scan-assembler-times "\[\t \]0x.\[\t \]+\[^\n\]*bti_encoding" 
1 } } */
+/* { dg-final { scan-assembler-times "\[\t \]0x4..\[\t 
\]+\[^\n\]*bti_encoding" 1 } } */
  
  /* Check that there is a string entry for each type name.  */

  /* { dg-final { scan-assembler-times "ascii \"unsigned char.0\"\[\t 
\]+\[^\n\]*btf_string" 1 } } */
@@ -42,3 +44,5 @@ signed int f = -66;
  
  unsigned long int g = 77;

  signed long int h = 88;
+
+_Bool x = 1;

[GCC 12, committed] d: Merge upstream dmd 76e3b41375, druntime 1462ebd1, phobos 5fef0d28f.

[Iain Buclaw via Gcc-patches]

Hi,

This patch merges the D front-end with upstream dmd 76e3b41375, and
standard run-time libraries with druntime 1462ebd1, and phobos
5fef0d28f, updating the D language version to v2.100.1.

D front-end changes:

- Fix delegate literal with inferred return value that requires
  following alias-this to not use class cast.
- Fix internal error on variadic template type instantiated with two
  arrays of classes.
- `scope(failure)' blocks that contain `return' statements are now
  deprecated.
- Fix regression where wrong cast was inserted for ternary operator
  and non-int enums.
- Fix internal error in code generation trying to reference
  _d_arraysetctor.
- Fix memory corruption when array literal is passed to map in
  lambda, then returned from nested function.
- Generate invariant id on the basis of location rather than a
  global counter.
- Make `noreturn' conversions work.
- Fix segfault when `.stringof' of template alias overloaded with
  function accessed by trait.
- Empty array literal passed to scope param not 'falsey' anymore.

Phobos changes:

- Avoid copying ranges in std.algorithm.comparison.equal.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, and
committed to the releases/gcc-12 branch.

Regards,
Iain.

---
gcc/d/ChangeLog:

* dmd/MERGE: Merge upstream dmd 76e3b41375.
* dmd/VERSION: Bump version to v2.100.1.
* decl.cc (DeclVisitor::visit (VarDeclaration *)): Evaluate RHS
  of noreturn declaration expressions first.
* expr.cc (ExprVisitor::visit (AssignExp *)): Don't generate
  assignment for noreturn types.

libphobos/ChangeLog:

* libdruntime/MERGE: Merge upstream druntime 1462ebd1.
* src/MERGE: Merge upstream phobos 5fef0d28f.
---
 gcc/d/decl.cc |  7 ++-
 gcc/d/dmd/MERGE   |  2 +-
 gcc/d/dmd/VERSION |  2 +-
 gcc/d/dmd/dcast.d | 14 -
 gcc/d/dmd/dsymbolsem.d|  3 +
 gcc/d/dmd/expressionsem.d | 13 +++--
 gcc/d/dmd/func.d  | 14 -
 gcc/d/dmd/impcnvtab.d | 55 +++
 gcc/d/dmd/mtype.d |  5 ++
 gcc/d/dmd/statementsem.d  | 16 +-
 gcc/d/expr.cc | 11 
 .../gdc.test/compilable/backendfloatoptim.d   | 10 
 gcc/testsuite/gdc.test/compilable/noreturn1.d | 28 ++
 gcc/testsuite/gdc.test/compilable/test23082.d | 17 ++
 gcc/testsuite/gdc.test/compilable/test23166.d | 22 
 gcc/testsuite/gdc.test/compilable/test23172.d | 33 +++
 gcc/testsuite/gdc.test/compilable/test23258.d | 21 +++
 .../gdc.test/fail_compilation/fail23181.d | 16 ++
 .../gdc.test/fail_compilation/fail6889.d  |  2 +-
 .../gdc.test/fail_compilation/fail7848.d  |  8 +--
 .../gdc.test/fail_compilation/test21443.d | 21 +++
 .../gdc.test/fail_compilation/test23170.d | 12 
 gcc/testsuite/gdc.test/runnable/noreturn1.d   | 32 +++
 gcc/testsuite/gdc.test/runnable/test20734.d   |  7 +++
 gcc/testsuite/gdc.test/runnable/test23181.d   | 27 +
 gcc/testsuite/gdc.test/runnable/test23234.d   | 22 
 gcc/testsuite/gdc.test/runnable/warning1.d|  9 ---
 libphobos/libdruntime/MERGE   |  2 +-
 libphobos/src/MERGE   |  2 +-
 libphobos/src/std/algorithm/comparison.d  |  2 +-
 libphobos/src/std/typecons.d  | 10 +++-
 31 files changed, 408 insertions(+), 37 deletions(-)
 create mode 100644 gcc/testsuite/gdc.test/compilable/backendfloatoptim.d
 create mode 100644 gcc/testsuite/gdc.test/compilable/test23082.d
 create mode 100644 gcc/testsuite/gdc.test/compilable/test23166.d
 create mode 100644 gcc/testsuite/gdc.test/compilable/test23172.d
 create mode 100644 gcc/testsuite/gdc.test/compilable/test23258.d
 create mode 100644 gcc/testsuite/gdc.test/fail_compilation/fail23181.d
 create mode 100644 gcc/testsuite/gdc.test/fail_compilation/test21443.d
 create mode 100644 gcc/testsuite/gdc.test/fail_compilation/test23170.d
 create mode 100644 gcc/testsuite/gdc.test/runnable/test23181.d
 create mode 100644 gcc/testsuite/gdc.test/runnable/test23234.d

diff --git a/gcc/d/decl.cc b/gcc/d/decl.cc
index f5c21078aad..43c3d87cdd1 100644
--- a/gcc/d/decl.cc
+++ b/gcc/d/decl.cc
@@ -645,9 +645,12 @@ public:
if (!d->isDataseg () && !d->isMember ()
&& d->_init && !d->_init->isVoidInitializer ())
  {
+   /* Evaluate RHS for side effects first.  */
+   Expression *ie = initializerToExpression (d->_init);
+   add_stmt (build_expr (ie));
+
Expression *e = d->type->defaultInitLiteral (d->loc);
-   tree exp = build_expr (e);
-   add_stmt (exp);
+   add_stmt (build_expr (e));
  }

Re: [PATCH 1/2] RISC-V: Support _Float16 type.

[Joseph Myers]

On Thu, 7 Jul 2022, Kito Cheng wrote:

> +/* Implement TARGET_MANGLE_TYPE.  */
> +
> +static const char *
> +riscv_mangle_type (const_tree type)
> +{
> +  /* Half-precision float.  */
> +  if (TREE_CODE (type) == REAL_TYPE && TYPE_PRECISION (type) == 16)
> +return "Dh";

Are you sure you wish to use "Dh" instead of "DF16_" used on x86?  The C++ 
ABI lists both

 ::= Dh # IEEE 754r half-precision floating point (16 bits)
 ::= DF  _ # ISO/IEC TS 18661 binary floating point 
type _FloatN (N bits)

without distinguishing which should be used when - maybe the choice made 
for _Float16 on RISC-V needs documenting in the RISC-V psABI?

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH V1] HIGH part of symbol ref is invalid for constant pool

[Segher Boessenkool]

Hi!

On Tue, Jul 19, 2022 at 10:30:54PM +0800, Jiufu Guo wrote:
> In patch https://gcc.gnu.org/pipermail/gcc-patches/2022-July/597712.html,
> test case was not added.  After more check, a testcase is added for it.
> 
> The high part of the symbol address is invalid for the constant pool.

Invalid, how so?  Is there a PR related here?

But it is not particularly useful ever, either: we do not know two
different addresses will have the same HIGH unless we know the exact
address, and then we don't need HIGH anyway.

>   * config/rs6000/rs6000.cc (rs6000_cannot_force_const_mem):
>   Return true for HIGH code rtx.

* config/rs6000/rs6000.cc (rs6000_cannot_force_const_mem): Return true
for HIGH code rtx.

Please don't wrap lines early: changelog lines are 80 positions long,
including the leading tab (which counts as eight positions).

>  static bool
>  rs6000_cannot_force_const_mem (machine_mode mode ATTRIBUTE_UNUSED, rtx x)
>  {
> -  if (GET_CODE (x) == HIGH
> -  && GET_CODE (XEXP (x, 0)) == UNSPEC)
> +  /* High part of a symbol ref/address can not be put into constant pool. 
> e.g.
> + (high:DI (symbol_ref:DI ("var")..)) or
> + (high:DI (unspec:DI [(symbol_ref/u:DI ("*.LC0")..)
> + (high:DI (const:DI (plus:DI (symbol_ref:DI ("xx")) (const_int 12.  
> */
> +  if (GET_CODE (x) == HIGH)
>  return true;

I'm not sure the new comment is helpful at all?  Are these examples of
where the compiler (or assembler perhaps) will choke?

> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/constpoolcheck.c
> @@ -0,0 +1,11 @@
> +/* { dg-do compile { target powerpc*-*-* } } */

Everything in gcc.target/powerpc is target powerpc* always.

> +/* { dg-options "-O1 -mdejagnu-cpu=power10" } */
> +/* (high:DI (symbol_ref:DI ("var_48")..))) should not cause ICE. */

Ah, so there is an ICE, I see.  Please open a PR, and mention that in
the testcase as well as in the commit message and changelog.

I agree with what the patch does, it just needs a little more work :-)


Segher

Re: [PATCH] c-family: Honor -Wno-init-self for cv-qual vars [PR102633]

[Marek Polacek via Gcc-patches]

On Tue, Jul 26, 2022 at 04:24:18PM -0400, Jason Merrill wrote:
> On 7/26/22 15:03, Marek Polacek wrote:
> > Since r11-5188-g32934a4f45a721, we drop qualifiers during l-to-r
> > conversion by creating a NOP_EXPR.  For e.g.
> > 
> >const int i = i;
> > 
> > that means that the DECL_INITIAL is '(int) i' and not 'i' anymore.
> > Consequently, we don't suppress_warning here:
> > 
> > 711 case DECL_EXPR:
> > 715   if (VAR_P (DECL_EXPR_DECL (*expr_p))
> > 716   && !DECL_EXTERNAL (DECL_EXPR_DECL (*expr_p))
> > 717   && !TREE_STATIC (DECL_EXPR_DECL (*expr_p))
> > 718   && (DECL_INITIAL (DECL_EXPR_DECL (*expr_p)) == DECL_EXPR_DECL 
> > (*expr_p))
> > 719   && !warn_init_self)
> > 720 suppress_warning (DECL_EXPR_DECL (*expr_p), OPT_Winit_self);
> > 
> > because of the check on line 718 -- (int) i is not i.  So -Wno-init-self
> > doesn't disable the warning as it's supposed to.
> > 
> > The following patch fixes it...except it doesn't, for volatile variables
> > in C++.  The problem is that for
> > 
> >volatile int k = k;
> > 
> > we see that the initializer has TREE_SIDE_EFFECTS, so we perform dynamic
> > initialization.  So there's no DECL_INITIAL and the suppress_warning
> > call above is never done.  I suppose we could amend get_no_uninit_warning
> > to return true for volatile-qualified expressions.  I mean, can we ever
> > say for a fact that a volatile variable is uninitialized?
> > 
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > 
> > PR middle-end/102633
> > 
> > gcc/c-family/ChangeLog:
> > 
> > * c-gimplify.cc (c_gimplify_expr): Strip NOPs of DECL_INITIAL.
> 
> I wonder if we want to handle this i = i case earlier, like in finish_decl.

I could, something like

@@ -5381,7 +5381,14 @@ finish_decl (tree decl, location_t init_loc, tree init,
 init = NULL_TREE;

   if (init)
-store_init_value (init_loc, decl, init, origtype);
+{
+  /* In the self-init case, undo the artificial NOP_EXPR we may have
+added in convert_lvalue_to_rvalue so that c_gimplify_expr/DECL_EXPR
+can perform suppress_warning.  */
+  if (TREE_CODE (init) == NOP_EXPR && TREE_OPERAND (init, 0) == decl)
+   init = TREE_OPERAND (init, 0);
+  store_init_value (init_loc, decl, init, origtype);
+}

but then I'd have to do the same thing in cp_finish_decl because
decay_conversion also adds a NOP_EXPR for cv-qualified non-class prvalues.
Is that what we want?  To me that seems less clean than having c_gimplify_expr
see through NOP_EXPRs.

Marek

[committed] analyzer: fix false +ves from -Wanalyzer-va-arg-type-mismatch on int promotion [PR106319]

[David Malcolm via Gcc-patches]

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

gcc/analyzer/ChangeLog:
PR analyzer/106319
* store.cc (store::set_value): Don't strip away casts if the
region has NULL type.

gcc/testsuite/ChangeLog:
PR analyzer/106319
* gcc.dg/analyzer/stdarg-types-3.c: New test.
* gcc.dg/analyzer/stdarg-types-4.c: New test.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/store.cc |  4 +-
 .../gcc.dg/analyzer/stdarg-types-3.c  | 67 +++
 .../gcc.dg/analyzer/stdarg-types-4.c  | 22 ++
 3 files changed, 92 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/stdarg-types-3.c
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/stdarg-types-4.c

diff --git a/gcc/analyzer/store.cc b/gcc/analyzer/store.cc
index 0b3fb370d1e..46475f6a7fa 100644
--- a/gcc/analyzer/store.cc
+++ b/gcc/analyzer/store.cc
@@ -2445,7 +2445,9 @@ store::set_value (store_manager *mgr, const region 
*lhs_reg,
 
   remove_overlapping_bindings (mgr, lhs_reg, uncertainty);
 
-  rhs_sval = simplify_for_binding (rhs_sval);
+  if (lhs_reg->get_type ())
+rhs_sval = simplify_for_binding (rhs_sval);
+  /* ...but if we have no type for the region, retain any cast.  */
 
   const region *lhs_base_reg = lhs_reg->get_base_region ();
   binding_cluster *lhs_cluster;
diff --git a/gcc/testsuite/gcc.dg/analyzer/stdarg-types-3.c 
b/gcc/testsuite/gcc.dg/analyzer/stdarg-types-3.c
new file mode 100644
index 000..7351261a55c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/stdarg-types-3.c
@@ -0,0 +1,67 @@
+static void __attribute__((noinline))
+__analyzer_consume_n_ints (int num, ...)
+{
+  __builtin_va_list ap;
+  __builtin_va_start (ap, num);
+
+  int i, v;
+  for (i = 0; i < num; i++)
+v = __builtin_va_arg (ap, int);
+
+  __builtin_va_end (ap);
+}
+
+void test_int (int x)
+{
+  __analyzer_consume_n_ints (1, x);
+}
+
+void test_3_ints (int x, int y, int z)
+{
+  __analyzer_consume_n_ints (3, x, y, z);
+}
+
+/* Verify that we don't complain about types that get promoted to int
+   at the variadic call.  */
+
+void test_short (short s)
+{
+  __analyzer_consume_n_ints (1, s);
+}
+
+void test_ushort (unsigned short s)
+{
+  __analyzer_consume_n_ints (1, s);
+}
+
+void test_schar (signed char ch)
+{
+  __analyzer_consume_n_ints (1, ch);
+}
+
+void test_uchar (unsigned char ch)
+{
+  __analyzer_consume_n_ints (1, ch);
+}
+
+struct ust
+{
+  int b0123 : 4;
+  int b4567 : 4;
+};
+
+void test_signed_bitfield (struct ust s)
+{
+  __analyzer_consume_n_ints (2, s.b0123, s.b4567);
+}
+
+struct sst
+{
+  unsigned int b0123 : 4;
+  unsigned int b4567 : 4;
+};
+
+void test_unsigned_bitfield (struct sst s)
+{
+  __analyzer_consume_n_ints (2, s.b0123, s.b4567);
+}
diff --git a/gcc/testsuite/gcc.dg/analyzer/stdarg-types-4.c 
b/gcc/testsuite/gcc.dg/analyzer/stdarg-types-4.c
new file mode 100644
index 000..920eccebc2b
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/stdarg-types-4.c
@@ -0,0 +1,22 @@
+static void __attribute__((noinline))
+__analyzer_consume_n_uints (int num, ...)
+{
+  __builtin_va_list ap;
+  __builtin_va_start (ap, num);
+
+  int i, v;
+  for (i = 0; i < num; i++)
+v = __builtin_va_arg (ap, unsigned int);
+
+  __builtin_va_end (ap);
+}
+
+void test_uint (unsigned int x)
+{
+  __analyzer_consume_n_uints (1, x);
+}
+
+void test_3_uints (unsigned int x, unsigned int y, unsigned int z)
+{
+  __analyzer_consume_n_uints (3, x, y, z);
+}
-- 
2.26.3

RE: [PATCH] Add new target hook: simplify_modecc_const.

[Roger Sayle]

Hi Segher,
It's very important to distinguish the invariants that exist for the RTL
data structures as held in memory (rtx), vs. the use of "enum rtx_code"s,
"machine_mode"s and operands in the various processing functions
of the middle-end.

Yes, it's very true that RTL integer constants don't specify a mode
(are VOIDmode), so therefore operations like ZERO_EXTEND or EQ
don't make sense with all constant operands.  This is (one reason)
why constant-only operands are disallowed from RTL (data structures),
and why in APIs that perform/simplify these operations, the original
operand mode (of the const_int(s)) must be/is always passed as a
parameter.

Hence, for say simplify_const_binary_operation, op0 and op1 can
both be const_int, as the mode argument specifies the mode of the
"code" operation. Likewise, in simplify_relational_operation, both
op0 and op1 may be CONST_INT as "cmp_mode" explicitly specifies
the mode that the operation is performed in and "mode" specifies
the mode of the result.

Your comment that "comparing two integer constants is invalid
RTL *in all contexts*" is a serious misunderstanding of what's
going on.  At no point is a RTL rtx node ever allocated with two
integer constant operands.  RTL simplification is for hypothetical
"what if" transformations (just like try_combine calls recog with
RTL that may not be real instructions), and these simplifcations
are even sometimes required to preserve the documented RTL
invariants.  Comparisons of two integers must be simplified to
true/false precisely to ensure that they never appear in an actual
COMPARE node.

I worry this fundamental misunderstanding is the same issue that
has been holding up understanding/approving a previous patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578848.html

For a related bug, consider PR rtl-optimization/67382, that's assigned
to you in bugzilla.  In this case, the RTL optimizers know that both
operands to a COMPARE are integer constants (both -2), yet the
compiler still performs a run-time comparison and conditional jump:

movl$-2, %eax
movl%eax, 12(%rsp)
cmpl$-2, %eax
je  .L1

Failing to optimize/consider a comparison between two integer
constants *in any context* just leads to poor code.

Hopefully, this clears up that the documented constraints on RTL rtx
aren't exactly the same as the constraints on the use of rtx_codes in
simplify-rtx's functional APIs.  So simplify_subreg really gets called
on operands that are neither REG nor MEM, as this is unrelated to
what the documentation of the SUBREG rtx specifies.

If you don't believe that op0 and op1 can ever both be const_int
in this function, perhaps consider it harmless dead code and humor
me.

Thanks in advance,
Roger
--

> -Original Message-
> From: Segher Boessenkool 
> Sent: 26 July 2022 18:45
> To: Roger Sayle 
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] Add new target hook: simplify_modecc_const.
> 
> Hi!
> 
> On Tue, Jul 26, 2022 at 01:13:02PM +0100, Roger Sayle wrote:
> > This patch is a major revision of the patch I originally proposed here:
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598040.html
> >
> > The primary motivation of this patch is to avoid incorrect
> > optimization of MODE_CC comparisons in
> > simplify_const_relational_operation when/if a backend represents the
> > (known) contents of a MODE_CC register using a CONST_INT.  In such
> > cases, the RTL optimizers don't know the semantics of this integer
> > value, so shouldn't change anything (i.e. should return NULL_RTX from
> simplify_const_relational_operation).
> 
> This is invalid RTL.  What would  (set (reg:CC) (const_int 0))  mean, for
example?
> If this was valid it would make most existing code using CC modes do
essentially
> random things :-(
> 
> The documentation (in tm.texi, "Condition Code") says
>   Alternatively, you can use @code{BImode} if the comparison operator is
>   specified already in the compare instruction.  In this case, you are not
>   interested in most macros in this section.
> 
> > The worked example provided with this patch is to allow the i386
> > backend to explicitly model the carry flag (MODE_CCC) using 1 to
> > indicate that the carry flag is set, and 0 to indicate the carry flag
> > is clear.  This allows the instructions stc (set carry flag), clc
> > (clear carry flag) and cmc (complement carry flag) to be represented in
RTL.
> 
> Hrm, I wonder how other targets do this.
> 
> On Power we have a separate hard register for the carry flag of course (it
is a
> separate bit in the hardware as well, XER[CA]).
> 
> On Arm there is arm_carry_operation (as well as arm_borrow_operation).
> 
> Aarch64 directly uses
> (define_expand "add3_carryin"
>   [(set (match_operand:GPI 0 "register_operand")
> (plus:GPI
>   (plus:GPI
> (ltu:GPI (reg:CC_C CC_REGNUM) (const_int 0))
> (match_operand:GPI 1 "aarch64_reg_or_zero"))
>   

Re: [PATCH] c-family: Honor -Wno-init-self for cv-qual vars [PR102633]

[Jason Merrill via Gcc-patches]

On 7/26/22 15:03, Marek Polacek wrote:

Since r11-5188-g32934a4f45a721, we drop qualifiers during l-to-r
conversion by creating a NOP_EXPR.  For e.g.

   const int i = i;

that means that the DECL_INITIAL is '(int) i' and not 'i' anymore.
Consequently, we don't suppress_warning here:

711 case DECL_EXPR:
715   if (VAR_P (DECL_EXPR_DECL (*expr_p))
716   && !DECL_EXTERNAL (DECL_EXPR_DECL (*expr_p))
717   && !TREE_STATIC (DECL_EXPR_DECL (*expr_p))
718   && (DECL_INITIAL (DECL_EXPR_DECL (*expr_p)) == DECL_EXPR_DECL 
(*expr_p))
719   && !warn_init_self)
720 suppress_warning (DECL_EXPR_DECL (*expr_p), OPT_Winit_self);

because of the check on line 718 -- (int) i is not i.  So -Wno-init-self
doesn't disable the warning as it's supposed to.

The following patch fixes it...except it doesn't, for volatile variables
in C++.  The problem is that for

   volatile int k = k;

we see that the initializer has TREE_SIDE_EFFECTS, so we perform dynamic
initialization.  So there's no DECL_INITIAL and the suppress_warning
call above is never done.  I suppose we could amend get_no_uninit_warning
to return true for volatile-qualified expressions.  I mean, can we ever
say for a fact that a volatile variable is uninitialized?

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

PR middle-end/102633

gcc/c-family/ChangeLog:

* c-gimplify.cc (c_gimplify_expr): Strip NOPs of DECL_INITIAL.


I wonder if we want to handle this i = i case earlier, like in finish_decl.


gcc/testsuite/ChangeLog:

* c-c++-common/Winit-self1.c: New test.
* c-c++-common/Winit-self2.c: New test.
---
  gcc/c-family/c-gimplify.cc   | 18 +++--
  gcc/testsuite/c-c++-common/Winit-self1.c | 32 
  gcc/testsuite/c-c++-common/Winit-self2.c | 31 +++
  3 files changed, 74 insertions(+), 7 deletions(-)
  create mode 100644 gcc/testsuite/c-c++-common/Winit-self1.c
  create mode 100644 gcc/testsuite/c-c++-common/Winit-self2.c

diff --git a/gcc/c-family/c-gimplify.cc b/gcc/c-family/c-gimplify.cc
index a6f26c9b0d3..2e011830846 100644
--- a/gcc/c-family/c-gimplify.cc
+++ b/gcc/c-family/c-gimplify.cc
@@ -712,13 +712,17 @@ c_gimplify_expr (tree *expr_p, gimple_seq *pre_p 
ATTRIBUTE_UNUSED,
/* This is handled mostly by gimplify.cc, but we have to deal with
 not warning about int x = x; as it is a GCC extension to turn off
 this warning but only if warn_init_self is zero.  */
-  if (VAR_P (DECL_EXPR_DECL (*expr_p))
- && !DECL_EXTERNAL (DECL_EXPR_DECL (*expr_p))
- && !TREE_STATIC (DECL_EXPR_DECL (*expr_p))
- && (DECL_INITIAL (DECL_EXPR_DECL (*expr_p)) == DECL_EXPR_DECL 
(*expr_p))
- && !warn_init_self)
-   suppress_warning (DECL_EXPR_DECL (*expr_p), OPT_Winit_self);
-  break;
+  {
+   tree  = DECL_EXPR_DECL (*expr_p);
+   if (VAR_P (decl)
+   && !DECL_EXTERNAL (decl)
+   && !TREE_STATIC (decl)
+   && (DECL_INITIAL (decl)
+   && tree_strip_nop_conversions (DECL_INITIAL (decl)) == decl)
+   && !warn_init_self)
+ suppress_warning (decl, OPT_Winit_self);
+   break;
+  }
  
  case PREINCREMENT_EXPR:

  case PREDECREMENT_EXPR:
diff --git a/gcc/testsuite/c-c++-common/Winit-self1.c 
b/gcc/testsuite/c-c++-common/Winit-self1.c
new file mode 100644
index 000..2a1a755fc71
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/Winit-self1.c
@@ -0,0 +1,32 @@
+/* PR middle-end/102633 */
+/* { dg-do compile } */
+/* { dg-options "-Wuninitialized -Wno-init-self" } */
+
+int
+fn1 (void)
+{
+  int i = i;
+  return i;
+}
+
+int
+fn2 ()
+{
+  const int j = j;
+  return j;
+}
+
+int
+fn3 ()
+{
+  /* ??? Do we want this warning in C++?  Probably not with -Wno-init-self.  */
+  volatile int k = k; /* { dg-warning "used uninitialized" "" { target c++ } } 
*/
+  return k;
+}
+
+int
+fn4 ()
+{
+  const volatile int l = l; /* { dg-warning "used uninitialized" "" { target 
c++ } } */
+  return l;
+}
diff --git a/gcc/testsuite/c-c++-common/Winit-self2.c 
b/gcc/testsuite/c-c++-common/Winit-self2.c
new file mode 100644
index 000..13aa9efdf26
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/Winit-self2.c
@@ -0,0 +1,31 @@
+/* PR middle-end/102633 */
+/* { dg-do compile } */
+/* { dg-options "-Wuninitialized -Winit-self" } */
+
+int
+fn1 (void)
+{
+  int i = i; /* { dg-warning "used uninitialized" } */
+  return i;
+}
+
+int
+fn2 ()
+{
+  const int j = j; /* { dg-warning "used uninitialized" } */
+  return j;
+}
+
+int
+fn3 ()
+{
+  volatile int k = k; /* { dg-warning "used uninitialized" } */
+  return k;
+}
+
+int
+fn4 ()
+{
+  const volatile int l = l; /* { dg-warning "used uninitialized" } */
+  return l;
+}

base-commit: 600956c81c784f4a0cc9d10f6e03e01847afd961

Re: [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]

[Mikael Morin]

Le 25/07/2022 à 22:18, Harald Anlauf a écrit :
I would normally trust NAG more than Intel and Cray.  

… and yourself, it seems.  Too bad.


If somebody else convinces me to accept that NAG has it wrong this time, I 
would be happy to proceed.

It won’t convince you about NAG, but here are two reasons to proceed:
 - Consensus among the maintainers is sufficient; it’s the case here.
 - If uncertain, let’s be rather too permissive than too strict; it’s 
fine as long as the runtime answer is right.

[PATCH] c-family: Honor -Wno-init-self for cv-qual vars [PR102633]

[Marek Polacek via Gcc-patches]

Since r11-5188-g32934a4f45a721, we drop qualifiers during l-to-r
conversion by creating a NOP_EXPR.  For e.g.

  const int i = i;

that means that the DECL_INITIAL is '(int) i' and not 'i' anymore.
Consequently, we don't suppress_warning here:

711 case DECL_EXPR:
715   if (VAR_P (DECL_EXPR_DECL (*expr_p))
716   && !DECL_EXTERNAL (DECL_EXPR_DECL (*expr_p))
717   && !TREE_STATIC (DECL_EXPR_DECL (*expr_p))
718   && (DECL_INITIAL (DECL_EXPR_DECL (*expr_p)) == DECL_EXPR_DECL 
(*expr_p))
719   && !warn_init_self)
720 suppress_warning (DECL_EXPR_DECL (*expr_p), OPT_Winit_self);

because of the check on line 718 -- (int) i is not i.  So -Wno-init-self
doesn't disable the warning as it's supposed to.

The following patch fixes it...except it doesn't, for volatile variables
in C++.  The problem is that for

  volatile int k = k;

we see that the initializer has TREE_SIDE_EFFECTS, so we perform dynamic
initialization.  So there's no DECL_INITIAL and the suppress_warning
call above is never done.  I suppose we could amend get_no_uninit_warning
to return true for volatile-qualified expressions.  I mean, can we ever
say for a fact that a volatile variable is uninitialized?

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

PR middle-end/102633

gcc/c-family/ChangeLog:

* c-gimplify.cc (c_gimplify_expr): Strip NOPs of DECL_INITIAL.

gcc/testsuite/ChangeLog:

* c-c++-common/Winit-self1.c: New test.
* c-c++-common/Winit-self2.c: New test.
---
 gcc/c-family/c-gimplify.cc   | 18 +++--
 gcc/testsuite/c-c++-common/Winit-self1.c | 32 
 gcc/testsuite/c-c++-common/Winit-self2.c | 31 +++
 3 files changed, 74 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/Winit-self1.c
 create mode 100644 gcc/testsuite/c-c++-common/Winit-self2.c

diff --git a/gcc/c-family/c-gimplify.cc b/gcc/c-family/c-gimplify.cc
index a6f26c9b0d3..2e011830846 100644
--- a/gcc/c-family/c-gimplify.cc
+++ b/gcc/c-family/c-gimplify.cc
@@ -712,13 +712,17 @@ c_gimplify_expr (tree *expr_p, gimple_seq *pre_p 
ATTRIBUTE_UNUSED,
   /* This is handled mostly by gimplify.cc, but we have to deal with
 not warning about int x = x; as it is a GCC extension to turn off
 this warning but only if warn_init_self is zero.  */
-  if (VAR_P (DECL_EXPR_DECL (*expr_p))
- && !DECL_EXTERNAL (DECL_EXPR_DECL (*expr_p))
- && !TREE_STATIC (DECL_EXPR_DECL (*expr_p))
- && (DECL_INITIAL (DECL_EXPR_DECL (*expr_p)) == DECL_EXPR_DECL 
(*expr_p))
- && !warn_init_self)
-   suppress_warning (DECL_EXPR_DECL (*expr_p), OPT_Winit_self);
-  break;
+  {
+   tree  = DECL_EXPR_DECL (*expr_p);
+   if (VAR_P (decl)
+   && !DECL_EXTERNAL (decl)
+   && !TREE_STATIC (decl)
+   && (DECL_INITIAL (decl)
+   && tree_strip_nop_conversions (DECL_INITIAL (decl)) == decl)
+   && !warn_init_self)
+ suppress_warning (decl, OPT_Winit_self);
+   break;
+  }
 
 case PREINCREMENT_EXPR:
 case PREDECREMENT_EXPR:
diff --git a/gcc/testsuite/c-c++-common/Winit-self1.c 
b/gcc/testsuite/c-c++-common/Winit-self1.c
new file mode 100644
index 000..2a1a755fc71
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/Winit-self1.c
@@ -0,0 +1,32 @@
+/* PR middle-end/102633 */
+/* { dg-do compile } */
+/* { dg-options "-Wuninitialized -Wno-init-self" } */
+
+int
+fn1 (void)
+{
+  int i = i;
+  return i;
+}
+
+int
+fn2 ()
+{
+  const int j = j;
+  return j;
+}
+
+int
+fn3 ()
+{
+  /* ??? Do we want this warning in C++?  Probably not with -Wno-init-self.  */
+  volatile int k = k; /* { dg-warning "used uninitialized" "" { target c++ } } 
*/
+  return k;
+}
+
+int
+fn4 ()
+{
+  const volatile int l = l; /* { dg-warning "used uninitialized" "" { target 
c++ } } */
+  return l;
+}
diff --git a/gcc/testsuite/c-c++-common/Winit-self2.c 
b/gcc/testsuite/c-c++-common/Winit-self2.c
new file mode 100644
index 000..13aa9efdf26
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/Winit-self2.c
@@ -0,0 +1,31 @@
+/* PR middle-end/102633 */
+/* { dg-do compile } */
+/* { dg-options "-Wuninitialized -Winit-self" } */
+
+int
+fn1 (void)
+{
+  int i = i; /* { dg-warning "used uninitialized" } */
+  return i;
+}
+
+int
+fn2 ()
+{
+  const int j = j; /* { dg-warning "used uninitialized" } */
+  return j;
+}
+
+int
+fn3 ()
+{
+  volatile int k = k; /* { dg-warning "used uninitialized" } */
+  return k;
+}
+
+int
+fn4 ()
+{
+  const volatile int l = l; /* { dg-warning "used uninitialized" } */
+  return l;
+}

base-commit: 600956c81c784f4a0cc9d10f6e03e01847afd961
-- 
2.37.1

[committed] analyzer: fix stray get_element decls

[David Malcolm via Gcc-patches]

These were copy errors.

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

gcc/analyzer/ChangeLog:
* region.h (code_region::get_element): Remove stray decl.
(function_region::get_element): Likewise.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/region.h | 8 
 1 file changed, 8 deletions(-)

diff --git a/gcc/analyzer/region.h b/gcc/analyzer/region.h
index fd0d4a05cc9..1067748a7cd 100644
--- a/gcc/analyzer/region.h
+++ b/gcc/analyzer/region.h
@@ -400,10 +400,6 @@ public:
   /* region vfuncs.  */
   void dump_to_pp (pretty_printer *pp, bool simple) const final override;
   enum region_kind get_kind () const final override { return RK_CODE; }
-
-  const region *get_element (region_model *model,
-   const svalue *index,
-   region_model_context *ctxt);
 };
 
 } // namespace ana
@@ -439,10 +435,6 @@ public:
 
   tree get_fndecl () const { return m_fndecl; }
 
-  region *get_element (region_model *model,
-   const svalue *index_sid,
-   region_model_context *ctxt);
-
 private:
   tree m_fndecl;
 };
-- 
2.26.3

[PATCH] RISC-V: Standardize formatting of SFB ALU conditional move

[Maciej W. Rozycki]

Standardize the formatting of SFB ALU conditional move operations from:

beq a2,zero,1f; mv a0,zero; 1: # movcc

to:

beq a2,zero,1f  # movcc
mv  a0,zero
1:

for consistency with other assembly code produced.  No functional change.

gcc/
* gcc/config/riscv/riscv.md (*movcc): Fix 
output pattern formatting.
---
Hi,

 No regressions in `-mtune=sifive-7-series' testing except for:

FAIL: gcc.target/riscv/pr105314.c   -O0   scan-assembler-not \tbeq\t
FAIL: gcc.target/riscv/pr105314.c   -O1   scan-assembler-not \tbeq\t
FAIL: gcc.target/riscv/pr105314.c   -O2   scan-assembler-not \tbeq\t
FAIL: gcc.target/riscv/pr105314.c   -O3 -g   scan-assembler-not \tbeq\t
FAIL: gcc.target/riscv/pr105314.c   -Os   scan-assembler-not \tbeq\t
FAIL: gcc.target/riscv/pr105314.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none   scan-assembler-not \tbeq\t
FAIL: gcc.target/riscv/pr105314.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects   scan-assembler-not \tbeq\t

as expected due to the brokenness of the test case, as discussed here: 
 (still 
unresolved).

 OK to apply?

  Maciej
---
 gcc/config/riscv/riscv.md |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

gcc-riscv-movcc-format.diff
Index: gcc/gcc/config/riscv/riscv.md
===
--- gcc.orig/gcc/config/riscv/riscv.md
+++ gcc/gcc/config/riscv/riscv.md
@@ -2187,8 +2187,8 @@
 (match_operand:GPR 4 "sfb_alu_operand" "rJ,IL")))]
   "TARGET_SFB_ALU"
   "@
-   b%C5 %1,%z2,1f; mv %0,%z4; 1: # movcc
-   b%C5 %1,%z2,1f; li %0,%4; 1: # movcc"
+   b%C5\t%1,%z2,1f\t# movcc\;mv\t%0,%z4\n1:
+   b%C5\t%1,%z2,1f\t# movcc\;li\t%0,%4\n1:"
   [(set_attr "length" "8")
(set_attr "type" "sfb_alu")
(set_attr "mode" "")])

Re: [PATCH] Add new target hook: simplify_modecc_const.

[Segher Boessenkool]

Hi!

On Tue, Jul 26, 2022 at 01:13:02PM +0100, Roger Sayle wrote:
> This patch is a major revision of the patch I originally proposed here:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598040.html
> 
> The primary motivation of this patch is to avoid incorrect optimization
> of MODE_CC comparisons in simplify_const_relational_operation when/if a
> backend represents the (known) contents of a MODE_CC register using a
> CONST_INT.  In such cases, the RTL optimizers don't know the semantics
> of this integer value, so shouldn't change anything (i.e. should return
> NULL_RTX from simplify_const_relational_operation).

This is invalid RTL.  What would  (set (reg:CC) (const_int 0))  mean,
for example?  If this was valid it would make most existing code using
CC modes do essentially random things :-(

The documentation (in tm.texi, "Condition Code") says
  Alternatively, you can use @code{BImode} if the comparison operator is
  specified already in the compare instruction.  In this case, you are not
  interested in most macros in this section.

> The worked example provided with this patch is to allow the i386 backend
> to explicitly model the carry flag (MODE_CCC) using 1 to indicate that
> the carry flag is set, and 0 to indicate the carry flag is clear.  This
> allows the instructions stc (set carry flag), clc (clear carry flag) and
> cmc (complement carry flag) to be represented in RTL.

Hrm, I wonder how other targets do this.

On Power we have a separate hard register for the carry flag of course
(it is a separate bit in the hardware as well, XER[CA]).

On Arm there is arm_carry_operation (as well as arm_borrow_operation).

Aarch64 directly uses
(define_expand "add3_carryin"
  [(set (match_operand:GPI 0 "register_operand")
(plus:GPI
  (plus:GPI
(ltu:GPI (reg:CC_C CC_REGNUM) (const_int 0))
(match_operand:GPI 1 "aarch64_reg_or_zero"))
  (match_operand:GPI 2 "aarch64_reg_or_zero")))]
   ""
   ""
)
(CC_Cmode means only the C bit is validly set).

s390 does similar.  sparc does similar.

> However an even better example would be the rs6000 backend, where this
> patch/target hook would allow improved modelling of the condition register
> CR.  The powerpc's comparison instructions set fields/bits in the CR
> register [where bit 0 indicates less than, bit 1 greater than, bit 2
> equal to and bit3 overflow]

There are eight condition register fields which can be used
interchangeably (some insns only write to CR0, CR1, or CR6).  The
meaning of the four bits in a field depends on the instruction that set
them.  For integer comparisons bit 3 does not mean anything to do with a
comparison: instead, it is a copy of the XER[SO] bit ("summary
overflow").  The rs6000 backend does not currently model this (we do not
model the overflow instructions at all!)

> analogous to x86's flags register [containing
> bits for carry, zero, overflow, parity etc.].  These fields can be
> manipulated directly using crset (aka creqv) and crclr (aka crxor)
> instructions

crand, crnand, cror, crxor, crnor, creqv, crandc, crorc insns, or the
extended mnemonics crmove, crclr, crnot, crset, yes.  All these for
setting single bits; there also is mcrf to copy all four bits of a CR
field to another.

> and even transferred from general purpose registers using
> mtcr.  However, without a patch like this, it's impossible to safely
> model/represent these instructions in rs6000.md.

And yet we do.  See for example @cceq_rev_compare_ which
implements crnot.

> +  /* Handle MODE_CC comparisons that have been simplified to
> + constants.  */
> +  if (GET_MODE_CLASS (mode) == MODE_CC
> +  && op1 == const0_rtx
> +  && CONST_INT_P (op0))
> +return targetm.simplify_modecc_const (mode, (int)code, op0);

Comparing two integer constants is invalid RTL *in all contexts*.  The
items compared do not have a mode!  From rtl.texi:
  A @code{compare} specifying two @code{VOIDmode} constants is not valid
  since there is no way to know in what mode the comparison is to be
  performed; the comparison must either be folded during the compilation
  or the first operand must be loaded into a register while its mode is
  still known.


Segher

Re: [PATCH] RISC-V: Remove duplicate backslashes from `stack_protect_set_'

[Kito Cheng via Gcc-patches]

Hi Maciej:

Ooops, thanks for fixing that, the change was gotten from kernel
folks. I assume they have already used that for a while, but it's
really weird no bug report from those guys...

OK for trunk and backport for release branch.

On Wed, Jul 27, 2022 at 1:00 AM Maciej W. Rozycki  wrote:
>
> Remove redundant duplicate backslash characters from \t sequences in the
> output pattern of the `stack_protect_set_' RTL insn.
>
> gcc/
> * gcc/config/riscv/riscv.md (stack_protect_set_): Remove
> duplicate backslashes.
> ---
> Hi,
>
>  I don't know why it doesn't matter whether the backslash is duplicated
> here or not, but output produced in insn-output.cc is the same either way,
> with lone \t sequences present, so remove these extraneous backslashes for
> consistency.  Even this very output pattern does not have this duplication
> present in the final LI instruction.
>
>  OK to apply?
>
>   Maciej
> ---
>  gcc/config/riscv/riscv.md |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> gcc-riscv-stack-protect-tab.diff
> Index: gcc/gcc/config/riscv/riscv.md
> ===
> --- gcc.orig/gcc/config/riscv/riscv.md
> +++ gcc/gcc/config/riscv/riscv.md
> @@ -2851,7 +2851,7 @@
>  UNSPEC_SSP_SET))
> (set (match_scratch:GPR 2 "=") (const_int 0))]
>""
> -  "\\t%2, %1\;\\t%2, %0\;li\t%2, 0"
> +  "\t%2, %1\;\t%2, %0\;li\t%2, 0"
>[(set_attr "length" "12")])
>
>  (define_expand "stack_protect_test"

[PATCH] RISC-V: Remove duplicate backslashes from `stack_protect_set_'

[Maciej W. Rozycki]

Remove redundant duplicate backslash characters from \t sequences in the 
output pattern of the `stack_protect_set_' RTL insn.

gcc/
* gcc/config/riscv/riscv.md (stack_protect_set_): Remove 
duplicate backslashes.
---
Hi,

 I don't know why it doesn't matter whether the backslash is duplicated 
here or not, but output produced in insn-output.cc is the same either way, 
with lone \t sequences present, so remove these extraneous backslashes for 
consistency.  Even this very output pattern does not have this duplication 
present in the final LI instruction.

 OK to apply?

  Maciej
---
 gcc/config/riscv/riscv.md |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

gcc-riscv-stack-protect-tab.diff
Index: gcc/gcc/config/riscv/riscv.md
===
--- gcc.orig/gcc/config/riscv/riscv.md
+++ gcc/gcc/config/riscv/riscv.md
@@ -2851,7 +2851,7 @@
 UNSPEC_SSP_SET))
(set (match_scratch:GPR 2 "=") (const_int 0))]
   ""
-  "\\t%2, %1\;\\t%2, %0\;li\t%2, 0"
+  "\t%2, %1\;\t%2, %0\;li\t%2, 0"
   [(set_attr "length" "12")])
 
 (define_expand "stack_protect_test"

Re: [PATCH] analyzer: add get_meaning_for_state_change vfunc to fd_diagnostic in sm-fd.cc [PR106286]

[David Malcolm via Gcc-patches]

On Tue, 2022-07-26 at 22:07 +0530, Immad Mir wrote:
> This patch adds get_meaning_for_state_change vfunc to
> fd_diagnostic in sm-fd.cc which could be used by SARIF output.
> 
> Lightly tested on x86_64 Linux.

Thanks - looks good for trunk.

Dave

[PATCH] analyzer: add get_meaning_for_state_change vfunc to fd_diagnostic in sm-fd.cc [PR106286]

[Immad Mir via Gcc-patches]

This patch adds get_meaning_for_state_change vfunc to
fd_diagnostic in sm-fd.cc which could be used by SARIF output.

Lightly tested on x86_64 Linux.

gcc/analyzer/ChangeLog:
PR analyzer/106286
* sm-fd.cc:
(fd_diagnostic::get_meaning_for_state_change): New.

gcc/testsuite/ChangeLog:
PR analyzer/106286
* gcc.dg/analyzer/fd-meaning.c: New test.

Signed-off-by: Immad Mir 
---
 gcc/analyzer/sm-fd.cc  | 14 
 gcc/testsuite/gcc.dg/analyzer/fd-meaning.c | 37 ++
 2 files changed, 51 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/fd-meaning.c

diff --git a/gcc/analyzer/sm-fd.cc b/gcc/analyzer/sm-fd.cc
index 56b0063ba42..ed923ade100 100644
--- a/gcc/analyzer/sm-fd.cc
+++ b/gcc/analyzer/sm-fd.cc
@@ -229,6 +229,20 @@ public:
 return label_text ();
   }
 
+  diagnostic_event::meaning
+  get_meaning_for_state_change (
+  const evdesc::state_change ) const final override
+  {
+if (change.m_old_state == m_sm.get_start_state ()
+   && (m_sm.is_unchecked_fd_p (change.m_new_state)))
+  return diagnostic_event::meaning (diagnostic_event::VERB_acquire,
+diagnostic_event::NOUN_resource);
+if (change.m_new_state == m_sm.m_closed)
+  return diagnostic_event::meaning (diagnostic_event::VERB_release,
+diagnostic_event::NOUN_resource);
+return diagnostic_event::meaning ();
+  }
+
 protected:
   const fd_state_machine _sm;
   tree m_arg;
diff --git a/gcc/testsuite/gcc.dg/analyzer/fd-meaning.c 
b/gcc/testsuite/gcc.dg/analyzer/fd-meaning.c
new file mode 100644
index 000..6a9ec921fd3
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/fd-meaning.c
@@ -0,0 +1,37 @@
+  /* { dg-additional-options "-fanalyzer-verbose-state-changes" } */
+int open(const char *, int mode);
+void close(int fd);
+
+#define O_RDONLY 0
+#define O_WRONLY 1
+#define O_RDWR 2
+
+void test_1 (const char* path)
+{
+int fd = open (path, O_RDWR); /* { dg-message "meaning: \\{verb: 
'acquire', noun: 'resource'\\}" } */
+if (fd != -1)
+{
+close(fd); /* { dg-message "meaning: \\{verb: 'release', noun: 
'resource'\\}" } */
+close(fd); /* { dg-warning "double 'close' of file descriptor 'fd' 
\\\[CWE-1341\\\]" } */
+}
+}
+
+void test_2 (const char* path)
+{
+int fd = open (path, O_RDONLY); /* { dg-message "meaning: \\{verb: 
'acquire', noun: 'resource'\\}" } */
+if (fd != -1)
+{
+close(fd); /* { dg-message "meaning: \\{verb: 'release', noun: 
'resource'\\}" } */
+close(fd); /* { dg-warning "double 'close' of file descriptor 'fd' 
\\\[CWE-1341\\\]" } */
+}
+}
+
+void test_3 (const char* path)
+{
+int fd = open (path, O_WRONLY); /* { dg-message "meaning: \\{verb: 
'acquire', noun: 'resource'\\}" } */
+if (fd != -1)
+{
+close(fd); /* { dg-message "meaning: \\{verb: 'release', noun: 
'resource'\\}" } */
+close(fd); /* { dg-warning "double 'close' of file descriptor 'fd' 
\\\[CWE-1341\\\]" } */
+}
+}
\ No newline at end of file
-- 
2.25.1

[PATCH] middle-end: More support for ABIs that pass FP values as wider ints.

[Roger Sayle]

Firstly many thanks again to Jeff Law for reviewing/approving the previous
patch to add support for ABIs that pass FP values as wider integer modes.
That has allowed significant progress on PR target/104489.  As predicted
enabling HFmode on nvptx-none automatically enables more testcases in the
testsuite and making sure these all PASS has revealed a few missed spots
and a deficiency in the middle-end.  For example, support for HC mode,
where a complex value is encoded as two 16-bit HFmode parts was
insufficiently covered in my previous testing.  More interesting is
that __fixunshfti is required by GCC, and not natively supported by
the nvptx backend, requiring softfp support in libgcc, which in turn
revealed an interesting asymmetry in libcall handling in optabs.cc.

In the expand_fixed_convert function, which is responsible for
expanding libcalls for integer to floating point conversion, GCC
calls prepare_libcall_arg that (specifically for integer arguments)
calls promote_function_mode on the argument, so that the libcall
ABI matches the regular target ABI.  By comparison, the equivalent
expand_fix function, for floating point to integer conversion, doesn't
promote its argument.  On nvptx, where the assembler is strongly
typed, this produces a mismatch as the __fixunshfti function created
by libgcc doesn't precisely match the signature assumed by optabs.
The solution is to perform the same (or similar) prepare_libcall_arg
preparation in both cases.  In this patch, the existing (static)
prepare_libcall_arg, which assumes an integer argument, is renamed
prepare_libcall_int_arg, and a matching prepare_libcall_fp_arg is
introduced.  This should be safe on other platforms (fingers-crossed)
as floating point argument promotion is rare [floats are passed in
float registers, doubles are passed in double registers, etc.]

This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32},
and on nvptx-none with a backend patch that resolves the rest of
PR target/104489.  Ok for mainline?


2022-07-26  Roger Sayle  

gcc/ChangeLog
PR target/104489
* calls.cc (emit_library_call_value_1): Enable the FP return value
of a libcall to be returned as a wider integer, by converting the
int result to be converted to the desired floating point mode.
(store_one_arg): Allow floating point arguments to be passed on
the stack as wider integers using convert_float_to_wider_int.
* function.cc (assign_parms_unsplit_complex): Likewise, allow
complex floating point modes to be passed as wider integer parts,
using convert_wider_int_to_float.
* optabs.cc (prepare_libcall_fp_arg): New function. A floating
point version of the previous prepare_libcall_arg that calls
promote_function_mode on its argument.
(expand_fix): Call new prepare_libcall_fp_arg on FIX argument.
(prepare_libcall_int_arg): Renamed from prepare_libcall_arg.
(expand_fixed_convert): Update call of prepare_libcall_arg to
the new name, prepare_libcall_int_arg.


Thanks again,
Roger
--

diff --git a/gcc/calls.cc b/gcc/calls.cc
index 7f3cf5f..50d0495 100644
--- a/gcc/calls.cc
+++ b/gcc/calls.cc
@@ -4791,14 +4791,20 @@ emit_library_call_value_1 (int retval, rtx orgfun, rtx 
value,
   else
{
  /* Convert to the proper mode if a promotion has been active.  */
- if (GET_MODE (valreg) != outmode)
+ enum machine_mode valmode = GET_MODE (valreg);
+ if (valmode != outmode)
{
  int unsignedp = TYPE_UNSIGNED (tfom);
 
  gcc_assert (promote_function_mode (tfom, outmode, ,
 fndecl ? TREE_TYPE (fndecl) : 
fntype, 1)
- == GET_MODE (valreg));
- valreg = convert_modes (outmode, GET_MODE (valreg), valreg, 0);
+ == valmode);
+ if (SCALAR_INT_MODE_P (valmode)
+ && SCALAR_FLOAT_MODE_P (outmode)
+ && known_gt (GET_MODE_SIZE (valmode), GET_MODE_SIZE 
(outmode)))
+   valreg = convert_wider_int_to_float (outmode, valmode, valreg);
+ else
+   valreg = convert_modes (outmode, valmode, valreg, 0);
}
 
  if (value != 0)
@@ -5003,8 +5009,20 @@ store_one_arg (struct arg_data *arg, rtx argblock, int 
flags,
   /* If we are promoting object (or for any other reason) the mode
 doesn't agree, convert the mode.  */
 
-  if (arg->mode != TYPE_MODE (TREE_TYPE (pval)))
-   arg->value = convert_modes (arg->mode, TYPE_MODE (TREE_TYPE (pval)),
+  machine_mode old_mode = TYPE_MODE (TREE_TYPE (pval));
+
+  /* Some ABIs require scalar floating point modes to be passed
+in a wider scalar integer mode.  We need to explicitly
+reinterpret to an integer mode of the correct precision
+before 

Re: [PATCH 7/7] jit,docs: remove :ref:`modindex`

[David Malcolm via Gcc-patches]

On Tue, 2022-07-26 at 06:55 +0200, Martin Liška wrote:
> gcc/jit/ChangeLog:
> 
> * docs/index.rst: Remove reference to module index
> as we don't emit any.

Patch is OK

Thanks
Dave

> ---
>  gcc/jit/docs/index.rst | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/gcc/jit/docs/index.rst b/gcc/jit/docs/index.rst
> index 21c3140e238..0f575966303 100644
> --- a/gcc/jit/docs/index.rst
> +++ b/gcc/jit/docs/index.rst
> @@ -43,5 +43,4 @@ Indices and tables
>  ==
>  
>  * :ref:`genindex`
> -* :ref:`modindex`
>  * :ref:`search`

Re: [PATCH 6/7] jit,docs: use :expr:`type *` for pointers to a type

[David Malcolm via Gcc-patches]

On Tue, 2022-07-26 at 06:50 +0200, Martin Liška wrote:
> On 7/26/22 00:41, David Malcolm wrote:
> > On Mon, 2022-07-25 at 14:39 +0200, Martin Liska wrote:
> > > gcc/jit/ChangeLog:
> > > 
> > > * docs/cp/intro/tutorial02.rst: Use :expr:`type *` for
> > > pointers to a type
> > > * docs/cp/topics/asm.rst: Likewise.
> > > * docs/cp/topics/contexts.rst: Likewise.
> > > * docs/cp/topics/expressions.rst: Likewise.
> > > * docs/cp/topics/functions.rst: Likewise.
> > > * docs/cp/topics/objects.rst: Likewise.
> > > * docs/intro/tutorial02.rst: Likewise.
> > > * docs/intro/tutorial03.rst: Likewise.
> > > * docs/intro/tutorial04.rst: Likewise.
> > > * docs/intro/tutorial05.rst: Likewise.
> > > * docs/topics/compilation.rst: Likewise.
> > > * docs/topics/contexts.rst: Likewise.
> > > * docs/topics/objects.rst: Likewise.
> > 
> > As per patch 2/7, what's the motivation for this change?  The
> > things
> > being marked up are types rather than expressions.
> 
> Apparently, one can't reference a type pointer with :type:`type *` as
> I asked
> in: https://github.com/sphinx-doc/sphinx/issues/10704

Aha; thanks!

The patch is OK.

Dave

Re: [PATCH 2/7] jit,docs: replace c:type:`int_type` with :expr:`int_type`

[David Malcolm via Gcc-patches]

On Tue, 2022-07-26 at 06:48 +0200, Martin Liška wrote:
> On 7/26/22 00:37, David Malcolm wrote:
> > On Mon, 2022-07-25 at 11:03 +0200, Martin Liska wrote:
> > > Use expression that work fine for basic type.
> > 
> > What's the motivation for this change?  Surely the things being
> > marked
> > up are types, rather than expressions?
> 
> Problem is that one can't reference a type that is not defined by a
> :type: directive,
> that's why I'm using :expr:
> 
> Fixes the following Sphinx warnings:
> 
> /home/marxin/Programming/gcc/gcc/jit/docs/topics/expressions.rst:70:
> WARNING: Unparseable C cross-reference: 'long'
> Invalid C declaration: Expected identifier in nested name, got
> keyword: long [error at 4]
>   long
>   ^

Fair enough, thanks.  LGTM.

Dave

Re: [PATCH] jit,docs: shorten assembly output

[David Malcolm via Gcc-patches]

On Tue, 2022-07-26 at 08:42 +0200, Martin Liška wrote:
> Shorten the assembly example so that there is not slider.
> 
> Ready for master?

OK, thanks
Dave

Re: [PING][PATCH] c: Handle initializations of opaque types [PR106016] (need review of expr.cc hunk)

[Peter Bergner via Gcc-patches]

On 7/26/22 1:57 AM, Richard Biener via Gcc-patches wrote:
>> On 6/17/22 11:50 PM, Peter Bergner via Gcc-patches wrote:
>>> The initial commit that added opaque types thought that there couldn't
>>> be any valid initializations for variables of these types, but the test
>>> case in the bug report shows that isn't true.  The solution is to handle
>>> OPAQUE_TYPE initializations just like the other scalar types.
>>>
>>> This passed bootstrap and regtesting with no regressions on 
>>> powerpc64le-linux.
>>> Ok for trunk?  This is an issue in GCC 12 and 11 too.  Ok for the release
>>> branches after some burn-in on trunk?
> 
> OK.

Ok, pushed to trunk.  I'll push the backports after a little burn-in
on trunk.  Thanks!

Peter

Re: [PATCH] match.pd: Add new division pattern [PR104992]

[Sam Feifer via Gcc-patches]

>
> int f(_Complex int x, _Complex int y)
> {
>   return x == x / y * y;
> }
>

After some research about mod with complex types, I found that the binary
mod operation does not work with complex types. If so, the complex test
case should not be simplified. Is this correct?

I should also note that the above function, f, causes a segmentation fault.
I can only get a function with complex types to compile by breaking up the
operations like I would in a forward propagation test case. When I do this,
it does not simplify into mod, which I think is right.

Thanks
-Sam


> For vector try (which works for both the C and C++ front-end):
> #define vector __attribute__((vector_size(4*sizeof(int)) ))
> vector int f(vector int x, vector int y)
> {
>   return x == x / y * y;
> }
>
> That is for the vector case, == still returns a vector type.
>
> Thanks,
> Andrew Pinski
>
> >
> > Thanks
> > -Sam
> >
> >> Thanks,
> >> Andrew Pinski
> >>
> >> > diff --git a/gcc/testsuite/gcc.dg/pr104992-1.c
> b/gcc/testsuite/gcc.dg/pr104992-1.c
> >> > new file mode 100644
> >> > index 000..a80e5e180ce
> >> > --- /dev/null
> >> > +++ b/gcc/testsuite/gcc.dg/pr104992-1.c
> >> > @@ -0,0 +1,30 @@
> >> > +/* PR tree-optimization/104992 */
> >> > +/* { dg-do run } */
> >> > +/* { dg-options "-O2"} */
> >> > +
> >> > +#include "pr104992.c"
> >> > +
> >> > +int main () {
> >> > +
> >> > +/* Should be true.  */
> >> > +if (!foo(6, 3)
> >> > +|| !bar(12, 2)
> >> > +|| !baz(34, 17)
> >> > +|| !qux(50, 10)
> >> > +|| !fred(16, 8)
> >> > +|| !baz(-9, 3)
> >> > +|| !baz(9, -3)
> >> > +|| !baz(-9, -3)
> >> > +) {
> >> > +__builtin_abort();
> >> > + }
> >> > +
> >> > +/* Should be false.  */
> >> > +if (foo(5, 30)
> >> > +|| bar(72, 27)
> >> > +|| baz(42, 15)) {
> >> > +__builtin_abort();
> >> > +}
> >> > +
> >> > +return 0;
> >> > +}
> >> > diff --git a/gcc/testsuite/gcc.dg/pr104992.c
> b/gcc/testsuite/gcc.dg/pr104992.c
> >> > new file mode 100644
> >> > index 000..b4b0ca53118
> >> > --- /dev/null
> >> > +++ b/gcc/testsuite/gcc.dg/pr104992.c
> >> > @@ -0,0 +1,35 @@
> >> > +/* PR tree-optimization/104992 */
> >> > +/* { dg-do compile } */
> >> > +/* { dg-options "-O2 -fdump-tree-optimized" } */
> >> > +
> >> > +/* Form from PR.  */
> >> > +__attribute__((noipa)) unsigned foo(unsigned x, unsigned y)
> >> > +{
> >> > +return x / y * y == x;
> >> > +}
> >> > +
> >> > +__attribute__((noipa)) unsigned bar(unsigned x, unsigned y) {
> >> > +return x == x / y * y;
> >> > +}
> >> > +
> >> > +/* Signed test case.  */
> >> > +__attribute__((noipa)) unsigned baz (int x, int y) {
> >> > +return x / y * y == x;
> >> > +}
> >> > +
> >> > +/* Changed order.  */
> >> > +__attribute__((noipa)) unsigned qux (unsigned x, unsigned y) {
> >> > +return y * (x / y) == x;
> >> > +}
> >> > +
> >> > +/* Wrong order.  */
> >> > +__attribute__((noipa)) unsigned fred (unsigned x, unsigned y) {
> >> > +return y * x / y == x;
> >> > +}
> >> > +
> >> > +/* Wrong pattern.  */
> >> > +__attribute__((noipa)) unsigned waldo (unsigned x, unsigned y,
> unsigned z) {
> >> > +return x / y * z == x;
> >> > +}
> >> > +
> >> > +/* { dg-final {scan-tree-dump-times " % " 4 "optimized" } } */
> >> >
> >> > base-commit: 633e9920589ddfaf2d6da1c24ce99b18a2638db4
> >> > --
> >> > 2.31.1
> >> >
> >>
>
>

[PATCH] LoongArch: adjust the default of -mexplicit-relocs by checking gas feature

[Xi Ruoyao via Gcc-patches]

> > Maybe we can add a check in gcc/configure.ac to see if gcc_cv_ld
> > supports %got_pc_hi20 and adjust the default for -m[no]-explicit-relocs?

> I think this is a good way, I'll look at adding a check.

The following should work.  I've tested it locally by building GCC with
both old (2.38 with patch) and new (trunk) Binutils. Ok for trunk?

I simply checked as instead of ld.  If as supports explicitly
relocations, the produced .o file won't be supported by an old ld even
if we use -mno-explicit-relocs (because as will generate new relocation
types for la.local etc).  So such a mismatch between as and ld can be
considered "completely broken" and we don't need to support it.  And,
the Alpha port also check the assembler for the default of -mexplicit-
relocs.

This should be documented in invoke.texi, but currently it does not
mention -mexplicit-relocs for LoongArch at all.  So I'll submit the
doclater in another patch.

-- >8 --

The assembly produced with -mexplicit-relocs is not supported by gas <=
2.39.  Check if the assembler supports explicit relocations and set the
default accordingly.

gcc/ChangeLog:

* configure.ac (HAVE_AS_EXPLICIT_RELOCS): Define to 1 if the
assembler supports explicit relocation for LoongArch.
* configure: Regenerate.
* config/loongarch/loongarch-opts.h (HAVE_AS_EXPLICIT_RELOCS):
Define to 0 if not defined.
* config/loongarch/genopts/loongarch.opt.in
(TARGET_EXPLICIT_RELOCS): Default to HAVE_AS_EXPLICIT_RELOCS.
* config/loongarch/loongarch.opt: Regenerate.
---
 gcc/config/loongarch/genopts/loongarch.opt.in |  2 +-
 gcc/config/loongarch/loongarch-opts.h |  4 ++
 gcc/config/loongarch/loongarch.opt|  2 +-
 gcc/configure | 37 +--
 gcc/configure.ac  |  7 +++-
 5 files changed, 46 insertions(+), 6 deletions(-)

diff --git a/gcc/config/loongarch/genopts/loongarch.opt.in 
b/gcc/config/loongarch/genopts/loongarch.opt.in
index 6f39500935d..a571b6b7524 100644
--- a/gcc/config/loongarch/genopts/loongarch.opt.in
+++ b/gcc/config/loongarch/genopts/loongarch.opt.in
@@ -155,7 +155,7 @@ Target Joined RejectNegative UInteger 
Var(loongarch_max_inline_memcpy_size) Init
 -mmax-inline-memcpy-size=SIZE  Set the max size of memcpy to inline, default 
is 1024.
 
 mexplicit-relocs
-Target Var(TARGET_EXPLICIT_RELOCS) Init(1)
+Target Var(TARGET_EXPLICIT_RELOCS) Init(HAVE_AS_EXPLICIT_RELOCS)
 Use %reloc() assembly operators.
 
 ; The code model option names for -mcmodel.
diff --git a/gcc/config/loongarch/loongarch-opts.h 
b/gcc/config/loongarch/loongarch-opts.h
index eaa6fc07448..da24ecd2b50 100644
--- a/gcc/config/loongarch/loongarch-opts.h
+++ b/gcc/config/loongarch/loongarch-opts.h
@@ -87,4 +87,8 @@ loongarch_config_target (struct loongarch_target *target,
while -m[no]-memcpy imposes a global constraint.  */
 #define TARGET_DO_OPTIMIZE_BLOCK_MOVE_P  loongarch_do_optimize_block_move_p()
 
+#ifndef HAVE_AS_EXPLICIT_RELOCS
+#define HAVE_AS_EXPLICIT_RELOCS 0
+#endif
+
 #endif /* LOONGARCH_OPTS_H */
diff --git a/gcc/config/loongarch/loongarch.opt 
b/gcc/config/loongarch/loongarch.opt
index 7a8c5b44418..9df7e187283 100644
--- a/gcc/config/loongarch/loongarch.opt
+++ b/gcc/config/loongarch/loongarch.opt
@@ -162,7 +162,7 @@ Target Joined RejectNegative UInteger 
Var(loongarch_max_inline_memcpy_size) Init
 -mmax-inline-memcpy-size=SIZE  Set the max size of memcpy to inline, default 
is 1024.
 
 mexplicit-relocs
-Target Var(TARGET_EXPLICIT_RELOCS) Init(1)
+Target Var(TARGET_EXPLICIT_RELOCS) Init(HAVE_AS_EXPLICIT_RELOCS)
 Use %reloc() assembly operators.
 
 ; The code model option names for -mcmodel.
diff --git a/gcc/configure b/gcc/configure
index 62872d132ea..7eb9479ae8e 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -19674,7 +19674,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 19679 "configure"
+#line 19677 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -19780,7 +19780,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 19785 "configure"
+#line 19783 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -28771,7 +28771,7 @@ $as_echo "#define HAVE_AS_MARCH_ZIFENCEI 1" >>confdefs.h
 fi
 
 ;;
-  loongarch*-*-*)
+loongarch*-*-*)
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for 
.dtprelword support" >&5
 $as_echo_n "checking assembler for .dtprelword support... " >&6; }
 if ${gcc_cv_as_loongarch_dtprelword+:} false; then :
@@ -28807,6 +28807,37 @@ if test $gcc_cv_as_loongarch_dtprelword != yes; then
 $as_echo "#define HAVE_AS_DTPRELWORD 1" >>confdefs.h
 
 fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for explicit 
relocation support" >&5
+$as_echo_n "checking assembler for explicit relocation support... " >&6; }

[PATCH 2/2] tree-optimization/105651 - simplify address range overlap check

[Richard Biener via Gcc-patches]

The following adds a pattern for ifcombine to match an address overlap
check and use alias analysis to decide overlap at compile-time.  This
happens with code generated from std::string as shown in the PR even
if meanwhile the trunk generated code causes the pattern to no longer
match.

Bootstrapped and tested on x86_64-unknown-linux-gnu.

PR tree-optimization/105651
* match.pd: Add pattern optimizing address range overlap.

* gcc.dg/tree-ssa/ssa-ifcombine-14.c: New testcase.
---
 gcc/match.pd  | 47 +++
 .../gcc.dg/tree-ssa/ssa-ifcombine-14.c| 18 +++
 2 files changed, 65 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-14.c

diff --git a/gcc/match.pd b/gcc/match.pd
index 330c1db0c8e..7661317a53f 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -7806,6 +7806,53 @@ and,
  { swap_p ? @0 : @2; }))
{ rhs_tree; })
 
+/* Similarly handle
+
+(uint) @A < (uint) @B + @BO & (uint) @B < (uint) @A + @AO
+
+   in particular optimize the case when @A and @B are within distinct
+   objects and all addresses are invariant as happens with std::string
+   in PR105651.  */
+(for cmp1 (lt le le lt)
+ cmp2 (lt le lt le)
+ (simplify
+  (bit_and (cmp1:c (convert@4 @0) (convert @1))
+  (cmp2:c (convert@5 @2) (convert @3)))
+  (with
+   {
+ tree addr0, addr1, addr2, addr3;
+ /* Instead of multiple matchings see to extract a base from the
+   conversion operands since all we need to relate is bases.  */
+ auto get_addr = [] (tree op) -> tree {
+   if (TREE_CODE (op) == ADDR_EXPR)
+ return op;
+   else if (TREE_CODE (op) == SSA_NAME)
+if (gassign *ass = dyn_cast  (SSA_NAME_DEF_STMT (op)))
+  if (gimple_assign_rhs_code (ass) == ADDR_EXPR
+  || gimple_assign_rhs_code (ass) == POINTER_PLUS_EXPR)
+return gimple_assign_rhs1 (ass);
+   return op;
+ };
+   }
+   (if ((addr0 = get_addr (@0))
+   && (addr1 = get_addr (@1))
+   && (addr2 = get_addr (@2))
+   && (addr3 = get_addr (@3))
+   && INTEGRAL_TYPE_P (TREE_TYPE (@4))
+   && types_match (TREE_TYPE (@4), TREE_TYPE (@5)))
+(with { poly_int64 diff0, diff1; }
+ (if (ptr_difference_const (addr3, addr0, )
+ && known_ge (diff0, 0)
+ && ptr_difference_const (addr1, addr2, )
+ && known_ge (diff1, 0)
+ /* Since we are in the end just comparing whether two objects may
+overlap via alias analysis it isn't really important to exactly
+compute the ranges above.  ptr_difference_const mainly determines
+there is a common base and the known_ge is testing we are comparing
+the proper end points.  */
+ && !ptr_derefs_may_alias_p (addr0, addr1))
+  { constant_boolean_node (false, type); }))
+
 /* Fold REDUC (@0 & @1) -> @0[I] & @1[I] if element I is the only nonzero
element of @1.  */
 (for reduc (IFN_REDUC_PLUS IFN_REDUC_IOR IFN_REDUC_XOR)
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-14.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-14.c
new file mode 100644
index 000..f058ac04a36
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-14.c
@@ -0,0 +1,18 @@
+/* From PR105651 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-ifcombine" } */
+
+typedef __UINTPTR_TYPE__ uintptr_t;
+void init (char *a);
+void oops ();
+void foo ()
+{
+  char a[16];
+  init (a);
+  char *p = "foo";
+  if ((uintptr_t)a < (uintptr_t)[4] && (uintptr_t)p < (uintptr_t)[16])
+oops ();
+}
+
+/* { dg-final { scan-tree-dump "optimizing two comparisons to 0" "ifcombine" } 
} */
+/* { dg-final { scan-tree-dump-not "oops" "ifcombine" } } */
-- 
2.35.3

[PATCH 1/2] tree-optimization/105142 - improve maybe_fold_comparisons_from_match_pd fix

[Richard Biener via Gcc-patches]

The following improves on the fix for PR105142 which restricted the
expression lookup used for maybe_fold_comparisons_from_match_pd to
avoid picking up flow-sensitive info for use in places where guarding
conditions do not hold.  Instead of not allowing to expand SSA
definitions there the following temporarily clears flow-sensitive
info on the SSA names and restores it when finished matching.

Bootstrapped and tested on x86_64-unknown-linux-gnu.

PR tree-optimization/105142
* gimple-fold.cc (fosa_unwind): New global.
(follow_outer_ssa_edges): When the SSA definition to follow
is does not dominate fosa_bb, temporarily clear flow-sensitive
info.  Make sure to not expand stmts with not defined overflow.
(maybe_fold_comparisons_from_match_pd): Set up unwind stack
for follow_outer_ssa_edges and unwind flow-sensitive info
clearing after matching.
---
 gcc/gimple-fold.cc | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/gcc/gimple-fold.cc b/gcc/gimple-fold.cc
index a1704784bc9..14640f6952a 100644
--- a/gcc/gimple-fold.cc
+++ b/gcc/gimple-fold.cc
@@ -6886,6 +6886,7 @@ and_comparisons_1 (tree type, enum tree_code code1, tree 
op1a, tree op1b,
 }
 
 static basic_block fosa_bb;
+static vec > *fosa_unwind;
 static tree
 follow_outer_ssa_edges (tree val)
 {
@@ -6899,7 +6900,21 @@ follow_outer_ssa_edges (tree val)
  && (def_bb == fosa_bb
  || dominated_by_p (CDI_DOMINATORS, fosa_bb, def_bb
return val;
-  return NULL_TREE;
+  /* We cannot temporarily rewrite stmts with undefined overflow
+behavior, so avoid expanding them.  */
+  if ((ANY_INTEGRAL_TYPE_P (TREE_TYPE (val))
+  || POINTER_TYPE_P (TREE_TYPE (val)))
+ && !TYPE_OVERFLOW_WRAPS (TREE_TYPE (val)))
+   return NULL_TREE;
+  /* If the definition does not dominate fosa_bb temporarily reset
+flow-sensitive info.  */
+  if (val->ssa_name.info.range_info)
+   {
+ fosa_unwind->safe_push (std::make_pair
+   (val, val->ssa_name.info.range_info));
+ val->ssa_name.info.range_info = NULL;
+   }
+  return val;
 }
   return val;
 }
@@ -6958,9 +6973,14 @@ maybe_fold_comparisons_from_match_pd (tree type, enum 
tree_code code,
  type, gimple_assign_lhs (stmt1),
  gimple_assign_lhs (stmt2));
   fosa_bb = outer_cond_bb;
+  auto_vec, 8> unwind_stack;
+  fosa_unwind = _stack;
   if (op.resimplify (NULL, (!outer_cond_bb
? follow_all_ssa_edges : follow_outer_ssa_edges)))
 {
+  fosa_unwind = NULL;
+  for (auto p : unwind_stack)
+   p.first->ssa_name.info.range_info = p.second;
   if (gimple_simplified_result_is_gimple_val ())
{
  tree res = op.ops[0];
@@ -6982,6 +7002,9 @@ maybe_fold_comparisons_from_match_pd (tree type, enum 
tree_code code,
  return build2 ((enum tree_code)op.code, op.type, op0, op1);
}
 }
+  fosa_unwind = NULL;
+  for (auto p : unwind_stack)
+p.first->ssa_name.info.range_info = p.second;
 
   return NULL_TREE;
 }
-- 
2.35.3

Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support

[Lulu Cheng]

在 2022/7/26 下午8:01, Xi Ruoyao 写道:

On Tue, 2022-07-26 at 19:42 +0800, Lulu Cheng wrote:


在 2022/7/26 下午5:44, Xi Ruoyao 写道:

+  whether the la.* macro instructions will be generated when
+  loading symbolic addresses.
+  This feature requires binutils version 2.40 or later. If you want to use the
+  older version of bintuils, add compiler parameters
+  -mno-explicit-relocs at compile time.

Does it mean we need to make sure GCC 13 released after binutils-2.40?
binutils-2.39 release branch is already created and it's now explicitly
"no new feature" so a backport seems impossible...

Do you think it's okay if we don't write Binutils version restrictions
now and wait until Binutils code is released to annotate?

I think you can just put Binutils 2.40 here.  GCC 13 will be released in
Apr or May 2023, and Binutils-2.40 will be released in Jan or Feb 2023
(if no bad thing happens), so my previous concern is actually not a
problem.

Maybe we can add a check in gcc/configure.ac to see if gcc_cv_ld
supports %got_pc_hi20 and adjust the default for -m[no]-explicit-relocs?


I think this is a good way, I'll look at adding a check.


Should we indicate that our .eh_frame section format has changed?

I don't really understand C++ exception handling, so: does the change
breaks something?  For example, if foo links to libbar, libbar is built
with GCC 12 (or vice versa), would an exception thrown from libbar
properly caught by foo?

Generally changes.html is for compiler users (instead of developers),
and I believe at least 90% of users (including I) don't know the
potential consequences from a .eh_frame format change.  So it's better
to describe the breakage and possible workaround here.  If nothing will
be broken, we can just skip the change in changes.html.



I'm looking to see if I can find a test that can verify the

compatibility or incompatibility before and after the modification.


Thanks!:-)

Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support

[Lulu Cheng]

在 2022/7/26 下午7:32, Gerald Pfeifer 写道:

On Tue, 26 Jul 2022, Lulu Cheng wrote:

+LoongArch
+
+  The option -mexplicit-relocs has been added, this indicates
+  whether the la.* macro instructions will be generated when
+  loading symbolic addresses.

How about making this "...has been added. It indicates..." or, if you
prefer one sentence "...has been added to indicate whether"?


+  This feature requires binutils version 2.40 or later. If you want to use the
+  older version of bintuils, add compiler parameters
+  -mno-explicit-relocs at compile time.

"...older versions..." (or "...an older version...")

And I believe we can simplify and just say "...add -mno-explicit..."


+  The method for calling global functions changed from
+  la.global + jirl to bl when complied add
+  -fplt.

Do you mean "compiled" instead of "complied"?

And maybe "compiled with"?


+  Enable option -fsection-anchors when -O1 and
+  more advanced optimization.

How about "-fsection-anchors is now enabled with
-O1 and above"?


If my suggestions make sense to you, please go ahead and commit with those
or variations thereof you may prefer.

If you have any questions, please let me know and we'll sort things out
quickly.

Thank you,
Gerald


Thanks a lot, I will fix it soon. Lulu Cheng

Re: [PATCH] contrib: use sphinx-build from a venv

[Martin Liška]

On 7/26/22 14:01, Jonathan Wakely via Gcc-patches wrote:
> On Tue, 26 Jul 2022 at 12:56, Frank Ch. Eigler wrote:
>>
>> Hi -
>>
 The gccadmin team can do this kind of thing without overseer/root
 privileges, or indeed so can any local shell-privileged user.
>>>
>>> Yeah, I said I didn't want to install it that way without overseer
>>> approval, as pip won't keep the packages up to date the way dnf
>>> installations do.
>>
>> Indeed, but that's your own preference/responsibility and does not
>> affect the system, so no overseer oversight is necessary.
> 
> OK, I can install it for Martin then.

Thanks Jonathan.

> 
 (That said, rhel8 includes sphynx 1.7.6 - are you sure that's
 not satisfactory?)
>>>
>>> That's a different package (full text search engine), what's needed
>>> here is python3-sphinx.
>>
>> # rpm -q python3-sphinx
>> python3-sphinx-1.7.6-2.el8.noarch
> 
> Oh right, yes, sorry, I got confused after I looked into the packages
> myself. The "other sphinx" is in EPEL 8 as sphinx-2.2.11-15.el8

Sorry, but it's too old, we actually need a release that was released this week 
;)
(5.1.0).

Thanks,
Martin

[PATCH] Add new target hook: simplify_modecc_const.

[Roger Sayle]

This patch is a major revision of the patch I originally proposed here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598040.html

The primary motivation of this patch is to avoid incorrect optimization
of MODE_CC comparisons in simplify_const_relational_operation when/if a
backend represents the (known) contents of a MODE_CC register using a
CONST_INT.  In such cases, the RTL optimizers don't know the semantics
of this integer value, so shouldn't change anything (i.e. should return
NULL_RTX from simplify_const_relational_operation).

The secondary motivation is that by introducing a new target hook, called
simplify_modecc_const, the backend can (optionally) encode and interpret
a target dependent encoding of MODE_CC registers.

The worked example provided with this patch is to allow the i386 backend
to explicitly model the carry flag (MODE_CCC) using 1 to indicate that
the carry flag is set, and 0 to indicate the carry flag is clear.  This
allows the instructions stc (set carry flag), clc (clear carry flag) and
cmc (complement carry flag) to be represented in RTL.

However an even better example would be the rs6000 backend, where this
patch/target hook would allow improved modelling of the condition register
CR.  The powerpc's comparison instructions set fields/bits in the CR
register [where bit 0 indicates less than, bit 1 greater than, bit 2
equal to and bit3 overflow] analogous to x86's flags register [containing
bits for carry, zero, overflow, parity etc.].  These fields can be
manipulated directly using crset (aka creqv) and crclr (aka crxor)
instructions and even transferred from general purpose registers using
mtcr.  However, without a patch like this, it's impossible to safely
model/represent these instructions in rs6000.md.

This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32},
and both with and without a patch to add stc, clc and cmc support to
the x86 backend.  I'll resubmit the x86 target pieces again with that
follow-up backend patch, so for now I'm only looking for approval
of the middle-end infrastructure pieces.  The x86 hunks below are
provided as context/documentation for how this hook could/should be
used (but I wouldn't object to pre-approval of those bits by Uros).
Ok for mainline?


2022-07-26  Roger Sayle  

gcc/ChangeLog
* target.def (simplify_modecc_const): New target hook.
* doc/tm.texi (TARGET_SIMPLIFY_MODECC_CONST): Document here.
* doc/tm.texi.in (TARGET_SIMPLIFY_MODECC_CONST): Locate @hook here.
* hooks.cc (hook_rtx_mode_int_rtx_null): Define default hook here.
* hooks.h (hook_rtx_mode_int_rtx_null): Prototype here.
* simplify-rtx.c (simplify_const_relational_operation): Avoid
mis-optimizing MODE_CC comparisons by calling new target hook.

* config/i386.cc (ix86_simplify_modecc_const): Implement new target
hook, supporting interpreting MODE_CCC values as the x86 carry flag.
(TARGET_SIMPLIFY_MODECC_CONST): Define as
ix86_simplify_modecc_const.


Thanks in advance,
Roger
--

> -Original Message-
> From: Segher Boessenkool 
> Sent: 07 July 2022 23:39
> To: Roger Sayle 
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] Be careful with MODE_CC in
> simplify_const_relational_operation.
> 
> Hi!
> 
> On Thu, Jul 07, 2022 at 10:08:04PM +0100, Roger Sayle wrote:
> > I think it's fair to describe RTL's representation of condition flags
> > using MODE_CC as a little counter-intuitive.
> 
> "A little challenging", and you should see that as a good thing, as a
puzzle to
> crack :-)
> 
> > For example, the i386
> > backend represents the carry flag (in adc instructions) using RTL of
> > the form "(ltu:SI (reg:CCC) (const_int 0))", where great care needs to
> > be taken not to treat this like a normal RTX expression, after all LTU
> > (less-than-unsigned) against const0_rtx would normally always be
> > false.
> 
> A comparison of a MODE_CC thing against 0 means the result of a
> *previous* comparison (or other cc setter) is looked at.  Usually it
simply looks
> at some condition bits in a flags register.  It does not do any actual
comparison:
> that has been done before (if at all even).
> 
> > Hence, MODE_CC comparisons need to be treated with caution, and
> > simplify_const_relational_operation returns early (to avoid
> > problems) when GET_MODE_CLASS (GET_MODE (op0)) == MODE_CC.
> 
> Not just to avoid problems: there simply isn't enough information to do a
> correct job.
> 
> > However, consider the (currently) hypothetical situation, where the
> > RTL optimizers determine that a previous instruction unconditionally
> > sets or clears the carry flag, and this gets propagated by combine
> > into the above expression, we'd end up with something that looks like
> > (ltu:SI (const_int 1) (const_int 0)), which doesn't mean what it says.
> > Fortunately, simplify_const_relational_operation is passed the
> > 

Re: [PATCH] contrib: use sphinx-build from a venv

[Jonathan Wakely via Gcc-patches]

On Tue, 26 Jul 2022 at 12:56, Frank Ch. Eigler wrote:
>
> Hi -
>
> > > The gccadmin team can do this kind of thing without overseer/root
> > > privileges, or indeed so can any local shell-privileged user.
> >
> > Yeah, I said I didn't want to install it that way without overseer
> > approval, as pip won't keep the packages up to date the way dnf
> > installations do.
>
> Indeed, but that's your own preference/responsibility and does not
> affect the system, so no overseer oversight is necessary.

OK, I can install it for Martin then.

> > > (That said, rhel8 includes sphynx 1.7.6 - are you sure that's
> > > not satisfactory?)
> >
> > That's a different package (full text search engine), what's needed
> > here is python3-sphinx.
>
> # rpm -q python3-sphinx
> python3-sphinx-1.7.6-2.el8.noarch

Oh right, yes, sorry, I got confused after I looked into the packages
myself. The "other sphinx" is in EPEL 8 as sphinx-2.2.11-15.el8

Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support

[Xi Ruoyao via Gcc-patches]

On Tue, 2022-07-26 at 19:42 +0800, Lulu Cheng wrote:

> 在 2022/7/26 下午5:44, Xi Ruoyao 写道:
> > 
> > > +  whether the la.* macro instructions will be generated when
> > > +  loading symbolic addresses.
> > > +  This feature requires binutils version 2.40 or later. If you want to 
> > > use the
> > > +  older version of bintuils, add compiler parameters
> > > +  -mno-explicit-relocs at compile time.
> > Does it mean we need to make sure GCC 13 released after binutils-2.40?
> > binutils-2.39 release branch is already created and it's now explicitly
> > "no new feature" so a backport seems impossible...
> 
> Do you think it's okay if we don't write Binutils version restrictions
> now and wait until Binutils code is released to annotate?

I think you can just put Binutils 2.40 here.  GCC 13 will be released in
Apr or May 2023, and Binutils-2.40 will be released in Jan or Feb 2023
(if no bad thing happens), so my previous concern is actually not a
problem.

Maybe we can add a check in gcc/configure.ac to see if gcc_cv_ld
supports %got_pc_hi20 and adjust the default for -m[no]-explicit-relocs?

> 
> Should we indicate that our .eh_frame section format has changed?

I don't really understand C++ exception handling, so: does the change
breaks something?  For example, if foo links to libbar, libbar is built
with GCC 12 (or vice versa), would an exception thrown from libbar
properly caught by foo?

Generally changes.html is for compiler users (instead of developers),
and I believe at least 90% of users (including I) don't know the
potential consequences from a .eh_frame format change.  So it's better
to describe the breakage and possible workaround here.  If nothing will
be broken, we can just skip the change in changes.html.


-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Re: [PATCH] contrib: use sphinx-build from a venv

[Frank Ch. Eigler via Gcc-patches]

Hi -

> > The gccadmin team can do this kind of thing without overseer/root
> > privileges, or indeed so can any local shell-privileged user.
> 
> Yeah, I said I didn't want to install it that way without overseer
> approval, as pip won't keep the packages up to date the way dnf
> installations do.

Indeed, but that's your own preference/responsibility and does not
affect the system, so no overseer oversight is necessary.

> > (That said, rhel8 includes sphynx 1.7.6 - are you sure that's
> > not satisfactory?)
> 
> That's a different package (full text search engine), what's needed
> here is python3-sphinx.

# rpm -q python3-sphinx
python3-sphinx-1.7.6-2.el8.noarch


- FChE

Re: [PATCH] contrib: use sphinx-build from a venv

[Jonathan Wakely via Gcc-patches]

On Tue, 26 Jul 2022 at 12:45, Frank Ch. Eigler  wrote:
>
> Hi -
>
> > CCing overseers and Frank.
> > Can you please help me with that?
>
> > > Can please a maintainer install the package from pip?
> > > Something like:
> > > virtualenv /home/gcc/venv && /home/gcc/venv/bin/pip install Sphinx
> > > or a similar location?
>
> The gccadmin team can do this kind of thing without overseer/root
> privileges, or indeed so can any local shell-privileged user.

Yeah, I said I didn't want to install it that way without overseer
approval, as pip won't keep the packages up to date the way dnf
installations do.

> (That said, rhel8 includes sphynx 1.7.6 - are you sure that's
> not satisfactory?)

That's a different package (full text search engine), what's needed
here is python3-sphinx.

Re: [PATCH] contrib: use sphinx-build from a venv

[Frank Ch. Eigler via Gcc-patches]

Hi -

> CCing overseers and Frank.
> Can you please help me with that?

> > Can please a maintainer install the package from pip?
> > Something like:
> > virtualenv /home/gcc/venv && /home/gcc/venv/bin/pip install Sphinx
> > or a similar location?

The gccadmin team can do this kind of thing without overseer/root
privileges, or indeed so can any local shell-privileged user.

(That said, rhel8 includes sphynx 1.7.6 - are you sure that's
not satisfactory?)

- FChE

Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support

[Lulu Cheng]

在 2022/7/26 下午5:44, Xi Ruoyao 写道:



+  whether the la.* macro instructions will be generated when
+  loading symbolic addresses.
+  This feature requires binutils version 2.40 or later. If you want to use the
+  older version of bintuils, add compiler parameters
+  -mno-explicit-relocs at compile time.

Does it mean we need to make sure GCC 13 released after binutils-2.40?
binutils-2.39 release branch is already created and it's now explicitly
"no new feature" so a backport seems impossible...


Do you think it's okay if we don't write Binutils version restrictions 
now and wait until Binutils code is released to annotate?



+  
+  The method for calling global functions changed from
+  la.global + jirl to bl when complied add
+  -fplt.

"from la.global + jirl to bl with -fno-plt and -mexplicit-relocs"?  With
"-fplt" GCC 12 is already using bl, and with -mno-explicit-relocs
la.global is still used (if I read func-call-3.c correctly).

I  should put '-fplt -mexplicit-relocs' here.

+  Changed ASM_PREFERRED_EH_DATA_FORMAT macro definition from
+  WD_EH_PE_absptr to WD_EH_PE_pcrel | 
DW_EH_PE_sdata4.
+  

I don't think this paragraph is necessary because this change is purely
internal.


Should we indicate that our .eh_frame section format has changed?


Thanks!

Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support

[Gerald Pfeifer]

On Tue, 26 Jul 2022, Lulu Cheng wrote:
> +LoongArch
> +
> +  The option -mexplicit-relocs has been added, this 
> indicates
> +  whether the la.* macro instructions will be generated when
> +  loading symbolic addresses.

How about making this "...has been added. It indicates..." or, if you
prefer one sentence "...has been added to indicate whether"?

> +  This feature requires binutils version 2.40 or later. If you want to use 
> the
> +  older version of bintuils, add compiler parameters
> +  -mno-explicit-relocs at compile time.

"...older versions..." (or "...an older version...")

And I believe we can simplify and just say "...add -mno-explicit..."

> +  The method for calling global functions changed from
> +  la.global + jirl to bl when complied add
> +  -fplt.

Do you mean "compiled" instead of "complied"?

And maybe "compiled with"?

> +  Enable option -fsection-anchors when -O1 and
> +  more advanced optimization.

How about "-fsection-anchors is now enabled with 
-O1 and above"?


If my suggestions make sense to you, please go ahead and commit with those
or variations thereof you may prefer. 

If you have any questions, please let me know and we'll sort things out
quickly.

Thank you,
Gerald

[PATCH] tree-optimization/105142 - improve maybe_fold_comparisons_from_match_pd fix

[Richard Biener via Gcc-patches]

The following improves on the fix for PR105142 which restricted the
expression lookup used for maybe_fold_comparisons_from_match_pd to
avoid picking up flow-sensitive info for use in places where guarding
conditions do not hold.  Instead of not allowing to expand SSA
definitions there the following temporarily clears flow-sensitive
info on the SSA names and restores it when finished matching.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

PR tree-optimization/105142
* gimple-fold.cc (fosa_unwind): New global.
(follow_outer_ssa_edges): When the SSA definition to follow
is does not dominate fosa_bb, temporarily clear flow-sensitive
info.
(maybe_fold_comparisons_from_match_pd): Set up unwind stack
for follow_outer_ssa_edges and unwind flow-sensitive info
clearing after matching.
---
 gcc/gimple-fold.cc | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/gcc/gimple-fold.cc b/gcc/gimple-fold.cc
index a1704784bc9..876ef45434e 100644
--- a/gcc/gimple-fold.cc
+++ b/gcc/gimple-fold.cc
@@ -6886,6 +6886,7 @@ and_comparisons_1 (tree type, enum tree_code code1, tree 
op1a, tree op1b,
 }
 
 static basic_block fosa_bb;
+static vec > *fosa_unwind;
 static tree
 follow_outer_ssa_edges (tree val)
 {
@@ -6899,7 +6900,15 @@ follow_outer_ssa_edges (tree val)
  && (def_bb == fosa_bb
  || dominated_by_p (CDI_DOMINATORS, fosa_bb, def_bb
return val;
-  return NULL_TREE;
+  /* If the definition does not dominate fosa_bb temporarily reset
+flow-sensitive info.  */
+  if (val->ssa_name.info.range_info)
+   {
+ fosa_unwind->safe_push (std::make_pair
+   (val, val->ssa_name.info.range_info));
+ val->ssa_name.info.range_info = NULL;
+   }
+  return val;
 }
   return val;
 }
@@ -6958,9 +6967,14 @@ maybe_fold_comparisons_from_match_pd (tree type, enum 
tree_code code,
  type, gimple_assign_lhs (stmt1),
  gimple_assign_lhs (stmt2));
   fosa_bb = outer_cond_bb;
+  auto_vec, 8> unwind_stack;
+  fosa_unwind = _stack;
   if (op.resimplify (NULL, (!outer_cond_bb
? follow_all_ssa_edges : follow_outer_ssa_edges)))
 {
+  fosa_unwind = NULL;
+  for (auto p : unwind_stack)
+   p.first->ssa_name.info.range_info = p.second;
   if (gimple_simplified_result_is_gimple_val ())
{
  tree res = op.ops[0];
@@ -6982,6 +6996,9 @@ maybe_fold_comparisons_from_match_pd (tree type, enum 
tree_code code,
  return build2 ((enum tree_code)op.code, op.type, op0, op1);
}
 }
+  fosa_unwind = NULL;
+  for (auto p : unwind_stack)
+p.first->ssa_name.info.range_info = p.second;
 
   return NULL_TREE;
 }
-- 
2.35.3

[COMMITTED] [106444] Handle non constant ranges in irange pretty printer.

[Aldy Hernandez via Gcc-patches]

Technically iranges only exist in constant form, but we allow symbolic
ones before arriving in the ranger, so legacy VRP can work.  This fixes the
ICE when attempting to print symbolic iranges in the pretty printer.

For consistency's sake, I have made sure irange::get_nonzero_bits does
not similarly ICE on a symbolic range, even though no one should be
querying nonzero bits on such a range.  This should all melt away
when legacy disappears, because all these methods are slated for
removal (min, max, kind, symbolic_p, constant_p, etc).

Finally, Richi suggested using pp_wide_int in the pretty printer
instead of going through trees.  I've adapted a test, since
dump_generic_node seems to work slightly different.

PR tree-optimization/106444

gcc/ChangeLog:

* value-range-pretty-print.cc (vrange_printer::visit): Handle
legacy ranges.
(vrange_printer::print_irange_bound): Work on wide_int's.
* value-range-pretty-print. (print_irange_bound): Same.
* value-range.cc (irange::get_nonzero_bits): Handle legacy ranges.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/evrp4.c: Adjust.
---
 gcc/testsuite/gcc.dg/tree-ssa/evrp4.c |  2 +-
 gcc/value-range-pretty-print.cc   | 33 ---
 gcc/value-range-pretty-print.h|  2 +-
 gcc/value-range.cc|  8 +++
 4 files changed, 30 insertions(+), 15 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/evrp4.c 
b/gcc/testsuite/gcc.dg/tree-ssa/evrp4.c
index e3f4531b16c..895109fdadd 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/evrp4.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/evrp4.c
@@ -17,4 +17,4 @@ int bar (struct st *s)
   foo (>a);
 }
 
-/* { dg-final { scan-tree-dump "\\\[1B, \\+INF\\\]" "evrp" } } */
+/* { dg-final { scan-tree-dump "\\\[1, \\+INF\\\]" "evrp" } } */
diff --git a/gcc/value-range-pretty-print.cc b/gcc/value-range-pretty-print.cc
index 485612fe67c..cbf50d3d854 100644
--- a/gcc/value-range-pretty-print.cc
+++ b/gcc/value-range-pretty-print.cc
@@ -63,38 +63,45 @@ vrange_printer::visit (const irange ) const
   pp_string (pp, "VARYING");
   return;
 }
- for (unsigned i = 0; i < r.num_pairs (); ++i)
+  // Handle legacy symbolics.
+  if (!r.constant_p ())
 {
-  tree lb = wide_int_to_tree (r.type (), r.lower_bound (i));
-  tree ub = wide_int_to_tree (r.type (), r.upper_bound (i));
+  if (r.kind () == VR_ANTI_RANGE)
+   pp_character (pp, '~');
   pp_character (pp, '[');
-  print_irange_bound (lb);
+  dump_generic_node (pp, r.min (), 0, TDF_NONE, false);
   pp_string (pp, ", ");
-  print_irange_bound (ub);
+  dump_generic_node (pp, r.max (), 0, TDF_NONE, false);
+  pp_character (pp, ']');
+  print_irange_bitmasks (r);
+  return;
+}
+  for (unsigned i = 0; i < r.num_pairs (); ++i)
+{
+  pp_character (pp, '[');
+  print_irange_bound (r.lower_bound (i), r.type ());
+  pp_string (pp, ", ");
+  print_irange_bound (r.upper_bound (i), r.type ());
   pp_character (pp, ']');
 }
  print_irange_bitmasks (r);
 }
 
 void
-vrange_printer::print_irange_bound (tree bound) const
+vrange_printer::print_irange_bound (const wide_int , tree type) const
 {
-  tree type = TREE_TYPE (bound);
   wide_int type_min = wi::min_value (TYPE_PRECISION (type), TYPE_SIGN (type));
   wide_int type_max = wi::max_value (TYPE_PRECISION (type), TYPE_SIGN (type));
 
   if (INTEGRAL_TYPE_P (type)
   && !TYPE_UNSIGNED (type)
-  && TREE_CODE (bound) == INTEGER_CST
-  && wi::to_wide (bound) == type_min
+  && bound == type_min
   && TYPE_PRECISION (type) != 1)
 pp_string (pp, "-INF");
-  else if (TREE_CODE (bound) == INTEGER_CST
-  && wi::to_wide (bound) == type_max
-  && TYPE_PRECISION (type) != 1)
+  else if (bound == type_max && TYPE_PRECISION (type) != 1)
 pp_string (pp, "+INF");
   else
-dump_generic_node (pp, bound, 0, TDF_NONE, false);
+pp_wide_int (pp, bound, TYPE_SIGN (type));
 }
 
 void
diff --git a/gcc/value-range-pretty-print.h b/gcc/value-range-pretty-print.h
index c1c7c4244cc..ad06c93c044 100644
--- a/gcc/value-range-pretty-print.h
+++ b/gcc/value-range-pretty-print.h
@@ -29,7 +29,7 @@ public:
   void visit (const irange &) const override;
   void visit (const frange &) const override;
 private:
-  void print_irange_bound (tree bound) const;
+  void print_irange_bound (const wide_int , tree type) const;
   void print_irange_bitmasks (const irange &) const;
   void print_frange_prop (const char *str, const fp_prop &) const;
 
diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index e49b06d1038..2923f4f5a0e 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -2593,6 +2593,14 @@ irange::get_nonzero_bits () const
 {
   gcc_checking_assert (!undefined_p ());
 
+  // In case anyone in the legacy world queries us.
+  if (!constant_p ())
+{
+  if (m_nonzero_mask)
+   return wi::to_wide (m_nonzero_mask);
+  return wi::shwi (-1, 

[PATCH] Improve ptr_derefs_may_alias_p for the case of _CST

[Richard Biener via Gcc-patches]

When the first pointer happens to be a pointer to a STRING_CST we
give up too early since the 2nd pointer handling could still end
up with a DECL for example which can disambiguate against a STRING_CST
just fine.

Boostrapped and tested on x86_64-unknown-linux-gnu, pushed.

* tree-ssa-alias.cc (ptr_derefs_may_alias_p): If ptr1
points to a constant continue checking ptr2.
---
 gcc/tree-ssa-alias.cc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gcc/tree-ssa-alias.cc b/gcc/tree-ssa-alias.cc
index 390cd875074..b4c65da5718 100644
--- a/gcc/tree-ssa-alias.cc
+++ b/gcc/tree-ssa-alias.cc
@@ -349,7 +349,9 @@ ptr_derefs_may_alias_p (tree ptr1, tree ptr2)
   else if (base
   && DECL_P (base))
return ptr_deref_may_alias_decl_p (ptr2, base);
-  else
+  /* Try ptr2 when ptr1 points to a constant.  */
+  else if (base
+  && !CONSTANT_CLASS_P (base))
return true;
 }
   if (TREE_CODE (ptr2) == ADDR_EXPR)
-- 
2.35.3

[RFC] Teach vectorizer to deal with bitfield reads

[Andre Vieira (lists) via Gcc-patches]

Hi,

This is a RFC for my prototype for bitfield read vectorization. This 
patch enables bit-field read vectorization by removing the rejection of 
bit-field read's during DR analysis and by adding two vect patterns. The 
first one transforms TREE_COMPONENT's with BIT_FIELD_DECL's into 
BIT_FIELD_REF's, this is a temporary one as I believe there are plans to 
do this lowering earlier in the compiler. To avoid having to wait for 
that to happen we decided to implement this temporary vect pattern.
The second one looks for conversions of the result of BIT_FIELD_REF's 
from a 'partial' type to a 'full-type' and transforms it into a 
'full-type' load followed by the necessary shifting and masking.


The patch is not perfect, one thing I'd like to change for instance is 
the way the 'full-type' load is represented. I currently abuse the fact 
that the vectorizer transforms the original TREE_COMPONENT with a 
BIT_FIELD_DECL into a full-type vector load, because it uses the 
smallest mode necessary for that precision. The reason I do this is 
because I was struggling to construct a MEM_REF that the vectorizer 
would accept and this for some reason seemed to work ... I'd appreciate 
some pointers on how to do this properly :)


Another aspect that I haven't paid much attention to yet is costing, 
I've noticed some testcases fail to vectorize due to costing where I 
think it might be wrong, but like I said, I haven't paid much attention 
to it.


Finally another aspect I'd eventually like to tackle is the sinking of 
the masking when possible, for instance in bit-field-read-3.c the 
'masking' does not need to be inside the loop because we are doing 
bitwise operations. Though I suspect we are better off looking at things 
like this elsewhere, maybe where we do codegen for the reduction... 
Haven't looked at this at all yet.


Let me know if you believe this is a good approach? I've ran regression 
tests and this hasn't broken anything so far...


Kind regards,
Andre

PS: Once we do have lowering of BIT_FIELD_DECL's to BIT_FIELD_REF's 
earlier in the compiler I suspect we will require some further changes 
to the DR analysis part, but that's difficult to test right now.
diff --git a/gcc/testsuite/gcc.dg/vect/bitfield-read-1.c 
b/gcc/testsuite/gcc.dg/vect/bitfield-read-1.c
new file mode 100644
index 
..c30aad365c40474109748bd03c3a5ca1d10723ed
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/bitfield-read-1.c
@@ -0,0 +1,38 @@
+/* { dg-require-effective-target vect_int } */
+
+#include 
+#include "tree-vect.h"
+
+extern void abort(void);
+
+struct s { int i : 31; };
+
+#define ELT0 {0}
+#define ELT1 {1}
+#define ELT2 {2}
+#define ELT3 {3}
+#define RES 48
+struct s A[N]
+  = { ELT0, ELT1, ELT2, ELT3, ELT0, ELT1, ELT2, ELT3,
+  ELT0, ELT1, ELT2, ELT3, ELT0, ELT1, ELT2, ELT3,
+  ELT0, ELT1, ELT2, ELT3, ELT0, ELT1, ELT2, ELT3,
+  ELT0, ELT1, ELT2, ELT3, ELT0, ELT1, ELT2, ELT3};
+
+int f(struct s *ptr, unsigned n) {
+int res = 0;
+for (int i = 0; i < n; ++i)
+  res += ptr[i].i;
+return res;
+}
+
+int main (void)
+{
+  check_vect ();
+
+  if (f([0], N) != RES)
+abort ();
+
+  return 0;
+}
+
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */
diff --git a/gcc/testsuite/gcc.dg/vect/bitfield-read-2.c 
b/gcc/testsuite/gcc.dg/vect/bitfield-read-2.c
new file mode 100644
index 
..ab82ff347c55e78d098d194d739bcd9d7737f777
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/bitfield-read-2.c
@@ -0,0 +1,42 @@
+/* { dg-require-effective-target vect_int } */
+
+#include 
+#include "tree-vect.h"
+
+extern void abort(void);
+
+struct s {
+unsigned i : 31;
+char a : 4;
+};
+
+#define N 32
+#define ELT0 {0x7FFFUL, 0}
+#define ELT1 {0x7FFFUL, 1}
+#define ELT2 {0x7FFFUL, 2}
+#define ELT3 {0x7FFFUL, 3}
+#define RES 48
+struct s A[N]
+  = { ELT0, ELT1, ELT2, ELT3, ELT0, ELT1, ELT2, ELT3,
+  ELT0, ELT1, ELT2, ELT3, ELT0, ELT1, ELT2, ELT3,
+  ELT0, ELT1, ELT2, ELT3, ELT0, ELT1, ELT2, ELT3,
+  ELT0, ELT1, ELT2, ELT3, ELT0, ELT1, ELT2, ELT3};
+
+int f(struct s *ptr, unsigned n) {
+int res = 0;
+for (int i = 0; i < n; ++i)
+  res += ptr[i].a;
+return res;
+}
+
+int main (void)
+{
+  check_vect ();
+
+  if (f([0], N) != RES)
+abort ();
+
+  return 0;
+}
+
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */
diff --git a/gcc/testsuite/gcc.dg/vect/bitfield-read-3.c 
b/gcc/testsuite/gcc.dg/vect/bitfield-read-3.c
new file mode 100644
index 
..216611a29fd8bbfbafdbdb79d790e520f44ba672
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/bitfield-read-3.c
@@ -0,0 +1,43 @@
+/* { dg-require-effective-target vect_int } */
+
+#include 
+#include "tree-vect.h"
+#include 
+
+extern void abort(void);
+
+typedef struct {
+int  c;
+int  b;
+bool a : 1;
+} struct_t;
+
+#define N 16
+#define ELT_F { 0x, 0x, 

Re: [PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support

[Xi Ruoyao via Gcc-patches]

+Xuerui (his English is much better than mine).

On Tue, 2022-07-26 at 15:21 +0800, Lulu Cheng wrote:
> Hi,
>   Recently we added split symbol support, changed in r13-1834.
>   It is ok for wwwdocs?

> +LoongArch
> +
> +  The option -mexplicit-relocs has been added, this indicate

I think "added and enabled by default" would be better.

> +  whether the la.* macro instructions will be generated when
> +  loading symbolic addresses.
> +  This feature requires binutils version 2.40 or later. If you want to use 
> the
> +  older version of bintuils, add compiler parameters
> +  -mno-explicit-relocs at compile time.

Does it mean we need to make sure GCC 13 released after binutils-2.40? 
binutils-2.39 release branch is already created and it's now explicitly
"no new feature" so a backport seems impossible...

> +  
> +  The method for calling global functions changed from
> +  la.global + jirl to bl when complied add
> +  -fplt.

"from la.global + jirl to bl with -fno-plt and -mexplicit-relocs"?  With
"-fplt" GCC 12 is already using bl, and with -mno-explicit-relocs
la.global is still used (if I read func-call-3.c correctly).

> +  Enable option -fsection-anchors when -O1 and
> +  more advanced optimization.

"-fsection-anchors is enabled by default at -O1 and higher
optimization levels for better code generation".

> +  Changed ASM_PREFERRED_EH_DATA_FORMAT macro definition from
> +  WD_EH_PE_absptr to WD_EH_PE_pcrel | 
> DW_EH_PE_sdata4. 
> +  

I don't think this paragraph is necessary because this change is purely
internal.

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Rainer Orth]

Hi Gaius,

> Rainer Orth  writes:
>
>>> I think this just leaves:
>>>
 * While this lets the build finish on all of i386-pc-solaris2.11,
   sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu, I get thousands of
   testsuite failures, all of the same kind:

 Undefined   first referenced
  symbol in file
 RTco_signal 
 /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
 RTco_select 
 /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
 RTco_initSemaphore  
 /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
 RTco_wait   
 /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
 ld: fatal: symbol referencing errors
 collect2: error: ld returned 1 exit status
 compiler exited with status 1
 FAIL: gm2/exceptions/run/pass/libexcept.mod compilation,  -g

   I haven't yet tried to fix those.
>>>
>>> which I'll try and reproduce,
>>
>> Excellent.  I've also seen this one on Linux/x86_64, so this isn't a
>> Solaris-specific issue.
>
> Hi Rainer,
>
> I think these are now fixed

indeed, thanks.

However, there are still a couple of issues with the branch:

* There's an unresolved merge conflict in toplevel Makefile.in.

* Bootstrap on i386-pc-solaris2.11 initially fails with

/vol/gcc/src/hg/master/modula-2/gcc/gcc.cc: In function 'void 
print_option(const char*, unsigned int, cl_decoded_option*)':
/vol/gcc/src/hg/master/modula-2/gcc/gcc.cc:4805:46: error: format '%ld' expects 
argument of type 'long int', but argument 2 has type 'std::size_t' {aka 
'unsigned int'} [-Werror=format=]
 4805 |   printf (" canonical_option_num_elements [%ld]\n",
  |~~^
  |  |
  |  long int
  |%d
 4806 |   in_decoded_options[i].canonical_option_num_elements);
  |   ~~~
  | |
  | std::size_t {aka unsigned int}

  Fixed by the attached patch.

* The libgm2 build fails with

make[5]: *** No rule to make target 'KeyBoardLEDs.c', needed by 
'KeyBoardLEDs.lo'.  Stop.

  While libgm2/libm2cor/Makefile.am had been updated for the rename, the
  corresponding Makefile.in hasn't.  Besides, the Makefile.in's are
  still generated with a distribution-patched automake (which supports
  runstatedir).  This makes it unnecessarily hard to check if
  everything's ok if you have to update Makefile.am's and run automake
  locally afterwards.

That said, results are pretty good:

* i386-pc-solaris2.11:

=== gm2 Summary for unix ===

# of expected passes11650
# of unexpected failures14

=== gm2 Summary for unix/-m64 ===

# of expected passes11647
# of unexpected failures17

=== gm2 Summary ===

# of expected passes23297
# of unexpected failures31

* amd64-pc-solaris2.11:

=== gm2 Summary for unix ===

# of expected passes11658
# of unexpected failures6

=== gm2 Summary for unix/-m32 ===

# of expected passes11650
# of unexpected failures14

=== gm2 Summary ===

# of expected passes23308
# of unexpected failures20

* sparcv9-sun-solaris2.11:

=== gm2 Summary for unix ===

# of expected passes11653
# of unexpected failures9
# of unresolved testcases   1

=== gm2 Summary for unix/-m32 ===

# of expected passes7390
# of unexpected failures2131
# of unresolved testcases   2029

=== gm2 Summary ===

# of expected passes19043
# of unexpected failures2140
# of unresolved testcases   2030

  The 32-bit failures are mostly (all?) of the same type.  I've filed PR
  modula2/106443 for that

* sparc-sun-solaris2.11:

  Still fails with a cc1gm2 SEGV in stage2: PR modula2/101392.

And just for completeness' sake:

* x86_64-pc-linux-gnu:

=== gm2 Summary for unix ===

# of expected passes11662
# of unexpected failures2

=== gm2 Summary for unix/-m32 ===

# of expected passes11657
# of unexpected failures7

=== gm2 Summary ===

# of expected passes23319
# of unexpected failures9

* i686-pc-linux-gnu:

=== gm2 Summary for unix ===

# of expected passes11663
# of unexpected failures1

=== gm2 Summary 

Re: [PATCH] contrib: use sphinx-build from a venv

[Martin Liška]

CCing overseers and Frank.

Can you please help me with that?

Thanks,
Martin

On 7/25/22 16:00, Martin Liška wrote:
> Hi.
> 
> As you likely know, I'm still working on transition of the current docs to 
> Sphinx.
> But for now, I've sent a modernizing patches for the current libgccjit 
> documentation
> and I will need a more recent version of Sphinx.
> 
> Can please a maintainer install the package from pip?
> 
> Something like:
> virtualenv /home/gcc/venv && /home/gcc/venv/bin/pip install Sphinx
> 
> or a similar location?
> 
> Thanks,
> Martin
> 
> maintainer-scripts/ChangeLog:
> 
>   * update_web_docs_git: Use sphinx-build from a venv so that
>   we can use a recent version.
> ---
>  maintainer-scripts/update_web_docs_git | 21 ++---
>  1 file changed, 6 insertions(+), 15 deletions(-)
> 
> diff --git a/maintainer-scripts/update_web_docs_git 
> b/maintainer-scripts/update_web_docs_git
> index 996d29bfb68..4b01b3dc1c0 100755
> --- a/maintainer-scripts/update_web_docs_git
> +++ b/maintainer-scripts/update_web_docs_git
> @@ -176,23 +176,14 @@ for file in $MANUALS; do
>fi
>  done
>  
> -# The jit is a special-case, using sphinx rather than texinfo.
> -# Specifically, the jit docs need sphinx 1.0 or later.
> +# The jit is a special-case, using Sphinx rather than texinfo.
> +# Specifically, the jit docs need Sphinx 3.0 or later.
>  #
> -# The jit/docs Makefile uses the executable $(SPHINXBUILD),
> -# defaulting to "sphinx-build".
> -#
> -# sphinx is packaged in Fedora and EPEL 6 within "python-sphinx",
> -# in RHEL 8 within "python3-sphinx",
> -# and in openSUSE within "python-Sphinx".
> -#
> -# For EPEL6, python-sphinx is sphinx 0.6.6, which is missing various
> -# directives (e.g. ":c:macro:"), so we need the variant
> -# python-sphinx10 package.  The latter installs its executable as
> -#   /usr/bin/sphinx-1.0-build
> -# so we needed to override SPHINXBUILD with this when invoking "make".
> +# Use the Sphinx installed in a virtual environment so that
> +# we don't depend on a system package.
> +
>  pushd gcc/gcc/jit/docs
> -make html || true
> +make html SPHINXBUILD=/home/gcc/venv/bin/sphinx-build || true
>  popd
>  cp -a gcc/gcc/jit/docs/_build/html jit
>  mkdir -p $DOCSDIR/jit

[PATCH][wwwdocs] gcc-13: Add loongarch '-mexplicit-relocs' support

[Lulu Cheng]

Hi,
  Recently we added split symbol support, changed in r13-1834.
  It is ok for wwwdocs?

Thanks!
Lulu Cheng

---
 htdocs/gcc-13/changes.html | 21 +
 1 file changed, 21 insertions(+)

diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 57bd8724..60399e4e 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -124,6 +124,27 @@ a work-in-progress.
 
 
 
+LoongArch
+
+  The option -mexplicit-relocs has been added, this indicates
+  whether the la.* macro instructions will be generated when
+  loading symbolic addresses.
+  This feature requires binutils version 2.40 or later. If you want to use the
+  older version of bintuils, add compiler parameters
+  -mno-explicit-relocs at compile time.
+  
+  The method for calling global functions changed from
+  la.global + jirl to bl when complied add
+  -fplt.
+  
+  Enable option -fsection-anchors when -O1 and
+  more advanced optimization.
+  
+  Changed ASM_PREFERRED_EH_DATA_FORMAT macro definition from
+  WD_EH_PE_absptr to WD_EH_PE_pcrel | 
DW_EH_PE_sdata4. 
+  
+
+
 
 
 
-- 
2.31.1

Re: [PATCH] Fortran: error recovery from calculation of storage size of a symbol [PR103504]

[Mikael Morin]

Le 25/07/2022 à 22:39, Harald Anlauf via Fortran a écrit :

Dear all,

we currently may ICE when array bounds of a dummy argument have
a non-integer type, and the procedure with the bad declaration is
referenced.  The same applies to bad character length of dummies.
We could simply punt in such a situation, as the causing error
seems to be reliably diagnosed, see testcase.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?


Yes.


This is a really safe fix and potentially backportable to other
open branches.  Would that be fine?


I think it is.

Thanks.

Re: [PING][PATCH] c: Handle initializations of opaque types [PR106016] (need review of expr.cc hunk)

[Richard Biener via Gcc-patches]

On Tue, Jul 26, 2022 at 12:46 AM Peter Bergner via Gcc-patches
 wrote:
>
> I'd like to ping the following patch.  Segher has approved the
> test case change, so I just need a review for the expr.cc change.
>
> Peter
>
>
>
> Message-ID: <009c391d-3994-8755-0d22-9e80faf91...@linux.ibm.com>
> Date: Fri, 17 Jun 2022 23:50:35 -0500
> To: GCC Patches 
> Subject: [PATCH] c: Handle initializations of opaque types [PR106016]
>
>
> On 6/17/22 11:50 PM, Peter Bergner via Gcc-patches wrote:
> > The initial commit that added opaque types thought that there couldn't
> > be any valid initializations for variables of these types, but the test
> > case in the bug report shows that isn't true.  The solution is to handle
> > OPAQUE_TYPE initializations just like the other scalar types.
> >
> > This passed bootstrap and regtesting with no regressions on 
> > powerpc64le-linux.
> > Ok for trunk?  This is an issue in GCC 12 and 11 too.  Ok for the release
> > branches after some burn-in on trunk?

OK.

Richard.

> > Peter
> >
> > gcc/
> >   PR c/106016
> >   * expr.cc (count_type_elements): Handle OPAQUE_TYPE.
> >
> > gcc/testsuite/
> >   PR c/106016
> >   * gcc.target/powerpc/pr106016.c: New test.
> >
> > diff --git a/gcc/expr.cc b/gcc/expr.cc
> > index 78c839ab425..1675198a146 100644
> > --- a/gcc/expr.cc
> > +++ b/gcc/expr.cc
> > @@ -6423,13 +6423,13 @@ count_type_elements (const_tree type, bool 
> > for_ctor_p)
> >  case OFFSET_TYPE:
> >  case REFERENCE_TYPE:
> >  case NULLPTR_TYPE:
> > +case OPAQUE_TYPE:
> >return 1;
> >
> >  case ERROR_MARK:
> >return 0;
> >
> >  case VOID_TYPE:
> > -case OPAQUE_TYPE:
> >  case METHOD_TYPE:
> >  case FUNCTION_TYPE:
> >  case LANG_TYPE:
> > diff --git a/gcc/testsuite/gcc.target/powerpc/pr106016.c 
> > b/gcc/testsuite/gcc.target/powerpc/pr106016.c
> > new file mode 100644
> > index 000..3db8345dcc6
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/powerpc/pr106016.c
> > @@ -0,0 +1,14 @@
> > +/* PR target/106016 */
> > +/* { dg-require-effective-target power10_ok } */
> > +/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
> > +
> > +/* Make sure we do not ICE on the following test case.  */
> > +
> > +extern void bar (__vector_quad *);
> > +
> > +void
> > +foo (__vector_quad *a, __vector_quad *b)
> > +{
> > +  __vector_quad arr[2] = {*a, *b};
> > +  bar ([0]);
> > +}
>

Re: [PATCH V1] HIGH part of symbol ref is invalid for constant pool

[Jiufu Guo via Gcc-patches]

"Kewen.Lin"  writes:

> Hi Jeff,
>
> on 2022/7/19 22:30, Jiufu Guo wrote:
>> Hi,
>> 
>> In patch https://gcc.gnu.org/pipermail/gcc-patches/2022-July/597712.html,
>> test case was not added.  After more check, a testcase is added for it.
>> 
>
> Good to see that you constructed one actual test case, nice!  :)
>
>> The high part of the symbol address is invalid for the constant pool.
>> In function rs6000_cannot_force_const_mem, we already return true for
>> "HIGH with UNSPEC" rtx.  Below are some examples also indicate the high
>> part of a symbol_ref:
>> (high:DI (const:DI (plus:DI (symbol_ref:DI ("xx") (const_int 12 [0xc])
>> (high:DI (symbol_ref:DI ("var_1")..)))
>> 
>> This patch updates rs6000_cannot_force_const_mem to return true for
>> rtx with HIGH code.
>> 
>> Bootstrapped and regtested on ppc64le and ppc64.
>> Is it ok for trunk?
>
> I think this patch is OK with some nits below tweaked.

Thanks so much for your time to review and helpful comments!
I will update accordingly before commit.

BR,
Jeff(Jiufu)

>
>> 
>> BR,
>> Jeff(Jiufu)
>> 
>> 
>> gcc/ChangeLog:
>> 
>>  * config/rs6000/rs6000.cc (rs6000_cannot_force_const_mem):
>>  Return true for HIGH code rtx.
>> 
>> gcc/testsuite/ChangeLog:
>> 
>>  * gcc.target/powerpc/constpoolcheck.c: New test.
>> 
>> ---
>>  gcc/config/rs6000/rs6000.cc   |  7 +--
>>  gcc/testsuite/gcc.target/powerpc/constpoolcheck.c | 11 +++
>>  2 files changed, 16 insertions(+), 2 deletions(-)
>>  create mode 100644 gcc/testsuite/gcc.target/powerpc/constpoolcheck.c
>> 
>> diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
>> index 0af2085adc0..d56832ebbfc 100644
>> --- a/gcc/config/rs6000/rs6000.cc
>> +++ b/gcc/config/rs6000/rs6000.cc
>> @@ -9704,8 +9704,11 @@ rs6000_init_stack_protect_guard (void)
>>  static bool
>>  rs6000_cannot_force_const_mem (machine_mode mode ATTRIBUTE_UNUSED, rtx x)
>>  {
>> -  if (GET_CODE (x) == HIGH
>> -  && GET_CODE (XEXP (x, 0)) == UNSPEC)
>> +  /* High part of a symbol ref/address can not be put into constant pool. 
>> e.g.
>
> Nit: two spaces after the period in "... pool.".
Thanks!
>
>> + (high:DI (symbol_ref:DI ("var")..)) or
>
> Nit: You have one "or" at the end of the above line, I think it's better to
> keep the below line consistent by either removing the above " or" or adding
> one "or" at the end of the below line.
Thanks!
>
>> + (high:DI (unspec:DI [(symbol_ref/u:DI ("*.LC0")..)
>
>
>> + (high:DI (const:DI (plus:DI (symbol_ref:DI ("xx")) (const_int 12.  
>> */
>> +  if (GET_CODE (x) == HIGH)
>>  return true;
>> 
>>/* A TLS symbol in the TOC cannot contain a sum.  */
>> diff --git a/gcc/testsuite/gcc.target/powerpc/constpoolcheck.c 
>> b/gcc/testsuite/gcc.target/powerpc/constpoolcheck.c
>> new file mode 100644
>> index 000..ed7a994827b
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/powerpc/constpoolcheck.c
>
> Maybe it's good to name it to "const-pool-check.c" or "not-force-const-mem.c".
Great sugguestion! Thanks.
>
>> @@ -0,0 +1,11 @@
>> +/* { dg-do compile { target powerpc*-*-* } } */
>
> Nit: this "dg-do" line isn't needed since all here are default.
Thanks for your comments!

>
> BR,
> Kewen
>
>> +/* { dg-options "-O1 -mdejagnu-cpu=power10" } */
>> +/* (high:DI (symbol_ref:DI ("var_48")..))) should not cause ICE. */
>> +extern short var_48;
>> +void
>> +foo (double *r)
>> +{
>> +  if (var_48)
>> +*r = 1234.5678;
>> +}
>> +

[PATCH] jit,docs: shorten assembly output

[Martin Liška]

Shorten the assembly example so that there is not slider.

Ready for master?
Thanks,
Martin

gcc/jit/ChangeLog:

* docs/cp/intro/tutorial02.rst:
Shorten the assembly example so that there is not slider.
* docs/cp/intro/tutorial04.rst: Likewise.
* docs/intro/tutorial02.rst: Likewise.
* docs/intro/tutorial04.rst: Likewise.
* docs/topics/contexts.rst: Likewise.
---
 gcc/jit/docs/cp/intro/tutorial02.rst | 4 ++--
 gcc/jit/docs/cp/intro/tutorial04.rst | 2 +-
 gcc/jit/docs/intro/tutorial02.rst| 4 ++--
 gcc/jit/docs/intro/tutorial04.rst| 2 +-
 gcc/jit/docs/topics/contexts.rst | 2 +-
 5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/gcc/jit/docs/cp/intro/tutorial02.rst 
b/gcc/jit/docs/cp/intro/tutorial02.rst
index 2064f8e4dd9..03643566f27 100644
--- a/gcc/jit/docs/cp/intro/tutorial02.rst
+++ b/gcc/jit/docs/cp/intro/tutorial02.rst
@@ -286,7 +286,7 @@ before compiling:
 .cfi_endproc
   .LFE6:
 .size   square, .-square
-.ident  "GCC: (GNU) 4.9.0 20131023 (Red Hat 
0.2-0.5.1920c315ff984892399893b380305ab36e07b455.fc20)"
+.ident  "GCC: (GNU) 4.9.0 20131023 (Red Hat 0.2)"
 .section   .note.GNU-stack,"",@progbits
 
 By default, no optimizations are performed, the equivalent of GCC's
@@ -315,7 +315,7 @@ By default, no optimizations are performed, the equivalent 
of GCC's
 .cfi_endproc
   .LFE7:
 .size   square, .-square
-.ident  "GCC: (GNU) 4.9.0 20131023 (Red Hat 
0.2-0.5.1920c315ff984892399893b380305ab36e07b455.fc20)"
+.ident  "GCC: (GNU) 4.9.0 20131023 (Red Hat 0.2)"
 .section.note.GNU-stack,"",@progbits
 
 Naturally this has only a small effect on such a trivial function.
diff --git a/gcc/jit/docs/cp/intro/tutorial04.rst 
b/gcc/jit/docs/cp/intro/tutorial04.rst
index 45198ce3d7a..0a7cabfc037 100644
--- a/gcc/jit/docs/cp/intro/tutorial04.rst
+++ b/gcc/jit/docs/cp/intro/tutorial04.rst
@@ -549,7 +549,7 @@ yields this code, which is simple enough to quote in its 
entirety:
   .cfi_endproc
   .LFE0:
   .size   factorial, .-factorial
-  .ident  "GCC: (GNU) 4.9.0 20131023 (Red Hat 0.2-%{gcc_release})"
+  .ident  "GCC: (GNU) 4.9.0 20131023 (Red Hat 0.2)"
   .section.note.GNU-stack,"",@progbits
 
 Note that the stack pushing and popping have been eliminated, as has the
diff --git a/gcc/jit/docs/intro/tutorial02.rst 
b/gcc/jit/docs/intro/tutorial02.rst
index 5739548b0e3..d7423f25279 100644
--- a/gcc/jit/docs/intro/tutorial02.rst
+++ b/gcc/jit/docs/intro/tutorial02.rst
@@ -332,7 +332,7 @@ before compiling:
 .cfi_endproc
   .LFE6:
 .size   square, .-square
-.ident  "GCC: (GNU) 4.9.0 20131023 (Red Hat 
0.2-0.5.1920c315ff984892399893b380305ab36e07b455.fc20)"
+.ident  "GCC: (GNU) 4.9.0 20131023 (Red Hat 0.2)"
 .section   .note.GNU-stack,"",@progbits
 
 By default, no optimizations are performed, the equivalent of GCC's
@@ -364,7 +364,7 @@ By default, no optimizations are performed, the equivalent 
of GCC's
 .cfi_endproc
   .LFE7:
 .size   square, .-square
-.ident  "GCC: (GNU) 4.9.0 20131023 (Red Hat 
0.2-0.5.1920c315ff984892399893b380305ab36e07b455.fc20)"
+.ident  "GCC: (GNU) 4.9.0 20131023 (Red Hat 0.2)"
 .section.note.GNU-stack,"",@progbits
 
 Naturally this has only a small effect on such a trivial function.
diff --git a/gcc/jit/docs/intro/tutorial04.rst 
b/gcc/jit/docs/intro/tutorial04.rst
index e1c47a0d2d5..111dad80e51 100644
--- a/gcc/jit/docs/intro/tutorial04.rst
+++ b/gcc/jit/docs/intro/tutorial04.rst
@@ -571,7 +571,7 @@ yields this code, which is simple enough to quote in its 
entirety:
   .cfi_endproc
   .LFE0:
   .size   factorial, .-factorial
-  .ident  "GCC: (GNU) 4.9.0 20131023 (Red Hat 0.2-%{gcc_release})"
+  .ident  "GCC: (GNU) 4.9.0 20131023 (Red Hat 0.2)"
   .section.note.GNU-stack,"",@progbits
 
 Note that the stack pushing and popping have been eliminated, as has the
diff --git a/gcc/jit/docs/topics/contexts.rst b/gcc/jit/docs/topics/contexts.rst
index dfbe968e127..0993d5733b9 100644
--- a/gcc/jit/docs/topics/contexts.rst
+++ b/gcc/jit/docs/topics/contexts.rst
@@ -423,7 +423,7 @@ Boolean options
.cfi_endproc
.LFE0:
.sizesquare, .-square
-   .ident"GCC: (GNU) 4.9.0 20131023 (Red Hat 0.1-%{gcc_release})"
+   .ident"GCC: (GNU) 4.9.0 20131023 (Red Hat 0.2)"
.section.note.GNU-stack,"",@progbits
 
 
-- 
2.37.1

Re: [pushed][PATCH v1 0/2] LoongArch: Modify the method of obtaining symbolic addresses.

[Lulu Cheng]

在 2022/7/19 下午9:08, Lulu Cheng 写道:

1. The original LA macro instruction is split into two instructions to
obtain the address of the symbol if enable '-mexplicit-relocs'.
2. Currently, '-mcmodel=' only supports 'normal' mode, because other mode
behaviors are not yet determined. This function is gradually improved
by the subsequent handling.
3. Modify the method that calls global functions. Changed from 'la.global + 
jirl'
to 'bl'.
4. Some R_LARCH_64 in section .eh_frame will to generate  R_LARCH_NONE, we
change ASM_PREFERRED_EH_DATA_FORMAT from 'WD_EH_PE_absptr' to
'WD_EH_PE_pcrel | DW_EH_PE_sdata4' then relocation to R_LARCH_32_PCREL
from R_LARCH_64 in setction .eh_frame and not generate dynamic relocation
for R_LARCH_32_PCREL.

This new symbol loading method not support by upstream binutils yet,
this GCC port requires the following patches applied to binutils to build.

https://sourceware.org/pipermail/binutils/2022-July/121849.html
https://sourceware.org/pipermail/binutils/2022-July/121850.html
https://sourceware.org/pipermail/binutils/2022-July/121851.html
https://sourceware.org/pipermail/binutils/2022-July/121852.html
https://sourceware.org/pipermail/binutils/2022-July/121853.html

Lulu Cheng (2):
   LoongArch: Modify the method of obtaining symbolic addresses.
   LoongArch: Modify the definition of the ASM_PREFERRED_EH_DATA_FORMAT
 macro.

  .../config/loongarch/loongarch-common.cc  |   1 +
  gcc/config/loongarch/constraints.md   |  24 +-
  gcc/config/loongarch/genopts/loongarch.opt.in |   4 +
  gcc/config/loongarch/loongarch-protos.h   |   9 +-
  gcc/config/loongarch/loongarch.cc | 660 +-
  gcc/config/loongarch/loongarch.h  |   4 +-
  gcc/config/loongarch/loongarch.md | 401 +++
  gcc/config/loongarch/loongarch.opt|   4 +
  gcc/config/loongarch/predicates.md|  56 +-
  9 files changed, 629 insertions(+), 534 deletions(-)

[PATCH] tree-optimization/106189 - avoid division by zero exception

[Richard Biener via Gcc-patches]

The diagnostic code can end up with zero sized array elements
with T[][0] and the wide-int code nicely avoids exceptions when
dividing by zero in one codepath but not in another.  The following
fixes the exception by using wide-int in both paths.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.

PR tree-optimization/106189
* gimple-array-bounds.cc (array_bounds_checker::check_mem_ref):
Divide using offset_ints.

* gcc.dg/pr106189.c: New testcase.
---
 gcc/gimple-array-bounds.cc  | 2 +-
 gcc/testsuite/gcc.dg/pr106189.c | 5 +
 2 files changed, 6 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr106189.c

diff --git a/gcc/gimple-array-bounds.cc b/gcc/gimple-array-bounds.cc
index 0b48bdb0ae5..e190b93aa85 100644
--- a/gcc/gimple-array-bounds.cc
+++ b/gcc/gimple-array-bounds.cc
@@ -534,7 +534,7 @@ array_bounds_checker::check_mem_ref (location_t location, 
tree ref,
   int i = 0;
   if (aref.offmax[i] < -aref.sizrng[1] || aref.offmax[i = 1] > ubound)
 {
-  HOST_WIDE_INT tmpidx = aref.offmax[i].to_shwi () / eltsize.to_shwi ();
+  HOST_WIDE_INT tmpidx = (aref.offmax[i] / eltsize).to_shwi ();
 
   if (warning_at (location, OPT_Warray_bounds,
  "intermediate array offset %wi is outside array bounds "
diff --git a/gcc/testsuite/gcc.dg/pr106189.c b/gcc/testsuite/gcc.dg/pr106189.c
new file mode 100644
index 000..0eca8343c56
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr106189.c
@@ -0,0 +1,5 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -Warray-bounds=2 -w" } */
+
+int a_n_0_0_a[][0];
+void a_n_0_0() { T(((char *)a_n_0_0_a)[1]); }
-- 
2.35.3