[Bug c/110205] New: Some new warnings from clang for the range code

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 110205
   Summary: Some new warnings from clang for the range code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

I just did a build of gcc trunk with clang. It said

../../trunk.year/gcc/range-op-mixed.h:215:8: warning: 'fold_range' overrides a
member function but is not marked 'override' [-Winconsistent-missing-override]
../../trunk.year/gcc/range-op-mixed.h:222:8: warning: 'op1_range' overrides a
member function but is not marked 'override' [-Winconsistent-missing-override]
../../trunk.year/gcc/range-op-mixed.h:229:8: warning: 'op2_range' overrides a
member function but is not marked 'override' [-Winconsistent-missing-override]
../../trunk.year/gcc/range-op-mixed.h:236:8: warning: 'update_bitmask'
overrides a member function but is not marked 'override'
[-Winconsistent-missing-override]
../../trunk.year/gcc/range-op.cc:169:16: warning: unused variable 'RO_FII'
[-Wunused-const-variable]
../../trunk.year/gcc/range-op.cc:2292:8: warning: 'update_bitmask' overrides a
member function but is not marked 'override' [-Winconsistent-missing-override]

These might be worth fixing. The unused variable might be a typo or some
missing code.

[Bug c/110169] wrong code with '-Ofast'

[19373742 at buaa dot edu.cn via Gcc-bugs]

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

--- Comment #3 from CTC <19373742 at buaa dot edu.cn> ---
(In reply to Alexander Monakov from comment #2)
> It seems csmith was run with the --float argument. Differences under -Ofast
> are expected (but even without -Ofast, it seems csmith can emit bit
> manipulation of arbitrary floats, which can lead to unpredictable results
> when NaNs are involved).

It's true that I ran csmith with '--float --paranoid'. Sorry for the misreport.

[Bug c/110169] wrong code with '-Ofast'

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID
 CC||xry111 at gcc dot gnu.org

--- Comment #4 from Xi Ruoyao  ---
.

[Bug middle-end/109907] Missed optimization for bit extraction (uses shift instead of single bit-test)

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

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

--- Comment #30 from CVS Commits  ---
The master branch has been updated by Georg-Johann Lay :

https://gcc.gnu.org/g:20643513b8dd34c07f2b0fccf119153a30735f66

commit r14-1694-g20643513b8dd34c07f2b0fccf119153a30735f66
Author: Georg-Johann Lay 
Date:   Sat Jun 10 23:21:13 2023 +0200

target/19907: Overhaul bit extractions.

o Logical right shift that shifts the MSB to position 0 can be performed in
  such a way that the input operand constraint can be relaxed from "0" to
"r".
  This results in less register pressure.  Moreover, no scratch register is
  required in that case.

o The deprecated "extzv" pattern is replaced by "extzv" that allows
  inputs of scalar integer modes of different sizes (1 up to 4 bytes).

o Existing patterns are adjusted to the more generic "extzv" pattern.
  Some patterns are added as the middle-end has been reworked to spot
  more bit-extraction opportunities.

o A C function is used to print the asm for bit extractions, which is more
  convenient for complex output logic.

The generated code is still not optimal because RTL optimizers might still
prefer arithmetic like shift over bit-extractions.  For test cases see
also PR36884 and PR55181.

gcc/
PR target/109907
* config/avr/avr.md (adjust_len) [extr, extr_not]: New elements.
(MSB, SIZE): New mode attributes.
(any_shift): New code iterator.
(*lshr3_split, *lshr3, lshr3)
(*lshr3_const_split): Add constraint alternative for
the case of shift-offset = MSB.  Ditch "length" attribute.
(extzv, *extzv..subreg, *extzv.xor)
(*extzv.ge, *neg.ashiftrt.msb, *extzv.io.lsr7): New.
* config/avr/constraints.md (C15, C23, C31, Yil): New
* config/avr/predicates.md (reg_or_low_io_operand)
(const7_operand, reg_or_low_io_operand)
(const15_operand, const_0_to_15_operand)
(const23_operand, const_0_to_23_operand)
(const31_operand, const_0_to_31_operand): New.
* config/avr/avr-protos.h (avr_out_extr, avr_out_extr_not): New.
* config/avr/avr.cc (avr_out_extr, avr_out_extr_not): New funcs.
(lshrqi3_out, lshrhi3_out, lshrpsi3_out, lshrsi3_out): Adjust
MSB case to new insn constraint "r" for operands[1].
(avr_adjust_insn_length) [ADJUST_LEN_EXTR_NOT, ADJUST_LEN_EXTR]:
Handle these cases.
(avr_rtx_costs_1): Adjust cost for a new pattern.
gcc/testsuite/
PR target/109907
* gcc.target/avr/pr109907.c: New test.
* gcc.target/avr/torture/pr109907-1.c: New test.
* gcc.target/avr/torture/pr109907-2.c: New test.

[Bug middle-end/109907] Missed optimization for bit extraction (uses shift instead of single bit-test)

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #31 from Georg-Johann Lay  ---
Fixed in v14 for now.

The backend does all it can do.  Non-optimal code is usually due to middleend
and RTL optimizers coming up with sub-optimal expansions.

[Bug target/109456] `-ffixed` is ignored for `a` registers on RISC-V.

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

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

--- Comment #9 from Xi Ruoyao  ---
The easiest way is considering it a documentation issue and do:

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 0870f7aff93..c39880349d5 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -18635,8 +18635,8 @@ more efficient than other code generation strategies.
 @opindex ffixed
 @item -ffixed-@var{reg}
 Treat the register named @var{reg} as a fixed register; generated code
-should never refer to it (except perhaps as a stack pointer, frame
-pointer or in some other fixed role).
+should never refer to it (except as a stack pointer, frame
+pointer, argument register or in some other fixed role).

 @var{reg} must be the name of a register.  The register names accepted
 are machine-specific and are defined in the @code{REGISTER_NAMES}

[Bug target/109456] `-ffixed` is ignored for `a` registers on RISC-V.

[schwab--- via Gcc-bugs]

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

--- Comment #10 from Andreas Schwab  ---
Or "other ABI-mandated fixed roles".  This also includes return value
registers.

[Bug target/110206] New: [14 Regression] wrong code with -Os -march=cascadelake

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 110206
   Summary: [14 Regression] wrong code with -Os -march=cascadelake
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 55301
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55301&action=edit
reduced testcase

Output:
$ x86_64-pc-linux-gnu-gcc -Os -march=cascadelake testcase.c
$ sde64 -future -- ./a.out 
Aborted

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-1694-2023062131-g20643513b8d-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-1694-2023062131-g20643513b8d-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20230611 (experimental) (GCC)

[Bug c/110207] New: problems of fseek and fsetpos

[irip at qq dot com via Gcc-bugs]

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

Bug ID: 110207
   Summary: problems of fseek and fsetpos
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: irip at qq dot com
  Target Milestone: ---

when I test function fseek/fsetpos using the following C language statement：
   rstat = fseek(fp, 0L, SEEK_SET);or
   retstat = fsetpos(fp, &pos)
 It always return zero. 

Test program running on PowerPC 7447.

[Bug c/110208] New: problem with fscanf

[irip at qq dot com via Gcc-bugs]

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

Bug ID: 110208
   Summary: problem with fscanf
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: irip at qq dot com
  Target Milestone: ---

When using the fscanf function in code to handle certain formatting characters,
such as:

%L closely follows e, E, f, F, g, G

%*[

%N or similar  %10n

The input value obtained after execution is incorrect.

[Bug c/110209] New: problem with strtod strtof strtold

[irip at qq dot com via Gcc-bugs]

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

Bug ID: 110209
   Summary: problem with strtod strtof strtold
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: irip at qq dot com
  Target Milestone: ---

When using strtod, strtof, and strtold functions in code to convert values that
exceed the representation range,

The error number after execution is incorrect, and the error message is:

Got 37 Expected 38 Errno return.


Requirements for this Class function in Standard C: if the correct value
exceeds the range of representation, it is necessary to add/subtract the value
(corresponding to the sign bit) HUGE_ VAL, HUGE_ VALF or HUGE_ After VALL,
return and save the value of macro ERANGE in errno.

During testing, it was found that the errno returned was not the ERANGE value,
and the ERANGE value in the error message was not a common 34, but 38

[Bug c/110210] New: problem with strtol strtoll strtoul strtoull

[irip at qq dot com via Gcc-bugs]

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

Bug ID: 110210
   Summary: problem with strtol strtoll strtoul strtoull
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: irip at qq dot com
  Target Milestone: ---

When using strtol, strtoll, strtoul, and strtoull functions in code to convert
values that exceed the representation range,

Incorrect error number after execution

The requirement of C standard for this Class function: if the correct value
exceeds the representation range, LONG_ MIN, LONG_ MAX, LLONG_ MIN, LLONG_ MAX,
ULONG_ MAX or ULLONG_ MAX (corresponding symbol bit) will be used as the return
value, and the value of macro ERANGE will be stored in errno.

During testing, it was found that the returned errno was not an ERANGE value

[Bug c++/110122] [13/14 Regression] using an aggregate with a member variable with a user defined copy constructor in a class NTTP causes capture and use of the `this` pointer in a generic lambda to p

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:682d401a6ba723b2bf98779d056efc8ff2640178

commit r14-1697-g682d401a6ba723b2bf98779d056efc8ff2640178
Author: Patrick Palka 
Date:   Sun Jun 11 11:09:16 2023 -0400

c++: extend lookup_template_class shortcut [PR110122]

Here when substituting the injected class name A during regeneration of
the lambda, we find ourselves in lookup_template_class for A with
V=_ZTAXtl3BarEE (i.e. the template parameter object for Foo{}).  The call
to coerce_template_parms within then undesirably tries to make a copy of
this class NTTP argument, which fails because Foo is not copyable.  But it
seems clear that this testcase shouldn't require copyability of Foo.

lookup_template_class has a shortcut for looking up the current class
scope, which would avoid the problematic coerce_template_parms call, but
the shortcut doesn't trigger because it only considers the innermost
class scope which in this case in the lambda type.  So this patch fixes
this by extending the lookup_template_class shortcut to consider outer
class scopes too (and skipping over lambda types since they are never
specialized from lookup_template_class).  We also need to avoid calling
coerce_template_parms when specializing a templated non-template nested
class for the first time (such as A::B in the testcase).  Coercion should
be unnecessary there because the innermost arguments belong to the context
and so should have already been coerced.

PR c++/110122

gcc/cp/ChangeLog:

* pt.cc (lookup_template_class): Extend shortcut for looking up the
current class scope to consider outer class scopes too, and use
current_nonlambda_class_type instead of current_class_type.  Only
call coerce_template_parms when specializing a primary template.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/nontype-class57.C: New test.
* g++.dg/cpp2a/nontype-class58.C: New test.

[Bug c++/110122] [13/14 Regression] using an aggregate with a member variable with a user defined copy constructor in a class NTTP causes capture and use of the `this` pointer in a generic lambda to p

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:59946a4c0c97c842ac5a34de5b1aadb73b738809

commit r14-1698-g59946a4c0c97c842ac5a34de5b1aadb73b738809
Author: Patrick Palka 
Date:   Sun Jun 11 11:27:10 2023 -0400

c++: unsynthesized defaulted constexpr fn [PR110122]

In this other testcase from PR110122, during regeneration of the generic
lambda with V=Bar{}, substitution followed by coerce_template_parms for
A's template argument naturally yields a copy of V in terms of Bar's
(implicitly) defaulted copy constructor.

This however happens inside a template context so although we introduced
a use of the copy constructor, mark_used didn't actually synthesize it,
which causes subsequent constant evaluation of the template argument to
fail with:

  nontype-class59.C: In instantiation of âvoid f() [with Bar V =
Bar{Foo()}]â:
  nontype-class59.C:22:11:   required from here
  nontype-class59.C:18:18: error: âconstexpr Bar::Bar(const Bar&)â used
before its definition

We already make sure to instantiate templated constexpr functions needed
for constant evaluation (as per P0859R0).  So this patch fixes this by
making us synthesize defaulted constexpr functions needed for constant
evaluation as well.

PR c++/110122

gcc/cp/ChangeLog:

* constexpr.cc (cxx_eval_call_expression): Synthesize defaulted
functions needed for constant evaluation.
(instantiate_cx_fn_r): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/nontype-class59.C: New test.

[Bug c/110210] problem with strtol strtoll strtoul strtoull

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |MOVED
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
Gcc does not provide these functions. They are provided by the libc that gcc
links to.

In the case of Linux, it is most likely glibc but it could be musl or uclibc .

[Bug c/110209] problem with strtod strtof strtold

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #1 from Andrew Pinski  ---
Gcc does not provide these functions. They are provided by the libc that gcc
links to.

In the case of Linux, it is most likely glibc but it could be musl or uclibc .
If you are using a -elf target, then libc is most likely provided by newlib.


Also GCC 4.8.x is no longer supported upstream, you should try a much newer
GCC, like GCC 9.x or even better GCC 13.

[Bug c/110208] problem with fscanf

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #1 from Andrew Pinski  ---
Gcc does not provide these functions. They are provided by the libc that gcc
links to.

In the case of Linux, it is most likely glibc but it could be musl or uclibc .
If you are using a -elf target, then libc is most likely provided by newlib.


Also GCC 4.8.x is no longer supported upstream, you should try a much newer
GCC, like GCC 9.x or even better GCC 13.

[Bug c/110207] problems of fseek and fsetpos

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |MOVED
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
Gcc does not provide these functions. They are provided by the libc that gcc
links to.

In the case of Linux, it is most likely glibc but it could be musl or uclibc .
If you are using a -elf target, then libc is most likely provided by newlib.


Also GCC 4.8.x is no longer supported upstream, you should try a much newer
GCC, like GCC 9.x or even better GCC 13.

[Bug target/110206] [14 Regression] wrong code with -Os -march=cascadelake

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug c/110210] problem with strtol strtoll strtoul strtoull

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

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

--- Comment #2 from Andrew Pinski  ---
Gcc does not provide these functions. They are provided by the libc that gcc
links to.

In the case of Linux, it is most likely glibc but it could be musl or uclibc .
If you are using a -elf target, then libc is most likely provided by newlib.


Also GCC 4.8.x is no longer supported upstream, you should try a much newer
GCC, like GCC 9.x or even better GCC 13.

[Bug target/110206] [14 Regression] wrong code with -Os -march=cascadelake

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

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

--- Comment #1 from Andrew Pinski  ---
There is a difference at the gimple level even:
trunk:
  _3 = { 204, 204, 204, 204 } >> u_7(D);

GCC 13.1:
  _15 = BIT_FIELD_REF ;
  _16 = 204 >> _15;
  _17 = BIT_FIELD_REF ;
  _18 = 204 >> _17;
  _19 = BIT_FIELD_REF ;
  _20 = 204 >> _19;
  _21 = BIT_FIELD_REF ;
  _22 = 204 >> _21;
  _3 = {_16, _18, _20, _22};

[Bug c++/110211] New: Local lambda treated as non-local

[johelegp at gmail dot com via Gcc-bugs]

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

Bug ID: 110211
   Summary: Local lambda treated as non-local
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: c++-lambda, rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
  Target Milestone: ---

See .

```C++
template concept invocable = requires(F f, T x) { f(x); };
static_assert(!invocable<
  decltype([](T) -> decltype([&](U x)
requires requires { x.a();
}
  {}(T())) {}),
   int>);
```

```output
:3:52: error: non-local lambda expression cannot have a capture-default
3 |   decltype([](T) -> decltype([&](U x)
  |^
Compiler returned: 1
```

According to , this should
work.
If the `static_assert` is in a function, it still fails:
.
It fails on GCC10: .

[Bug c++/110211] Local lambda treated as non-local

[johelegp at gmail dot com via Gcc-bugs]

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

Johel Ernesto Guerrero Peña  changed:

   What|Removed |Added

  Known to fail||9.5.0

--- Comment #1 from Johel Ernesto Guerrero Peña  ---
Simplified:
- GCC 9.5 .
- GCC trunk .

```C++
int main() {
  [](auto x) -> decltype([&](auto) {}(x)) {}(0);
}
```

With this, MSVC fails.
Apparently, rather than a hard error, it fails OR.
That must be why it passed before.

[Bug d/110113] gdc -fpreview=dip1021 crash in d/dmd/root/aav.d:127 dmd_aaGetRvalue from DsymbolTable::lookup(Identifier const*)

[witold.baryluk+gcc at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Witold Baryluk  ---
Thank you Iain. Amazing debugging skills.

BTW. `import std;` was because dustmite reduced original import to just that.
Original import was `import std.math.algebraic : sqrt;`

But you already figured this out without even using Phobos.

[Bug target/110206] [14 Regression] wrong code with -Os -march=cascadelake since r14-1246

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[14 Regression] wrong code  |[14 Regression] wrong code
   |with -Os -march=cascadelake |with -Os -march=cascadelake
   ||since r14-1246
 Status|UNCONFIRMED |NEW
 CC||jakub at gcc dot gnu.org
   Last reconfirmed||2023-06-11
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Started with r14-1246-g52ff3f7b863da1011b

[Bug tree-optimization/95923] Failure to optimize bool checks into and

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

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

--- Comment #3 from Andrew Pinski  ---
After r14-1597-g64d90d06d2db, we now have:
  _8 = a_6(D) | b_7(D);
  _10 = a_6(D) == b_7(D);
  _1 = _8 & _10;

(a == b) & (a | b)

I am no longer working on this right now. That is a job for reassociate I
think.

Note I noticed that we don't remove some "dead" statements during phiopt3 too:
```
  if (_8 != 0)
goto ; [66.00%]
  else
goto ; [34.00%]

   [local count: 708669601]:
  _1 = ~a_6(D);
  _2 = _1 & b_7(D);
  _10 = a_6(D) == b_7(D);

   [local count: 1073741824]:
  # _5 = PHI <_10(3), 0(2)>
```

I will fix that before unassigning. The problem there is:
We had:
  _1 = ~a_6(D);
  _2 = _1 & b_7(D);
  if (_2 != 0)

But we don't mark _2 as possible unused even though match will produce without
it:
Folded into the sequence:
_3 = ~b_7(D);
_4 = _3 | a_6(D);
_11 = a_6(D) ^ b_7(D);
_10 = a_6(D) == b_7(D);
statement un-sinked:
_12 = _1 | b_7(D);

[Bug tree-optimization/96237] Failure to recognize and pattern composed of and+or after shift

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> I am going to implement the match patterns needed.

This is just expanding:
/* (zero_one != 0) ? z  y : y -> ((typeof(y))zero_one * z)  y */

Patterns not to just zero_one but rather integer_power2 which I am going to do
the week after next.

[Bug tree-optimization/41244] "&data[i] - data" isn't converted to "i"

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

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

--- Comment #8 from Andrew Pinski  ---

  _14 = _13 * 32;
  _15 = (long int) _14;
  _2 = _15 /[ex] 32;

I think this will work 
(simplify
 (exact_div (nop_convert (mult @0 INTEGER_CST@1)) INTEGER_CST@2)
 (if (!TYPE_UNSIGNED (@0)
  && wi::to_wide (@1) == wi::to_wide (@2))
  (convert @0)))

[Bug c++/110212] New: ICE on invalid: template constraint failure

[stevenxia990430 at gmail dot com via Gcc-bugs]

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

Bug ID: 110212
   Summary: ICE on invalid: template constraint failure
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stevenxia990430 at gmail dot com
  Target Milestone: ---

The following invalid program produces internal compiler error: error reporting
routines re-entered (related to template constraints). Tested on GCC-trunk.
Apologies that it might be complex, had a difficult time trying to reduce this.

To quickly reproduce: https://gcc.godbolt.org/z/7hxdx6Y6Y
```
#include 
#include 
#include 

template
struct foo() <<
std::declval().size())>> : std::true_type {};

template::value>* = nullptr>
auto print_elements(T const& t) -> decltype(std::declval() <<
std::declval().size(), void())
{
std::cout << t;
}

int main()
{
std::array a{ 2, 0, 5, 66, 4, 90, 25, 54, 23, 1 };
print_elements(a);
}
```

Note: requires -std=c++20 and above.

[Bug c++/110212] ICE on invalid: template constraint failure

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

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

--- Comment #1 from Andrew Pinski  ---
There is a dup of this bug.

[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays

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

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

--- Comment #20 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #18)
> Created attachment 55300 [details]
> Alternative patch v2

This patch fails for me on several occasions including the testsuite.
I guess the logic was intended as follows:

diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index e1c75e9fe02..ebadda20004 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -1117,7 +1117,7 @@ gfc_trans_allocate_array_storage (stmtblock_t * pre,
stmtblock_t * post,

   desc = info->descriptor;
   info->offset = gfc_index_zero_node;
-  if (size == NULL_TREE || integer_zerop (size))
+  if (size == NULL_TREE)
 {
   /* A callee allocated array.  */
   gfc_conv_descriptor_data_set (pre, desc, null_pointer_node);
@@ -1129,6 +1129,7 @@ gfc_trans_allocate_array_storage (stmtblock_t * pre,
stmtblock_t * post,
   onstack = !dynamic && initial == NULL_TREE
 && (flag_stack_arrays
 || gfc_can_put_var_on_stack (size));
+  onstack = onstack && !integer_zerop (size);

   if (onstack)
{


This seems to work on the present cases and regtests almost cleanly, with
the only exception being gfortran.dg/pr69955.f90, which needs an adjustment
of the scan-tree-dump pattern due to an additional __builtin_malloc.

I am beginning to think that there are multiple issues exhibited here: a
wrong-code issue, which is fixed by the above, and a missed-optimization,
which I tried to address with my initial patch.

If the above patch turns out to fix the wrong-code issue safely, I would
like to prepare it for mainline, and if it survives there for some time,
consider a backport to 13-branch in time for 13.2 release.

The missed optimization with superfluous temporaries could then be split
off to a separate PR and addressed only for future (14+) branches.

I'll prepare additional testcases for character and type and see if the above
patch is sufficient.

[Bug tree-optimization/41244] "&data[i] - data" isn't converted to "i"

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

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

--- Comment #9 from Andrew Pinski  ---
Created attachment 55302
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55302&action=edit
Patch which I will be testing

This extends the pattern that already handles `(t * 2) / 2) -> t`.

The one thing which I need to double check and understand if :c can/should be
used here, or should use another with here.

[Bug target/110188] gcc for RISC-V stack aligned error

[jzhgonha at 163 dot com via Gcc-bugs]

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

--- Comment #6 from jzhgonha at 163 dot com ---
   thank you very much!

   发自我的小米在 "kito at gcc dot gnu.org" ，2023年6月9日
   下午9:51写道：

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

 Kito Cheng  changed:

 What |Removed |Added


 CC| |kito at gcc dot gnu.org[1]

 --- Comment #5 from Kito Cheng  ---
 Each stack area will align to 16 byte, that could be optimized in
 theory, but
 will complicate the frame layout implementation.

 sp - 0
 a9 / outgoing stack arguments area
 sp - 4
  / outgoing stack arguments area
 sp - 8
  / outgoing stack arguments area
 sp - 12
  / outgoing stack arguments area
 sp - 16
  / GPR save area
 sp - 20
  / GPR save area
 sp - 24
  / GPR save area
 sp - 28
 ra / GPR save area
 sp - 32



 Complete layout has document in riscv.cc[2]:

 +---+
 | |
 | incoming stack arguments |
 | |
 +---+ <-- incoming stack pointer
 | |
 | callee-allocated save area |
 | for arguments that are |
 | split between registers and |
 | the stack |
 | |
 +---+ <-- arg_pointer_rtx
 | |
 | callee-allocated save area |
 | for register varargs |
 | |
 +---+ <-- hard_frame_pointer_rtx;
 | | stack_pointer_rtx + gp_sp_offset
 | GPR save area | + UNITS_PER_WORD
 | |
 +---+ <-- stack_pointer_rtx +
 fp_sp_offset
 | | + UNITS_PER_HWVALUE
 | FPR save area |
 | |
 +---+ <-- frame_pointer_rtx (virtual)
 | |
 | local variables |
 | |
 P +---+
 | |
 | outgoing stack arguments |
 | |
 +---+ <-- stack_pointer_rtx

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



   1. http://gnu.org
   2. http://riscv.cc

[Bug tree-optimization/41244] "&data[i] - data" isn't converted to "i"

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

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

--- Comment #10 from Andrew Pinski  ---
Created attachment 55303
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55303&action=edit
Better patch

This is a better patch, operand_equal_p already does the integer cst check too.

[Bug tree-optimization/41244] "&data[i] - data" isn't converted to "i"

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

--- Comment #11 from Andrew Pinski  ---
You know what, both patches are wrong with respect to the overflow check. 
Anyways Someone else can fix this.

[Bug tree-optimization/41244] "&data[i] - data" isn't converted to "i"

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

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

--- Comment #12 from Andrew Pinski  ---
So basically the biggest issue is we do the sign extend and then do the
multiply in an unsigned type; this causes all negative values causing a
wrapping which is not correct really but we don't know any better. I tried to
change pass_laddress::execute to do the multiply in a signed type but that
still is not able to optimize find in comment #6 to work and the IR is so much
more complex.

[Bug target/110170] Sub-optimal conditional jumps in conditional-swap with floating point

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Hongtao.liu  ---
ix86_expand_sse_fp_minmax failed since rtx_equal_p (cmp_op0, if_true) is false, 

249(reg:DF 86 [ _1 ])  (if_true)
250(reg:DF 83 [ _2 ])  (if_false)
251(reg:DF 82 [ _1 ])  (cmp0_op0)
252(reg:DF 83 [ _2 ])  (cmp1_op1)

but here if_true is just a copy from cmp_op0 but with different REGNO,
rtx_equal_p seems too conservative here.

 85(code_label 26 13 17 3 4 (nil) [1 uses])
 86(note 17 26 5 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
 87(insn 5 17 6 3 (set (reg:DF 86 [ _1 ])
 88(reg:DF 82 [ _1 ])) "test.C":3:20 153 {*movdf_internal}
 89 (expr_list:REG_DEAD (reg:DF 82 [ _1 ])
 90(nil)))
 91(insn 6 5 7 3 (set (reg:DF 82 [ _1 ])
 92(reg:DF 83 [ _2 ])) "test.C":4:14 discrim 1 153 {*movdf_internal}
 93 (expr_list:REG_DEAD (reg:DF 83 [ _2 ])
 94(nil)))
 95(insn 7 6 18 3 (set (reg:DF 83 [ _2 ])
 96(reg:DF 86 [ _1 ])) "test.C":3:20 discrim 1 153 {*movdf_internal}
 97 (expr_list:REG_DEAD (reg:DF 86 [ _1 ])
 98(nil)))


3812  if (rtx_equal_p (cmp_op0, if_true) && rtx_equal_p (cmp_op1, if_false))
 3813is_min = true;
 3814  else if (rtx_equal_p (cmp_op1, if_true) && rtx_equal_p (cmp_op0,
if_false))
 3815is_min = false;
 3816  else
 3817=>  return false;

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[boris at kolpackov dot net via Gcc-bugs]

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

Boris Kolpackov  changed:

   What|Removed |Added

 CC||boris at kolpackov dot net

--- Comment #34 from Boris Kolpackov  ---
Would like to echo other's comments: getting a large number false positives in
our codebase (build2). Thankfully this warning seems to only be enabled with
-Wextra and not with -Wall as stated in #106393.

[Bug c++/110213] New: Bogus (as opposed to false positive) -Wdangling-reference warning

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 110213
   Summary: Bogus (as opposed to false positive)
-Wdangling-reference warning
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

I have a call that, AFAICS, doesn't involve any binding of references to
temporaries but which nevertheless still produces this warning. The code boils
down to the following:

const target& search (const target&, name);

void pattern::apply(target& t) const
{
  name n = ...;
  const target& p (search (t, std::move (n))); // <- Warning points here.
}

However, I was not able to reduce it to a small reproducer so it seems to
depend on the overall context. So I am attaching a partially preprocessed TU.
To reproduce, run:

$ g++ -std=c++23 -Wall -Wextra -fdirectives-only -c adhoc-rule-regex-pattern.ii

adhoc-rule-regex-pattern.cxx: In member function ‘virtual void
build2::adhoc_rule_regex_pattern::apply_prerequisites(build2::action,
build2::target&, const scope&, build2::match_extra&) const’:
adhoc-rule-regex-pattern.cxx:485:21: warning: possibly dangling reference to a
temporary [-Wdangling-reference]
  485 |   const target& pt (search (t, move (n), *s, &e.type));
  | ^~
adhoc-rule-regex-pattern.cxx:485:32: note: the temporary was destroyed at the
end of the full expression 
‘build2::search((*(const build2::target*)(& t)), build2::name((* &
std::move(n))), (* s), (&
e.build2::adhoc_rule_regex_pattern::element::type))’
  485 |   const target& pt (search (t, move (n), *s, &e.type));
  | ~~~^~

The last two arguments (*s, &e.type) in the call do not make any difference.
Changing the search() function to take name by const& or && makes the warning
disappear.

$ g++ --version
g++-13 (Debian 13.1.0-3) 13.1.0

[Bug c++/110213] Bogus (as opposed to false positive) -Wdangling-reference warning

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #1 from Boris Kolpackov  ---
Created attachment 55304
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55304&action=edit
reproducer

[Bug c++/110213] Bogus (as opposed to false positive) -Wdangling-reference warning

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

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

--- Comment #2 from Andrew Pinski  ---
Reduced testcase:
#include 
struct f
{
  f(const f&);
  f();
};

struct g{};

g &search(f);

void h()
{
f n;
const g& pt (search (std::move(n)));
}

[Bug c++/110213] Bogus (as opposed to false positive) -Wdangling-reference warning

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

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

--- Comment #3 from Andrew Pinski  ---
I don't see an issue with this warning really as there is a temporary being
created for the argument of type name and that is what the issue is warning
about. the argument of type name is still passed via reference even and the
temp is created on caller side as needed by the C++ standard even.

There are other bugs dealing Wdangling-reference where they have false positive
warnings dealing with different types of being warned about.

[Bug tree-optimization/109371] MIN_EXPR/MAX_EXPR is not documented and SMIN/SMAX trapping behavior is not documented

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #1 from Hongtao.liu  ---
NOTE for ieee-2019, there're extra 8 new floating point min/max functions

-cut from ieee 2019 9.6 Minimum and maximum operations--
SourceFormat minimum(source, source)
sourceFormat minimumNumber(source, source)
sourceFormat maximum(source, source)
sourceFormat maximumNumber(source, source)
minimum(x, y) is x if x  y, y if y >x, and a quiet NaN if either operand is a
NaN, according to 6.2.
For this operation, +0 compares greater than −0. Otherwise (i.e., when x= y and
signs are the
same) it is either x or y.
maximumNumber(x, y) is x if x >y, y if y >x, and the number if one operand is a
number and the
other is a NaN. For this operation, +0 compares greater than −0. If x =y and
signs are the same it
is either x or y. If both operands are NaNs, a quiet NaN is returned, according
to 6.2. If either
operand is a signaling NaN, an invalid operation exception is signaled, but
unless both operands
are NaNs, the signaling NaN is otherwise ignored and not converted to a quiet
NaN as stated in
6.2 for other operations.
69
Copyright © 2019 IEEE. All rights reserved.
Authorized licensed use limited to: Intel Corporation via the Virtual Library.
Downloaded on January 04,2023 at 06:43:47 UTC from IEEE Xplore. Restrictions
apply.IEEE Std 754-2019
IEEE Standard for Floating-Point Arithmetic
― sourceFormat minimumMagnitude(source, source)
sourceFormat minimumMagnitudeNumber(source, source)
sourceFormat maximumMagnitude(source, source)
sourceFormat maximumMagnitudeNumber(source, source)
minimumMagnitude(x, y) is x if |x|< |y|, y if |y|< |x|, otherwise minimum(x,
y).
minimumMagnitudeNumber(x, y) is x if |x|< |y|, y if |y|< |x|, otherwise
minimumNumber(x, y).
maximumMagnitude(x, y) is x if |x|> |y|, y if |y|> |x|, otherwise maximum(x,
y).
maximumMagnitudeNumber(x,y) is x if | x| >| y|, y if | y| >| x|, otherwise
maximumNumber(x, y).
The preferred exponent is Q(x) if x is the result, Q(y) if y is the result.
NOTE—The quantum of the result might differ among implementations when x and y
are
different representations of the same cohort in decimal floating-point numbers. 
--cut ends--

Should we also support new IRs for them, libc has supported all of them.
https://sourceware.org/pipermail/libc-alpha/2021-September/131511.html

[Bug middle-end/108410] x264 averaging loop not optimized well for avx512

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Hongtao.liu  ---

> and the key thing to optimize is
> 
>   ivtmp_78 = ivtmp_77 + 4294967232; // -64
>   _79 = MIN_EXPR ;
>   _80 = (unsigned char) _79;
>   _81 = {_80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80,
> _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80,
> _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80,
> _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80,
> _80, _80, _80, _80, _80, _80};
> 
> that is we want to broadcast a saturated (to vector element precision) value.

Yes, backend needs to support vec_pack_ssat_m, vec_pack_usat_m.
But I didn't find optab for ss_truncate or us_truncate which might be used by
BB vectorizer.

[Bug target/110214] New: x86 backend lacks support for vec_pack_ssat_m and vec_pack_usat_m

[crazylht at gmail dot com via Gcc-bugs]

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

Bug ID: 110214
   Summary: x86 backend lacks support for vec_pack_ssat_m and
vec_pack_usat_m
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
  Target Milestone: ---

This is from PR108410:

> and the key thing to optimize is
> 
>   ivtmp_78 = ivtmp_77 + 4294967232; // -64
>   _79 = MIN_EXPR ;
>   _80 = (unsigned char) _79;
>   _81 = {_80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80,
> _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80,
> _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80,
> _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80, _80,
> _80, _80, _80, _80, _80, _80};
> 
> that is we want to broadcast a saturated (to vector element precision) value.


Yes, backend needs to support vec_pack_ssat_m, vec_pack_usat_m.
But I didn't find optab for ss_truncate or us_truncate which might be used by
BB vectorizer.

AVX512 support vpmov{u,}sqd, vpmov{u,}sdw, vpmov{u,}swb for demotion with
signed/unsigned saturation.

[Bug target/110146] ICE in riscv_vector::function_builder::add_unique_function()

[pan2.li at intel dot com via Gcc-bugs]

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

Li Pan  changed:

   What|Removed |Added

 CC||pan2.li at intel dot com

--- Comment #1 from Li Pan  ---
Hi Palmer,

It should be fixed already as I understand on June 06, give or take. Do you
still meet such issues from the upstream?

[Bug target/110011] -mfull-toc (-mfp-in-toc) yields incorrect _Float128 constants on power9

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Kewen Lin :

https://gcc.gnu.org/g:388809f2afde874180da0669c669e241037eeba0

commit r14-1703-g388809f2afde874180da0669c669e241037eeba0
Author: Kewen Lin 
Date:   Mon Jun 12 01:07:52 2023 -0500

rs6000: Don't use TFmode for 128 bits fp constant in toc [PR110011]

As PR110011 shows, when encoding 128 bits fp constant into
toc, we adopts REAL_VALUE_TO_TARGET_LONG_DOUBLE which is
to find the first float mode with LONG_DOUBLE_TYPE_SIZE
bits of precision, it would be TFmode here.  But the 128
bits fp constant can be with mode IFmode or KFmode, which
doesn't necessarily have the same underlying float format
as the one of TFmode, like this PR exposes, with option
-mabi=ibmlongdouble TFmode has ibm_extended_format while
KFmode has ieee_quad_format, mixing up the formats (the
encoding/decoding ways) would cause unexpected results.

This patch is to make it use constant's own mode instead
of TFmode for real_to_target call.

PR target/110011

gcc/ChangeLog:

* config/rs6000/rs6000.cc (output_toc): Use the mode of the 128-bit
floating constant itself for real_to_target call.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/pr110011.c: New test.

[Bug target/109932] ICE in in extract_insn, at recog.cc:2791 on ppc64le with -mno-vsx

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Kewen Lin :

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

commit r14-1704-gff83d1b47aadcdaf80a4fda84b0dc00bb2cd3641
Author: Kewen Lin 
Date:   Mon Jun 12 01:08:22 2023 -0500

rs6000: Guard __builtin_{un,}pack_vector_int128 with vsx [PR109932]

As PR109932 shows, builtins __builtin_{un,}pack_vector_int128
should be guarded under vsx rather than power7, as their
corresponding bif patterns have the conditions TARGET_VSX
and VECTOR_MEM_ALTIVEC_OR_VSX_P (V1TImode).  This patch is to
move __builtin_{un,}pack_vector_int128 to stanza vsx to ensure
their supports.

PR target/109932

gcc/ChangeLog:

* config/rs6000/rs6000-builtins.def (__builtin_pack_vector_int128,
__builtin_unpack_vector_int128): Move from stanza power7 to vsx.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/pr109932-1.c: New test.
* gcc.target/powerpc/pr109932-2.c: New test.

[Bug rtl-optimization/110215] New: RA fails to allocate register when loop invariant lives through EH region

[wwwhhhyyy333 at gmail dot com via Gcc-bugs]

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

Bug ID: 110215
   Summary: RA fails to allocate register when loop invariant
lives through EH region
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wwwhhhyyy333 at gmail dot com
  Target Milestone: ---

Created attachment 55305
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55305&action=edit
A Testcase

Compiled with -Ofast, The innermost loop is

.L41:
movups  (%rax), %xmm3
movaps  (%rsp), %xmm0
addq$16, %rax
subps   %xmm3, %xmm0
andps   %xmm2, %xmm0
movups  %xmm0, -16(%rax)
addps   %xmm0, %xmm1
cmpq%rax, %rdx
jne .L41

While for Clang it produces

.LBB0_14:   #   Parent Loop BB0_3 Depth=1
movups  (%rbp,%rax), %xmm1
movaps  %xmm3, %xmm2
subps   %xmm1, %xmm2
andps   %xmm4, %xmm2
movups  %xmm2, (%rbp,%rax)
addps   %xmm2, %xmm0
addq$16, %rax
cmpq%rax, %r12
jne .LBB0_14

The loop invariant `base` was spilled to stack in GCC, but for clang it can
directly use a sse register.

Godbolt: https://godbolt.org/z/TTvG8M6E8

[Bug rtl-optimization/110215] RA fails to allocate register when loop invariant lives across calls

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|RA fails to allocate|RA fails to allocate
   |register when loop  |register when loop
   |invariant lives through EH  |invariant lives across
   |region  |calls
   Keywords|ra  |

--- Comment #1 from Andrew Pinski  ---
happens on aarch64 also:
```
.L41:
ldr q31, [x0]
ldr q29, [sp, 112]
fabdv31.4s, v29.4s, v31.4s
faddv30.4s, v30.4s, v31.4s
str q31, [x0], 16
cmp x1, x0
bne .L41
```


Gimple level looks like:
   [local count: 372044713]:
  # vect_sum_lsm.128_11.134_88 = PHI 
  # ivtmp.155_176 = PHI 
  _173 = (void *) ivtmp.155_176;
  vect__4.137_85 = MEM  [(value_type &)_173];
  vect__5.138_74 = vect_cst__84 - vect__4.137_85;
  vect__38.139_68 = ABS_EXPR ;
  MEM  [(value_type &)_173] = vect__38.139_68;
  vect__7.142_39 = vect__38.139_68 + vect_sum_lsm.128_11.134_88;
  ivtmp.155_175 = ivtmp.155_176 + 16;
  if (_6 != ivtmp.155_175)
goto ; [83.33%]
  else
goto ; [16.67%]

That would be vect_cst__84 .

So what I think is happening is the spilling is happening is not related at all
to EH but rather a call.

[Bug rtl-optimization/110215] RA fails to allocate register when loop invariant lives across calls and eh

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Summary|RA fails to allocate|RA fails to allocate
   |register when loop  |register when loop
   |invariant lives across  |invariant lives across
   |calls   |calls and eh
 Ever confirmed|0   |1
   Keywords||ra
   Last reconfirmed||2023-06-12

--- Comment #2 from Andrew Pinski  ---
Reduced testcase for both x86_64 and aarch64:
```
#define vec __attribute__((vector_size(4*sizeof(float
struct s1
{
 s1();
 ~s1();
};
void g();
void g(float);
void f(float a, float b, vec float **c, int n, int j)
{
s1 t2;
float t = a/b;
vec float d = {t, t, t, t};
for (int l = 0; l < j; l++)
{
vec float s = {};
for(int i =0;i