Re: [PATCH] avr: Set param_min_pagesize to 0 [PR105523]

[SenthilKumar.Selvaraj--- via Gcc-patches]

On 26/04/23, 5:51 PM, "Richard Biener" mailto:richard.guent...@gmail.com>> wrote:
> On Wed, Apr 26, 2023 at 12:56 PM  > wrote:
> >
> > On Wed, Apr 26, 2023 at 3:15 PM Richard Biener via Gcc-patches 
> > mailto:gcc-patches@gcc.gnu.org>> wrote:
> > >
> > > On Wed, Apr 26, 2023 at 11:42 AM Richard Biener
> > > mailto:richard.guent...@gmail.com>> wrote:
> > > >
> > > > On Wed, Apr 26, 2023 at 11:01 AM SenthilKumar.Selvaraj--- via
> > > > Gcc-patches mailto:gcc-patches@gcc.gnu.org>> 
> > > > wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > This patch fixes PR 105523 by setting param_min_pagesize to 0 for the
> > > > > avr target. For this target, zero and offsets from zero are perfectly
> > > > > valid addresses, and the default value of param_min_pagesize ends up
> > > > > triggering warnings on valid memory accesses.
> > > >
> > > > I think the proper configuration is to have
> > > > DEFAULT_ADDR_SPACE_ZERO_ADDRESS_VALID
> > >
> > > Err, TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID
> >
> > That worked. Ok for trunk and backporting to 13 and 12 branches
> > (pending regression testing)?
> 
> 
> OK, but please let Denis time to comment.

Didn't hear from Denis. When running regression tests with this patch,
I found that some tests with -fdelete-null-pointer-checks were
failing. Commit 19416210b37db0584cd0b3f3b3961324b8973d25 made
-fdelete-null-pointer-checks false by default, while still allowing it
to be overridden from the command line (it was previously
unconditionally false).

To keep the same behavior, I modified the hook to report zero
addresses as valid only if -fdelete-null-pointer-checks is not set.
With this change, all regression tests pass.

Ok for trunk and backporting to 13 and 12 branches?

Regards
Senthil

PR 105523

gcc/ChangeLog:

* config/avr/avr.cc (avr_addr_space_zero_address_valid):
(TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID): Return true if
flag_delete_null_pointer_checks is not set.

gcc/testsuite/ChangeLog:

* gcc.target/avr/pr105523.c: New test.


diff --git gcc/config/avr/avr.cc gcc/config/avr/avr.cc
index d5af40f..4c9eb84 100644
--- gcc/config/avr/avr.cc
+++ gcc/config/avr/avr.cc
@@ -9787,6 +9787,18 @@ avr_addr_space_diagnose_usage (addr_space_t as, 
location_t loc)
   (void) avr_addr_space_supported_p (as, loc);
 }
 
+/* Implement `TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID. Zero is a valid
+   address in all address spaces. Even in ADDR_SPACE_FLASH1 etc..,
+   a zero address is valid and means 0x, where RAMPZ is
+   set to the appropriate segment value.
+   If the user explicitly passes in -fdelete-null-pointer-checks though,
+   assume zero addresses are invalid.*/
+
+static bool
+avr_addr_space_zero_address_valid (addr_space_t as ATTRIBUTE_UNUSED)
+{
+  return flag_delete_null_pointer_checks == 0;
+}
 
 /* Look if DECL shall be placed in program memory space by
means of attribute `progmem' or some address-space qualifier.
@@ -14687,6 +14699,9 @@ avr_float_lib_compare_returns_bool (machine_mode mode, 
enum rtx_code)
 #undef  TARGET_ADDR_SPACE_DIAGNOSE_USAGE
 #define TARGET_ADDR_SPACE_DIAGNOSE_USAGE avr_addr_space_diagnose_usage
 
+#undef  TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID
+#define TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID avr_addr_space_zero_address_valid
+
 #undef  TARGET_MODE_DEPENDENT_ADDRESS_P
 #define TARGET_MODE_DEPENDENT_ADDRESS_P avr_mode_dependent_address_p
 
diff --git gcc/testsuite/gcc.target/avr/pr105523.c 
gcc/testsuite/gcc.target/avr/pr105523.c
new file mode 100644
index 000..fbbf7bf
--- /dev/null
+++ gcc/testsuite/gcc.target/avr/pr105523.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-Os -Wall" } */
+
+/* Verify no "array subscript 0 is outside array bounds of" is generated
+   for accessing memory addresses in the 0-4096 range. */
+
+typedef __UINT8_TYPE__ uint8_t;
+
+#define SREG (*(volatile uint8_t*) (0x3F + __AVR_SFR_OFFSET__ ))
+
+void bar (void)
+{
+SREG = 0;
+}

[Bug target/109900] _mm256_abs_epi8 is not expanded on gimple level

[crazylht at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109900

--- Comment #1 from Hongtao.liu  ---
Yes, let me do the folding.
FYI, for those floating point abs intrinsics, they're already implemented as 

_mm512_abs_ps (__m512 __A)
{
  return (__m512) _mm512_and_epi32 ((__m512i) __A,
_mm512_set1_epi32 (0x7fff));
}

And no need for folding.

[Bug c/109905] New: Missed misleading indentation with braces

[roland.illig at gmx dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109905

Bug ID: 109905
   Summary: Missed misleading indentation with braces
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

https://github.com/NetBSD/src/blob/93dc650849c98c54c31aa9cbbce9affaaf649563/bin/cat/cat.c#L185
has misleading indentation, as the 'else' branch does not start with a '{'.

I tried GCC 10 and GCC 12, which don't detect this. Maybe GCC 14 should.

[Bug driver/33980] Precompiled header file not removed on error

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33980

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|pch |driver
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org

--- Comment #5 from Andrew Pinski  ---
I think I have a simple patch for this.

[Bug target/106545] peephole.md seems like it should not exist

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106545

--- Comment #3 from Andrew Pinski  ---
Note I see XTheadMemPair code has been added to peephole.md which is good to
have it away. 
But again the first peephole is also handled differently already via
zero_extendsidi2_shifted which was added in r11-745-gd5cdcd5cf2b292 but it was
not until r13-4907-g2e886eef7f2b5a when we started to optimizing the following
code:
unsigned long f(unsigned long a)
{
  a <<= 32;
  a >>= 32;
  a <<= 10;
  return a;
}

[Bug target/106545] peephole.md seems like it should not exist

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106545

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |vineetg at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-05-19
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
(In reply to Vineet Gupta from comment #1)
> How do I assign this to myself, can this only be done by maintainers ?

You use your @gcc.gnu.org email.

[Bug c++/105703] Add fix-it for missing nested-name-specifier on non-member function using 'this'

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105703

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-05-19
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug c++/105702] Add fix-it for missing nested-name-specifier on out-of-class assignment operator

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105702

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-05-19

--- Comment #2 from Andrew Pinski  ---
Confirmed.

[Bug c++/107744] Error in constant evaluation of dynamic_cast

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107744

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-05-19
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug tree-optimization/107694] Bogus stringop-overflow warning in gcc 12

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107694

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=109571

--- Comment #1 from Andrew Pinski  ---
PR 109571 is basically the same here just with a different warning (and
upcasting instead of downcasting).

In this case if we look at:
void nsJSPrincipals::Destroy(JSPrincipals* jsprin) {
 nsJSPrincipals* nsjsprin = nsJSPrincipals::get(jsprin);


if jsprin is null, then nsjsprin needs to be null too. And since nsjsprin ==
jsprin-8(bytes) (if it was a valid pointer), the C++ front-end needs to add a
check for null. And then the optimizations come along and does jump threading.
so one way of removing this is adding an assumption which can be done via one
of the following:
  if (!jsprin) __builtin_unreachable();
  [[assume(jsprin)]];

The first one is valid for GCC all the way back in 4.7 (and before).
the second one is C++23 and was only added in GCC 13.

[Bug c++/107587] Explicit specializations of user-defined deduction guides in unnamed namespaces trigger -Wunused-function

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107587

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
Dup of bug 106604.

*** This bug has been marked as a duplicate of bug 106604 ***

[Bug c++/106604] Fully-specified deduction guide in anonymous namespace warns as-if a function? Unsuppressably?

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106604

Andrew Pinski  changed:

   What|Removed |Added

 CC||development at jordi dot 
vilar.cat

--- Comment #2 from Andrew Pinski  ---
*** Bug 107587 has been marked as a duplicate of this bug. ***

[Bug target/107533] Inefficient code sequence for fp16 testcase on aarch64

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107533

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-05-19
 Ever confirmed|0   |1
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Take:
```
struct phalf {
__fp16 first;
__fp16 second;
};

void phalf_copy_(struct phalf *d, struct phalf src) {
*d = src;
}
struct phalf phalf_copy0( __fp16 f, __fp16 s) {
struct phalf t = {f, s};
return t;
}
struct phalf phalf_copy(struct phalf* src) {
return *src;
}
struct phalf phalf_copy1(__fp16 *f, __fp16 *s) {
struct phalf t = {*f, *s};
return t;
}
void phalf_copy2(struct phalf *d, __fp16 *f, __fp16 *s) {
struct phalf t = {*f, *s};
*d = t;
}
void phalf_copy3(struct phalf *d, struct phalf* src) {
*d = *src;
}
void phalf_copy4(struct phalf *d, __fp16 f, __fp16 s) {
struct phalf t = {f, s};
*d = t;
}
```
2,3,4 are all ok, while 0, none, _ and 1 are bad.
Which points to return values and argument passing being bad (which we already
knew had issues).

Confirmed.

[RFC V2] RISC-V : Support rv64 ilp32

[Liao Shihua]

This patch support ilp32 on rv64.
It remove option check when -march=rv64* -mabi=ilp32. And replace XLEN_SPEC in 
LINK_SPEC by ABI_LEN_SPEC. In addition, it some machine descriptions. 

The series kernel support in this link. 
https://lore.kernel.org/linux-riscv/20230518131013.3366406-1-guo...@kernel.org/

gcc/ChangeLog:

* config.gcc:
* config/riscv/elf.h (LINK_SPEC):
* config/riscv/linux.h (LINK_SPEC):
* config/riscv/riscv.cc (riscv_option_override):
* config/riscv/riscv.h (TARGET_ILP32):
(POINTER_SIZE):
(Pmode):
(ABI_LEN_SPEC):
* config/riscv/riscv.md:
---
 gcc/config.gcc|  3 +++
 gcc/config/riscv/elf.h|  2 +-
 gcc/config/riscv/linux.h  |  2 +-
 gcc/config/riscv/riscv.cc |  4 
 gcc/config/riscv/riscv.h  | 12 ++--
 gcc/config/riscv/riscv.md |  8 ++--
 6 files changed, 21 insertions(+), 10 deletions(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 6fd1594480a..db8e8f20791 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -4658,6 +4658,9 @@ case "${target}" in
ilp32,rv32* | ilp32e,rv32e* \
| ilp32f,rv32*f* | ilp32f,rv32g* \
| ilp32d,rv32*d* | ilp32d,rv32g* \
+   | ilp32f,rv64*f* | ilp32f,rv64g* \
+   | ilp32d,rv64*d* | ilp32d,rv64g* \
+   | ilp32,rv64* \
| lp64,rv64* \
| lp64f,rv64*f* | lp64f,rv64g* \
| lp64d,rv64*d* | lp64d,rv64g*)
diff --git a/gcc/config/riscv/elf.h b/gcc/config/riscv/elf.h
index a725c00b637..bea531ebe89 100644
--- a/gcc/config/riscv/elf.h
+++ b/gcc/config/riscv/elf.h
@@ -18,7 +18,7 @@ along with GCC; see the file COPYING3.  If not see
 .  */
 
 #define LINK_SPEC "\
--melf" XLEN_SPEC DEFAULT_ENDIAN_SPEC "riscv \
+-melf" ABI_LEN_SPEC DEFAULT_ENDIAN_SPEC "riscv \
 %{mno-relax:--no-relax} \
 %{mbig-endian:-EB} \
 %{mlittle-endian:-EL} \
diff --git a/gcc/config/riscv/linux.h b/gcc/config/riscv/linux.h
index b9557a75dc7..4f33c88ef6e 100644
--- a/gcc/config/riscv/linux.h
+++ b/gcc/config/riscv/linux.h
@@ -58,7 +58,7 @@ along with GCC; see the file COPYING3.  If not see
   "%{mabi=ilp32:_ilp32}"
 
 #define LINK_SPEC "\
--melf" XLEN_SPEC DEFAULT_ENDIAN_SPEC "riscv" LD_EMUL_SUFFIX " \
+-melf" ABI_LEN_SPEC DEFAULT_ENDIAN_SPEC "riscv" LD_EMUL_SUFFIX " \
 %{mno-relax:--no-relax} \
 %{mbig-endian:-EB} \
 %{mlittle-endian:-EL} \
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 5f44f6dc5c9..09ab940447d 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -6291,10 +6291,6 @@ riscv_option_override (void)
   && riscv_abi != ABI_LP64 && riscv_abi != ABI_ILP32E)
 error ("z*inx requires ABI ilp32, ilp32e or lp64");
 
-  /* We do not yet support ILP32 on RV64.  */
-  if (BITS_PER_WORD != POINTER_SIZE)
-error ("ABI requires %<-march=rv%d%>", POINTER_SIZE);
-
   /* Validate -mpreferred-stack-boundary= value.  */
   riscv_stack_boundary = ABI_STACK_BOUNDARY;
   if (riscv_preferred_stack_boundary_arg)
diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
index 66fb07d6652..54fd328b5b0 100644
--- a/gcc/config/riscv/riscv.h
+++ b/gcc/config/riscv/riscv.h
@@ -77,6 +77,10 @@ extern const char *riscv_multi_lib_check (int argc, const 
char **argv);
 #define TARGET_64BIT   (__riscv_xlen == 64)
 #endif /* IN_LIBGCC2 */
 
+#ifndef TARGET_ILP32
+#define TARGET_ILP32   (riscv_abi <= ABI_ILP32D)
+#endif /*TARGET_ILP32*/
+
 #ifdef HAVE_AS_MISA_SPEC
 #define ASM_MISA_SPEC "%{misa-spec=*}"
 #else
@@ -172,7 +176,7 @@ ASM_MISA_SPEC
 #define SHORT_TYPE_SIZE 16
 #define INT_TYPE_SIZE 32
 #define LONG_LONG_TYPE_SIZE 64
-#define POINTER_SIZE (riscv_abi >= ABI_LP64 ? 64 : 32)
+#define POINTER_SIZE (TARGET_ILP32 ? 32 : 64)
 #define LONG_TYPE_SIZE POINTER_SIZE
 
 #define FLOAT_TYPE_SIZE 32
@@ -789,7 +793,7 @@ typedef struct {
After generation of rtl, the compiler makes no further distinction
between pointers and any other objects of this machine mode.  */
 
-#define Pmode word_mode
+#define Pmode (TARGET_ILP32 ? SImode : DImode)
 
 /* Give call MEMs SImode since it is the "most permissive" mode
for both 32-bit and 64-bit targets.  */
@@ -1039,6 +1043,10 @@ extern poly_int64 riscv_v_adjust_bytesize (enum 
machine_mode, int);
   "%{march=rv32*:32}" \
   "%{march=rv64*:64}" \
 
+#define ABI_LEN_SPEC \
+  "%{mabi=ilp32*:32}" \
+  "%{mabi=lp64*:64}" \
+
 #define ABI_SPEC \
   "%{mabi=ilp32:ilp32}" \
   "%{mabi=ilp32e:ilp32e}" \
diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index bc384d9aedf..260b0907cf5 100644
--- a/gcc/config/riscv/riscv.md
+++ b/gcc/config/riscv/riscv.md
@@ -2737,6 +2737,10 @@
   "reload_completed"
   [(const_int 0)]
 {
+  if (GET_MODE (operands[0]) != Pmode)
+operands[0] = convert_to_mode (Pmode, operands[0], 0);  
+  if (GET_MODE (operands[1]) != Pmode)
+operands[1] = convert_to_mode (Pmode, operands[1], 0);
   

[Bug c++/106810] Unexpected constraint recursion

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106810

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Andrew Pinski  ---
Even though this bug is older, PR 108393 has the full analysis of what is going
on and even talks about a fix for the testcase and talking about CWG2369 too.

*** This bug has been marked as a duplicate of bug 108393 ***

[Bug c++/108393] circular concept false-positive

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108393

Andrew Pinski  changed:

   What|Removed |Added

 CC||hewillk at gmail dot com

--- Comment #5 from Andrew Pinski  ---
*** Bug 106810 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/107476] Spurious stringop-overflow warning

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107476

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
  Known to fail||13.1.0

--- Comment #2 from Andrew Pinski  ---
So it looks like there was some jump threading that happened here:
  if (one.0_59 > 1)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 131211251]:
  ivtmp.16_58 = (unsigned long)   [(void *)_ldsc +
520B];

   [local count: 131211252]:
  # ivtmp.14_38 = PHI 
  # ivtmp.16_18 = PHI 
  _9 = (struct TMLN *) ivtmp.16_18;
  temp_10 = tmxr_getc_ln (_9);
  if (temp_10 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

But for some reason the trunk does not do that any more. Would be interesting
to see when the warning disappeared from the trunk.

[Bug tree-optimization/107462] Missed optimization of std::atomic::fetch_xxx "null operations" to std::atomic::load()

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107462

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-05-19

--- Comment #2 from Andrew Pinski  ---
Confirmed.

[Bug c++/107450] GCC accepts invalid program involving multiple template parameter packs

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107450

--- Comment #2 from Andrew Pinski  ---
Reduced/simplified (using auto because I feel like it):
int i, j, k;
void f(auto){i++;}
void g(auto){j++;}
void h(auto){k++;}
void foo(auto&&...args1, auto&&... args2, auto&&... args3) {
(f(args1), ...);
(g(args2), ...);
(h(args3), ...);
}

int main(int argc, char** argv)
{
foo(1,2,3,4,5,6); //gcc and clang compiles this while msvc correctly
rejects this
__builtin_printf("args1: %d, args2: %d, args3: %d.\n", i, j, k);
}

Scripts to build Cross-GCC, Clang, and QEMU on Cygwin and MSYS2/MinGW-w64

[徐持恒 Xu Chiheng via Gcc]

Hi, friends

I have some scripts to build Cross-GCC, Clang, and QEMU on Cygwin and
MSYS2/MinGW-w64 at:
https://github.com/xu-chiheng/Tool

I hope the scripts are useful for those interested in building the
projects on Windows.

[PATCH 1/2] Improve do_store_flag for single bit comparison against 0

[Andrew Pinski via Gcc-patches]

While working something else, I noticed we could improve
the following function code generation:
```
unsigned f(unsigned t)
{
  if (t & ~(1<<30)) __builtin_unreachable();
  return t != 0;
}
```
Right know we just emit a comparison against 0 instead
of just a shift right by 30.
There is code in do_store_flag which already optimizes
`(t & 1<<30) != 0` to `(t >> 30) & 1`. This patch
extends it to handle the case where we know t has a
nonzero of just one bit set.

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

gcc/ChangeLog:

* expr.cc (do_store_flag): Extend the one bit checking case
to handle the case where we don't have an and but rather still
one bit is known to be non-zero.
---
 gcc/expr.cc | 27 +--
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/gcc/expr.cc b/gcc/expr.cc
index 5ede094e705..91528e734e7 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -13083,15 +13083,30 @@ do_store_flag (sepops ops, rtx target, machine_mode 
mode)
   && integer_zerop (arg1)
   && (TYPE_PRECISION (ops->type) != 1 || TYPE_UNSIGNED (ops->type)))
 {
-  gimple *srcstmt = get_def_for_expr (arg0, BIT_AND_EXPR);
-  if (srcstmt
- && integer_pow2p (gimple_assign_rhs2 (srcstmt)))
+  wide_int nz = tree_nonzero_bits (arg0);
+
+  if (wi::popcount (nz) == 1)
{
+ tree op0;
+ tree op1;
+ gimple *srcstmt = get_def_for_expr (arg0, BIT_AND_EXPR);
+ /* If the defining statement was (x & POW2), then remove the and
+as we are going to add it back. */
+ if (srcstmt
+ && integer_pow2p (gimple_assign_rhs2 (srcstmt)))
+   {
+ op0 = gimple_assign_rhs1 (srcstmt);
+ op1 = gimple_assign_rhs2 (srcstmt);
+   }
+ else
+   {
+ op0 = arg0;
+ op1 = wide_int_to_tree (TREE_TYPE (op0), nz);
+   }
  enum tree_code tcode = code == NE ? NE_EXPR : EQ_EXPR;
  type = lang_hooks.types.type_for_mode (mode, unsignedp);
- tree temp = fold_build2_loc (loc, BIT_AND_EXPR, TREE_TYPE (arg1),
-  gimple_assign_rhs1 (srcstmt),
-  gimple_assign_rhs2 (srcstmt));
+ tree temp = fold_build2_loc (loc, BIT_AND_EXPR, TREE_TYPE (op0),
+  op0, op1);
  temp = fold_single_bit_test (loc, tcode, temp, arg1, type);
  if (temp)
return expand_expr (temp, target, VOIDmode, EXPAND_NORMAL);
-- 
2.31.1

[PATCH 2/2] Improve do_store_flag for comparing single bit against that bit

[Andrew Pinski via Gcc-patches]

This is a case which I noticed while working on the previous patch.
Sometimes we end up with `a == CST` instead of comparing against 0.
This happens in the following code:
```
unsigned f(unsigned t)
{
  if (t & ~(1<<30)) __builtin_unreachable();
  t ^= (1<<30);
  return t != 0;
}
```

We should handle the case where the nonzero bits is the same as the
comparison operand.

OK? Bootstrapped and tested on x86_64-linux-gnu.

gcc/ChangeLog:

* expr.cc (do_store_flag): Improve for single bit testing
not against zero but against that single bit.
---
 gcc/expr.cc | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/gcc/expr.cc b/gcc/expr.cc
index 91528e734e7..a4628c51c0c 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -13080,12 +13080,15 @@ do_store_flag (sepops ops, rtx target, machine_mode 
mode)
  so we just call into the folder and expand its result.  */
 
   if ((code == NE || code == EQ)
-  && integer_zerop (arg1)
+  && (integer_zerop (arg1)
+ || integer_pow2p (arg1))
   && (TYPE_PRECISION (ops->type) != 1 || TYPE_UNSIGNED (ops->type)))
 {
   wide_int nz = tree_nonzero_bits (arg0);
 
-  if (wi::popcount (nz) == 1)
+  if (wi::popcount (nz) == 1
+ && (integer_zerop (arg1)
+ || wi::to_wide (arg1) == nz))
{
  tree op0;
  tree op1;
@@ -13103,11 +13106,13 @@ do_store_flag (sepops ops, rtx target, machine_mode 
mode)
  op0 = arg0;
  op1 = wide_int_to_tree (TREE_TYPE (op0), nz);
}
- enum tree_code tcode = code == NE ? NE_EXPR : EQ_EXPR;
+ enum tree_code tcode = EQ_EXPR;
+ if ((code == NE) ^ !integer_zerop (arg1))
+   tcode = NE_EXPR;
  type = lang_hooks.types.type_for_mode (mode, unsignedp);
  tree temp = fold_build2_loc (loc, BIT_AND_EXPR, TREE_TYPE (op0),
   op0, op1);
- temp = fold_single_bit_test (loc, tcode, temp, arg1, type);
+ temp = fold_single_bit_test (loc, tcode, temp, build_zero_cst (type), 
type);
  if (temp)
return expand_expr (temp, target, VOIDmode, EXPAND_NORMAL);
}
-- 
2.31.1

[Bug target/106471] -march=generic might want to remove X86_TUNE_AVOID_FALSE_DEP_FOR_BMI now

[crazylht at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106471

--- Comment #10 from Hongtao.liu  ---
The tune is added in PR62011

[Bug target/106471] -march=generic might want to remove X86_TUNE_AVOID_FALSE_DEP_FOR_BMI now

[crazylht at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106471

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #9 from Hongtao.liu  ---
lzcnt/tzcnt has been fixed since skylake, popcnt has been fixed since icelake.
At least for icelake and later intel Core processors, the errata tune is not
needed.

[Bug jit/66594] jitted code should use -mtune=native

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594

Andrew Pinski  changed:

   What|Removed |Added

 CC||helohe at bluewin dot ch

--- Comment #9 from Andrew Pinski  ---
*** Bug 107230 has been marked as a duplicate of this bug. ***

[Bug jit/107230] libgccjit rejects -march=native

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107230

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
Dup of bug 66594 really which will cause the -march= to be defaulting to native
...

*** This bug has been marked as a duplicate of bug 66594 ***

[Bug middle-end/107190] [aarch64] regression with optimization -fexpensive-optimizations

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107190

--- Comment #3 from Andrew Pinski  ---
Created attachment 55113
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55113=edit
testcase

[committed] c: Do not allow thread-local tentative definitions for C2x

[Joseph Myers]

C2x makes it clear that thread-local declarations can never be
tentative definitions (the legacy feature of C where you can e.g. do
"int i;" more than once at file scope, possibly with one of the
declarations initialized, and it counts as exactly one definition),
but are always definitions in the absence of "extern".  The wording
about external definitions was unclear in the thread-local case in C11
/ C17 (both about what counts as a tentative definition, and what is a
"definition" at all), not having been updated to cover the addition of
thread-local storage.

Implement this C2x requirement.  Arguably this is a defect fix that
would be appropriate to apply for all standard versions, but for now
the change is conditional on flag_isoc2x (however, it doesn't handle
_Thread_local / thread_local any different from GNU __thread).  Making
the change unconditional results in various TLS tests failing to
compile (gcc.dg/c11-thread-local-1.c gcc.dg/tls/thr-init-1.c
gcc.dg/tls/thr-init-2.c gcc.dg/torture/tls/thr-init-2.c
objc.dg/torture/tls/thr-init.m), though it's not clear if those tests
reflect any real code similarly trying to make use of thread-local
tentative definitions.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

gcc/c/
* c-decl.cc (diagnose_mismatched_decls): Do not handle
thread-local declarations as tentative definitions for C2x.
(finish_decl): Do not allow thread-local definition with
incomplete type for C2x.

gcc/testsuite/
* gcc.dg/c2x-thread-local-2.c: New test.

diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 945e45bff89..b5b491cf2da 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -2442,8 +2442,20 @@ diagnose_mismatched_decls (tree newdecl, tree olddecl,
  return false;
}
 
-  /* Multiple initialized definitions are not allowed (6.9p3,5).  */
-  if (DECL_INITIAL (newdecl) && DECL_INITIAL (olddecl))
+  /* Multiple initialized definitions are not allowed (6.9p3,5).
+For this purpose, C2x makes it clear that thread-local
+declarations without extern are definitions, not tentative
+definitions, whether or not they have initializers.  The
+wording before C2x was unclear; literally it would have made
+uninitialized thread-local declarations into tentative
+definitions only if they also used static, but without saying
+explicitly whether or not other cases count as
+definitions at all.  */
+  if ((DECL_INITIAL (newdecl) && DECL_INITIAL (olddecl))
+ || (flag_isoc2x
+ && DECL_THREAD_LOCAL_P (newdecl)
+ && !DECL_EXTERNAL (newdecl)
+ && !DECL_EXTERNAL (olddecl)))
{
  auto_diagnostic_group d;
  error ("redefinition of %q+D", newdecl);
@@ -5714,10 +5726,12 @@ finish_decl (tree decl, location_t init_loc, tree init,
  /* A static variable with an incomplete type
 is an error if it is initialized.
 Also if it is not file scope.
+Also if it is thread-local (in C2x).
 Otherwise, let it through, but if it is not `extern'
 then it may cause an error message later.  */
  ? (DECL_INITIAL (decl) != NULL_TREE
-|| !DECL_FILE_SCOPE_P (decl))
+|| !DECL_FILE_SCOPE_P (decl)
+|| (flag_isoc2x && DECL_THREAD_LOCAL_P (decl)))
  /* An automatic variable with an incomplete type
 is an error.  */
  : !DECL_EXTERNAL (decl)))
diff --git a/gcc/testsuite/gcc.dg/c2x-thread-local-2.c 
b/gcc/testsuite/gcc.dg/c2x-thread-local-2.c
new file mode 100644
index 000..d199ff23848
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c2x-thread-local-2.c
@@ -0,0 +1,40 @@
+/* Test that thread-local declarations are not considered tentative definitions
+   in C2x.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c2x -pedantic-errors" } */
+
+thread_local int a; /* { dg-message "previous" } */
+thread_local int a; /* { dg-error "redefinition" } */
+
+static thread_local int b; /* { dg-message "previous" } */
+static thread_local int b; /* { dg-error "redefinition" } */
+
+thread_local int c; /* { dg-message "previous" } */
+thread_local int c = 1; /* { dg-error "redefinition" } */
+
+static thread_local int d; /* { dg-message "previous" } */
+static thread_local int d = 1; /* { dg-error "redefinition" } */
+
+thread_local int e = 1; /* { dg-message "previous" } */
+thread_local int e; /* { dg-error "redefinition" } */
+
+static thread_local int f = 1; /* { dg-message "previous" } */
+static thread_local int f; /* { dg-error "redefinition" } */
+
+/* Not being a tentative definition means that incomplete arrays are an error
+   rather than defaulting to size 1.  */
+thread_local int g[]; /* { dg-error "storage size" } */
+static thread_local int h[]; /* { dg-error "array size missing" } */
+extern thread_local int i[];
+
+thread_local int 

[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

[adelson.oliveira at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109641

--- Comment #19 from Adelson Oliveira  ---
Thank you all

Em qui., 18 de mai. de 2023 às 14:01, anlauf at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> escreveu:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109641
>
> anlauf at gcc dot gnu.org changed:
>
>What|Removed |Added
>
> 
>  Status|ASSIGNED|RESOLVED
>Target Milestone|--- |13.2
>  Resolution|--- |FIXED
>
> --- Comment #18 from anlauf at gcc dot gnu.org ---
> Fixed on mainline for gcc-14, and backported to 13-branch.  Closing.
>
> Thanks for the report!
>
> --
> You are receiving this mail because:
> You reported the bug.

Re: RISC-V Test Errors and Failures

[Vineet Gupta]

On 5/17/23 00:52, Andreas Schwab wrote:

On Mai 16 2023, Vineet Gupta wrote:


Yes I was seeing similar tcl errors and such - and in my case an even
higher count.

They are coming from commit d6654a4be3b.



As of a726d007f197 today I get a gazzilion splat for riscv multilib 
dejagnu runs and over 5k fails


ERROR: torture-init: torture_without_loops is not empty as expected
ERROR: tcl error code NONE
...
...
   = Summary of gcc testsuite =
    | # of unexpected case / # of unique 
unexpected case

    |  gcc |  g++ | gfortran |
 rv64imafdc/  lp64d/ medlow | 5033 / 4 |    1 / 1 |   72 /    12 |
 rv32imafdc/ ilp32d/ medlow | 5032 / 3 |    3 / 2 |   72 /    12 |
   rv32imac/  ilp32/ medlow |    1 / 1 |    3 / 2 |  109 /    19 |
   rv64imac/   lp64/ medlow | 5034 / 5 |    1 / 1 |  109 /    19 |

For a non multilib run things are sane:

   = Summary of gcc testsuite =
    | # of unexpected case / # of unique 
unexpected case

    |  gcc |  g++ | gfortran |
 rv64imafdc/  lp64d/ medlow |   11 / 4 |    1 / 1 |   72 /    12 |

It is really hard to test anything on upstream ATM.

-Vineet

[Bug c++/106810] Unexpected constraint recursion

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106810

--- Comment #1 from Andrew Pinski  ---
Reduced down just this:
```
template 
  concept t = requires(a aa, b bb) { aa == bb; };

template 
struct I {
  using value_type = int;
  using difference_type = int;

  value_type& operator*() const;
  I& operator++();
  I operator++(int);

  template S>
  friend bool operator==(I, S);
};

static_assert(t>);
```

I think GCC is correct in saying this is recusive even.

[Bug target/106471] -mpcu=generic might want to remove X86_TUNE_AVOID_FALSE_DEP_FOR_BMI now

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106471

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-05-18
 Status|UNCONFIRMED |NEW
Summary|Strange code generation for |-mpcu=generic might want to
   |__builtin_ctzl()|remove
   ||X86_TUNE_AVOID_FALSE_DEP_FO
   ||R_BMI now
 Ever confirmed|0   |1

--- Comment #8 from Andrew Pinski  ---
Confirmed. I will let someone else make the decision on when this happens.

gcc-11-20230518 is now available

[GCC Administrator via Gcc]

Snapshot gcc-11-20230518 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20230518/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-11 revision ae5112f230f05e8a693931a44bf2fd20bef58f85

You'll find:

 gcc-11-20230518.tar.xz   Complete GCC

  SHA256=69133190a97bcfb2ab5da7e7144ede77866bcc7e62009ce274a6ee05532b23f8
  SHA1=07d94c79a121eefbed058672e1e5ae137313f992

Diffs from 11-20230511 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-11
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug c++/108321] [13 regression] g++.dg/contracts/contracts-tmpl-spec2.C fails after r13-4160-g2efb237ffc68ec

[seurer at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108321

--- Comment #4 from seurer at gcc dot gnu.org ---
*** Bug 107915 has been marked as a duplicate of this bug. ***

[Bug other/107915] new test case g++.dg/contracts/contracts-tmpl-spec2.C in r13-4160-g2efb237ffc68ec fails

[seurer at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107915

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #1 from seurer at gcc dot gnu.org ---
A PR on this was opened twice.

*** This bug has been marked as a duplicate of bug 108321 ***

[Bug c++/108321] [13 regression] g++.dg/contracts/contracts-tmpl-spec2.C fails after r13-4160-g2efb237ffc68ec

[seurer at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108321

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED
   Last reconfirmed||2023-05-18
 Ever confirmed|0   |1

--- Comment #3 from seurer at gcc dot gnu.org ---
The problem with g++.dg/contracts/contracts-tmpl-spec2.C has never been fixed
as far as I can tell.  It definitely occurs with the current r13.

I believe the "This is fixed after r13-4290-g138ee8f7453ffd" was referring to
the other mentioned issue.


g:f48c546902802cf640c4f2802543acfdc702404f, r13-7354-gf48c546902802c
make  -k check-gcc
RUNTESTFLAGS="dg.exp=g++.dg/contracts/contracts-tmpl-spec2.C"
FAIL: g++.dg/contracts/contracts-tmpl-spec2.C   output pattern test
# of expected passes2
# of unexpected failures1


FAIL: g++.dg/contracts/contracts-tmpl-spec2.C   output pattern test
Output was:
contract violation in function body at
g++.dg/contracts/contracts-tmpl-spec2.C:9: a > 0
[continue:on]
-2
contract violation in function body at
g++.dg/contracts/contracts-tmpl-spec2.C:17: a > 1
[continue:on]
-3
contract violation in function none at
g++.dg/contracts/contracts-tmpl-spec2.C:25: a > 0
[continue:on]
1
contract violation in function none at
g++.dg/contracts/contracts-tmpl-spec2.C:32: a > 1
[continue:on]
-101
contract violation in function arg0 at
g++.dg/contracts/contracts-tmpl-spec2.C:39: t > 0
[continue:on]
-9
contract violation in function arg0 at
g++.dg/contracts/contracts-tmpl-spec2.C:46: t > 1
[continue:on]
11
contract violation in function arg1 at
g++.dg/contracts/contracts-tmpl-spec2.C:53: a > 0
[continue:on]
contract violation in function arg1 at
g++.dg/contracts/contracts-tmpl-spec2.C:54: t > 0
[continue:on]
-3
contract violation in function arg1 at
g++.dg/contracts/contracts-tmpl-spec2.C:61: a > 1
[continue:on]
contract violation in function arg1 at
g++.dg/contracts/contracts-tmpl-spec2.C:62: t > 1
[continue:on]
14
contract violation in function ret at
g++.dg/contracts/contracts-tmpl-spec2.C:69: a > 0
[continue:on]
1
contract violation in function ret at
g++.dg/contracts/contracts-tmpl-spec2.C:76: a > 1
[continue:on]
3
contract violation in function ret at
g++.dg/contracts/contracts-tmpl-spec2.C:76: a > 1
[continue:on]
3.30
contract violation in function g1 at
g++.dg/contracts/contracts-tmpl-spec2.C:83: t > 0
[continue:on]
-1
-1
contract violation in function g2 at
g++.dg/contracts/contracts-tmpl-spec2.C:97: t > 0
[continue:on]
-1
contract violation in function g2 at
g++.dg/contracts/contracts-tmpl-spec2.C:107: t < 0
[continue:on]
1
contract violation in function g2 at
g++.dg/contracts/contracts-tmpl-spec2.C:114: t < 'c'
[continue:on]
100
contract violation in function G3::f at
g++.dg/contracts/contracts-tmpl-spec2.C:124: t > 0
[continue:on]
contract violation in function G3::f at
g++.dg/contracts/contracts-tmpl-spec2.C:125: s > 0
[continue:on]
G3 general T S
contract violation in function G3::f at
g++.dg/contracts/contracts-tmpl-spec2.C:139: t > 1
[continue:on]
contract violation in function G3::f at
g++.dg/contracts/contracts-tmpl-spec2.C:140: s > 1
[continue:on]
G3 partial int S
contract violation in function G3::f at
g++.dg/contracts/contracts-tmpl-spec2.C:147: t > 2
[continue:on]
contract violation in function G3::f at
g++.dg/contracts/contracts-tmpl-spec2.C:148: s > 2
[continue:on]
G3 full int double
G3 general T S
contract violation in function G3::f at
g++.dg/contracts/contracts-tmpl-spec2.C:139: t > 1
[continue:on]
G3 partial int S
G3 full int C
G3 full int C
contract violation in function G4::G4 at
g++.dg/contracts/contracts-tmpl-spec2.C:173: t > 0
[continue:on]
contract violation in function G4::G4 at
g++.dg/contracts/contracts-tmpl-spec2.C:174: s > 0
[continue:on]
G4 general T S
contract violation in function G4::G4 at
g++.dg/contracts/contracts-tmpl-spec2.C:175: x > 0
[continue:on]
G4 full double double
contract violation in function G4::G4 at
g++.dg/contracts/contracts-tmpl-spec2.C:206: a > 0
[continue:on]
contract violation in function G4::G4 at
g++.dg/contracts/contracts-tmpl-spec2.C:207: b > 'b'
[continue:on]
G4 full double char
contract violation in function G4::G4 at
g++.dg/contracts/contracts-tmpl-spec2.C:208: x > 1
[continue:on]
contract violation in function G4::G4 at
g++.dg/contracts/contracts-tmpl-spec2.C:187: t > 'c'
[continue:on]
contract violation in function G4::G4 at
g++.dg/contracts/contracts-tmpl-spec2.C:188: s > 3
[continue:on]
G4 partial char S
contract violation in function G4::G4 at
g++.dg/contracts/contracts-tmpl-spec2.C:189: x2 > 3
[continue:on]
contract violation in function G5::f at
g++.dg/contracts/contracts-tmpl-spec2.C:220: t > 0
[continue:on]
contract violation in function G5::f at
g++.dg/contracts/contracts-tmpl-spec2.C:221: s > 0

Re: [PING] [C PATCH] Fix ICEs related to VM types in C [PR106465, PR107557, PR108423, PR109450]

[Joseph Myers]

On Thu, 18 May 2023, Martin Uecker via Gcc-patches wrote:

> +  /* we still have to evaluate size expressions */

Comments should start with a capital letter and end with ".  ".

> diff --git a/gcc/testsuite/gcc.dg/nested-vla-1.c 
> b/gcc/testsuite/gcc.dg/nested-vla-1.c
> new file mode 100644
> index 000..408a68524d8
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/nested-vla-1.c
> @@ -0,0 +1,37 @@
> +/* { dg-do run } */
> +/* { dg-options "-std=gnu99" } */

I'm concerned with various undefined behavior in this and other tests; 
they look very fragile, relying on some optimizations and not others 
taking place.  I think they should be adjusted to avoid undefined behavior 
if all the evaluations from the abstract machine (in particular, of sizeof 
operands with variable size) take place, and other undefined behavior from 
calling functions through function pointers with incompatible type.

> + struct bar { char x[++n]; } (*bar2)(void) = bar;/* { dg-warning 
> "incompatible pointer type" } */
> +
> + if (2 != n)
> + __builtin_abort();
> +
> + if (2 != sizeof((*bar2)()))
> + __builtin_abort();

You're relying on the compiler not noticing that a function is being 
called through an incompatible type and thus not turning the call (which 
should be evaluated, because the operand of sizeof has a type with 
variable size) into a call to abort.

> diff --git a/gcc/testsuite/gcc.dg/nested-vla-2.c 
> b/gcc/testsuite/gcc.dg/nested-vla-2.c
> new file mode 100644
> index 000..504eec48c80
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/nested-vla-2.c
> @@ -0,0 +1,33 @@
> +/* { dg-do run } */
> +/* { dg-options "-std=gnu99" } */
> +
> +
> +int main()
> +{
> + int n = 1;
> +
> + typeof(char (*)[++n]) bar(void) { }
> +
> + if (2 != n)
> + __builtin_abort();
> +
> + if (2 != sizeof(*bar()))
> + __builtin_abort();

In this test, *bar() is evaluated, i.e. an undefined pointer is 
dereferenced; it would be better to return a valid pointer to a 
sufficiently large array to avoid that undefined behavior.

> diff --git a/gcc/testsuite/gcc.dg/pr106465.c b/gcc/testsuite/gcc.dg/pr106465.c
> new file mode 100644
> index 000..b03e2442f12
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr106465.c
> @@ -0,0 +1,86 @@
> +/* PR c/106465
> + * { dg-do run }
> + * { dg-options "-std=gnu99" }
> + * */
> +
> +int main()
> +{
> + int n = 3;
> + 
> + void g1(int m, struct { char p[++m]; }* b)  /* { dg-warning 
> "anonymous struct" } */
> + {
> + if (3 != m)
> + __builtin_abort();
> +
> + if (3 != sizeof(b->p))
> + __builtin_abort();
> + }

> + g1(2, (void*)0);

Similarly, this is dereferencing a null pointer in the evaluated operand 
of sizeof.

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

Re: [PATCH] rs6000: Fix __builtin_vec_xst_trunc definition

[Carl Love via Gcc-patches]

Peter:

On Thu, 2023-05-18 at 16:28 -0500, Peter Bergner wrote:
> 



> 
> > +  void __builtin_vec_xst_trunc (vsq, signed long long, signed long
> > *);
> > +TR_STXVRLX  TR_STXVRLX_S
> > +  void __builtin_vec_xst_trunc (vuq, signed long long, unsigned
> > long *);
> > +TR_STXVRLX  TR_STXVRLX_U
> 
> Not a comment on these two changes, and not a request to expand this
> specific patch, but I believe I saw other built-ins that were missing
> signed long */unsigned long * versions where they could/should accept
> them.  Can you double-check whether there are other built-ins that
> need similar changes and if so, please post a separate patch to fix
> those as well?  Thanks.

OK, I will put that on my to do list to go look for that in other
builtins.  

 Carl 

Re: [PATCH] rs6000: Fix __builtin_vec_xst_trunc definition

[Peter Bergner via Gcc-patches]

On 5/10/23 1:06 PM, Carl Love wrote:
> -  void __builtin_altivec_tr_stxvrhx (vsq, signed long, signed int *);
> +  void __builtin_altivec_tr_stxvrhx (vsq, signed long, signed short *);
>  TR_STXVRHX vsx_stxvrhx {stvec}
>  
> -  void __builtin_altivec_tr_stxvrwx (vsq, signed long, signed short *);
> +  void __builtin_altivec_tr_stxvrwx (vsq, signed long, signed int *);
>  TR_STXVRWX vsx_stxvrwx {stvec}

In my estimation, these two changes are "obvious" fixes.




> +  void __builtin_vec_xst_trunc (vsq, signed long long, signed long *);
> +TR_STXVRLX  TR_STXVRLX_S
> +  void __builtin_vec_xst_trunc (vuq, signed long long, unsigned long *);
> +TR_STXVRLX  TR_STXVRLX_U

Not a comment on these two changes, and not a request to expand this
specific patch, but I believe I saw other built-ins that were missing
signed long */unsigned long * versions where they could/should accept
them.  Can you double-check whether there are other built-ins that
need similar changes and if so, please post a separate patch to fix
those as well?  Thanks.

Peter

[PATCH v2] rs6000: Add buildin for mffscrn instructions

[Carl Love via Gcc-patches]

GCC maintainers:

version 2.  Fixed an issue with the test case.  The dg-options line was
missing.

The following patch adds an overloaded builtin.  There are two possible
arguments for the builtin.  The builtin definitions are:

  double __builtin_mffscrn (unsigned long int);
  double __builtin_mffscrn (double);

The patch has been tested on Power 10 with no regressions.  

Please let me know if the patch is acceptable for mainline.  Thanks.

Carl


rs6000: Add buildin for mffscrn instructions

This patch adds overloaded __builtin_mffscrn for the move From FPSCR
Control & Set R instruction with an immediate argument.  It also adds the
builtin with a floating point register argument.  A new runnable test is
added for the new builtin.

gcc/

* config/rs6000/rs6000-builtins.def (__builtin_mffscrni,
__builtin_mffscrnd): Add builtin definitions.
* config/rs6000/rs6000-overload.def (__builtin_mffscrn): Add
overloaded definition.
* doc/extend.texi: Add documentation for __builtin_mffscrn.

gcc/testsuite/

* gcc.target/powerpc/builtin-mffscrn.c: Add testcase for new
builtin.
---
 gcc/config/rs6000/rs6000-builtins.def |   7 ++
 gcc/config/rs6000/rs6000-overload.def |   5 +
 gcc/doc/extend.texi   |   8 ++
 .../gcc.target/powerpc/builtin-mffscrn.c  | 106 ++
 4 files changed, 126 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/builtin-mffscrn.c

diff --git a/gcc/config/rs6000/rs6000-builtins.def 
b/gcc/config/rs6000/rs6000-builtins.def
index 92d9b46e1b9..67125473684 100644
--- a/gcc/config/rs6000/rs6000-builtins.def
+++ b/gcc/config/rs6000/rs6000-builtins.def
@@ -2875,6 +2875,13 @@
   pure vsc __builtin_vsx_xl_len_r (void *, signed long);
 XL_LEN_R xl_len_r {}
 
+; Immediate instruction only uses the least significant two bits of the
+; const int.
+  double __builtin_mffscrni (const int<2>);
+MFFSCRNI rs6000_mffscrni {}
+
+  double __builtin_mffscrnd (double);
+MFFSCRNF rs6000_mffscrn {}
 
 ; Builtins requiring hardware support for IEEE-128 floating-point.
 [ieee128-hw]
diff --git a/gcc/config/rs6000/rs6000-overload.def 
b/gcc/config/rs6000/rs6000-overload.def
index c582490c084..adda2df69ea 100644
--- a/gcc/config/rs6000/rs6000-overload.def
+++ b/gcc/config/rs6000/rs6000-overload.def
@@ -78,6 +78,11 @@
 ; like after a required newline, but nowhere else.  Lines beginning with
 ; a semicolon are also treated as blank lines.
 
+[MFFSCR, __builtin_mffscrn, __builtin_mffscrn]
+  double __builtin_mffscrn (const int<2>);
+MFFSCRNI
+  double __builtin_mffscrn (double);
+MFFSCRNF
 
 [BCDADD, __builtin_bcdadd, __builtin_vec_bcdadd]
   vsq __builtin_vec_bcdadd (vsq, vsq, const int);
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index ed8b9c8a87b..f16c046051a 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -18455,6 +18455,9 @@ int __builtin_dfp_dtstsfi_ov_td (unsigned int 
comparison, _Decimal128 value);
 
 double __builtin_mffsl(void);
 
+double __builtin_mffscrn (unsigned long int);
+double __builtin_mffscrn (double);
+
 @end smallexample
 The @code{__builtin_byte_in_set} function requires a
 64-bit environment supporting ISA 3.0 or later.  This function returns
@@ -18511,6 +18514,11 @@ the FPSCR.  The instruction is a lower latency version 
of the @code{mffs}
 instruction.  If the @code{mffsl} instruction is not available, then the
 builtin uses the older @code{mffs} instruction to read the FPSCR.
 
+The @code{__builtin_mffscrn} returns the contents of the control bits in the
+FPSCR, bits 29:31 (DRN) and bits 56:63 (VE, OE, UE, ZE, XE, NI, RN).  The
+contents of bits [62:63] of the unsigned long int or double argument are placed
+into bits [62:63] of the FPSCR (RN).
+
 @node Basic PowerPC Built-in Functions Available on ISA 3.1
 @subsubsection Basic PowerPC Built-in Functions Available on ISA 3.1
 
diff --git a/gcc/testsuite/gcc.target/powerpc/builtin-mffscrn.c 
b/gcc/testsuite/gcc.target/powerpc/builtin-mffscrn.c
new file mode 100644
index 000..26c666a4091
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/builtin-mffscrn.c
@@ -0,0 +1,106 @@
+/* { dg-do run } */
+/* { dg-require-effective-target p9vector_hw } */
+/* { dg-options "-mpower9-vector -mdejagnu-cpu=power9" } */
+
+#include 
+
+#ifdef DEBUG
+#include 
+#endif
+
+#define MASK 0x3
+#define EXPECTED1 0x1
+#define EXPECTED2 0x2
+
+void abort (void);
+
+int
+main()
+{
+  unsigned long mask, result, expected;
+  double double_arg;
+  
+  union convert_t {
+double d;
+unsigned long ul;
+  } val;
+
+  /* Test immediate version of __builtin_mffscrn. */
+  /* Read FPSCR and set RN bits in FPSCR[62:63]. */
+  val.d = __builtin_mffscrn (EXPECTED2);
+
+  /* Read FPSCR, bits [62:63] should have been set to 0x2 by previous builtin
+ call.  */
+  val.d = __builtin_mffscrn (EXPECTED1);
+  /* The expected result is the 

[Bug libgomp/109904] linking with -static flag generates undefined references

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904

--- Comment #10 from Jakub Jelinek  ---
Offloading doesn't work for 32-bit architectures, the offloading target needs
to have the same wordsize as the host and e.g. nvptx 32-bit support has been
deprecated and removed some years ago.
So, don't configure offloading for 32-bit architectures.

As for  adding -ldl automatically for -static linking, I think we should do:
2023-05-18  Jakub Jelinek  

PR libgomp/109904
* configure.ac (link_gomp): Include also $DL_LIBS.
* configure: Regenerated.

--- libgomp/configure.ac.jj 2023-05-15 19:12:35.138624638 +0200
+++ libgomp/configure.ac2023-05-18 20:41:58.512501769 +0200
@@ -398,9 +398,9 @@ fi
 # which will force linkage against -lpthread (or equivalent for the system).
 # That's not 100% ideal, but about the best we can do easily.
 if test $enable_shared = yes; then
-  link_gomp="-lgomp %{static: $LIBS}"
+  link_gomp="-lgomp %{static: $LIBS${DL_LIBS:+ $DL_LIBS}}"
 else
-  link_gomp="-lgomp $LIBS"
+  link_gomp="-lgomp $LIBS${DL_LIBS:+ $DL_LIBS}"
 fi
 AC_SUBST(link_gomp)

--- libgomp/configure.jj2023-05-15 19:12:35.138624638 +0200
+++ libgomp/configure   2023-05-18 20:42:12.703299052 +0200
@@ -16788,9 +16788,9 @@ fi
 # which will force linkage against -lpthread (or equivalent for the system).
 # That's not 100% ideal, but about the best we can do easily.
 if test $enable_shared = yes; then
-  link_gomp="-lgomp %{static: $LIBS}"
+  link_gomp="-lgomp %{static: $LIBS${DL_LIBS:+ $DL_LIBS}}"
 else
-  link_gomp="-lgomp $LIBS"
+  link_gomp="-lgomp $LIBS${DL_LIBS:+ $DL_LIBS}"
 fi

[Bug libgomp/109904] linking with -static flag generates undefined references

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904

--- Comment #9 from Andrew Pinski  ---
See https://gcc.gnu.org/install/binaries.html 

Specifically: "Please note that we did not create these binaries, nor do we
support them. If you have any problems installing them, please contact their
makers."

[PATCH] c-family: implement -ffp-contract=on

[Alexander Monakov via Gcc-patches]

Implement -ffp-contract=on for C and C++ without changing default
behavior (=off for -std=cNN, =fast for C++ and -std=gnuNN).

gcc/c-family/ChangeLog:

* c-gimplify.cc (fma_supported_p): New helper.
(c_gimplify_expr) [PLUS_EXPR, MINUS_EXPR]: Implement FMA
contraction.

gcc/ChangeLog:

* common.opt (fp_contract_mode) [on]: Remove fallback.
* config/sh/sh.md (*fmasf4): Correct flag_fp_contract_mode test.
* doc/invoke.texi (-ffp-contract): Update.
* trans-mem.cc (diagnose_tm_1): Skip internal function calls.
---
 gcc/c-family/c-gimplify.cc | 78 ++
 gcc/common.opt |  3 +-
 gcc/config/sh/sh.md|  2 +-
 gcc/doc/invoke.texi|  8 ++--
 gcc/trans-mem.cc   |  3 ++
 5 files changed, 88 insertions(+), 6 deletions(-)

diff --git a/gcc/c-family/c-gimplify.cc b/gcc/c-family/c-gimplify.cc
index ef5c7d919f..f7635d3b0c 100644
--- a/gcc/c-family/c-gimplify.cc
+++ b/gcc/c-family/c-gimplify.cc
@@ -41,6 +41,8 @@ along with GCC; see the file COPYING3.  If not see
 #include "c-ubsan.h"
 #include "tree-nested.h"
 #include "context.h"
+#include "tree-pass.h"
+#include "internal-fn.h"
 
 /*  The gimplification pass converts the language-dependent trees
 (ld-trees) emitted by the parser into language-independent trees
@@ -686,6 +688,14 @@ c_build_bind_expr (location_t loc, tree block, tree body)
   return bind;
 }
 
+/* Helper for c_gimplify_expr: test if target supports fma-like FN.  */
+
+static bool
+fma_supported_p (enum internal_fn fn, tree type)
+{
+  return direct_internal_fn_supported_p (fn, type, OPTIMIZE_FOR_BOTH);
+}
+
 /* Gimplification of expression trees.  */
 
 /* Do C-specific gimplification on *EXPR_P.  PRE_P and POST_P are as in
@@ -739,6 +749,74 @@ c_gimplify_expr (tree *expr_p, gimple_seq *pre_p 
ATTRIBUTE_UNUSED,
break;
   }
 
+case PLUS_EXPR:
+case MINUS_EXPR:
+  {
+   tree type = TREE_TYPE (*expr_p);
+   /* For -ffp-contract=on we need to attempt FMA contraction only
+  during initial gimplification.  Late contraction across statement
+  boundaries would violate language semantics.  */
+   if (SCALAR_FLOAT_TYPE_P (type)
+   && flag_fp_contract_mode == FP_CONTRACT_ON
+   && cfun && !(cfun->curr_properties & PROP_gimple_any)
+   && fma_supported_p (IFN_FMA, type))
+ {
+   bool neg_mul = false, neg_add = code == MINUS_EXPR;
+
+   tree *op0_p = _OPERAND (*expr_p, 0);
+   tree *op1_p = _OPERAND (*expr_p, 1);
+
+   /* Look for ±(x * y) ± z, swapping operands if necessary.  */
+   if (TREE_CODE (*op0_p) == NEGATE_EXPR
+   && TREE_CODE (TREE_OPERAND (*op0_p, 0)) == MULT_EXPR)
+ /* '*EXPR_P' is '-(x * y) ± z'.  This is fine.  */;
+   else if (TREE_CODE (*op0_p) != MULT_EXPR)
+ {
+   std::swap (op0_p, op1_p);
+   std::swap (neg_mul, neg_add);
+ }
+   if (TREE_CODE (*op0_p) == NEGATE_EXPR)
+ {
+   op0_p = _OPERAND (*op0_p, 0);
+   neg_mul = !neg_mul;
+ }
+   if (TREE_CODE (*op0_p) != MULT_EXPR)
+ break;
+   auto_vec ops (3);
+   ops.quick_push (TREE_OPERAND (*op0_p, 0));
+   ops.quick_push (TREE_OPERAND (*op0_p, 1));
+   ops.quick_push (*op1_p);
+
+   enum internal_fn ifn = IFN_FMA;
+   if (neg_mul)
+ {
+   if (fma_supported_p (IFN_FNMA, type))
+ ifn = IFN_FNMA;
+   else
+ ops[0] = build1 (NEGATE_EXPR, type, ops[0]);
+ }
+   if (neg_add)
+ {
+   enum internal_fn ifn2 = ifn == IFN_FMA ? IFN_FMS : IFN_FNMS;
+   if (fma_supported_p (ifn2, type))
+ ifn = ifn2;
+   else
+ ops[2] = build1 (NEGATE_EXPR, type, ops[2]);
+ }
+   for (auto & : ops)
+ if (gimplify_expr (, pre_p, post_p, is_gimple_val, fb_rvalue)
+ == GS_ERROR)
+   return GS_ERROR;
+
+   gcall *call = gimple_build_call_internal_vec (ifn, ops);
+   gimple_seq_add_stmt_without_update (pre_p, call);
+   *expr_p = create_tmp_var (type);
+   gimple_call_set_lhs (call, *expr_p);
+   return GS_ALL_DONE;
+ }
+   break;
+  }
+
 default:;
 }
 
diff --git a/gcc/common.opt b/gcc/common.opt
index a28ca13385..3daec85aef 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1662,9 +1662,8 @@ Name(fp_contract_mode) Type(enum fp_contract_mode) 
UnknownError(unknown floating
 EnumValue
 Enum(fp_contract_mode) String(off) Value(FP_CONTRACT_OFF)
 
-; Not implemented, fall back to conservative FP_CONTRACT_OFF.
 EnumValue
-Enum(fp_contract_mode) String(on) Value(FP_CONTRACT_OFF)
+Enum(fp_contract_mode) String(on) Value(FP_CONTRACT_ON)
 
 EnumValue
 

[Bug libgomp/109904] linking with -static flag generates undefined references

[Gary.White at ColoState dot edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904

--- Comment #8 from GARY.WHITE at ColoState dot edu  ---
So send me the link where I should get the binaries from.


Gary C. White, CWB(r)
Professor Emeritus
Department of Fish, Wildlife, and Conservation Biology
10 Wagar
Colorado State University
Fort Collins, CO 80523
(515)450-2768 Mobile
gary.wh...@colostate.edu
https://sites.warnercnr.colostate.edu/gwhite/
he/him/his

See where we are!

"Leadership is a privilege to better the lives of others. It is not an
opportunity to satisfy personal greed." Mwai Kibaki

-Original Message-
From: pinskia at gcc dot gnu.org 
Sent: Thursday, May 18, 2023 2:59 PM
To: White,Gary 
Subject: [Bug libgomp/109904] linking with -static flag generates undefined
references

** Caution: EXTERNAL Sender **

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904

--- Comment #7 from Andrew Pinski  --- (In reply to
gary.wh...@colostate.edu from comment #6)
> So using -ldl seems really quirky.  Doesn't seem to work for
> generating 32-bit executables.  Plus, not working at all on my second
> machine.  Is there a better solution?

Yes use a differently built gcc where libgomp does NOT depend on dl* functions.
Again this is not the right place to report these issues, the correct place is
where you got the binary GCC from. In your case that would be
https://github.com/brechtsanders/winlibs_mingw/issues .

--
You are receiving this mail because:
You reported the bug.

[Bug libgomp/109904] linking with -static flag generates undefined references

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904

--- Comment #7 from Andrew Pinski  ---
(In reply to gary.wh...@colostate.edu from comment #6)
> So using -ldl seems really quirky.  Doesn't seem to work for generating
> 32-bit executables.  Plus, not working at all on my second machine.  Is
> there a better solution?

Yes use a differently built gcc where libgomp does NOT depend on dl* functions.
Again this is not the right place to report these issues, the correct place is
where you got the binary GCC from. In your case that would be
https://github.com/brechtsanders/winlibs_mingw/issues .

Re: [wish] Flexible array members in unions

[Qing Zhao via Gcc]

> On May 18, 2023, at 12:25 PM, Martin Uecker via Gcc  wrote:
> 
> 
> 
>> On Thu, May 11, 2023 at 11:14 PM Kees Cook via Gcc  wrote:
>>> 
>>> On Thu, May 11, 2023 at 08:53:52PM +, Joseph Myers wrote:
 On Thu, 11 May 2023, Kees Cook via Gcc wrote:
 
> On Thu, May 11, 2023 at 06:29:10PM +0200, Alejandro Colomar wrote:
>> On 5/11/23 18:07, Alejandro Colomar wrote:
>> [...]
>>> Would you allow flexible array members in unions?  Is there any
>>> strong reason to disallow them?
> 
> Yes please!! And alone in a struct, too.
> 
> AFAICT, there is no mechanical/architectural reason to disallow them
> (especially since they _can_ be constructed with some fancy tricks,
> and they behave as expected.) My understanding is that it's disallowed
> due to an overly strict reading of the very terse language that created
> flexible arrays in C99.
 
 Standard C has no such thing as a zero-size object or type, which would
 lead to problems with a struct or union that only contains a flexible
 array member there.
> 
> (I think it is fundamentally not too problematic to have zero-size
> objects, although it would take some work to specify the semantics
> exactly.)
> 
> But my preference would be to make structs / unions with FAM an
> incomplete type which would then restrict their use (for the cases
> now supported we would need backwards compatible exceptions).
> We could then allow such a struct / union as the last member
> of another struct / union which would make this an incomplete
> type too.

Yes, I like this approach. 
And we can make them GCC extensions first,  promote to C standard later.

My proposed patch sets (originally targeted on GCC13, now might need to target 
on GCC14) will
make one part of the above a GCC extension:
Allowing the struct with FAM as the last member of another struct. (See 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832)

https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614794.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614793.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614790.html

I’d like these changes going into GCC first to improve this area.

> 
> We then would need a special macro (based on a builtin) instead
> of sizeof to get the size, but this would be safer anyway.
> 
> In principle, an even better solution would be to allow dynamic
> arrays because then it has a dynamic bound where the type with
> the bound could propagate to some user. Bounds checking would
> work as expected and more cases.
> 
> struct foo {
>  int len;
>  char buf[.len];
> };
> 
> But this takes a bit more work to get right.
> 
>>> 
>>> Ah-ha, okay. That root cause makes sense now.
>> 
>> Hmm. but then the workaround
>> 
>> struct X {
>>  int n;
>>  union u {
>>  char at_least_size_one;
>>  int iarr[];
>>  short sarr[];
>>  };
>> };
>> 
>> doesn't work either.  We could make that a GNU extension without
>> adverse effects?
> 
> I think we could allow this even without the "at_least_size_one"
> without a problem when allowing the use of such unions only as
> a last member of some structure. Allowing it elsewhere seems
> questionable anyway.

Yes,  Such an union can be treated as an flexible array member 
(just multiple flexible arrays sharing the same storage).  Therefore it’s 
reasonable
To only allow it as the last field of a structure. 

thanks.

Qing.

> 
>> Richard.
>> 
>>> Why are zero-sized objects missing in Standard C? Or, perhaps, the better
>>> question is: what's needed to support the idea of a zero-sized object?
> 
> Probably a lot of convincing that it actually does not cause problems,
> and is useful. Also a lot of work in making sure the standard is revised
> everywhere where it is necessary. I think zero sized objects and
> especially arrays are very useful also to avoid special code for corner
> cases in numerical algorithms. But I think here some restrictions on
> the use of the FAM will do.
> 
> 
> Martin

[PATCH] RISC-V: improve codegen for large constants with same 32-bit lo and hi parts [2]

[Vineet Gupta]

[part #2 of PR/109279]

SPEC2017 deepsjeng uses large constants which currently generates less than
ideal code. This fix improves codegen for large constants which have
same low and hi parts: e.g.

long long f(void) { return 0x0101010101010101ull; }

Before
li  a5,0x101
addia5,a5,0x101
mv  a0,a5
sllia5,a5,32
add a0,a5,a0
ret

With patch
li  a5,0x101
addia5,a5,0x101
sllia0,a5,32
add a0,a0,a5
ret

This is testsuite clean.

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_split_integer): if loval is equal
  to hival, ASHIFT the corresponding regs.

Signed-off-by: Vineet Gupta 
---
 gcc/config/riscv/riscv.cc | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 79122699b6f5..4e1bb2f14cf8 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -703,13 +703,18 @@ riscv_split_integer (HOST_WIDE_INT val, machine_mode mode)
   unsigned HOST_WIDE_INT hival = sext_hwi ((val - loval) >> 32, 32);
   rtx hi = gen_reg_rtx (mode), lo = gen_reg_rtx (mode);
 
-  riscv_move_integer (hi, hi, hival, mode);
   riscv_move_integer (lo, lo, loval, mode);
 
-  hi = gen_rtx_fmt_ee (ASHIFT, mode, hi, GEN_INT (32));
-  hi = force_reg (mode, hi);
+  if (loval == hival)
+  hi = gen_rtx_ASHIFT (mode, lo, GEN_INT (32));
+  else
+{
+  riscv_move_integer (hi, hi, hival, mode);
+  hi = gen_rtx_ASHIFT (mode, hi, GEN_INT (32));
+}
 
-  return gen_rtx_fmt_ee (PLUS, mode, hi, lo);
+  hi = force_reg (mode, hi);
+  return gen_rtx_PLUS (mode, hi, lo);
 }
 
 /* Return true if X is a thread-local symbol.  */
-- 
2.34.1

[Bug libgomp/109904] linking with -static flag generates undefined references

[Gary.White at ColoState dot edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904

--- Comment #6 from GARY.WHITE at ColoState dot edu  ---
So using -ldl seems really quirky.  Doesn't seem to work for generating 32-bit
executables.  Plus, not working at all on my second machine.  Is there a better
solution?


Gary C. White, CWB(r)
Professor Emeritus
Department of Fish, Wildlife, and Conservation Biology
10 Wagar
Colorado State University
Fort Collins, CO 80523
(515)450-2768 Mobile
gary.wh...@colostate.edu
https://sites.warnercnr.colostate.edu/gwhite/
he/him/his

See where we are!

"Leadership is a privilege to better the lives of others. It is not an
opportunity to satisfy personal greed." Mwai Kibaki

-Original Message-
From: pinskia at gcc dot gnu.org 
Sent: Thursday, May 18, 2023 12:33 PM
To: White,Gary 
Subject: [Bug libgomp/109904] linking with -static flag generates undefined
references

** Caution: EXTERNAL Sender **

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904

--- Comment #4 from Andrew Pinski  --- (In reply to
gary.wh...@colostate.edu from comment #3)
> Linking with -ldl fixed the issue  Where is there documentation of -ldl?

-l says to link against a specified library in this case libdl; libgomp needs
to open a library at runtime due to offloading support and dl* functions do
that and for windows dl* functions are implemented in libdl-win32. But as I
mentioned you should be asking where you got the binary toolchain instead of
here.

--
You are receiving this mail because:
You reported the bug.

[Bug middle-end/101807] bool0 < bool1 Should expand as !bool0 and bool0 <= bool1 as !bool0 | bool1

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101807

--- Comment #4 from Andrew Pinski  ---
Here is what I have so far without the cost model:

  /* Hand bool0 CMP bool1 because bitwise operators
 are normally better than comparisons.  */
  if (INTEGRAL_TYPE_P (type)
  && ((tree_nonzero_bits (arg0) == 1 && tree_nonzero_bits (arg1) == 1)
  || (unsignedp && TYPE_PRECISION (type) == 1)))
{
  tree b0 = arg0;
  tree b1 = arg1;
  bool not_p = false;
  bool operand1_not_p = false;
  tree_code code = ERROR_MARK;
  switch (ops->code)
{
case EQ_EXPR:
  not_p = true;
  code = BIT_XOR_EXPR;
  break;
case NE_EXPR:
  code = BIT_XOR_EXPR;
  break;
case GT_EXPR:
  std::swap (b0, b1);
  code = BIT_AND_EXPR;
  operand1_not_p = true;
  break;
case LT_EXPR:
  code = BIT_AND_EXPR;
  operand1_not_p = true;
  break;
case GE_EXPR:
  std::swap (b0, b1);
  code = BIT_IOR_EXPR;
  operand1_not_p = true;
  break;
case LE_EXPR:
  code = BIT_IOR_EXPR;
  operand1_not_p = true;
  break;
default:
  code = ERROR_MARK;
  break;
}
  if (code != ERROR_MARK)
{
  tree exp;
  tree one = build_int_cst (type, 1);
  if (operand1_not_p)
b0 = build2_loc (loc, BIT_XOR_EXPR, type, b0, one);
  exp = build2_loc (loc, code, type, b0, b1);
  if (not_p)
exp = build2_loc (loc, BIT_XOR_EXPR, type, exp, one);
  return expand_expr (exp, target, VOIDmode, EXPAND_NORMAL);
}
}

[Bug middle-end/101807] bool0 < bool1 Should expand as !bool0 and bool0 <= bool1 as !bool0 | bool1

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101807

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> Actually I need to check the cost, e.g. on MIPS, there is an one instruction
> which does the less than without doing anything.

RISCV too ...

[Bug middle-end/101807] bool0 < bool1 Should expand as !bool0 and bool0 <= bool1 as !bool0 | bool1

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101807

--- Comment #2 from Andrew Pinski  ---
Actually I need to check the cost, e.g. on MIPS, there is an one instruction
which does the less than without doing anything.

That is for:
bool f0(bool a, bool b)
{
return a

Re: [PATCH 01/14] ada: use _P() defines from tree.h

[Bernhard Reutner-Fischer via Gcc-patches]

On Sun, 14 May 2023 17:03:55 -0600
Jeff Law  wrote:

> On 5/13/23 17:23, Bernhard Reutner-Fischer via Gcc-patches wrote:
> > From: Bernhard Reutner-Fischer 
> > 
> > gcc/ada/ChangeLog:
> > 
> > * gcc-interface/decl.cc (gnat_to_gnu_entity): Use _P defines

> The series as a whole is OK.

Thanks.
I've dropped the go and rust hunks and installed the rest (with tweaks
as requested) as r14-974-g04682fe764004b .. r14-985-gca2007a9bb3074

Re: [PATCH 01/14] ada: use _P() defines from tree.h

[Bernhard Reutner-Fischer via Gcc-patches]

On Mon, 15 May 2023 12:05:10 +0200
Eric Botcazou  wrote:

> > && DECL_RETURN_VALUE_P (inner))
> > diff --git a/gcc/ada/gcc-interface/utils.cc b/gcc/ada/gcc-interface/utils.cc
> > index 0c4f8b90c8e..460ef6f1f01 100644
> > --- a/gcc/ada/gcc-interface/utils.cc
> > +++ b/gcc/ada/gcc-interface/utils.cc
> > @@ -1966,7 +1966,7 @@ finish_record_type (tree record_type, tree field_list,
> > int rep_level, bool debug_info_p)
> >  {
> >const enum tree_code orig_code = TREE_CODE (record_type);
> > -  const bool had_size = TYPE_SIZE (record_type) != NULL_TREE;
> > +  const bool had_size = COMPLETE_TYPE_P (record_type);
> >const bool had_align = TYPE_ALIGN (record_type) > 0;
> >/* For all-repped records with a size specified, lay the QUAL_UNION_TYPE
> >   out just like a UNION_TYPE, since the size will be fixed.  */  
> 
> This one is not an improvement but more of a coincidence; the rest is OK.
> 

I've dropped this hunk and installed the rest as
r14-974-g04682fe764004b.
Thanks!

Re: [PATCH v2] Fortran: Narrow return types [PR78798]

[Bernhard Reutner-Fischer via Gcc-patches]

On Sun, 14 May 2023 14:27:42 +0200
Mikael Morin  wrote:

> Le 10/05/2023 à 18:47, Bernhard Reutner-Fischer via Fortran a écrit :
> > From: Bernhard Reutner-Fischer 
> > 
> > gcc/fortran/ChangeLog:
> > 
> > PR fortran/78798
> > * array.cc (compare_bounds): Use narrower return type.
> > (gfc_compare_array_spec): Likewise.
> > (is_constant_element): Likewise.
> > (gfc_constant_ac): Likewise.  
> (...)
> > ---
> > Bootstrapped without new warnings and regression tested on
> > x86_64-linux with no regressions, OK for trunk?
> >   
> (...)
> > diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
> > index b348bda6e6c..4e3aed84b9d 100644
> > --- a/gcc/fortran/check.cc
> > +++ b/gcc/fortran/check.cc
> > @@ -1156,7 +1156,7 @@ dim_rank_check (gfc_expr *dim, gfc_expr *array, int 
> > allow_assumed)
> >  dimension bi, returning 0 if they are known not to be identical,
> >  and 1 if they are identical, or if this cannot be determined.  */
> >   
> > -static int
> > +static bool
> >   identical_dimen_shape (gfc_expr *a, int ai, gfc_expr *b, int bi)
> >   {
> > mpz_t a_size, b_size;  
> 
> To be consistent, please change as well the local variable "ret" used as 
> return value from int to bool.
> 
> > diff --git a/gcc/fortran/cpp.cc b/gcc/fortran/cpp.cc
> > index c3b7c7f7bd9..d7890a97287 100644
> > --- a/gcc/fortran/cpp.cc
> > +++ b/gcc/fortran/cpp.cc
> > @@ -297,7 +297,7 @@ gfc_cpp_init_options (unsigned int 
> > decoded_options_count,
> > gfc_cpp_option.deferred_opt_count = 0;
> >   }
> >   
> > -int
> > +bool
> >   gfc_cpp_handle_option (size_t scode, const char *arg, int value 
> > ATTRIBUTE_UNUSED)
> >   {
> > int result = 1;  
> 
> Same here, change the type of variable "result".
> 
> (...)
> > diff --git a/gcc/fortran/dependency.cc b/gcc/fortran/dependency.cc
> > index a648d5c7903..b398b29a642 100644
> > --- a/gcc/fortran/dependency.cc
> > +++ b/gcc/fortran/dependency.cc  
> (...)
> 
> > @@ -1091,7 +1091,7 @@ gfc_check_argument_dependency (gfc_expr *other, 
> > sym_intent intent,
> >   /* Like gfc_check_argument_dependency, but check all the arguments in 
> > ACTUAL.
> >  FNSYM is the function being called, or NULL if not known.  */
> >   
> > -int
> > +bool
> >   gfc_check_fncall_dependency (gfc_expr *other, sym_intent intent,
> >  gfc_symbol *fnsym, gfc_actual_arglist *actual,
> >  gfc_dep_check elemental)  
> 
> Why not change the associated subfunctions 
> (gfc_check_argument_dependency, gfc_check_argument_var_dependency) as well ?

I have left these subfunctions alone for now to get the other hunks out
of the way. I have adjusted the patch according to your other comments
and pushed it as r14-973-gc072df1ab14450.

Thanks!

> 
> (...)
> > @@ -2098,7 +2098,7 @@ ref_same_as_full_array (gfc_ref *full_ref, gfc_ref 
> > *ref)
> > there is some kind of overlap.
> > 0 : array references are identical or not overlapping.  */
> >   
> > -int
> > +bool
> >   gfc_dep_resolver (gfc_ref *lref, gfc_ref *rref, gfc_reverse *reverse,
> >   bool identical)
> >   {  
> 
> The function comment states that the function may return 2, which 
> doesn't seem to be the case any more.  So please update the comment.
> 
> (...)> diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
> > index 221165d6dac..b4b36e27d75 100644
> > --- a/gcc/fortran/symbol.cc
> > +++ b/gcc/fortran/symbol.cc
> > @@ -3216,7 +3216,7 @@ gfc_find_symtree_in_proc (const char* name, 
> > gfc_namespace* ns)
> >  any parent namespaces if requested by a nonzero parent_flag.
> >  Returns nonzero if the name is ambiguous.  */
> >   
> > -int
> > +bool
> >   gfc_find_sym_tree (const char *name, gfc_namespace *ns, int parent_flag,
> >gfc_symtree **result)
> >   {  
> 
> Maybe change nonzero to true in the comment?
> 
> (...)
> 
> OK with all the above fixed.
> 
> Thanks.
> 

[Bug fortran/78798] [cleanup] some int-valued functions should be bool

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78798

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Bernhard Reutner-Fischer
:

https://gcc.gnu.org/g:c072df1ab144506cd8bb0ac81fb8f1aad69f0bd2

commit r14-973-gc072df1ab144506cd8bb0ac81fb8f1aad69f0bd2
Author: Bernhard Reutner-Fischer 
Date:   Sat Nov 6 06:48:00 2021 +0100

Fortran: Narrow return types [PR78798]

gcc/fortran/ChangeLog:

PR fortran/78798
* array.cc (compare_bounds): Use narrower return type.
(gfc_compare_array_spec): Likewise.
(is_constant_element): Likewise.
(gfc_constant_ac): Likewise.
* check.cc (dim_rank_check): Likewise.
* cpp.cc (gfc_cpp_init_options): Likewise.
(dump_macro): Likewise.
* cpp.h (gfc_cpp_handle_option): Likewise.
* dependency.cc (gfc_ref_needs_temporary_p): Likewise.
(gfc_check_argument_dependency): Likewise.
(gfc_check_fncall_dependency): Likewise.
(ref_same_as_full_array): Likewise.
* dependency.h (gfc_check_fncall_dependency): Likewise.
(gfc_dep_resolver): Likewise.
(gfc_are_equivalenced_arrays): Likewise.
* expr.cc (gfc_copy_ref): Likewise.
(gfc_kind_max): Likewise.
(numeric_type): Likewise.
* gfortran.h (gfc_at_end): Likewise.
(gfc_at_eof): Likewise.
(gfc_at_bol): Likewise.
(gfc_at_eol): Likewise.
(gfc_define_undef_line): Likewise.
(gfc_wide_is_printable): Likewise.
(gfc_wide_is_digit): Likewise.
(gfc_wide_fits_in_byte): Likewise.
(gfc_find_sym_tree): Likewise.
(gfc_generic_intrinsic): Likewise.
(gfc_specific_intrinsic): Likewise.
(gfc_intrinsic_actual_ok): Likewise.
(gfc_has_vector_index): Likewise.
(gfc_numeric_ts): Likewise.
(gfc_impure_variable): Likewise.
(gfc_pure): Likewise.
(gfc_implicit_pure): Likewise.
(gfc_elemental): Likewise.
(gfc_pure_function): Likewise.
(gfc_implicit_pure_function): Likewise.
(gfc_compare_array_spec): Likewise.
(gfc_constant_ac): Likewise.
(gfc_expanded_ac): Likewise.
(gfc_check_digit): Likewise.
* intrinsic.cc (gfc_find_subroutine): Likewise.
(gfc_generic_intrinsic): Likewise.
(gfc_specific_intrinsic): Likewise.
* io.cc (compare_to_allowed_values): Likewise. And remove
unneeded forward declaration.
* parse.cc: Likewise.
* parse.h (gfc_check_do_variable): Likewise.
* primary.cc (gfc_check_digit): Likewise.
* resolve.cc (resolve_structure_cons): Likewise.
(pure_stmt_function): Likewise.
(gfc_pure_function): Likewise.
(impure_stmt_fcn): Likewise.
(resolve_forall_iterators): Likewise.
(resolve_data): Likewise.
(gfc_impure_variable): Likewise.
(gfc_pure): Likewise.
(gfc_unset_implicit_pure): Likewise.
* scanner.cc (wide_is_ascii): Likewise.
(gfc_wide_toupper): Likewise.
(gfc_open_included_file): Likewise.
(gfc_at_end): Likewise.
(gfc_at_eof): Likewise.
(gfc_at_bol): Likewise.
(skip_comment_line): Likewise.
(gfc_gobble_whitespace): Likewise.
* symbol.cc (gfc_find_symtree_in_proc): Likewise.
* trans-array.cc: Likewise.
* trans-decl.cc (gfc_set_decl_assembler_name): Likewise.
* trans-types.cc (gfc_get_element_type): Likewise.
(gfc_add_field_to_struct): Likewise.
* trans-types.h (gfc_copy_dt_decls_ifequal): Likewise.
(gfc_return_by_reference): Likewise.
(gfc_is_nodesc_array): Likewise.
* trans.h (gfc_can_put_var_on_stack): Likewise.

[Bug other/109898] 'make install -j' sometimes corrupts 'dir' file for .info files due to parallel 'install-info' calls

[slyfox at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109898

--- Comment #3 from Sergei Trofimovich  ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Sergei Trofimovich from comment #0)
> > --- gcc-12.2.0/gcc/Makefile.in  2022-08-19 10:09:52.280658631 +0200
> > +++ gcc-12.2.0-new/gcc/Makefile.in  2023-05-04 14:35:44.401420184 +0200
> > @@ -3781,6 +3781,11 @@
> >   fi; \
> > fi
> >  
> > +# We don't care about the order in which the info files are built, but
> > +# install-info doesn't support multiple parallel invocations writing to
> > +# the same `dir-file`, so we have to disable parallelism for that reason:
> > +.NOTPARALLEL: install-info
> 
> Prerequisites of .NOTPARALLEL are ignored, so doesn't this un-parallelize
> building the entire gcc sub-dir?

When I tested on small example '.NOTPARALLEL: target' serialized exactly
prerequisites of 'target' and nothing more. 'info make' seems to confirm the
behaviour:

"""
'.NOTPARALLEL'

 If '.NOTPARALLEL' is mentioned as a target with no prerequisites,
 all targets in this invocation of 'make' will be run serially, even
 if the '-j' option is given.  Any recursively invoked 'make'
 command will still run recipes in parallel (unless its makefile
 also contains this target).

 If '.NOTPARALLEL' has targets as prerequisites, then all the
 prerequisites of those targets will be run serially.  This
 implicitly adds a '.WAIT' between each prerequisite of the listed
 targets.  *Note Disabling Parallel Execution: Parallel Disable.
"""

Here is the test that confirms it:

$ cat Makefile
all: a b

a: 1 2
echo a

1:
sleep 1

2:
sleep 1

b: 3 4
echo b

3:
sleep 1

4:
sleep 1

.NOTPARALLEL: a

$ make -j | LANG=C ts
May 18 20:34:23 sleep 1
May 18 20:34:23 sleep 1
May 18 20:34:23 sleep 1
May 18 20:34:24 sleep 1
May 18 20:34:24 echo b
May 18 20:34:24 b
May 18 20:34:25 echo a
May 18 20:34:25 a

Note how it takes 'b' 1 second to finish (due to parallelism) while 'a' takes 2
seconds (targets are sequential).

[Bug debug/109902] gcc/g++ emits wrong column number in DWARF

[simon.farre.cx at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109902

--- Comment #1 from Simon Farre  ---
This is slightly off-topic, but still relevant to this discussion. In the
attachment,
we can see this line

"  const auto res3 = b.set_foo (next_v ()).set_bar (next_v ()).set_baz (next_v
()).finalize ([] (auto v) { return v * 3; });"

-- GCC --
AddressLine   Column File   ISA Discriminator Flags
-- -- -- -- --- - -
0x004011ee 68 31  1   0 0  is_stmt
0x00401206 68 51  1   0 0  is_stmt
0x00401218 68 71  1   0 0  is_stmt
0x00401227 68 92  1   0 0  is_stmt

0x004012ee 68 93  1   0 0  is_stmt
0x004012f9 68118  1   0 0  is_stmt
0x00401302 68121  1   0 0  is_stmt

where as clang outputs:
AddressLine   Column File   ISA Discriminator Flags
-- -- -- -- --- - -
0x004011fd 68 32  1   0 0  is_stmt
0x0040120b 68 23  1   0 0
0x00401217 68 52  1   0 0
0x00401225 68 43  1   0 0
0x00401231 68 72  1   0 0
0x0040123f 68 63  1   0 0
0x00401247 68 83  1   0 0

0x00401450 68  0  1   0 0  is_stmt
0x0040145b 68116  1   0 0  is_stmt prologue_end
0x0040145f 68107  1   0 0
0x00401461 68107  1   0 0  end_sequence


As we can see, clang outputs information to the actual column meta data for
calls at parameter sites whereas GCC does not. Providing these positions in
source code opens up for "ergonomics-features", particularly in GDB as GDB can
more easily determine sites of interest to step to, set breakpoints at, etc.

Re: [PATCH 08/14] fortran: use _P() defines from tree.h

[Mikael Morin]

Le 18/05/2023 à 17:18, Bernhard Reutner-Fischer a écrit :

On Sun, 14 May 2023 15:10:12 +0200
Mikael Morin  wrote:


Le 14/05/2023 à 01:23, Bernhard Reutner-Fischer via Gcc-patches a écrit :

From: Bernhard Reutner-Fischer 

gcc/fortran/ChangeLog:

* trans-array.cc (is_pointer_array): Use _P() defines from tree.h.
(gfc_conv_scalarized_array_ref): Ditto.
(gfc_conv_array_ref): Ditto.
* trans-decl.cc (gfc_finish_decl): Ditto.
(gfc_get_symbol_decl): Ditto.
* trans-expr.cc (gfc_trans_pointer_assignment): Ditto.
(gfc_trans_arrayfunc_assign): Ditto.
(gfc_trans_assignment_1): Ditto.
* trans-intrinsic.cc (gfc_conv_intrinsic_minmax): Ditto.
(conv_intrinsic_ieee_value): Ditto.
* trans-io.cc (gfc_convert_array_to_string): Ditto.
* trans-openmp.cc (gfc_omp_is_optional_argument): Ditto.
(gfc_trans_omp_clauses): Ditto.
* trans-stmt.cc (gfc_conv_label_variable): Ditto.
* trans.cc (gfc_build_addr_expr): Ditto.
(get_array_span): Ditto.


OK from the fortran side.

Thanks


Thanks, i'll push it during the weekend.

I've fed gfortran.h into the script and found some CLASS_DATA spots,
see attached bootstrapped and tested patch.
Do we want to have that?

Some of it makes sense, but not all of it.

It is a macro to access the _data component of a class container.
So for class-related stuff it makes sense to use CLASS_DATA, and 
typically there will be a check that the type is BT_CLASS before.
But for cases where we loop over all of the components of a type that is 
not necessarily a class container, it doesn't make sense to use CLASS_DATA.


So I suggest to only keep the following hunks.



diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index aa01a4d3d22..a6b4ef0a0bf 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -5847,9 +5847,9 @@ gfc_get_corank (gfc_expr *e)
   if (!gfc_is_coarray (e))
 return 0;
 
-  if (e->ts.type == BT_CLASS && e->ts.u.derived->components)

-corank = e->ts.u.derived->components->as
-? e->ts.u.derived->components->as->corank : 0;
+  if (e->ts.type == BT_CLASS && CLASS_DATA (e))
+corank = CLASS_DATA (e)->as
+? CLASS_DATA (e)->as->corank : 0;
   else
 corank = e->symtree->n.sym->as ? e->symtree->n.sym->as->corank : 0;
 
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc

index 9c92958a397..6e26fb07ddd 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -15176,7 +15176,7 @@ resolve_component (gfc_component *c, gfc_symbol *sym)
   /* Check type-spec if this is not the parent-type component.  */
   if (((sym->attr.is_class
 && (!sym->components->ts.u.derived->attr.extension
-|| c != sym->components->ts.u.derived->components))
+   || c != CLASS_DATA (sym->components)))
|| (!sym->attr.is_class
&& (!sym->attr.extension || c != sym->components)))
   && !sym->attr.vtype
@@ -15189,7 +15189,7 @@ resolve_component (gfc_component *c, gfc_symbol *sym)
  component.  */
   if (super_type
   && ((sym->attr.is_class
-   && c == sym->components->ts.u.derived->components)
+  && c == CLASS_DATA (sym->components))
   || (!sym->attr.is_class && c == sym->components))
   && strcmp (super_type->name, c->name) == 0)
 c->attr.access = super_type->attr.access;
@@ -15435,7 +15435,7 @@ resolve_fl_derived0 (gfc_symbol *sym)
   return false;
 }
 
-  c = (sym->attr.is_class) ? sym->components->ts.u.derived->components

+  c = (sym->attr.is_class) ? CLASS_DATA (sym->components)
   : sym->components;
 
   success = true;

diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index a7b4784d73a..6ba2040e61c 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -3116,28 +3116,28 @@ gfc_simplify_extends_type_of (gfc_expr *a, gfc_expr 
*mold)
   /* Return .false. if the dynamic type can never be an extension.  */
   if ((a->ts.type == BT_CLASS && mold->ts.type == BT_CLASS
&& !gfc_type_is_extension_of
-   (mold->ts.u.derived->components->ts.u.derived,
-a->ts.u.derived->components->ts.u.derived)
+   (CLASS_DATA (mold)->ts.u.derived,
+CLASS_DATA (a)->ts.u.derived)
&& !gfc_type_is_extension_of
-   (a->ts.u.derived->components->ts.u.derived,
-mold->ts.u.derived->components->ts.u.derived))
+   (CLASS_DATA (a)->ts.u.derived,
+CLASS_DATA (mold)->ts.u.derived))
   || (a->ts.type == BT_DERIVED && mold->ts.type == BT_CLASS
  && !gfc_type_is_extension_of
-   (mold->ts.u.derived->components->ts.u.derived,
+   (CLASS_DATA (mold)->ts.u.derived,
 a->ts.u.derived))
   || (a->ts.type == BT_CLASS && mold->ts.type == BT_DERIVED
  && 

[Bug middle-end/101807] bool0 < bool1 Should expand as !bool0 and bool0 <= bool1 as !bool0 | bool1

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101807

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
   Last reconfirmed||2023-05-18
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Andrew Pinski  ---
I have a patch.

It even handles:
unsigned f(unsigned a, unsigned b)
{
if (a > 1) __builtin_unreachable();
if (b > 1) __builtin_unreachable();
return a

Re: [PATCH] c++: scoped variable template-id of reference type [PR97340]

[Jason Merrill via Gcc-patches]

On 5/18/23 13:59, Patrick Palka wrote:

lookup_and_finish_template_variable calls convert_from_reference, which
means for a variable template-id of reference type the function returns
an INDIRECT_REF instead of the bare VAR_DECL.  But the downstream logic
of two callers, tsubst_qualified_id and finish_class_member_access_expr,
expect a DECL_P result and so we end up crashing when resolving the
template-id's in the first testcase.  (Note that these two callers
eventually call convert_from_reference as appropriate, so this earlier
call seems at best redundant.)

This patch fixes this by pulling out the convert_from_reference call
from lookup_and_finish_template_variable and into the callers that
actually need it, which turns out to be tsubst_copy_and_build (without
it we'd mishandle the second testcase).

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


OK.


PR c++/97340

gcc/cp/ChangeLog:

* pt.cc (lookup_and_finish_template_variable): Don't call
convert_from_reference.
(tsubst_copy_and_build) : Call
convert_from_reference on the result of
lookup_and_finish_template_variable.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/var-templ80.C: New test.
* g++.dg/cpp1y/var-templ81.C: New test.
---
  gcc/cp/pt.cc |  3 ++-
  gcc/testsuite/g++.dg/cpp1y/var-templ80.C | 22 ++
  gcc/testsuite/g++.dg/cpp1y/var-templ81.C | 14 ++
  3 files changed, 38 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp1y/var-templ80.C
  create mode 100644 gcc/testsuite/g++.dg/cpp1y/var-templ81.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 351fc18b600..9e5b29f3099 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -10394,7 +10394,7 @@ lookup_and_finish_template_variable (tree templ, tree 
targs,
complain &= ~tf_partial;
var = finish_template_variable (var, complain);
mark_used (var);
-  return convert_from_reference (var);
+  return var;
  }
  
  /* If the set of template parameters PARMS contains a template parameter

@@ -20462,6 +20462,7 @@ tsubst_copy_and_build (tree t,
  {
tree r = lookup_and_finish_template_variable (templ, targs,
  complain);
+   r = convert_from_reference (r);
r = maybe_wrap_with_location (r, EXPR_LOCATION (t));
RETURN (r);
  }
diff --git a/gcc/testsuite/g++.dg/cpp1y/var-templ80.C 
b/gcc/testsuite/g++.dg/cpp1y/var-templ80.C
new file mode 100644
index 000..4439bee8292
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/var-templ80.C
@@ -0,0 +1,22 @@
+// PR c++/97340
+// { dg-do compile { target c++14 } }
+
+template
+struct A {
+  template
+  static constexpr const int& var = 0;
+};
+
+template
+struct B {
+  static constexpr int x1 = A::template var;
+  static constexpr int y1 = A{}.template var;
+
+  static constexpr int x2 = A::template var;
+  static constexpr int y2 = A{}.template var;
+
+  static constexpr int x3 = A::template var;
+  static constexpr int y3 = A{}.template var;
+};
+
+template struct B;
diff --git a/gcc/testsuite/g++.dg/cpp1y/var-templ81.C 
b/gcc/testsuite/g++.dg/cpp1y/var-templ81.C
new file mode 100644
index 000..f9d2e6b1eed
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/var-templ81.C
@@ -0,0 +1,14 @@
+// Verify we don't ICE on an invalid use of unary * for a variable
+// template-id of reference type.
+// { dg-do compile { target c++14 } }
+
+template
+static constexpr const int& var = 0;
+
+template
+struct B {
+  static constexpr int x = *var; // { dg-error "argument of unary" }
+  static constexpr const int& y = *var; // { dg-error "argument of unary" }
+};
+
+template struct B;

Re: [PATCH] c++: simplify norm_cache manipulation

[Jason Merrill via Gcc-patches]

On 5/18/23 14:01, Patrick Palka wrote:

Avoid performing two norm_cache lookups during normalization of a
concept-id by allocating inserting a norm_entry* before rather than
after the fact, which is simpler and faster.

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


OK.


gcc/cp/ChangeLog:

* constraint.cc (normalize_concept_check): Avoid having to do
two norm_cache lookups.  Remove unnecessary early exit for an
ill-formed concept definition.
---
  gcc/cp/constraint.cc | 31 +--
  1 file changed, 9 insertions(+), 22 deletions(-)

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index c81e024e0e2..8cf0f2d0974 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -774,38 +774,25 @@ normalize_concept_check (tree check, tree args, norm_info 
info)
  
if (!norm_cache)

  norm_cache = hash_table::create_ggc (31);
-  norm_entry entry = {tmpl, targs, NULL_TREE};
-  norm_entry **slot = nullptr;
-  hashval_t hash = 0;
-  bool insert = false;
+  norm_entry *entry = nullptr;
if (!info.generate_diagnostics ())
  {
/* Cache the normal form of the substituted concept-id (when not
 diagnosing).  */
-  hash = norm_hasher::hash ();
-  slot = norm_cache->find_slot_with_hash (, hash, NO_INSERT);
-  if (slot)
+  norm_entry elt = {tmpl, targs, NULL_TREE};
+  norm_entry **slot = norm_cache->find_slot (, INSERT);
+  if (*slot)
return (*slot)->norm;
-  insert = true;
+  entry = ggc_alloc ();
+  *entry = elt;
+  *slot = entry;
  }
  
-  /* The concept may have been ill-formed.  */

tree def = get_concept_definition (DECL_TEMPLATE_RESULT (tmpl));
-  if (def == error_mark_node)
-return error_mark_node;
-
info.update_context (check, args);
tree norm = normalize_expression (def, targs, info);
-  if (insert)
-{
-  /* Recompute SLOT since norm_cache may have been expanded during
-the recursive call.  */
-  slot = norm_cache->find_slot_with_hash (, hash, INSERT);
-  gcc_checking_assert (!*slot);
-  entry.norm = norm;
-  *slot = ggc_alloc ();
-  **slot = entry;
-}
+  if (entry)
+entry->norm = norm;
return norm;
  }
  

[COMMITTED] i386: Add infrastructure for QImode partial vector mult and shift operations

[Uros Bizjak via Gcc-patches]

QImode partial vector multiplications and shifts can be implemented using
their HImode counterparts.  Add infrastructure to handle V8QImode and
V4QImode vectors by extending (interleaving) their input operands to
V8HImode, performing V8HImode operation and truncating output back to
the original QImode vector.

The patch implements V8QImode and V4QImode multiplication for SSE2 targets,
using generic permutation to truncate output operand, but still taking
advantage of VPMOVWB down convert instruction, when available.

The patch also removes setting of REG_EQAUL note to the last insn
of ix86_expand_vecop_qihi expander.  This is what generic code does
automatically when named pattern is expanded.

gcc/ChangeLog:

* config/i386/i386-expand.cc (ix86_expand_vecop_qihi_partial): New.
(ix86_expand_vecop_qihi): Add op2vec bool variable.
Do not set REG_EQUAL note.
* config/i386/i386-protos.h (ix86_expand_vecop_qihi_partial):
Add prototype.
* config/i386/i386.cc (ix86_multiplication_cost): Handle
V4QImode and V8QImode.
* config/i386/mmx.md (mulv8qi3): New expander.
(mulv4qi3): Ditto.
* config/i386/sse.md (mulv8qi3): Remove.

gcc/testsuite/ChangeLog:

* gcc.target/i386/avx512vl-pr95488-1.c: Adjust
expected scan-assembler-times frequency and strings.
* gcc.target/i386/vect-mulv4qi.c: New test.
* gcc.target/i386/vect-mulv8qi.c: New test.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Uros.
diff --git a/gcc/config/i386/i386-expand.cc b/gcc/config/i386/i386-expand.cc
index 8a869eb3b30..d5116801498 100644
--- a/gcc/config/i386/i386-expand.cc
+++ b/gcc/config/i386/i386-expand.cc
@@ -23270,6 +23270,116 @@ ix86_expand_vec_shift_qihi_constant (enum rtx_code 
code,
   return true;
 }
 
+void
+ix86_expand_vecop_qihi_partial (enum rtx_code code, rtx dest, rtx op1, rtx op2)
+{
+  machine_mode qimode = GET_MODE (dest);
+  rtx qop1, qop2, hop1, hop2, qdest, hres;
+  bool op2vec = GET_MODE_CLASS (GET_MODE (op2)) == MODE_VECTOR_INT;
+  bool uns_p = true;
+
+  switch (qimode)
+{
+case E_V4QImode:
+case E_V8QImode:
+  break;
+default:
+  gcc_unreachable ();
+}
+
+  qop1 = lowpart_subreg (V16QImode, force_reg (qimode, op1), qimode);
+
+  if (op2vec)
+qop2 = lowpart_subreg (V16QImode, force_reg (qimode, op2), qimode);
+  else
+qop2 = op2;
+
+  switch (code)
+{
+case MULT:
+  gcc_assert (op2vec);
+  /* Unpack data such that we've got a source byte in each low byte of
+each word.  We don't care what goes into the high byte of each word.
+Rather than trying to get zero in there, most convenient is to let
+it be a copy of the low byte.  */
+  hop1 = copy_to_reg (qop1);
+  hop2 = copy_to_reg (qop2);
+  emit_insn (gen_vec_interleave_lowv16qi (hop1, hop1, hop1));
+  emit_insn (gen_vec_interleave_lowv16qi (hop2, hop2, hop2));
+  break;
+
+case ASHIFTRT:
+  uns_p = false;
+  /* FALLTHRU */
+case ASHIFT:
+case LSHIFTRT:
+  hop1 = gen_reg_rtx (V8HImode);
+  ix86_expand_sse_unpack (hop1, qop1, uns_p, false);
+  /* vashr/vlshr/vashl  */
+  if (op2vec)
+   {
+ hop2 = gen_reg_rtx (V8HImode);
+ ix86_expand_sse_unpack (hop2, qop2, uns_p, false);
+   }
+  else
+   hop2 = qop2;
+
+  break;
+default:
+  gcc_unreachable ();
+}
+
+  if (code != MULT && op2vec)
+{
+  /* Expand vashr/vlshr/vashl.  */
+  hres = gen_reg_rtx (V8HImode);
+  emit_insn (gen_rtx_SET (hres,
+ simplify_gen_binary (code, V8HImode,
+  hop1, hop2)));
+}
+  else
+/* Expand mult/ashr/lshr/ashl.  */
+hres = expand_simple_binop (V8HImode, code, hop1, hop2,
+   NULL_RTX, 1, OPTAB_DIRECT);
+
+  if (TARGET_AVX512BW && TARGET_AVX512VL)
+{
+  if (qimode == V8QImode)
+   qdest = dest;
+  else
+   qdest = gen_reg_rtx (V8QImode);
+
+  emit_insn (gen_truncv8hiv8qi2 (qdest, hres));
+}
+  else
+{
+  struct expand_vec_perm_d d;
+  rtx qres = gen_lowpart (V16QImode, hres);
+  bool ok;
+  int i;
+
+  qdest = gen_reg_rtx (V16QImode);
+
+  /* Merge the data back into the right place.  */
+  d.target = qdest;
+  d.op0 = qres;
+  d.op1 = qres;
+  d.vmode = V16QImode;
+  d.nelt = 16;
+  d.one_operand_p = false;
+  d.testing_p = false;
+
+  for (i = 0; i < d.nelt; ++i)
+   d.perm[i] = i * 2;
+
+  ok = ix86_expand_vec_perm_const_1 ();
+  gcc_assert (ok);
+}
+
+  if (qdest != dest)
+emit_move_insn (dest, gen_lowpart (qimode, qdest));
+}
+
 /* Expand a vector operation CODE for a V*QImode in terms of the
same operation on V*HImode.  */
 
@@ -23281,6 +23391,7 @@ ix86_expand_vecop_qihi (enum rtx_code code, rtx dest, 
rtx op1, rtx op2)
   rtx (*gen_il) (rtx, rtx, rtx);
   rtx (*gen_ih) (rtx, rtx, rtx);
   rtx op1_l, op1_h, op2_l, 

[Bug libgomp/109904] linking with -static flag generates undefined references

[Gary.White at ColoState dot edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904

--- Comment #5 from GARY.WHITE at ColoState dot edu  ---
I'm getting gfortran downloads from here:

https://github.com/brechtsanders/winlibs_mingw/releases


Gary C. White, CWB(r)
Professor Emeritus
Department of Fish, Wildlife, and Conservation Biology
10 Wagar
Colorado State University
Fort Collins, CO 80523
(515)450-2768 Mobile
gary.wh...@colostate.edu
https://sites.warnercnr.colostate.edu/gwhite/
he/him/his

See where we are!

"Leadership is a privilege to better the lives of others. It is not an
opportunity to satisfy personal greed." Mwai Kibaki

-Original Message-
From: pinskia at gcc dot gnu.org 
Sent: Thursday, May 18, 2023 12:33 PM
To: White,Gary 
Subject: [Bug libgomp/109904] linking with -static flag generates undefined
references

** Caution: EXTERNAL Sender **

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904

--- Comment #4 from Andrew Pinski  --- (In reply to
gary.wh...@colostate.edu from comment #3)
> Linking with -ldl fixed the issue  Where is there documentation of -ldl?

-l says to link against a specified library in this case libdl; libgomp needs
to open a library at runtime due to offloading support and dl* functions do
that and for windows dl* functions are implemented in libdl-win32. But as I
mentioned you should be asking where you got the binary toolchain instead of
here.

--
You are receiving this mail because:
You reported the bug.

[Bug libgomp/109904] linking with -static flag generates undefined references

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904

--- Comment #4 from Andrew Pinski  ---
(In reply to gary.wh...@colostate.edu from comment #3)
> Linking with -ldl fixed the issue  Where is there documentation of -ldl?

-l says to link against a specified library in this case libdl; libgomp needs
to open a library at runtime due to offloading support and dl* functions do
that and for windows dl* functions are implemented in libdl-win32. But as I
mentioned you should be asking where you got the binary toolchain instead of
here.

[Bug libgomp/109904] linking with -static flag generates undefined references

[Gary.White at ColoState dot edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904

--- Comment #3 from GARY.WHITE at ColoState dot edu  ---
Linking with -ldl fixed the issue  Where is there documentation of -ldl?


Gary C. White, CWB(r)
Professor Emeritus
Department of Fish, Wildlife, and Conservation Biology
10 Wagar
Colorado State University
Fort Collins, CO 80523
(515)450-2768 Mobile
gary.wh...@colostate.edu
https://sites.warnercnr.colostate.edu/gwhite/
he/him/his

See where we are!

"Leadership is a privilege to better the lives of others. It is not an
opportunity to satisfy personal greed." Mwai Kibaki

-Original Message-
From: pinskia at gcc dot gnu.org 
Sent: Thursday, May 18, 2023 12:11 PM
To: White,Gary 
Subject: [Bug libgomp/109904] linking with -static flag generates undefined
references

** Caution: EXTERNAL Sender **

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904

--- Comment #1 from Andrew Pinski  ---
>--enable-offload-targets=nvptx-none

I suspect this might be the issue. offloading only works with targets that have
dlopen . Maybe you need to link with -ldl to get it working.

--
You are receiving this mail because:
You reported the bug.

[Bug c++/109227] coroutines: ICE in tree check: expected record_type or union_type or qual_union_type, have array_type in build_special_member_call, at cp/call.cc:11067

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109227

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I guess if var_type is ARRAY_TYPE, then it shouldn't call
build_special_member_call with complete_dtor_identifier, but should do
something like build_vec_delete_1 does around it.
Though, seems coroutines.cc calls build_special_member_call with
complete_dtor_identifier in 12 different spots, which of those could be
ARRAY_TYPEs is unclear to me.

Re: [PATCH] Fix internal error on small array with negative lower bound

[Richard Biener via Gcc-patches]

> Am 18.05.2023 um 19:44 schrieb Eric Botcazou :
> 
> 
>> 
>> Would it be better to use
>> 
>>  wi::to_uhwi (wi::to_wide (local->index) - wi::to_wide (local->min_index))
>> 
>> to honor the actual sign of the indices?  I think nothing forbids frontends
>> to use a signed TYPE_DOMAIN here?  But the difference should be always
>> representable in an unsigned value of course.
> 
> We use tree_to_uhwi everywhere else though, see categorize_ctor_elements_1:
> 
>  if (tree_fits_uhwi_p (lo_index) && tree_fits_uhwi_p (hi_index))
>mult = (tree_to_uhwi (hi_index)
>- tree_to_uhwi (lo_index) + 1);
> 
> or store_constructor
> 
>this_node_count = (tree_to_uhwi (hi_index)
>   - tree_to_uhwi (lo_index) + 1);
> 
> so the proposed form looks better for the sake of consistency.

Ok, thanks for checking.

Richard 

> -- 
> Eric Botcazou
> 
> 

[Bug c++/101853] [12/13/14 Regression] g++.dg/modules/xtreme-header-5_b.C ICE

[hp at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101853

--- Comment #18 from Hans-Peter Nilsson  ---
(In reply to Jiu Fu Guo from comment #17)
> > But "nobody" counts that close, so better say "no xtreme-header-* failures
> > since r13-5702-g72058eea9d407e".
> 
> :) Since these failures occur erratically,

They did at the time for cris-elf (too), but I believe the cause of *those*
failures has been fixed.

> so maybe reopen this or open a
> new one if the failures are reproduced.

That's the idea. :)

> As two xtreme-header-5_ failures (not ICE) occur in Results for 14.0.0
> 20230518: https://gcc.gnu.org/pipermail/gcc-testresults/2023-May/784674.html.

Good to know, but not for cris-elf.

[Bug libgomp/109904] linking with -static flag generates undefined references

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Andrew Pinski  ---
In fact I noticed this on the configure comand line:
-I/d/Prog/winlibs64ucrt_stage/custombuilt/include/libdl-win32

Please report this issue to where you got the binary builds of GCC from and ask
them about providing libdl-win32 to you too.

[Bug libgomp/109904] linking with -static flag generates undefined references

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904

--- Comment #1 from Andrew Pinski  ---
>--enable-offload-targets=nvptx-none

I suspect this might be the issue. offloading only works with targets that have
dlopen . Maybe you need to link with -ldl to get it working.

[Bug fortran/109904] New: linking with -static flag generates undefined references

[Gary.White at ColoState dot edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904

Bug ID: 109904
   Summary: linking with -static flag generates undefined
references
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Gary.White at ColoState dot edu
  Target Milestone: ---

What follows are a portion of the undefined references when using -static with
gfortran-13.  I require the -static flag to be able to distribute executable to
users not having gfortran on their machines.

gfortran -m64 -fopenmp  mark.o glabrd.o xmatrx.o tmread.o rlabrd.o blabrd.o
dlabrd.o estmat.o varmat.o derivedest.o piread.o func.o saturd.o chprob.o
chprob001.o chprob002.o chprob008.o chprob009.o chprob032.o chprob115.o
chprob119.o chprob121.o chprob126.o chprob139.o chprob140.o chprob141.o
chprob142.o chprob143.o chprob144.o chprob160.o chprob170.o chprob171.o
chprob172.o chprob173.o chprob174.o chprob175.o chprob176.o chprob177.o
chprob178.o chprob179.o chprob180.o chprob181.o chprob182.o chprob183.o
chprob184.o rcread.o kfread.o nsread.o  optmiz.o status_module.o prcisub.o
prfunc.o mcmc.o hyperread.o gibbsitsub.o optimizers_module.o gaussquad.o
hyper_dist_module.o profile_conf_interval_module.o data_module.o
design_matrix_funcs_module.o random_values_module.o Linpack.a -o mark64.exe
-static -static-libgfortran
C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../lib\libgomp.a(target.o):(.text+0x94f):
undefined reference to `dlopen'
C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../lib\libgomp.a(target.o):(.text+0x96a):
undefined reference to `dlsym'
C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../lib\libgomp.a(target.o):(.text+0x99f):
undefined reference to `dlclose'
C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../lib\libgomp.a(oacc-profiling.o):(.text+0x83d):
undefined reference to `dlerror'

Specifics of the installation of gfortran are:
gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=C:/tdm-gcc-64/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/13.1.0/lto-wrapper.exe
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-w64-mingw32
Configured with: ../configure
--prefix=/R/winlibs64ucrt_stage/inst_gcc-13.1.0/share/gcc
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
--enable-offload-targets=nvptx-none --with-pkgversion='MinGW-W64
x86_64-msvcrt-posix-seh, built by Brecht Sanders' --with-tune=generic
--enable-checking=release --enable-threads=posix --disable-sjlj-exceptions
--disable-libunwind-exceptions --disable-serial-configure --disable-bootstrap
--enable-host-shared --enable-plugin --disable-default-ssp --disable-rpath
--disable-libstdcxx-debug --disable-version-specific-runtime-libs --with-stabs
--disable-symvers --enable-languages=c,c++,fortran,lto,objc,obj-c++
--disable-gold --disable-nls --disable-stage1-checking --disable-win32-registry
--disable-multilib --enable-ld --enable-libquadmath --enable-libada
--enable-libssp --enable-libstdcxx --enable-lto --enable-fully-dynamic-string
--enable-libgomp --enable-graphite --enable-mingw-wildcard
--enable-libstdcxx-time --enable-libstdcxx-pch
--with-mpc=/d/Prog/winlibs64ucrt_stage/custombuilt
--with-mpfr=/d/Prog/winlibs64ucrt_stage/custombuilt
--with-gmp=/d/Prog/winlibs64ucrt_stage/custombuilt
--with-isl=/d/Prog/winlibs64ucrt_stage/custombuilt --enable-libstdcxx-backtrace
--enable-install-libiberty --enable-__cxa_atexit --without-included-gettext
--with-diagnostics-color=auto --enable-clocale=generic --with-libiconv
--with-system-zlib
--with-build-sysroot=/R/winlibs64ucrt_stage/gcc-13.1.0/build_mingw/mingw-w64
CFLAGS='-I/d/Prog/winlibs64ucrt_stage/custombuilt/include/libdl-win32
-Wno-int-conversion' CXXFLAGS=-Wno-int-conversion LDFLAGS='-pthread
-Wl,--dynamicbase -Wl,--high-entropy-va -Wl,--nxcompat -Wl,--tsaware'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.0 (MinGW-W64 x86_64-msvcrt-posix-seh, built by Brecht Sanders)

[PATCH] c++: simplify norm_cache manipulation

[Patrick Palka via Gcc-patches]

Avoid performing two norm_cache lookups during normalization of a
concept-id by allocating inserting a norm_entry* before rather than
after the fact, which is simpler and faster.

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

gcc/cp/ChangeLog:

* constraint.cc (normalize_concept_check): Avoid having to do
two norm_cache lookups.  Remove unnecessary early exit for an
ill-formed concept definition.
---
 gcc/cp/constraint.cc | 31 +--
 1 file changed, 9 insertions(+), 22 deletions(-)

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index c81e024e0e2..8cf0f2d0974 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -774,38 +774,25 @@ normalize_concept_check (tree check, tree args, norm_info 
info)
 
   if (!norm_cache)
 norm_cache = hash_table::create_ggc (31);
-  norm_entry entry = {tmpl, targs, NULL_TREE};
-  norm_entry **slot = nullptr;
-  hashval_t hash = 0;
-  bool insert = false;
+  norm_entry *entry = nullptr;
   if (!info.generate_diagnostics ())
 {
   /* Cache the normal form of the substituted concept-id (when not
 diagnosing).  */
-  hash = norm_hasher::hash ();
-  slot = norm_cache->find_slot_with_hash (, hash, NO_INSERT);
-  if (slot)
+  norm_entry elt = {tmpl, targs, NULL_TREE};
+  norm_entry **slot = norm_cache->find_slot (, INSERT);
+  if (*slot)
return (*slot)->norm;
-  insert = true;
+  entry = ggc_alloc ();
+  *entry = elt;
+  *slot = entry;
 }
 
-  /* The concept may have been ill-formed.  */
   tree def = get_concept_definition (DECL_TEMPLATE_RESULT (tmpl));
-  if (def == error_mark_node)
-return error_mark_node;
-
   info.update_context (check, args);
   tree norm = normalize_expression (def, targs, info);
-  if (insert)
-{
-  /* Recompute SLOT since norm_cache may have been expanded during
-the recursive call.  */
-  slot = norm_cache->find_slot_with_hash (, hash, INSERT);
-  gcc_checking_assert (!*slot);
-  entry.norm = norm;
-  *slot = ggc_alloc ();
-  **slot = entry;
-}
+  if (entry)
+entry->norm = norm;
   return norm;
 }
 
-- 
2.41.0.rc0.4.g004e0f790f

Re: [PATCH 1/4] Missed opportunity to use [SU]ABD

[Richard Sandiford via Gcc-patches]

Thanks for the update.  Some of these comments would have applied
to the first version, so sorry for not catching them first time.

 writes:
> From: oluade01 
>
> This adds a recognition pattern for the non-widening
> absolute difference (ABD).
>
> gcc/ChangeLog:
>
>   * doc/md.texi (sabd, uabd): Document them.
>   * internal-fn.def (ABD): Use new optab.
>   * optabs.def (sabd_optab, uabd_optab): New optabs,
>   * tree-vect-patterns.cc (vect_recog_absolute_difference):
>   Recognize the following idiom abs (a - b).
>   (vect_recog_sad_pattern): Refactor to use
>   vect_recog_absolute_difference.
>   (vect_recog_abd_pattern): Use patterns found by
>   vect_recog_absolute_difference to build a new ABD
>   internal call.
> ---
>  gcc/doc/md.texi   |  10 ++
>  gcc/internal-fn.def   |   3 +
>  gcc/optabs.def|   2 +
>  gcc/tree-vect-patterns.cc | 255 +-
>  4 files changed, 239 insertions(+), 31 deletions(-)
>
> diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
> index 
> 07bf8bdebffb2e523f25a41f2b57e43c0276b745..3e65584d7efcd301f2c96a40edd82d30b84462b8
>  100644
> --- a/gcc/doc/md.texi
> +++ b/gcc/doc/md.texi
> @@ -5778,6 +5778,16 @@ Other shift and rotate instructions, analogous to the
>  Vector shift and rotate instructions that take vectors as operand 2
>  instead of a scalar type.
>  
> +@cindex @code{uabd@var{m}} instruction pattern
> +@cindex @code{sabd@var{m}} instruction pattern
> +@item @samp{uabd@var{m}}, @samp{sabd@var{m}}
> +Signed and unsigned absolute difference instructions.  These
> +instructions find the difference between operands 1 and 2
> +then return the absolute value.  A C code equivalent would be:
> +@smallexample
> +op0 = op0 > op1 ? op0 - op1 : op1 - op0;

Should be:

  op0 = op1 > op2 ? op1 - op2 : op2 - op1;

since op0 is the output.

> +@end smallexample
> +
>  @cindex @code{avg@var{m}3_floor} instruction pattern
>  @cindex @code{uavg@var{m}3_floor} instruction pattern
>  @item @samp{avg@var{m}3_floor}
> diff --git a/gcc/internal-fn.def b/gcc/internal-fn.def
> index 
> 7fe742c2ae713e7152ab05cfdfba86e4e0aa3456..0f1724ecf37a31c231572edf90b5577e2d82f468
>  100644
> --- a/gcc/internal-fn.def
> +++ b/gcc/internal-fn.def
> @@ -167,6 +167,9 @@ DEF_INTERNAL_OPTAB_FN (FMS, ECF_CONST, fms, ternary)
>  DEF_INTERNAL_OPTAB_FN (FNMA, ECF_CONST, fnma, ternary)
>  DEF_INTERNAL_OPTAB_FN (FNMS, ECF_CONST, fnms, ternary)
>  
> +DEF_INTERNAL_SIGNED_OPTAB_FN (ABD, ECF_CONST | ECF_NOTHROW, first,
> +   sabd, uabd, binary)
> +
>  DEF_INTERNAL_SIGNED_OPTAB_FN (AVG_FLOOR, ECF_CONST | ECF_NOTHROW, first,
> savg_floor, uavg_floor, binary)
>  DEF_INTERNAL_SIGNED_OPTAB_FN (AVG_CEIL, ECF_CONST | ECF_NOTHROW, first,
> diff --git a/gcc/optabs.def b/gcc/optabs.def
> index 
> 695f5911b300c9ca5737de9be809fa01aabe5e01..29bc92281a2175f898634cbe6af63c18021e5268
>  100644
> --- a/gcc/optabs.def
> +++ b/gcc/optabs.def
> @@ -359,6 +359,8 @@ OPTAB_D (mask_fold_left_plus_optab, 
> "mask_fold_left_plus_$a")
>  OPTAB_D (extract_last_optab, "extract_last_$a")
>  OPTAB_D (fold_extract_last_optab, "fold_extract_last_$a")
>  
> +OPTAB_D (uabd_optab, "uabd$a3")
> +OPTAB_D (sabd_optab, "sabd$a3")
>  OPTAB_D (savg_floor_optab, "avg$a3_floor")
>  OPTAB_D (uavg_floor_optab, "uavg$a3_floor")
>  OPTAB_D (savg_ceil_optab, "avg$a3_ceil")
> diff --git a/gcc/tree-vect-patterns.cc b/gcc/tree-vect-patterns.cc
> index 
> a49b09539776c0056e77f99b10365d0a8747fbc5..50f1822f220c023027f4b0f777965f3757842fa2
>  100644
> --- a/gcc/tree-vect-patterns.cc
> +++ b/gcc/tree-vect-patterns.cc
> @@ -770,6 +770,93 @@ vect_split_statement (vec_info *vinfo, stmt_vec_info 
> stmt2_info, tree new_rhs,
>  }
>  }
>  
> +/* Look for the following pattern
> + X = x[i]
> + Y = y[i]
> + DIFF = X - Y
> + DAD = ABS_EXPR
> +
> +   ABS_STMT should point to a statement of code ABS_EXPR or ABSU_EXPR.
> +   If REJECT_UNSIGNED is true it aborts if the type of ABS_STMT is unsigned.
> +   HALF_TYPE and UNPROM will be set should the statement be found to
> +   be a widened operation.
> +   DIFF_OPRNDS will be set to the two inputs of the MINUS_EXPR preceding
> +   ABS_STMT, otherwise it will be set the operations found by
> +   vect_widened_op_tree.
> + */
> +static bool
> +vect_recog_absolute_difference (vec_info *vinfo, gassign *abs_stmt,
> + tree *half_type, bool reject_unsigned,
> + vect_unpromoted_value unprom[2],
> + tree diff_oprnds[2])
> +{
> +  if (!abs_stmt)
> +return false;
> +
> +  /* FORNOW.  Can continue analyzing the def-use chain when this stmt in a 
> phi
> + inside the loop (in case we are analyzing an outer-loop).  */
> +  enum tree_code code = gimple_assign_rhs_code (abs_stmt);
> +  if (code != ABS_EXPR && code != ABSU_EXPR)
> +return false;
> +
> +  tree abs_oprnd = gimple_assign_rhs1 (abs_stmt);
> + 

[PATCH] c++: scoped variable template-id of reference type [PR97340]

[Patrick Palka via Gcc-patches]

lookup_and_finish_template_variable calls convert_from_reference, which
means for a variable template-id of reference type the function returns
an INDIRECT_REF instead of the bare VAR_DECL.  But the downstream logic
of two callers, tsubst_qualified_id and finish_class_member_access_expr,
expect a DECL_P result and so we end up crashing when resolving the
template-id's in the first testcase.  (Note that these two callers
eventually call convert_from_reference as appropriate, so this earlier
call seems at best redundant.)

This patch fixes this by pulling out the convert_from_reference call
from lookup_and_finish_template_variable and into the callers that
actually need it, which turns out to be tsubst_copy_and_build (without
it we'd mishandle the second testcase).

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

PR c++/97340

gcc/cp/ChangeLog:

* pt.cc (lookup_and_finish_template_variable): Don't call
convert_from_reference.
(tsubst_copy_and_build) : Call
convert_from_reference on the result of
lookup_and_finish_template_variable.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/var-templ80.C: New test.
* g++.dg/cpp1y/var-templ81.C: New test.
---
 gcc/cp/pt.cc |  3 ++-
 gcc/testsuite/g++.dg/cpp1y/var-templ80.C | 22 ++
 gcc/testsuite/g++.dg/cpp1y/var-templ81.C | 14 ++
 3 files changed, 38 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/var-templ80.C
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/var-templ81.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 351fc18b600..9e5b29f3099 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -10394,7 +10394,7 @@ lookup_and_finish_template_variable (tree templ, tree 
targs,
   complain &= ~tf_partial;
   var = finish_template_variable (var, complain);
   mark_used (var);
-  return convert_from_reference (var);
+  return var;
 }
 
 /* If the set of template parameters PARMS contains a template parameter
@@ -20462,6 +20462,7 @@ tsubst_copy_and_build (tree t,
  {
tree r = lookup_and_finish_template_variable (templ, targs,
  complain);
+   r = convert_from_reference (r);
r = maybe_wrap_with_location (r, EXPR_LOCATION (t));
RETURN (r);
  }
diff --git a/gcc/testsuite/g++.dg/cpp1y/var-templ80.C 
b/gcc/testsuite/g++.dg/cpp1y/var-templ80.C
new file mode 100644
index 000..4439bee8292
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/var-templ80.C
@@ -0,0 +1,22 @@
+// PR c++/97340
+// { dg-do compile { target c++14 } }
+
+template
+struct A {
+  template
+  static constexpr const int& var = 0;
+};
+
+template
+struct B {
+  static constexpr int x1 = A::template var;
+  static constexpr int y1 = A{}.template var;
+
+  static constexpr int x2 = A::template var;
+  static constexpr int y2 = A{}.template var;
+
+  static constexpr int x3 = A::template var;
+  static constexpr int y3 = A{}.template var;
+};
+
+template struct B;
diff --git a/gcc/testsuite/g++.dg/cpp1y/var-templ81.C 
b/gcc/testsuite/g++.dg/cpp1y/var-templ81.C
new file mode 100644
index 000..f9d2e6b1eed
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/var-templ81.C
@@ -0,0 +1,14 @@
+// Verify we don't ICE on an invalid use of unary * for a variable
+// template-id of reference type.
+// { dg-do compile { target c++14 } }
+
+template
+static constexpr const int& var = 0;
+
+template
+struct B {
+  static constexpr int x = *var; // { dg-error "argument of unary" }
+  static constexpr const int& y = *var; // { dg-error "argument of unary" }
+};
+
+template struct B;
-- 
2.41.0.rc0.4.g004e0f790f

Re: [PATCH V2, rs6000] Disable generation of scalar modulo instructions

[Pat Haugen via Gcc-patches]

Ping.

On 4/18/23 7:22 AM, Pat Haugen via Gcc-patches wrote:

Updated from prior patch to also disable for int128.


Disable generation of scalar modulo instructions.

It was recently discovered that the scalar modulo instructions can suffer
noticeable performance issues for certain input values. This patch disables
their generation since the equivalent div/mul/sub sequence does not suffer
the same problem.

Bootstrapped and regression tested on powerpc64/powerpc64le.
Ok for master and backports after burn in?

-Pat


2023-04-18  Pat Haugen  

gcc/
 * config/rs6000/rs6000.h (RS6000_DISABLE_SCALAR_MODULO): New.
 * config/rs6000/rs6000.md (mod3, *mod3): Disable.
 (define_expand umod3): New.
 (define_insn umod3): Rename to *umod3 and disable.
 (umodti3, modti3): Disable.

gcc/testsuite/
 * gcc.target/powerpc/clone1.c: Add xfails.
 * gcc.target/powerpc/clone3.c: Likewise.
 * gcc.target/powerpc/mod-1.c: Likewise.
 * gcc.target/powerpc/mod-2.c: Likewise.
 * gcc.target/powerpc/p10-vdivq-vmodq.c: Likewise.


diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
index 3503614efbd..1cf0a0013c0 100644
--- a/gcc/config/rs6000/rs6000.h
+++ b/gcc/config/rs6000/rs6000.h
@@ -2492,3 +2492,9 @@ while (0)
     rs6000_asm_output_opcode (STREAM);    \
  }    \
    while (0)
+
+/* Disable generation of scalar modulo instructions due to performance 
issues

+   with certain input values. This can be removed in the future when the
+   issues have been resolved.  */
+#define RS6000_DISABLE_SCALAR_MODULO 1
+
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 44f7dd509cb..4f397bc9179 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -3421,6 +3421,17 @@ (define_expand "mod3"
  FAIL;

    operands[2] = force_reg (mode, operands[2]);
+
+  if (RS6000_DISABLE_SCALAR_MODULO)
+    {
+  temp1 = gen_reg_rtx (mode);
+  temp2 = gen_reg_rtx (mode);
+
+  emit_insn (gen_div3 (temp1, operands[1], operands[2]));
+  emit_insn (gen_mul3 (temp2, temp1, operands[2]));
+  emit_insn (gen_sub3 (operands[0], operands[1], temp2));
+  DONE;
+    }
  }
    else
  {
@@ -3440,17 +3451,42 @@ (define_insn "*mod3"
    [(set (match_operand:GPR 0 "gpc_reg_operand" "=,r")
  (mod:GPR (match_operand:GPR 1 "gpc_reg_operand" "r,r")
   (match_operand:GPR 2 "gpc_reg_operand" "r,r")))]
-  "TARGET_MODULO"
+  "TARGET_MODULO && !RS6000_DISABLE_SCALAR_MODULO"
    "mods %0,%1,%2"
    [(set_attr "type" "div")
     (set_attr "size" "")])

+;; This define_expand can be removed when RS6000_DISABLE_SCALAR_MODULO is
+;; removed.
+(define_expand "umod3"
+  [(set (match_operand:GPR 0 "gpc_reg_operand")
+    (umod:GPR (match_operand:GPR 1 "gpc_reg_operand")
+  (match_operand:GPR 2 "gpc_reg_operand")))]
+  ""
+{
+  rtx temp1;
+  rtx temp2;
+
+  if (!TARGET_MODULO)
+    FAIL;

-(define_insn "umod3"
+  if (RS6000_DISABLE_SCALAR_MODULO)
+    {
+  temp1 = gen_reg_rtx (mode);
+  temp2 = gen_reg_rtx (mode);
+
+  emit_insn (gen_udiv3 (temp1, operands[1], operands[2]));
+  emit_insn (gen_mul3 (temp2, temp1, operands[2]));
+  emit_insn (gen_sub3 (operands[0], operands[1], temp2));
+  DONE;
+    }
+})
+
+(define_insn "*umod3"
    [(set (match_operand:GPR 0 "gpc_reg_operand" "=,r")
  (umod:GPR (match_operand:GPR 1 "gpc_reg_operand" "r,r")
    (match_operand:GPR 2 "gpc_reg_operand" "r,r")))]
-  "TARGET_MODULO"
+  "TARGET_MODULO && !RS6000_DISABLE_SCALAR_MODULO"
    "modu %0,%1,%2"
    [(set_attr "type" "div")
     (set_attr "size" "")])
@@ -3507,7 +3543,7 @@ (define_insn "umodti3"
    [(set (match_operand:TI 0 "altivec_register_operand" "=v")
  (umod:TI (match_operand:TI 1 "altivec_register_operand" "v")
   (match_operand:TI 2 "altivec_register_operand" "v")))]
-  "TARGET_POWER10 && TARGET_POWERPC64"
+  "TARGET_POWER10 && TARGET_POWERPC64 && !RS6000_DISABLE_SCALAR_MODULO"
    "vmoduq %0,%1,%2"
    [(set_attr "type" "vecdiv")
     (set_attr "size" "128")])
@@ -3516,7 +3552,7 @@ (define_insn "modti3"
    [(set (match_operand:TI 0 "altivec_register_operand" "=v")
  (mod:TI (match_operand:TI 1 "altivec_register_operand" "v")
  (match_operand:TI 2 "altivec_register_operand" "v")))]
-  "TARGET_POWER10 && TARGET_POWERPC64"
+  "TARGET_POWER10 && TARGET_POWERPC64 && !RS6000_DISABLE_SCALAR_MODULO"
    "vmodsq %0,%1,%2"
    [(set_attr "type" "vecdiv")
     (set_attr "size" "128")])
diff --git a/gcc/testsuite/gcc.target/powerpc/clone1.c 
b/gcc/testsuite/gcc.target/powerpc/clone1.c

index c69fd2aa1b8..74323ca0e8c 100644
--- a/gcc/testsuite/gcc.target/powerpc/clone1.c
+++ b/gcc/testsuite/gcc.target/powerpc/clone1.c
@@ -21,6 +21,7 @@ long mod_func_or (long a, long b, long c)
    return mod_func (a, b) | c;
  }

-/* { dg-final { scan-assembler-times {\mdivd\M}  1 } } */
-/* { dg-final { scan-assembler-times {\mmulld\M} 1 } } 

Re: [PATCH] Fix internal error on small array with negative lower bound

[Eric Botcazou via Gcc-patches]

> Would it be better to use
> 
>   wi::to_uhwi (wi::to_wide (local->index) - wi::to_wide (local->min_index))
> 
> to honor the actual sign of the indices?  I think nothing forbids frontends
> to use a signed TYPE_DOMAIN here?  But the difference should be always
> representable in an unsigned value of course.

We use tree_to_uhwi everywhere else though, see categorize_ctor_elements_1:

  if (tree_fits_uhwi_p (lo_index) && tree_fits_uhwi_p (hi_index))
mult = (tree_to_uhwi (hi_index)
- tree_to_uhwi (lo_index) + 1);

or store_constructor

this_node_count = (tree_to_uhwi (hi_index)
   - tree_to_uhwi (lo_index) + 1);

so the proposed form looks better for the sake of consistency.

-- 
Eric Botcazou

[Bug tree-optimization/106379] DCE depends on order

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106379

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 Depends on||106380
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
   Severity|normal  |enhancement

--- Comment #5 from Andrew Pinski  ---

  _1 = ~c_5(D);
  _2 = _1 & s_4(D);

Mine.
That is `c < s`.  So the same as PR 106380 .


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106380
[Bug 106380] DCE depends on datatype used (bool vs unsigned)

[Bug c++/109876] [10/11/12/13/14 Regression] initializer_list not usable in constant expressions in a template

[jason at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #6 from Jason Merrill  ---
(In reply to Patrick Palka from comment #5)
> Seems related to PR89144 too -- there we were mishandling defining a
> non-dependent static std::initializer_list member variable, here we're
> subsequently trying to use it.

The issue there is that the initializer_list wasn't static, but here it is, so
the array temporary should be as well.  And presumably the problem is that we
aren't representing that lifetime extension in a template.  And checking the
initializer gives up on trying to enforce that.  But then when we try to
evaluate the template argument we find that we don't have a constant value to
work with, and complain.  

Instead, we should probably treat num as value-dependent even though it
actually isn't.  Or fix it to be properly evaluated by representing the
lifetime extension somehow.

[Bug tree-optimization/106381] DCE depends on used programming language (C vs C++)

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106381

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-05-18
 Ever confirmed|0   |1
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Actually it is worse in GCC 13. Both the C and C++ front-ends produced IR does
not get optimized.

[Bug tree-optimization/106380] DCE depends on datatype used (bool vs unsigned)

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106380

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org

[Bug tree-optimization/106380] DCE depends on datatype used (bool vs unsigned)

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106380

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-05-18
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Mine.

In this case if we fold:
  _1 = ~s_4(D);
  _2 = _1 & c_5(D);

to
s < c

Then the rest will be optimized by normally.

Re: [PATCH 2/3] Refactor widen_plus as internal_fn

[Andre Vieira (lists) via Gcc-patches]

How about this?

Not sure about the DEF_INTERNAL documentation I rewrote in 
internal-fn.def, was struggling to word these, so improvements welcome!


gcc/ChangeLog:

2023-04-25  Andre Vieira  
Joel Hutton  
Tamar Christina  

* config/aarch64/aarch64-simd.md 
(vec_widen_addl_lo_): Rename

this ...
(vec_widen_add_lo_): ... to this.
(vec_widen_addl_hi_): Rename this ...
(vec_widen_add_hi_): ... to this.
(vec_widen_subl_lo_): Rename this ...
(vec_widen_sub_lo_): ... to this.
(vec_widen_subl_hi_): Rename this ...
(vec_widen_sub_hi_): ...to this.
* doc/generic.texi: Document new IFN codes.
	* internal-fn.cc (ifn_cmp): Function to compare ifn's for 
sorting/searching.

(lookup_hilo_internal_fn): Add lookup function.
(commutative_binary_fn_p): Add widen_plus fn's.
(widening_fn_p): New function.
(narrowing_fn_p): New function.
(direct_internal_fn_optab): Change visibility.
* internal-fn.def (DEF_INTERNAL_WIDENING_OPTAB_FN): Macro to define an
internal_fn that expands into multiple internal_fns for widening.
(DEF_INTERNAL_NARROWING_OPTAB_FN): Likewise but for narrowing.
(IFN_VEC_WIDEN_PLUS, IFN_VEC_WIDEN_PLUS_HI, IFN_VEC_WIDEN_PLUS_LO,
 IFN_VEC_WIDEN_PLUS_EVEN, IFN_VEC_WIDEN_PLUS_ODD,
 IFN_VEC_WIDEN_MINUS, IFN_VEC_WIDEN_MINUS_HI, 
IFN_VEC_WIDEN_MINUS_LO,
 IFN_VEC_WIDEN_MINUS_ODD, IFN_VEC_WIDEN_MINUS_EVEN): Define 
widening

plus,minus functions.
* internal-fn.h (direct_internal_fn_optab): Declare new prototype.
(lookup_hilo_internal_fn): Likewise.
(widening_fn_p): Likewise.
(Narrowing_fn_p): Likewise.
* optabs.cc (commutative_optab_p): Add widening plus optabs.
* optabs.def (OPTAB_D): Define widen add, sub optabs.
* tree-cfg.cc (verify_gimple_call): Add checks for widening ifns.
* tree-inline.cc (estimate_num_insns): Return same
cost for widen add and sub IFNs as previous tree_codes.
* tree-vect-patterns.cc (vect_recog_widen_op_pattern): Support
patterns with a hi/lo or even/odd split.
(vect_recog_sad_pattern): Refactor to use new IFN codes.
(vect_recog_widen_plus_pattern): Likewise.
(vect_recog_widen_minus_pattern): Likewise.
(vect_recog_average_pattern): Likewise.
* tree-vect-stmts.cc (vectorizable_conversion): Add support for
_HILO IFNs.
(supportable_widening_operation): Likewise.
* tree.def (WIDEN_SUM_EXPR): Update example to use new IFNs.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/vect-widen-add.c: Test that new
IFN_VEC_WIDEN_PLUS is being used.
* gcc.target/aarch64/vect-widen-sub.c: Test that new
IFN_VEC_WIDEN_MINUS is being used.diff --git a/gcc/config/aarch64/aarch64-simd.md 
b/gcc/config/aarch64/aarch64-simd.md
index 
bfc98a8d943467b33390defab9682f44efab5907..ffbbecb9409e1c2835d658c2a8855cd0e955c0f2
 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -4626,7 +4626,7 @@
   [(set_attr "type" "neon__long")]
 )
 
-(define_expand "vec_widen_addl_lo_"
+(define_expand "vec_widen_add_lo_"
   [(match_operand: 0 "register_operand")
(ANY_EXTEND: (match_operand:VQW 1 "register_operand"))
(ANY_EXTEND: (match_operand:VQW 2 "register_operand"))]
@@ -4638,7 +4638,7 @@
   DONE;
 })
 
-(define_expand "vec_widen_addl_hi_"
+(define_expand "vec_widen_add_hi_"
   [(match_operand: 0 "register_operand")
(ANY_EXTEND: (match_operand:VQW 1 "register_operand"))
(ANY_EXTEND: (match_operand:VQW 2 "register_operand"))]
@@ -4650,7 +4650,7 @@
   DONE;
 })
 
-(define_expand "vec_widen_subl_lo_"
+(define_expand "vec_widen_sub_lo_"
   [(match_operand: 0 "register_operand")
(ANY_EXTEND: (match_operand:VQW 1 "register_operand"))
(ANY_EXTEND: (match_operand:VQW 2 "register_operand"))]
@@ -4662,7 +4662,7 @@
   DONE;
 })
 
-(define_expand "vec_widen_subl_hi_"
+(define_expand "vec_widen_sub_hi_"
   [(match_operand: 0 "register_operand")
(ANY_EXTEND: (match_operand:VQW 1 "register_operand"))
(ANY_EXTEND: (match_operand:VQW 2 "register_operand"))]
diff --git a/gcc/doc/generic.texi b/gcc/doc/generic.texi
index 
8b2882da4fe7da07d22b4e5384d049ba7d3907bf..5e36dac2b1a10257616f12cdfb0b12d0f2879ae9
 100644
--- a/gcc/doc/generic.texi
+++ b/gcc/doc/generic.texi
@@ -1811,10 +1811,16 @@ a value from @code{enum annot_expr_kind}, the third is 
an @code{INTEGER_CST}.
 @tindex VEC_RSHIFT_EXPR
 @tindex VEC_WIDEN_MULT_HI_EXPR
 @tindex VEC_WIDEN_MULT_LO_EXPR
-@tindex VEC_WIDEN_PLUS_HI_EXPR
-@tindex VEC_WIDEN_PLUS_LO_EXPR
-@tindex VEC_WIDEN_MINUS_HI_EXPR
-@tindex VEC_WIDEN_MINUS_LO_EXPR
+@tindex IFN_VEC_WIDEN_PLUS
+@tindex IFN_VEC_WIDEN_PLUS_HI
+@tindex IFN_VEC_WIDEN_PLUS_LO
+@tindex IFN_VEC_WIDEN_PLUS_EVEN
+@tindex IFN_VEC_WIDEN_PLUS_ODD
+@tindex IFN_VEC_WIDEN_MINUS
+@tindex IFN_VEC_WIDEN_MINUS_HI
+@tindex 

[Bug tree-optimization/106185] Spurious Wstringop-overflow in std::vector::resize

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106185

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #1 from Andrew Pinski  ---
This looks to be fixed in GCC 13. I think there was a missed optimization which
is being caught now. It would be interesting to know which patch fixed the
warning (and missed optimization).

[Bug c++/109876] [10/11/12/13/14 Regression] initializer_list not usable in constant expressions in a template

[ppalka at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876

Patrick Palka  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=89144
 CC||ppalka at gcc dot gnu.org

--- Comment #5 from Patrick Palka  ---
Seems related to PR89144 too -- there we were mishandling defining a
non-dependent static std::initializer_list member variable, here we're
subsequently trying to use it.

[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109641

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |13.2
 Resolution|--- |FIXED

--- Comment #18 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-14, and backported to 13-branch.  Closing.

Thanks for the report!

Re: [PATCH v1] tree-ssa-sink: Improve code sinking pass.

[Segher Boessenkool]

Hi!

On Thu, May 18, 2023 at 12:44:28PM +0530, Ajit Agarwal wrote:
> This patch improves code sinking pass to sink statements before call to reduce
> register pressure.

An example would be useful :-)

>   * tree-ssa-sink.cc (statement_sink_location): Modifed to
>   move statements before calls.

Spello ("modified").  But, you should write in the imperative mood
anyway, so "modify".  But, every change is a modification, so do without
the fluff altogether?  "Move statements before calls."

>   (block_call_p): New function.
>   (def_use_same_block): New function.
>   (select_best_block): Add heuristics to select the best
>   blocks in the immediate post dominator.

Please don't break lines
early
it makes things
harder to
read.

:-)

> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-20.c
> @@ -0,0 +1,16 @@
> +/* { dg-do compile } */

This is the default, you can just leave it out.

> +/* { dg-options "-O2 -fdump-tree-sink -fdump-tree-optimized 
> -fdump-tree-sink-stats" } */

You don't need -fdump-tree-sink without options since you have
-fdump-tree-sink-stats as well.

> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-21.c
> @@ -0,0 +1,20 @@
> +/* { dg-do compile } */ 
> +/* { dg-options "-O2 -fdump-tree-sink-stats -fdump-tree-sink-stats" } */

You don't need to say it twice either :-)

> +/* Return TRUE if immediate uses of the defs in
> +   USE occur in the same block as USE, FALSE otherwise.  */
> +
> +bool
> +def_use_same_block (gimple *stmt)
> +{

There is no function parameter "use" here?  STMT instead?

> +  use_operand_p use_p;
> +  def_operand_p def_p;

Neither of these is a predicate.  Lose the _p please?

> +   if (use_p
> +   && (gimple_bb (USE_STMT (use_p)) == gimple_bb (stmt)))

Please fit this on one line.  And no parens around random things please.

> +/* Return TRUE if the block has only calls, FALSE otherwise. */
> +
> +bool
> +block_call_p (basic_block bb)

> +/* We have already seen a call.  */
> +if (is_call)
> +  return false;
> +
> +if (is_gimple_call (stmt))
> +  is_call = true;
> +else
> +  return false;

> +  if (is_call && i == 1)
> +return true;
> +
> +  return false;

This doesn't do what the function comment says?  It is very important
that function comments say exactly what a function does.  It can perhaps
leave out some details, but it should be correct by and large.

> + /* Update sinking point as stmt before call if the sinking block
> +has only calls. Otherwise update sinking point as the use
> +stmt. */

(two spaces after full stop, twice)

> + if (gsi_stmt (gsi) == use
> + && !is_gimple_call (last_stmt)
> + && (gimple_code (last_stmt) != GIMPLE_SWITCH)
> + && (gimple_code (last_stmt) != GIMPLE_COND)
> + && (gimple_code (last_stmt) != GIMPLE_GOTO)
> + && (!gimple_vdef (use) || !def_use_same_block (def_stmt)))

Please no unnecessary parens.  At first I didn't notice the last line
here *does* need it!


Segher

RE: [PATCH] PR gcc/98350:Handle FMA friendly in reassoc pass

[Cui, Lili via Gcc-patches]

Attach CPU2017 3 run results:

On ICX: 
507.cactuBSSN_r: Improved by 1.7% for multi-copy .
503.bwaves_r  : Improved by  0.60% for single copy .
507.cactuBSSN_r : Improved by  1.10% for single copy .
519.lbm_r : Improved by  2.21% for single copy .
no measurable changes for other benchmarks.

On aarch64 
507.cactuBSSN_r: Improved by 1.7% for multi-copy.
503.bwaves_r : Improved by 6.00% for single-copy.
no measurable changes for other benchmarks.

> -Original Message-
> From: Cui, Lili 
> Sent: Wednesday, May 17, 2023 9:02 PM
> To: gcc-patches@gcc.gnu.org
> Cc: richard.guent...@gmail.com; Cui, Lili 
> Subject: [PATCH] PR gcc/98350:Handle FMA friendly in reassoc pass
> 
> From: Lili Cui 
> 
> Make some changes in reassoc pass to make it more friendly to fma pass
> later.
> Using FMA instead of mult + add reduces register pressure and insruction
> retired.
> 
> There are mainly two changes
> 1. Put no-mult ops and mult ops alternately at the end of the queue, which is
> conducive to generating more fma and reducing the loss of FMA when
> breaking the chain.
> 2. Rewrite the rewrite_expr_tree_parallel function to try to build parallel
> chains according to the given correlation width, keeping the FMA chance as
> much as possible.
> 
> TEST1:
> 
> float
> foo (float a, float b, float c, float d, float *e) {
>return  *e  + a * b + c * d ;
> }
> 
> For "-Ofast -mfpmath=sse -mfma" GCC generates:
> vmulss  %xmm3, %xmm2, %xmm2
> vfmadd132ss %xmm1, %xmm2, %xmm0
> vaddss  (%rdi), %xmm0, %xmm0
> ret
> 
> With this patch GCC generates:
> vfmadd213ss   (%rdi), %xmm1, %xmm0
> vfmadd231ss   %xmm2, %xmm3, %xmm0
> ret
> 
> TEST2:
> 
> for (int i = 0; i < N; i++)
> {
>   a[i] += b[i]* c[i] + d[i] * e[i] + f[i] * g[i] + h[i] * j[i] + k[i] * l[i] 
> + m[i]* o[i] +
> p[i]; }
> 
> For "-Ofast -mfpmath=sse -mfma"  GCC generates:
>   vmovapd e(%rax), %ymm4
>   vmulpd  d(%rax), %ymm4, %ymm3
>   addq$32, %rax
>   vmovapd c-32(%rax), %ymm5
>   vmovapd j-32(%rax), %ymm6
>   vmulpd  h-32(%rax), %ymm6, %ymm2
>   vmovapd a-32(%rax), %ymm6
>   vaddpd  p-32(%rax), %ymm6, %ymm0
>   vmovapd g-32(%rax), %ymm7
>   vfmadd231pd b-32(%rax), %ymm5, %ymm3
>   vmovapd o-32(%rax), %ymm4
>   vmulpd  m-32(%rax), %ymm4, %ymm1
>   vmovapd l-32(%rax), %ymm5
>   vfmadd231pd f-32(%rax), %ymm7, %ymm2
>   vfmadd231pd k-32(%rax), %ymm5, %ymm1
>   vaddpd  %ymm3, %ymm0, %ymm0
>   vaddpd  %ymm2, %ymm0, %ymm0
>   vaddpd  %ymm1, %ymm0, %ymm0
>   vmovapd %ymm0, a-32(%rax)
>   cmpq$8192, %rax
>   jne .L4
>   vzeroupper
>   ret
> 
> with this patch applied GCC breaks the chain with width = 2 and generates 6
> fma:
> 
>   vmovapd a(%rax), %ymm2
>   vmovapd c(%rax), %ymm0
>   addq$32, %rax
>   vmovapd e-32(%rax), %ymm1
>   vmovapd p-32(%rax), %ymm5
>   vmovapd g-32(%rax), %ymm3
>   vmovapd j-32(%rax), %ymm6
>   vmovapd l-32(%rax), %ymm4
>   vmovapd o-32(%rax), %ymm7
>   vfmadd132pd b-32(%rax), %ymm2, %ymm0
>   vfmadd132pd d-32(%rax), %ymm5, %ymm1
>   vfmadd231pd f-32(%rax), %ymm3, %ymm0
>   vfmadd231pd h-32(%rax), %ymm6, %ymm1
>   vfmadd231pd k-32(%rax), %ymm4, %ymm0
>   vfmadd231pd m-32(%rax), %ymm7, %ymm1
>   vaddpd  %ymm1, %ymm0, %ymm0
>   vmovapd %ymm0, a-32(%rax)
>   cmpq$8192, %rax
>   jne .L2
>   vzeroupper
>   ret
> 
> gcc/ChangeLog:
> 
>   PR gcc/98350
>   * tree-ssa-reassoc.cc
>   (rewrite_expr_tree_parallel): Rewrite this function.
>   (rank_ops_for_fma): New.
>   (reassociate_bb): Handle new function.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR gcc/98350
>   * gcc.dg/pr98350-1.c: New test.
>   * gcc.dg/pr98350-2.c: Ditto.
> ---
>  gcc/testsuite/gcc.dg/pr98350-1.c |  31   gcc/testsuite/gcc.dg/pr98350-2.c
> |  11 ++
>  gcc/tree-ssa-reassoc.cc  | 256 +--
>  3 files changed, 215 insertions(+), 83 deletions(-)  create mode 100644
> gcc/testsuite/gcc.dg/pr98350-1.c  create mode 100644
> gcc/testsuite/gcc.dg/pr98350-2.c
> 
> diff --git a/gcc/testsuite/gcc.dg/pr98350-1.c b/gcc/testsuite/gcc.dg/pr98350-
> 1.c
> new file mode 100644
> index 000..185511c5e0a
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr98350-1.c
> @@ -0,0 +1,31 @@
> +/* { dg-do compile } */
> +/* { dg-options "-Ofast -mfpmath=sse -mfma -Wno-attributes " } */
> +
> +/* Test that the compiler properly optimizes multiply and add
> +   to generate more FMA instructions.  */ #define N 1024 double a[N];
> +double b[N]; double c[N]; double d[N]; double e[N]; double f[N]; double
> +g[N]; double h[N]; double j[N]; double k[N]; double l[N]; double m[N];
> +double o[N]; double p[N];
> +
> +
> +void
> +foo (void)
> +{
> +  for (int i = 0; i < N; i++)
> +  {
> +a[i] += b[i] * c[i] + d[i] * e[i] + f[i] * g[i] + 

[Bug fortran/109846] Pointer-valued function reference rejected as actual argument

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109846

--- Comment #7 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:f48c546902802cf640c4f2802543acfdc702404f

commit r13-7354-gf48c546902802cf640c4f2802543acfdc702404f
Author: Harald Anlauf 
Date:   Sun May 14 21:53:51 2023 +0200

Fortran: CLASS pointer function result in variable definition context
[PR109846]

gcc/fortran/ChangeLog:

PR fortran/109846
* expr.cc (gfc_check_vardef_context): Check appropriate pointer
attribute for CLASS vs. non-CLASS function result in variable
definition context.

gcc/testsuite/ChangeLog:

PR fortran/109846
* gfortran.dg/ptr-func-5.f90: New test.

(cherry picked from commit fa0569e90efe8a5cb895a3f50dd502f849940828)

[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109641

--- Comment #17 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:611be07e48956c8b7371eb580eef124990114fd3

commit r13-7353-g611be07e48956c8b7371eb580eef124990114fd3
Author: Harald Anlauf 
Date:   Fri May 5 21:22:12 2023 +0200

Fortran: overloading of intrinsic binary operators [PR109641]

Fortran allows overloading of intrinsic operators also for operands of
numeric intrinsic types.  The intrinsic operator versions are used
according to the rules of F2018 table 10.2 and imply type conversion as
long as the operand ranks are conformable.  Otherwise no type conversion
shall be performed to allow the resolution of a matching user-defined
operator.

gcc/fortran/ChangeLog:

PR fortran/109641
* arith.cc (eval_intrinsic): Check conformability of ranks of
operands
for intrinsic binary operators before performing type conversions.
* gfortran.h (gfc_op_rank_conformable): Add prototype.
* resolve.cc (resolve_operator): Check conformability of ranks of
operands for intrinsic binary operators before performing type
conversions.
(gfc_op_rank_conformable): New helper function to compare ranks of
operands of binary operator.

gcc/testsuite/ChangeLog:

PR fortran/109641
* gfortran.dg/overload_5.f90: New test.

(cherry picked from commit 185da7c2014ba41f38dd62cc719873ebf020b076)

[Bug target/106902] [11/12/13/14 Regression] Program compiled with -O3 -mfma produces different result

[rguenther at suse dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902

--- Comment #27 from rguenther at suse dot de  ---
> Am 18.05.2023 um 10:31 schrieb amonakov at gcc dot gnu.org 
> :
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
> 
> --- Comment #25 from Alexander Monakov  ---
> (In reply to Richard Biener from comment #24)
>> As of the patch it looks good, I wonder if we want to check for OPTIMIZE_BOTH
>> though since at least when no extra negations are required the contraction
>> should also be a win when optimizing for size?
> 
> Makes sense, I'll change that (current target hooks always return true for
> fma).
> 
>> Also I wondered about the PROP_gimple_any check - do we get into the
>> gimplification langhook after lowering?  I see we are not resetting the
>> langhook after lowering (only in free-lang-data, but that only runs with
>> LTO).
> 
> Yes, that surprised me. I caught it when analyzing ICE on slp-50.c testcase.
> 
>> We probably at least should gate the langhook invocation in the gimplifier
>> with what you added in the patch or specify whether the gimplifier is
>> invoked from the middle-end via the gimplifier context.
> 
> Perhaps. I'll add a comment that we want to handle -ffp-contract=on strictly
> during initial gimplification, to hash this out further on gcc-patches, if
> necessary.  
> 
>> If we go for c-family only the genericize entry could be another place to
>> handle this.
> 
> That seems less convenient to me. Is IFN_FMA representable as a tree?

Yes, that’s possible.  Let’s see if others have an opinion on the ml.

>> Did you run into any of NON_LVALUE / C_MAYBE_CONST wrappings of the
>> multiplication btw?
> 
> No, I'm not familiar with those, so I didn't try to construct corresponding
> testcases.
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug c++/106143] Add fix-it for missing ::value on trait with std::integral_constant base

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106143

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[avr,committed] Fix a trivial typo in gen-avr-mmcu-specs.cc.

[Georg-Johann Lay]

Applied as obvious, there was a trailing */ in a 1-line // comment.

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=a726d007f197d13ec80b9d625bf8bab97c96384c

Johann


gcc/ChangeLog
* config/avr/gen-avr-mmcu-specs.cc: Remove stale */ after // comment.

--

diff --git a/gcc/config/avr/gen-avr-mmcu-specs.cc 
b/gcc/config/avr/gen-avr-mmcu-specs.cc
index 
9344246cb7203a665db575a2bf7c0e8a29521963..b9a5ad44e4e5c350fbcc45d468684ff6d873574e 
100644 (file)

--- a/gcc/config/avr/gen-avr-mmcu-specs.cc
+++ b/gcc/config/avr/gen-avr-mmcu-specs.cc
@@ -30,7 +30,7 @@
 #include "avr-devices.cc"

 // Get rid of "defaults.h".  We just need tm.h for `WITH_AVRLIBC' and
-// and `WITH_RTEMS'.  */
+// and `WITH_RTEMS'.
 #define GCC_DEFAULTS_H

 #include "tm.h"

[Bug c++/109876] [10/11/12/13/14 Regression] initializer_list not usable in constant expressions in a template

[mpolacek at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876

Marek Polacek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

[Bug c++/105826] failure to compile namespace-scope constexpr new-expression

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105826

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-05-18
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.

Re: [aarch64] Code-gen for vector initialization involving constants

[Richard Sandiford via Gcc-patches]

Prathamesh Kulkarni  writes:
> On Thu, 18 May 2023 at 13:37, Richard Sandiford
>  wrote:
>>
>> Prathamesh Kulkarni  writes:
>> > On Tue, 16 May 2023 at 00:29, Richard Sandiford
>> >  wrote:
>> >>
>> >> Prathamesh Kulkarni  writes:
>> >> > Hi Richard,
>> >> > After committing the interleave+zip1 patch for vector initialization,
>> >> > it seems to regress the s32 case for this patch:
>> >> >
>> >> > int32x4_t f_s32(int32_t x)
>> >> > {
>> >> >   return (int32x4_t) { x, x, x, 1 };
>> >> > }
>> >> >
>> >> > code-gen:
>> >> > f_s32:
>> >> > moviv30.2s, 0x1
>> >> > fmovs31, w0
>> >> > dup v0.2s, v31.s[0]
>> >> > ins v30.s[0], v31.s[0]
>> >> > zip1v0.4s, v0.4s, v30.4s
>> >> > ret
>> >> >
>> >> > instead of expected code-gen:
>> >> > f_s32:
>> >> > moviv31.2s, 0x1
>> >> > dup v0.4s, w0
>> >> > ins v0.s[3], v31.s[0]
>> >> > ret
>> >> >
>> >> > Cost for fallback sequence: 16
>> >> > Cost for interleave and zip sequence: 12
>> >> >
>> >> > For the above case, the cost for interleave+zip1 sequence is computed 
>> >> > as:
>> >> > halves[0]:
>> >> > (set (reg:V2SI 96)
>> >> > (vec_duplicate:V2SI (reg/v:SI 93 [ x ])))
>> >> > cost = 8
>> >> >
>> >> > halves[1]:
>> >> > (set (reg:V2SI 97)
>> >> > (const_vector:V2SI [
>> >> > (const_int 1 [0x1]) repeated x2
>> >> > ]))
>> >> > (set (reg:V2SI 97)
>> >> > (vec_merge:V2SI (vec_duplicate:V2SI (reg/v:SI 93 [ x ]))
>> >> > (reg:V2SI 97)
>> >> > (const_int 1 [0x1])))
>> >> > cost = 8
>> >> >
>> >> > followed by:
>> >> > (set (reg:V4SI 95)
>> >> > (unspec:V4SI [
>> >> > (subreg:V4SI (reg:V2SI 96) 0)
>> >> > (subreg:V4SI (reg:V2SI 97) 0)
>> >> > ] UNSPEC_ZIP1))
>> >> > cost = 4
>> >> >
>> >> > So the total cost becomes
>> >> > max(costs[0], costs[1]) + zip1_insn_cost
>> >> > = max(8, 8) + 4
>> >> > = 12
>> >> >
>> >> > While the fallback rtl sequence is:
>> >> > (set (reg:V4SI 95)
>> >> > (vec_duplicate:V4SI (reg/v:SI 93 [ x ])))
>> >> > cost = 8
>> >> > (set (reg:SI 98)
>> >> > (const_int 1 [0x1]))
>> >> > cost = 4
>> >> > (set (reg:V4SI 95)
>> >> > (vec_merge:V4SI (vec_duplicate:V4SI (reg:SI 98))
>> >> > (reg:V4SI 95)
>> >> > (const_int 8 [0x8])))
>> >> > cost = 4
>> >> >
>> >> > So total cost = 8 + 4 + 4 = 16, and we choose the interleave+zip1 
>> >> > sequence.
>> >> >
>> >> > I think the issue is probably that for the interleave+zip1 sequence we 
>> >> > take
>> >> > max(costs[0], costs[1]) to reflect that both halves are interleaved,
>> >> > but for the fallback seq we use seq_cost, which assumes serial execution
>> >> > of insns in the sequence.
>> >> > For above fallback sequence,
>> >> > set (reg:V4SI 95)
>> >> > (vec_duplicate:V4SI (reg/v:SI 93 [ x ])))
>> >> > and
>> >> > (set (reg:SI 98)
>> >> > (const_int 1 [0x1]))
>> >> > could be executed in parallel, which would make it's cost max(8, 4) + 4 
>> >> > = 12.
>> >>
>> >> Agreed.
>> >>
>> >> A good-enough substitute for this might be to ignore scalar moves
>> >> (for both alternatives) when costing for speed.
>> > Thanks for the suggestions. Just wondering for aarch64, if there's an easy
>> > way we can check if insn is a scalar move, similar to riscv's 
>> > scalar_move_insn_p
>> > that checks if get_attr_type(insn) is TYPE_VIMOVXV or TYPE_VFMOVFV ?
>>
>> It should be enough to check that the pattern is a SET:
>>
>> (a) whose SET_DEST has a scalar mode and
>> (b) whose SET_SRC an aarch64_mov_operand
> Hi Richard,
> Thanks for the suggestions, the attached patch calls seq_cost to compute
> cost for sequence and then subtracts cost of each scalar move insn from it.
> Does that look OK ?
> The patch is under bootstrap+test on aarch64-linux-gnu.

Yeah, the patch looks reasonable (some comments below).  The testing
for this kind of patch is more than a formality though, so it would
be good to wait to see if the tests pass.

> [...]
> diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
> index 29dbacfa917..7efd896d364 100644
> --- a/gcc/config/aarch64/aarch64.cc
> +++ b/gcc/config/aarch64/aarch64.cc
> @@ -22332,6 +22332,32 @@ aarch64_unzip_vector_init (machine_mode mode, rtx 
> vals, bool even_p)
>return gen_rtx_PARALLEL (new_mode, vec);
>  }
>  
> +/* Return true if INSN is a scalar move.  */
> +
> +static bool
> +scalar_move_insn_p (rtx_insn *insn)
> +{
> +  rtx set = single_set (insn);
> +  if (!set)
> +return false;
> +  rtx src = SET_SRC (set);
> +  rtx dest = SET_DEST (set);
> +  return is_a(GET_MODE (dest)) && aarch64_mov_operand_p (src, 
> GET_MODE (src));

Long line.

> +}
> +
> +/* Ignore cost for scalar moves from cost of sequence. This function is 
> called
> +   for calculating sequence costs in aarch64_expand_vector_init.  */
> +
> +static unsigned
> +seq_cost_ignore_scalar_moves (rtx_insn *seq, bool speed)

Maybe more readable as "ignoring" rather 

Re: [wish] Flexible array members in unions

[Martin Uecker via Gcc]

> On Thu, May 11, 2023 at 11:14 PM Kees Cook via Gcc  wrote:
> >
> > On Thu, May 11, 2023 at 08:53:52PM +, Joseph Myers wrote:
> > > On Thu, 11 May 2023, Kees Cook via Gcc wrote:
> > >
> > > > On Thu, May 11, 2023 at 06:29:10PM +0200, Alejandro Colomar wrote:
> > > > > On 5/11/23 18:07, Alejandro Colomar wrote:
> > > > > [...]
> > > > > > Would you allow flexible array members in unions?  Is there any
> > > > > > strong reason to disallow them?
> > > >
> > > > Yes please!! And alone in a struct, too.
> > > >
> > > > AFAICT, there is no mechanical/architectural reason to disallow them
> > > > (especially since they _can_ be constructed with some fancy tricks,
> > > > and they behave as expected.) My understanding is that it's disallowed
> > > > due to an overly strict reading of the very terse language that created
> > > > flexible arrays in C99.
> > >
> > > Standard C has no such thing as a zero-size object or type, which would
> > > lead to problems with a struct or union that only contains a flexible
> > > array member there.

(I think it is fundamentally not too problematic to have zero-size
objects, although it would take some work to specify the semantics
exactly.)

But my preference would be to make structs / unions with FAM an
incomplete type which would then restrict their use (for the cases
now supported we would need backwards compatible exceptions).
We could then allow such a struct / union as the last member
of another struct / union which would make this an incomplete
type too.

We then would need a special macro (based on a builtin) instead
of sizeof to get the size, but this would be safer anyway.

In principle, an even better solution would be to allow dynamic
arrays because then it has a dynamic bound where the type with
the bound could propagate to some user. Bounds checking would
work as expected and more cases.

struct foo {
  int len;
  char buf[.len];
};

But this takes a bit more work to get right.

> >
> > Ah-ha, okay. That root cause makes sense now.
> 
> Hmm. but then the workaround
> 
> struct X {
>   int n;
>   union u {
>   char at_least_size_one;
>   int iarr[];
>   short sarr[];
>   };
> };
> 
> doesn't work either.  We could make that a GNU extension without
> adverse effects?

I think we could allow this even without the "at_least_size_one"
without a problem when allowing the use of such unions only as
a last member of some structure. Allowing it elsewhere seems
questionable anyway.

> Richard.
> 
> > Why are zero-sized objects missing in Standard C? Or, perhaps, the better
> > question is: what's needed to support the idea of a zero-sized object?

Probably a lot of convincing that it actually does not cause problems,
and is useful. Also a lot of work in making sure the standard is revised
everywhere where it is necessary. I think zero sized objects and
especially arrays are very useful also to avoid special code for corner
cases in numerical algorithms. But I think here some restrictions on
the use of the FAM will do.


Martin


 

[Bug target/109903] Register misallocation in hand-crafted asm insn, no diagnostics produced

[dimitri.gorokhovik at free dot fr via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109903

--- Comment #6 from Dimitri Gorokhovik  ---
Thank you Andrew, I indeed see now the early-clobber effect of this code.

It isn't that we don't read documentation (we do time to time), rather our real
asm statement has more output ops and more elementary instructions in the
template, so the early-clobber effect doesn't jump to the eye quite as easily.
I guess we have to mask all output ops as early clobbers.

Re: [v2] RISC-V: Remove masking third operand of rotate instructions

[Joern Rennecke]

On Thu, 18 May 2023 at 16:37, Joern Rennecke  wrote
in https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618928.html :
>
> This breaks building libstdc++-v3 for
> -march=rv32imafdcv_zicsr_zifencei_zba_zbb_zbc_zbs_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b
> -mabi=ilp32f .

Sorry, I forgot the ChangeLog entry for my patch and missed the [v2]
part of the subject.

2023-05-18  Joern Rennecke  

gcc/ChangeLog:
* config/riscv/constraints.md (DsS, DsD): Restore agreement
with shiftm1 mode attribute.
diff --git a/gcc/config/riscv/constraints.md b/gcc/config/riscv/constraints.md
index c448e6b37e9..44525b2da49 100644
--- a/gcc/config/riscv/constraints.md
+++ b/gcc/config/riscv/constraints.md
@@ -65,13 +65,13 @@
   "@internal
31 immediate"
   (and (match_code "const_int")
-   (match_test "ival == 31")))
+   (match_test "(ival & 31) == 31")))
 
 (define_constraint "DsD"
   "@internal
63 immediate"
   (and (match_code "const_int")
-   (match_test "ival == 63")))
+   (match_test "(ival & 63) == 63")))
 
 (define_constraint "DbS"
   "@internal"

[Bug target/106902] [11/12/13/14 Regression] Program compiled with -O3 -mfma produces different result

[amonakov at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902

--- Comment #26 from Alexander Monakov  ---
> > Did you run into any of NON_LVALUE / C_MAYBE_CONST wrappings of the
> > multiplication btw?
> 
> No, I'm not familiar with those, so I didn't try to construct corresponding
> testcases.

I had a look now. My understanding is they are eliminated in c_fully_fold, so
c_gimplify_expr will not encounter those trees.

[Bug libstdc++/109891] Null pointer special handling in ostream's operator << for C-strings

[xry111 at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109891

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #8 from Xi Ruoyao  ---
(In reply to Jonathan Wakely from comment #7)
> Oops, if I'd typed PEDASSERT not PEDANTIC, it would be a deliberate choice
> ;-)
> 
> Yes, I think PEDASSERT fits better, based on the documented meaning of it
> (which even mentions the std::string((const char*)nullptr) case):
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode_semantics.html

Ccan we add a "pednonnull" attribute or something to produce a -Wnonnull
warning like the nonnull attribute but w/o affecting code generation as well? 
I remember we've discussed "adding nonnull attribute for
basic_ostream::operator<<" and the idea was rejected because the nonnull
attribute would throw away the null pointer check.