[Bug tree-optimization/117606] single element interleaving behavior for SLP does not exactly match non-SLP behavior

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

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||116578
   Keywords||missed-optimization
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2024-11-15


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116578
[Bug 116578] vectorizer SLP transition issues / dependencies

[Bug tree-optimization/117558] peeling for gap overrun check imprecise for VLA

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

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug tree-optimization/117606] New: single element interleaving behavior for SLP does not exactly match non-SLP behavior

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

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

Bug ID: 117606
   Summary: single element interleaving behavior for SLP does not
exactly match non-SLP behavior
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

For the following, derived from gcc.target/aarch64/sve/strided_load_5.c

void foo (unsigned *restrict dest, unsigned *src, int n)
{
  for (int i = 0; i < n; ++i)
dest[i] += src[i * 5];
}

when not using SLP we classify the load from src[] as VMAT_ELEMENTWISE and
thus consider using gathers.  This is because we do not have general permute
support there but only load-lanes and the static set of "group loads" and
both vect_load_lanes_supported and vect_grouped_load_supported FAIL
(on aarch64, riscv supports ld5).

With SLP this gets classified as (permuted) VMAT_CONTIGUOUS since load-lanes
isn't supported.  We do not attempt to lower the permutation to something
supported and thus run into the 3 vector limit.  The fallback to
VMAT_ELEMENTWISE is only for groups larger than the vector size so it doesn't
apply here.

One possible approach would be to check for the permute to be supported
during VMAT classification rather than after the fact in
vectorizable_load/store.  That matches how we verify
vect_grouped_load_supported.

[Bug tree-optimization/117605] New: SLP vectorization fails for negative stride interleaving

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

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

Bug ID: 117605
   Summary: SLP vectorization fails for negative stride
interleaving
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Testing with --param vect-force-slp=1 reveals (via
gcc.target/aarch64/sve/strided_load_4.c and a few others) that we do not SLP
vectorize

void foo (unsigned *restrict dest, unsigned *src, int n)
{
  for (int i = 0; i < n; ++i)
dest[i] += src[i * -100];
}

note:   Detected single element interleaving *_8 step -400

missed:   permutation requires at least three vectors _9 = *_8;

the non-SLP path classifies this as VMAT_ELEMENTWISE, SLP as
VMAT_CONTIGUOUS_REVERSE.  The non-SLP path never cosiders that for
grouped accesses.

The easiest solution is to extend the existing VMAT_CONTIGUOUS demotion
to VMAT_ELEMENTWISE for large groups to also cover VMAT_CONTIGUOUS_REVERSE.

[Bug tree-optimization/117605] SLP vectorization fails for negative stride interleaving

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Keywords||missed-optimization
   Last reconfirmed||2024-11-15
 Blocks||116578


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116578
[Bug 116578] vectorizer SLP transition issues / dependencies

[Bug c++/117370] std::nothrow variants of operator new are not optimized away when block is unused

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #5 from Sam James  ---
All done, AFAICT.

[Bug rtl-optimization/117128] [15 regression] GCC trunk generates larger code than GCC 14 at -Os/Oz since r14-2161-g237e83e2158a3d

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

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

Sam James  changed:

   What|Removed |Added

   Last reconfirmed||2024-11-15
 CC||roger at nextmovesoftware dot 
com
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #7 from Sam James  ---
Confirmed and also CCing Roger in case he's interested (-Oz).

[Bug target/117278] [12/13/14/15 regression] Code at -Os is larger on trunk than GCC 11.4.0 since r12-6149-gdc1969dab39266

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

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

Sam James  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-11-15
 CC||hubicka at gcc dot gnu.org,
   ||law at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Sam James  ---
Not sure if Xionghu Luo is involved in GCC development at the moment, but CCing
jeff and honza as reviewers of that patchset (and this being honza's area
anyway).

[Bug target/117253] [14/15 regression] Generated code at -Os on trunk is larger than GCC 13.3 since r14-1656-g55fcaa9a8bd9c8

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|13.4|14.3
Summary|[14/15 regression]  |[14/15 regression]
   |Generated code at -Os on|Generated code at -Os on
   |trunk is larger than GCC|trunk is larger than GCC
   |13.3|13.3 since
   ||r14-1656-g55fcaa9a8bd9c8
   Last reconfirmed||2024-11-15
  Known to work||13.3.1
 Ever confirmed|0   |1
  Known to fail||14.2.1, 15.0
 Status|UNCONFIRMED |NEW

--- Comment #8 from Sam James  ---
Confirmed in that it's grown, although I agree the first testcase is (very)
synthetic.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117253#c6 is a lot more
reasonable, I think.

[Bug middle-end/117271] [13/14/15 regression] GCC trunk emits larger code at -Os than 12.4.0 since r14-3084-gaadc5c07feb0ab

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

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

Sam James  changed:

   What|Removed |Added

 Blocks||85316
Summary|[13/14/15 regression] GCC   |[13/14/15 regression] GCC
   |trunk emits larger code at  |trunk emits larger code at
   |-Os than 12.4.0 |-Os than 12.4.0 since
   ||r14-3084-gaadc5c07feb0ab
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-11-15
  Known to fail||13.3.1, 14.2.1, 15.0
 Ever confirmed|0   |1
  Known to work||12.4.1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
[Bug 85316] [meta-bug] VRP range propagation missed cases

[Bug target/117006] [15 regression] GCC trunk generates larger code than GCC 14 at -Os

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #2 from Sam James  ---
Reluctant to confirm it given the above. It's factually larger but I'm not sure
it matters.

[Bug target/116994] [15 regression] GCC trunk generates larger code than GCC 14 at -Os since r15-313-gd826f794560904

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

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

Sam James  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Known to work||14.2.1
  Known to fail||15.0
   Last reconfirmed||2024-11-15

[Bug middle-end/117352] [15 Regression] switch bit test conversion makes comparison code worse on aarch64 and x86_64 with APX due to not generating ccmp

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

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

--- Comment #4 from Filip Kastl  ---
It took me longer than I expected but I've submitted the patch.

https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668911.html

[Bug tree-optimization/90594] [12/13/14/15 regression] Spurious popcount emitted

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

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

--- Comment #14 from Andrew Pinski  ---
I should note some of the reuse stack issues are due to sccp even though the
pointer value is there at the end anyways ...

[Bug tree-optimization/117574] [12/13/14/15 Regression] Miscompile with -O2/3 and -O0/1 since r6-4133-ga8fc25795155d4

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

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

--- Comment #10 from Richard Biener  ---
And we compute the "noloop" condition as

noloop = fold_build2 (GT_EXPR, boolean_type_node,
  iv0->base,
  fold_build2 (PLUS_EXPR, type1,
   iv1->base, tmod));

where tmod is 47 (that's STEP - DELTA %[fl] STEP in the IVs type - mind,
DELTA is unsigned!).

So the noloop condition is

(long int) ((int) d.3_5 + 40) + 1 >= (long int) ((int) d.3_5 + 76)

which is wrong, it should compute true.

What's fishy here is the negative DELTA (so there is IV overflow in that
compute) and then the use of unsigned FLOOR_MOD to compute the adjustment
for the final value and the noloop condition (I'm not sure why that needs
the mod adjustment at all?!).

I'm going to test the naiive

diff --git a/gcc/tree-ssa-loop-niter.cc b/gcc/tree-ssa-loop-niter.cc
index 9518bf969cd..1be4b552206 100644
--- a/gcc/tree-ssa-loop-niter.cc
+++ b/gcc/tree-ssa-loop-niter.cc
@@ -1200,17 +1200,6 @@ number_of_iterations_lt_to_ne (tree type, affine_iv
*iv0,
 affine_iv *iv1,
  if (integer_zerop (assumption))
return false;
}
-  if (mpz_cmp (mmod, bnds->below) < 0)
-   noloop = boolean_false_node;
-  else if (POINTER_TYPE_P (type))
-   noloop = fold_build2 (GT_EXPR, boolean_type_node,
- iv0->base,
- fold_build_pointer_plus (iv1->base, tmod));
-  else
-   noloop = fold_build2 (GT_EXPR, boolean_type_node,
- iv0->base,
- fold_build2 (PLUS_EXPR, type1,
-  iv1->base, tmod));
 }
   else
 {
@@ -1226,21 +1215,15 @@ number_of_iterations_lt_to_ne (tree type, affine_iv
*iv0, affine_iv *iv1,
  if (integer_zerop (assumption))
return false;
}
-  if (mpz_cmp (mmod, bnds->below) < 0)
-   noloop = boolean_false_node;
-  else if (POINTER_TYPE_P (type))
-   noloop = fold_build2 (GT_EXPR, boolean_type_node,
- fold_build_pointer_plus (iv0->base,
-  fold_build1
(NEGATE_EXPR,
-   type1,
tmod)),
- iv1->base);
-  else
-   noloop = fold_build2 (GT_EXPR, boolean_type_node,
- fold_build2 (MINUS_EXPR, type1,
-  iv0->base, tmod),
- iv1->base);
 }

+  /* IV0 < IV1 does not loop if IV0->base >= IV1->base.  */
+  if (mpz_cmp (mmod, bnds->below) < 0)
+noloop = boolean_false_node;
+  else
+noloop = fold_build2 (GE_EXPR, boolean_type_node,
+ iv0->base, iv1->base);
+
   if (!integer_nonzerop (assumption))
 niter->assumptions = fold_build2 (TRUTH_AND_EXPR, boolean_type_node,
  niter->assumptions,

[Bug rtl-optimization/49330] Integer arithmetic on addresses optimised with pointer arithmetic rules

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

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

--- Comment #40 from Richard Biener  ---
(In reply to Andrew Pinski from comment #39)
> (In reply to Andrew Pinski from comment #38)
> > Hmm, something changed in GCC 14  The original testcase now works so
> > does the testcase in PR 93105 .
> 
> Oh it was the fix for PR 113255 .

Yeah, I finally fixed the RTL side of things ...

[Bug libstdc++/109442] Dead local copy of std::vector not removed from function

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

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

--- Comment #26 from Jan Hubicka  ---
After some more checking we need help from libstdc++ here. Problem is that size
does the pointer subtraction which is always positive, but we do not know it,
and then converts it to size_type.

The following makes us to optimize the size check out.

libstdc++-v3/ChangeLog:

* include/bits/stl_vector.h: Vector size is never negative.

diff --git a/libstdc++-v3/include/bits/stl_vector.h
b/libstdc++-v3/include/bits/stl_vector.h
index df48ba3377f..59c9348724a 100644
--- a/libstdc++-v3/include/bits/stl_vector.h
+++ b/libstdc++-v3/include/bits/stl_vector.h
@@ -1114,7 +1114,12 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   _GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
   size_type
   size() const _GLIBCXX_NOEXCEPT
-  { return size_type(this->_M_impl._M_finish - this->_M_impl._M_start); }
+  {
+   ptrdiff_t __dif = this->_M_impl._M_finish - this->_M_impl._M_start;
+   if (__dif < 0)
+  __builtin_unreachable ();
+   return size_type(__dif);
+  }

   /**  Returns the size() of the largest possible %vector.  */
   _GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR

[Bug rtl-optimization/117611] New: internal compiler error: in as_a, at machmode.h:381

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

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

Bug ID: 117611
   Summary: internal compiler error: in as_a, at machmode.h:381
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

_Accum acc1 (_Accum x)
{
return x << 16;
}

$ avr-gcc acc1.c -S -Os
during RTL pass: combine
acc1.c: In function 'acc1':
acc1.c:4:1: internal compiler error: in as_a, at machmode.h:381
4 | }
  | ^
0x1586eb4 simplify_shift_const_1
../../../source/gcc-master/gcc/combine.cc:10634
0x158934f simplify_shift_const
../../../source/gcc-master/gcc/combine.cc:11397
0x157aa3a combine_simplify_rtx
../../../source/gcc-master/gcc/combine.cc:6412
0x15783f1 subst
../../../source/gcc-master/gcc/combine.cc:5630
0x15780f2 subst
../../../source/gcc-master/gcc/combine.cc:5557
0x1570d95 try_combine
../../../source/gcc-master/gcc/combine.cc:3312
0x156af00 combine_instructions
../../../source/gcc-master/gcc/combine.cc:1264
0x15933a4 rest_of_handle_combine
../../../source/gcc-master/gcc/combine.cc:15158
0x1593460 execute
../../../source/gcc-master/gcc/combine.cc:15202
0x7f3fe58ccd8f __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58

Target: avr
Configured with: ../../source/gcc-master/configure --target=avr --disable-nls
--with-dwarf2 --with-gnu-as --with-gnu-ld --disable-shared
--enable-languages=c,c++
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20241024 (experimental) (GCC)

[Bug tree-optimization/116518] GCC does not optimize-out useless operations. Clang does.

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

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

--- Comment #7 from Jan Hubicka  ---
I wonder if DSE can use gimple_call_from_new_or_delete even without
-fassume-sane-operator-new.

In normal use of operator delete we know that the object in question was
destroyed and thus memory is undefined.
Now we mark also __builtin_operator_new/delete uses and in this case we know
delete can not inspect the memory in useful way since it does not know how what
libstdc++ does with it.

[Bug c++/117615] constexpr failure static_cast of Derived virtual Pointer to Member function

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Target Milestone|--- |12.5
   Last reconfirmed||2024-11-15
Summary|constexpr failure   |constexpr failure
   |static_cast of Derived  |static_cast of Derived
   |virtual Pointer to Member   |virtual Pointer to Member
   ||function
   Keywords||rejects-valid
 Ever confirmed|0   |1
  Known to work||5.1.0

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

[Bug c++/117615] constexpr failure static_cast of Derived virtual Pointer to Member function

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

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

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

[Bug tree-optimization/115275] [14/15 Regression] Missed optimization for Dead Code Elimination since r14-1951-g7b34cacc573538

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
So looking into the code.
In forwprop2 we have:
  iftmp.1_3 = (unsigned int) _13;
  b.4_2 = b;
  _10 = MAX_EXPR ;
  if (_10 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870912]:

   [local count: 1073741824]:
  # _14 = PHI 
  iftmp.3_4 = (unsigned int) _14;
  if (iftmp.1_3 != iftmp.3_4)

Why didn't forwprop change `iftmp.1_3 != iftmp.3_4` into `_13 != _14`.

The other thing is:
  _10 = MAX_EXPR ;
  if (_10 != 0)

Since this is unsigned, here `max != 0` could be `a != 0 | b != 0` which
then will optmize this.


So that is the following:
```
template
T max(T a, T b)
{
return a > b ? a : b;
}

int f1(unsigned f, unsigned t)
{
  return max(f, t) != 0;
}
```

Should be optimized to `(f | t) != 0`.

I will handle this. Min is similar but clang does not optimize that.

[Bug c++/117614] [14/15 Regression] Cannot change active member of anonymous union in constant expression since r14-4771-g1d260ab0e39ea6

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

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

Sam James  changed:

   What|Removed |Added

 CC||nshead at gcc dot gnu.org
Summary|[14/15 Regression] Cannot   |[14/15 Regression] Cannot
   |change active member of |change active member of
   |anonymous union in constant |anonymous union in constant
   |expression  |expression since
   ||r14-4771-g1d260ab0e39ea6
   Keywords|needs-bisection |
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=101631,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=102286

--- Comment #2 from Sam James  ---
r14-4771-g1d260ab0e39ea6

[Bug c/95445] diagnose incompatible calls to functions declared without prototype

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

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

--- Comment #4 from Florian Weimer  ---
Patch posted:

[PATCH] c: Implement -Wdeprecated-non-prototype


This is what the new warning produces for the input from the description:

t.c: In function ‘f0’:
t.c:5:10: warning: ISO C23 does not allow arguments for function ‘strchr’
declared without parameters [-Wdeprecated-non-prototype]
5 |   return strchr (s, 'x');// no warning (okay)
  |  ^~
t.c:1:7: note: declared here
1 | char* strchr ();
  |   ^~
t.c: In function ‘f1’:
t.c:10:10: warning: ISO C23 does not allow arguments for function ‘strchr’
declared without parameters [-Wdeprecated-non-prototype]
   10 |   return strchr (s, "y");// warning (good)
  |  ^~
t.c:1:7: note: declared here
1 | char* strchr ();
  |   ^~
t.c:10:21: error: passing argument 2 of ‘strchr’ makes integer from pointer
without a cast [-Wint-conversion]
   10 |   return strchr (s, "y");// warning (good)
  | ^~~
  | |
  | char *
t.c:1:7: note: expected ‘int’ but argument is of type ‘char *’
1 | char* strchr ();
  |   ^~
t.c: In function ‘h’:
t.c:17:3: warning: ISO C23 does not allow arguments for function ‘g’ declared
without parameters [-Wdeprecated-non-prototype]
   17 |   g (1); // (presumably) okay, f's type is 'void
(int)'
  |   ^
t.c:13:6: note: declared here
   13 | void g ();
  |  ^
t.c:18:3: warning: ISO C23 does not allow arguments for function ‘g’ declared
without parameters [-Wdeprecated-non-prototype]
   18 |   g ("foo"); // should be diagnosed
  |   ^
t.c:13:6: note: declared here
   13 | void g ();
  |  ^
t.c:19:3: warning: ISO C23 does not allow arguments for function ‘g’ declared
without parameters [-Wdeprecated-non-prototype]
   19 |   g (1, "bar");  // ditto
  |   ^
t.c:13:6: note: declared here
   13 | void g ();
  |  ^

[Bug c++/117615] [12/13/14/15 Regression] constexpr failure static_cast of Derived virtual Pointer to Member function since r6-4015-g2a9fb7125e0b0e

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

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

Sam James  changed:

   What|Removed |Added

   Keywords|needs-bisection |
Summary|[12/13/14/15 Regression]|[12/13/14/15 Regression]
   |constexpr failure   |constexpr failure
   |static_cast of Derived  |static_cast of Derived
   |virtual Pointer to Member   |virtual Pointer to Member
   |function|function since
   ||r6-4015-g2a9fb7125e0b0e
 CC||jason at gcc dot gnu.org

--- Comment #4 from Sam James  ---
r6-4015-g2a9fb7125e0b0e

[Bug c++/117615] [12/13/14/15 Regression] constexpr failure static_cast of Derived virtual Pointer to Member function since r6-4014-gdcdbc004d531b4

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

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

Sam James  changed:

   What|Removed |Added

Summary|[12/13/14/15 Regression]|[12/13/14/15 Regression]
   |constexpr failure   |constexpr failure
   |static_cast of Derived  |static_cast of Derived
   |virtual Pointer to Member   |virtual Pointer to Member
   |function since  |function since
   |r6-4015-g2a9fb7125e0b0e |r6-4014-gdcdbc004d531b4

--- Comment #5 from Sam James  ---
Sorry, it was actually the commit before: r6-4014-gdcdbc004d531b4.

[Bug target/117583] big-endian aarch64 BitInt support

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

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

Sam James  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-11-16

[Bug target/117585] IA64 BitInt support

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

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

Sam James  changed:

   What|Removed |Added

   Last reconfirmed||2024-11-16
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug target/117581] Riscv support for _BitInt

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

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

Sam James  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-11-16

[Bug target/117582] arm implementation of _BitInt

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

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

Sam James  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-11-16
 Status|UNCONFIRMED |NEW

[Bug target/117580] [meta-bug] Targets should have a defined _BitInt ABI and implement that ABI

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

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

Sam James  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-11-16
 Status|UNCONFIRMED |NEW

[Bug target/117589] hppa support for BitInt

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

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

Sam James  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-11-16
 Ever confirmed|0   |1

[Bug target/117584] PowerPC ABI for BitInt needs to be done

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

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

Sam James  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-11-16
 Status|UNCONFIRMED |NEW

[Bug target/117587] BPF support for BitInt

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

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

Sam James  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-11-16
 Ever confirmed|0   |1

[Bug target/117599] LoongArch support for BitInt

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

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

Sam James  changed:

   What|Removed |Added

   Last reconfirmed||2024-11-16
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug ada/111308] BITINT_TYPE unsupported in c-ada-spec.cc

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

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

Bug 102989 Summary: Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989

   What|Removed |Added

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

[Bug go/111310] BITINT_TYPE unsupported in godump.cc

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

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

Bug 102989 Summary: Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989

   What|Removed |Added

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

[Bug target/117590] nvptx support for BitInt

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

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

Sam James  changed:

   What|Removed |Added

   Last reconfirmed||2024-11-16
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug target/117593] amdgcn support for BitInt

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

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

Sam James  changed:

   What|Removed |Added

   Last reconfirmed||2024-11-16
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug target/117616] New: frv: may need adaptation for C23 varargs

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

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

Bug ID: 117616
   Summary: frv: may need adaptation for C23 varargs
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: aoliva at gcc dot gnu.org, nickc at gcc dot gnu.org
Blocks: 114175
  Target Milestone: ---

Split out from PR114175 (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175#c64).

This target needs to check if it needs a tweak for handling C23 varargs like in
r14-9503-g218d17496122abe1fd831bd003f129310b32ca83.

If gcc.dg/c23-stdarg* passes on this target, it should be fine as-is.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175
[Bug 114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on
multiple targets

[Bug c/102989] Implement C2x's n2763 (_BitInt)

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #118 from Sam James  ---
.

[Bug target/117617] New: mcore: may need adaptation for C23 varargs

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

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

Bug ID: 117617
   Summary: mcore: may need adaptation for C23 varargs
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: nickc at gcc dot gnu.org
Blocks: 114175
  Target Milestone: ---

Split out from PR114175 (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175#c64).

This target needs to check if it needs a tweak for handling C23 varargs like in
r14-9503-g218d17496122abe1fd831bd003f129310b32ca83.

If gcc.dg/c23-stdarg* passes on this target, it should be fine as-is.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175
[Bug 114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on
multiple targets

[Bug target/117618] New: mmix: may need adaptation for C23 varargs

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

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

Bug ID: 117618
   Summary: mmix: may need adaptation for C23 varargs
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: hp at gcc dot gnu.org
Blocks: 114175
  Target Milestone: ---

Split out from PR114175 (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175#c64).

This target needs to check if it needs a tweak for handling C23 varargs like in
r14-9503-g218d17496122abe1fd831bd003f129310b32ca83.

If gcc.dg/c23-stdarg* passes on this target, it should be fine as-is.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175
[Bug 114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on
multiple targets

[Bug modula2/117371] [14/15 Regression] type incompatibility between ‘INTEGER’ and ‘CARDINAL’

[ludovic--- via Gcc-bugs]

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

--- Comment #6 from Ludovic Brenta  ---
Thanks for the fix but now I am curious: is K not a constant inside the outer
loop? i.e. is it allowed to assign to K? (In Ada, FOR loops implicitly declare
the so-called "loop parameter", a constant whose scope is one iteration of the
loop).

[Bug target/117619] New: sh: may need adaptation for C23 varargs

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

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

Bug ID: 117619
   Summary: sh: may need adaptation for C23 varargs
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: aoliva at gcc dot gnu.org, olegendo at gcc dot gnu.org
Blocks: 114175
  Target Milestone: ---

Split out from PR114175 (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175#c64).

This target needs to check if it needs a tweak for handling C23 varargs like in
r14-9503-g218d17496122abe1fd831bd003f129310b32ca83.

If gcc.dg/c23-stdarg* passes on this target, it should be fine as-is.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175
[Bug 114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on
multiple targets

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

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

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

--- Comment #65 from Sam James  ---
(In reply to Sam James from comment #64)
> I think the bug was kept open for other targets to check if they needed
> adaptation.
> 
> jakub's guess in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175#c24
> said:
> > aarch64, alpha, arc, maybe arm, csky, maybe epiphany, maybe fr30, maybe 
> > frv, maybe ft32, ia64, loongarch, maybe m32r, maybe mcore, mips, mmix, 
> > maybe nds32, nios2, riscv, maybe rs6000, maybe sh, visium need similar fix.
> 
> rs6000 is done, alpha is done, loong is done, arc is done, riscv is done,
> csky is done, epiphany is done, ft32 is done, m32r is done, nds32 is done,
> nios2 is done, visium is done, mips is done. aarch64 seems unaffected.
> 
> That means we need to check:
> * frv
> * mcore
> * mmix
> * sh
> 
> I think?

I've filed individual bugs for these.

[Bug target/117594] [15 regression] RISC-V: Miscompile at -O3 since r15-4012-gba7632674a2

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

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

Sam James  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
Summary|[15] RISC-V: Miscompile at  |[15 regression] RISC-V:
   |-O3 since   |Miscompile at -O3 since
   |r15-4012-gba7632674a2   |r15-4012-gba7632674a2
   Target Milestone|--- |15.0

[Bug modula2/117555] [15 regression] libgm2 build failure after r15-5081-g95960cd473297c

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Gaius Mulley :

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

commit r15-5331-ge77fd9aa89c210db6006fcefb03d80bae0fae851
Author: Gaius Mulley 
Date:   Sat Nov 16 02:32:56 2024 +

PR modula2/117555: Add missing return statement after raise

This patch adds missing return statements after a call to RAISE.  Four
of the modules in libgm2 have procedure functions with missing return
statements.  These errors were exposed after the reimplementation of
parameter declaration patch and triggered by -Wreturn-type.  The patch
also adds exit statements to the M2RTS noreturn functions.

gcc/m2/ChangeLog:

PR modula2/117555
* gm2-libs-iso/EXCEPTIONS.mod (CurrentNumber): Add return
statement.
* gm2-libs-iso/IOChan.mod (ReadResult): Ditto.
(CurrentFlags): Ditto.
(DeviceError): Ditto.
* gm2-libs-iso/IOLink.mod (DeviceTablePtrValue): Ditto.
* gm2-libs-iso/LongConv.mod (ValueReal): Ditto.
* gm2-libs/M2RTS.mod (Halt): Add noreturn attribute.
Add exit (1).
(HaltC): Add exit (1).
* pge-boot/GM2RTS.cc (M2RTS_Halt): Add exit (1).
(M2RTS_HaltC): Ditto.

Signed-off-by: Gaius Mulley 

[Bug modula2/117555] [15 regression] libgm2 build failure after r15-5081-g95960cd473297c

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

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

--- Comment #3 from Gaius Mulley  ---
Closing now that the patch has been applied.

[Bug libstdc++/98723] On Windows with CP936 encoding, regex compiles very slow.

[luca.bacci at outlook dot com via Gcc-bugs]

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

--- Comment #13 from Luca Bacci  ---
Here we are:
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668988.html

Let me know if anything is missing.

Best regards,
Luca

[Bug c/117548] [15 regression] ICE when redeclaring function with a compatible type involving C23 structure compatibility

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

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

--- Comment #3 from uecker at gcc dot gnu.org ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668998.html

[Bug c++/117614] [14/15 Regression] Cannot change active member of anonymous union in constant expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Cannot change active member |[14/15 Regression] Cannot
   |of anonymous union in   |change active member of
   |constant expression |anonymous union in constant
   ||expression
  Known to fail||14.1.0
  Known to work||13.3.0
   Target Milestone|--- |14.3
 Ever confirmed|0   |1
   Last reconfirmed||2024-11-15
   Keywords||needs-bisection
 Status|UNCONFIRMED |NEW

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

[Bug tree-optimization/90594] [12/13/14/15 regression] Spurious popcount emitted

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=117572,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=60412,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=111630

--- Comment #15 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #14)
> I should note some of the reuse stack issues are due to sccp even though the
> pointer value is there at the end anyways ...

PR 117572 and PR 60412 and PR 111630 are an examples where the sccp is not
needed because the pointer is already correct at the end of the loop but we do
sccp anyways.

[Bug c++/117615] New: constexpr failure static_cast of Derived virtual Pointer to Member

[acox at reliablecontrols dot com via Gcc-bugs]

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

Bug ID: 117615
   Summary: constexpr failure static_cast of Derived virtual
Pointer to Member
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acox at reliablecontrols dot com
  Target Milestone: ---

Casting a virtual member function from the derived class fails to compile with
an error message complaining about a reinterpret_cast from a number to the
function signature. The number seems to be an offset, if you add a virtual
destructor to the Base class before the line doit is defined on the number
increases to 17.

https://godbolt.org/z/xPennWh15

: In function 'int main()':
:36:37:   in 'constexpr' expansion of 'help(&Derived::doit)'
:28:7: error: 'reinterpret_cast(1)' is not a
constant expression
   28 | : mFn(static_cast(fn))
  |   ^~
Compiler returned: 1

It compiles under the following changes
- if the member functions are made non-virtual
- if constexpr is removed from h
- if h is constructed with &Base::doit

Code from the godbolt link is included below as well.

```
#include 

#define BREAK_IT

struct Base {
#ifdef BREAK_IT
virtual
#endif
void doit(int v) const { std::cout << "doit base " << v; }
virtual ~Base() = default;

};

struct Derived : Base {
#ifdef BREAK_IT
virtual
#endif
void doit(int v) const { std::cout << "doit derived " << v; }
};

struct help
{
using fn_t = void (Base::*)(int) const;

fn_t mFn;

constexpr help(auto && fn)
: mFn(static_cast(fn))
{

}
};

int main()
{
constexpr help h (&Derived::doit);
Derived x;
(x.*h.mFn)(12);
}
```

[Bug tree-optimization/115275] [14/15 Regression] Missed optimization for Dead Code Elimination since r14-1951-g7b34cacc573538

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #6)
> This should work:

Mostly (except for a mistmatched `()`). So now just need to write testcases.

[Bug c++/117620] Problem passing rvalue to co_yield (maybe?)

[mwd at md5i dot com via Gcc-bugs]

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

--- Comment #1 from Michael Duggan  ---
When I said line 214, I actually meant line 213.  (I modified the example but
didn't update all of my text.)

[Bug tree-optimization/111292] [14/15 Regression] Missed Dead Code Elimination since r14-2228-g02460c0b8c9

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

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

Sam James  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #5 from Sam James  ---
(In reply to Andrew Pinski from comment #2)
> Looks like this has been fixed on the trunk ...

Apparently by r14-4777-g88c27070c25309. I am not sure if that really means this
is just latent again.

[Bug modula2/117555] [15 regression] libgm2 build failure after r15-5081-g95960cd473297c

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

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

Gaius Mulley  changed:

   What|Removed |Added

   Last reconfirmed||2024-11-15
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from Gaius Mulley  ---
Confirmed, thanks for the bug report.

[Bug c/117289] gcc.dg/debug/ctf/ctf-function-pointers-2.c failure with -std=gnu23

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Joseph Myers :

https://gcc.gnu.org/g:55e3bd376b2214e200fa76d12b67ff259b06c212

commit r15-5327-g55e3bd376b2214e200fa76d12b67ff259b06c212
Author: Joseph Myers 
Date:   Fri Nov 15 23:42:59 2024 +

c: Default to -std=gnu23

Change the default language version for C compilation from -std=gnu17
to -std=gnu23.  A few tests are updated to remove local definitions of
bool, true and false (where making such an unconditional test change
seemed to make more sense than changing the test conditionally earlier
or building it with -std=gnu17); most test issues were already
addressed in previous patches.  In the case of
ctf-function-pointers-2.c, it was agreed in bug 117289 that it would
be OK to put -std=gnu17 in the test and leave more optimal BTF / CTF
output for this test as a potential future improvement.

Since the original test fixes, more such fixes have become necessary
and so are included in this patch.  More noinline attributes are added
to simulate-thread tests where () meaning a prototype affected test
results, while gcc.dg/torture/pr117496-1.c (a test declaring a
function with () then calling it with arguments) gets -std=gnu17
added.

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

NOTE: it's likely there are target-specific tests for non-x86 targets
that need updating as a result of this change.  See commit
9fb5348e3021021e82d75e4ca4e6f8d51a34c24f ("testsuite: Prepare for
-std=gnu23 default") for examples of changes to prepare the testsuite
to work with a -std=gnu23 default.  In most cases, adding
-Wno-old-style-definition (for warnings for old-style function
definitions) or -std=gnu17 (for other issues such as unprototyped
function declarations with ()) is appropriate, but watch out for cases
that indicate bugs with -std=gnu23 (in particular, any ICEs - there
was only the one nested function test where I had to fix an ICE on
x86_64).

gcc/
* doc/invoke.texi (-std=gnu17, -std=gnu23): Document -std=gnu23 as
default for C code.

gcc/c-family/
* c-opts.cc (c_common_init_options): Default to C23.

gcc/testsuite/
* c-c++-common/analyzer/asm-x86-dyndbg-2.c,
c-c++-common/analyzer/asm-x86-lp64-2.c,
c-c++-common/analyzer/attr-malloc-CVE-2019-19078-usb-leak.c,
c-c++-common/analyzer/coreutils-cksum-pr108664.c,
c-c++-common/analyzer/feasibility-3.c,
c-c++-common/analyzer/pr105783.c, c-c++-common/analyzer/sock-1.c,
c-c++-common/attributes-4.c, gcc.dg/Warray-bounds-78.c,
gcc.dg/analyzer/asm-x86-dyndbg-1.c: Do not define bool, true or
false.
* gcc.dg/debug/ctf/ctf-function-pointers-2.c: Use -std-gnu17.
* gcc.dg/gnu23-version-2.c: New test.
* gcc.dg/simulate-thread/atomic-load-int.c,
gcc.dg/simulate-thread/atomic-load-longlong.c,
gcc.dg/simulate-thread/atomic-load-short.c: Add more noinline
attributes.
* gcc.dg/torture/pr117496-1.c: Use -std=gnu17.

[Bug target/117594] [15] RISC-V: Miscompile at -O3 since r15-4012-gba7632674a2

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

Summary|[15] RISC-V: Miscompile at  |[15] RISC-V: Miscompile at
   |-O3 |-O3 since
   ||r15-4012-gba7632674a2
 Target|riscv*-*-*  |riscv*-*-* x86_64-*-*

--- Comment #6 from Patrick O'Neill  ---
Bisected to r15-4012-gba7632674a2

[Bug tree-optimization/105558] simple 8-bit integer calculation fails with -O3 / march=core-avx2 on some gfortran 8/9/10 versions

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

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

--- Comment #9 from Sam James  ---
I can bisect it if someone gives me a case which aborts with the wrong value.

[Bug target/117564] a-comp.c:649:1: internal compiler error: in plus_constant, at explow.cc:102

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-13 branch has been updated by John David Anglin
:

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

commit r13-9194-ge99c6e555703bd2b5d139914b24958a1a5de1d69
Author: John David Anglin 
Date:   Fri Nov 15 11:05:58 2024 -0500

hppa: Fix typos in 32-bit SFmode peephole2 patterns

2024-11-15  John David Anglin  

gcc/ChangeLog:

PR target/117564
* config/pa/pa.md: Fix typos in 32-bit SFmode peephole2 patterns.

[Bug target/117564] a-comp.c:649:1: internal compiler error: in plus_constant, at explow.cc:102

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

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

--- Comment #3 from GCC Commits  ---
The releases/gcc-14 branch has been updated by John David Anglin
:

https://gcc.gnu.org/g:878b3354859ace887c0613fda6b79e96d6d5024b

commit r14-10932-g878b3354859ace887c0613fda6b79e96d6d5024b
Author: John David Anglin 
Date:   Fri Nov 15 11:05:58 2024 -0500

hppa: Fix typos in 32-bit SFmode peephole2 patterns

2024-11-15  John David Anglin  

gcc/ChangeLog:

PR target/117564
* config/pa/pa.md: Fix typos in 32-bit SFmode peephole2 patterns.

[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)

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

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

--- Comment #13 from uecker at gcc dot gnu.org ---
Tests were fixed in PR115545

[Bug tree-optimization/117612] spaceship codegen is inferior to hand written operator when comparing doubles

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

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

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

[Bug tree-optimization/117093] Missing detection of REV64 vector permute

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Jennifer Schmitz :

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

commit r15-5324-gc83e2d47574fd9a21f257e0f0d7e350c3f1b0618
Author: Jennifer Schmitz 
Date:   Mon Nov 4 07:56:09 2024 -0800

match.pd: Fold vec_perm with view_convert

This patch improves the codegen for the following test case:
uint64x2_t foo (uint64x2_t r) {
uint32x4_t a = vreinterpretq_u32_u64 (r);
uint32_t t;
t = a[0]; a[0] = a[1]; a[1] = t;
t = a[2]; a[2] = a[3]; a[3] = t;
return vreinterpretq_u64_u32 (a);
}
from (-O1):
foo:
mov v31.16b, v0.16b
ins v0.s[0], v0.s[1]
ins v0.s[1], v31.s[0]
ins v0.s[2], v31.s[3]
ins v0.s[3], v31.s[2]
ret
to:
foo:
rev64   v0.4s, v0.4s
ret

This is achieved by extending the following match.pd pattern to account
for type differences between @0 and @1 due to view converts.
/* Simplify vector inserts of other vector extracts to a permute.  */
(simplify
 (bit_insert @0 (BIT_FIELD_REF@2 @1 @rsize @rpos) @ipos)

The patch was bootstrapped and regtested on aarch64-linux-gnu and
x86_64-linux-gnu, no regression.
OK for mainline?

Signed-off-by: Jennifer Schmitz 
Co-authored-by: Richard Biener 

gcc/
PR tree-optimization/117093
* match.pd: Extend
(bit_insert @0 (BIT_FIELD_REF@2 @1 @rsize @rpos) @ipos) to allow
type differences between @0 and @1 due to view converts.

gcc/testsuite/
PR tree-optimization/117093
* gcc.dg/tree-ssa/pr117093.c: New test.

[Bug rtl-optimization/117611] [15 Regression] internal compiler error: in as_a, at machmode.h:381

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-checking
  Known to work|14.2.0  |

--- Comment #1 from Andrew Pinski  ---
  gcc_checking_assert (T::includes_p (m));

So only ICEs with checking enabled.

The ICE comes from
  scalar_int_mode shift_unit_mode
= as_a  (GET_MODE_INNER (shift_mode));

So maybe caused by r8-2775-ge3731c52cf1b60 (or maybe it was there earlier than
that though).

[Bug modula2/117371] [14/15 Regression] type incompatibility between ‘INTEGER’ and ‘CARDINAL’

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Gaius Mulley :

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

commit r15-5326-gf242f79b8afeec58477e99c44530bd503878c6d5
Author: Gaius Mulley 
Date:   Fri Nov 15 21:12:37 2024 +

PR modula2/117371: type incompatibility between INTEGER and CARDINAL

This patch enforces a const expression increment in a FOR loop.
It also fixes missing error locations.  The FOR loop last iterator
value is now calculated during M2GenGCC after all types and constants have
been resolved.  This results in fewer quadruples (as there is no need to
build two paths for step > 0 and step < 0).

gcc/m2/ChangeLog:

PR modula2/117371
* gm2-compiler/M2Base.mod (MixMetaTypes): Add parameter TRUE to
MetaErrorDecl.
(IsUserType): Test against ZType.
(MixTypesDecl): Test for ZType.
* gm2-compiler/M2GenGCC.mod (ErrorMessageDecl): Add parameter TRUE
to
MetaErrorDecl.
(CodeLastForIterator): New procedure.
(FoldLastForIterator): Ditto.
(PerformLastForIterator): Ditto.
(CodeStatement): Add case clause for LastForIteratorOp.
(ErrorMessageDecl): Add iserror parameter.
Call MetaErrorDecl with iserror parameter.
(checkIncorrectMeta): Call MetaErrorDecl with TRUE parameter.
(CheckBinaryExpressionTypes): Ditto.
(CheckElementSetTypes): Ditto.
* gm2-compiler/M2LexBuf.def (MakeVirtualTok): Update comment
detailing the fall back when UnknownTokenNo is encountered.
(MakeVirtual2Tok): Ditto.
* gm2-compiler/M2LexBuf.mod (MakeVirtualTok): Check against
UnknownTokenNo.
(MakeVirtual2Tok): Ditto.
* gm2-compiler/M2MetaError.def (MetaErrorDecl): Add error
parameter.
* gm2-compiler/M2MetaError.mod (MetaErrorDecl): Add error
parameter.
Issue warning if error is FALSE.
* gm2-compiler/M2Quads.def (QuadOperator): Add LastForIteratorOp.
* gm2-compiler/M2Quads.mod (AddQuadInformation): New case clause
LastForIteratorOp.
(CheckAddTuple2Read): New procedure.
(BuildForLoopToRangeCheck): Remove.
(ForLoopLastIteratorVariable): Ditto.
(ForLoopLastIteratorConstant): Ditto.
(ForLoopLastIterator): Reimplement.
(BuildForToByDo): Remove ByType from call to ForLoopLastIterator.
(WriteQuad): New case clause LastForIteratorOp.
(WriteOperator): Ditto.
* gm2-compiler/M2Students.def
(CheckForVariableThatLooksLikeKeyword): Replace with ...
(CheckVariableAgainstKeyword): ... this.
* gm2-compiler/M2Students.mod
(CheckForVariableThatLooksLikeKeyword): Replace with ...
(CheckVariableAgainstKeyword): ... this.
* gm2-compiler/M2SymInit.mod (CheckLastForIterator): New
procedure.
(CheckReadBeforeInitQuad): New case clause to call
CheckLastForIterator.
* gm2-compiler/P2SymBuild.mod: Replace
CheckForVariableThatLooksLikeKeyword with
CheckVariableAgainstKeyword.

gcc/testsuite/ChangeLog:

PR modula2/117371
* gm2/iso/fail/forloopbyvar.mod: New test.
* gm2/iso/fail/forloopbyvar4.mod: New test.
* gm2/iso/fail/forloopbyvar5.mod: New test.
* gm2/iso/pass/forloopbyvar3.mod: New test.

Signed-off-by: Gaius Mulley 

[Bug c++/117614] New: Cannot change active member of anonymous union in constant expression

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 117614
   Summary: Cannot change active member of anonymous union in
constant expression
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

This program
```
constexpr int f() {
union {
int x{0};
char y;
};
y = 1;
return y;
}

static_assert( f() == 1 );
```
is accepted in Clang and GCC 13.3, but GCC 14.2 complains:

:6:7: error: accessing 'f()y' member instead of
initialized 'f()x' member in constant expression
6 | y = 1;
  | ~~^~~
:4:14: note: initializing 'f()y' requires a member
access expression as the left operand of the assignment

Online demo: https://gcc.godbolt.org/z/6h9W5fjh1

[Bug target/117588] m68k support for BitInt

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

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

Sam James  changed:

   What|Removed |Added

   Last reconfirmed||2024-11-16
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug target/117596] avr support for BitInt

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

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

Sam James  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-11-16
 Ever confirmed|0   |1

[Bug tree-optimization/115275] [14/15 Regression] Missed optimization for Dead Code Elimination since r14-1951-g7b34cacc573538

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

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

Sam James  changed:

   What|Removed |Added

Summary|[14/15 Regression] Missed   |[14/15 Regression] Missed
   |optimization for Dead Code  |optimization for Dead Code
   |Elimination |Elimination since
   ||r14-1951-g7b34cacc573538
   Keywords|needs-bisection |
 CC||hubicka at gcc dot gnu.org

--- Comment #4 from Sam James  ---
(In reply to Andrew Pinski from comment #2)
> I suspect r14-1951-g7b34cacc573538 exposes the missed optimization here.
> 

Yep, r14-1951-g7b34cacc573538.

[Bug tree-optimization/115275] [14/15 Regression] Missed optimization for Dead Code Elimination since r14-1951-g7b34cacc573538

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

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

--- Comment #6 from Andrew Pinski  ---
This should work:
(for cmp (eq ne)
 (simplify
  (cmp (max @0 @1) integer_zerop@2)
  (if (TYPE_UNSIGNED (TREE_TYPE (@0))
   (cmp (bit_ior @0 @1) @2)))

[Bug c++/117620] New: Problem passing rvalue to co_yield (maybe?)

[mwd at md5i dot com via Gcc-bugs]

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

Bug ID: 117620
   Summary: Problem passing rvalue to co_yield (maybe?)
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mwd at md5i dot com
  Target Milestone: ---

Created attachment 59606
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59606&action=edit
Example code

When I compile the attached test code with -std=c++20, I get the following
error:

foo.cpp: In function ‘void get_values_2(get_values_2(int,
int)::_Z12get_values_2ii.Frame*)’:
foo.cpp:218:1: error: use of deleted function ‘constexpr
Generator::Generator(const Generator&)’
  218 | }
  | ^
foo.cpp:15:7: note: ‘constexpr Generator::Generator(const
Generator&)’ is implicitly declared as deleted because ‘Generator’
declares a move constructor or move assignment operator
   15 | class Generator : std::ranges::view_interface>
  |   ^
foo.cpp:215:1: note: use ‘-fdiagnostics-all-candidates’ to display considered
candidates
  218 | }
  | ^


Setting aside the fact that there are non-demangled identifiers in the output,
this is triggered by the co_yield on line 214 of the code, which reads:

  co_yield elements_of{get_values(low, high)};

If I rewrite the code (recompile with -DFIXED) as follows:

  auto x = elements_of{get_values(low, high)};
  co_yield std::move(x);

I do not get an error and everything runs correctly.  I cannot understand why
these should generate different results.  I also cannot figure out how and
where the call to the purported Generator copy constructor occurs.

[Bug target/113243] mips: Wrong code for pr91323.c

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

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

--- Comment #2 from YunQiang Su  ---
Ohh. In fact the e3e5fd0c24c9b82d824da27bf8455bb3654e8eff works for r6 with



@@ -1082,7 +1085,7 @@
 (lt "lt")
 (le "le")
 (ordered "or")
-(ltgt "ne")
+(ltgt "sne")
 (ne "une")])

[Bug target/113243] mips: Wrong code for pr91323.c

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

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

YunQiang Su  changed:

   What|Removed |Added

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

--- Comment #3 from YunQiang Su  ---
It has been fixed by

e3e5fd0c24c9b82d824da27bf8455bb3654e8eff

[Bug modula2/117555] [15 regression] libgm2 build failure after r15-5081-g95960cd473297c

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #4 from Gaius Mulley  ---
Closing, please re-open if this is premature.

[Bug tree-optimization/96188] -Wstringop-overflow false positive on std::vector::push_back with -O3

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

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

Sam James  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #10 from Sam James  ---
(In reply to Martin Sebor from comment #9)
> Today's trunk doesn't reproduce it but the warning is still issued with GCC
> 12 for a GCC 11 translation unit, so it must be some library change that's
> made it go away.

The non-preprocessed case was fixed by r12-5312-gb96e2ff9d8c56b in libstdc++.

[Bug tree-optimization/117574] [12/13/14/15 Regression] Miscompile with -O2/3 and -O0/1 since r6-4133-ga8fc25795155d4

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #9 from Richard Biener  ---
So before IVCANON we have a loop-header copy that will enter the loop:

if (_8 >= _10) // 76 >= 40
  goto ; [89.00%] // enter loop
else
  goto ; [11.00%] // skip it

and the first loop jump 

 [local count: 955630224]:
# g_33 = PHI 
# b_lsm.12_28 = PHI <_20(15), b_lsm.12_30(13)>
_20 = b_lsm.12_28 + g_33;
g_21 = g_33 + 50;
if (_8 >= g_21)  // 76 >= 90
  goto ; [89.00%]  // loop
else
  goto ; [11.00%]  // exit

should exit the loop.  We enter number_of_iterations_lt with

{ (long int) ((int) d.3_5 + 40) + 50, +, 50 } and (long int) ((int) d.3_5 + 76)
+ 1

computing delta == 18446744073709551603 (aka -13u) and then
number_of_iterations_lt_to_ne computes we can convert this to NE with
a final value of 34 and a { 0, +, 50 } IV.  I will dig further.

[Bug target/114189] Target implements obsolete vcond{,u,eq} expanders

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

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

--- Comment #16 from Richard Biener  ---
As of r15-5318-g5a2c3a69fbdcb5 both ISEL (which used to build .VCOND{,U,EQ})
and vector lowering (which allowed that) now only look for vec_cmp{,u,eq} and
vec_cond_mask optabs.

[Bug libstdc++/98723] On Windows with CP936 encoding, regex compiles very slow.

[luca.bacci at outlook dot com via Gcc-bugs]

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

--- Comment #9 from Luca Bacci  ---
To respond the my previous comment: the expected string encoding is determined
by the C locale in use, which is either the global one or imbued in
std::regex_traits.

[Bug testsuite/116080] [15 regression] New tests from r15-2233-g8d1af8f904a0c0 fail

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

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

--- Comment #20 from GCC Commits  ---
The master branch has been updated by Christophe Lyon :

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

commit r15-5319-ga064fed18a02696586cd8c182fd56c571c9438c1
Author: Christophe Lyon 
Date:   Thu Oct 3 13:37:16 2024 +

testsuite: Fix tail_call and musttail effective targets [PR116080]

Some of the musttail tests (eg musttail7.c) fail on arm-eabi because
check_effective_target_musttail pass, but the actual code in the test
is rejected.

The reason is that on arm-eabi with the default configuration, the
compiler targets armv4t for which TARGET_INTERWORK is true, making
arm_function_ok_for_sibcall reject a tail-call candidate if
TREE_ASM_WRITTEN (decl) is false.

For more recent architecture versions, TARGET_INTERWORK is false,
hence the problem was not seen on all arm configurations.

musttail7.c is in turn rejected because f2 is recursive, so
TREE_ASM_WRITTEN is false.

However, the same code used in check_effective_target_musttail is not
recursive and the function body for foo has TREE_ASM_WRITTEN == true.

The simplest fix is to remove the (empty) body for foo () in
check_effective_target_musttail.  For consistency, do the same with
check_effective_target_tail_call.

gcc/testsuite/ChangeLog:
PR testsuite/116080
* lib/target-supports.exp (check_effective_target_tail_call):
Remove foo's body.
(check_effective_target_musttail): Likewise.

[Bug libstdc++/98723] On Windows with CP936 encoding, regex compiles very slow.

[luca.bacci at outlook dot com via Gcc-bugs]

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

--- Comment #10 from Luca Bacci  ---
There's another report for Solaris which is essentially a duplicate:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85824.

> the regex compilation will be affected by current locale even if 
> std::regex::collate is not set

Yes, std::regex ends up calling strxfrm even when std::regex::collate is not
set, but that's not an issue.

std::regex::collate only determines if character ranges [a-b] will be locale
sensitive; on the other hand, things like equivalence classes [=a=] have to
work regardless of the collate flag. For equivalence classes you need locale
data. The C++ standard delegates locale-sensitive processing to
std::regex_traits, and that will be used regardless of the std::regex::collate
flag.

[Bug c++/110137] implement clang -fassume-sane-operator-new

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

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

--- Comment #32 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #31)
> I believe to match clang++ behavior the needed change would be:
> --- gcc/gimple.cc.jj  2024-11-14 18:26:16.877459015 +0100
> +++ gcc/gimple.cc 2024-11-15 13:40:43.484711373 +0100
> @@ -1605,7 +1605,7 @@ gimple_call_fnspec (const gcall *stmt)
>if (fndecl
>&& DECL_IS_REPLACEABLE_OPERATOR_NEW_P (fndecl)
>&& gimple_call_from_new_or_delete (stmt))
> -return "m ";
> +return "mP";
>return "";
>  }
>  
> Clearly ::operator delete, even when called from delete expression, isn't
> assumed not to change global state nor read it by clang++.
> Or of course if we want to go even further than that, we could return "mC"
> and let it behave like __builtin_malloc.
> Though, while perhaps one can somehow derive from the fact that the call can
> be omitted the undesirability to visibly change global state (because the
> compiler could decide not to call it and thus the global state change
> wouldn't occur), I don't see what rationale we'd use for not reading global
> state, other than that when using malloc under the hood the operator doesn't
> do that (visibly).

See PR101480 for a reason why to not do this.

[Bug libstdc++/110952] Allocator::pointer is required to be implicitly convertible from and into a native pointer

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Depends on||57572
   Target Milestone|--- |15.0
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57572
[Bug 57572] vector operators don't participate in overload resolution

[Bug libstdc++/57272] node-based containers don't use allocator's pointer type internally

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

[Bug c++/110137] implement clang -fassume-sane-operator-new

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #34 from rguenther at suse dot de  ---
On Fri, 15 Nov 2024, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
> 
> --- Comment #33 from Jakub Jelinek  ---
> (In reply to Richard Biener from comment #32)
> > See PR101480 for a reason why to not do this.
> 
> That testcase would be fine with "mP" rather than "mC".
> Sure, that PR is a reason not to do the stronger (C) case unless some flag is
> used.
> Maybe we can have both, use "mP" by default and have some (uniquely named)
> non-default flag which turns that into "mC" and the delete case into ".Co ",
> and perhaps does that even when not from new/delete.

I don't think the testcase is a good argument for some intermediate
"mP", it seems artifically reduced and soon you'll see one with
modification shown.  That said, P vs. C seems arbitrary to me.

[Bug tree-optimization/117574] [12/13/14/15 Regression] Miscompile with -O2/3 and -O0/1 since r6-4133-ga8fc25795155d4

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

--- Comment #8 from Richard Biener  ---
for (g = 40; g != 124; g += 50)

.optimized has

  d.3_5 = d; // 0
  _6 = (int) d.3_5;
  _9 = _6 + 40;
  _10 = (long int) _9;  // 40

  _43 = (unsigned int) d.3_5;
  _23 = _43 + 41;
  _29 = (int) _23;
  _50 = _43 + 76;
  _39 = (int) _50;
  _18 = _29 >= _39;  // 41 >= 76
  _37 = _18 ? 1 : 368934881474191034;  // 368934881474191034
  _42 = (unsigned long) d.3_5;
  _41 = _37 * 50;  // 84
  _17 = _42 + 40;
  _38 = _17 + _41; // 124
  _46 = (long int) _38;


   [local count: 955630224]:
  # g_33 = PHI 
  # b_lsm.12_28 = PHI <_20(4), b_lsm.12_30(3)>
  _20 = b_lsm.12_28 + g_33;
  g_21 = g_33 + 50;
  if (g_21 != _46)
goto ; [89.00%]

it is IVCANON replacing the inner loop IV and thus in the end this looks like
a niter issue.  Before IVCANON we have

  d.3_5 = d;
  _6 = (int) d.3_5;
  _7 = _6 + 76;
  _8 = (long int) _7;
  _9 = _6 + 40;
  _10 = (long int) _9;

   [local count: 955630224]:
  # g_33 = PHI 
  # b_lsm.12_28 = PHI <_20(15), b_lsm.12_30(13)>
  _20 = b_lsm.12_28 + g_33;
  g_21 = g_33 + 50;
  if (_8 >= g_21)  // 76 >= { 40, +, 50 }
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 850510900]:
  goto ; [100.00%]

so we wrongly replaced a >= IV check with a != one, the generated code suggests
a flipped condition somewhere:

  _18 = _29 >= _39;  // 41 >= 76
  _37 = _18 ? 1 : 368934881474191034;  // 368934881474191034

with _18 = _29 <= _39 it would have been correct.

[Bug rtl-optimization/116781] [lra][avr] internal compiler error: in cselib_invalidate_regno, at cselib.cc:2545

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

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

--- Comment #2 from Georg-Johann Lay  ---
Created attachment 59602
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59602&action=edit
pr116781-gjl.diff

(In reply to Denis Chertykov from comment #1)
> Probably we have a wring definition of "*tablejump_split" 
> 
> The patch:
> 
> diff --git a/gcc/config/avr/avr.md b/gcc/config/avr/avr.md
> index aae8a696a63..a26309650f2 100644
> --- a/gcc/config/avr/avr.md
> +++ b/gcc/config/avr/avr.md
> @@ -7653,7 +7653,7 @@
>  (unspec:HI [(match_operand:HI 0 "register_operand" "!z,*r,z")]
> UNSPEC_INDEX_JMP))
> (use (label_ref (match_operand 1 "" "")))
> -   (clobber (match_dup 0))
> +   (clobber (match_scratch:HI 2 "=X,X,0"))
> (clobber (const_int 0))]
>"!AVR_HAVE_EIJMP_EICALL"
>"#"
> @@ -7759,7 +7759,7 @@
> (parallel [(set (pc)
> (unspec:HI [(match_dup 7)] UNSPEC_INDEX_JMP))
>(use (label_ref (match_dup 3)))
> -  (clobber (match_dup 7))
> +  (clobber (scratch:HI))
>(clobber (match_dup 8))])]
>""
>{

I am not sure whether that is expressing what is being clobbered (operand 0).

The casesi expander must clobber the registers for operand 7 which it is
cooking up, so the casesi expander looks correct to me.

The tablejump insn for the 2-byte PC case would go something like:

diff --git a/gcc/config/avr/avr.md b/gcc/config/avr/avr.md
index 550b01b36fb..7ba43030570 100644
--- a/gcc/config/avr/avr.md
+++ b/gcc/config/avr/avr.md
@@ -7713,7 +7713,7 @@ (define_insn_and_split "*tablejump_split"
 (unspec:HI [(match_operand:HI 0 "register_operand" "!z,*r,z")]
UNSPEC_INDEX_JMP))
(use (label_ref (match_operand 1 "" "")))
-   (clobber (match_dup 0))
+   (clobber (match_operand:HI 2 "register_operand" "=0,0,0"))
(clobber (const_int 0))]
   "!AVR_HAVE_EIJMP_EICALL"
   "#"
@@ -7722,7 +7722,7 @@ (define_insn_and_split "*tablejump_split"
(unspec:HI [(match_dup 0)]
   UNSPEC_INDEX_JMP))
   (use (label_ref (match_dup 1)))
-  (clobber (match_dup 0))
+  (clobber (match_dup 2))
   (clobber (const_int 0))
   (clobber (reg:CC REG_CC))])]
   ""
@@ -7733,7 +7733,7 @@ (define_insn "*tablejump"
 (unspec:HI [(match_operand:HI 0 "register_operand" "!z,*r,z")]
UNSPEC_INDEX_JMP))
(use (label_ref (match_operand 1 "" "")))
-   (clobber (match_dup 0))
+   (clobber (match_operand:HI 2 "register_operand" "=0,0,0"))
(clobber (const_int 0))
(clobber (reg:CC REG_CC))]
   "!AVR_HAVE_EIJMP_EICALL && reload_completed"

The reason is that it has to clobber regs it already has; the regs are NOT
provided by reload.

For the split pattern it should not matter whether (match_dup 0) or (match_dup
2) is used because they must be the same.

[Bug c/117610] -Wzero-as-null-pointer-constant false positive with {0}

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #3 from Alejandro Colomar  ---
(In reply to Xi Ruoyao from comment #2)
> No, it *is* initializing a pointer.  You cannot initialize a struct with 0. 
> Instead the initializer is considered "flattened" in C.
> 
> For example:
> 
> struct s2 {
>   int  *x;
>   int y;
> };
> 
> int t;
> 
> int
> main(void)
> {
>   struct s2  a2[] = {0, 1, &t, 2};
>   _Static_assert(sizeof(a2) == sizeof(struct s2) * 2);
> }

Ahhh, you're right.  That's shown in EXAMPLE 5 (p29) in
.
 (I'm not sure which of the weird paragraphs specify this exactly.)

How about adding a diagnostic for flat initializers?  :-)

[Bug tree-optimization/117612] New: spaceship codegen is inferior to hand written operator when comparing doubles

[cuzdav at gmail dot com via Gcc-bugs]

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

Bug ID: 117612
   Summary: spaceship codegen is inferior to hand written operator
when comparing doubles
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cuzdav at gmail dot com
  Target Milestone: ---

Codegen for using spaceship operator is not as good as normal operators with
obvious implementations with -std=c++20 and -O3

This code was run on Linux X86_64.  This is the same code output from gcc 11.2
through the trunk.  This code demonstrates:

#include 

struct CustomOperators {
double value;
friend bool operator<(const CustomOperators& a, 
  const CustomOperators& b) {
return a.value < b.value;
}
};

struct SpaceOperators {
double value;
friend auto operator<=>(SpaceOperators, SpaceOperators) = default;
};

bool lt(CustomOperators l, CustomOperators r) { return l < r; }
bool lt(SpaceOperators l, SpaceOperators r) { return l < r; }

As seen on Compiler Explorer
https://godbolt.org/z/zrhM5bE94

OUTPUT:

lt(CustomOperators, CustomOperators):
comisd  xmm1, xmm0
setaal
ret

lt(SpaceOperators, SpaceOperators):
ucomisd xmm0, xmm1
jp  .L7
mov eax, 0
jne .L7
ret
.L7:
comisd  xmm1, xmm0
setaal
ret

It's worth noting that clang generates identical (good) code for both hand
written and for the spaceship operator, also visible in above godbolt link.

[Bug libstdc++/57272] node-based containers don't use allocator's pointer type internally

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

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

--- Comment #7 from Jonathan Wakely  ---
Patch for std::list posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668979.html

[Bug libstdc++/110952] Allocator::pointer is required to be implicitly convertible from and into a native pointer

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Jonathan Wakely  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668979.html

[Bug tree-optimization/117601] Another missing optimization after rewrite of SCCP for overflow

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

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

--- Comment #4 from Richard Biener  ---
Aka

char a;
char b;

(char *)((unsigned)&a + 1)

is a "valid" way to get to 'b', so even always allowing 1 isn't safe.

[Bug target/117253] [14/15 regression] Generated code at -Os on trunk is larger than GCC 13.3 since r14-1656-g55fcaa9a8bd9c8

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

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

--- Comment #9 from Andrew Pinski  ---
/* A C expression for the cost of a branch instruction.  A value of 1
   is the default; other values are interpreted relative to that.  */

#define BRANCH_COST(speed_p, predictable_p) \
  (!(speed_p) ? 2 : (predictable_p) ? 0 : ix86_branch_cost)


So aarch64 uses 3 when optimizing for size. I wonder if 3 would be better when
!speed for x86 too.

[Bug tree-optimization/117607] New: unnecessary scev optimization for popcnt

[fxue at os dot amperecomputing.com via Gcc-bugs]

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

Bug ID: 117607
   Summary: unnecessary scev optimization for popcnt
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxue at os dot amperecomputing.com
  Target Milestone: ---

Look at the case:

  int *foo(long v, int *p)
  {
while (v) {
  long t = v;

  v &= (v - 1);
  *p++ = __builtin_ctzl(t);
}

return p;
  }

On arch with popcnt supported, such as aarch64, with "-O2 -ftree-scev-cprop",
it generates:

foo:
.LFB0:
.cfi_startproc
cbz x0, .L4
mov x4, x1
mov x2, x0
.p2align 5,,15
.L3:
rbitx3, x2
clz x3, x3
str w3, [x4], 4
sub x3, x2, #1
andsx2, x2, x3
bne .L3
fmovd31, x0
add x1, x1, 4
cnt v31.8b, v31.8b
addvb31, v31.8b
fmovw0, s31
sub w2, w0, #1
add x0, x1, w2, uxtw 2
ret
.p2align 2,,3
.L4:
mov x0, x1
ret

For ""-O2 -fno-tree-scev-cprop", it gets simpler codegen:

.LFB0:
.cfi_startproc
mov x2, x0
mov x0, x1
cbz x2, .L2
.p2align 5,,15
.L3:
rbitx1, x2
sub x3, x2, #1
clz x1, x1
str w1, [x0], 4
andsx2, x2, x3
bne .L3
.L2:
ret

The cause is that scev would compute exit value of "p" using POPCNT in
one-shot. However, since "p" value is used and has to be evaluated at every
iteration, so the computation at exit is unneeded.

final value replacement:
  p_15 = PHI 
 with expr: (int *) (((sizetype) (unsigned int) (.POPCOUNT ((unsigned long)
v_7(D)) + -1) * 4 + (sizetype) p_8(D)) + 4)
 final stmt:
  p_15 = (int *) _25

[Bug c/117610] -Wzero-as-null-pointer-constant false positive with {0}

[alx at kernel dot org via Gcc-bugs]

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

--- Comment #1 from Alejandro Colomar  ---
On the other hand, it would be interesting to have a diagnostic that helps
switching from {0} to {}.

[Bug analyzer/117609] [14/15 Regression] ICE: SIGSEGV in fold_convert_const (fold-const.cc:2486) with -fanalyzer -frounding-math and __builtin_memmove()

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.3

[Bug c++/110137] implement clang -fassume-sane-operator-new

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

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

--- Comment #33 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #32)
> See PR101480 for a reason why to not do this.

That testcase would be fine with "mP" rather than "mC".
Sure, that PR is a reason not to do the stronger (C) case unless some flag is
used.
Maybe we can have both, use "mP" by default and have some (uniquely named)
non-default flag which turns that into "mC" and the delete case into ".Co ",
and perhaps does that even when not from new/delete.

[Bug libstdc++/98723] On Windows with CP936 encoding, regex compiles very slow.

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

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

--- Comment #12 from Jonathan Wakely  ---
Yes, that looks like nice improvement, thanks.

I think it would be easier to read as:

if (!_M_equiv_set.empty())
  {
auto __x = _M_traits.transform_primary(&__ch, &__ch+1);
auto __p = std::find(_M_equiv_set.begin(), _M_equiv_set.end(),
__x);
if (__p != _M_equiv_set.end())
  return true;
  }

Could you send a patch to the mailing lists for review?