[Bug target/111078] csneg is not used for (cset) * 2 - 1

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
MIne
For f0 we should be able to match:
(set (reg:SI 98)
(plus:SI (ashift:SI (eq:SI (reg:CC 66 cc)
(const_int 0 [0]))
(const_int 1 [0x1]))
(const_int -1 [0x])))

here. Note -1 is important.

for f1 we should be able to match:
(set (reg:SI 98)
(ior:SI (neg:SI (ne:SI (reg:CC 66 cc)
(const_int 0 [0])))
(const_int 1 [0x1])))

Though I wonder for gimple if we should conconalization to one form or another
...

[Bug target/98477] aarch64: Unnecessary GPR -> FPR moves for conditional select

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
I am going to look into this ...

[Bug target/112454] csinc (csel is though) is not being used when there is matches twice

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

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

--- Comment #3 from Andrew Pinski  ---

-1/~0 has the same issue as mentioned:
```
int finv(int a, int b, int c, int d)
{
  return (a == 2 ? -1 : b) + (c == 3 ? -1 : d);
}
```

[Bug target/112454] csinc (csel is though) is not being used when there is matches twice

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Mine, looks like a cost issue not recording that 1 (and ~0) are free to create.

you can see the cost issue if we look at combine for the case of 1 csel:
Trying 37 -> 39:
   37: r98:SI=0x1
   39: r92:SI={(cc:CC!=0)?r100:SI:r98:SI}
  REG_DEAD r100:SI
  REG_DEAD cc:CC
  REG_DEAD r98:SI
Successfully matched this instruction:
(set (reg:SI 92 [  ])
(if_then_else:SI (ne (reg:CC 66 cc)
(const_int 0 [0]))
(reg:SI 100)
(const_int 1 [0x1])))
allowing combination of insns 37 and 39
original costs 4 + 4 = 8
replacement cost 8
deferring deletion of insn with uid = 37.
modifying insn i339: r92:SI={(cc:CC!=0)?r100:SI:0x1}
  REG_DEAD cc:CC
  REG_DEAD r100:SI
deferring rescan insn with uid = 39.

The replacement cost should be still 4.

[Bug tree-optimization/112416] absu is not detected

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug target/112519] [14 Regression] wrong code with __builtin_sub_overflow_p() on x86_64-pc-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

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

[Bug target/112518] [14 Regression] wrong code with __builtin_mul_overflow_p() and int128_t on x86_64-pc-linux-gnu

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

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

--- Comment #5 from Andrew Pinski  ---
Works for me with r14-5566-g841008d3966c0f .

[Bug middle-end/112560] [14 Regression] ICE in try_combine on pr112494.c

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug middle-end/112560] [14 Regression] ICE in try_combine on pr112494.c

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

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

--- Comment #1 from Andrew Pinski  ---
This code seems to originally was added with
https://gcc.gnu.org/pipermail/gcc-patches/2011-April/311365.html 

The discussion on the patch continues into May:
https://gcc.gnu.org/pipermail/gcc-patches/2011-May/312415.html

[Bug middle-end/112581] [14 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (generated code hangs) since r14-4661 due to reassoc not handling maybe_undefs

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

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

--- Comment #10 from Andrew Pinski  ---
I have a patch but I don't like it since it requires to touch
gimple-if-to-switch.cc since that uses init_range_entry.  Maybe someone else
can come up with a better patch.

[Bug driver/108865] gcc on Windows fails with Unicode path to source file

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

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #44 from Alexandre Oliva  ---
All configure --with-* and --enable-* options are stored in shell variables
named with_* and enable_*, respectively, so it's just a matter of testing for
yes (for --enable) or rather for no (for explicit --disable).  Look for e.g.
--enable-initfini-array around line 1932 in $top_srcdir/gcc/configure.ac, or
with_avrlibc around line 1495 in gcc/config.gcc; you can do something similar
in gcc/config.host, without any explicit argument passing, because the
config.{host,gcc} files are sourced by configure, so they inherit all shell
variables.

[Bug analyzer/106147] RFE: -fanalyzer could complain about some cases of infinite loops and infinite recursion

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:841008d3966c0fe7a80ec10703a50fbdab7620ac

commit r14-5566-g841008d3966c0fe7a80ec10703a50fbdab7620ac
Author: David Malcolm 
Date:   Fri Nov 17 19:55:25 2023 -0500

analyzer: new warning: -Wanalyzer-infinite-loop [PR106147]

This patch implements a new analyzer warning: -Wanalyzer-infinite-loop.

It works by examining the exploded graph once the latter has been
fully built.  It attempts to detect cycles in the exploded graph in
which:
- no externally visible work occurs
- no escape is possible from the cycle once it has been entered
- the program state is "sufficiently concrete" at each step:
  - no unknown activity could be occurring
  - the worklist was fully drained for each enode in the cycle
i.e. every enode in the cycle is processed

For example, it correctly complains about this bogus "for" loop:

  int sum = 0;
  for (struct node *iter = n; iter; iter->next)
sum += n->val;
  return sum;

like this:

infinite-loop-linked-list.c: In function âfor_loop_noop_nextâ:
infinite-loop-linked-list.c:110:31: warning: infinite loop [CWE-835]
[-Wanalyzer-infinite-loop]
  110 |   for (struct node *iter = n; iter; iter->next)
  |   ^~~~
  âfor_loop_noop_nextâ: events 1-5
|
|  110 |   for (struct node *iter = n; iter; iter->next)
|  |   ^~~~
|  |   |
|  |   (1) infinite loop here
|  |   (2) when âiterâ is non-NULL:
always following âtrueâ branch...
|  |   (5) ...to here
|  111 | sum += n->val;
|  | ~
|  | |   |
|  | |   (3) ...to here
|  | (4) looping back...
|

gcc/ChangeLog:
PR analyzer/106147
* Makefile.in (ANALYZER_OBJS): Add analyzer/infinite-loop.o.
* doc/invoke.texi: Add -fdump-analyzer-infinite-loop and
-Wanalyzer-infinite-loop.  Add missing CWE link for
-Wanalyzer-infinite-recursion.
* timevar.def (TV_ANALYZER_INFINITE_LOOPS): New.

gcc/analyzer/ChangeLog:
PR analyzer/106147
* analyzer.opt (Wanalyzer-infinite-loop): New option.
(fdump-analyzer-infinite-loop): New option.
* checker-event.h (start_cfg_edge_event::get_desc): Drop "final".
(start_cfg_edge_event::maybe_describe_condition): Convert from
private to protected.
* checker-path.h (checker_path::get_logger): New.
* diagnostic-manager.cc (process_worklist_item): Update for
new context param of maybe_update_for_edge.
* engine.cc
(impl_region_model_context::impl_region_model_context): Add
out_could_have_done_work param to both ctors and use it to
initialize mm_out_could_have_done_work.
(impl_region_model_context::maybe_did_work): New vfunc
implementation.
(exploded_node::on_stmt): Add out_could_have_done_work param and
pass to ctxt ctor.
(exploded_node::on_stmt_pre): Treat setjmp and longjmp as "doing
work".
(exploded_node::on_longjmp): Likewise.
(exploded_edge::exploded_edge): Add "could_do_work" param and use
it to initialize m_could_do_work_p.
(exploded_edge::dump_dot_label): Add result of could_do_work_p.
(exploded_graph::add_function_entry): Mark edge as doing no work.
(exploded_graph::add_edge): Add "could_do_work" param and pass to
exploded_edge ctor.
(add_tainted_args_callback): Treat as doing no work.
(exploded_graph::process_worklist): Likewise when merging nodes.
(maybe_process_run_of_before_supernode_enodes::item): Likewise.
(exploded_graph::maybe_create_dynamic_call): Likewise.
(exploded_graph::process_node): Likewise for phi nodes.
Pass in a "could_have_done_work" bool when handling stmts and use
when creating edges.  Assume work is done at bifurcation.
(exploded_path::feasible_p): Update for new context param of
maybe_update_for_edge.
(feasibility_state::feasibility_state): New ctor.
(feasibility_state::operator=): New.
(feasibility_state::maybe_update_for_edge): Add ctxt param and use
it.  Fix missing newline when logging state.
(impl_run_checkers): Call exploded_graph::detect_infinite_loops.
* exploded-graph.h

[Bug c++/112588] ICE in make_decl_rtl when returning str literal when string header imported in module

[nathanieloshead at gmail dot com via Gcc-bugs]

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

Nathaniel Shead  changed:

   What|Removed |Added

 CC||nathanieloshead at gmail dot 
com

--- Comment #1 from Nathaniel Shead  ---
Minimised (the actual offender here is the with std::allocator):


  // test.h
  void f(int*);

  template 
  struct S {
void g(int n) { f(); }
  };

  template struct S;


  // a.cpp
  module;
  #include "test.h"
  export module test;


  // b.cpp
  #include "test.h"
  import test;


So far it seems the issue is that the PARM_DECL in the expression tree of the
body of the instantiation for `S::g` is a different node from the actual
PARM_DECL in g's DECL_ARGUMENTS; the latter gets RTL but the former does not.
The issue is in the deduplication logic for instantiations somewhere.

The following patch fixes this issue but causes other issues in the testsuite,
and I don't think this is the correct approach anyway:


diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 4f5b6e2747a..f2d191fc408 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -8302,9 +8302,7 @@ trees_in::decl_value ()
   if (TREE_CODE (inner) == FUNCTION_DECL)
{
  tree e_inner = STRIP_TEMPLATE (existing);
- for (auto parm = DECL_ARGUMENTS (inner);
-  parm; parm = DECL_CHAIN (parm))
-   DECL_CONTEXT (parm) = e_inner;
+ DECL_ARGUMENTS (inner) = DECL_ARGUMENTS (e_inner);
}

   /* And our result is the existing node.  */


(I was originally working on this after attempting to reduce PR9.)

[Bug ipa/112601] [11/12/13/14 Regression] ICE in cgraph_node::verify_node(): error: invalid calls_comdat_local flag

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Confirmed. Looks like an older regression.

[Bug middle-end/112581] [14 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (generated code hangs) since r14-4661

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

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

--- Comment #9 from Andrew Pinski  ---
Adding -fdisable-tree-reassoc2 causes the problem not to happen so yes it is a
bug in reassoc. If I get some time next week I will look into adding the
support.

[Bug middle-end/112581] [14 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (generated code hangs) since r14-4661

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

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

--- Comment #8 from Andrew Pinski  ---
tree-ssa-reassoc.cc needs to call mark_ssa_maybe_undefs and checks
ssa_name_maybe_undef_p similar to the way tree-ssa-ifcombine.cc does it.

[Bug middle-end/112581] [14 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (generated code hangs) since r14-4661

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

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

--- Comment #7 from Andrew Pinski  ---
Wait a minute, h might be uninitialized.


So the issue is inside reassociate which is must not have recognized that
iftmp.7_30 is defined by a maybe an uninitialized variable ...

[Bug middle-end/112581] [14 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (generated code hangs) since r14-4661

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

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

--- Comment #6 from Andrew Pinski  ---
forwprop3 does:
```
  _12 = ~iftmp.7_30;
  h_40 = (unsigned int) _12;
...
  if (h_40 == 4294967295)
```

into:
```
  _75 = (unsigned int) iftmp.7_30;
  if (iftmp.7_30 == 0)
```

Which as far as I can tell is correct.

And then reassociate2 combines:
```
   [local count: 57431765]:
  if (iftmp.7_30 == 0)
goto ; [97.17%]
  else
goto ; [2.83%]

   [local count: 55807730]:
  if (i_27 != 0)
goto ; [100.00%]
  else
goto ; [0.00%]
```
into:
```
   [local count: 57431765]:
  _75 = iftmp.7_30 | i_27;
  _33 = _75 == 0;
  if (_33 != 0)
goto ; [97.17%]
  else
goto ; [2.83%]
```

or
```
if ((_30 == 0) & (i_27 == 0)) goto <17> else goto <19/20>
```
Which looks correct.
I don't see anything going wrong with the patch itself ...

[Bug jit/112603] Allow setting the personality function

[bouanto at zoho dot com via Gcc-bugs]

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

--- Comment #1 from Antoni  ---
Created attachment 56628
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56628=edit
Patch

[Bug jit/112603] New: Allow setting the personality function

[bouanto at zoho dot com via Gcc-bugs]

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

Bug ID: 112603
   Summary: Allow setting the personality function
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: bouanto at zoho dot com
  Target Milestone: ---

I'll soon send a patch for this.

[Bug middle-end/112581] [14 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (generated code hangs) since r14-4661

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

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

--- Comment #5 from Andrew Pinski  ---
Looking into what is going wrong.

[Bug jit/112602] Support vector permutation and access

[bouanto at zoho dot com via Gcc-bugs]

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

--- Comment #1 from Antoni  ---
Created attachment 56627
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56627=edit
Patch

[Bug ipa/112601] [11/12/13/14 Regression] ICE in cgraph_node::verify_node(): error: invalid calls_comdat_local flag

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.5
  Known to fail||10.1.0
Summary|ICE in  |[11/12/13/14 Regression]
   |cgraph_node::verify_node(): |ICE in
   |error: invalid  |cgraph_node::verify_node():
   |calls_comdat_local flag |error: invalid
   ||calls_comdat_local flag
  Known to work||9.5.0
   Keywords||ice-on-valid-code

[Bug jit/112602] New: Support vector permutation and access

[bouanto at zoho dot com via Gcc-bugs]

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

Bug ID: 112602
   Summary: Support vector permutation and access
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: bouanto at zoho dot com
  Target Milestone: ---

I'll soon send a patch for this feature request.

[Bug libstdc++/112596] GCC regex error in Opentelemetry C++

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2023-11-17
 Status|UNCONFIRMED |WAITING
  Component|c++ |libstdc++
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
std::regex doesn't work in any release older than gcc-4.9.0 so I doubt it's
working properly with gcc-4.8.5

If it is working properly, then you're not actually using std::regex, so you
should just be able to remove it.

In any case, we can't do anything without the information we request for all
bug reports:
https://gcc.gnu.org/bugs/

[Bug ipa/112601] New: ICE in cgraph_node::verify_node(): error: invalid calls_comdat_local flag

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

/slyfox/dev/git/gcc/configure --disable-multilib
--disable-bootstrap --disable-lto --disable-libsanitizer
--disable-libstdcxx-pch --enable-languages=c,c++ --disable-libgomp
--disable-libquadmath --disable-libvtv CFLAGS='-O1 -g0' CXXFLAGS='-O1 -g0'
LDFLAGS='-O1 -g0'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231117 (experimental) (GCC)

[Bug c++/106650] [C++23] P2280 - Using unknown references in constant expressions

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637101.html
though I'm not sure it's complete.

[Bug middle-end/112600] Failed to optimize saturating addition using __builtin_add_overflow

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

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

--- Comment #2 from Jonathan Wakely  ---
For similar saturating subtraction functions:

unsigned
sub_sat(unsigned x, unsigned y) noexcept
{
unsigned z;
if (!__builtin_sub_overflow(x, y, ))
return z;
return 0;
}

unsigned
sub_sat2(unsigned x, unsigned y) noexcept
{
unsigned res;
res = x - y;
res &= -(res <= x);;
return res;
}

GCC x86_64 gives:

sub_sat(unsigned int, unsigned int):
sub edi, esi
jb  .L3
mov eax, edi
ret
.L3:
xor eax, eax
ret
sub_sat2(unsigned int, unsigned int):
sub edi, esi
mov eax, 0
cmovnb  eax, edi
ret

GCC aarch64 gives:

sub_sat(unsigned int, unsigned int):
subsw2, w0, w1
mov w3, 0
cmp w0, w1
cselw0, w2, w3, cs
ret
sub_sat2(unsigned int, unsigned int):
subsw0, w0, w1
cselw0, w0, wzr, cs
ret


Clang x86_64 gives:

sub_sat(unsigned int, unsigned int):
xor eax, eax
sub edi, esi
cmovae  eax, edi
ret
sub_sat2(unsigned int, unsigned int):
xor eax, eax
sub edi, esi
cmovae  eax, edi
ret

[Bug middle-end/112600] Failed to optimize saturating addition using __builtin_add_overflow

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

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

--- Comment #1 from Jonathan Wakely  ---
Similar results for aarch64 with GCC:

add_sat(unsigned int, unsigned int):
addsw0, w0, w1
bcs .L7
ret
.L7:
mov w0, -1
ret
add_sat2(unsigned int, unsigned int):
addsw0, w0, w1
csinv   w0, w0, wzr, cc
ret

[Bug middle-end/112600] New: Failed to optimize saturating addition using __builtin_add_overflow

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

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

Bug ID: 112600
   Summary: Failed to optimize saturating addition using
__builtin_add_overflow
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

These two implementations of C++26 saturating addition (std::add_sat)
have equivalent behaviour:

unsigned
add_sat(unsigned x, unsigned y) noexcept
{
unsigned z;
if (!__builtin_add_overflow(x, y, ))
return z;
return -1u;
}

unsigned
add_sat2(unsigned x, unsigned y) noexcept
{
unsigned res;
res = x + y;
res |= -(res < x);
return res;
}


For -O3 on x86_64 GCC uses a branch for the first one:

add_sat(unsigned int, unsigned int):
add edi, esi
jc  .L3
mov eax, edi
ret
.L3:
or  eax, -1
ret

For the second one we get better code:

add_sat2(unsigned int, unsigned int):
add edi, esi
sbb eax, eax
or  eax, edi
ret



Clang compiles them both to the same code:

add_sat(unsigned int, unsigned int):
add edi, esi
mov eax, -1
cmovae  eax, edi
ret

[Bug target/112599] RISC-V regression testsuite errors with rv64gcv_zvl1024b

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #1 from Patrick O'Neill  ---
Related issues:
128: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112583
256: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112597
512: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598
1024: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112599

[Bug target/112598] RISC-V regression testsuite errors with rv64gcv_zvl512b

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #1 from Patrick O'Neill  ---
Related issues:
128: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112583
256: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112597
512: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598
1024: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112599

[Bug target/112597] RISC-V regression testsuite errors with rv64gcv_zvl256b

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #1 from Patrick O'Neill  ---
Related issues:
128: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112583
256: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112597
512: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598
1024: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112599

[Bug target/112583] RISC-V regression testsuite errors with rv64gcv_zvl128b

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #1 from Patrick O'Neill  ---
Related issues:
128: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112583
256: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112597
512: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598
1024: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112599

[Bug target/112599] New: RISC-V regression testsuite errors with rv64gcv_zvl1024b

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 112599
   Summary: RISC-V regression testsuite errors with
rv64gcv_zvl1024b
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Created attachment 56626
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56626=edit
rv64gcv_zvl1024b testsuite failures 2023-11-17

Current testsuite status of rv64gcv_zvl1024b on GCC
5cb13173e85537a8a423b7b22b60ca3b6505f91e

I've started running zvl variants 128-1024b weekly on the postcommit CI. This
is my first time running these so if any of the failures look odd poke me here
or via email and I can dig into/share the logs.

Artifacts for this run can be downloaded here:
https://github.com/patrick-rivos/gcc-postcommit-ci/actions/runs/6898356494
Likely artifacts of interest:
gcc-linux-rv64gcv_zvl-lp64d-5cb13173e85537a8a423b7b22b60ca3b6505f91e-multilib-debug-output.log
gcc-linux-rv64gcv_zvl-lp64d-5cb13173e85537a8a423b7b22b60ca3b6505f91e-multilib-report.log
 
gcc-linux-rv64gcv_zvl-lp64d-5cb13173e85537a8a423b7b22b60ca3b6505f91e-multilib-sum-files
 

This is just a tracking issue, similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311

I've attached the current results for rv64gcv_zvl1024b with glibc v2.37 on QEMU
v8.1.2

[Bug target/112598] New: RISC-V regression testsuite errors with rv64gcv_zvl512b

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 112598
   Summary: RISC-V regression testsuite errors with
rv64gcv_zvl512b
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Created attachment 56625
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56625=edit
rv64gcv_zvl512b testsuite failures 2023-11-17

Current testsuite status of rv64gcv_zvl512b on GCC
5cb13173e85537a8a423b7b22b60ca3b6505f91e

I've started running zvl variants 128-1024b weekly on the postcommit CI. This
is my first time running these so if any of the failures look odd poke me here
or via email and I can dig into/share the logs.

Artifacts for this run can be downloaded here:
https://github.com/patrick-rivos/gcc-postcommit-ci/actions/runs/6898356494
Likely artifacts of interest:
gcc-linux-rv64gcv_zvl-lp64d-5cb13173e85537a8a423b7b22b60ca3b6505f91e-multilib-debug-output.log
gcc-linux-rv64gcv_zvl-lp64d-5cb13173e85537a8a423b7b22b60ca3b6505f91e-multilib-report.log
 
gcc-linux-rv64gcv_zvl-lp64d-5cb13173e85537a8a423b7b22b60ca3b6505f91e-multilib-sum-files
 

This is just a tracking issue, similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311

I've attached the current results for rv64gcv_zvl512b with glibc v2.37 on QEMU
v8.1.2

[Bug target/112597] New: RISC-V regression testsuite errors with rv64gcv_zvl256b

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 112597
   Summary: RISC-V regression testsuite errors with
rv64gcv_zvl256b
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Created attachment 56624
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56624=edit
rv64gcv_zvl256b testsuite failures 2023-11-17

Current testsuite status of rv64gcv_zvl256b on GCC
5cb13173e85537a8a423b7b22b60ca3b6505f91e

I've started running zvl variants 128-1024b weekly on the postcommit CI. This
is my first time running these so if any of the failures look odd poke me here
or via email and I can dig into/share the logs.

Artifacts for this run can be downloaded here:
https://github.com/patrick-rivos/gcc-postcommit-ci/actions/runs/6898356494
Likely artifacts of interest:
gcc-linux-rv64gcv_zvl-lp64d-5cb13173e85537a8a423b7b22b60ca3b6505f91e-multilib-debug-output.log
gcc-linux-rv64gcv_zvl-lp64d-5cb13173e85537a8a423b7b22b60ca3b6505f91e-multilib-report.log
 
gcc-linux-rv64gcv_zvl-lp64d-5cb13173e85537a8a423b7b22b60ca3b6505f91e-multilib-sum-files
 

This is just a tracking issue, similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311

I've attached the current results for rv64gcv_zvl256b with glibc v2.37 on QEMU
v8.1.2

[Bug target/112578] LoongArch: Wrong code -with -mlsx -fno-fp-int-builtin-inexact

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

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

Xi Ruoyao  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-Novembe
   ||r/637097.html
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=107723
   Keywords||patch

--- Comment #3 from Xi Ruoyao  ---
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637097.html

This fixes most of -ml[a]sx -fno-fp-int-builtin-inexact issues on LoongArch,
except PR107723.

[Bug c++/112596] New: GCC regex error in

[svraghavan7 at gmail dot com via Gcc-bugs]

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

Bug ID: 112596
   Summary: GCC regex error in
   Product: gcc
   Version: 9.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: svraghavan7 at gmail dot com
  Target Milestone: ---

Created attachment 56623
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56623=edit
Gdb Output trace

I have a plugin code which is developed using Opentelemetry C++ where the code
is running fine on gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) when i
deploy the same code in gcc 9.5.0 or 11.4 (Ubuntu 9.5.0-1ubuntu1~22.04)  the
plugin is generating following error.

terminate called after throwing an instance of '
std::bad_alloc'
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc  what():  std::bad_alloc

at the stage of executing this code
std::__cxx11::basic_regex
>::basic_regex, std::allocator
>(std::__cxx11::basic_string, std::allocator
> const&, std::regex_constants::syntax_option_type)

[Bug middle-end/112552] [14 Regression] ICE: in expand_insn, at optabs.cc:8305

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Robin Dapp :

https://gcc.gnu.org/g:231bb992592a9e1bd7ce6583131acb1874c8e34e

commit r14-5564-g231bb992592a9e1bd7ce6583131acb1874c8e34e
Author: Robin Dapp 
Date:   Thu Nov 16 20:42:10 2023 +0100

vect: Pass truth type to vect_get_vec_defs.

For conditional operations the mask is loop invariant and cannot be
stored explicitly.  By default, for reductions, we deduce the vectype
from the statement or the loop but this does not work for conditional
operations.  Therefore this patch passes the truth type of the reduction
input vectype for the mask operand instead.  This will override the
other choices and make sure we have the proper mask vectype.

gcc/ChangeLog:

PR middle-end/112406
PR middle-end/112552

* tree-vect-loop.cc (vect_transform_reduction): Pass truth
vectype for mask operand.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/pr112406.c: New test.
* gcc.target/riscv/rvv/autovec/pr112552.c: New test.

[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with on internal compiler error: in expand_insn, at optabs.cc:8305 after g:01c18f58d37865d5f3bbe93e666183b54ec608c7

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

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Robin Dapp :

https://gcc.gnu.org/g:231bb992592a9e1bd7ce6583131acb1874c8e34e

commit r14-5564-g231bb992592a9e1bd7ce6583131acb1874c8e34e
Author: Robin Dapp 
Date:   Thu Nov 16 20:42:10 2023 +0100

vect: Pass truth type to vect_get_vec_defs.

For conditional operations the mask is loop invariant and cannot be
stored explicitly.  By default, for reductions, we deduce the vectype
from the statement or the loop but this does not work for conditional
operations.  Therefore this patch passes the truth type of the reduction
input vectype for the mask operand instead.  This will override the
other choices and make sure we have the proper mask vectype.

gcc/ChangeLog:

PR middle-end/112406
PR middle-end/112552

* tree-vect-loop.cc (vect_transform_reduction): Pass truth
vectype for mask operand.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/pr112406.c: New test.
* gcc.target/riscv/rvv/autovec/pr112552.c: New test.

[Bug middle-end/112584] Suboptimal stack usage on third memcpy

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/112590] structural constexpr class fails to instantiate

[janezz55 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Janez Zemva  ---
Sorry for my last comment. I have prepared a more involved example:

https://github.com/user1095108/ca/blob/master/consttests.cpp

If

test();

is commented out, everything compiles, otherwise not.

[Bug c++/112590] structural constexpr class fails to instantiate

[janezz55 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Janez Zemva  ---
Very nice, but if I write:

int main()
{
  static constexpr S<10> s;
  return 0;
}

there will still be a compile error.

[Bug middle-end/112589] man gcc does not specify the default behavior of -fcf-protection when used without arguments

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-11-17

--- Comment #1 from Andrew Pinski  ---
Looks like it has been undocumented since the documentation was added in
r8-3997-g771c6b44dd0353 .

Note the option itself was added in r8-3995-g5c5f0b65eebe36 .

```
fcf-protection
Common RejectNegative Alias(fcf-protection=,full)

fcf-protection=
Common Joined RejectNegative Enum(cf_protection_level) EnumSet
Var(flag_cf_protection) Init(CF_NONE)
-fcf-protection=[full|branch|return|none|check] Instrument functions with
checks to verify jump/call/return control-flow transfer
instructions have valid targets.

```
https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-fcf-protection


Confirmed.

[Bug c++/112590] structural constexpr class fails to instantiate

[mital at mitalashok dot co.uk via Gcc-bugs]

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

Mital Ashok  changed:

   What|Removed |Added

 CC||mital at mitalashok dot co.uk

--- Comment #1 from Mital Ashok  ---
See [temp.arg.nontype]p3
:

> For a non-type template-parameter of reference type, or for each non-static
> data member of reference or pointer type in a non-type template-parameter
> of class type or subobject thereof, the reference or pointer value shall
> not refer to or be the address of (respectively):
>  - A temporary object,
>  - [...]
>  - a subject of one of the above.

And "f_{a_}" is initializing the pointer as a subobject of a temporary
object, so this is invalid. Though the error given might be wrong or
misleading.

[Bug c++/112595] New: ICE on invalid code: Literal class NTTP aggregate initialized with self-referential pointer

[mital at mitalashok dot co.uk via Gcc-bugs]

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

Bug ID: 112595
   Summary: ICE on invalid code: Literal class NTTP aggregate
initialized with self-referential pointer
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mital at mitalashok dot co.uk
  Target Milestone: ---

This code is invalid because it tries to create a NTTP with a pointer to a
temporary object:



struct S {
S* self = this;
};

template
void f() {}

int main() {
f();
}

With either -std=c++20 or -std=c++23, this causes an internal compiler error:

: In function 'int main()':
:9:11: error: no matching function for call to 'f()'
9 | f();
  | ~~^~
:6:6: note: candidate: 'template void f()'
6 | void f() {}
  |  ^
:6:6: note:   template argument deduction/substitution failed:
:9:9: internal compiler error: in cxx_eval_constant_expression, at
cp/constexpr.cc:8236
9 | f();
  | ^
0x26a4c3e internal_error(char const*, ...)
???:0
0xb0affd fancy_abort(char const*, int, char const*)
???:0
0xb77c23 cxx_constant_value(tree_node*, tree_node*, int)
???:0
0xd1580b coerce_template_parms(tree_node*, tree_node*, tree_node*, int, bool)
???:0
0xd440fc fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
???:0
0xb3a13d build_new_function_call(tree_node*, vec**, int)
???:0
0xd6991c finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0xcf5ac9 c_parse_file()
???:0
0xe37da9 c_common_parse_file()
???:0

This ICE doesn't happen if aggregate initialization isn't used (Changing to
`f()` or adding `constexpr S() = default;`)

[Bug c++/112594] New: Non-type template parameter created with converting constructor sometimes has original type

[mital at mitalashok dot co.uk via Gcc-bugs]

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

Bug ID: 112594
   Summary: Non-type template parameter created with converting
constructor sometimes has original type
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mital at mitalashok dot co.uk
  Target Milestone: ---

The following code complains that `N` (which was declared `n N`) is `3` (of
type `int`) instead of `n(3)`:



template
concept C = true;

struct n {
constexpr n(int) {}
static int i;
};

template
using get_n_i_type = decltype(N.i);

template
int f() {
using iii = get_n_i_type;
#if 1  // Change to 0 and this compiles
static_assert(C);
#endif
return iii{};
}

template int f<3>();

Compiler error given:

: In instantiation of 'int f() [with int X = 3]':
:21:19:   required from here
   21 | template int f<3>();
  |   ^
:10:33: error: request for member 'i' in '3', which is of non-class
type 'int'
   10 | using get_n_i_type = decltype(N.i);
  |   ~~^

This compiles fine if Clang and MSVC or if you remove the static_assert or
change `template` to `template`.

[Bug libstdc++/112591] variant allows for creating multiple empty objects at same address

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

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

--- Comment #2 from Jonathan Wakely  ---
Ug. The C++20 behaviour is correct, but fixing it for C++17 is an ABI
change. I think we need to do it though.

It should work to change the C++17 variant to use a union of
__aligned_membuf and Empty, and then just ignore the latter (or maybe we
can use the C++20 impl for C++17 too?)

This is a more general problem with __aligned_membuf, it's just that
std::variant is probably the only place you can trigger it, because you can't
have a data member of types such as _Rb_tree_node. We could change
aligned_membuf to use a union internally, so that anything using aligned_membuf
avoids having the same problem.

[Bug libstdc++/112593] New: FAIL: 26_numerics/headers/cmath/equivalent_functions.cc on Solaris 11.3

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

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

Bug ID: 112593
   Summary: FAIL:
26_numerics/headers/cmath/equivalent_functions.cc on
Solaris 11.3
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---
Target: sparc-sun-solaris2.11

/export/home/jwakely/src/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/equivalent_functions.cc:197:
void test_long_double_overload(): Assertion 'std::cosh(x) == std::coshl(x)'
failed.


std::cosh is provided by
/export/home/jwakely/build/gcc/include-fixed/iso/math_iso.h which has:

namespace std {
...
extern long double __coshl(long double);
...
inline long double cosh(long double __X) { return __coshl(__X); }


std::coshl is provided by libstdc++'s  (since r14-5341-g0b880466e910b4)
which does:

using std::coshl;

That finds ::coshl from /export/home/jwakely/build/gcc/include-fixed/math.h:

extern long double coshl (long double);


That means that Solaris provides both ::coshl and also std::__coshl, and they
return different values for cosh(1.0):

std::cosh(x)= 1.5430806348152437784779056207570615
std::__coshl(x) = 1.5430806348152437784779056207570615
std::coshl(x)   = 1.5430806348152437784779056207570617

The first two match, as expected because std::cosh just calls std::__coshl.

I don't know why Solaris provides two different implementations of coshl.

[Bug c++/112592] New: FAIL: c-c++-common/pr111309-1.c -std=gnu++14 (internal compiler error: in expand_fn_using_insn, at internal-fn.cc:216)

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

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

Bug ID: 112592
   Summary: FAIL: c-c++-common/pr111309-1.c  -std=gnu++14
(internal compiler error: in expand_fn_using_insn, at
internal-fn.cc:216)
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../../xg++
-B/home/dave/gnu/gcc/objdir64/gcc/testsuite/g++/../../
/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/pr111309-1.c
-fdiagnostics-plain-output -nostdinc++
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++14 -O2
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs
-B/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir64/hppa64-hp-hpux11.11/./libstdc++-v3/src/experimental/.libs
-lm -o ./pr111309-1.exe
during RTL pass: expand
/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/pr111309-1.c: In function
'int clzI(__int128 unsigned)':
/home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/pr111309-1.c:69:27: internal
compiler error: in expand_fn_using_insn, at internal-fn.cc:216
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
compiler exited with status 1
FAIL: c-c++-common/pr111309-1.c  -std=gnu++14 (internal compiler error: in
expand_fn_using_insn, at internal-fn.cc:216)
FAIL: c-c++-common/pr111309-1.c  -std=gnu++14 (test for excess errors)

Breakpoint 1, expand_fn_using_insn (stmt=0x83ffbff071b0,
icode=CODE_FOR_nothing, ninputs=1, noutputs=1)
at ../../gcc/gcc/internal-fn.cc:216
216   gcc_assert (icode != CODE_FOR_nothing);
(gdb) p icode
$1 = CODE_FOR_nothing
(gdb) bt
#0  expand_fn_using_insn (stmt=0x83ffbff071b0, icode=CODE_FOR_nothing,
ninputs=1, noutputs=1) at ../../gcc/gcc/internal-fn.cc:216
#1  0x40c55dd4 in expand_direct_optab_fn (fn=,
stmt=0x83ffbff071b0, optab=clz_optab, nargs=1)
at ../../gcc/gcc/internal-fn.cc:3817
#2  0x40c55ee0 in expand_CLZ (fn=,
stmt=) at ../../gcc/gcc/internal-fn.def:431
#3  0x40c63918 in expand_internal_call (stmt=,
fn=) at ../../gcc/gcc/internal-fn.cc:4920
#4  expand_internal_call (stmt=)
at ../../gcc/gcc/internal-fn.cc:4928
#5  0x409dacd8 in expand_call_stmt (stmt=0x83ffbff071b0)
at ../../gcc/gcc/cfgexpand.cc:2737
#6  expand_gimple_stmt_1 (stmt=0x83ffbff071b0)
at ../../gcc/gcc/cfgexpand.cc:3880
#7  expand_gimple_stmt (stmt=0x83ffbff071b0)
at ../../gcc/gcc/cfgexpand.cc:4044
#8  0x409db63c in expand_gimple_tailcall (bb=0x83ffbff071b0,
stmt=0x69, can_fallthru=0x83ffbfb00508)
at ../../gcc/gcc/cfgexpand.cc:4090
#9  0x409e3c98 in expand_gimple_basic_block (
disable_tail_calls=, bb=)
at ../../gcc/gcc/cfgexpand.cc:6074
---Type  to continue, or q  to quit---
#10 (anonymous namespace)::pass_expand::execute (this=,
fun=) at ../../gcc/gcc/cfgexpand.cc:6835
#11 0x40e4f508 in execute_one_pass (pass=0x83ffbff071b0)
at ../../gcc/gcc/passes.cc:2641
#12 0x40e50088 in execute_pass_list_1 (pass=0x83ffbff071b0)
at ../../gcc/gcc/passes.cc:2750
#13 0x40e50120 in execute_pass_list (fn=,
pass=) at ../../gcc/gcc/passes.cc:2761
#14 0x40a27844 in expand (this=0x83ffbff071b0)
at ../../gcc/gcc/context.h:48
#15 cgraph_node::expand (this=0x83ffbff071b0)
at ../../gcc/gcc/cgraphunit.cc:1794
#16 0x40a29fe4 in expand_all_functions ()
at ../../gcc/gcc/cgraphunit.cc:2022
#17 symbol_table::compile (this=0x45043) at ../../gcc/gcc/cgraphunit.cc:2398
#18 0x40a2c9e4 in compile (this=0x1)
at ../../gcc/gcc/cgraphunit.cc:2583
#19 symbol_table::finalize_compilation_unit (this=0x1)
at ../../gcc/gcc/cgraphunit.cc:2583
#20 0x40f92b78 in compile_file () at ../../gcc/gcc/toplev.cc:473
#21 0x in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

[Bug libstdc++/112591] variant allows for creating multiple empty objects at same address

[barry.revzin at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Barry Revzin  ---
Basically, in C++17, Sub looks like this:

struct Sub17 : Empty {
aligned_membuf storage;
unsigned char index;
};

But in C++20 it turns into:

struct Sub20 : Empty {
union { Empty storage; };
unsigned char index;
};

sizeof(Sub17) == 2 because of the empty base optimization, but sizeof(Sub20) ==
3 because now the language understands that storage is an Empty and thus needs
a distinct address from the Empty base class.

[Bug libstdc++/112591] New: variant allows for creating multiple empty objects at same address

[barry.revzin at gmail dot com via Gcc-bugs]

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

Bug ID: 112591
   Summary: variant allows for creating multiple empty objects at
same address
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Consider:

#include 
#include 

struct Empty { ~Empty() {} };
struct Sub : Empty { std::variant e; };

int main() {
Sub v;

Empty* base = 
Empty* obj = ::get(v.e);

std::cout
<< "base=" << (void*)base
<< " obj=" << (void*)obj
<< " matches=" << (base == obj)
<< '\n';
}

In C++17 mode on trunk, base and obj have the same address.
In C++20 mode up through 11.4, they have the same address. Since 12.1, they do
not.

If Empty were trivially destructible, they never have the same address.

[Bug c++/112590] New: structural constexpr class fails to instantiate

[janezz55 at gmail dot com via Gcc-bugs]

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

Bug ID: 112590
   Summary: structural constexpr class fails to instantiate
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janezz55 at gmail dot com
  Target Milestone: ---

Compiling:

#include 

template  void test() {}

template 
struct S
{
  int a_[N];
  int* f_;
  constexpr S(): a_{}, f_{a_} {}
};

int main()
{
  test{}>();
  return 0;
}

fails with:

prog.cc: In function 'int main()':
prog.cc:18:16: error: no matching function for call to 'test()>()'
   18 |   test{}>();
  |   ~^~
prog.cc:4:6: note: candidate: 'template void test()'
4 | void test()
  |  ^~~~
prog.cc:4:6: note:   template argument deduction/substitution failed:
prog.cc:18:16: error: 'S<10>{int [10](), ((int*)(&.S<10>::a_))}' is
not a constant expression
   18 |   test{}>();
  |   ~^~
prog.cc:18:16: error: 'S<10>()' is not a constant expression because it refers
to an incompletely initialized variable

But everything is initialized. I believe a workaround exists, but I didn't
experiment.

https://wandbox.org/permlink/xA81TIzI5XsXdh57

[Bug c++/107571] Missing fallthrough attribute diagnostics

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Should be implemented now.

[Bug c++/107571] Missing fallthrough attribute diagnostics

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:52eedfa00960f2d255ec542626e3531a65aa8bb8

commit r14-5561-g52eedfa00960f2d255ec542626e3531a65aa8bb8
Author: Jakub Jelinek 
Date:   Fri Nov 17 15:43:31 2023 +0100

c++: Implement C++ DR 2406 - [[fallthrough]] attribute and iteration
statements

The following patch implements
CWG 2406 - [[fallthrough]] attribute and iteration statements
The genericization of some loops leaves nothing at all or just a label
after a body of a loop, so if the loop is later followed by
case or default label in a switch, the fallthrough statement isn't
diagnosed.

The following patch implements it by marking the IFN_FALLTHROUGH call
in such a case, such that during gimplification it can be pedantically
diagnosed even if it is followed by case or default label or some normal
labels followed by case/default labels.

While looking into this, I've discovered other problems.
expand_FALLTHROUGH_r is removing the IFN_FALLTHROUGH calls from the IL,
but wasn't telling that to walk_gimple_stmt/walk_gimple_seq_mod, so
the callers would then skip the next statement after it, and it would
return non-NULL if the removed stmt was last in the sequence.  This could
lead to wi->callback_result being set even if it didn't appear at the very
end of switch sequence.
The patch makes use of wi->removed_stmt such that the callers properly
know what happened, and use different way to handle the end of switch
sequence case.

That change discovered a bug in the gimple-walk handling of
wi->removed_stmt.  If that flag is set, the callback is telling the callers
that the current statement has been removed and so the innermost
walk_gimple_seq_mod shouldn't gsi_next.  The problem is that
wi->removed_stmt is only reset at the start of a walk_gimple_stmt, but that
can be too late for some cases.  If we have two nested gimple sequences,
say GIMPLE_BIND as the last stmt of some gimple seq, we remove the last
statement inside of that GIMPLE_BIND, set wi->removed_stmt there, don't
do gsi_next correctly because already gsi_remove moved us to the next stmt,
there is no next stmt, so we return back to the caller, but
wi->removed_stmt
is still set and so we don't do gsi_next even in the outer sequence,
despite
the GIMPLE_BIND (etc.) not being removed.  That means we walk the
GIMPLE_BIND with its whole sequence again.
The patch fixes that by resetting wi->removed_stmt after we've used that
flag in walk_gimple_seq_mod.  Nothing really uses that flag after the
outermost walk_gimple_seq_mod, it is just a private notification that
the stmt callback has removed a stmt.

2023-11-17  Jakub Jelinek  

PR c++/107571
gcc/
* gimplify.cc (expand_FALLTHROUGH_r): Use wi->removed_stmt after
gsi_remove, change the way of passing fallthrough stmt at the end
of sequence to expand_FALLTHROUGH.  Diagnose IFN_FALLTHROUGH
with GF_CALL_NOTHROW flag.
(expand_FALLTHROUGH): Change loc into array of 2 location_t elts,
don't test wi.callback_result, instead check whether first
elt is not UNKNOWN_LOCATION and in that case pedwarn with the
second location.
* gimple-walk.cc (walk_gimple_seq_mod): Clear wi->removed_stmt
after the flag has been used.
* internal-fn.def (FALLTHROUGH): Mention in comment the special
meaning of the TREE_NOTHROW/GF_CALL_NOTHROW flag on the calls.
gcc/c-family/
* c-gimplify.cc (genericize_c_loop): For C++ mark IFN_FALLTHROUGH
call at the end of loop body as TREE_NOTHROW.
gcc/testsuite/
* g++.dg/DRs/dr2406.C: New test.

[Bug other/112589] New: man gcc does not specify the default behavior of -fcf-protection when used without arguments

[ago at gentoo dot org via Gcc-bugs]

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

Bug ID: 112589
   Summary: man gcc does not specify the default behavior of
-fcf-protection when used without arguments
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ago at gentoo dot org
  Target Milestone: ---

man gcc says:

-fcf-protection=[full|branch|return|none|check]

However, at runtime, you can use -fcf-protection without any arguments, but the
manual does not specify what is the default behavior in case of missing
argument.

[Bug c++/112588] New: ICE in make_decl_rtl when returning str literal when string header imported in module

[nickbegg at gmail dot com via Gcc-bugs]

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

Bug ID: 112588
   Summary: ICE in make_decl_rtl when returning str literal when
string header imported in module
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nickbegg at gmail dot com
  Target Milestone: ---

Created attachment 56622
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56622=edit
-freport-bug output

/home/nick/gcc-trunk-debug-inst/include/c++/14.0.0/bits/allocator.h:191:39:
internal compiler error: in make_decl_rtl, at varasm.cc:1442
  191 | if (__builtin_mul_overflow(__n, sizeof(_Tp), &__n))
  | ~~^~~~

Using when importing a module into a non-module TU, #including string in both
causes an ICE when returning a string literal in a function with std::string
return type -


// modA.mpp (compiled as module):

module;

#include 

export module modA;

///
// main.cpp (compiled as regular TU): 

#include 

import modA;

std::string test_func() {
return "foo";
}

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

The ICE happens when compiling main.cpp.

Removing the import from main.cpp, or returning std::string() from test_func()
stops the ICE. 

GCC trunk (14) version, git rev ba3f5b8465ef7b278ea33ff94cd85b9638058635

[Bug tree-optimization/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/83171] __builtin_popcountl ((unsigned long long)unsigned_var) is not being optimized to __builtin_popcount (unsigned_var)

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:6dd4c703be17fa5dd56136d067e7fdc4a61584b3

commit r14-5557-g6dd4c703be17fa5dd56136d067e7fdc4a61584b3
Author: Jakub Jelinek 
Date:   Fri Nov 17 15:10:51 2023 +0100

match.pd: Optimize ctz/popcount/parity/ffs on extended argument [PR112566]

ctz(ext(X)) is the same as ctz(X) in the UB on zero case (or could be also
in the 2 argument case on large BITINT_TYPE by preserving the argument, not
implemented in this patch),
popcount(zext(X)) is the same as popcount(X),
parity(zext(X)) is the same as parity(X),
parity(sext(X)) is the same as parity(X) provided the bit difference
between
the extended and unextended types is even,
ffs(ext(X)) is the same as ffs(X).

The following patch optimizes those in match.pd if those are beneficial
(always in the large BITINT_TYPE case, or if the narrower type has optab
and the wider doesn't, or the wider is larger than word and narrower is
one of the standard argument sizes (tested just int and long long, as
long is on most targets same bitsize as one of those two).

Joseph in the PR mentioned that ctz(narrow(X)) is the same as ctz(X)
if UB on 0, but that can be handled incrementally (and would need different
decisions when it is profitable).
And clz(zext(X)) is clz(X) + bit_difference, but not sure we want to change
that in match.pd at all, perhaps during insn selection?

2023-11-17  Jakub Jelinek  

PR tree-optimization/112566
PR tree-optimization/83171
* match.pd (ctz(ext(X)) -> ctz(X), popcount(zext(X)) ->
popcount(X),
parity(ext(X)) -> parity(X), ffs(ext(X)) -> ffs(X)): New
simplifications.
( __builtin_ffs (X) == 0 -> X == 0): Use FFS rather than
BUILT_IN_FFS BUILT_IN_FFSL BUILT_IN_FFSLL BUILT_IN_FFSIMAX.

* gcc.dg/pr112566-1.c: New test.
* gcc.dg/pr112566-2.c: New test.
* gcc.target/i386/pr78057.c (foo): Pass another long long argument
and use it in __builtin_ia32_*zcnt_u64 instead of the int one.

[Bug tree-optimization/112566] Some ctz/popcount/parity/ffs optimizations

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:6dd4c703be17fa5dd56136d067e7fdc4a61584b3

commit r14-5557-g6dd4c703be17fa5dd56136d067e7fdc4a61584b3
Author: Jakub Jelinek 
Date:   Fri Nov 17 15:10:51 2023 +0100

match.pd: Optimize ctz/popcount/parity/ffs on extended argument [PR112566]

ctz(ext(X)) is the same as ctz(X) in the UB on zero case (or could be also
in the 2 argument case on large BITINT_TYPE by preserving the argument, not
implemented in this patch),
popcount(zext(X)) is the same as popcount(X),
parity(zext(X)) is the same as parity(X),
parity(sext(X)) is the same as parity(X) provided the bit difference
between
the extended and unextended types is even,
ffs(ext(X)) is the same as ffs(X).

The following patch optimizes those in match.pd if those are beneficial
(always in the large BITINT_TYPE case, or if the narrower type has optab
and the wider doesn't, or the wider is larger than word and narrower is
one of the standard argument sizes (tested just int and long long, as
long is on most targets same bitsize as one of those two).

Joseph in the PR mentioned that ctz(narrow(X)) is the same as ctz(X)
if UB on 0, but that can be handled incrementally (and would need different
decisions when it is profitable).
And clz(zext(X)) is clz(X) + bit_difference, but not sure we want to change
that in match.pd at all, perhaps during insn selection?

2023-11-17  Jakub Jelinek  

PR tree-optimization/112566
PR tree-optimization/83171
* match.pd (ctz(ext(X)) -> ctz(X), popcount(zext(X)) ->
popcount(X),
parity(ext(X)) -> parity(X), ffs(ext(X)) -> ffs(X)): New
simplifications.
( __builtin_ffs (X) == 0 -> X == 0): Use FFS rather than
BUILT_IN_FFS BUILT_IN_FFSL BUILT_IN_FFSLL BUILT_IN_FFSIMAX.

* gcc.dg/pr112566-1.c: New test.
* gcc.dg/pr112566-2.c: New test.
* gcc.target/i386/pr78057.c (foo): Pass another long long argument
and use it in __builtin_ia32_*zcnt_u64 instead of the int one.

[Bug tree-optimization/112374] [14 Regression] Failed bootstrap with `--with-arch=skylake-avx512 --with-cpu=skylake-avx512`, causes a comparison failure since r14-5076-g01c18f58d37865d5f3bbe93e666183b

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

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

--- Comment #48 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:172a72da368146e0fe34194020eb7a6636db4438

commit r14-5556-g172a72da368146e0fe34194020eb7a6636db4438
Author: Jakub Jelinek 
Date:   Fri Nov 17 15:09:44 2023 +0100

vect: Fix check_reduction_path [PR112374]

As mentioned in the PR, the intent of the r14-5076 changes was that
it doesn't count one of the uses on the use_stmt, but what actually
got implemented is that it does this processing on any op_use_stmt,
even if it is not the use_stmt statement, which means that it
can increase count even on debug stmts (-fcompare-debug failures),
or if there would be some other use stmt with 2+ uses it could count
that as a single use.  Though, because it fails whenever cnt != 1
and I believe use_stmt must be one of the uses, it would probably
fail in the latter case anyway.

The following patch fixes that by doing this extra processing only when
op_use_stmt is use_stmt, and using the normal processing otherwise
(so ignore debug stmts, and increase on any uses on the stmt).

2023-11-17  Jakub Jelinek  

PR tree-optimization/112374
* tree-vect-loop.cc (check_reduction_path): Perform the cond_fn_p
special case only if op_use_stmt == use_stmt, use as_a rather than
dyn_cast in that case.

* gcc.dg/pr112374-1.c: New test.
* gcc.dg/pr112374-2.c: New test.
* g++.dg/opt/pr112374.C: New test.

[Bug tree-optimization/112281] [12/13/14 Regression] wrong code at -O3 on x86_64-linux-gnu since r12-2097-g9f34b780b0461e

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

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

Bug 112585 Summary: [14 Regression] wrong code at -O3 on x86_64-linux-gnu since 
r14-5444
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112585

   What|Removed |Added

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

[Bug tree-optimization/112585] [14 Regression] wrong code at -O3 on x86_64-linux-gnu since r14-5444

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Fixed.  r14-5444-g5ea2965b499f9e reverted.

[Bug tree-optimization/112585] [14 Regression] wrong code at -O3 on x86_64-linux-gnu since r14-5444

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

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

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

https://gcc.gnu.org/g:04abafe9831f6867af1211ecae853ff373235b2d

commit r14--g04abafe9831f6867af1211ecae853ff373235b2d
Author: Richard Biener 
Date:   Fri Nov 17 14:49:06 2023 +0100

tree-optimization/112585 - new testcase

The offending commit r14-5444-g5ea2965b499f9e was reverted.  The
following adds a testcase.

PR tree-optimization/112585
* gcc.dg/torture/pr112585.c: New testcase.

[Bug tree-optimization/112281] [12/13/14 Regression] wrong code at -O3 on x86_64-linux-gnu since r12-2097-g9f34b780b0461e

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[12/13 Regression] wrong|[12/13/14 Regression] wrong
   |code at -O3 on  |code at -O3 on
   |x86_64-linux-gnu since  |x86_64-linux-gnu since
   |r12-2097-g9f34b780b0461e|r12-2097-g9f34b780b0461e
  Known to work|14.0|

--- Comment #9 from Richard Biener  ---
The fix was wrong and reverted.

[Bug target/111657] Memory copy with structure assignment from named address space should be improved

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #8)
> I'd say it is a user error to invoke memcpy/memset etc. with pointers to
> non-default address spaces, and for aggregate copies the middle-end should
> ensure that the copying is not done using library calls; is that the case
> and the problem was just that optab expansion was allowed for the structure
> copies and the backend decided to use libcall in that case?

Yes, the stringop selection mechanism chose libcall strategy. However, the call
to memcpy is unavailable for non-default address space, so the middle-end
expanded the call into most trivial byte-copy loop. The patch just teaches
stringop selection to use optimized copy loop as a last resort with non-default
address spaces instead.

[Bug target/112537] Is there a way to disable cpymem pass for rvv

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

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

--- Comment #13 from Jorn Wolfgang Rennecke  ---
Before we can consider any costs, we first have to know what they are.  Is
there any manual for a hardware implementation that specifies costs?

[Bug target/112537] Is there a way to disable cpymem pass for rvv

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

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

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

 CC||amylaar at gcc dot gnu.org

--- Comment #12 from Jorn Wolfgang Rennecke  ---
(In reply to JuzheZhong from comment #2)
> Currently, we don't have a compile option to disable cpymem by RVV.

If you don't want any vector instructions to be emitted, why do you tell the
compiler to enable the 'v' extsnsion of the architecture?

[Bug target/53372] [avr] Section attribute ignored with address space

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||addr-space
   Target Milestone|--- |13.3
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Georg-Johann Lay  ---
Fixed in v13.3+

[Bug target/53372] [avr] Section attribute ignored with address space

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

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Georg-Johann Lay
:

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

commit r13-8080-gadb1f8b0eda99e8a1d21bda5955cbe1df5517e63
Author: Georg-Johann Lay 
Date:   Fri Nov 17 12:51:16 2023 +0100

PR target/53372: Don't ignore section attribute with address-space.

gcc/
PR target/53372
* config/avr/avr.cc (avr_asm_named_section) [AVR_SECTION_PROGMEM]:
Only return some .progmem*.data section if the user did not
specify a section attribute.
(avr_section_type_flags) [avr_progmem_p]: Unset SECTION_NOTYPE
in returned section flags.

gcc/testsuite/
PR target/53372
* gcc.target/avr/pr53372-1.c: New test.
* gcc.target/avr/pr53372-2.c: New test.

(cherry picked from commit 68221c54a9752dbf131c231413edfd21046f8dad)

[Bug c++/112587] -save-temps with p1689 dep output causes null ptr dereference

[nickbegg at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Nick Begg  ---
Created attachment 56621
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56621=edit
Full output from invocation

[Bug c++/112587] -save-temps with p1689 dep output causes null ptr dereference

[nickbegg at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Nick Begg  ---
Created attachment 56620
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56620=edit
preprocessed source

[Bug c++/112587] New: -save-temps with p1689 dep output causes null ptr dereference

[nickbegg at gmail dot com via Gcc-bugs]

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

Bug ID: 112587
   Summary: -save-temps with p1689 dep output causes null ptr
dereference
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nickbegg at gmail dot com
  Target Milestone: ---

Whilst debugging a separate bug with a trivial module, GCC crashes with a null
ptr dereference. I have --save-temps on.

The problem seems to start here:

gcc/c-family/c-opts.cc:1340
  fatal_error (input_location, "%<-MF%> and %<-fdeps-file=%> cannot share an
output file %s: %m", fdeps_file);

The cc1plus process looks like it's not invoked with -fdeps-file, and thus
fdeps_file is null. Printing this diagnostic causes a crash. It seems to crash
before a bug report is written out.

This is the version -

GNU C++23 (GCC) version 14.0.0 20231117 (experimental) (x86_64-pc-linux-gnu)
(git rev ba3f5b8465ef7b278ea33ff94cd85b9638058635)

This is the cmdline used to launch gcc  (launched from cmake/ninja) -

/home/nick/gcc-trunk-debug-inst/bin/g++ -D_GLIBCXX_ASSERTIONS -D_GLIBCXX_DEBUG 
-std=gnu++23 -Wall -Wextra -v -freport-bug -save-temps -MD -MT
CMakeFiles/moduleMin.dir/modA.mpp.o -MF CMakeFiles/moduleMin.dir/modA.mpp.o.d
-fmodules-ts -fmodule-mapper=CMakeFiles/moduleMin.dir/modA.mpp.o.modmap -MD
-fdeps-format=p1689r5 -x c++ -o CMakeFiles/moduleMin.dir/modA.mpp.o -c
/home/nick/src/moduleMin/modA.mpp

... and the cmdline to launch cc1plus which crashes -

 /home/nick/gcc-trunk-debug-inst/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/cc1plus
-fpreprocessed CMakeFiles/moduleMin.dir/modA.mpp.ii -quiet -dumpdir
CMakeFiles/moduleMin.dir/ -dumpbase modA.mpp.mpp -dumpbase-ext .mpp
-mtune=generic -march=x86-64 -Wall -Wextra -std=gnu++23 -version -freport-bug
-fmodules-ts -fmodule-mapper=CMakeFiles/moduleMin.dir/modA.mpp.o.modmap
-fdeps-format=p1689r5 -o CMakeFiles/moduleMin.dir/modA.mpp.s

[Bug target/111657] Memory copy with structure assignment from named address space should be improved

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
I'd say it is a user error to invoke memcpy/memset etc. with pointers to
non-default address spaces, and for aggregate copies the middle-end should
ensure that the copying is not done using library calls; is that the case and
the problem was just that optab expansion was allowed for the structure copies
and the backend decided to use libcall in that case?

[Bug target/53372] [avr] Section attribute ignored with address space

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

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

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

https://gcc.gnu.org/g:68221c54a9752dbf131c231413edfd21046f8dad

commit r14-5552-g68221c54a9752dbf131c231413edfd21046f8dad
Author: Georg-Johann Lay 
Date:   Fri Nov 17 12:51:16 2023 +0100

PR target/53372: Don't ignore section attribute with address-space.

gcc/
PR target/53372
* config/avr/avr.cc (avr_asm_named_section) [AVR_SECTION_PROGMEM]:
Only return some .progmem*.data section if the user did not
specify a section attribute.
(avr_section_type_flags) [avr_progmem_p]: Unset SECTION_NOTYPE
in returned section flags.

gcc/testsuite/
PR target/53372
* gcc.target/avr/pr53372-1.c: New test.
* gcc.target/avr/pr53372-2.c: New test.

[Bug target/112578] LoongArch: Wrong code -with -mlsx -fno-fp-int-builtin-inexact

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #2 from chenglulu  ---
(In reply to Xi Ruoyao from comment #1)
> I've made a patch and it's under testing.
> 
> I've seen some "random" gcc.dg/torture/builtin-fp-int-inexact.c failures
> recently but maybe it's not related, we don't enable LSX/LASX compiling it
> anyway...  But who knows.

This problem of random errors has always existed．This is a known problem．

[Bug target/112578] LoongArch: Wrong code -with -mlsx -fno-fp-int-builtin-inexact

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

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

Xi Ruoyao  changed:

   What|Removed |Added

   Last reconfirmed||2023-11-17
   See Also||https://github.com/loongson
   ||-community/discussions/issu
   ||es/7
   Keywords||wrong-code
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |xry111 at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Xi Ruoyao  ---
I've made a patch and it's under testing.

I've seen some "random" gcc.dg/torture/builtin-fp-int-inexact.c failures
recently but maybe it's not related, we don't enable LSX/LASX compiling it
anyway...  But who knows.

[Bug middle-end/112581] [14 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (generated code hangs) since r14-4661

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
Summary|[14 Regression] wrong code  |[14 Regression] wrong code
   |at -O2 and -O3 on   |at -O2 and -O3 on
   |x86_64-linux-gnu (generated |x86_64-linux-gnu (generated
   |code hangs) |code hangs) since r14-4661

--- Comment #4 from Jakub Jelinek  ---
Started with r14-4661-g29a4453c7b8a86d242dab89b9e4d222749fd911e

[Bug tree-optimization/112585] wrong code at -O3 on x86_64-linux-gnu since r14-5444

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

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||112281
Version|unknown |14.0
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

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


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112281
[Bug 112281] [12/13 Regression] wrong code at -O3 on x86_64-linux-gnu since
r12-2097-g9f34b780b0461e

[Bug tree-optimization/112585] wrong code at -O3 on x86_64-linux-gnu since r14-5444

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

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

--- Comment #2 from Richard Biener  ---
Confirmed.  In .optimized all loops are unrolled and we have

  e.0_103 = e;
  _105 = (int) e.0_103;
  a[2] = _105;
...
  _7 = a[2];
  if (_7 != 1)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

loop distribution splits the loop, putting a loop with just a[f] = 1 first.
I think that's wrong.  Related to PR112281, here we have a zero distance
for the inner loop.

[Bug tree-optimization/112585] wrong code at -O3 on x86_64-linux-gnu since r14-5444

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Summary|wrong code at -O3 on|wrong code at -O3 on
   |x86_64-linux-gnu|x86_64-linux-gnu since
   ||r14-5444
 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Last reconfirmed||2023-11-17
   Target Milestone|--- |14.0
 Ever confirmed|0   |1
   Priority|P3  |P1

--- Comment #1 from Jakub Jelinek  ---
Started with r14-5444-g5ea2965b499f9e491e45db19fedbccfccb75076a

[Bug fortran/112586] New: [F2023] Add "A statement shall not have more than one million characters." warning

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

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

Bug ID: 112586
   Summary: [F2023] Add "A statement shall not have more than one
million characters." warning
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

See also https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636868.html

GCC currently has a warning for:

  if (gfc_notification_std (GFC_STD_GNU) || pedantic)
gfc_warning (0, "Limit of %d continuations exceeded in "
 "statement at %C",

for both fixed and free form source code. This matches:

Fortran 2018's
  "A statement shall not have more than 255 continuation lines."


But Fortran 2023 now has:
  "A statement shall not have more than one million characters."

Where a 'statement' is "A Fortran statement is a sequence of one or more
complete or partial lines." - and a 'line' is: "sequence of zero or more
characters".


It is not completely clear to me in how far comments count; It seems as if
comment lines (blank lines or blanks followed by a comment) do not count - but
do in-line comments count? What about '&'?  Does a (partial) line start with
the first non-blank character or already at the first column? It probably ends
with '\n' and ';' and neither counts.

* * *

The parsing is done in scanner.cc's gfc_next_char_literal — as code is
reparsed,  i.e. gfc_current_locus can move to older code, we cannot simply
count the number of characters at "return c".

BTW: As scanner.cc currently does not handle ';', which had to be added in that
case.

Actually, it is not quite clear to me how the counting of continuation lines
works with 'gfc_current_locus = old_loc' handling. As long we only jump back in
the same line, it's fine - but I expect that reparsing might cause problems
with the count handling. This count is only used by warning above, but
nonetheless.

[Bug tree-optimization/112585] New: wrong code at -O3 on x86_64-linux-gnu

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 112585
   Summary: wrong code at -O3 on x86_64-linux-gnu
   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: ---

This appears to be a recent regression as it does not reproduce with 13.2. 

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


[563] % 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/14.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 14.0.0 20231117 (experimental) (GCC) 
[564] % 
[564] % gcctk -O2 small.c; ./a.out
[565] % 
[565] % gcctk -O3 small.c
[566] % ./a.out
Aborted
[567] % 
[567] % cat small.c
static int a[10], b;
char c, *d = , e;
int main() {
  int f = 0;
  for (; f < 9; f++) {
a[f] = 1;
a[f + 1] = e;
for (b = 0; b < 8; b++)
  *d = 0;
  }
  if (a[2] != 1)
__builtin_abort();
  return 0;
}

[Bug middle-end/112572] [14 regression] LLVM miscompiled since r14-5355-g3cd3a09b3f91a1

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

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

--- Comment #7 from Jakub Jelinek  ---
In any case, it would be useful to narrow it to a single CU, if you know
libLLVMCodeGen.so.17 is bad and have trees built by good vs. bad revision, take
the link line of that library, amend all .o objects with absolute paths to the
good objects in a text file, run that + test, then replace second half of the
paths with the ones to bad objects, etc.

[Bug tree-optimization/112584] New: Suboptimal stack usage on third memcpy

[antoshkka at gmail dot com via Gcc-bugs]

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

Bug ID: 112584
   Summary: Suboptimal stack usage on third memcpy
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Consider the example:


struct string_view {
const char* data;
unsigned long size;
};

void AppendToCharArray(char*& data, string_view s1, string_view s2, string_view
s3) {
  __builtin_memcpy(data, s1.data, s1.size);
  data += s1.size;

  __builtin_memcpy(data, s2.data, s2.size);
  data += s2.size;

  __builtin_memcpy(data, s3.data, s3.size);
  data += s3.size;
}


With -O2 it generates an assembly with 6 push and 6 pop instructions. However,
there's a better assembly possible:

  push r15
  push r14
  push r12
  push rbx
  push rax
  mov rbx, r8
  mov r14, rcx
  mov r15, rdx
  mov r12, rdi
  mov rdi, qword ptr [rdi]
  call memcpy
  add r15, qword ptr [r12]
  mov qword ptr [r12], r15
  mov rdi, r15
  mov rsi, r14
  mov rdx, rbx
  call memcpy
  add rbx, qword ptr [r12]
  mov qword ptr [r12], rbx
  mov rsi, qword ptr [rsp + 48]
  mov r14, qword ptr [rsp + 56]
  mov rdi, rbx
  mov rdx, r14
  call memcpy
  add qword ptr [r12], r14
  add rsp, 8
  pop rbx
  pop r12
  pop r14
  pop r15
  ret

Godbolt playground: https://godbolt.org/z/EY8E1GGPz

[Bug middle-end/112581] [14 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (generated code hangs)

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Uroš Bizjak  ---
(In reply to Andrew Pinski from comment #1)
> It might be one of the x86 specific target patches ...

I don't think so, these patches deal specifically with high registers, and:

$ grep %.h pr112581.s

finds none.

[Bug target/111449] memcmp (p,q,16) == 0 can be optimized better on ppc64 with vector comparison instructions

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

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

HaoChen Gui  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from HaoChen Gui  ---
Fixed

[Bug target/111449] memcmp (p,q,16) == 0 can be optimized better on ppc64 with vector comparison instructions

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by HaoChen Gui :

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

commit r14-5548-gcd295a80c91040fd4d826528c8e8e07fe909ae62
Author: Haochen Gui 
Date:   Fri Nov 17 17:12:32 2023 +0800

rs6000: Enable vector mode for by pieces equality compare

This patch adds a new expand pattern - cbranchv16qi4 to enable vector
mode by pieces equality compare on rs6000.  The macro MOVE_MAX_PIECES
(COMPARE_MAX_PIECES) is set to 16 bytes when EFFICIENT_UNALIGNED_VSX
is enabled, otherwise keeps unchanged.  The macro STORE_MAX_PIECES is
set to the same value as MOVE_MAX_PIECES by default, so now it's
explicitly defined and keeps unchanged.

gcc/
PR target/111449
* config/rs6000/altivec.md (cbranchv16qi4): New expand pattern.
* config/rs6000/rs6000.cc (rs6000_generate_compare): Generate
insn sequence for V16QImode equality compare.
* config/rs6000/rs6000.h (MOVE_MAX_PIECES): Define.
(STORE_MAX_PIECES): Define.

gcc/testsuite/
PR target/111449
* gcc.target/powerpc/pr111449-1.c: New.
* gcc.dg/tree-ssa/sra-17.c: Add additional options for 32-bit
powerpc.
* gcc.dg/tree-ssa/sra-18.c: Likewise.

--- Comment #4 from CVS Commits  ---
The master branch has been updated by HaoChen Gui :

https://gcc.gnu.org/g:10615c8a10d6b61e813254924d76be728dbd4688

commit r14-5549-g10615c8a10d6b61e813254924d76be728dbd4688
Author: Haochen Gui 
Date:   Fri Nov 17 17:17:59 2023 +0800

rs6000: Fix regression cases caused 16-byte by pieces move

The previous patch enables 16-byte by pieces move. Originally 16-byte
move is implemented via pattern.  expand_block_move does an optimization
on P8 LE to leverage V2DI reversed load/store for memory to memory move.
Now 16-byte move is implemented via by pieces move and finally split to
two DI load/store.  This patch creates an insn_and_split pattern to
retake the optimization.

gcc/
PR target/111449
* config/rs6000/vsx.md (*vsx_le_mem_to_mem_mov_ti): New.

gcc/testsuite/
PR target/111449
* gcc.target/powerpc/pr111449-2.c: New.

[Bug rtl-optimization/112568] [14 Regression] Miscompilation of radeonsi (mesa) with -march=raptorlake (-mavx) since r14-5355-g3cd3a09b3f91a1

[kocelfc at tutanota dot com via Gcc-bugs]

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

Kostadin Shishmanov  changed:

   What|Removed |Added

  Attachment #56602|0   |1
is obsolete||
  Attachment #56612|0   |1
is obsolete||

--- Comment #15 from Kostadin Shishmanov  ---
Created attachment 56619
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56619=edit
bad object file

[Bug rtl-optimization/112568] [14 Regression] Miscompilation of radeonsi (mesa) with -march=raptorlake (-mavx) since r14-5355-g3cd3a09b3f91a1

[kocelfc at tutanota dot com via Gcc-bugs]

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

Kostadin Shishmanov  changed:

   What|Removed |Added

  Attachment #56603|0   |1
is obsolete||

--- Comment #14 from Kostadin Shishmanov  ---
Created attachment 56618
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56618=edit
good object file

[Bug rtl-optimization/112568] [14 Regression] Miscompilation of radeonsi (mesa) with -march=raptorlake (-mavx) since r14-5355-g3cd3a09b3f91a1

[kocelfc at tutanota dot com via Gcc-bugs]

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

Kostadin Shishmanov  changed:

   What|Removed |Added

  Attachment #56614|0   |1
is obsolete||

--- Comment #13 from Kostadin Shishmanov  ---
Created attachment 56617
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56617=edit
dump of the first different pass with the commit reverted

[Bug rtl-optimization/112568] [14 Regression] Miscompilation of radeonsi (mesa) with -march=raptorlake (-mavx) since r14-5355-g3cd3a09b3f91a1

[kocelfc at tutanota dot com via Gcc-bugs]

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

Kostadin Shishmanov  changed:

   What|Removed |Added

  Attachment #56613|0   |1
is obsolete||

--- Comment #12 from Kostadin Shishmanov  ---
Created attachment 56616
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56616=edit
dump of the first different pass with the problematic commit

[Bug rtl-optimization/112568] [14 Regression] Miscompilation of radeonsi (mesa) with -march=raptorlake (-mavx) since r14-5355-g3cd3a09b3f91a1

[kocelfc at tutanota dot com via Gcc-bugs]

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

--- Comment #11 from Kostadin Shishmanov  ---
I think the gcc builds might be a bit more different than just the commit
reverted, so I am going to redo everything and upload the attachments again
with just that difference.

[Bug target/112583] New: RISC-V regression testsuite errors with rv64gcv_zvl128b

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 112583
   Summary: RISC-V regression testsuite errors with
rv64gcv_zvl128b
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Created attachment 56615
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56615=edit
rv64gcv_zvl128b testsuite failures

Current testsuite status of rv64gcv_zvl128b on GCC
5cb13173e85537a8a423b7b22b60ca3b6505f91e

I've started running zvl variants 128-1024b weekly on the postcommit CI. This
is my first time running these so if any of the failures look odd poke me here
or via email and I can dig into/share the logs.

Artifacts for this run can be downloaded here:
https://github.com/patrick-rivos/gcc-postcommit-ci/actions/runs/6898356494
Likely artifacts of interest:
gcc-linux-rv64gcv_zvl-lp64d-5cb13173e85537a8a423b7b22b60ca3b6505f91e-multilib-debug-output.log
gcc-linux-rv64gcv_zvl-lp64d-5cb13173e85537a8a423b7b22b60ca3b6505f91e-multilib-report.log
 
gcc-linux-rv64gcv_zvl-lp64d-5cb13173e85537a8a423b7b22b60ca3b6505f91e-multilib-sum-files
 

This is just a tracking issue, similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311

I'll open separate tracking issues for zvl 256,512,1024 tomorrow.

I've attached the current results for rv64gcv_zvl128b with glibc v2.37 on QEMU
v8.1.2

[Bug rtl-optimization/112568] [14 Regression] Miscompilation of radeonsi (mesa) with -march=raptorlake (-mavx) since r14-5355-g3cd3a09b3f91a1

[kocelfc at tutanota dot com via Gcc-bugs]

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

--- Comment #10 from Kostadin Shishmanov  ---
Created attachment 56614
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56614=edit
dump of the first bad pass with the commit reverted

[Bug rtl-optimization/112568] [14 Regression] Miscompilation of radeonsi (mesa) with -march=raptorlake (-mavx) since r14-5355-g3cd3a09b3f91a1

[kocelfc at tutanota dot com via Gcc-bugs]

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

--- Comment #9 from Kostadin Shishmanov  ---
Created attachment 56613
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56613=edit
dump of the first bad pass with the problematic commit