[Bug c++/113038] [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||testsuite-fail
   Target Milestone|--- |14.0

[Bug target/113039] [14 Regression] -fcf-protection -fcf-protection=branch doesn't work

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/113040] [14 Regression] libmvec test failures

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection
 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Can you produce a standalone testcase?

[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||arm

--- Comment #13 from Richard Biener  ---
Yeah, I think that's an artifact of using valgrind.  But I can't see how
valgrind could be fixed here apart from trying to special-case a bigger
instruction pattern.

[Bug target/113048] [13/14 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1862 (unable to find a register to spill) {*andndi3_doubleword_bmi} with -march=cascadelake

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2023-12-18
   Target Milestone|--- |13.3
   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Keywords||ra
 Ever confirmed|0   |1
  Known to work||12.3.1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug rust/113056] [14 regression] Build failure in libgrust

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug middle-end/113058] New: [meta-bug] RTL frontend issues

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

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

Bug ID: 113058
   Summary: [meta-bug] RTL frontend issues
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

[Bug tree-optimization/113013] [12/13/14 regression] ICE in fold_convert_loc with -fsanitize=undefined

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:5347263b347d02e875879ca40ca6e289ac178919

commit r14-6654-g5347263b347d02e875879ca40ca6e289ac178919
Author: Jakub Jelinek 
Date:   Mon Dec 18 09:59:28 2023 +0100

tree-object-size: Robustify alloc_size attribute handling [PR113013]

The following testcase ICEs because we aren't careful enough with
alloc_size attribute.  We do check that such an argument exists
(although wouldn't handle correctly functions with more than INT_MAX
arguments), but didn't check that it is scalar integer, the ICE is
trying to fold_convert a structure to sizetype.

Given that the attribute can also appear on non-prototyped functions
where the arguments aren't known, I don't see how the FE could diagnose
that and because we already handle the case where argument doesn't exist,
I think we should also verify the argument is scalar integer convertible
to sizetype.  Furthermore, given this is not just in diagnostics but
used for code generation, I think it is better to punt on arguments with
larger precision then sizetype, the upper bits are then truncated.

The patch also fixes some formatting issues and avoids duplication of the
fold_convert, plus removes unnecessary check for if (arg1 >= 0), that is
always the case after if (arg1 < 0) return ...;

2023-12-18  Jakub Jelinek  

PR tree-optimization/113013
* tree-object-size.cc (alloc_object_size): Return size_unknown if
corresponding argument(s) don't have integral type or have integral
type with higher precision than sizetype.  Don't check arg1 >= 0
uselessly.  Compare argument indexes against gimple_call_num_args
in unsigned type rather than int.  Formatting fixes.

* gcc.dg/pr113013.c: New test.

[Bug target/113059] New: [14 regression] fftw fails tests for -O3 -m32 -march=znver2 since r14-6210-ge44ed92dbbe9d4

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

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

Bug ID: 113059
   Summary: [14 regression] fftw fails tests for -O3 -m32
-march=znver2 since r14-6210-ge44ed92dbbe9d4
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

fftw started failing tests (very inconsistently - almost always fails, but
sometimes w/ segfault, sometimes with wrong results) since
r14-6210-ge44ed92dbbe9d4.

Might be a continuation of PR112572. We had pinskia's workaround patch applied
until r14-6210-ge44ed92dbbe9d4 landed so I may need to double check.

I can reproduce with the following:
```
./configure CFLAGS="-O3 -m32 -march=znver2 -ggdb3"
make -j$(nproc)
make -j$(nproc) check
```

Just `tests/bench --verbose=1 --verify //obrd896` seems to be a good crasher
for me.

```
Program received signal SIGSEGV, Segmentation fault.
r2cf_32 (R0=0x97c0, R1=0x98d0, Cr=0x97c0, Ci=,
rs=, csr=0x56690040, csi=0x0, v=, ivs=1, ovs=1)
at r2cf_32.c:490
490 Ci[WS(csi, 8)] = T29 - T28;
(gdb) bt
#0  r2cf_32 (R0=0x97c0, R1=0x98d0, Cr=0x97c0, Ci=,
rs=, csr=0x56690040, csi=0x0, v=, ivs=1, ovs=1)
at r2cf_32.c:490
#1  0x56632963 in dobatch_r2hc (ego=0x566916b0, I=0x56680e80, O=0x56680e80,
buf=0x97c0, batchsz=1) at direct-r2c.c:91
#2  0x56632a5d in iterate (ego=0x566916b0, I=, O=, dobatch=0x56632880 ) at direct-r2c.c:142
#3  0x565a09f5 in fftw_rdft_solve (ego_=0x566916b0, p_=0x566921d0) at
solve.c:29
#4  0x565603eb in measure (iter=1, p=, pln=) at
timer.c:136
#5  fftw_measure_execution_time (plnr=0x56684690, pln=0x566916b0, p=0x566921d0)
at timer.c:159
#6  0x5655d853 in evaluate_plan (ego=ego@entry=0x56684690,
pln=pln@entry=0x566916b0, p=p@entry=0x566921d0) at planner.c:460
#7  0x5655e773 in search0 (ego=ego@entry=0x56684690, p=p@entry=0x566921d0,
slvndx=slvndx@entry=0xbbac, flagsp=) at planner.c:529
#8  0x5655eb37 in search (flagsp=0xbbb0, slvndx=0xbbac, p=0x566921d0,
ego=0x56684690) at planner.c:600
#9  mkplan (ego=, p=) at planner.c:711
[...]
```

Reducing is challenging so far, as FFTW is massive. I'm not going to waste much
more time on that, but I'll do the usual bisecting object files and such now.

[Bug tree-optimization/113013] [12/13/14 regression] ICE in fold_convert_loc with -fsanitize=undefined

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

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

--- Comment #8 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:2ea5a22b3e594cdf88e916b3df774883ce9dbc3a

commit r13-8165-g2ea5a22b3e594cdf88e916b3df774883ce9dbc3a
Author: Jakub Jelinek 
Date:   Mon Dec 18 09:59:28 2023 +0100

tree-object-size: Robustify alloc_size attribute handling [PR113013]

The following testcase ICEs because we aren't careful enough with
alloc_size attribute.  We do check that such an argument exists
(although wouldn't handle correctly functions with more than INT_MAX
arguments), but didn't check that it is scalar integer, the ICE is
trying to fold_convert a structure to sizetype.

Given that the attribute can also appear on non-prototyped functions
where the arguments aren't known, I don't see how the FE could diagnose
that and because we already handle the case where argument doesn't exist,
I think we should also verify the argument is scalar integer convertible
to sizetype.  Furthermore, given this is not just in diagnostics but
used for code generation, I think it is better to punt on arguments with
larger precision then sizetype, the upper bits are then truncated.

The patch also fixes some formatting issues and avoids duplication of the
fold_convert, plus removes unnecessary check for if (arg1 >= 0), that is
always the case after if (arg1 < 0) return ...;

2023-12-18  Jakub Jelinek  

PR tree-optimization/113013
* tree-object-size.cc (alloc_object_size): Return size_unknown if
corresponding argument(s) don't have integral type or have integral
type with higher precision than sizetype.  Don't check arg1 >= 0
uselessly.  Compare argument indexes against gimple_call_num_args
in unsigned type rather than int.  Formatting fixes.

* gcc.dg/pr113013.c: New test.

(cherry picked from commit 5347263b347d02e875879ca40ca6e289ac178919)

[Bug tree-optimization/113013] [12/13/14 regression] ICE in fold_convert_loc with -fsanitize=undefined

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

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

--- Comment #9 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:

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

commit r12-10059-gfebb86b366047e0ea48da85c9b52ee03878cb5bf
Author: Jakub Jelinek 
Date:   Mon Dec 18 09:59:28 2023 +0100

tree-object-size: Robustify alloc_size attribute handling [PR113013]

The following testcase ICEs because we aren't careful enough with
alloc_size attribute.  We do check that such an argument exists
(although wouldn't handle correctly functions with more than INT_MAX
arguments), but didn't check that it is scalar integer, the ICE is
trying to fold_convert a structure to sizetype.

Given that the attribute can also appear on non-prototyped functions
where the arguments aren't known, I don't see how the FE could diagnose
that and because we already handle the case where argument doesn't exist,
I think we should also verify the argument is scalar integer convertible
to sizetype.  Furthermore, given this is not just in diagnostics but
used for code generation, I think it is better to punt on arguments with
larger precision then sizetype, the upper bits are then truncated.

The patch also fixes some formatting issues and avoids duplication of the
fold_convert, plus removes unnecessary check for if (arg1 >= 0), that is
always the case after if (arg1 < 0) return ...;

2023-12-18  Jakub Jelinek  

PR tree-optimization/113013
* tree-object-size.cc (alloc_object_size): Return size_unknown if
corresponding argument(s) don't have integral type or have integral
type with higher precision than sizetype.  Don't check arg1 >= 0
uselessly.  Compare argument indexes against gimple_call_num_args
in unsigned type rather than int.  Formatting fixes.

* gcc.dg/pr113013.c: New test.

(cherry picked from commit 5347263b347d02e875879ca40ca6e289ac178919)

[Bug target/104401] [x86] Failure to recognize min/max pattern using pcmp+pblendv

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

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

Hongtao Liu  changed:

   What|Removed |Added

 CC||liuhongt at gcc dot gnu.org

--- Comment #6 from Hongtao Liu  ---
On latest trunk, we have

19   [local count: 1073741824]:
20  _6 = VIEW_CONVERT_EXPR(value_2(D));
21  _7 = VIEW_CONVERT_EXPR(input_3(D));
22  _8 = _6 < _7;
23  _4 = VEC_COND_EXPR <_8, _6, _7>;
24  _5 = VIEW_CONVERT_EXPR(_4);
25  return _5;
26
27}

And we can match a < b ? a : b for vector modes.

[Bug target/113059] [14 regression] fftw fails tests for -O3 -m32 -march=znver2 since r14-6210-ge44ed92dbbe9d4

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||i?86-*-*
   Target Milestone|--- |14.0

[Bug libstdc++/113060] New: std::variant converting constructor/assignment is non-conforming after P2280?

[dangelog at gmail dot com via Gcc-bugs]

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

Bug ID: 113060
   Summary: std::variant converting constructor/assignment is
non-conforming after P2280?
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dangelog at gmail dot com
  Target Milestone: ---

GCC 14 implements P2280 (see #106650). 

As a side effect of that, the "narrowing detector" used in std::variant's
converting constructor/assignment is now too restrictive. This code:


// IC is a type with a constexpr conversion operator
using IC = std::integral_constant;
std::variant v( IC{} );

should work after P2280 (libstdc++ says ill-formed).

---

https://eel.is/c++draft/variant.ctor#14 says:

> Let Tj be a type that is determined as follows: build an imaginary function 
> FUN(Ti) for each alternative type Ti for which Ti x[] = 
> {std​::​forward(t)}; is well-formed for some invented variable x.
> The overload FUN(Tj) selected by overload resolution for the expression 
> FUN(std​::​forward(​t)) defines the alternative Tj which is the type of 
> the contained value after construction.


Right now libstdc++ implements this by means of SFINAE:

> https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/variant#L787-L823


IC is convertible to float, and given the constexpr nature of its conversion
operator (to int), it wouldn't be a narrowing conversion:

  IC ic;
  float f{ic}; // not narrowing

However, using SFINAE means that std::declval() is used to build the
"candidate" argument of FUN. declval is not a constexpr function so its
returned value is not considered to be usable in constant expressions. 

The net effect is that `Ti x[] = {std​::​forward(t)};` is considered to be a
narrowing conversion ([dcl.init.list], int->float, source is not a constant
expression), and FUN(float) rejected.

But nowhere does [variant.ctor] talk about using std::declval; if one
reimplements the same check with a constraint, then GCC 14 accepts the
conversion:

template 
concept FUN_constraint = requires(T &&t) {
{ std::type_identity_t{ std::forward(t) } };
};

template 
requires FUN_constraint
void FUN(float);

FUN( IC{} ); // OK

https://gcc.godbolt.org/z/xP9z97v35

P2280 is necessary to make this work, because otherwise the usage of a
reference in the requires-expression would make `t` again not usable in
constant expressions. In conclusion, it seems that variant should indeed
accept construction from IC.

(I can't cross-check this report with other compilers as none of them
implements P2280 yet.)

[Bug tree-optimization/113013] [12/13/14 regression] ICE in fold_convert_loc with -fsanitize=undefined

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #10 from Jakub Jelinek  ---
Should be fixed now.

[Bug target/113061] New: [14 Regression][aarch64] ICE in lra_create_new_reg_with_unique_value, at lra.cc:192 since r14-6605-gc0911c6b357ba9

[mjires at suse dot cz via Gcc-bugs]

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

Bug ID: 113061
   Summary: [14 Regression][aarch64] ICE in
lra_create_new_reg_with_unique_value, at lra.cc:192
since r14-6605-gc0911c6b357ba9
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjires at suse dot cz
CC: acoplan at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

Compiling reduced testcase gfortran.dg/PR100911.f90 results in ICE since
r14-6605-gc0911c6b357ba9.


$ cat PR100911.f90
module module_foo
  use iso_c_binding
  contains
  subroutine foo(a) bind(c)
type(c_ptr)  a(..)
select rank(a)
end select
call bar
  end
end


$ aarch64-linux-gnu-gfortran PR100911.f90 -fno-move-loop-invariants -Oz
during RTL pass: reload
PR100911.f90:9:5:

9 |   end
  | ^
internal compiler error: in lra_create_new_reg_with_unique_value, at lra.cc:192
0x1578f06 lra_create_new_reg_with_unique_value(machine_mode, rtx_def*,
reg_class, HARD_REG_SET*, char const*)
/home/mjires/git/GCC/master/gcc/lra.cc:192
0x15792cd lra_create_new_reg(machine_mode, rtx_def*, reg_class, HARD_REG_SET*,
char const*)
/home/mjires/git/GCC/master/gcc/lra.cc:235
0x1588e7a get_reload_reg
/home/mjires/git/GCC/master/gcc/lra-constraints.cc:737
0x1593bf4 curr_insn_transform
/home/mjires/git/GCC/master/gcc/lra-constraints.cc:4663
0x1596278 lra_constraints(bool)
/home/mjires/git/GCC/master/gcc/lra-constraints.cc:5414
0x157eb50 lra(_IO_FILE*, int)
/home/mjires/git/GCC/master/gcc/lra.cc:2442
0x1526e43 do_reload
/home/mjires/git/GCC/master/gcc/ira.cc:5973
0x15272e0 execute
/home/mjires/git/GCC/master/gcc/ira.cc:6161
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


$ aarch64-linux-gnu-gfortran -v
Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-gfortran
COLLECT_LTO_WRAPPER=/home/mjires/built/master/libexec/gcc/aarch64-linux-gnu/14.0.0/lto-wrapper
Target: aarch64-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --target=aarch64-linux-gnu
--disable-bootstrap --enable-languages=c,c++,fortran --disable-multilib
--disable-libsanitizer --enable-checking
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231218 (experimental) (GCC)

[Bug target/113061] [14 Regression][aarch64] ICE in lra_create_new_reg_with_unique_value, at lra.cc:192 since r14-6605-gc0911c6b357ba9

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

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

Alex Coplan  changed:

   What|Removed |Added

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

--- Comment #1 from Alex Coplan  ---
Confirmed, I'll take a look.

[Bug libstdc++/113060] std::variant converting constructor/assignment is non-conforming after P2280?

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

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Giuseppe D'Angelo from comment #0)
> GCC 14 implements P2280 (see #106650). 

N.B. if you say "Bug 106650" or "PR 106650" or "bug #106650" or pretty much
anything except just #106650 then bugzilla makes it a clickable link :)

> it seems that variant should indeed accept construction from IC.

I'm not convinced that this change to the semantics of std::variant was an
intended side effect of https://wg21.link/P2280 -- I think I'd prefer if the
committee confirmed it.

The standard doesn't say that it _should_ work in a constant expression, it
seems like you're assuming that because it's now possible to implement it so
that it works, that it's required to work.

My reading of [variant.ctor] p14 is that "some invented variable x" is not a
constant expression, so using std::declval as a stand-in for "some invented
variable" is fine.

If we made this change, then some cases that compile today would become
ill-formed, e.g. see PR 113007. Under your reading, conversion from the
constant 42 would be valid for both int64_t and double, and so the
initialization would be ill-formed. But it would be well-formed when using a
non-constant int equal to 42.

Apart from the fact it would be a breaking change, the difference in behaviour
between runtime and compile time would be surprising. It would also mean that
std::is_constructible would be misleading: it would say you can construct
variant from 42, but when you try to do that it would fail to
compile.

[Bug target/113062] New: [14 Regression][aarch64] ICE in fuse_pair, at config/aarch64/aarch64-ldp-fusion.cc:1456 since r14-6605-gc0911c6b357ba9

[mjires at suse dot cz via Gcc-bugs]

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

Bug ID: 113062
   Summary: [14 Regression][aarch64] ICE in fuse_pair, at
config/aarch64/aarch64-ldp-fusion.cc:1456 since
r14-6605-gc0911c6b357ba9
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjires at suse dot cz
CC: acoplan at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

Compiling reduced testcase gcc.dg/compat/struct-return-10_x.c results in ICE
since r14-6605-gc0911c6b357ba9.

$ cat struct-return-10_x.c
long double foo;
double bar;
void abort();
void check() {
  if (foo == bar)
abort();
}


$ aarch64-linux-gnu-gcc struct-return-10_x.c -Oz -fharden-conditional-branches
during RTL pass: ldp_fusion
struct-return-10_x.c: In function ‘check’:
struct-return-10_x.c:7:1: internal compiler error: in fuse_pair, at
config/aarch64/aarch64-ldp-fusion.cc:1456
7 | }
  | ^
0x1e2c0c8 ldp_bb_info::fuse_pair(bool, unsigned int, int, rtl_ssa::insn_info*,
rtl_ssa::insn_info*, base_cand&, rtl_ssa::insn_range_info const&)
   
/home/mjires/git/GCC/master/gcc/config/aarch64/aarch64-ldp-fusion.cc:1456
0x1e2da97 ldp_bb_info::try_fuse_pair(bool, unsigned int, rtl_ssa::insn_info*,
rtl_ssa::insn_info*)
   
/home/mjires/git/GCC/master/gcc/config/aarch64/aarch64-ldp-fusion.cc:2217
0x1e2de0f ldp_bb_info::merge_pairs(std::__cxx11::list >&, std::__cxx11::list >&, bool, unsigned int)
   
/home/mjires/git/GCC/master/gcc/config/aarch64/aarch64-ldp-fusion.cc:2306
0x1e2e034 ldp_bb_info::transform_for_base(int, access_group&)
   
/home/mjires/git/GCC/master/gcc/config/aarch64/aarch64-ldp-fusion.cc:2339
0x1e306c8 void
ldp_bb_info::traverse_base_map >, access_group,
simple_hashmap_traits > >, access_group> >
>(ordered_hash_map >,
access_group,
simple_hashmap_traits > >, access_group> >&)
   
/home/mjires/git/GCC/master/gcc/config/aarch64/aarch64-ldp-fusion.cc:2398
0x1e2e27c ldp_bb_info::transform()
   
/home/mjires/git/GCC/master/gcc/config/aarch64/aarch64-ldp-fusion.cc:2405
0x1e2968c ldp_fusion_bb(rtl_ssa::bb_info*)
   
/home/mjires/git/GCC/master/gcc/config/aarch64/aarch64-ldp-fusion.cc:2634
0x1e29716 ldp_fusion()
   
/home/mjires/git/GCC/master/gcc/config/aarch64/aarch64-ldp-fusion.cc:2643
0x1e29828 execute
   
/home/mjires/git/GCC/master/gcc/config/aarch64/aarch64-ldp-fusion.cc:2693
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


$ aarch64-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/mjires/built/master/libexec/gcc/aarch64-linux-gnu/14.0.0/lto-wrapper
Target: aarch64-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --target=aarch64-linux-gnu
--disable-bootstrap --enable-languages=c,c++,fortran --disable-multilib
--disable-libsanitizer --enable-checking
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231218 (experimental) (GCC)

[Bug target/113062] [14 Regression][aarch64] ICE in fuse_pair, at config/aarch64/aarch64-ldp-fusion.cc:1456 since r14-6605-gc0911c6b357ba9

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

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

Alex Coplan  changed:

   What|Removed |Added

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

--- Comment #1 from Alex Coplan  ---
Confirmed, thanks for the report, I'll take a look.

[Bug c++/113063] New: Strange linker error in special case involving local class with defaulted spaceship operator and static assert

[kristian.spangsege at gmail dot com via Gcc-bugs]

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

Bug ID: 113063
   Summary: Strange linker error in special case involving local
class with defaulted spaceship operator and static
assert
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kristian.spangsege at gmail dot com
  Target Milestone: ---

With the latest GCC (13.2) and also with GCC 11.4, the following C++ code
triggers a strange linker error:


#include 

int main()
{
struct X {
auto operator<=>(const X&) const = default;
};
X x;
static_assert(noexcept(x < x));
static_cast(x < x);
}


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


The linker error is this:

/usr/bin/ld: /tmp/ccsnSU59.o: in function `main::X::operator<=>(X const&)
const':
t.cpp:(.text+0x31): undefined reference to
`std::strong_ordering::strong_ordering(std::strong_ordering const&)'


It seems to be a bug that is triggered by the presence of the static assertion,
but only when the it occurs before the actual invocation of the less-than
comparison operation. Also, if the local class (`X`) is moved out of `main()`,
the problem goes away.

[Bug c++/113063] Strange linker error in special case involving local class with defaulted spaceship operator and static assert

[kristian.spangsege at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Kristian Spangsege  ---
By the way, and as expected, this problem does not exist in Clang.

[Bug middle-end/111975] gimple front end can't round-trip vectorized code

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:5bca321faa30c4fb46225efbe2698a13b3271b1c

commit r14-6658-g5bca321faa30c4fb46225efbe2698a13b3271b1c
Author: Richard Biener 
Date:   Mon Dec 18 11:41:03 2023 +0100

c/111975 - GIMPLE FE dumping and parsing of TARGET_MEM_REF

The following adds dumping of TARGET_MEM_REF in -gimple form and
adds parsing of it to the GIMPLE FE.

PR c/111975
gcc/c/
* gimple-parser.cc (c_parser_gimple_postfix_expression):
Parse TARGET_MEM_REF extended operands for __MEM.

gcc/
* tree-pretty-print.cc (dump_mem_ref): Use TDF_GIMPLE path
also for TARGET_MEM_REF and amend it.

gcc/testsuite/
* gcc.dg/gimplefe-52.c: New testcase.

[Bug c++/113064] New: assignement from temporary sometimes invokes copy-assign instead of move-assign operator

[m.cencora at gmail dot com via Gcc-bugs]

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

Bug ID: 113064
   Summary: assignement from temporary sometimes invokes
copy-assign instead of move-assign operator
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.cencora at gmail dot com
  Target Milestone: ---

Following code fails to compile on any gcc version with any selected language
version. Works with clang.

When invoking the conversion operator the problem does not occur.
Also the mere existence of second overloaded conversion operator is
problematic.
Even though this conversion operator does not participate in overload
resolution due to being && qualified.
I marked it as deleted to show that this is not the overload being chosen by
compiler but just declaring it normally is enough to trigger the bug.

Compilation fails with error:
: In function 'void test()':
:31:10: error: use of deleted function 'no_copy&
no_copy::operator=(const no_copy&)'
   31 | nc = f;
  |  ^
:9:14: note: declared here
9 | no_copy& operator=(const no_copy&) = delete;
  |  ^~~~
Compiler returned: 1



// test.cpp
struct no_copy
{
no_copy() = default;

no_copy(const no_copy&) = delete;
no_copy(no_copy&&);

no_copy& operator=(const no_copy&) = delete;
no_copy& operator=(no_copy&&);
};

struct foo
{
operator no_copy() &
{
return no_copy();
}

#ifndef WORKAROUND1
operator no_copy&&() && = delete;
#endif
};

void test()
{
foo f;
no_copy nc;

#ifndef WORKAROUND2
nc = f;
#else
nc = f.operator bar();
#endif
}

[Bug target/113062] [14 Regression][aarch64] ICE in fuse_pair, at config/aarch64/aarch64-ldp-fusion.cc:1456 since r14-6605-gc0911c6b357ba9

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug target/113061] [14 Regression][aarch64] ICE in lra_create_new_reg_with_unique_value, at lra.cc:192 since r14-6605-gc0911c6b357ba9

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug c/113065] New: [ARM][NEON] Compiler crashes when doing shift on data with NEON intrinsic type

[clh960524+gcc at gmail dot com via Gcc-bugs]

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

Bug ID: 113065
   Summary: [ARM][NEON] Compiler crashes when doing shift on data
with NEON intrinsic type
   Product: gcc
   Version: 11.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clh960524+gcc at gmail dot com
  Target Milestone: ---

Created attachment 56900
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56900&action=edit
preprocessor result

Hi developers,

Currently I am working on adding ARMv8-A 32-bit test environment.
However, compiler outputs an internal error when it tries to do shifting on
NEON intrinsic data type.

This bug is confirmed on arm-linux-gnueabihf-gcc version 10.5.0, 11.4.0, and
12.3.0.

For your ease, here is the code to reproduce the issue (test.c):

#include 

#include 
#include 

#define HEDLEY_STATIC_CAST(T, expr) ((T) (expr))

#define SIMDE_POLY64_TYPE poly64_t
#define SIMDE_POLY64_C(value) (HEDLEY_STATIC_CAST(poly64_t, value ## ull))

typedef SIMDE_POLY64_TYPE simde_poly64;
typedef simde_poly64 simde_poly64_t;
typedef poly128_t simde_poly128_t;

simde_poly128_t
simde_vaddq_p128(simde_poly128_t a, simde_poly128_t b) {
  simde_poly128_t mask = 0xull;
  mask = mask << 64; 
  mask = mask | 0xull;
  return b ^ ((0 ^ a) & mask);
}

static int
simde_assert_equal_p64(simde_poly64 a, simde_poly64 b) {
  uint64_t a_ = HEDLEY_STATIC_CAST(uint64_t, a);
  uint64_t b_ = HEDLEY_STATIC_CAST(uint64_t, b);
  if (a_ != b_) {
return 1;
  }
  return 0;
}

static int
test_simde_vaddq_p128 () {
  struct {
simde_poly64_t a[2];
simde_poly64_t b[2];
simde_poly64_t r[2];
  } test_vec[] = {
{ {  SIMDE_POLY64_C( 2773134259082670592),  SIMDE_POLY64_C(
9031857671464751104) },
  {  SIMDE_POLY64_C(15408611317451976704),  SIMDE_POLY64_C(
5314471842361763840) },
  {  SIMDE_POLY64_C(17557921622677996032),  SIMDE_POLY64_C(
3789586984176121856) } }, 
{ {  SIMDE_POLY64_C(14363410812027238400),  SIMDE_POLY64_C(
7751777860661664768) },
  {  SIMDE_POLY64_C( 4070846577912177664),  SIMDE_POLY64_C(
8033403141717473280) },
  {  SIMDE_POLY64_C(18386960794487266304),  SIMDE_POLY64_C( 
355706841938420736) } }, 
{ {  SIMDE_POLY64_C(17019201421568192512),  SIMDE_POLY64_C(
9077731670917768192) },
  {  SIMDE_POLY64_C( 1093803490337685888), 
SIMDE_POLY64_C(12690135020377692160) },
  {  SIMDE_POLY64_C(16365414741193798016), 
SIMDE_POLY64_C(14836825620528675840) } }, 
{ {  SIMDE_POLY64_C( 8834005665657798656),  SIMDE_POLY64_C(
7315692870291161088) },
  {  SIMDE_POLY64_C( 3583172236868845568), 
SIMDE_POLY64_C(14913079096527761408) },
  {  SIMDE_POLY64_C( 5413693383775240192), 
SIMDE_POLY64_C(12354334249137418240) } }, 
{ {  SIMDE_POLY64_C(16318651152855345152), 
SIMDE_POLY64_C(15283972988033570816) },
  {  SIMDE_POLY64_C( 4795255037585536000), 
SIMDE_POLY64_C(17815911970323484672) },
  {  SIMDE_POLY64_C(11599959615349332992),  SIMDE_POLY64_C(
2532502929754736640) } }, 
{ {  SIMDE_POLY64_C(16540936757178476544),  SIMDE_POLY64_C(
4596081763017794560) },
  {  SIMDE_POLY64_C(15120265319048798208),  SIMDE_POLY64_C(
3251201193519464448) },
  {  SIMDE_POLY64_C( 3771992723781634048),  SIMDE_POLY64_C(
1357279216665519104) } }, 
{ {  SIMDE_POLY64_C( 7991373722374909952), 
SIMDE_POLY64_C(17418001980645539840) },
  {  SIMDE_POLY64_C(  303154826827825408),  SIMDE_POLY64_C(
9983013542091358208) },
  {  SIMDE_POLY64_C( 7697238601746657536),  SIMDE_POLY64_C(
8877691528758722560) } }, 
{ {  SIMDE_POLY64_C(14668463690243614720),  SIMDE_POLY64_C(
4370163632906065408) },
  {  SIMDE_POLY64_C( 3236423722687647744),  SIMDE_POLY64_C(
6051015495717347328) },
  {  SIMDE_POLY64_C(16679868711160412160),  SIMDE_POLY64_C(
8024418529387197952) } }, 
  };

  for (size_t i = 0 ; i < (sizeof(test_vec) / sizeof(test_vec[0])) ; i++) {
simde_poly128_t a = test_vec[i].a[0];
simde_poly128_t b = test_vec[i].b[0];
simde_poly128_t r, mask;
simde_poly64_t top_r, bottom_r;
a = a << 64;
a = a | test_vec[i].a[1];
b =  b << 64;
b =  b | test_vec[i].b[1];
r = simde_vaddq_p128(a, b);

mask = HEDLEY_STATIC_CAST(simde_poly128_t, 0xull);
top_r = HEDLEY_STATIC_CAST(simde_poly64_t, (r >> 64) & mask);
bottom_r = HEDLEY_STATIC_CAST(simde_poly64_t, (r << 64) >> 64);

simde_assert_equal_p64(top_r, test_vec[i].r[0]);
simde_assert_equal_p64(bottom_r, test_vec[i].r[1]);
  }

  return 0;
}

int main() {
  test_simde_vaddq_p128();
  return 0;
}

Here's the command for compiling:

arm-linux-gnueabihf-gcc -v -save-temps -mcpu=cortex-a32
-mfpu=crypto-neon-fp-armv8 -Wextra -Werror -Wall -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations test.c

[Bug c/113065] [ARM][NEON] Compiler crashes when doing shift on data with NEON intrinsic type

[clh960524+gcc at gmail dot com via Gcc-bugs]

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

--- Comment #1 from 陳履軒  ---
Here's the result after compiling:

$ arm-linux-gnueabihf-gcc -mcpu=cortex-a32 -mfpu=crypto-neon-fp-armv8 -Wextra
-Werror -Wall -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations
test.c
during RTL pass: expand
test.c: In function ‘simde_vaddq_p128’:
test.c:18:8: internal compiler error: in expand_shift_1, at expmed.c:2668
   18 |   mask = mask << 64;
  |   ~^~~~
0x7f9d29bf4d8f __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7f9d29bf4e3f __libc_start_main_impl
../csu/libc-start.c:392
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/113064] assignement from temporary sometimes invokes copy-assign instead of move-assign operator

[m.cencora at gmail dot com via Gcc-bugs]

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

--- Comment #1 from m.cencora at gmail dot com ---
Fixed sample (a typo in else branch of WORKAROUND2):

struct no_copy
{
no_copy() = default;

no_copy(const no_copy&) = delete;
no_copy(no_copy&&);

no_copy& operator=(const no_copy&) = delete;
no_copy& operator=(no_copy&&);
};

struct foo
{
operator no_copy() &
{
return no_copy();
}

#ifndef WORKAROUND1
operator no_copy&&() && = delete;
#endif
};

void test()
{
foo f;
no_copy nc;

#ifndef WORKAROUND2
nc = f;
#else
nc = f.operator no_copy();
#endif
}

[Bug c++/113064] assignement from temporary sometimes invokes copy-assign instead of move-assign operator

[m.cencora at gmail dot com via Gcc-bugs]

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

--- Comment #2 from m.cencora at gmail dot com ---
> When invoking the conversion operator the problem does not occur.
When invoking the conversion operator *explicitly* the problem does not occur.

[Bug rust/113056] [14 regression] Build failure in libgrust

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

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

--- Comment #10 from Sam James  ---
(In reply to Sam James from comment #8)
> for the pkg build (original report): no
> for the quick test I did earlier: yes because I was rushing, oops

/tmp/build $ ~/git/gcc/configure --prefix=/tmp/gcc
--enable-languages=c,c++,rust --enable-multilib --with-multilib-list=m32,m64
--with-checking=yes,extra,rtl --disable-analyzer --disable-cet
--disable-default-pie --disable-default-ssp --disable-gcov --disable-libada
--disable-libatomic --disable-libgomp --disable-libitm --disable-libquadmath
--disable-libsanitizer --disable-libssp --disable-libstdcxx-pch
--disable-libvtv --disable-lto --disable-nls --disable-objc-gc
--disable-systemtap --disable-werror && make -j$(nproc)

failed for me as well, so out of source indeed fails as well

[Bug c/112432] Internal-fn: The [i|l|ll]rint family don't support FLOATN

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Pan Li :

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

commit r14-6659-gb3b2799b872bc4c1944629af9dfc8472c8ca5fe6
Author: Juzhe-Zhong 
Date:   Mon Dec 18 19:35:21 2023 +0800

RISC-V: Support one more overlap for wv instructions

For 'wv' instructions, e.g. vwadd.wv vd,vs2,vs1.

vs2 has same EEW as vd.
vs1 has smaller than vd.

So, vs2 can overlap with vd, but vs1 can only overlap highest-number of vd
when LMUL of vs1 is greater than 1.

We already have supported overlap for vs1 LMUL >= 1.
But I forget vs1 LMUL < 1, vs2 can overlap vd even though vs1 totally can
not overlap vd.

Consider the reduction auto-vectorization:

int64_t
reduc_plus_int (int *__restrict a, int n)
{
  int64_t r = 0;
  for (int i = 0; i < n; ++i)
r += a[i];
  return r;
}

When we use --param=riscv-autovec-lmul=m2, the codegen is good to us
because we already supported
overlap for source EEW32 LMUL1 -> dest EEW64 LMUL2.

--param=riscv-autovec-lmul=m2:

reduc_plus_int:
ble a1,zero,.L4
vsetvli a5,zero,e64,m2,ta,ma
vmv.v.i v2,0
.L3:
vsetvli a5,a1,e32,m1,tu,ma
sllia4,a5,2
sub a1,a1,a5
vle32.v v1,0(a0)
add a0,a0,a4
vwadd.wvv2,v2,v1
bne a1,zero,.L3
li  a5,0
vsetivlizero,1,e64,m1,ta,ma
vmv.s.x v1,a5
vsetvli a5,zero,e64,m2,ta,ma
vredsum.vs  v2,v2,v1
vmv.x.s a0,v2
ret
.L4:
li  a0,0
ret

However, default LMUL (--param=riscv-autovec-lmul=m1) generates redundant
vmv1r since
it is EEW32 LMUL=MF2 -> EEW64 LMUL = 1

Before this patch:

reduc_plus_int:
ble a1,zero,.L4
vsetvli a5,zero,e64,m1,ta,ma
vmv.v.i v1,0
.L3:
vsetvli a5,a1,e32,mf2,tu,ma
sllia4,a5,2
sub a1,a1,a5
vle32.v v2,0(a0)
vmv1r.v v3,v1  >  This should be removed.
add a0,a0,a4
vwadd.wvv1,v3,v2   >  vs2 should be v1
bne a1,zero,.L3
li  a5,0
vsetivlizero,1,e64,m1,ta,ma
vmv.s.x v2,a5
vsetvli a5,zero,e64,m1,ta,ma
vredsum.vs  v1,v1,v2
vmv.x.s a0,v1
ret
.L4:
li  a0,0
ret

After this patch:

reduc_plus_int:
ble a1,zero,.L4
vsetvli a5,zero,e64,m1,ta,ma
vmv.v.i v1,0
.L3:
vsetvli a5,a1,e32,mf2,tu,ma
sllia4,a5,2
sub a1,a1,a5
vle32.v v2,0(a0)
add a0,a0,a4
vwadd.wvv1,v1,v2
bne a1,zero,.L3
li  a5,0
vsetivlizero,1,e64,m1,ta,ma
vmv.s.x v2,a5
vsetvli a5,zero,e64,m1,ta,ma
vredsum.vs  v1,v1,v2
vmv.x.s a0,v1
ret
.L4:
li  a0,0
ret

PR target/112432

gcc/ChangeLog:

* config/riscv/riscv.md (none,W21,W42,W84,W43,W86,W87): Add W0.
(none,W21,W42,W84,W43,W86,W87,W0): Ditto.
* config/riscv/vector.md: Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr112432-42.c: New test.

[Bug target/113061] [14 Regression][aarch64] ICE in lra_create_new_reg_with_unique_value, at lra.cc:192 since r14-6605-gc0911c6b357ba9

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

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

Alex Coplan  changed:

   What|Removed |Added

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

--- Comment #2 from Alex Coplan  ---
Looks like the bug is in the backend predicate aarch64_stp_reg_operand, I
messed up the parentheses there.  Sorry for the breakage.  I'll prepare a patch
to fix it.

[Bug target/69374] install.texi is bit-rotten

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

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

--- Comment #6 from GCC Commits  ---
The trunk branch has been updated by Gerald Pfeifer :

https://gcc.gnu.org/g:04538248c3ed202fd938f0ceff65ecce3b1786f3

commit r14-6660-g04538248c3ed202fd938f0ceff65ecce3b1786f3
Author: Gerald Pfeifer 
Date:   Mon Dec 18 21:39:22 2023 +0800

install: Drop hppa*-hp-hpux10, remove old notes on hppa*-hp-hpux11

gcc:
PR target/69374
* doc/install.texi (Specific) : Remove section.
(Specific) : Remove references to GCC 2.95 and
3.0. Also libffi has been ported now.

[Bug middle-end/113033] GCC 14 (20231203 snapshot) ICE when building LSX vector rotate code on LoongArch

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

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

Xi Ruoyao  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-Decembe
   ||r/640871.html
  Component|target  |middle-end

--- Comment #7 from Xi Ruoyao  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640871.html

I'm not convinced the ICE is a target issue.  The missed-optimization is a
target issue though.

[Bug libstdc++/113060] std::variant converting constructor/assignment is non-conforming after P2280?

[dangelog at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Giuseppe D'Angelo  ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Giuseppe D'Angelo from comment #0)
> > GCC 14 implements P2280 (see #106650). 
> 
> N.B. if you say "Bug 106650" or "PR 106650" or "bug #106650" or pretty much
> anything except just #106650 then bugzilla makes it a clickable link :)

D'oh! 


> > it seems that variant should indeed accept construction from IC.
> 
> I'm not convinced that this change to the semantics of std::variant was an
> intended side effect of https://wg21.link/P2280 -- I think I'd prefer if the
> committee confirmed it.

Ok, I'll raise the question to LEWG. Or maybe EWG?


> The standard doesn't say that it _should_ work in a constant expression, it
> seems like you're assuming that because it's now possible to implement it so
> that it works, that it's required to work.
> 
> My reading of [variant.ctor] p14 is that "some invented variable x" is not a
> constant expression, so using std::declval as a stand-in for "some invented
> variable" is fine.


But it does say how you get that x, you get it from the statement:

  Tj x[] = {std​::​forward(t)};

Nowhere in there's a call to declval. My reasoning is simply that if you spell
FUN out for Ti = float, something like this (although the standard doesn't
really specify the signature of FUN, which is not ideal):

  template 
  auto FUN_float(T &&t) {
  float x[] = {std​::​forward(t)};
  }

then FUN_float(IC{}) is well-formed after P2280.

Note that in general

  IC c;   // not const!!!
  float f{c}; // OK

is well-formed, and this is even before P2280. What seems to have changed with
P2280 is that references do not disqualify expressions from being constant, and
thus we can now detect this case a requires-expression that uses references.


> If we made this change, then some cases that compile today would become
> ill-formed, e.g. see PR 113007. Under your reading, conversion from the
> constant 42 would be valid for both int64_t and double, and so the
> initialization would be ill-formed. But it would be well-formed when using a
> non-constant int equal to 42.

Are you sure it would? FUN_double(42) should be still ill-formed (!), due to
narrowing. 

My reasoning, in the context of P0870 (is_convertible_without_narrowing), is
that int->double requires a lvalue-to-rvalue conversion, and then this kicks in
https://eel.is/c++draft/expr.const#5.9 , disqualifying `t` from being treated
as a constant expression. So then the list-initialization of `x` triggers
narrowing.

This is different from IC->double, where there's no lvalue-to-rvalue conversion
(!), it's described here
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p0870r5.html#ch5.9

Testcase: https://gcc.godbolt.org/z/rfvnfvYzs


> Apart from the fact it would be a breaking change, the difference in
> behaviour between runtime and compile time would be surprising. It would
> also mean that std::is_constructible would be misleading: it would say you
> can construct variant from 42, but when you try to do that it
> would fail to compile.

Sure, I'm really struggling at squaring the P2280 rules with detecting
narrowing conversions, but I'm not sure if this would actually break. (And I'm
not sure if something _else_ would break instead.)

[Bug middle-end/111975] gimple front end can't round-trip vectorized code

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:88a398a487ee37f1fc7850740f2d94d895657646

commit r14-6662-g88a398a487ee37f1fc7850740f2d94d895657646
Author: Richard Biener 
Date:   Mon Dec 18 13:40:46 2023 +0100

middle-end/111975 - dump -> GIMPLE FE roundtrip improvements

The following improves the manual work needed to make a -gimple dump
valid input to the GIMPLE FE.  First of all it recognizes the 'sizetype'
tree and dumps it as __SIZETYPE__, then it changes dumping vector types
without name from 'vector(n) T' to 'T [[gnu::vector_size(n')]]' which
we can parse in most relevant contexts (and that's shorter than
using __attribute__).  Third it avoids a NULL_TREE TMR_STEP when
it would be one, an optimization that's re-done when generating RTL.

PR middle-end/111975
* tree-pretty-print.cc (dump_generic_node): Dump
sizetype as __SIZETYPE__ with TDF_GIMPLE.
Dump unnamed vector types as T [[gnu::vector_size(n)]] with
TDF_GIMPLE.
* tree-ssa-address.cc (create_mem_ref_raw): Never generate
a NULL STEP when INDEX is specified.

[Bug middle-end/111975] gimple front end can't round-trip vectorized code

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

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

--- Comment #5 from Richard Biener  ---
What's left is the dots.

[Bug translation/113066] New: Returning from a function marked noreturn allows execution to fall-through

[luke.geeson at cs dot ucl.ac.uk via Gcc-bugs]

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

Bug ID: 113066
   Summary: Returning from a function marked noreturn allows
execution to fall-through
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luke.geeson at cs dot ucl.ac.uk
  Target Milestone: ---

Consider the following program.

```
[[noreturn]] inline void ub_if_reached() { return; }

void P0 () {
  atomic_store_explicit(y,1,memory_order_release);
  ub_if_reached();
}
```

If compiled to target Armv8-a using `clang -O3`
(https://godbolt.org/z/T33Yncjsh), the whole of `P0` is optimised away.

This is because `ub_if_reached` is marked as `noreturn` which means this
function should not return, however the `return` statement does exactly that,
inducing undefined behaviour.

Clang warns of this behaviour, and optimises away the code in `P0` before the
call, since it assumes a program is UB-free and that `P0` is therefore
unreachable.  Further if we define an `f` that calls a `g` that calls `P0` from
`main` then all functions including `main` are also optimised away
(https://godbolt.org/z/qsraYr7o5).

Technically the standards and compiler are not required to do anything here as
there is UB, however if this program is compiled and linked with a program that
calls `P0` then the resultant execution may fallthrough to the code below `P0`.
Both GCC and LLVM allow `P0` to fallthrough - this is not good and only
functions guaranteed to return should be subject to this optimisation.

In practice we can fix this by:

- emitting an explicit abort (or undefined instruction that causes a trap) at
the end of `noreturn` functions like `ub_if_reached`, or
- if the compiler can statically determine that a `noreturn` function does in
fact `return` then ignore the noreturn attribute, and emit an abort on return.

As far as I can tell, this behaviour arises in clang, but clang has an optional
`-mllvm -trap-unreachable` to prevent this behaviour. I was made aware that GCC
has `-fsanitize=undefined` `-fsanitize-trap=undefined` for this, but these seem
to be general options. It would be good for GCC to have a flag similar to
`-mllvm -trap-unreachable`.

Disclaimer: The views of the authors expressed in this bug report are my own
and are not endorsed by Arm or any other company mentioned.

[Bug rust/113056] [14 regression] Build failure in libgrust

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
 Status|WAITING |ASSIGNED
 CC||tschwinge at gcc dot gnu.org

--- Comment #11 from Thomas Schwinge  ---
Reproduced, and I think I know what's happening.

[Bug middle-end/113067] New: [OpenMP][5.1] Context selector - handle 'implementation={requires(...)}'

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

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

Bug ID: 113067
   Summary: [OpenMP][5.1] Context selector - handle
'implementation={requires(...)}'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

OpenMP 5.1 added:
  'implementation={requires(...)}'
where ... = unified_shared_memory or unified_address etc.

OpenMP 5.0 only had, e.g.
  'implementation={unified_shared_memory}'

the former is not yet handled

* * *

With the about to be committed patch,
  https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640817.html
which is actually at
  https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639797.html
the Fortran parser in principle handles (when removing the 'sorry') and adds
'unified_shared_memory' and 'requires' according to -fdump-tree-*.

For C/C++, it does ICE - which means that more work is required.

And, in either case, depends how we want to handle it in internal
representation.

=> Attached parse-only testcase.

* * *

Independent of this, I am not sure whether we do handle this requirement
correctly.

Namely, for:

(A)  implementation={unified_shared_memory}'
i.e. those which change depending on 'omp requires unified_shared_memory'
being set or not.

(B)  implementation={dynamic_allocators}'
which is currently ignored rather early as it is always true for GCC.

(C) implementation={atomic_default_mem_order(acq_rel)}'

The later is quite interesting as - at least in Fortran - multiple values are
permitted per file (to be checked) and I am not quite sure whether the value is
really handled in the ME.

[Bug middle-end/113067] [OpenMP][5.1] Context selector - handle 'implementation={requires(...)}'

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

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

--- Comment #1 from Tobias Burnus  ---
Created attachment 56901
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56901&action=edit
Simple testcase (C and Fortran) -  as same-directory .diff

[Bug middle-end/113066] Returning from a function marked noreturn allows execution to fall-through

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

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

--- Comment #1 from Andrew Pinski  ---
GCC does warn not just once but twice:
```
: In function 'ub_if_reached':
:2:44: warning: function declared 'noreturn' has a 'return' statement
2 | [[noreturn]] inline void ub_if_reached() { return; }
  |^~
:2:44: warning: 'noreturn' function does return
2 | [[noreturn]] inline void ub_if_reached() { return; }
  |^
```

[Bug target/113062] [14 Regression][aarch64] ICE in fuse_pair, at config/aarch64/aarch64-ldp-fusion.cc:1456 since r14-6605-gc0911c6b357ba9

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

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

--- Comment #2 from Alex Coplan  ---
So we try to combine these two insns:

(insn 14 82 16 2 (set (mem/c:TF (plus:DI (reg/f:DI 31 sp)
(const_int 32 [0x20])) [3 %sfp+-32 S16 A128])
(asm_operands:TF ("") ("=g") 0 [
(mem/c:TF (plus:DI (reg/f:DI 31 sp)
(const_int 32 [0x20])) [3 %sfp+-32 S16 A128])
]
 [
(asm_input:TF ("0") t.c:5)
]
 [] t.c:5)) "t.c":5:6 -1
 (nil))
(insn 16 14 19 2 (set (mem/c:TF (plus:DI (reg/f:DI 31 sp)
(const_int 48 [0x30])) [3 %sfp+-16 S16 A128])
(asm_operands:TF ("") ("=g") 0 [
(mem/c:TF (plus:DI (reg/f:DI 31 sp)
(const_int 48 [0x30])) [3 %sfp+-16 S16 A128])
]
 [
(asm_input:TF ("0") t.c:5)
]
 [] t.c:5)) "t.c":5:6 -1
 (nil))

I think we aren't expecting to see memory operands in the RHS of the stores, I
think the pass needs to reject invalid operands earlier before we even start
tracking them.

Testing a patch.

[Bug middle-end/113066] Returning from a function marked noreturn allows execution to fall-through

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

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

--- Comment #2 from Andrew Pinski  ---
GCC 2.95.3 has the same behavior 

[Bug middle-end/113066] Returning from a function marked noreturn allows execution to fall-through

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

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

--- Comment #3 from Andrew Pinski  ---
Note -funreachable-traps works for what you want it to work at -O1 and above
but not at -O0 due to ub_if_reached not being inlined ...

[Bug middle-end/113066] Returning from a function marked noreturn allows execution to fall-through

[luke.geeson at cs dot ucl.ac.uk via Gcc-bugs]

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

Luke Geeson  changed:

   What|Removed |Added

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

--- Comment #4 from Luke Geeson  ---
Ah my apologies - I missed that command line flag when I was checking...

I'm sorry for wasting your time. I will close and mark it as invalid.
Thanks!

[Bug libstdc++/113068] New: : ranges::to() | ranges::to() is not a range adaptor

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 113068
   Summary: : ranges::to() |
ranges::to() is not a range adaptor
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

libstdc++ rejects the following code, which it shouldn't be.

  #include 
  #include 

  int main() {
auto adaptor = std::ranges::to() |
std::ranges::to();
auto str = adaptor(" ");
  }

https://godbolt.org/z/7TrzcdTcz

[Bug target/113040] [14 Regression] libmvec test failures

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #2 from H.J. Lu  ---
Created attachment 56902
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56902&action=edit
A testcase

[hjl@gnu-tgl-3 tmp]$
/export/build/gnu/tools-build/gcc-gitlab-debug/release/usr/gcc-14.0.0-x86-64/bin/gcc
x.c -frounding-math -O2 -g -fopenmp -fno-inline -mavx2 -D_GNU_SOURCE -lm
-fno-builtin -D__FAST_MATH__
[hjl@gnu-tgl-3 tmp]$ ./a.out 
Segmentation fault (core dumped)
[hjl@gnu-tgl-3 tmp]$
/export/build/gnu/tools-build/gcc-gitlab-debug/release/usr/gcc-14.0.0-x86-64/bin/gcc
x.c -frounding-math -O2 -g -fopenmp -fno-inline -mavx512f -D_GNU_SOURCE -lm
-fno-builtin -D__FAST_MATH__
[hjl@gnu-tgl-3 tmp]$ ./a.out 
Segmentation fault (core dumped)
[hjl@gnu-tgl-3 tmp]$

[Bug target/113040] [14 Regression] libmvec test failures

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

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

[Bug libstdc++/113068] : ranges::to() | ranges::to() is not a range adaptor

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 CC||ppalka at gcc dot gnu.org
   Last reconfirmed||2023-12-18
 Ever confirmed|0   |1
 Depends on||112802

--- Comment #1 from Patrick Palka  ---
IIUC this will be fixed by making ranges::to's closure object SFINAE-friendly.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112802
[Bug 112802] : _ToClosure::operator() has no constraints

[Bug target/113065] [ARM][NEON] Compiler crashes when doing shift on data with NEON intrinsic type

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

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

Alex Coplan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-12-18
   Keywords||ice-on-valid-code
 CC||acoplan at gcc dot gnu.org

--- Comment #2 from Alex Coplan  ---
Confirmed, here is a reduced testcase:

$ cat t.c
typedef __builtin_neon_poly128 poly128_t;
poly128_t test_simde_vaddq_p128(poly128_t a) { return a << 4; }
$ ./xgcc -B . -c t.c -S -o /dev/null -march=armv8-a+simd -mfloat-abi=hard
during RTL pass: expand
t.c: In function ‘test_simde_vaddq_p128’:
t.c:2:57: internal compiler error: in expand_shift_1, at expmed.cc:2686
2 | poly128_t test_simde_vaddq_p128(poly128_t a) { return a << 4; }
  |   ~~^~~~
0x225b687 expand_shift_1
/home/alecop01/toolchain/src/gcc/gcc/expmed.cc:2686
0x225b7a0 expand_variable_shift(tree_code, machine_mode, rtx_def*, tree_node*,
rtx_def*, int)
/home/alecop01/toolchain/src/gcc/gcc/expmed.cc:2727
0x229007d expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/home/alecop01/toolchain/src/gcc/gcc/expr.cc:10256
0x207a203 expand_gimple_stmt_1
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.cc:3983
0x207a44c expand_gimple_stmt
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.cc:4044
0x20824cc expand_gimple_basic_block
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.cc:6100
0x208487d execute
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.cc:6835
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/113068] : ranges::to() | ranges::to() is not a range adaptor

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #2 from 康桓瑋  ---
(In reply to Patrick Palka from comment #1)
> IIUC this will be fixed by making ranges::to's closure object
> SFINAE-friendly.

I didn't investigate the root cause in depth. So this should probably be
considered a duplicate of PR 112802, right?

[Bug tree-optimization/113054] [14 regressions] ODR warnings when building new SCCP pass

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

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

--- Comment #5 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:4554a151d0ec62332c332175ec1017f853006b60

commit r14-6663-g4554a151d0ec62332c332175ec1017f853006b60
Author: Andrew Pinski 
Date:   Mon Dec 18 08:18:13 2023 -0800

SCCP: Fix ODR issues when compiling with LTO [PR 113054}

The problem here is that in C++ structs and classes have a
linkage too so the type vertex is not considered local to
the TU but will conflict with the globally defined one
in graphds.h.  The simple way to fix this is to wrap the ones
defined locally in gimple-ssa-sccopy.cc inside an anonymous namespace
and they are now considered locally to that TU.

Committed as obvious after a bootstrap/test on x86_64.

gcc/ChangeLog:

PR tree-optimization/113054
* gimple-ssa-sccopy.cc: Wrap the local types
with an anonymous namespace.

Signed-off-by: Andrew Pinski 

[Bug tree-optimization/113054] [14 regressions] ODR warnings when building new SCCP pass

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Andrew Pinski  ---
Fixed.

[Bug middle-end/113058] [meta-bug] RTL frontend issues

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug c++/113063] Strange linker error in special case involving local class with defaulted spaceship operator and static assert

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-12-18
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed, also GCC ICEs with -O1 and above (when GCC is configured with
checking enabled which is the default for the trunk):
```
: In function 'int main()':
:11:27:   in 'constexpr' expansion of 'x.main()::X::operator<=>(x)'
:7:14: internal compiler error: in cxx_eval_call_expression, at
cp/constexpr.cc:3013
7 | auto operator<=>(const X&) const = default;
  |  ^~~~
```

[Bug c++/113063] Strange linker error in special case involving local class with defaulted spaceship operator and static assert

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick Palka  ---
Seems the problem is that the first use of the operator<=> occurs inside an
unevaluated context, and we forget to reset the context before synthesizing the
function.

[Bug c/113069] New: gimple-ssa-sccopy.cc:143:12: warning: private field 'curr_generation' is not used [-Wunused-private-field]

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 113069
   Summary: gimple-ssa-sccopy.cc:143:12: warning: private field
'curr_generation' is not used [-Wunused-private-field]
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

>From today's build of gcc trunk with clang:

gcc $ grep curr_generation gimple-ssa-sccopy.cc 
  unsigned curr_generation = 0;
gcc $

[Bug rust/113056] [14 regression] Build failure in libgrust

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #12 from Thomas Schwinge  ---
(In reply to Sam James from comment #0)
> checking for suffix of object files... configure: error: in
> `/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/build/32/libgrust':
> configure: error: cannot compute suffix of object files: cannot compile
> See `config.log' for more details
> make[1]: *** [Makefile:16176: configure-libgrust] Error 1

Notice that this is the *host* libgrust build -- unexpectedly multilibbed. 
Please test

"libgrust: 'AM_ENABLE_MULTILIB' only for target builds [PR113056]".

[Bug c++/113025] Pointer is sometimes assumed to be 16-byte aligned even when there is no such guarantee

[juki at gcc dot mail.kapsi.fi via Gcc-bugs]

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

juki at gcc dot mail.kapsi.fi changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #2 from juki at gcc dot mail.kapsi.fi ---
Unfortunately alignment of the cast type was not causing this issue.

I changed all calls that were defined in GCC headers to use __m128i_u or
__m128d_u types to use those types before unaligned intrinsic.

For example LOAD_SI128 macro looks like the following:

#define LOAD_SI128(ptr) \
( ((uintptr_t)(ptr) & 15) == 0 ) ? _mm_load_si128((__m128i*)(ptr)) :
_mm_loadu_si128((__m128i_u*)(ptr))

My changes only changed the debug information locations but did not lead to the
generation of different kind of load operations. In fact, generated assembly
was identical outside of debug line information changes:

$ diff -u0 orig.s fixed.s|grep movdq| wc
  0   0   0

But if aligned loads are removed completely as an option and only unaligned
loads (even with the wrong intrinsic type) are used, no invalid aligned loads
are generated and assembly changes significantly regarding movdq* instructions:

#define LOAD_SI128(ptr) \
( 0 ) ? _mm_load_si128((__m128i*)(ptr)) :
_mm_loadu_si128((__m128i*)(ptr))

diff -u0 orig.s align-loads-removed.s|grep movdq| wc
  11001   44004  263376

Above code fixes all our invalid instruction generation while only using
correct types does not.

While I can't share the related sources, I could still try to run different
tests locally to see what is be causing the issue. What could I do next to help
solve this as I do have reliable test cases to work with.

[Bug c++/113025] Pointer is sometimes assumed to be 16-byte aligned even when there is no such guarantee

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug libstdc++/113068] : ranges::to() | ranges::to() is not a range adaptor

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

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

--- Comment #3 from Patrick Palka  ---
It could, but IMHO it's a different enough testcase/issue that a separate PR is
fine too.

[Bug tree-optimization/113069] gimple-ssa-sccopy.cc:143:12: warning: private field 'curr_generation' is not used [-Wunused-private-field]

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||fkastl at suse dot cz

--- Comment #1 from David Binderman  ---
git blame has this:

cd794c39610 (Filip Kastl 2023-12-14 11:29:31 +0100 143)   unsigned
curr_generation = 0;

Adding author for their opinion.

[Bug target/113070] New: [14 regression] [AArch64] [PGO/LTO] Miscompilation of go compiler

[schwab--- via Gcc-bugs]

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

Bug ID: 113070
   Summary: [14 regression] [AArch64] [PGO/LTO] Miscompilation of
go compiler
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: lto, wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
  Target Milestone: ---
Target: aarch64-*-*

https://build.opensuse.org/package/live_build_log/devel:gcc:next/gcc14/openSUSE_Factory_ARM/aarch64

In a PGO/LTO bootstrap the Go compiler is apparently miscompiled:

make[4]: Entering directory
'/home/abuild/rpmbuild/BUILD/gcc-14.0.0+git6645/obj-aarch64-suse-linux/aarch64-suse-linux/libgo'
/usr/bin/mkdir -p internal; files=`echo
../../../libgo/go/internal/goarch/goarch.go zgoarch.go | sed -e 's/[^
]*\.gox//g' -e 's/[^ ]*\.dep//'`; /bin/sh ./libtool --tag GO --mode=compile
/home/abuild/rpmbuild/BUILD/gcc-14.0.0+git6645/obj-aarch64-suse-linux/./gcc/gccgo
-B/home/abuild/rpmbuild/BUILD/gcc-14.0.0+git6645/obj-aarch64-suse-linux/./gcc/
-B/usr/aarch64-suse-linux/bin/ -B/usr/aarch64-suse-linux/lib/ -isystem
/usr/aarch64-suse-linux/include -isystem /usr/aarch64-suse-linux/sys-include   
   -O2 -g -I . -c -fgo-pkgpath=`echo internal/goarch.lo | sed -e 's/.lo$//'` 
-o internal/goarch.lo $files
libtool: compile: 
/home/abuild/rpmbuild/BUILD/gcc-14.0.0+git6645/obj-aarch64-suse-linux/./gcc/gccgo
-B/home/abuild/rpmbuild/BUILD/gcc-14.0.0+git6645/obj-aarch64-suse-linux/./gcc/
-B/usr/aarch64-suse-linux/bin/ -B/usr/aarch64-suse-linux/lib/ -isystem
/usr/aarch64-suse-linux/include -isystem /usr/aarch64-suse-linux/sys-include
-O2 -g -I . -c -fgo-pkgpath=internal/goarch
../../../libgo/go/internal/goarch/goarch.go zgoarch.go  -fPIC -o
internal/.libs/goarch.o
zgoarch.go:7:3: error: redefinition of ''
7 |   _BigEndian = false
  |   ^
zgoarch.go:6:3: note: previous definition of '' was here
6 |   _ArchFamily = ARM64
  |   ^
zgoarch.go:8:3: error: redefinition of ''
8 |   _DefaultPhysPageSize = 65536
  |   ^
zgoarch.go:6:3: note: previous definition of '' was here
6 |   _ArchFamily = ARM64
  |   ^
zgoarch.go:9:3: error: redefinition of ''
9 |   _Int64Align = 8
  |   ^
zgoarch.go:6:3: note: previous definition of '' was here
6 |   _ArchFamily = ARM64
  |   ^
zgoarch.go:10:3: error: redefinition of ''
   10 |   _MinFrameSize = 8
  |   ^
zgoarch.go:6:3: note: previous definition of '' was here
6 |   _ArchFamily = ARM64
  |   ^
zgoarch.go:11:3: error: redefinition of ''
   11 |   _PCQuantum = 4
  |   ^
zgoarch.go:6:3: note: previous definition of '' was here
6 |   _ArchFamily = ARM64
  |   ^
zgoarch.go:12:3: error: redefinition of ''
   12 |   _StackAlign = 16
  |   ^
zgoarch.go:6:3: note: previous definition of '' was here
6 |   _ArchFamily = ARM64
  |   ^
../../../libgo/go/internal/goarch/goarch.go:8:21: error: expected type
8 | type ArchFamilyType int
  | ^
zgoarch.go:6:3: error: constant refers to itself
6 |   _ArchFamily = ARM64
  |   ^
../../../libgo/go/internal/goarch/goarch.go:12:19: error: shift count overflow
   12 | const PtrSize = 4 << (^uintptr(0) >> 63)
  |   ^
zgoarch.go:21:9: error: constant refers to itself
   21 | ARM64
  | ^
make[4]: *** [Makefile:3049: internal/goarch.lo] Error 1
make[4]: Leaving directory
'/home/abuild/rpmbuild/BUILD/gcc-14.0.0+git6645/obj-aarch64-suse-linux/aarch64-suse-linux/libgo'
make[4]: Entering directory
'/home/abuild/rpmbuild/BUILD/gcc-14.0.0+git6645/obj-aarch64-suse-linux/aarch64-suse-linux/libgo'
/usr/bin/mkdir -p internal; files=`echo
../../../libgo/go/internal/unsafeheader/unsafeheader.go | sed -e 's/[^
]*\.gox//g' -e 's/[^ ]*\.dep//'`; /bin/sh ./libtool --tag GO --mode=compile
/home/abuild/rpmbuild/BUILD/gcc-14.0.0+git6645/obj-aarch64-suse-linux/./gcc/gccgo
-B/home/abuild/rpmbuild/BUILD/gcc-14.0.0+git6645/obj-aarch64-suse-linux/./gcc/
-B/usr/aarch64-suse-linux/bin/ -B/usr/aarch64-suse-linux/lib/ -isystem
/usr/aarch64-suse-linux/include -isystem /usr/aarch64-suse-linux/sys-include   
   -O2 -g -I . -c -fgo-pkgpath=`echo internal/unsafeheader.lo | sed -e
's/.lo$//'`  -o internal/unsafeheader.lo $files
libtool: compile: 
/home/abuild/rpmbuild/BUILD/gcc-14.0.0+git6645/obj-aarch64-suse-linux/./gcc/gccgo
-B/home/abuild/rpmbuild/BUILD/gcc-14.0.0+git6645/obj-aarch64-suse-linux/./gcc/
-B/usr/aarch64-suse-linux/bin/ -B/usr/aarch64-suse-linux/lib/ -isystem
/usr/aarch64-suse-linux/include -isystem /usr/aarch64-suse-linux/sys-include
-O2 -g -I . -c -fgo-pkgpath=internal/unsafeheader
../../../libgo/go/internal/unsafeheader/unsafeheader.go  -fPIC -o
internal/.libs/unsafeheader.o
go1: internal compiler error: in note_usage, at go/gofrontend/gogo.cc:9524
0x1aaefd3 Package::note_usage(std::__cxx11::basic_string, std::allocator 

[Bug fortran/96580] F2018 changes to date_and_time intrinsics

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org

--- Comment #4 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2023-December/060045.html

[Bug tree-optimization/113071] New: `((a == c) || (a == b)) ? a : b` is sometimes not optimized to `(a == c) ? c : b`

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

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

Bug ID: 113071
   Summary: `((a == c) || (a == b)) ? a : b` is sometimes not
optimized to `(a == c) ? c : b`
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
int f(int a, int b, int c)
{
  return ((a == c) | (a == b)) ? a : b;
}
int f_(int a, int b, int c)
{
  return ((a == b) | (a == c)) ? a : b;
}
int f1(int a, int b, int c)
{
  return ((a == c) || (a == b)) ? a : b;
}
int f1_(int a, int b, int c)
{
  return ((a == b) || (a == c)) ? a : b;
}
int f2(int a, int b, int c)
{
  if (a == c) return a;
  if (a == b) return a;
  return b;
}
int f2_(int a, int b, int c)
{
  if (a == b) return a;
  if (a == c) return a;
  return b;
}
int f3(int a, int b, int c)
{
  if (a == c) return c;
  return b;
}
```

These all should be optimized to the same as f3 but currently only f2 is on all
targets while f1 is on targets were logical-op-non-short-circuit is 0.
f_, f1_, f2_ all are not optimized either.

[Bug tree-optimization/113072] New: `(a ^ CST0) & (~a ^ CST0)` is not optimized to 0 at the gimple level

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

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

Bug ID: 113072
   Summary: `(a ^ CST0) & (~a ^ CST0)` is not optimized to 0 at
the gimple level
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: TREE
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
int foo(int a, int b) { return (a ^ 4) & (~a ^ 4); }
```
This should be optimized to 0 but is missed at the gimple level.


RTL Combine catches it:
```
Trying 8, 7 -> 9:
8: {r105:SI=r101:SI^0xfffb;clobber flags:CC;}
  REG_DEAD r101:SI
  REG_UNUSED flags:CC
7: {r104:SI=r101:SI^0x4;clobber flags:CC;}
  REG_UNUSED flags:CC
9: {r103:SI=r104:SI&r105:SI;clobber flags:CC;}
  REG_DEAD r105:SI
  REG_DEAD r104:SI
  REG_UNUSED flags:CC
Failed to match this instruction:
(parallel [
(set (reg:SI 103)
(const_int 0 [0]))
(clobber (reg:CC 17 flags))
])
Successfully matched this instruction:
(set (reg:SI 103)
(const_int 0 [0]))
allowing combination of insns 7, 8 and 9
original costs 4 + 4 + 4 = 12
replacement cost 4
```
via apply_distributive_law (I think) which does basically `(a ^ 4) & (a ^
(~4))` -> `(4 ^ (~4)) & (a ^ a)` which is 0 as `a ^ a` is 0.

[Bug tree-optimization/113072] `(a ^ CST0) & (~a ^ CST0)` is not optimized to 0 at the gimple level

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

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

--- Comment #1 from Andrew Pinski  ---
Wait this part is wrong `which does basically `(a ^ 4) & (a ^ (~4))` -> `(4 ^
(~4)) & (a ^ a)` which is 0 as `a ^ a` is 0.`

Anyways a pattern like:
```
(simplify
 (bit_and (bit_xor @0 @1) (bit_xor @0 @2))
 (with { bool wascmp; }
  (if (bitwise_inverted_equal_p (@1, @2, &wascmp))
   { wascmp ? constant_boolean_node (false, type) : build_zero_cst (type); })))
```

Is needed for bool.

[Bug tree-optimization/113072] `(a ^ CST0) & (~a ^ CST0)` is not optimized to 0 at the gimple level

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

[Bug tree-optimization/113072] `(a ^ CST0) & (~a ^ CST0)` is not optimized to 0 at the gimple level

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Looks like bool sometimes produces != or ^ :)
```
bool foo(bool a, int b)
{
bool b1 = b == 1;
bool b2 = !b1;
bool c = (a ^ b1);
return  c & (a ^ b2);
}
```
Though that is PR 49 .

[Bug tree-optimization/113072] `(a ^ CST0) & (~a ^ CST0)` is not optimized to 0 at the gimple level

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

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

--- Comment #3 from Andrew Pinski  ---
here is the bool testcase which just allows the use of ^:
```
bool foo1(bool a, int b)
{
bool b1 = b == 1;
bool b2 = !b1;
return  (a ^ b1) & (a ^ b2);
}
```

[Bug target/112816] [11/12 Regression] ICE unrecognizable_insn with __builtin_signbit and returning struct with int[4]

[a.elovikov at gmail dot com via Gcc-bugs]

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

--- Comment #15 from Andrei Elovikov  ---
I'd like to point out that while the first reproducer
(https://godbolt.org/z/3vzejjWcq) started to pass now on godbolt, the second
(https://godbolt.org/z/cEh1W7PdG) still fails with an ICE. Please let me know
if you'd prefer me to submit a separate report for it.

[Bug fortran/96580] F2018 changes to date_and_time intrinsics

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r14-6665-gb77691a90fc8a7e917417ce747bf78669304f951
Author: Harald Anlauf 
Date:   Mon Dec 18 18:59:02 2023 +0100

Fortran: update DATE_AND_TIME intrinsic for Fortran 2018 [PR96580]

Fortran 2018 allows a non-default integer kind for its VALUES argument if
it has a decimal exponent range of at least four.  Update checks, library
implementation and documentation.

gcc/fortran/ChangeLog:

PR fortran/96580
* check.cc (array_size_check): New helper function.
(gfc_check_date_and_time): Use it for checking minimum size of
VALUES argument.  Update kind check to Fortran 2018.
* intrinsic.texi: Fix documentation of DATE_AND_TIME.

libgfortran/ChangeLog:

PR fortran/96580
* intrinsics/date_and_time.c (date_and_time): Handle VALUES
argument
for kind=2 and kind=16 (if available).

gcc/testsuite/ChangeLog:

PR fortran/96580
* gfortran.dg/date_and_time_2.f90: New test.
* gfortran.dg/date_and_time_3.f90: New test.
* gfortran.dg/date_and_time_4.f90: New test.

[Bug tree-optimization/113072] `(a ^ CST0) & (~a ^ CST0)` is not optimized to 0 at the gimple level

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

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

--- Comment #4 from Andrew Pinski  ---
Note this applies to `|` instead of `&` too:
```
int foo1(int a, int b)
{
return  (a ^ 4) | (~a ^ 4);
}
```
This should be optimized to `-1`. Though this does NOT get optimized to `-1` on
the RTL level ...

[Bug fortran/96584] f2018 changes to get_command

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-12-18
 CC||anlauf at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

[Bug fortran/96585] Fortran 2018 changes to get_command_argument

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-12-18
 CC||anlauf at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

[Bug target/113040] [14 Regression] libmvec test failures

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||andre.simoesdiasvieira@arm.
   ||com

--- Comment #3 from H.J. Lu  ---
It is caused by r14-5057-gea4a3d08f11a59

[Bug c++/113064] assignement from temporary sometimes invokes copy-assign instead of move-assign operator

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Doesn't look like a regression.

[Bug target/112816] [11/12 Regression] ICE unrecognizable_insn with __builtin_signbit and returning struct with int[4]

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

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

--- Comment #16 from Jakub Jelinek  ---
Created attachment 56903
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56903&action=edit
gcc14-pr112816-3.patch

Ah, forgot some expanders in mmx.md.

[Bug target/113033] GCC 14 (20231203 snapshot) ICE when building LSX vector rotate code on LoongArch

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

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

Xi Ruoyao  changed:

   What|Removed |Added

  Component|middle-end  |target

--- Comment #8 from Xi Ruoyao  ---
(In reply to Xi Ruoyao from comment #2)
> It looks like we are missing a force_reg () somewhere.

Per Jakub's review my first gut feeling seems actually correct...

[Bug target/113033] GCC 14 (20231203 snapshot) ICE when building LSX vector rotate code on LoongArch

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

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

--- Comment #9 from Xi Ruoyao  ---
diff --git a/gcc/config/loongarch/loongarch.cc
b/gcc/config/loongarch/loongarch.cc
index 256fa7d048d..65a2915329e 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -10770,7 +10770,7 @@ loongarch_expand_vector_init_same (rtx target, rtx
vals, unsigned nvar)
  gcc_unreachable ();
}
 }
-  temp = gen_reg_rtx (imode);
+
   if (imode == GET_MODE (same))
 temp2 = same;
   else if (GET_MODE_SIZE (imode) >= UNITS_PER_WORD)
@@ -10795,7 +10795,8 @@ loongarch_expand_vector_init_same (rtx target, rtx
vals, unsigned nvar)
   else
temp2 = lowpart_subreg (imode, same, GET_MODE (same));
 }
-  emit_move_insn (temp, temp2);
+
+  temp = force_reg (imode, temp2);

   switch (vmode)
 {

I mistakenly thought force_reg is just creating an reg and moving into it (if
the operand is not already in reg) but I was wrong.

[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy

[terra at gnome dot org via Gcc-bugs]

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

--- Comment #46 from M Welinder  ---
Should "-std=c99" imply turning off these optimizations?

Creating calls to, say, strlen is incompatible with the C99 standard and
perhaps better limited to "-std=gnu-something" or an opt-in f-flag.

[Bug c++/113025] Pointer is sometimes assumed to be 16-byte aligned even when there is no such guarantee

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #3 from Xi Ruoyao  ---
(In reply to juki from comment #2)
> Unfortunately alignment of the cast type was not causing this issue.
> 
> I changed all calls that were defined in GCC headers to use __m128i_u or
> __m128d_u types to use those types before unaligned intrinsic.
> 
> For example LOAD_SI128 macro looks like the following:
> 
> #define LOAD_SI128(ptr) \
> ( ((uintptr_t)(ptr) & 15) == 0 ) ? _mm_load_si128((__m128i*)(ptr)) :
> _mm_loadu_si128((__m128i_u*)(ptr))

This won't work if ptr is a __m128i *.  It is allowed to optimize
(uintptr_t)(__m128i *)foo % 15 to 0 because the standard says (__m128i *)foo
invokes undefined behavior when foo is a pointer not aligned to 16-byte
boundary (C23 section 6.3.2.3p6).

[Bug c++/113025] Pointer is sometimes assumed to be 16-byte aligned even when there is no such guarantee

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

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

--- Comment #4 from Xi Ruoyao  ---
(In reply to Xi Ruoyao from comment #3)
> (In reply to juki from comment #2)
> > Unfortunately alignment of the cast type was not causing this issue.
> > 
> > I changed all calls that were defined in GCC headers to use __m128i_u or
> > __m128d_u types to use those types before unaligned intrinsic.
> > 
> > For example LOAD_SI128 macro looks like the following:
> > 
> > #define LOAD_SI128(ptr) \
> > ( ((uintptr_t)(ptr) & 15) == 0 ) ? _mm_load_si128((__m128i*)(ptr)) :
> > _mm_loadu_si128((__m128i_u*)(ptr))
> 
> This won't work if ptr is a __m128i *.  It is allowed to optimize
> (uintptr_t)(__m128i *)foo % 15 to 0 because the standard says (__m128i *)foo

I mean % 16, not % 15.

> invokes undefined behavior when foo is a pointer not aligned to 16-byte
> boundary (C23 section 6.3.2.3p6).

[Bug target/113073] New: [14] RISC-V: segfault from out of bounds memory access in gcc.dg/torture/pr112736.c

[ewlu at rivosinc dot com via Gcc-bugs]

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

Bug ID: 113073
   Summary: [14] RISC-V: segfault from out of bounds memory access
in gcc.dg/torture/pr112736.c
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ewlu at rivosinc dot com
  Target Milestone: ---

The testcase from pr112736

#include 
#include 

int a, c[3][5];

void __attribute__((noipa))
fn1 (int * __restrict b)
{
  int e;
  for (a = 2; a >= 0; a--)
for (e = 0; e < 4; e++)
  c[a][e] = b[a];
}

int main()
{
  long pgsz = sysconf (_SC_PAGESIZE);
  void *p = mmap (NULL, pgsz * 2, PROT_READ|PROT_WRITE,
  MAP_ANONYMOUS|MAP_PRIVATE, 0, 0);
  if (p == MAP_FAILED)
return 0;
  mprotect (p, pgsz, PROT_NONE);
  fn1 (p + pgsz);
  return 0;
}

generates out of bound memory access on linux vector targets 

Program received signal SIGSEGV, Segmentation fault.
0x0001067c in fn1 (b=b@entry=0x2b4be000) at
../gcc/gcc/testsuite/gcc.dg/torture/pr112736.c:14
14c[a][e] = b[a];
(gdb) disass fn1
Dump of assembler code for function fn1:
   0x0001066c <+0>: addia1,a0,-4
   0x00010670 <+4>: vsetivlizero,4,e32,m1,ta,ma
   0x00010674 <+8>: addia5,gp,-1968
   0x00010678 <+12>:addia2,a0,-12
=> 0x0001067c <+16>:vle32.v v1,(a1)
   0x00010680 <+20>:vrgather.vi v2,v1,3
   0x00010684 <+24>:li  a7,-1
   0x00010686 <+26>:addia3,a5,40
   0x0001068a <+30>:addia0,a0,-8
   0x0001068c <+32>:addia4,a5,20
   0x00010690 <+36>:vle32.v v3,(a2)
   0x00010694 <+40>:vrgather.vi v1,v3,3
   0x00010698 <+44>:vse32.v v2,(a3)
   0x0001069c <+48>:vse32.v v1,(a5)
   0x000106a0 <+52>:vle32.v v2,(a0)
   0x000106a4 <+56>:sw  a7,-1984(gp)
   0x000106a8 <+60>:vrgather.vi v1,v2,3
   0x000106ac <+64>:vse32.v v1,(a4)
   0x000106b0 <+68>:ret
End of assembler dump.
(gdb) p /x $a1
$8 = 0x2b4bdffc
(gdb) p /x *$a1
Cannot access memory at address 0x2b4bdffc

first appeared: https://github.com/patrick-rivos/gcc-postcommit-ci/issues/282

compile command: ./build-gcc-linux-stage2/gcc/xgcc
-B./build-gcc-linux-stage2/gcc/ ../gcc/gcc/testsuite/gcc.dg/torture/pr112736.c
-march=rv64gcv -mabi=lp64d -mcmodel=medlow -fdiagnostics-plain-output -O3 -g
-lm -o ./pr112736.exe

run command:
QEMU_CPU=rv64,vlen=128,v=true,vext_spec=v1.0,Zve32f=true,Zve64f=true
./bin/qemu-riscv64 ./pr112736.exe

[Bug c++/113074] New: requires requires should be SFINAE

[jdapena at igalia dot com via Gcc-bugs]

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

Bug ID: 113074
   Summary: requires requires should be SFINAE
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jdapena at igalia dot com
  Target Milestone: ---

Created attachment 56904
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56904&action=edit
Test case from godbolt

Calling std::to_address in a requires requires function should be SFINAE.
Instead of it, it fails to compile.

This is breaking GCC build of Chromium in
https://chromium.googlesource.com/chromium/src.git/+/refs/tags/122.0.6193.2/mojo/public/cpp/bindings/type_converter.h#98
when the type does not support std::to_address because it fails to find
operator->.

Code is:
template 
  requires requires(const U& obj) {
not std::is_pointer_v;
{ mojo::ConvertTo(std::to_address(obj)) } -> std::same_as;
  }
inline T ConvertTo(const U& obj) {
  return mojo::ConvertTo(std::to_address(obj));
}

The code is designed to only declare ConvertTo in case it can convert from
std::to_address result.

A possible test case is attached. This case fails in Clang with the expected
outcome (it fails to resolve to a valid call).

[Bug c++/113025] Pointer is sometimes assumed to be 16-byte aligned even when there is no such guarantee

[juki at gcc dot mail.kapsi.fi via Gcc-bugs]

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

--- Comment #5 from juki at gcc dot mail.kapsi.fi ---
(In reply to Xi Ruoyao from comment #4)
> (In reply to Xi Ruoyao from comment #3)
> > 
> > This won't work if ptr is a __m128i *.  It is allowed to optimize
> > (uintptr_t)(__m128i *)foo % 15 to 0 because the standard says (__m128i *)foo
> 
> I mean % 16, not % 15.
> 
> > invokes undefined behavior when foo is a pointer not aligned to 16-byte
> > boundary (C23 section 6.3.2.3p6).

ptr on this case is one of the parameter types defined for various memory load
intrinsics of NEON instruction set like vld1q_u8(const uint8_t *ptr) or
vld1q_u16(const uint16_t *ptr). These instructions expect natural alignment of
that type which is why unaligned load is needed for SSE operation to work with
them in general case.

The same macro is used to implement all those different loads that just need to
read 128 bits of memory into a vector. Alignment of ptr is something smaller
than 16 and can be as low as 1 for const uint8_t which it is has been for the
cases that have been crashing for me.

[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy

[david at westcontrol dot com via Gcc-bugs]

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

--- Comment #47 from David Brown  ---
(In reply to M Welinder from comment #46)
> Should "-std=c99" imply turning off these optimizations?
> 
> Creating calls to, say, strlen is incompatible with the C99 standard and
> perhaps better limited to "-std=gnu-something" or an opt-in f-flag.

How is it incompatible with C99 to create calls to library functions?  I can
think of a two possibilities:

1. If the function implementation plays with errno (allowed in 7.5p3), in a way
that is visible to the code.

2. If the function is called with parameters that may invoke undefined
behaviour (such as calling "strlen" without being sure that the parameter
points to a null-terminated string), where such undefined behaviour is not
already present.

If the user writes code that acts like a call to strlen (let's assume the
implementation knows strlen does not change errno), then the compiler can
replace it with a library call.  Similarly, if the user writes a call to
strlen, then the compiler can replace it with inline code.

As long as there is no difference in the observable behaviour, the
transformation is allowed.

Or am I missing something here?

[Bug fortran/96580] F2018 changes to date_and_time intrinsics

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Fixed in gcc-14.

[Bug fortran/85836] [meta-bug] Fortran 2018 support

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85836
Bug 85836 depends on bug 96580, which changed state.

Bug 96580 Summary: F2018 changes to date_and_time intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96580

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug c++/113025] Pointer is sometimes assumed to be 16-byte aligned even when there is no such guarantee

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

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

--- Comment #6 from Xi Ruoyao  ---
Works for me:

#include 
#include 

#define LOAD_SI128(ptr) \
( ((uintptr_t)(ptr) & 15) == 0 ) ? _mm_load_si128((__m128i*)(ptr)) :
_mm_loadu_si128((__m128i*)(ptr))

extern char x[16];
__m128i y;

void
test ()
{
  y = LOAD_SI128 (&x);
}

compiled to:

test:
.LFB532:
.cfi_startproc
movdqu  x(%rip), %xmm0
movaps  %xmm0, y(%rip)
ret
.cfi_endproc

Note that if x is not extern, GCC will generate:

test:
.LFB532:
.cfi_startproc
movdqa  x(%rip), %xmm0
movaps  %xmm0, y(%rip)
ret
.cfi_endproc

but it's legal because GCC places x at 16-byte boundary:

.align 16
.type   x, @object
.size   x, 16
x:
.zero   16

[Bug c++/113025] Pointer is sometimes assumed to be 16-byte aligned even when there is no such guarantee

[juki at gcc dot mail.kapsi.fi via Gcc-bugs]

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

--- Comment #7 from juki at gcc dot mail.kapsi.fi ---
(In reply to Xi Ruoyao from comment #6)
> Works for me:

I also have plenty of code where this works just fine and still some locations
where it does not. And there are optimization level requirements (-O3 -NDEBUG)
for that to happen as well or GCC will generate correct code in the places I
have seen those issues.

Like I mentioned earlier, creating a small test case to replicate this has been
something that I haven't been able to do yet. I think there are some special
circumstances necessary for wrong instruction to be generated.

I have caught this with gdb quite nicely in my test cases, debug information
points to this load operation being used there. Assembly at that position shows
movdqa instruction being used while movdqu should have been and removing
possibility to use movdqa fixes all failures for all tested compilers.

So it can fail and failure is tied to that alignment comparison. Somehow.

[Bug target/112918] [m68k] [LRA] ICE: maximum number of generated reload insns per insn achieved (90)

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

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

--- Comment #13 from GCC Commits  ---
The master branch has been updated by Vladimir Makarov :

https://gcc.gnu.org/g:989e67f827b74b76e58abe137ce12d948af2290c

commit r14-6667-g989e67f827b74b76e58abe137ce12d948af2290c
Author: Vladimir N. Makarov 
Date:   Mon Dec 18 17:12:23 2023 -0500

[PR112918][LRA]: Fixing IRA ICE on m68k

Some GCC tests on m68K port of LRA is failed on `maximum number of
generated reload insns per insn achieved`.  The problem is in that for
subreg reload LRA can not narrow reg class more from ALL_REGS to
GENERAL_REGS and then to data regs or address regs.  The patch permits
narowing reg class from reload insns if this results in succesful
matching of reg operand.

gcc/ChangeLog:

PR rtl-optimization/112918
* lra-constraints.cc (SMALL_REGISTER_CLASS_P): Move before
in_class_p.
(in_class_p): Restrict condition for narrowing class in case of
allow_all_reload_class_changes_p.
(process_alt_operands): Pass true for
allow_all_reload_class_changes_p in calls of in_class_p.
(curr_insn_transform): Ditto for reg operand win.

[Bug c++/113075] New: Inconsistent/wrong diagnostic when incorrectly taking address of single/overloaded

[waffl3x at protonmail dot com via Gcc-bugs]

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

Bug ID: 113075
   Summary: Inconsistent/wrong diagnostic when incorrectly taking
address of single/overloaded
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: waffl3x at protonmail dot com
  Target Milestone: ---

I am including all 3 bugs in a single report as they are similar and
located in the same region of code.

```
struct S {
  void f() {}

  void g() {}
  void g(int) {}

  void test() {
void (S::*fp)() = &f;
void (S::*gp)() = &g;
  }
};
```

: In member function 'void S::test()':
:29:24: error: ISO C++ forbids taking the address of an unqualified or
parenthesized non-static member function to form a pointer to member function. 
Say '&S::f' [-fpermissive]
   29 | void (S::*fp)() = &f;
  |^
:30:24: error: assuming pointer to member 'void S::g()' [-fpermissive]
   30 | void (S::*gp)() = &g;
  |^
:30:24: note: (a pointer to member can only be formed with '&S::g')

The error message between the overloaded case and the single case is
largely different. Perhaps there is a reason why it should be different
but this is kind of confusing in my opinion.


```
struct S {
  void f() {}

  void g() {}
  void g(int) {}
};

int main()
{
  S s{};
  void (S::*fp)() = &s.f;
  void (S::*gp)() = &s.g;
}
```

: In function 'int main()':
:32:24: error: ISO C++ forbids taking the address of a bound member
function to form a pointer to member function.  Say '&S::f' [-fpermissive]
   32 |   void (S::*fp)() = &s.f;
  |  ~~^
:33:24: error: assuming pointer to member 'void S::g()' [-fpermissive]
   33 |   void (S::*gp)() = &s.g;
  |^
:33:24: note: (a pointer to member can only be formed with '&S::g')

The single function case has a slightly different message, while the
overloaded case has an identical message. This appears to be due to a
lack of context in resolve_address_of_overloaded_function where the
errors are emitted in the overloaded case.

```
struct B {
  void f() {}

  void g() {}
  void g(int) {}
};

struct D : B {
  void test() {
void (D::*fp)() = &f;
void (D::*gp)() = &g;
  }
};
```

: In member function 'void D::test()':
:10:24: error: ISO C++ forbids taking the address of an unqualified or
parenthesized non-static member function to form a pointer to member function. 
Say '&D::f' [-fpermissive]
   10 | void (D::*fp)() = &f;
  |^
:11:24: error: assuming pointer to member 'void B::g()' [-fpermissive]
   11 | void (D::*gp)() = &g;
  |^
:11:24: note: (a pointer to member can only be formed with '&B::g')

The single function case properly suggests &D::f but the overload case
suggests &B::g instead.

All 3 bugs are super mild, and I don't know how feasible they are to
fix, but at the very least it's worth tracking them in my opinion.

[Bug libstdc++/113074] requires requires should be SFINAE

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

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

--- Comment #1 from Andrew Pinski  ---
Oh
https://cplusplus.github.io/LWG/issue3545

[Bug libstdc++/113074] requires requires should be SFINAE

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> Oh
> https://cplusplus.github.io/LWG/issue3545

Whoops wrong one.

[Bug libstdc++/113074] requires requires should be SFINAE

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

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

--- Comment #3 from Andrew Pinski  ---
https://eel.is/c++draft/memory#pointer.conversion


As far as I can tell, std::to_address is not required to be SFINAE safe ...

The standard just says:
```
Returns: pointer_traits​::​to_address(p) if that expression is well-formed
(see [pointer.traits.optmem]), otherwise to_address(p.operator->()).
```

[Bug libstdc++/113068] : ranges::to() | ranges::to() is not a range adaptor

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:4f54e656788be3268dd45eb036447464a937fae9

commit r14-6668-g4f54e656788be3268dd45eb036447464a937fae9
Author: Patrick Palka 
Date:   Mon Dec 18 18:05:36 2023 -0500

libstdc++: Make ranges::to closure objects SFINAE-friendly [PR112802]

This also happens to fix composition of these closure objects.

PR libstdc++/112802
PR libstdc++/113068

libstdc++-v3/ChangeLog:

* include/std/ranges (__detail::_To::operator()): Add constraints.
(__detail::_To2::operator()): Likewise.
* testsuite/std/ranges/conv/1.cc (test_sfinae): New test.
(test_composition): New test.

[Bug libstdc++/112802] : _ToClosure::operator() has no constraints

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:4f54e656788be3268dd45eb036447464a937fae9

commit r14-6668-g4f54e656788be3268dd45eb036447464a937fae9
Author: Patrick Palka 
Date:   Mon Dec 18 18:05:36 2023 -0500

libstdc++: Make ranges::to closure objects SFINAE-friendly [PR112802]

This also happens to fix composition of these closure objects.

PR libstdc++/112802
PR libstdc++/113068

libstdc++-v3/ChangeLog:

* include/std/ranges (__detail::_To::operator()): Add constraints.
(__detail::_To2::operator()): Likewise.
* testsuite/std/ranges/conv/1.cc (test_sfinae): New test.
(test_composition): New test.