[Bug ipa/96505] attribute access effect lost after inlining

2024-09-20 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96505

--- Comment #2 from Sam James  ---
(In reply to Sam James from comment #1)
> f1 is diagnosed since GCC 12...

since r12-6606-g9d6a0f388eb048f8d87f47af78f07b5ce513bfe6, which changed
gimple-ssa-warn-access to run a few more times...

[Bug rtl-optimization/48037] Missed optimization: unnecessary register moves

2024-09-20 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48037

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=92645
 Status|NEW |RESOLVED
   Target Milestone|--- |11.0

--- Comment #12 from Andrew Pinski  ---
Fixed in GCC 11.

[Bug ipa/100717] missing warning for a call to a function with attribute access inlined into caller

2024-09-20 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100717

--- Comment #1 from Sam James  ---
This seems to work now, presumably the same as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96505#c2.

[Bug tree-optimization/116795] New: ICE on valid code at -O3 on x86_64-linux-gnu: verify_ssa failed

2024-09-20 Thread zhendong.su at inf dot ethz.ch via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116795

Bug ID: 116795
   Summary: ICE on valid code at -O3 on x86_64-linux-gnu:
verify_ssa failed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a recent regression as it doesn't reproduce with 14.2 and
earlier. 

Compiler Explorer: https://godbolt.org/z/z17zjxs7K


[520] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240921 (experimental) (GCC) 
[521] % 
[521] % gcctk -O3 small.c
small.c: In function ‘main’:
small.c:3:5: error: definition in block 10 does not dominate use in block 8
3 | int main() {
  | ^~~~
for SSA_NAME: _5 in statement:
e_12 = .SAT_SUB (1, _5);
during GIMPLE pass: widening_mul
small.c:3:5: internal compiler error: verify_ssa failed
0x25b5ae5 internal_error(char const*, ...)
../../gcc-trunk/gcc/diagnostic-global-context.cc:517
0x144b18e verify_ssa(bool, bool)
../../gcc-trunk/gcc/tree-ssa.cc:1203
0x1074c05 execute_function_todo
../../gcc-trunk/gcc/passes.cc:2108
0x10754ae execute_todo
../../gcc-trunk/gcc/passes.cc:2155
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.
[522] % 
[522] % cat small.c
volatile int a, b;
int c;
int main() {
  unsigned e = 0;
  for (; e < 2; e++) {
a && b;
if (c)
  e = -(c ^ e);
  }
  return 0;
}

[Bug tree-optimization/116796] New: ICE on valid code at -O3 with "-fno-tree-dominator-opts -fno-tree-vrp -fno-tree-ch" on x86_64-linux-gnu: in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:647

2024-09-20 Thread zhendong.su at inf dot ethz.ch via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116796

Bug ID: 116796
   Summary: ICE on valid code at -O3 with
"-fno-tree-dominator-opts -fno-tree-vrp -fno-tree-ch"
on x86_64-linux-gnu: in check_loop_closed_ssa_def, at
tree-ssa-loop-manip.cc:647
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a recent regression (it doesn't reproduce with 14.2 and
earlier).

Compiler Explorer: https://godbolt.org/z/seGdoYGYq

[541] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240921 (experimental) (GCC) 
[542] % 
[542] % gcctk -O3 -c small.c
[543] % gcctk -O3 -c -fno-tree-dominator-opts -fno-tree-vrp -fno-tree-ch
small.c
during GIMPLE pass: cunroll
small.c: In function ‘main’:
small.c:4:5: internal compiler error: in check_loop_closed_ssa_def, at
tree-ssa-loop-manip.cc:647
4 | int main() {
  | ^~~~
0x25b5ae5 internal_error(char const*, ...)
../../gcc-trunk/gcc/diagnostic-global-context.cc:517
0xa6f6e0 fancy_abort(char const*, int, char const*)
../../gcc-trunk/gcc/diagnostic.cc:1512
0x8bebeb check_loop_closed_ssa_def
../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:647
0x1356e54 check_loop_closed_ssa_bb
../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:661
0x1358a3e verify_loop_closed_ssa(bool, loop*)
../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:697
0x1358a3e verify_loop_closed_ssa(bool, loop*)
../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:681
0x133f441 tree_unroll_loops_completely
../../gcc-trunk/gcc/tree-ssa-loop-ivcanon.cc:1576
0x133f4c3 execute
../../gcc-trunk/gcc/tree-ssa-loop-ivcanon.cc:1680
0x133f4c3 execute
../../gcc-trunk/gcc/tree-ssa-loop-ivcanon.cc:1670
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.
[544] % 
[544] % cat small.c
volatile int a;
extern void b();
int c;
int main() {
 L1:
  if (c) {
int f;
  L2:
for (f = 0; f < 6; f++) {
  b();
  if (f)
goto L2;
  a;
}
  }
  if (c)
goto L1;
  return 0;
}

[Bug c++/97383] Consider special casing diagnostics for C++20 customization point objects

2024-09-20 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97383

--- Comment #1 from Andrew Pinski  ---
Note clang is worse than GCC here:
clang with libc++ does:
:8:3: error: no matching function for call to object of type 'const
__sort'


With libstdc++ clang does:
:8:3: error: no matching function for call to object of type 'const
__sort_fn'


So at least GCC displays the full qualified name. clang does not.

[Bug tree-optimization/116791] [15 Regression] ICE in operator[], at vec.h:910 since r15-3735-g664e0ce580a8f2

2024-09-20 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116791

--- Comment #7 from Sam James  ---
libjxl as well.

[Bug tree-optimization/116796] [15 regression] ICE on valid code at -O3 with "-fno-tree-dominator-opts -fno-tree-vrp -fno-tree-ch" on x86_64-linux-gnu: in check_loop_closed_ssa_def, at tree-ssa-loop-m

2024-09-20 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116796

Sam James  changed:

   What|Removed |Added

   Last reconfirmed||2024-09-21
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug tree-optimization/116795] [15 regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_ssa failed

2024-09-20 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116795

Sam James  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-09-21
 Status|UNCONFIRMED |NEW

[Bug tree-optimization/116795] [15 regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_ssa failed

2024-09-20 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116795

Sam James  changed:

   What|Removed |Added

Version|unknown |15.0
   Target Milestone|--- |15.0

[Bug tree-optimization/116796] [15 regression] ICE on valid code at -O3 with "-fno-tree-dominator-opts -fno-tree-vrp -fno-tree-ch" on x86_64-linux-gnu: in check_loop_closed_ssa_def, at tree-ssa-loop-m

2024-09-20 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116796

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
Version|unknown |15.0

[Bug other/116792] RFE: should we be able to generate diagnostics in HTML format?

2024-09-20 Thread xry111 at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116792

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #4 from Xi Ruoyao  ---
FWIW to display GCC diagnostics on a website I use -fdiagnostics-color=always
and render the output using https://github.com/drudru/ansi_up.

[Bug target/115673] [15 regression] gcc.target/i386/force-indirect-call-2.c test failure

2024-09-20 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115673

Sam James  changed:

   What|Removed |Added

   Last reconfirmed|2024-06-27 00:00:00 |2024-9-21

--- Comment #8 from Sam James  ---
I'm still seeing this, but I think it's an actual bug, not a testism.

[Bug target/55212] [SH] Switch to LRA

2024-09-20 Thread kkojima at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #283 from Kazumoto Kojima  ---
(In reply to Kazumoto Kojima from comment #276)
> Current my assumption on the sfunc issue: LRA doesn't handle the clobber
> hard reg pattern if that hard reg is recognized as the input reg.  I don't
> know the direct way to give the output modifier to the raw hard reg pattern.
> I'm trying match_operand instead of raw reg so to modify it to the output. 
> For example, rewriting block_lump_real_i4 to
> 
> (define_insn "block_lump_real_i4"
>   [(parallel [(set (mem:BLK (match_operand:SI 2 "" "r,r"))
>  (mem:BLK (match_operand:SI 3 "" "r,r")))
> (use (match_operand:SI 0 "arith_reg_operand" "r,r"))
> (use (match_operand 1 "" "Z,Ccl"))
> (use (match_operand:SI 4 "" "r,r"))
> (clobber (match_scratch:SI 5 "=2,2"))
> (clobber (match_scratch:SI 6 "=3,3"))

It turned out that the c#276 version of block_lump_real_i4 works correctly in
only the limited cases.

[Bug c++/116775] C++20 Coroutine await_suspend is unexpectedly executed when using in __builtin_constant_p

2024-09-20 Thread arsen at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116775

Arsen Arsenović  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-09-20
 Status|UNCONFIRMED |NEW
 CC||arsen at gcc dot gnu.org

--- Comment #2 from Arsen Arsenović  ---
indeed, this happens because the processing of constant_p happens after we
split the coroutine up, it'd seem, so we get this:

  if (<>)
{
  <;
  if (<::operator
std::__n4861::coroutine_handle (&_Coro_self_handle)>)>>)
{
  <;
}
  switch (<>)
{
  case 0:;
  <;
  case 1:;
  goto resume.4;
  default:;
  goto destroy.4;
}
  destroy.4:;
  goto coro.delete.promise;
}
  resume.4:;
  <;

... that last line is supposed to be an await_resume call, but it got folded to
zero (because it's not a constant, and the coroutine code generated
__builtin_constant_p (Aw0.await_resume ()).

confirmed

[Bug c++/116775] C++20 Coroutine await_suspend is unexpectedly executed when using in __builtin_constant_p

2024-09-20 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116775

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
So, likely the coroutine lowering shouldn't walk into __builtin_constant_p
TREE_SIDE_EFFECTS argument subtrees at all, keep those as is and leave them to
be removed later.

[Bug target/113953] Finish LRA transition for s390 by removing -mlra

2024-09-20 Thread stefansf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113953

--- Comment #5 from Stefan Schulze Frielinghaus  
---
(In reply to Segher Boessenkool from comment #4)
> Heh, I thought you forgot the manual, but -mlra apparently never was
> mentioned
> in there anyway :-)

Uff you almost had me there, i.e., if it had been documented I
might/probably/maybe have missed it ;-)  Thanks for double checking!

[Bug target/55212] [SH] Switch to LRA

2024-09-20 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #291 from Andrew Pinski  ---
(In reply to Kazumoto Kojima from comment #285)
> (In reply to Oleg Endo from comment #284)
> > (In reply to Kazumoto Kojima from comment #283)
> ...
> > > It turned out that the c#276 version of block_lump_real_i4 works correctly
> > > in only the limited cases.
> > 
> > Have you tried writing the pattern as 
> > 
> > (define_insn "block_lump_real_i4"
> >   [(set (mem:BLK (match_operand:SI 2 "" "r,r"))
> >(mem:BLK (match_operand:SI 3 "" "r,r")))
> >(use (match_operand:SI 0 "arith_reg_operand" "r,r"))
> >(use (match_operand 1 "" "Z,Ccl"))
> >...
> > 
> > i.e. without the parallel in there?  Sorry, maybe it's a stupid idea but ...
> 
> The last time I tried it against slightly different patterns, there was no
> difference. I'll try it again.


One of the explicit parallel issue was fixed with my commit
g:da33ad53bcb57943fa671c745938a53f4de89a1b 
But there could be more hiding.

[Bug target/55212] [SH] Switch to LRA

2024-09-20 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #292 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #289)
> I've reconstructed patches as follows:
> 
> [59157] a revised patch to movsf issue which splits movesf_ie_ra
> [59158] a revised patch to QIHI extend/move
> [59159] a revised workaround sfunc issue
> [59153] Alex's patch works magically for call_pcrel* issue.
> 
> I've also created sh-lra-take2 branch of https://github.com/kazkojima/gcc.git
> with these patches for the reference.

OK, I'm trying this branch now. I assume I won't need any other patches.

[Bug tree-optimization/116583] vectorizable_slp_permutation cannot handle even/odd extract from VLA vector

2024-09-20 Thread tnfchris at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116583

--- Comment #3 from Tamar Christina  ---
(In reply to Richard Biener from comment #2)
> Another example this shows is for gcc.dg/vect/slp-42.c - we definitely can
> do the interleaving scheme as non-SLP vectorization shows.
> 
> gcc.dg/vect/slp-42.c also shows we're not yet "lowering" all SLP load
> permutes.
> The original SLP attempt still has
> 
>node 0x45d5050 (max_nunits=4, refcnt=2) vector([4,4]) int
>op template: _2 = q[_1];
> stmt 0 _2 = q[_1];
> stmt 1 _8 = q[_7];
> stmt 2 _14 = q[_13];
> stmt 3 _20 = q[_19];
> load permutation { 0 1 2 3 }
>node 0x45d50e8 (max_nunits=4, refcnt=2) vector([4,4]) int
>op template: _4 = q[_3];
> stmt 0 _4 = q[_3];
> stmt 1 _10 = q[_9];
> stmt 2 _16 = q[_15];
> stmt 3 _22 = q[_21];
> load permutation { 4 5 6 7 }
> 
> instead of a single contiguous load and two VEC_PERM_EXPR nodes to extract
> the lo/hi parts (which is also extract even/odd, but with a larger mode
> encompassing 4 elements).
> 
> I'd say for VLA operation this is one of the major blockers for all-SLP.

I'll take a look if Richard hasn't yet once I finish early break transition :)
.

[Bug tree-optimization/116785] [15 Regression] RAJAPerf REDUCE_SUM regresses with r15-792-gf0a02467bbc35a

2024-09-20 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116785

--- Comment #9 from Richard Biener  ---
Note r15-792-gf0a02467bbc35a is a fix for correctness.

I'm waiting for a better reduction - I'd suggest you reduce the function
with the kernel itself manually and use creduce only to reduce the
rest of the file.

[Bug target/116787] New: [14/15 Regression] No longer recognizes vector maxps

2024-09-20 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116787

Bug ID: 116787
   Summary: [14/15 Regression] No longer recognizes vector maxps
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

typedef float v4sf __attribute__((vector_size (sizeof (4 * sizeof (float);

v4sf
foo (v4sf x, v4sf y)
{
  return x < y ? y : x;
}

is no longer generating

_Z3fooDv2_fS_:
.LFB0:
.cfi_startproc
maxps   %xmm0, %xmm1
movaps  %xmm1, %xmm0
ret

with -O2, neither with -O2 -msse4.2

[Bug libstdc++/116777] error: 'current_zone' is not a member of 'std::chrono' with -D_GLIBCXX_USE_CXX11_ABI=0

2024-09-20 Thread vital.had at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116777

--- Comment #4 from Sergey Fedorov  ---
(In reply to Jonathan Wakely from comment #2)
> I was going to say that libfmt upstream is wrong to say it's a regression,
> but it looks like they never claimed that.

Maybe I misread it, but:
https://github.com/fmtlib/fmt/issues/4160#issuecomment-2350140965

> You're using -D_GLIBCXX_USE_CXX11_ABI=0 which means time zones are not
> supported. They have never been supported with -D_GLIBCXX_USE_CXX11_ABI=0 
> so not a regression.

Sorry, I was not aware of that. Normally everything works with either ABI.

[Bug target/55212] [SH] Switch to LRA

2024-09-20 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #290 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #263)
> Created attachment 59132 [details]
> a patch rewriting movsh_ie_ra
> 
> This patch splits movsf_ie_ra into several new patterns to remove
> match_scratch.  Also define a new sub-pattern of movdf for constant loads.
> 
> * gcc/config/sh/predicates.md (pc_relative_load_operand):
> New predicate.
> * gcc/config/sh/sh-protos.h (sh_movsf_ie_ra_split_p): Remove.
> (sh_movsf_ie_y_split_p): New proto.
> * gcc/config/sh/sh.cc: (sh_movsf_ie_ra_split_p): Remove.
> (sh_movsf_ie_y_split_p): New function.
> * gcc/config/sh/sh.md (movdf_i4_F_z): New insn pattern.
> (movdf): Use it.
> (movsf_ie_ra): Use define_insn instead of define_insn_and_split.
> (movsf_ie_F_z): Rename from movsf_ie_const_ra.
> (movsf_ie_Q_z, movsf_ie_y): New insn pattern.
> (movsf): Use new patterns.
> (movdf_i4_F_z+7): New splitter.
> 
> With it, now "make check-gcc" has no new ICEs with unix/-m4/-mlra when
> comparing unix/-m4.

I have added this patch on top of the other patches and got an ICE when
bootstrapping Ada natively:

a-ngcefu.adb: In function 'Ada.Numerics.Complex_Elementary_Functions.Arccos':
a-ngcefu.adb:177:8: error: unable to find a register to spill
a-ngcefu.adb:177:8: error: this is the insn:
(insn 105 605 587 10 (parallel [
(set (reg:SF 449 [orig:184 _24 ] [184])
(reg:SF 463))
(use (reg:SI 154 fpscr0))
]) "a-ngcefu.adb":164:17 222 {movsf_ie_ra}
 (expr_list:REG_DEAD (reg:SF 463)
(nil)))
during RTL pass: reload

[Bug driver/116788] New: Relative sysroot and -save-temps don't play nicely

2024-09-20 Thread w.steinwender at freenet dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116788

Bug ID: 116788
   Summary: Relative sysroot and -save-temps don't play nicely
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: w.steinwender at freenet dot de
  Target Milestone: ---

GCC is configured with:
--prefix=/root/crossdev --sysroot=/root/crossdev/sysroot

--sysroot:
If the specified directory is a subdirectory of ${exec_prefix}, then it will be
found relative to the GCC binaries if the installation tree is moved.

Normal compilation with moved installation tree works. gcc --print-sysroot for
example:
/home/foo/crossdev/bin/../sysroot

But compilation with -save-temps on a system with /root directory mode 700
fails:
cc1: error: /root/crossdev/sysroot/usr/local/include: Permission denied
cc1: error: /root/crossdev/sysroot/usr/include: Permission denied

It seems that with -save-temps files are searched outside sysroot.

More information: cc1 -v 
cc1: error: /root/crossdev/lib/gcc/arm-none-linux-gnueabi/14.2.0/include:
Permission denied
cc1: error: /root/crossdev/sysroot/usr/local/include: Permission denied
cc1: error: /root/crossdev/lib/gcc/arm-none-linux-gnueabi/14.2.0/include-fixed:
Permission denied
cc1: error: /root/crossdev/arm-none-linux-gnueabi/include: Permission denied
cc1: error: /root/crossdev/sysroot/usr/include: Permission denied

Is it possible that with -save-temps relative sysroot is not communicated to
cc1?
But explicitly setting --sysroot for compilation doesn't help either.

This is somehow similar to:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54560

GCC configuration:
Configured with: ../gcc/configure --target=arm-none-linux-gnueabi
--prefix=/root/crossdev --with-sysroot=/root/crossdev/sysroot
--with-build-sysroot=/root/crossdev/sysroot --enable-threads
--enable-languages=c,c++ --enable-__cxa_atexit --disable-libstdcxx-pch
--disable-lto --disable-nls --with-arch=armv5te --with-float=soft
--enable-shared --disable-multilib

Same problem with gcc 13.2.

[Bug rtl-optimization/116783] [14/15 Regression] Wrong code at -O2 with late pair fusion pass (wrong alias analysis)

2024-09-20 Thread acoplan at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116783

Alex Coplan  changed:

   What|Removed |Added

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

--- Comment #3 from Alex Coplan  ---
Ah, right, thanks both for the input.  In that case, it sounds like we need to
be more conservative around calls to RTL alias analysis in pair-fusion.cc. 
Mine, then.

[Bug libstdc++/114742] invalid use of '__ieee128' in and

2024-09-20 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114742

--- Comment #7 from Jonathan Wakely  ---
OK, then ALT128_COMPAT is effectively only for LE.

So I think I'll make whatever change is needed so that ALT128_COMPAT isn't
defined for power6 LE and power7 LE, so the errors Matthias found don't happen.
But I won't spend time trying to actually make it work well on the unsupported
power6 LE combo.

[Bug tree-optimization/116583] vectorizable_slp_permutation cannot handle even/odd extract from VLA vector

2024-09-20 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116583

--- Comment #4 from Richard Biener  ---
So the key to notice here is the regular interleaving knows there's enough
vectors to perform two-vector to one permutes within the same group and
we only have a single child for the VEC_PERM_EXPR which for the permute
in question effectively means we have to take "two" VLA vectors.

The non-SLP interleaving scheme for this performs multiple VLA loads while
we'd have a contiguous load node that we'd permute later on but we're usually
not emitting multiple loads(?).  For gcc.dg/vect/slp-42.c we do end up
(after re-analyzing with single-lane SLP) with store-lanes for the 4 element
store but SVE doesn't support 8 element load-lanes (we could use 4 element
load lanes with u64 elements - missing feature).

I do think the VLA interleaving scheme we produce is quite inefficient
(and the cost modeling agrees and would choose V4SI fixed-size regs).

[Bug target/115372] [15 Regression] RISCV pr97428.c scan-tree-dump-times after r15-812-gc71886f2ca2

2024-09-20 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115372

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-09-20
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=116583
 CC||rsandifo at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #4 from Richard Biener  ---
I'm quite sure we didn't use SLP before r15-812-gc71886f2ca2 but the dump scan
was changed from expecting 1 instead of 2 times "vectorizing stmts using SLP".

We do end up vectorizing gcc.dg/vect/pr97428.c with load/store-lanes but
somehow
fail to see that store-lanes is valid with SLP and the 16 lane store.

We're using vec_mask_len_load_lanes for the loads when
not using SLP but as well fail to find an array mode for RVVM1DF[16] and
use classical pow2 store interleaving (it generates awkward code).  We
try with the same store interleaving scheme for SLP but fail to handle the

   node 0x5a92170 (max_nunits=1, refcnt=1) vector([2,2]) double
   op: VEC_PERM_EXPR
{ }
lane permutation { 0[0] 1[0] }
children 0x5a91168 0x5a90f08
   node 0x5a91168 (max_nunits=2, refcnt=3) vector([2,2]) double

permutes on the store side - see PR116583 for a similar issue on the load
side though this (interleave even/odd) should be possibly easier to handle?



Btw, the gcc.target/riscv/rvv/autovec/struct/struct_vect-?.c tests are
just very fragile because they have -funroll-all-loops.  Currently I see
the following for rv64gcv on linux:

FAIL: gcc.target/riscv/rvv/autovec/struct/struct_vect-1.c scan-assembler-times
vsseg4e8\\.v 4
FAIL: gcc.target/riscv/rvv/autovec/struct/struct_vect-2.c scan-assembler-times
vsseg4e16\\.v 4
FAIL: gcc.target/riscv/rvv/autovec/struct/struct_vect-2.c scan-assembler-times
vsseg7e16\\.v 2
FAIL: gcc.target/riscv/rvv/autovec/struct/struct_vect-3.c scan-assembler-times
vsseg4e32\\.v 4
FAIL: gcc.target/riscv/rvv/autovec/struct/struct_vect-4.c scan-assembler-times
vsseg3e64\\.v 8
FAIL: gcc.target/riscv/rvv/autovec/struct/struct_vect-4.c scan-assembler-times
vsseg4e64\\.v 4
FAIL: gcc.target/riscv/rvv/autovec/struct/struct_vect-4.c scan-assembler-times
vsseg5e64\\.v 4
FAIL: gcc.target/riscv/rvv/autovec/struct/struct_vect-4.c scan-assembler-times
vsseg7e64\\.v 4
FAIL: gcc.target/riscv/rvv/autovec/struct/struct_vect-5.c scan-assembler-times
vsseg4e32\\.v 4

[Bug target/116738] Constant folding of _mm_min_ss and _mm_max_ss is wrong

2024-09-20 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738

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

https://gcc.gnu.org/g:624d3af025e820ede7ec4334f7a2d5d4731c99a9

commit r15-3728-g624d3af025e820ede7ec4334f7a2d5d4731c99a9
Author: Jakub Jelinek 
Date:   Fri Sep 20 09:14:29 2024 +0200

i386: Fix up _mm_min_ss etc. handling of zeros and NaNs [PR116738]

min/max patterns for intrinsics which on x86 result in the second
input operand if the two operands are both zeros or one or both of them
are a NaN shouldn't use SMIN/SMAX RTL, because that is similarly to
MIN_EXPR/MAX_EXPR undefined what will be the result in those cases.

The following patch adds an expander which uses either a new pattern with
UNSPEC_IEEE_M{AX,IN} or use the S{MIN,MAX} representation of the same.

2024-09-20  Uros Bizjak  
Jakub Jelinek  

PR target/116738
* config/i386/subst.md (mask_scalar_operand_arg34,
mask_scalar_expand_op3, round_saeonly_scalar_mask_arg3): New
subst attributes.
* config/i386/sse.md
   
(_vm3):
Change from define_insn to define_expand, rename the old
define_insn
to ...
   
(*_vm3):
... this.
   
(_ieee_vm3):
New define_insn.

* gcc.target/i386/sse-pr116738.c: New test.

[Bug target/116787] [14/15 Regression] No longer recognizes vector maxps since r14-2786

2024-09-20 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116787

--- Comment #3 from Richard Biener  ---
Eh - sizeof (4 * sizeof (float)).  So this is about emulated V2SF, it still
regressed though but probably correctly so because of sNaNs?

[Bug target/116787] [14/15 Regression] No longer recognizes vector maxps since r14-2786

2024-09-20 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116787

--- Comment #4 from Richard Biener  ---
That said, it works fine with vector_size (4 * sizeof (float)) aka "real" V4SF.

[Bug target/85919] Incomplete transition to IFNs for scatter/gather support, drop vectorize.builtin_{gather,scatter} target hooks

2024-09-20 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85919

--- Comment #4 from Richard Biener  ---
To summarize the main issue was around the fact that the x86 backend supports
two distinct mask_gather_load differing only in the mode of the _mask_ but

OPTAB_CD(mask_gather_load_optab, "mask_gather_load$a$b")

only has modes for the index and data vector.  I think it's a non-problem
solvable in the vectorizer though, for example by looking at predicates
for the mask operand.

Another complication is that the ISA has V4SF[V4DI] gathers thus mixed size
operation - the vectorizer needs to deal with this by splitting.  Most of
this is implemented for the open-coded path already but the IFN path still
lacks this ability, so does the optab query part.

Scatters are going to be "easier" since at least there's only AVX512 thus
a single kind of mask mode.

[Bug target/116787] [14/15 Regression] No longer recognizes vector maxps

2024-09-20 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116787

--- Comment #1 from Richard Biener  ---
GCC 13 manages

;; Generating RTL for gimple basic block 2

;; _4 = .VCOND (x_2(D), y_3(D), y_3(D), x_2(D), 108);

(insn 7 6 0 (set (reg:V2SF 82 [  ])
(unspec:V2SF [
(reg/v:V2SF 84 [ y ])
(reg/v:V2SF 83 [ x ])
] UNSPEC_IEEE_MAX)) "t.c":6:22 -1
 (nil))

while GCC 14 has

;; _4 = .VCOND (x_2(D), y_3(D), y_3(D), x_2(D), 109);

(insn 7 6 8 (set (reg:V4SF 101)
(vec_concat:V4SF (reg/v:V2SF 100 [ y ])
(const_vector:V2SF [
(const_double:SF 0.0 [0x0.0p+0]) repeated x2
]))) "t.c":6:22 -1
 (nil))

(insn 8 7 9 (set (reg:V4SF 102)
(vec_concat:V4SF (reg/v:V2SF 99 [ x ])
(const_vector:V2SF [
(const_double:SF 0.0 [0x0.0p+0]) repeated x2
]))) "t.c":6:22 -1
 (nil))

(insn 9 8 10 (set (reg:V4SF 104)
(lt:V4SF (reg:V4SF 102)
(reg:V4SF 101))) "t.c":6:22 -1
 (nil))
...

[Bug target/113932] [meta-bug] Targets which should be ported to LRA

2024-09-20 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932

--- Comment #3 from Sam James  ---
(In reply to John Paul Adrian Glaubitz from comment #2)

I agree, dropped. One can see the full dependency graph via BZ anyway.

[Bug target/116787] [14/15 Regression] No longer recognizes vector maxps since r14-2786

2024-09-20 Thread ubizjak at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116787

--- Comment #6 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #0)
> typedef float v4sf __attribute__((vector_size (sizeof (4 * sizeof
> (float);
> 
> v4sf
> foo (v4sf x, v4sf y)
> {
>   return x < y ? y : x;
> }
> 
> is no longer generating
> 
> _Z3fooDv2_fS_:
> .LFB0:
> .cfi_startproc
> maxps   %xmm0, %xmm1
> movaps  %xmm1, %xmm0
> ret
> 
> with -O2, neither with -O2 -msse4.2

It does with -ffast-math.

[Bug target/116782] x86 backend cannot control vectorization of gather and masked gather (and scatter) separately

2024-09-20 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116782

--- Comment #1 from Richard Biener  ---
Note the vectorizer would need to learn how to operate both modes, IFN and
builtin, at the same time - at the moment it makes its life too easy there.

[Bug target/116787] [14/15 Regression] No longer recognizes vector maxps since r14-2786

2024-09-20 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116787

--- Comment #7 from Richard Biener  ---
(In reply to Uroš Bizjak from comment #6)
> (In reply to Richard Biener from comment #0)
> > typedef float v4sf __attribute__((vector_size (sizeof (4 * sizeof
> > (float);
> > 
> > v4sf
> > foo (v4sf x, v4sf y)
> > {
> >   return x < y ? y : x;
> > }
> > 
> > is no longer generating
> > 
> > _Z3fooDv2_fS_:
> > .LFB0:
> > .cfi_startproc
> > maxps   %xmm0, %xmm1
> > movaps  %xmm1, %xmm0
> > ret
> > 
> > with -O2, neither with -O2 -msse4.2
> 
> It does with -ffast-math.

I think the issue is that we pad out the compare RTXen with zeros but
not the RHS when they are equal to the compare operands.  We then later
are not able to combine to maxps.

Something like

diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md
index 9a8d6030d8b..8b846306fd6 100644
--- a/gcc/config/i386/mmx.md
+++ b/gcc/config/i386/mmx.md
@@ -1184,6 +1184,14 @@

   emit_insn (gen_movq_v2sf_to_sse (ops[5], operands[5]));
   emit_insn (gen_movq_v2sf_to_sse (ops[4], operands[4]));
+  if (rtx_equal_p (operands[5], operands[2]))
+ops[2] = ops[5];
+  else if (rtx_equal_p (operands[5], operands[1]))
+ops[1] = ops[5];
+  if (rtx_equal_p (operands[4], operands[1]))
+ops[1] = ops[4];
+  else if (rtx_equal_p (operands[4], operands[2]))
+ops[2] = ops[4];

   bool ok = ix86_expand_fp_vcond (ops);
   gcc_assert (ok);

generates the expected

_Z3fooDv2_fS_:
.LFB0:
.cfi_startproc
movq%xmm0, %xmm0
movq%xmm1, %xmm1
maxps   %xmm0, %xmm1
movaps  %xmm1, %xmm0
ret

[Bug target/113953] Finish LRA transition for s390 by removing -mlra

2024-09-20 Thread segher at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113953

--- Comment #4 from Segher Boessenkool  ---
Heh, I thought you forgot the manual, but -mlra apparently never was mentioned
in there anyway :-)

Thanks for the help pulling GCC kicking and streaming into the 21st century!

[Bug libstdc++/116777] error: 'current_zone' is not a member of 'std::chrono' with -D_GLIBCXX_USE_CXX11_ABI=0

2024-09-20 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116777

--- Comment #5 from Jonathan Wakely  ---
(In reply to Sergey Fedorov from comment #4)
> Maybe I misread it, but:
> https://github.com/fmtlib/fmt/issues/4160#issuecomment-2350140965

But that says bug, not regression.

> Sorry, I was not aware of that. Normally everything works with either ABI.

Not everything. And more and more things will stop working, because we're not
going to keep supporting the dual ABI for every new feature. It's not
sustainable.

Features not supported for the old std::string include:
- std::string members taking const_iterator, allocator propagation (PR 81967)
- std::chrono::tzdb
- 

The list will grow.

[Bug libstdc++/116777] error: 'current_zone' is not a member of 'std::chrono' with -D_GLIBCXX_USE_CXX11_ABI=0

2024-09-20 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116777

--- Comment #6 from Jonathan Wakely  ---
Oh, and constexpr std::string isn't supported either.

[Bug tree-optimization/116583] vectorizable_slp_permutation cannot handle even/odd extract from VLA vector

2024-09-20 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116583

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2024-09-20
 Target||aarch64, riscv
   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||tnfchris at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
Another example this shows is for gcc.dg/vect/slp-42.c - we definitely can
do the interleaving scheme as non-SLP vectorization shows.

gcc.dg/vect/slp-42.c also shows we're not yet "lowering" all SLP load permutes.
The original SLP attempt still has

   node 0x45d5050 (max_nunits=4, refcnt=2) vector([4,4]) int
   op template: _2 = q[_1];
stmt 0 _2 = q[_1];
stmt 1 _8 = q[_7];
stmt 2 _14 = q[_13];
stmt 3 _20 = q[_19];
load permutation { 0 1 2 3 }
   node 0x45d50e8 (max_nunits=4, refcnt=2) vector([4,4]) int
   op template: _4 = q[_3];
stmt 0 _4 = q[_3];
stmt 1 _10 = q[_9];
stmt 2 _16 = q[_15];
stmt 3 _22 = q[_21];
load permutation { 4 5 6 7 }

instead of a single contiguous load and two VEC_PERM_EXPR nodes to extract
the lo/hi parts (which is also extract even/odd, but with a larger mode
encompassing 4 elements).

I'd say for VLA operation this is one of the major blockers for all-SLP.

[Bug libstdc++/114742] invalid use of '__ieee128' in and

2024-09-20 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114742

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
At least glibc on powerpc64 be I think doesn't have any __float128/_Float128
support I think.

[Bug libstdc++/116777] error: 'current_zone' is not a member of 'std::chrono' with -D_GLIBCXX_USE_CXX11_ABI=0

2024-09-20 Thread iains at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116777

--- Comment #7 from Iain Sandoe  ---
as noted in several places; the long-term solution for Darwin (in general since
there's an installed /usr/lib/libstdc++.6.dylib even on modern systems) - is
for use to use an inline namespace for libstdc++ (always).  When that is done,
there's no conflict with the older installed .6.dylib s.  This work is not
finished yet, I have some hacks but not coherent enough to want to put them in
the wild.

This and Apple blocks are the two biggest issues in making GCC better on
Darwin.

[Bug target/116787] [14/15 Regression] No longer recognizes vector maxps

2024-09-20 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116787

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization,
   ||needs-bisection
 Target||x86_64-*-*
   Target Milestone|--- |14.3
  Known to work||13.3.1

[Bug target/116787] [14/15 Regression] No longer recognizes vector maxps

2024-09-20 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116787

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Priority|P3  |P2
 Ever confirmed|0   |1
   Last reconfirmed||2024-09-20
   Keywords|needs-bisection |
 Status|UNCONFIRMED |NEW

--- Comment #2 from Jakub Jelinek  ---
Started with r14-2786-gade30fad6669e5f34ca4c587c724d74ecc953175

[Bug target/82420] ICE with -malign-int and -m68000

2024-09-20 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82420

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #9 from Sam James  ---
r15-3729-g0be3f4546f9b92 fixes up the test.

[Bug target/99708] __SIZEOF_FLOAT128__ not defined on powerpc64le-linux

2024-09-20 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #40 from Sam James  ---
r15-3729-g0be3f4546f9b92 fixes up the test.

[Bug target/110934] m68k: ICE with -fzero-call-used-regs=all compiling openssh 9.3p2

2024-09-20 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934

--- Comment #17 from Sam James  ---
r15-3729-g0be3f4546f9b92 fixes up the test.

[Bug target/108640] ICE compiling busybox for m68k in change_address_1, at emit-rtl.cc:2283

2024-09-20 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #11 from Sam James  ---
r15-3729-g0be3f4546f9b92 fixes up the test.

[Bug target/55212] [SH] Switch to LRA

2024-09-20 Thread kkojima at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #286 from Kazumoto Kojima  ---
Created attachment 59157
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59157&action=edit
a revised patch to movsf issue which splits movesf_ie_ra

[Bug target/55212] [SH] Switch to LRA

2024-09-20 Thread kkojima at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #285 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #284)
> (In reply to Kazumoto Kojima from comment #283)
...
> > It turned out that the c#276 version of block_lump_real_i4 works correctly
> > in only the limited cases.
> 
> Have you tried writing the pattern as 
> 
> (define_insn "block_lump_real_i4"
>   [(set (mem:BLK (match_operand:SI 2 "" "r,r"))
>  (mem:BLK (match_operand:SI 3 "" "r,r")))
>(use (match_operand:SI 0 "arith_reg_operand" "r,r"))
>(use (match_operand 1 "" "Z,Ccl"))
>...
> 
> i.e. without the parallel in there?  Sorry, maybe it's a stupid idea but ...

The last time I tried it against slightly different patterns, there was no
difference. I'll try it again.

[Bug target/55212] [SH] Switch to LRA

2024-09-20 Thread kkojima at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #287 from Kazumoto Kojima  ---
Created attachment 59158
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59158&action=edit
a revised patch to QIHI extend/move

[Bug target/55212] [SH] Switch to LRA

2024-09-20 Thread kkojima at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #288 from Kazumoto Kojima  ---
Created attachment 59159
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59159&action=edit
a revised workaround sfunc issue

[Bug testsuite/116397] [15 Regression] slp-reduc-3.c fails on aarch64-linux-gnu

2024-09-20 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116397

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2024-09-20
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #1 from Richard Biener  ---
It is - we're using SLP to produce load_lanes now but VEC_PERM_EXPR appears a
lot because of SLP nodes using it.  I'm changing the dump to look for =
VEC_PERM_EXPR.

[Bug target/55212] [SH] Switch to LRA

2024-09-20 Thread kkojima at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #289 from Kazumoto Kojima  ---
I've reconstructed patches as follows:

[59157] a revised patch to movsf issue which splits movesf_ie_ra
[59158] a revised patch to QIHI extend/move
[59159] a revised workaround sfunc issue
[59153] Alex's patch works magically for call_pcrel* issue.

I've also created sh-lra-take2 branch of https://github.com/kazkojima/gcc.git
with these patches for the reference.

[Bug testsuite/116397] [15 Regression] slp-reduc-3.c fails on aarch64-linux-gnu

2024-09-20 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116397

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

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

commit r15-3732-g5d0e46a939f3840f810f071037e543a6249c06fe
Author: Richard Biener 
Date:   Fri Sep 20 13:47:34 2024 +0200

testsuite/116397 - avoid looking for "VEC_PERM_EXPR"

With SLP this token appears a lot, when looking for what gets code
generated instead look for " = VEC_PERM_EXPR"

PR testsuite/116397
* gcc.dg/vect/slp-reduc-3.c: Look for " = VEC_PERM_EXPR"
instead of "VEC_PERM_EXPR".

[Bug testsuite/116397] [15 Regression] slp-reduc-3.c fails on aarch64-linux-gnu

2024-09-20 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116397

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug tree-optimization/116578] vectorizer SLP transition issues / dependences

2024-09-20 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116578
Bug 116578 depends on bug 116397, which changed state.

Bug 116397 Summary: [15 Regression] slp-reduc-3.c fails on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116397

   What|Removed |Added

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

[Bug target/113953] Finish LRA transition for s390 by removing -mlra

2024-09-20 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113953

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Stefan Schulze Frielinghaus
:

https://gcc.gnu.org/g:09a52cf036ba8f2fa7b60b18ba58ca17ffa1b146

commit r15-3733-g09a52cf036ba8f2fa7b60b18ba58ca17ffa1b146
Author: Stefan Schulze Frielinghaus 
Date:   Fri Sep 20 13:53:08 2024 +0200

s390: Remove -m{,no-}lra option

Since the old reload pass is about to be removed and we defaulted to LRA
for over a decade, remove option -m{,no-}lra.

PR target/113953

gcc/ChangeLog:

* config/s390/s390.cc (s390_lra_p): Remove.
(TARGET_LRA_P): Remove.
* config/s390/s390.opt (mlra): Remove.
* config/s390/s390.opt.urls (mlra): Remove.

gcc/testsuite/ChangeLog:

* gcc.target/s390/TI-constants-nolra.c: Removed.
* gcc.target/s390/pr79895.c: Removed.

[Bug target/113953] Finish LRA transition for s390 by removing -mlra

2024-09-20 Thread stefansf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113953

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

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

--- Comment #3 from Stefan Schulze Frielinghaus  
---
Fixed.

[Bug target/113932] [meta-bug] Targets which should be ported to LRA

2024-09-20 Thread stefansf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932
Bug 113932 depends on bug 113953, which changed state.

Bug 113953 Summary: Finish LRA transition for s390 by removing -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113953

   What|Removed |Added

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

[Bug c++/116769] Instantiation of defaulted default constructor with non default constructible NDSMIs

2024-09-20 Thread ppalka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116769

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #5 from Patrick Palka  ---
I believe GCC, deliberately as an extension, treats NSDMIs as within the
"immediate context" of a defaulted default constructor synthesis.  So if NSDMI
instantiation fails the defaulted constructor gets defined as deleted instead
of issuing a hard error.  Strictly speaking the code is ill-formed though IIUC.
 There's probably an existing PR about this.

[Bug c++/116789] New: Internal compiler error for non-type template parameter to alias template inside macro

2024-09-20 Thread aslobodkins at mail dot smu.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116789

Bug ID: 116789
   Summary: Internal compiler error for non-type template
parameter to alias template inside macro
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aslobodkins at mail dot smu.edu
  Target Milestone: ---

I get the following error on all versions of gcc13 and gcc14 I have tried so
far(includes gcc-14.1 and gcc-14.2):

In file included from ../src/Expr/array_expr1D.hpp:9,
 from ../src/strict_lib.hpp:8,
 from test.hpp:6,
 from fixed_array.cpp:8:
../src/Expr/../derived1D.hpp: In substitution of ‘template  requires  Builtin using slib::FixedArray1D =
slib::Derived1D >
[with slib::ImplicitIntStatic sz = T]’:
fixed_array.cpp:64:4:   required from here
../src/Expr/../derived1D.hpp:994:7: internal compiler error: Segmentation fault
  994 | using FixedArray1D = Derived1D>;
  |   ^~~~

The error occurs in the following scenario:  
constexpr FixedArray1D A;
REQUIRE_STRICT_THROW((FixedArray1D(A.begin(), A.end(;

where REQUIRE_STRICT_THROW is a macro that tests error handling and triggers
assertion if the passed expression does not throw. 

It is important to point out that this error does not occur if one calls
standard size() function:
REQUIRE_STRICT_THROW((FixedArray1D(A.begin(), A.end(;

In addition, removing REQUIRE_STRICT_THROW gets rid of the issue as well:
FixedArray1D(A.begin(), A.end());

Finally, replacing FixedArray1D alias with Derived1D also
works fine:
REQUIRE_STRICT_THROW((Derived1D>(A.begin(),
A.end(;

[Bug c++/116492] inherited constructors with concept in subclass overrides constructor in subclass

2024-09-20 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116492

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

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

commit r15-3741-gee3efe06c9c49c04eaa4e195a7ae8774a1b3faa2
Author: Patrick Palka 
Date:   Fri Sep 20 12:33:13 2024 -0400

c++: CWG 2789 and usings [PR116492]

After CWG 2789, the "more constrained" tiebreaker for non-template
functions should exclude member functions that are defined in
different classes.  This patch implements this missing refinement.

In turn we can get rid of four-parameter version of object_parms_correspond
and call the main overload directly since now correspondence is only
only checked for members from the same class.

PR c++/116492
DR 2789

gcc/cp/ChangeLog:

* call.cc (object_parms_correspond): Remove.
(cand_parms_match): Return false for member functions that come
from different classes.  Adjust call to object_parms_correspond.
(joust): Update comment for the non-template "more constrained"
case.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-memfun4.C: Also compile in C++20 mode.
Expect ambiguity when candidates come from different classes.
* g++.dg/cpp2a/concepts-inherit-ctor12.C: New test.

Reviewed-by: Jason Merrill 

[Bug testsuite/109656] [14/15 regression] 26_numerics/random/random_device/cons/token.cc fails after r14-289-gf9412cedd6c0e7

2024-09-20 Thread seurer at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109656

--- Comment #10 from seurer at gcc dot gnu.org ---
Looking through my logs the tests stopped failing sometime between r14-2132 and
r14-2263.  I think we can close this unless you want me to find where they
stopped failing.

[Bug target/113933] Switch pa to LRA

2024-09-20 Thread danglin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933

--- Comment #4 from John David Anglin  ---
Created attachment 59163
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59163&action=edit
Initial patch to enable lra

[Bug target/113933] Switch pa to LRA

2024-09-20 Thread danglin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933

--- Comment #5 from John David Anglin  ---
Created attachment 59164
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59164&action=edit
Preproccessed source

We have lra crash with this source.

/home/dave/gnu/gcc/objdir/./gcc/cc1 -fpreprocessed _mulvdi3.i -quiet -dumpbase
_mulvdi3.c -dumpbase-ext .c -g -g -g -O2 -O2 -O2 -Wextra -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wformat=0 -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -version -fno-checking -fbuilding-libgcc
-fno-stack-protector -fPIC -fvisibility=hidden -o _mulvdi3.s

[Bug c++/116789] Internal compiler error for non-type template parameter to alias template inside macro

2024-09-20 Thread mpolacek at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116789

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2024-09-20
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Please provide a complete test case.

https://gcc.gnu.org/bugs/

[Bug c/116791] New: ICE in operator[], at vec.h:910

2024-09-20 Thread manuel.lauss at googlemail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116791

Bug ID: 116791
   Summary: ICE in operator[], at vec.h:910
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manuel.lauss at googlemail dot com
  Target Milestone: ---

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

The attached unreduced testcase ICEs on AMD64:

gcc version 15.0.0 20240919 (experimental)
33ccc1314dcdb0b988a9276ca6b6ce9b07bea21e (Gentoo 15.0. p, commit
d676863b64b58bf73a7f26eea70f81aeba517b13)

# gcc -c nine_ff.i -O2 -mavx2
during GIMPLE pass: vect
../mesa-/src/gallium/frontends/nine/nine_ff.c: In function
'nine_ff_update':
../mesa-/src/gallium/frontends/nine/nine_ff.c:2073:1: internal compiler
error: in operator[], at vec.h:910
 2073 | nine_ff_update(struct NineDevice9 *device)
  | ^~
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.


-O2 -mavx2 are required to trigger it; -O1 or plain -mavx make it go away.

Thanks!
 Manuel

[Bug rtl-optimization/116783] [14/15 Regression] Wrong code at -O2 with late pair fusion pass (wrong alias analysis)

2024-09-20 Thread acoplan at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116783

--- Comment #4 from Alex Coplan  ---
Testing a fix for the trunk.

[Bug target/113933] Switch pa to LRA

2024-09-20 Thread danglin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933

--- Comment #3 from John David Anglin  ---
This code in pa_emit_move_sequence is reload specific (reg_equiv_mem):

  if (scratch_reg
  && reload_in_progress
  && GET_CODE (operand0) == REG
  && REGNO (operand0) >= FIRST_PSEUDO_REGISTER)
operand0 = reg_equiv_mem (REGNO (operand0));
  else if (scratch_reg
   && reload_in_progress
   && GET_CODE (operand0) == SUBREG
   && GET_CODE (SUBREG_REG (operand0)) == REG
   && REGNO (SUBREG_REG (operand0)) >= FIRST_PSEUDO_REGISTER)
{
 /* We must not alter SUBREG_BYTE (operand0) since that would confuse
the code which tracks sets/uses for delete_output_reload.  */
  rtx temp = gen_rtx_SUBREG (GET_MODE (operand0),
 reg_equiv_mem (REGNO (SUBREG_REG (operand0))),
 SUBREG_BYTE (operand0));
  operand0 = alter_subreg (&temp, true);
}

We need something similar for lra.  Otherwise, we hit following error:

dave@mx3210:~/gnu/gcc/objdir/hppa-linux-gnu/libgcc$ sh xx.sh
GNU C17 (GCC) version 15.0.0 20240918 (experimental) [master
r15-3695-gcc62b2c3da1] (hppa-linux-gnu)
compiled by GNU C version 13.3.0, GMP version 6.3.0, MPFR version
4.2.1, MPC version 1.3.1, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 07d108a61db93a2471fe8e13f11689df
during RTL pass: reload
../../../gcc/libgcc/libgcc2.c: In function ‘__mulvdi3’:
../../../gcc/libgcc/libgcc2.c:376:1: internal compiler error: maximum number of
generated reload insns per insn achieved (90)
  376 | }
  | ^
0x335fd73 internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:517
0x12b9e43 lra_constraints(bool)
../../gcc/gcc/lra-constraints.cc:5404
0x1291b63 lra(_IO_FILE*, int)
../../gcc/gcc/lra.cc:2445
0x11f4d43 do_reload
../../gcc/gcc/ira.cc:5976
0x11f5663 execute
../../gcc/gcc/ira.cc:6164

[Bug tree-optimization/116791] [15 Regression] ICE in operator[], at vec.h:910

2024-09-20 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116791

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE in operator[], at   |[15 Regression] ICE in
   |vec.h:910   |operator[], at vec.h:910
   Target Milestone|--- |15.0

[Bug c++/116789] Internal compiler error for non-type template parameter to alias template inside macro

2024-09-20 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116789

--- Comment #6 from Andrew Pinski  ---
Looks to be fixed on the trunk. Will reduce in a few.

[Bug c++/109126] [DR2387] Linkage of const-qualified variable template

2024-09-20 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109126

--- Comment #12 from Jonathan Wakely  ---
Yes but for the function template case if I want to use it in constexpr I add
'constexpr' and it's implicitly inline. For the variable template
specialisation it's already constexpr, and I can't define it non-inline in
another TU because it needs to be in a header to use in other constexpr
functions.

So it has to be inline (or static, which can cause odr violations in headers).

But this seems like a language problem not a gcc one.

[Bug c++/116793] New: ice in gimplify_var_or_parm_decl, at gimplify.cc:3309

2024-09-20 Thread dcb314 at hotmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116793

Bug ID: 116793
   Summary: ice in gimplify_var_or_parm_decl, at gimplify.cc:3309
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 59165
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59165&action=edit
gzipped C++ source code

The attached code does this

$ /home/dcb40b/gcc/results.20240909.asan.ubsan/bin/g++ -c -w -std=gnu++20
bug1049.cc
/home/dcb40b/rpmbuild/BUILD/libunifex-0.4.0/test/at_coroutine_exit_test.cpp: In
function ‘void
{anonymous}::AtCoroutineExit::test_mutable_stateful_cleanup_action(_ZN12_GLOBAL__N_115AtCoroutineExit36test_mutable_stateful_cleanup_actionEv.Frame*)’:
/home/dcb40b/rpmbuild/BUILD/libunifex-0.4.0/test/at_coroutine_exit_test.cpp:77:11:
internal compiler error: in gimplify_var_or_parm_decl, at gimplify.cc:3309
   77 |   }, 3);
  |   ^

It used to work with 20240906. The git hashes are g:6a1a856ba78589f7
and g:39a01fcf24676a27.

I have a reduction running.

[Bug other/116792] RFE: should we be able to generate diagnostics in HTML format?

2024-09-20 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116792

--- Comment #1 from Andrew Pinski  ---
Maybe just a post processing of json is needed instead.

[Bug target/113933] Switch pa to LRA

2024-09-20 Thread danglin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933

--- Comment #6 from John David Anglin  ---
lra crashes on this insn:

(insn 524 38 523 5 (set (reg:DI 106 [ _16 ])
(reg:DI 321 [orig:106 _16 ] [106]))
"../../../gcc/libgcc/libgcc2.c":276:4 81 {*pa.md:4260}
 (nil))

[Bug fortran/100273] [12/13/14 Regression] ICE in gfc_create_module_variable, at fortran/trans-decl.c:5352

2024-09-20 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100273

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #16 from anlauf at gcc dot gnu.org ---
Fixed on all open branches.  Closing.

Thanks for the report!

[Bug c++/116793] ice in gimplify_var_or_parm_decl, at gimplify.cc:3309

2024-09-20 Thread mpolacek at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116793

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2024-09-20
 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Seems to have started with r15-3513:

commit 964577c31df206d780d5cc7bc07189d44de2719e
Author: Jakub Jelinek 
Date:   Fri Sep 6 13:50:47 2024 +0200

c++: Partially implement CWG 2867 - Order of initialization for structured
bindings [PR115769]

[Bug fortran/116679] Memory leak when creating derived type instance with allocatable component within array expression

2024-09-20 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116679

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-09-20
 Status|UNCONFIRMED |NEW

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

The testcase in comment#1 needs fixing (remove 'use bugdemo').
The memleak there depends on array being a pointer.
Changing it to allocatable seems to plug the leak here.

Note that replacing in the block

items = [wrapper(1)]

by

items(1)% val = 1

also does not leak.

[Bug c++/67491] [meta-bug] concepts issues

2024-09-20 Thread ppalka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 116492, which changed state.

Bug 116492 Summary: inherited constructors with concept in subclass overrides 
constructor in subclass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116492

   What|Removed |Added

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

[Bug c++/94404] [meta-bug] C++ core issues

2024-09-20 Thread ppalka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
Bug 94404 depends on bug 116492, which changed state.

Bug 116492 Summary: inherited constructors with concept in subclass overrides 
constructor in subclass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116492

   What|Removed |Added

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

[Bug c++/116492] inherited constructors with concept in subclass overrides constructor in subclass

2024-09-20 Thread ppalka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116492

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |14.3
 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org

--- Comment #8 from Patrick Palka  ---
Narrowly fixed for GCC 14.3, fully fixed GCC 15, thanks for the bug report.

[Bug c++/116793] ice in gimplify_var_or_parm_decl, at gimplify.cc:3309

2024-09-20 Thread dcb314 at hotmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116793

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #2 from David Binderman  ---
Created attachment 59166
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59166&action=edit
gzipped C++ source code

After more than an hour of cvise, I attach the
partially reduced source code.

[Bug fortran/100273] [12/13/14 Regression] ICE in gfc_create_module_variable, at fortran/trans-decl.c:5352

2024-09-20 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100273

--- Comment #14 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Harald Anlauf
:

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

commit r12-10720-gcb25c5dd6b315dc216c7a5640dc89c5d74ffea34
Author: Harald Anlauf 
Date:   Thu Sep 5 21:30:25 2024 +0200

Fortran: fix ICE in gfc_create_module_variable [PR100273]

gcc/fortran/ChangeLog:

PR fortran/100273
* trans-decl.cc (gfc_create_module_variable): Handle module
variable also when it is needed for the result specification
of a contained function.

gcc/testsuite/ChangeLog:

PR fortran/100273
* gfortran.dg/pr100273.f90: New test.

(cherry picked from commit 1f462b5072a5e82c35921f7e3bdf3959c4a49dc9)

[Bug fortran/100273] [12/13/14 Regression] ICE in gfc_create_module_variable, at fortran/trans-decl.c:5352

2024-09-20 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100273

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

https://gcc.gnu.org/g:3604d9cab9bb9fe6a3c642385c816211b8f2be5d

commit r13-9048-g3604d9cab9bb9fe6a3c642385c816211b8f2be5d
Author: Harald Anlauf 
Date:   Thu Sep 5 21:30:25 2024 +0200

Fortran: fix ICE in gfc_create_module_variable [PR100273]

gcc/fortran/ChangeLog:

PR fortran/100273
* trans-decl.cc (gfc_create_module_variable): Handle module
variable also when it is needed for the result specification
of a contained function.

gcc/testsuite/ChangeLog:

PR fortran/100273
* gfortran.dg/pr100273.f90: New test.

(cherry picked from commit 1f462b5072a5e82c35921f7e3bdf3959c4a49dc9)

[Bug c/116726] [14/15 Regression] compiler segfault when using certain struct redefinitions

2024-09-20 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116726

--- Comment #9 from GCC Commits  ---
The master branch has been updated by Martin Uecker :

https://gcc.gnu.org/g:9227a64495d5594613604573b72422e8e3722fc5

commit r15-3745-g9227a64495d5594613604573b72422e8e3722fc5
Author: Martin Uecker 
Date:   Tue Sep 17 11:37:29 2024 +0200

c: fix crash when checking for compatibility of structures [PR116726]

When checking for compatibility of structure or union types in
tagged_types_tu_compatible_p, restore the old value of the pointer to
the top of the temporary cache after recursively calling comptypes_internal
when looping over the members of a structure of union.  While the next
iteration of the loop overwrites the pointer, I missed the fact that it can
be accessed again when types of function arguments are compared as part
of recursive type checking and the function is entered again.

PR c/116726

gcc/c/ChangeLog:

* c-typeck.cc (tagged_types_tu_compatible_p): Restore value
of the cache after recursing into comptypes_internal.

gcc/testsuite/ChangeLog:

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

[Bug driver/116794] New: gcc -pipe does not work on macOS with as from Xcode 16 (on macOS 15)

2024-09-20 Thread mark at moxienet dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116794

Bug ID: 116794
   Summary: gcc -pipe does not work on macOS with as from Xcode 16
(on macOS 15)
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mark at moxienet dot com
  Target Milestone: ---

On macOS, Xcode 16 has redone the way that its packaged `as` tool operates.
It’s now a shell script that delegates to `clang -x assembler -c`. One
consequence of this is that `as` no longer adheres to the convention that, in
the absence of a named input file, it will read from standard input.

`gcc -pipe` provides input to `as` via standard input. When `gcc -pipe` drives
Xcode 16 `as`, it does not give `as` an input file pathname on its command
line, causing `as`, which invokes `clang`, to produce this error and exit with
status 1:

% gcc -pipe -c -o ~/t.o ~/t.c
clang: error: no input files

This makes it impossible to use `gcc -pipe`.

It is apparent that the problem is `as`. Although this works in previous
versions of Xcode, with Xcode 16, it fails:

% as -o /dev/null <<< '.globl main'
clang: error: no input files

while this works:

% as -o /dev/null - <<< '.globl main'

Xcode 16 `as` will read its input from standard input if invoked with `-` as
the input path. Previous versions of `as` supplied by Apple, including Xcode 15
`as` and older cctools-based `as`, respect this convention as well (I tested
cctools-836 from the CLT 201211 on OS X 10.7.5 11G63), as should binutils
`gas`.

gcc has a macro, `AS_NEEDS_DASH_FOR_PIPED_INPUT`, which can be defined to
configure it to operate with `as` programs that require this convention.
Because it appears that any `as` likely to be used on any macOS/Darwin system
of any vintage can accept the `-` for this purpose, it ought to be possible to
define this for Darwin unconditionally.

This change should be taken on all live gcc branches (currently, 14, 13, and
12), as all are affected.

(There are other macOS 15/Xcode 16 compatibility concerns on gcc 13 and 12, and
other compatibility concerns even on gcc 14 for x86_64. This change alone,
however, is sufficient to make gcc work on macOS 15/Xcode 16 for arm64 using
either https://github.com/iains/gcc-darwin-arm64 or
https://github.com/iains/gcc-14-branch)

Also discussed at:
https://github.com/iains/gcc-darwin-arm64/issues/136
https://trac.macports.org/ticket/70641

[Bug driver/116794] gcc -pipe does not work on macOS with as from Xcode 16 (on macOS 15)

2024-09-20 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116794

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |15.0
 Resolution|--- |FIXED

--- Comment #1 from Andrew Pinski  ---
Fixed by r15-3737-g33ccc1314dcdb0b988a9276ca6b6ce9b07bea21e .

[Bug c++/116492] inherited constructors with concept in subclass overrides constructor in subclass

2024-09-20 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116492

--- Comment #7 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:659f32ea9de57661f8a37dcfb0b9a01bfe29acce

commit r14-10696-g659f32ea9de57661f8a37dcfb0b9a01bfe29acce
Author: Patrick Palka 
Date:   Fri Sep 20 17:37:03 2024 -0400

c++: CWG 2789 and usings [PR116492]

For GCC 14, narrowly fix this PR by implementing the missing

  - if they are member functions, both are direct members of the same
class, and

part of CWG 2789 for constructors only.

PR c++/116492
DR 2789

gcc/cp/ChangeLog:

* call.cc (cand_parms_match): Return false for constructors that
come from different classes.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-inherit-ctor12.C: New test.

Reviewed-by: Jason Merrill 

[Bug c++/116418] [12/13/14/15 Regression] statement expressions as initializer for decltype auto breaks in templates with optimization turned on and debug info turned on due to gstatement-frontiers

2024-09-20 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116418

--- Comment #10 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Patrick Palka
:

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

commit r14-10697-gabdea396e12e66185d810435bbc363845cf4664a
Author: Patrick Palka 
Date:   Thu Sep 12 12:45:03 2024 -0400

c++: decltype(auto) deduction of statement-expression [PR116418]

r8-7538 for PR84968 made strip_typedefs_expr diagnose STATEMENT_LIST
so that we reject statement-expressions in noexcept-specifiers to
match our behavior in template arguments (which the parser diagnoses
directly).

Later r11-7452 made decltype(auto) deduction canonicalize the expression
(as an implementation detail) which in turn calls strip_typedefs_expr,
and so ever since we inadvertently reject decltype(auto) deduction of a
statement-expression.

This patch just removes the diagnostic in strip_typedefs_expr and instead
treats statement-expressions similar to lambda-expressions.  The function
doesn't seem like the right place for such a diagnostic and so it seems
easier to just accept rather than try to reject them in a suitable place.

PR c++/116418

gcc/cp/ChangeLog:

* tree.cc (strip_typedefs_expr) : Replace
this error path with ...
: ... this, returning the original tree.

gcc/testsuite/ChangeLog:

* g++.dg/eh/pr84968.C: No longer expect an ahead of time diagnostic
for the statement-expresssion.  Instantiate the template and expect
an incomplete type error instead.
* g++.dg/ext/stmtexpr26.C: New test.

Reviewed-by: Jason Merrill 
(cherry picked from commit 12bdcc3d7970860b9d66ed4dea203bde8fd68d4d)

[Bug c++/116418] [12/13 Regression] statement expressions as initializer for decltype auto breaks in templates with optimization turned on and debug info turned on due to gstatement-frontiers

2024-09-20 Thread ppalka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116418

Patrick Palka  changed:

   What|Removed |Added

Summary|[12/13/14/15 Regression]|[12/13 Regression]
   |statement expressions as|statement expressions as
   |initializer for decltype|initializer for decltype
   |auto breaks in templates|auto breaks in templates
   |with optimization turned on |with optimization turned on
   |and debug info turned on|and debug info turned on
   |due to gstatement-frontiers |due to gstatement-frontiers

--- Comment #11 from Patrick Palka  ---
Fixed for GCC 14.3 so far.

[Bug c++/116789] Internal compiler error for non-type template parameter to alias template inside macro

2024-09-20 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116789

--- Comment #8 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #7)
> The important part is the type alias ali1.

Even from the commit message:
```
it occurred to me that the problem is really
with alias (and concept) templates
```

So yes that looks like the real fix too.

[Bug c++/116789] Internal compiler error for non-type template parameter to alias template inside macro

2024-09-20 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116789

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #9 from Andrew Pinski  ---
.

[Bug c++/116789] Internal compiler error for non-type template parameter to alias template inside macro

2024-09-20 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116789

--- Comment #7 from Andrew Pinski  ---
Reduced testcase:
```
struct s3 {
  template  constexpr s3(T x){}
};
template  class s1;
template  class s2;
template 
  using ali1 = s1;
template 
void h() {
  s2 A;
  ali1 b;
}
```

The important part is the type alias ali1.

[Bug c++/116793] [15 regression] ice in gimplify_var_or_parm_decl, at gimplify.cc:3309 since r15-3513

2024-09-20 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116793

--- Comment #3 from Andrew Pinski  ---
Reducing this further.

[Bug other/116613] RFE: support outputting diagnostics in *multiple* formats

2024-09-20 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613

--- Comment #4 from GCC Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:725231e16768bd9f16169b3b7e4cb5a98b251d1c

commit r15-3750-g725231e16768bd9f16169b3b7e4cb5a98b251d1c
Author: David Malcolm 
Date:   Fri Sep 20 18:51:55 2024 -0400

diagnostics: isolate SARIF output's pretty_printer [PR116613]

Add an m_printer to sarif_builder and use throughout, rather than
using the context's printer.  For now this is the same printer, but
eventually this should help with transitioning to multiple output sinks.

No functional change intended.

gcc/ChangeLog:
PR other/116613
* diagnostic-format-sarif.cc (sarif_builder::m_printer): New
field.
(sarif_invocation::add_notification_for_ice): Drop context param.
(sarif_invocation::prepare_to_flush): Convert param from context
to builder.
(sarif_result::on_nested_diagnostic): Drop context param.  Use
builder's printer.
(sarif_result::on_diagram): Drop context param.
(sarif_ice_notification::sarif_ice_notification): Drop context
param.  Use builder's printer.
(sarif_builder::sarif_builder): Initialize m_printer.
(sarif_builder::on_report_diagnostic): Drop context param.  Use
builder's printer.
(sarif_builder::emit_diagram): Drop context param.
(sarif_builder::flush_to_object): Use this rather than context
for call to prepare_to_flush.
(sarif_builder::make_result_object): Drop context param.  Use
builder's printer.
(sarif_builder::make_reporting_descriptor_object_for_warning):
Drop context param.
(sarif_builder::make_message_object_for_diagram): Likewise.
Use builder's printer.
(sarif_output_format::on_report_diagnostic): Drop context param
from call to sarif_builder::on_report_diagnostic.
(sarif_output_format::on_diagram): Drop context param from call to
sarif_builder::emit_diagram.
* diagnostic.h (diagnostic_conetxt::get_client_data_hooks): Make
const.

Signed-off-by: David Malcolm 

[Bug other/116792] RFE: should we be able to generate diagnostics in HTML format?

2024-09-20 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116792

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #3 from Sam James  ---
(In reply to Andrew Pinski from comment #1)
> Maybe just a post processing of json is needed instead.

The issue I foresee is restoring colour at that point.

[Bug libstdc++/116777] error: 'current_zone' is not a member of 'std::chrono' with -D_GLIBCXX_USE_CXX11_ABI=0

2024-09-20 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116777

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:82309222300acf68e345b32155df21e1b876144e

commit r15-3746-g82309222300acf68e345b32155df21e1b876144e
Author: Jonathan Wakely 
Date:   Fri Sep 20 17:35:48 2024 +0100

libstdc++: Document missing features for old std:string ABI [PR116777]

There are several features that are not supported when using the old
std::string ABI. It's possible that PR 81967 will get fixed, but the
missing C++20 features almost certainly won't be. Document this in the
manual.

libstdc++-v3/ChangeLog:

PR libstdc++/116777
* doc/xml/manual/using.xml: Document features that are not
supported for the gcc4-compatible ABI.
* doc/html/manual/using_dual_abi.html: Regenerate.

  1   2   >