[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||zhendong.su at inf dot ethz.ch

--- Comment #20 from Andrew Pinski  ---
*** Bug 110509 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/110509] wrong code at -O3 on x86_64-linux-gnu (nondeterministic hang)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Andrew Pinski  ---
Dup of bug 110228.

*** This bug has been marked as a duplicate of bug 110228 ***

[Bug tree-optimization/110509] wrong code at -O3 on x86_64-linux-gnu (nondeterministic hang)

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

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

--- Comment #1 from Andrew Pinski  ---
Oh this one.

  # _37 = PHI <_39(D)(2), _2(13)>
L1:
  d.0_35 = d;
  _36 = d.0_35 != 0;
  _14 = (int) _36;
  _2 = _14 | _37;
  goto ; [100.00%]

[Bug tree-optimization/110509] New: wrong code at -O3 on x86_64-linux-gnu (nondeterministic hang)

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

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

Bug ID: 110509
   Summary: wrong code at -O3 on x86_64-linux-gnu
(nondeterministic hang)
   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.

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

[521] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../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
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230701 (experimental) (GCC) 
[522] % 
[522] % gcctk -O3 small.c
[523] % for i in $(seq 1 10); do
> echo $i
> timeout -s 9 5 ./a.out
> done
1
2
3
4
Killed
5
6
7
Killed
8
Killed
9
Killed
10
Killed
[524] % 
[524] % cat small.c
int printf (const char *, ...);
int a, d = 10, b = 8, c, e, i, r, f, j;
int g (short l) {
  if (d)
return l;
}
int main () {
  int m[] = {987, 1, 47}, p, o = 2;
 L1:
  p = g (m[2] >= 8);
  while (1) {
while (p > 1)
  while (r) {
int h = m[a];
while (1)
  ;
  }
while (i < 9) {
  if (c && f) {
if (o) {
  p = 7 ^ j;
  b = o = 0;
  if (p <= 4) {
printf ("%d", j);
goto L2;
  }
}
if (j)
  goto L1;
  L2:
b > 1;
  }
  if (b)
return e;
}
  }
  return 0;
}

[Bug tree-optimization/110487] [12/13/14 Regression] invalid wide Boolean value

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #55441|0   |1
is obsolete||

--- Comment #11 from Andrew Pinski  ---
Created attachment 55443
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55443=edit
Patch for the original issue updated

This updated the patch for the original issue slightly by using type rather
than TREE_TYPE (@12) as they will be the same but type is shorter and will be
slightly faster (at compile time).

[Bug tree-optimization/110487] [12/13/14 Regression] invalid wide Boolean value

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

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

--- Comment #10 from Andrew Pinski  ---
Created attachment 55442
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55442=edit
Patch for the two_value pattern

[Bug c++/110463] [13/14 Regression] Mutable subobject is usable in a constant expression

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #4 from Patrick Palka  ---
Should be fixed for GCC 13.2, thanks for the bug report.

[Bug c++/110468] [12/13/14 regression] Internal compiler error in nothrow_spec_p

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

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

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

https://gcc.gnu.org/g:23c64450cbce916547142519a72075d1930c8282

commit r13-7517-g23c64450cbce916547142519a72075d1930c8282
Author: Patrick Palka 
Date:   Thu Jun 29 16:10:18 2023 -0400

c++: NSDMI instantiation during overload resolution [PR110468]

Here we find ourselves instantiating the NSDMI for A<1>::m when
computing argument conversions during overload resolution, and
thus tf_conv is set.  The flag causes mark_used for the constructor
used in the NSDMI to exit early and not instantiate its noexcept-spec,
which eventually leads to an ICE from nothrow_spec_p.

This patch fixes this by clearing any special tsubst flags during
instantiation of an NSDMI, since the result should be independent of
the context that requires the instantiation.

PR c++/110468

gcc/cp/ChangeLog:

* init.cc (maybe_instantiate_nsdmi_init): Mask out all
tsubst flags except for tf_warning_or_error.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/noexcept79.C: New test.

(cherry picked from commit 9479da4515f7d019b4ef282d0e21536431c44f71)

[Bug c++/110463] [13/14 Regression] Mutable subobject is usable in a constant expression

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:8f2cafc03f645748109291710157fdeceac32ee1

commit r13-7516-g8f2cafc03f645748109291710157fdeceac32ee1
Author: Patrick Palka 
Date:   Thu Jun 29 16:02:04 2023 -0400

c++: unpropagated CONSTRUCTOR_MUTABLE_POISON [PR110463]

Here we're incorrectly accepting the mutable member accesses because
cp_fold neglects to propagate CONSTRUCTOR_MUTABLE_POISON when folding a
CONSTRUCTOR.

PR c++/110463

gcc/cp/ChangeLog:

* cp-gimplify.cc (cp_fold) : Propagate
CONSTRUCTOR_MUTABLE_POISON.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-mutable6.C: New test.

(cherry picked from commit fd8a1be04d4cdbfefea457b99ed8404d77b35dd6)

[Bug tree-optimization/110487] [12/13/14 Regression] invalid wide Boolean value

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

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Andrew Pinski from comment #5)
> > I think there is zero_one_value_p is also accepting signed-boolean:32
> > incorrectly too ...
> 
> No, zero_one_value_p is fine as truth_valued_p only accepts single bit
> integeral types.
> 
> Though the pattern mentioned in comment #3 is still an issue ...

The pattern in comment # 3 is especially an issue with strict enum even.

[Bug tree-optimization/110487] [12/13/14 Regression] invalid wide Boolean value

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #5)
> I think there is zero_one_value_p is also accepting signed-boolean:32
> incorrectly too ...

No, zero_one_value_p is fine as truth_valued_p only accepts single bit
integeral types.

Though the pattern mentioned in comment #3 is still an issue ...

[Bug tree-optimization/110487] [12/13/14 Regression] invalid wide Boolean value

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #55440|0   |1
is obsolete||

--- Comment #7 from Andrew Pinski  ---
Created attachment 55441
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55441=edit
Fixes the first part

Attach the correct patch this time around.

[Bug tree-optimization/110487] [12/13/14 Regression] invalid wide Boolean value

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

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

--- Comment #6 from Andrew Pinski  ---
Created attachment 55440
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55440=edit
Fixes the first part

Here is the patch which fixes the first part, I will fix zero_one_p too.

[Bug tree-optimization/110508] [14 Regression] ICE (Segfault) during widening_mul, in match_uaddc_usubc

[ali.mpfard at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Ali Mohammad Pur Fard  ---
Can confirm that the patch
() fixes the original
reproducer.

[Bug libstdc++/110504] std::format("{:%S}", duration>(4)) returns "02.0" instead of "02"

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

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

--- Comment #1 from Jonathan Wakely  ---
I have a patch to fix this:

--- a/libstdc++-v3/include/bits/chrono_io.h
+++ b/libstdc++-v3/include/bits/chrono_io.h
@@ -1079,7 +1079,9 @@ namespace __format
{
  locale __loc = _M_locale(__ctx);
  auto __ss = __hms.subseconds();
- if constexpr (is_floating_point_v)
+ if (__ss == __ss.zero())
+   ; // Do not write all-zero fractional part.
+ else if constexpr (is_floating_point_v)
{
  __out = std::format_to(__loc, std::move(__out),
 _GLIBCXX_WIDEN("{:.{}Lg}"),


However the example in [time.clock.utc.nonmembers] suggests that in fact
printing the zeros is correct. The sys_time value is printed as
"2015-06-30 23:59:60.000 UTC" which would be altered by the patch above.

[Bug other/110505] Memory Problems with Array Constructor From Zero Size Allocatable Array Function Result

[everythingfunctional at protonmail dot com via Gcc-bugs]

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

Brad Richardson  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED
 Resolution|MOVED   |INVALID

--- Comment #5 from Brad Richardson  ---
Got it. Happy to close this one then.

[Bug tree-optimization/110508] [14 Regression] ICE (Segfault) during widening_mul, in match_uaddc_usubc

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

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 55439
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55439=edit
gcc14-pr110508.patch

Untested fix.

[Bug other/110505] Memory Problems with Array Constructor From Zero Size Allocatable Array Function Result

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |MOVED
   See Also||https://bugs.kde.org/show_b
   ||ug.cgi?id=470520
 Status|WAITING |RESOLVED

--- Comment #4 from Andrew Pinski  ---
Actually it was reported to valgrind already:
https://bugs.kde.org/show_bug.cgi?id=470520

[Bug other/110505] Memory Problems with Array Constructor From Zero Size Allocatable Array Function Result

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|fortran |other

--- Comment #3 from Andrew Pinski  ---
>The following program breaks valgrind.

I suspect you should report this to valgrind instead of here. And from the
other person who tried it, it works with an older version of valgrind, I am
suspecting valgrind has a regression in it rather than libgfortran ...

[Bug tree-optimization/110503] [13/14 Regression] Dead Code Elimination Regression at -O3 since r13-322-g7f04b0d786e

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> 
> Oh and had:
>   # RANGE [irange] int [-128, 127]
>   _10 = (intD.6) _9;
>   # RANGE [irange] int [0, 1] NONZERO 0x1
>   _11 = 1 % _10;
> 
> I wonder if we could optimize `1 % b` into just `b != 1` (since 1 % 0 is
> undefined) which will further reduce things here.

That does not change the size of the loop though and we are still left with:
  size:   1 _10 = _9 == 1;
  size:   0 _11 = (unsigned int) _10;
  size:   1 _12 = -_11;
  size:   2 if (_12 > 2)

But at least now we just need to optimize the above to just `if (_9 == 1)`

Something like:
(simplify
 (gt (negative zero_one_value@0) INTEGER_CST@1)
 (if (wi::to_wide (@1) >= 1 && TYPE_UNSIGNED (TREE_TYPE (@1)))
  (ne @0 { build_zero_cst (TREE_TYPE (@1)); } )
  (if (wi::to_wide (@1) >= 0 && !TYPE_UNSIGNED (TREE_TYPE (@1)))
   (eq @0 { build_zero_cst (TREE_TYPE (@1)); } )
  )
 )
)

But I get the feeling this should be done in VRP instead of match ...

[Bug c++/110508] [14 Regression] ICE (Segfault) during widening_mul, in match_uaddc_usubc

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Summary|ICE (Segfault) during   |[14 Regression] ICE
   |widening_mul, in|(Segfault) during
   |match_uaddc_usubc   |widening_mul, in
   ||match_uaddc_usubc
 Status|UNCONFIRMED |ASSIGNED
 CC||jakub at gcc dot gnu.org
   Last reconfirmed||2023-06-30
   Target Milestone|--- |14.0
   Priority|P3  |P1
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Reduced testcase for -O2:

void
foo (unsigned long a, unsigned long b, unsigned long *c, _Bool d)
{
  __builtin_addcl (a, b, d, c);
}

[Bug c++/110508] ICE (Segfault) during widening_mul, in match_uaddc_usubc

[ali.mpfard at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Ali Mohammad Pur Fard  ---
Created attachment 55438
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55438=edit
Reduced source

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #42 from Jürgen Reuter  ---
(In reply to Jakub Jelinek from comment #41)
> 
> 0x04f5dc90 is pseudo NaN:
> Pseudo Not a Number. The sign bit is meaningless. The 8087 and 80287 treat
> this as a Signaling Not a Number. The 80387 and later treat this as an
> invalid operand.
> So, if that comes from some random number generator, I'd say that random
> number generator should be fixed not to create the erroneous cases for
> https://en.wikipedia.org/wiki/Extended_precision

Hm, the example provided does not use extended precision.

[Bug c++/110508] New: ICE (Segfault) during widening_mul, in match_uaddc_usubc

[ali.mpfard at gmail dot com via Gcc-bugs]

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

Bug ID: 110508
   Summary: ICE (Segfault) during widening_mul, in
match_uaddc_usubc
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ali.mpfard at gmail dot com
  Target Milestone: ---

Created attachment 55437
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55437=edit
Original preprocessed source

GCC trunk (commit db38b285ba61c5b888adc0d117177bfd774c1153, not bisected)
segfaults when compiling the reduced source below (also attached: full
preprocessed source), also related to #79173
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173>. 

// Target: x86_64-pc-linux-gnu
// Configured with: ./configure --prefix=/opt/gcc --disable-nls
--disable-libstdcxx-pch --enable-shared --enable-languages=c,c++
--enable-default-pie --enable-lto --enable-threads=posix
// Thread model: posix
// Supported LTO compression algorithms: zlib zstd
// gcc version 14.0.0 20230630 (experimental) (GCC)
//
// secp.cpp: In instantiation of 'static void
Detail::StorageOperations::add(auto:1) [with int  = 0; auto:1 =
int]':
// secp.cpp:23:34:   required from 'void Detail::UFixedBigInt::addc(T, bool)
[with T = Detail::UFixedBigInt]'
// secp.cpp:31:12:   required from here
// secp.cpp:9:11: error: reference 'carry' is initialized with itself
[-Werror=init-self]
// 9 | bool  = carry;
//   |   ^
// secp.cpp:11:9: error: unused variable 'outputoutput'
[-Werror=unused-variable]
//11 | outputoutput =
//   | ^~~~
// secp.cpp: In static member function 'static void
Detail::StorageOperations::add(auto:1) [with int  = 0; auto:1 =
int]':
// secp.cpp:9:11: error: 'carry' is used uninitialized [-Werror=uninitialized]
// 9 | bool  = carry;
//   |   ^
// secp.cpp:9:11: note: 'carry' was declared here
// 9 | bool  = carry;
//   |   ^
// during GIMPLE pass: widening_mul
// secp.cpp: In function 'void modular_multiply()':
// secp.cpp:29:6: internal compiler error: Segmentation fault
//29 | void modular_multiply() {
//   |  ^~~~
// 0x149fb7f crash_signal
//  ../.././gcc/toplev.cc:314
// 0xe80858 gimple_bb(gimple const*)
//  ../.././gcc/gimple.h:1905
// 0x114529c gsi_for_stmt(gimple*)
//  ../.././gcc/gimple-iterator.cc:617
// 0x1640ff7 match_uaddc_usubc
//  ../.././gcc/tree-ssa-math-opts.cc:4864
// 0x164b6ce after_dom_children
//  ../.././gcc/tree-ssa-math-opts.cc:5589
// 0x217dbba dom_walker::walk(basic_block_def*)
//  ../.././gcc/domwalk.cc:354
// 0x163c836 execute
//  ../.././gcc/tree-ssa-math-opts.cc:5666
// Please submit a full bug report, with preprocessed source.
// Please include the complete backtrace with any bug report.
// See <https://gcc.gnu.org/bugs/> for instructions.

// /opt/gcc/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/cc1plus -quiet -D_GNU_SOURCE
secp.cpp -quiet -dumpdir a- -dumpbase secp.cpp -dumpbase-ext .cpp
-mtune=generic -march=x86-64 -g1 -O2 -Wall -Wextra -Wno-unknown-warning-option
-Wno-unused-command-line-argument -Werror -Wno-expansion-to-defined
-Wno-literal-suffix -Wno-dangling-reference -Wno-maybe-uninitialized
-Wno-shorten-64-to-32 -Wvla -std=c++20 -fno-exceptions -fsigned-char
-fno-semantic-interposition -fPIC -freport-bug -o - -frandom-seed=0
-fdump-noaddr

# 0 "secp.cpp"
# 1 "/home/test/Workspace/serenity/reduce//"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "secp.cpp"
template  constexpr bool IsSame = false;
namespace Detail {
typedef long NativeWord;
struct IntegerWrapper;
long add_words_word1;
long add_words_word2;
struct StorageOperations {
  template  static void add(auto) {
bool  = carry;
NativeWord ncarry,
outputoutput =
__builtin_addcl(add_words_word1, add_words_word2, carry,
reinterpret_cast());
carry = ncarry;
  }
};
template 
concept UFixedInt = !
IsSame;
int m_data;
struct UFixedBigInt {
  template  void addc(T, bool) {
StorageOperations::add(m_data);
  }
};
}
using Detail::UFixedBigInt;
bool modular_multiply_carry;
void modular_multiply() {
  UFixedBigInt mult, mp;
  mult.addc(mp, modular_multiply_carry);
}

[Bug tree-optimization/110503] [13/14 Regression] Dead Code Elimination Regression at -O3 since r13-322-g7f04b0d786e

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-06-30
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> I noticed there is a missing optimization here (during VRP1):
>   _29 = _11 == 0;
>   _30 = (unsigned int) _29;
>   _14 = -_30;
>   if (_14 > 2)
> 
> That is just:
>   if (_14 != 0)
> or:
>   if (_29 != 0)
> or rather:
>   if (_11 == 0)

I wonder if the above will decrease the "size" estimates enough to optimize
this again ...

Oh and had:
  # RANGE [irange] int [-128, 127]
  _10 = (intD.6) _9;
  # RANGE [irange] int [0, 1] NONZERO 0x1
  _11 = 1 % _10;

I wonder if we could optimize `1 % b` into just `b != 1` (since 1 % 0 is
undefined) which will further reduce things here.

[Bug tree-optimization/110503] [13/14 Regression] Dead Code Elimination Regression at -O3 since r13-322-g7f04b0d786e

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

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

--- Comment #1 from Andrew Pinski  ---
I noticed there is a missing optimization here (during VRP1):
  _29 = _11 == 0;
  _30 = (unsigned int) _29;
  _14 = -_30;
  if (_14 > 2)

That is just:
  if (_14 != 0)
or:
  if (_29 != 0)
or rather:
  if (_11 == 0)


Oh the difference between GCC 12 and GCC 13 is that completely unroll does not
happen.

GCC 13:
size: 13-6, last_iteration: 13-6
  Loop size: 13
  Estimated size after unrolling: 14
Not unrolling loop 1: contains call and code would grow.
Not peeling: upper bound is known so can unroll completely

GCC 12:
size: 13-6, last_iteration: 13-6
  Loop size: 13
  Estimated size after unrolling: 14
Making edge 11->7 impossible by redistributing probability to other edges.
Making edge 15->7 impossible by redistributing probability to other edges.
Making edge 6->8 impossible by redistributing probability to other edges.
/app/example.cpp:17:14: optimized: loop with 2 iterations completely unrolled
(header execution count 1073741833)
Exit condition of peeled iterations was eliminated.

Basically the comparatively size would increase too much ...

So this was just by accident I think.

[Bug target/96532] [m68k] gcc 10.x generates calls to memset even for very small amounts

[eerott at gmail dot com via Gcc-bugs]

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

Eero Tamminen  changed:

   What|Removed |Added

 CC||eerott at gmail dot com

--- Comment #7 from Eero Tamminen  ---
Timing and profiling whole EmuTOS (m68k ROM) bootup, showed these added
memcpy() calls adding 8% to the boot time [1] with GCC 13.1.

For that particular case, all those extra (2) memcpy() calls, and the
associated 8% bootup overhead, came from this loop:
---
uint32_t pair_planes[4];
...
for (i = 0; i < v_planes / 2; i++) {
*(uint32_t*)addr = pair_planes[i];
addr += sizeof(uint32_t);
} 
---
And it went away when GCC -freestanding option was used.

Without that memcpy() overhead, GCC 13.1 perf was then very close to GCC 4.6
perf in that particular case (it did not help other cases where newer GCC was
slower).

Further testing with (compiler explorer) showed that when compiler was given a
better hint that the loop it replaced with memcpy() actually loops max 4 times,
those memcpy() instances went also away:
---
if (v_planes > 2*ARRAY_SIZE(pair_planes)) return;
---

How GCC deduced that above loop was large enough that it makes sense to replace
it with memcpy() overhead?  From the max valid index for "pair_planes", it
should have already been clear that any large indexes get to "undefined
behavior".

[1] 1/3 of the boot time went to timeout for waiting user interaction, and 1/3
went to waiting slow disk responses, so in reality the overhead was really 3x
8%.

[Bug fortran/110505] Memory Problems with Array Constructor From Zero Size Allocatable Array Function Result

[everythingfunctional at protonmail dot com via Gcc-bugs]

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

--- Comment #2 from Brad Richardson  ---
I'm on and x86 Arch Linux machine. By works do you mean valgrind doesn't report
any errors at all? I can also try a system upgrade and reboot and see if
anything changes.

[Bug tree-optimization/110503] [13/14 Regression] Dead Code Elimination Regression at -O3 since r13-322-g7f04b0d786e

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |13.2

[Bug c/110500] gcc: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in c_parser_omp_clause_allocate

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

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

--- Comment #2 from Andrew Pinski  ---
Created attachment 55436
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55436=edit
Patch which should fix this

This patch will fix this (and other) ICEs.
There might be more further below but I didn't check.
Someone can take this patch and finish it up.

[Bug c/110500] gcc: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in c_parser_omp_clause_allocate

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-06-30

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

[Bug c/110500] gcc: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in c_parser_omp_clause_allocate

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |minor

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

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

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

--- Comment #41 from Jakub Jelinek  ---
(In reply to Uroš Bizjak from comment #39)
> (In reply to anlauf from comment #36)
> > Breakpoint 2, rng_stream.rng_stream_s::mmm_mod (x1=330289839997,
> > x2=4294967087) at rng_stream_sub.f90:336
> > 336 res = mod (x1, x2)
> > (gdb) info float
> >   R7: Valid   0x401be51fb578 +480507567 
> >   R6: Valid   0x401be51fb578 +480507567 
> >   R5: Zero0x +0 
> >   R4: Zero0x +0 
> >   R3: Zero0x +0 
> >   R2: Zero0x +0 
> >   R1: Zero0x +0 
> > =>R0: Special 0x04f5dc90 Unsupported

0x04f5dc90 is pseudo NaN:
Pseudo Not a Number. The sign bit is meaningless. The 8087 and 80287 treat this
as a Signaling Not a Number. The 80387 and later treat this as an invalid
operand.
So, if that comes from some random number generator, I'd say that random number
generator should be fixed not to create the erroneous cases for
https://en.wikipedia.org/wiki/Extended_precision

[Bug tree-optimization/110381] [11/12/13 Regression] double counting for sum of structs of floating point types

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

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

--- Comment #16 from Andrew Pinski  ---
I suspect this patch will fix the arm failure:
```
diff --git a/gcc/testsuite/gcc.dg/vect/pr110381.c
b/gcc/testsuite/gcc.dg/vect/pr110381.c
index dc8c6a8f683..ee78666d2e8 100644
--- a/gcc/testsuite/gcc.dg/vect/pr110381.c
+++ b/gcc/testsuite/gcc.dg/vect/pr110381.c
@@ -1,4 +1,5 @@
 /* { dg-do run } */
+/* { dg-require-effective-target vect_float_strict } */

 #include "tree-vect.h"




Arm enables -funsafe-math-optimizations for the vector testsuite (as it
requires because of denormals IIRC) but this testcase requires strict ordering
so you need to not allow `-funsafe-math-optimizations` which is what
vect_float_strict does.

[Bug tree-optimization/110502] [14 Regression] Dead Code Elimination Regression at -Os since r14-1656-g55fcaa9a8bd

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-06-30
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

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

[Bug fortran/110505] Memory Problems with Array Constructor From Zero Size Allocatable Array Function Result

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2023-06-30
 Ever confirmed|0   |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
Works here on x86_64-pc-linux-gnu with all branches tested (7...14),
but an older version of valgrind (3.18.1).

Need more details on your system.

[Bug tree-optimization/110502] [14 Regression] Dead Code Elimination Regression at -Os since r14-1656-g55fcaa9a8bd

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |14.0
 Target||x86_64-linux-gnu

--- Comment #1 from Andrew Pinski  ---
Note on aarch64, it is still optimized (not you need -fsigned-char there or
change all char to be `signed char`).

Note also with -fno-ivopts, even GCC 13 is not optimizing out the call to foo.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

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

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

--- Comment #40 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #38)
> At the moment unfortunately too busy to provide a smaller reproducer (which
> also still has a small dependency on a dynamic library),

I have just commented out the references to dlopen, dlclose, dlsym, dlerror
in os_interface_sub.f90, removed the -ldl and can still reproduce the failure.

[Bug tree-optimization/110506] [14 Regression] Ice: tree check: expected none of vector_type, have vector_type in get_value_for_expr, at tree-ssa-ccp.cc:686

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> No reason to do a bisect as it was introduced by the extra checking commit.

That is r14-2150 .

[Bug tree-optimization/110506] [14 Regression] Ice: tree check: expected none of vector_type, have vector_type in get_value_for_expr, at tree-ssa-ccp.cc:686

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-06-30
 Status|UNCONFIRMED |NEW
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug libstdc++/110507] cannot initialize immovable type in a std::tuple

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

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

--- Comment #2 from Andrew Pinski  ---
Note if you change immovable not to be an empty class, it works and this is why
it is a dup of bug 98995 .

[Bug c++/98995] [10/11/12/13/14 Regression] Copy elision not applied to members declared with [[no_unique_address]] or a empty base class

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||eric.niebler at gmail dot com

--- Comment #11 from Andrew Pinski  ---
*** Bug 110507 has been marked as a duplicate of this bug. ***

[Bug libstdc++/110507] cannot initialize immovable type in a std::tuple

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
>The following should work since C++17, when C++ got guaranteed copy elision.

Except for Defect report 2403 (https://wg21.link/cwg2403).

This is a dup of bug 98995.

*** This bug has been marked as a duplicate of bug 98995 ***

[Bug c++/105667] [C++20] lambas in template argument sometimes causes an ICE (seg fault)

[blubban at gmail dot com via Gcc-bugs]

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

Alfred Agrell  changed:

   What|Removed |Added

 CC||blubban at gmail dot com

--- Comment #8 from Alfred Agrell  ---
I ran into something similar. My reduced testcase is


struct class1
{
virtual void a_function() = 0;
};

template() {}>
class class2 {};

template
struct class3 : public class1 {
void a_function()
{
class2<> x;
}
};

struct class4 : public class3 {
class4() {}
};


https://godbolt.org/z/GKo5oWe8j

[Bug libstdc++/110507] New: cannot initialize immovable type in a std::tuple

[eric.niebler at gmail dot com via Gcc-bugs]

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

Bug ID: 110507
   Summary: cannot initialize immovable type in a std::tuple
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric.niebler at gmail dot com
  Target Milestone: ---

The following should work since C++17, when C++ got guaranteed copy elision.


#include 

struct immovable {
  immovable() = default;
  immovable(immovable&&) = delete;
};

struct init_immovable {
  operator immovable() const { return {}; }
};

int main() {
  std::tuple m{init_immovable{}};
}


result:

In file included from :1:
/opt/compiler-explorer/gcc-trunk-20230630/include/c++/14.0.0/tuple: In
instantiation of 'constexpr std::_Head_base<_Idx, _Head,
true>::_Head_base(_UHead&&) [with _UHead = init_immovable; long unsigned int
_Idx = 0; _Head = immovable]':
/opt/compiler-explorer/gcc-trunk-20230630/include/c++/14.0.0/tuple:514:38:  
required from here
:13:43:   in 'constexpr' expansion of
'm.std::tuple::tuple(init_immovable())'
/opt/compiler-explorer/gcc-trunk-20230630/include/c++/14.0.0/tuple:891:54:   in
'constexpr' expansion of '((std::_Tuple_impl<0,
immovable>*)this)->std::_Tuple_impl<0,
immovable>::_Tuple_impl((* & std::forward((* &
__elements#0))))'
/opt/compiler-explorer/gcc-trunk-20230630/include/c++/14.0.0/tuple:92:11:
error: use of deleted function 'immovable::immovable(immovable&&)'
   92 | : _M_head_impl(std::forward<_UHead>(__h)) { }
  |   ^~~
:5:3: note: declared here
5 |   immovable(immovable&&) = delete;
  |   ^


https://godbolt.org/z/nfd1zdcqs

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #39 from Uroš Bizjak  ---
(In reply to anlauf from comment #36)
> Breakpoint 2, rng_stream.rng_stream_s::mmm_mod (x1=330289839997,
> x2=4294967087) at rng_stream_sub.f90:336
> 336 res = mod (x1, x2)
> (gdb) info float
>   R7: Valid   0x401be51fb578 +480507567 
>   R6: Valid   0x401be51fb578 +480507567 
>   R5: Zero0x +0 
>   R4: Zero0x +0 
>   R3: Zero0x +0 
>   R2: Zero0x +0 
>   R1: Zero0x +0 
> =>R0: Special 0x04f5dc90 Unsupported

Here is the problem. FPREM chokes on invalid input in R0.

[1] Says that IA (invalid arithmetic) exception is generated for unsupported
format, and this is what happened above:

#IA Source operand is an SNaN value, modulus is 0, dividend is ∞, or
unsupported format.

[1] https://www.felixcloutier.com/x86/fprem

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #38 from Jürgen Reuter  ---
At the moment unfortunately too busy to provide a smaller reproducer (which
also still has a small dependency on a dynamic library), but one more info:
inserting the explicit operations instead of the intrinsic mod function leads
to no more NaNs with the gfortran 14, but still is numerically different from
the one with previous gfortran versions: so it looks like it leads to a
different random number sequence which is really disturbing.

[Bug tree-optimization/110506] [14 Regression] Ice: tree check: expected none of vector_type, have vector_type in get_value_for_expr, at tree-ssa-ccp.cc:686

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #1 from Andrew Pinski  ---
No reason to do a bisect as it was introduced by the extra checking commit.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

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

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

--- Comment #37 from anlauf at gcc dot gnu.org ---
After the FPE:

(gdb) info float
  R7: Valid   0x401be51fb578 +480507567 
  R6: Valid   0x401be51fb578 +480507567 
  R5: Zero0x +0 
  R4: Zero0x +0 
  R3: Zero0x +0 
  R2: Zero0x +0 
  R1: Zero0x +0 
=>R0: Special 0x04f5dc90 Unsupported

Status Word: 0x82c1   IE  ES   SF  C1  
   TOP: 0
Control Word:0x0372  DM   UM PM
   PC: Extended Precision (64-bits)
   RC: Round to nearest
Tag Word:0x0556
Instruction Pointer: 0x00:0x004031d2
Operand Pointer: 0x00:0x011b5708
Opcode:  0xdd45

[Bug tree-optimization/110506] [14 Regression] Ice: tree check: expected none of vector_type, have vector_type in get_value_for_expr, at tree-ssa-ccp.cc:686

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |tree-optimization
   Keywords||ice-on-valid-code
Summary|ice: tree check: expected   |[14 Regression] Ice: tree
   |none of vector_type,  have  |check: expected none of
   |vector_type in  |vector_type,  have
   |get_value_for_expr, at  |vector_type in
   |tree-ssa-ccp.cc:686 |get_value_for_expr, at
   ||tree-ssa-ccp.cc:686
   Target Milestone|--- |14.0

[Bug middle-end/31985] Wide operations (i.e. adddi3) are split too late

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

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

--- Comment #5 from Roger Sayle  ---
This is now fixed on mainline.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

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

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

--- Comment #36 from anlauf at gcc dot gnu.org ---
Breakpoint 2, rng_stream.rng_stream_s::mmm_mod (x1=330289839997, x2=4294967087)
at rng_stream_sub.f90:336
336 res = mod (x1, x2)
(gdb) info float
  R7: Valid   0x401be51fb578 +480507567 
  R6: Valid   0x401be51fb578 +480507567 
  R5: Zero0x +0 
  R4: Zero0x +0 
  R3: Zero0x +0 
  R2: Zero0x +0 
  R1: Zero0x +0 
=>R0: Special 0x04f5dc90 Unsupported

Status Word: 0x
   TOP: 0
Control Word:0x0372  DM   UM PM
   PC: Extended Precision (64-bits)
   RC: Round to nearest
Tag Word:0x0556
Instruction Pointer: 0x00:0x
Operand Pointer: 0x00:0x
Opcode:  0x
(gdb) n

Program received signal SIGFPE, Arithmetic exception.
0x00678e6a in rng_stream.rng_stream_s::mmm_mod (x1=330289839997,
x2=4294967087) at rng_stream_sub.f90:336
336 res = mod (x1, x2)

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #35 from Uroš Bizjak  ---
(In reply to anlauf from comment #33)
> (In reply to Jakub Jelinek from comment #32)
> > Then maybe r13-6361-g8020c9c42349f51f75239b
> > is the commit that changed it?
> > Would be good to put a breakpoint at that instruction and see in which
> > iteration it results in NaN and what operands it had...
> 
> Program received signal SIGFPE, Arithmetic exception.
> 0x00678f1a in rng_stream.rng_stream_s::mmm_mod (x1=330289839997,
> x2=4294967087) at rng_stream_sub.f90:336
> 336 res = mod (x1, x2)
> (gdb) p x1
> $1 = 330289839997
> (gdb) p x2
> $2 = 4294967087
> 
> Strangely enough, a small testcase with these arguments does not fail...

Please show the FP registers (and coprocessor state, 'info float') just before
the FPREM instruction. These two values (as shown) are nothing special, but
perhaps FP register value contains something that FPREM does not like. Also,
please show the state after FPREM is executed. Please note that FPREM is
performed in the loop, so perhaps a couple of trips through the loop will be
needed.

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

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #55427|0   |1
is obsolete||

--- Comment #73 from Jakub Jelinek  ---
Created attachment 55435
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55435=edit
gcc14-bitint-wip.patch

WIP on casts, casts from non-_BitInt integers or small/middle _BitInt to
large/huge _BitInt tested (at least when used as operands of mergeable
operations or comparisons/shifts/stores), cast between different precision
large/huge _BitInt implemented but so far untested, casts from large/huge
_BitInt to non-_BitInt integers or small/middle _BitInt yet to be implemented.
After that multiplication/division/modulo, then casts from/to floating point.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

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

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

--- Comment #34 from anlauf at gcc dot gnu.org ---
A few more data points:

reverting r13-6361-g8020c9c42349f51f75239b on 13-branch fixes the issue:
no fprem generated, no FPE.

Adding -ffinite-math-only to the modified 13-branch restores the FPE.

Compiling the affected module (only) with 12-branch and linking everything
with 14-mainline shows the same: fprem is used only with -ffinite-math-only,
and I get an FPE even with 12-branch in that case.

Same with 11-branch.

I am still not sure why it cannot be reproduced with a smaller example,
thus I hope that Jürgen can provide a significantly smaller reproducer.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

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

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

--- Comment #33 from anlauf at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #32)
> Then maybe r13-6361-g8020c9c42349f51f75239b
> is the commit that changed it?
> Would be good to put a breakpoint at that instruction and see in which
> iteration it results in NaN and what operands it had...

Program received signal SIGFPE, Arithmetic exception.
0x00678f1a in rng_stream.rng_stream_s::mmm_mod (x1=330289839997,
x2=4294967087) at rng_stream_sub.f90:336
336 res = mod (x1, x2)
(gdb) p x1
$1 = 330289839997
(gdb) p x2
$2 = 4294967087

Strangely enough, a small testcase with these arguments does not fail...

[Bug tree-optimization/101832] __builtin_object_size(P->M, 1) where M ends with a flex-array behaves like sizeof()

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

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Qing Zhao :

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

commit r14-2225-ge050ce7c3adf71eedd5482c29cf54b827e026642
Author: Qing Zhao 
Date:   Fri Jun 30 18:24:34 2023 +

Use TYPE_INCLUDES_FLEXARRAY in __builtin_object_size [PR
tree-optimization/101832]

__builtin_object_size should treat struct with TYPE_INCLUDES_FLEXARRAY as
flexible size.

gcc/ChangeLog:

PR tree-optimization/101832
* tree-object-size.cc (addr_object_size): Handle structure/union
type
when it has flexible size.

gcc/testsuite/ChangeLog:

PR tree-optimization/101832
* gcc.dg/builtin-object-size-pr101832.c: New test.

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||uros at gcc dot gnu.org

--- Comment #32 from Jakub Jelinek  ---
Then maybe r13-6361-g8020c9c42349f51f75239b
is the commit that changed it?
Would be good to put a breakpoint at that instruction and see in which
iteration it results in NaN and what operands it had...

[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer

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

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

--- Comment #31 from anlauf at gcc dot gnu.org ---
Looking at rng_stream_sub.o with objdump, I see fprem generated for 13 & 14,
but not for 12.

I haven't yet found an option to suppress its generation and fall back to
the behavior of 12-branch.

[Bug c/110506] New: ice: tree check: expected none of vector_type, have vector_type in get_value_for_expr, at tree-ssa-ccp.cc:686

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 110506
   Summary: ice: tree check: expected none of vector_type,  have
vector_type in get_value_for_expr, at
tree-ssa-ccp.cc:686
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C code:

struct {
  long *sp;
  long *csp
} neko_interp_loop_vm;
int neko_interp_loop_vm_2;
void neko_interp_loop() {
  long pc[] = {&, &, &,
   &, &};
  long *sp, *csp = neko_interp_loop_vm.csp;
LabelAccGlobal:
  neko_interp_loop_vm.sp = sp;
  neko_interp_loop_vm.csp = csp;
  goto * 0;
LabelTailCall:
  csp = sp -= neko_interp_loop_vm_2;
LabelMakeArray2:
LabelPhysCompare:
LabelLoop:
  goto * 0;
}

compiled by g:9757e4440bd8755d, does this:

$ ~/gcc/results.20230628.asan.ubsan/bin/gcc -c -w -O2 bug936.c
during GIMPLE pass: ccp
/home/dcb38/rpmbuild/BUILD/neko-2-3-0/vm/interp.c: In function
‘neko_interp_loop’:
/home/dcb38/rpmbuild/BUILD/neko-2-3-0/vm/interp.c:613:9: internal compiler
error: tree check: expected none of vector_type, have vector_type in
get_value_for_expr, at tree-ssa-ccp.cc:686
  613 | int_val neko_interp_loop( neko_vm *VM_ARG, neko_module *m, int_val
_acc, int_val *_pc ) {
  | ^~~~
0x11656f9 tree_not_check_failed(tree_node const*, char const*, int, char
const*, ...)
../../trunk.year/gcc/tree.cc:8936
0xf75774 tree_not_check(tree_node*, char const*, int, char const*, tree_code)
../../trunk.year/gcc/tree.h:3581
0xf75774 get_value_for_expr(tree_node*, bool)
../../trunk.year/gcc/tree-ssa-ccp.cc:686

It was fine with a version from a couple of days earlier:

foundBugs $ ~/gcc/results.20230626.asan.ubsan/bin/gcc -c -w -O2 bug936.c
foundBugs $ ~/gcc/results.20230626.asan.ubsan/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/dcb38/gcc/results.20230626.asan.ubsan/bin/gcc
COLLECT_LTO_WRAPPER=/home/dcb38/gcc/results.20230626.asan.ubsan/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../trunk.year/configure
--prefix=/home/dcb38/gcc/results.20230626.asan.ubsan --disable-multilib
--disable-bootstrap --with-build-config=bootstrap-asan
--with-build-config=bootstrap-ubsan --with-pkgversion=3a39a31b8ae9c646
--enable-checking=df,extra,fold,rtl,yes --enable-languages=c,c++,fortran
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20230626 (experimental) (3a39a31b8ae9c646)

[Bug libstdc++/110355] std::format("{}", 1e-7) returns "1e-07" instead of "1e-7"

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
Oh this is actually std::to_chars not std::format

#include 

int main()
{
  char buf[5];
  std::to_chars(buf, buf+5, 1e-7);
  if (__builtin_memcmp(buf, "1e-7", 4))
__builtin_abort();
}

[Bug libstdc++/110504] std::format("{:%S}", duration>(4)) returns "02.0" instead of "02"

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2023-06-30
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

[Bug target/110217] [avr] SREG: use BSET and BCLR instead of load/modify/write

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #1 from Georg-Johann Lay  ---
The only case where this might make sense is for bit 7 (the I-flag), however
the established coding style is to use cli() and sei() from AVR-LibC, cf.
documentation of #include :

https://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html

For more sophitsticated use cases there is even ATOMIC_BLOCK and friends
provided by #include , cf:

https://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html

This has the additional benefit of being more readable than bit manipulations.  

Apart from that, the proposed patch won't work for indirect addressing, or when
the compiler is turning direct addresses to indirect addresses (using CSE etc,
common subexpression elimination and similar strategies).

Also the patch relies on insn combine which only runs when optimization is on,
thus any application which relies on that optimization will glitch at -O0.

So I am inclined to "won't fix" this PR.

Maybe you just missed avr/interrupt.h and / or util/atomic.h ?

If you must not use AVR-LibC for some reason, then the next best approach is to
use __builtin_avr_sei(), cf. AVR built-in functions:

https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/AVR-Built-in-Functions.html

Or implement it as static inline function that does __asm volatile ("sei" :::
"memory") if you are not allowed to use built-ins.

[Bug fortran/110505] New: Memory Problems with Array Constructor From Zero Size Allocatable Array Function Result

[everythingfunctional at protonmail dot com via Gcc-bugs]

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

Bug ID: 110505
   Summary: Memory Problems with Array Constructor From Zero Size
Allocatable Array Function Result
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: everythingfunctional at protonmail dot com
  Target Milestone: ---

The following program breaks valgrind. Note that the loop is actually required
and can't be manually unrolled or it doesn't exhibit the same behavior.

program example
integer :: i
do i = 1, 2
print *, [make_array(), make_array()]
end do
contains
function make_array()
integer, allocatable :: make_array(:)

allocate(make_array(0))
end function
end program

$ gfortran -g example.f90
$ valgrind ./a.out   
==216962== Memcheck, a memory error detector
==216962== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==216962== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
==216962== Command: ./a.out
==216962== 
==216962== realloc() with size 0
==216962==at 0x4846BE0: realloc (vg_replace_malloc.c:1649)
==216962==by 0x10960F: MAIN__ (example.f90:4)
==216962==by 0x10976F: main (example.f90:3)
==216962==  Address 0x4e68a30 is 0 bytes after a block of size 0 alloc'd
==216962==at 0x4846BE0: realloc (vg_replace_malloc.c:1649)
==216962==by 0x1094BD: MAIN__ (example.f90:4)
==216962==by 0x10976F: main (example.f90:3)
==216962== 

Error:
  unknown error code 14

Memcheck: the 'impossible' happened:
   unknown error code in mc_eq_Error

host stacktrace:
==216962==at 0x58042CDA: show_sched_status_wrk (m_libcassert.c:406)
==216962==by 0x58042E07: report_and_quit (m_libcassert.c:477)
==216962==by 0x580430DF: panic (m_libcassert.c:553)
==216962==by 0x580430DF: vgPlain_tool_panic (m_libcassert.c:568)
==216962==by 0x58039828: vgMemCheck_eq_Error (mc_errors.c:1067)
==216962==by 0x5803E1B7: eq_Error (m_errormgr.c:307)
==216962==by 0x5803E1B7: vgPlain_maybe_record_error (m_errormgr.c:765)
==216962==by 0x580390A4: vgMemCheck_record_realloc_size_zero
(mc_errors.c:896)
==216962==by 0x5800599A: vgMemCheck_realloc (mc_malloc_wrappers.c:583)
==216962==by 0x580A029E: do_client_request (scheduler.c:1987)
==216962==by 0x580A029E: vgPlain_scheduler (scheduler.c:1542)
==216962==by 0x580E58BD: thread_wrapper (syswrap-linux.c:102)
==216962==by 0x580E58BD: run_a_thread_NORETURN (syswrap-linux.c:155)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 216962)
==216962==at 0x4846BE0: realloc (vg_replace_malloc.c:1649)
==216962==by 0x10960F: MAIN__ (example.f90:4)
==216962==by 0x10976F: main (example.f90:3)
client stack range: [0x1FFEFFE000 0x1FFF000FFF] client SP: 0x1FFF000130
valgrind stack range: [0x1002BAA000 0x1002CA9FFF] top usage: 1 of 1048576


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.

[Bug libstdc++/110504] New: std::format("{:%S}", duration>(4)) returns "02.0" instead of "02"

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

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

Bug ID: 110504
   Summary: std::format("{:%S}", duration>(4)) returns "02.0" instead of "02"
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

And std::format("{:%M:%S}", duration>(99)) returns
"01:06.00" instead of "01:06"

[Bug tree-optimization/110503] New: [13/14 Regression] Dead Code Elimination Regression at -O3 since r13-322-g7f04b0d786e

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

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

Bug ID: 110503
   Summary: [13/14 Regression] Dead Code Elimination Regression at
-O3 since  r13-322-g7f04b0d786e
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: theodort at inf dot ethz.ch
  Target Milestone: ---

https://godbolt.org/z/h3G76EEW5

Given the following code:

void foo(void);
static int f = 10, g, h;
static int *i = , *j = , *k = 
static char(a)(int b) {
if (!(((b) >= 1) && ((b) <= 3))) {
__builtin_unreachable();
}
return 0;
}
static char(c)(char d, char e) { return d % e; }
static void l() {
char m, n;
unsigned o;
int *p = 
o = -19;
for (; o > 22; o = o + 8) {
int *q = 
g = 30;
unsigned char d = 60, e = o;
m = d / e;
if ((0 || *q) & m == 0)
;
else {
foo();
n = c(0 != p, *p);
a(n);
*q = 0;
}
}
*i = a(3);
*k = 0 != *j;
}
int main() {
l();
a(h);
}

gcc-trunk -O3 does not eliminate the call to foo:

main:
pushq   %rbx
movl$-19, %ebx
jmp .L5
.p2align 4,,10
.p2align 3
.L8:
callfoo
addl$8, %ebx
.L5:
movl$30, g(%rip)
cmpb$60, %bl
jbe .L8
addl$8, %ebx
cmpl$5, %ebx
jne .L5
movlf(%rip), %edx
xorl%eax, %eax
popq%rbx
movl$0, g(%rip)
testl   %edx, %edx
setne   %al
movl%eax, h(%rip)
xorl%eax, %eax
ret

gcc-12.3.0 -O3 eliminates the call to foo:

main:
movlf(%rip), %edx
xorl%eax, %eax
movl$0, g(%rip)
testl   %edx, %edx
setne   %al
movl%eax, h(%rip)
xorl%eax, %eax
ret

Bisects to r13-322-g7f04b0d786e

[Bug rtl-optimization/110220] [13/14 Regression] ICE in patch_jump_insn, at cfgrtl.cc:1295 - avr/xmega

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||gjl at gcc dot gnu.org

--- Comment #6 from Georg-Johann Lay  ---
I can reproduce Andi's testcase, and with -fdisable-rtl-avr-casesi the ICE goes
away.  Hence

1) This is just an accident, or

2) There is a bug in avr-specific pass avr-casesi (as dumped with
-fdump-rtl-avr-casesi) like wrong RTL-sharing or such, or

3) cfgrtl's assertion is too strict and effectively disallows such
target-specific (optimization) passes.

I don't currently have time to look into this in a timely manner.

[Bug tree-optimization/110502] New: [14 Regression] Dead Code Elimination Regression at -Os since r14-1656-g55fcaa9a8bd

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

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

Bug ID: 110502
   Summary: [14 Regression] Dead Code Elimination Regression at
-Os since r14-1656-g55fcaa9a8bd
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: theodort at inf dot ethz.ch
  Target Milestone: ---

https://godbolt.org/z/T9rv1nsGr

Given the following code:

void foo(void);
static char e = -3L, k;
static int f;
static int *g;
static signed char *h = 
static signed char **i = 
static unsigned j;
static char(a)(char b, char c) { return b + c; }
static int(d)(int b, int c) { return b && b < -c ? b : b + c; }
static char l(char *n, unsigned short o) {
char p;
int q, s = 4104765887;
int *r = 
if (!(((o) >= 65533) && ((o) <= 65533))) {
__builtin_unreachable();
}
for (; s <= 4; s = a(s, 5)) {
int **t = 
*t = 
j++;
p = *n;
q = d(*g, p);
*r = q;
}
if (g || f)
;
else
foo();
return 0;
}
int main() {
l(, e);
char m =  == (*i = );
}

gcc-trunk -Os does not eliminate the call to foo:

main:
pushq   %rbx
movl$-190201409, %edx
xorl%esi, %esi
subq$16, %rsp
movlj(%rip), %ecx
movl$-190201409, 12(%rsp)
leal15(%rcx), %r8d
.L2:
leal1(%rcx), %edi
cmpl%r8d, %edi
je  .L8
testl   %edx, %edx
movb$1, %sil
sete%al
cmpl$2, %edx
setg%cl
orl %ecx, %eax
movl%edi, %ecx
movzbl  %al, %eax
negl%eax
andl$-3, %eax
addl%edx, %eax
addl$5, %edx
movsbl  %dl, %edx
jmp .L2
.L8:
testb   %sil, %sil
leaq12(%rsp), %rbx
je  .L4
movq%rbx, g(%rip)
movl%ecx, j(%rip)
movl%eax, f(%rip)
jmp .L5
.L4:
cmpq$0, g(%rip)
jne .L5
cmpl$0, f(%rip)
jne .L5
callfoo
.L5:
movq%rbx, h(%rip)
addq$16, %rsp
xorl%eax, %eax
popq%rbx
ret

gcc-13.1.0 -Os eliminates the call to foo:

main:
movlj(%rip), %edx
movl$-190201409, %eax
leal14(%rdx), %esi
.L4:
testl   %eax, %eax
je  .L6
movl%eax, %ecx
cmpl$2, %eax
jle .L2
.L6:
leal-3(%rax), %ecx
.L2:
addl$5, %eax
incl%edx
movsbl  %al, %eax
cmpl%esi, %edx
jne .L4
leaq-4(%rsp), %rax
movl%ecx, f(%rip)
movq%rax, g(%rip)
movq%rax, h(%rip)
xorl%eax, %eax
movl%edx, j(%rip)
ret

Bisects to r14-1656-g55fcaa9a8bd

[Bug tree-optimization/103680] Jump threading and switch corrupts profile

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

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

--- Comment #11 from Jan Hubicka  ---
The following are passes affecting mismatches for tramp3d -O3 build:
107t cunrolli  | 85   +77  
110t forwprop  | 87+2  
113t fre   |151   +64 
115t threadfull|474  +323 
116t vrp   |379   -95 
127t ch|   3106 +2729
130t thread|   3166   +60
131t dom   |   3036  -130
159t cddce |   3146  +109
195t fre   |   1232   +10
196t thread|   1259   +27
197t dom   |   1249   -10
199t threadfull|   1275   +26
200t vrp   |   1264   -11
211t cddce |   1264   +14
264r cprop |   1174   +13
275r loop2_unroll  |   1180+8
312r pro_and_epilogue  |   1204   +21
315r jump2 |   1245   +41

So jump threading still produces mismatches, but I will need to look more if
these are really conflicting profiles or another updating bug.
Not sure what happens in ch.

[Bug tree-optimization/103680] Jump threading and switch corrupts profile

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

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

--- Comment #10 from Jan Hubicka  ---
I am testing:
diff --git a/gcc/cfg.cc b/gcc/cfg.cc
index 897ef534ff5..defdf679f7b 100644
--- a/gcc/cfg.cc
+++ b/gcc/cfg.cc
@@ -922,7 +922,6 @@ update_bb_profile_for_threading (basic_block bb,
fprintf (dump_file, "bb %i count became negative after threading",
 bb->index);
 }
-  bb->count -= count;

   /* Compute the probability of TAKEN_EDGE being reached via threaded edge.
  Watch for overflows.  */
@@ -934,8 +933,8 @@ update_bb_profile_for_threading (basic_block bb,
 {
   if (dump_file)
{
- fprintf (dump_file, "Jump threading proved probability of edge "
-  "%i->%i too small (it is ",
+ fprintf (dump_file, "Jump threading proved that the probability of
edge "
+  "%i->%i was originally estimated too small (it is ",
   taken_edge->src->index, taken_edge->dest->index);
  taken_edge->probability.dump (dump_file);
  fprintf (dump_file, " should be ");
@@ -945,6 +944,8 @@ update_bb_profile_for_threading (basic_block bb,
   prob = taken_edge->probability.apply_scale (6, 8);
 }

+  bb->count -= count;
+
   /* Now rescale the probabilities.  */
   taken_edge->probability -= prob;
   prob = prob.invert ();

This fixes the trivial testcase in comment #9

[Bug tree-optimization/110501] Invalid use-after-free / realloc with a store/load happening

[cheyenne.wills at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Cheyenne Wills  ---
(In reply to Andrew Pinski from comment #3)
> Oh GCC warns even with optimizations turned on ...

Correct.  For gcc-12 the failure only occurs with -O0.  With gcc-13 (and
later), the problem occurs with or without optimization.

[Bug tree-optimization/110501] Invalid use-after-free / realloc with a store/load happening

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

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

--- Comment #3 from Andrew Pinski  ---
Oh GCC warns even with optimizations turned on ...

[Bug tree-optimization/110501] Invalid use-after-free / realloc at -O0

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Invalid use-after-free /|Invalid use-after-free /
   |realloc |realloc at -O0

--- Comment #2 from Andrew Pinski  ---
At -O0, the redundant load from S->sp is not optimized out ... so the warning
does not realize that it was checking against the return value of realloc ...

[Bug jit/110466] jit.dg FAILs on ppc64le

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

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

--- Comment #9 from David Malcolm  ---
Should be fixed on trunk for gcc 14 by the above commits.

Keeping open to track backporting to gcc 13.

[Bug bootstrap/110467] Bootstrap with Ada enabled fails with --enable-host-pie

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

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

--- Comment #4 from Eric Botcazou  ---
> You were CC'd here:
> , FWIW.

I totally missed it, sorry about that. :-(

[Bug libstdc++/110432] macOS: Segmentation fault when using stdlibc++ from gcc 13.1 in combination with clang-16

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #14 from Jakub Jelinek  ---
The above change hasn't been backported to 13 branch yet.
13.2 release is tentatively planned for July 27th.

[Bug jit/110466] jit.dg FAILs on ppc64le

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

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

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

https://gcc.gnu.org/g:6735d66083953315c0d7d491df07d36061093a24

commit r14--g6735d66083953315c0d7d491df07d36061093a24
Author: David Malcolm 
Date:   Fri Jun 30 11:20:02 2023 -0400

jit: avoid using __vector in testcase [PR110466]

r13-4531-gd2e782cb99c311 added test coverage to libgccjit's vector
support, but used __vector, which doesn't work on Power.  Additionally
the size param to gcc_jit_type_get_vector was wrong.

Fixed thusly.

gcc/testsuite/ChangeLog:
PR jit/110466
* jit.dg/test-expressions.c (run_test_of_comparison): Fix size
param to gcc_jit_type_get_vector.
(verify_comparisons): Use a typedef rather than __vector.

Co-authored-by: Marek Polacek 
Signed-off-by: David Malcolm 

[Bug jit/110466] jit.dg FAILs on ppc64le

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

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

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

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

commit r14-2223-gc3c0ba5436170e01499f4390b7b628a32943a9e2
Author: David Malcolm 
Date:   Fri Jun 30 11:20:02 2023 -0400

jit.exp: handle dwarf version mismatch in jit-check-debug-info [PR110466]

gcc/testsuite/ChangeLog:
PR jit/110466
* jit.dg/jit.exp (jit-check-debug-info): Gracefully handle too
early versions of gdb that don't support our dwarf version, via
"unsupported".

Signed-off-by: David Malcolm 

[Bug libstdc++/110432] macOS: Segmentation fault when using stdlibc++ from gcc 13.1 in combination with clang-16

[sascha.scandella at dentsplysirona dot com via Gcc-bugs]

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

--- Comment #13 from Sascha Scandella  ---
Awesome. Thanks a lot for the provided solution! Nice!

Is already known when approximately GCC 13.2 will be released?

Have a great weekend!

[Bug analyzer/110501] Invalid use-after-free / realloc

[cheyenne.wills at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Cheyenne Wills  ---
Created attachment 55434
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55434=edit
stdout/stderr from compile

[Bug analyzer/110501] New: Invalid use-after-free / realloc

[cheyenne.wills at gmail dot com via Gcc-bugs]

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

Bug ID: 110501
   Summary: Invalid use-after-free / realloc
   Product: gcc
   Version: 12.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: cheyenne.wills at gmail dot com
  Target Milestone: ---

Created attachment 55433
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55433=edit
testcase.i

I've ran into a problem where gcc-12 (and later versions) is producing a false
positive on a use-after-free following a realloc.

The attached information obtained from a current gentoo system using gcc
(Gentoo 12.3.1_p20230526 p2) 12.3.1 20230526) 

gcc -v -save-temps -Wall -c testcase.c &> testcase.log


I've been able to duplicate the problem on godbolt.org using different versions
of gcc from gcc 12.1 through gcc master (I also tried various architectures,
x86_64, arm, etc.). godbolt's gcc 11 does work as expected.

The gist of the problem is:
---
 S->sp = realloc(p, size * 2);
 if (S->sp == NULL && size != 0) {
 free(p);/* << is flagged as a use after free */
 return 0;
 }
---
However the following works:
---
 char *t;
 t = realloc(p, size * 2);
 if (t == NULL && size != 0) {
 free(p);   /* << is not flagged as a use after free */
 return 0;
 }
 S->sp = t;
---

The provided testcase contains 3 simple functions.  The function fail1 and
fail2  has code that shows the invalid use-after-free, while the function
succeeds has code that does not produce the use-after-free message.  The only
difference between the failed functions and the success that the success
function uses a stack based temporary variable to hold the result of the
realloc.


==
$ $ gcc -Wall -Wextra  -c testcase.c 
testcase.c: In function ‘fail1’:
testcase.c:10:9: warning: pointer ‘p’ may be used after ‘realloc’
[-Wuse-after-free]
   10 | free(p); /* Is flagged as a use after free */
  | ^~~
testcase.c:8:13: note: call to ‘realloc’ here
8 | S->sp = realloc(p, size*2);
  | ^~
testcase.c: In function ‘fail2’:
testcase.c:20:9: warning: pointer ‘p’ may be used after ‘realloc’
[-Wuse-after-free]
   20 | free(p); /* Is flagged as a use after free */
  | ^~~
testcase.c:18:9: note: call to ‘realloc’ here
   18 | t = realloc(p, size*2);
  | ^~
$

==

The problem was originally discovered while building from openafs's master
branch (www.openafs.org) with a gcc-13 compiler. 

  src/external/heimdal/krb5/crypto.c:1157:9: error: pointer ‘p’ may be
  used after ‘realloc’ [-Werror=use-after-free]
   1157 | free(p);
| ^~~
  src/external/heimdal/krb5/crypto.c:1155:20: note: call to ‘realloc’
  here
   1155 | result->data = realloc(p, sz);
|^~

The failing code is part of an "external library" from the heimdal project.

[Bug libstdc++/110077] [14 regression] libstdc++-abi/abi_check FAILs on Solaris

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

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

--- Comment #14 from Jonathan Wakely  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #13)
> That would mean an implementation of C23 Annex H, right?  IIUC,
> implementing that is optional.

Right (on both counts).

> However, I can reach out to determine if there are any plans for that.

Thanks, that would be useful.

[Bug analyzer/105948] RFE: analyzer could check c++ placement-new sizes

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

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

--- Comment #1 from Benjamin Priour  ---
I'm writing a patch for this, and I've got support for non symbolic bounds.
However, as I wrote my patch, a missing warning came up.
Consider the test case:

---

void var_too_short ()
{
  short s;
  long *lp = new () long; /* { dg-warning "stack-based buffer overflow" } */
  /* { dg-warning "allocated buffer size is not a multiple of the pointee's
size" "" { target *-*-* } .-1 } */
}

void static_buffer_too_short ()
{
  int n = 16;
  int buf[n];
  int *p = new (buf) int[n + 1]; /* { dg-warning "stack-based buffer overflow"
} */
  /* (+) */
}

---

In 'var_too_short', two warnings are emitted, second being from
'-Wanalyzer-allocation-size', which makes sense.

Then given the name of this warning, would it not also makes sense to emit it
at (+) in 'static_buffer_too_short' ?

Pointer 'p' is an int, and 'buf' is an array of int, so the buffer size is
indeed a multiple size of 'p'.

However, we know 'p' points to an area actually overflowing 'buf', so
-Wanalyzer-allocation-size is reasonable there.

What are your thoughts on that ?

[Bug libstdc++/110432] macOS: Segmentation fault when using stdlibc++ from gcc 13.1 in combination with clang-16

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

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r14-2221-gfe2651affa8c15624188bfd062fb894648743431
Author: Jonathan Wakely 
Date:   Fri Jun 30 11:07:35 2023 +0100

libstdc++: Fix iostream init for Clang on darwin [PR110432]

The __has_attribute(init_priority) check in  is true for Clang
on darwin, which means that user code including  thinks the
library will initialize the global streams. However, when libstdc++ is
built by GCC on darwin, the __has_attribute(init_priority) check is
false, which means that the library thinks that user code will do the
initialization when  is included. This means that the
initialization is never done.

Add an autoconf check so that the header and the library both make their
decision based on the static properties of GCC at build time, with a
consistent outcome.

As a belt and braces check, also do the initialization in  if
the compiler including that header doesn't support the attribute (even
if the library also containers the initialization). This might result in
redundant initialization done in , but ensures the
initialization happens somewhere if there's any doubt about the
attribute working correctly due to missing linker support.

libstdc++-v3/ChangeLog:

PR libstdc++/110432
* acinclude.m4 (GLIBCXX_CHECK_INIT_PRIORITY): New.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Use GLIBCXX_CHECK_INIT_PRIORITY.
* include/std/iostream: Use new autoconf macro as well as
__has_attribute.
* src/c++98/ios_base_init.h: Use new autoconf macro instead of
__has_attribute.

Reviewed-by: Patrick Palka 

[Bug middle-end/109849] suboptimal code for vector walking loop

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

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

--- Comment #20 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

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

commit r14-2219-geab57b825bcc350e9ff44eb2fa739a80199d9bb1
Author: Jan Hubicka 
Date:   Fri Jun 30 16:27:27 2023 +0200

Fix handling of __builtin_expect_with_probability and improve first-match
heuristics

While looking into the std::vector _M_realloc_insert codegen I noticed that
call of __throw_bad_alloc is predicted with 10% probability. This is
because
the conditional guarding it has __builtin_expect (cond, 0) on it.  This
incorrectly takes precedence over more reliable heuristics predicting that
call
to cold noreturn is likely not going to happen.

So I reordered the predictors so __builtin_expect_with_probability comes
first
after predictors that never makes a mistake (so user can use it to always
specify the outcome by hand).  I also downgraded malloc predictor since I
do
think user-defined malloc functions & new operators may behave funny ways
and
moved usual __builtin_expect after the noreturn cold predictor.

This triggered latent bug in expr_expected_value_1 where

  if (*predictor < predictor2)
*predictor = predictor2;

should be:

  if (predictor2 < *predictor)
*predictor = predictor2;

which eventually triggered an ICE on combining heuristics.  This made me
notice
that we can do slightly better while combining expected values in case only
one of the parameters (such as in a*b when we expect a==0) can determine
overall result.

Note that the new code may pick weaker heuristics in case that both values
are
predicted.  Not sure if this scenario is worth the extra CPU time: there is
not correct way to combine the probabilities anyway since we do not know if
the predictions are independent, so I think users should not rely on it.

Fixing this issue uncovered another problem.  In 2018 Martin Liska added
code predicting that MALLOC returns non-NULL but instead of that he
predicts
that it returns true (boolean 1).  This sort of works for testcase testing
 malloc (10) != NULL
but, for example, we will predict
 malloc (10) == malloc (10)
as true, which is not right and such comparsion may happen in real code

I think proper way is to update expr_expected_value_1 to work with value
ranges, but that needs greater surgery so I decided to postpone this and
only add FIXME and fill PR110499.

gcc/ChangeLog:

PR middle-end/109849
* predict.cc (estimate_bb_frequencies): Turn to static function.
(expr_expected_value_1): Fix handling of binary expressions with
predicted values.
* predict.def (PRED_MALLOC_NONNULL): Move later in the priority
queue.
(PRED_BUILTIN_EXPECT_WITH_PROBABILITY): Move to almost top of the
priority
queue.
* predict.h (estimate_bb_frequencies): No longer declare it.

gcc/testsuite/ChangeLog:

PR middle-end/109849
* gcc.dg/predict-18.c: Improve testcase.

[Bug testsuite/108835] gm2 tests at large -jNN numbers do not return

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

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

commit r14-2218-gef4ea6e08707d27674a8c5ddb4b478aac8713c03
Author: Iain Sandoe 
Date:   Sat Feb 25 23:18:13 2023 +

modula-2: Amend the handling of failed select() calls in RTint [PR108835].

When we make a select() that fails, there is an attempt to (a) diagnose
why and (b) make a fallback.  These actions are causing some tests to
hang on some Darwin versions, this is because the first action that is
tried to assist in diagnosis/fallback handling is to replace the set
timeout with NIL (which causes select to wait forever, modulo other
reasons it might complete).

To fix this, call select with a zero timeout when checking for error
conditions.  Also, as we check the possible failure conditions, if we
find a change that succeeds, then stop looking for errors.

Signed-off-by: Iain Sandoe 

PR testsuite/108835

gcc/m2/ChangeLog:

* gm2-libs/RTint.mod: Do not use NIL timeout setting on select,
test failures sequentially, finishing on the first success.

[Bug c++/55004] [meta-bug] constexpr issues

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

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

Bug 92181 Summary: initializer_list & string_view result in "modification of 
'' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92181

   What|Removed |Added

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

[Bug c++/92181] initializer_list & string_view result in "modification of '' is not a constant expression

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
 Status|NEW |RESOLVED
   Target Milestone|--- |12.3
 Depends on||107079
 Resolution|--- |FIXED

--- Comment #5 from Patrick Palka  ---
Looks like this is fixed for GCC 12.3+ by the fix for PR107079.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107079
[Bug 107079] [10/11 Regression] ICE initializing lifetime-extended constexpr
variable that stores its this pointer

[Bug libstdc++/105081] Make std::random_device throw std::system_error

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r14-2217-gd6a6a4ea086d6af97bd7fbd482f51df41c265b79
Author: Jonathan Wakely 
Date:   Fri Jun 30 14:37:59 2023 +0100

libstdc++: Make std::random_device throw more std::system_error [PR105081]

In r14-289-gf9412cedd6c0e7 I made the std::random_device constructor
throw std::system_error for unrecognized tokens. But it still throws
std::runtime_error for a token such as "rdseed" that is recognized but
not supported at runtime by the CPU the program is running on.

With this change we throw std::system_error for those cases too. This
fixes the following failures on Intel CPUs withour rdseed support:

FAIL: 26_numerics/random/random_device/94087.cc execution test
FAIL: 26_numerics/random/random_device/cons/token.cc execution test
FAIL: 26_numerics/random/random_device/entropy.cc execution test

libstdc++-v3/ChangeLog:

PR libstdc++/105081
* src/c++11/random.cc (random_device::_M_init): Throw
std::system_error when the requested device is a valid token but
not available at runtime.

[Bug c/110500] New: gcc: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in c_parser_omp_clause_allocate

[141242068 at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 110500
   Summary: gcc: internal compiler error: tree check: expected
class 'type', have 'exceptional' (error_mark) in
c_parser_omp_clause_allocate
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 141242068 at smail dot nju.edu.cn
  Target Milestone: ---

The program:
```
$ cat small.c
int f, l, ll, r;

void foo(int i1, int i2, int p, int s, int nth, int *q, int ntm) {
#pragma omp distribute parallel for simd \
private (p) firstprivate (f) collapse(1) dist_schedule(static, 16) \
if (parallel: i2) if(simd: i1) default(shared) shared(s) reduction(+:r)
num_threads (nth) proc_bind(spread) \
lastprivate (l) schedule(static, 4) nontemporal(ntm) \
safelen(8) simdlen(4) aligned(q: 32) order(concurrent) allocate
(omp_default_mem_alloc:f)
  for (int i = 0; i < 64; i++)
ll++;
}
```

When compile it using gcc-14 with option `-fopenmp-simd -O0`, gcc reports
internal compiler errors as below:
```
: In function 'foo':
:8:70: error: 'omp_default_mem_alloc' undeclared (first use in this
function)
8 | safelen(8) simdlen(4) aligned(q: 32) order(concurrent) allocate
(omp_default_mem_alloc:f)
  | 
^
:8:70: note: each undeclared identifier is reported only once for each
function it appears in
:4:9: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in c_parser_omp_clause_allocate, at
c/c-parser.cc:16332
4 | #pragma omp distribute parallel for simd \
  | ^~~
0x213097e internal_error(char const*, ...)
???:0
0x8947e8 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
???:0
0xa7029d c_parse_file()
???:0
0xadf919 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

This behavior can be verified by visiting the CompilerExplorer:
https://gcc.godbolt.org/z/73436b54M

[Bug tree-optimization/110381] [11/12/13 Regression] double counting for sum of structs of floating point types

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

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

--- Comment #15 from Christophe Lyon  ---
(In reply to Richard Biener from comment #14)
> (In reply to Christophe Lyon from comment #12)
> > The new testcase (gcc.dg/vect/pr110381.c) fails:
> > FAIL: gcc.dg/vect/pr110381.c -flto -ffat-lto-objects execution test
> > FAIL: gcc.dg/vect/pr110381.c execution test
> > 
> > on arm-linux-gnueabihf configured with --with-float=hard
> > --with-fpu=neon-fp-armv8 --with-mode=thumb --with-arch=armv8-a
> 
> Can you check if it works now?  I've added a missing check_vect () call in
> case the harness passes in command-line options that your HW doesn't
> support.  Otherwise I'd appreciate command-line options to reproduce.

I still fails (check_vect() passes on my config, so there's no change).

Here is what sum_8_foos looks like:
sum_8_foos:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
vmov.i64d0, #0  @ float
add r3, r0, #192
.L10:
vldr.64 d16, [r0, #8]
addsr0, r0, #24
vldr.64 d18, [r0, #-24]
vldr.64 d17, [r0, #-8]
cmp r3, r0
vadd.f64d16, d16, d18
vadd.f64d16, d16, d17
vadd.f64d0, d0, d16
bne .L10
bx  lr

so we load:
d16=5
d17=-__DBL_MAX__
d18=__DBL_MAX__
the first addition makes d16=__DBL_MAX__
and the second one makes d16=0


> I cannot get anything to vectorize with a cc1 cross using
> 
> > ./cc1 -quiet t.c -O2 -ftree-vectorize -fno-vect-cost-model -fopt-info-vec 
> > -I include tri
> 
> but I have a cross configured with --with-float=hard --with-cpu=cortex-a9
> --with-fpu=neon-fp16

Not sure what happens. I tried my native compiler with the above flags, I get
the same code.
I tried to build my native compiler with the same flags, same code too.

> 
> I hope the FPU is compliant enough to compute __DBL_MAX__ + -__DBL_MAX__ +
> 5. to 5.

[Bug c++/102921] error: modification of '' is not a constant expression

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Keywords||rejects-valid
 CC||ppalka at gcc dot gnu.org
   Target Milestone|--- |12.3

--- Comment #4 from Patrick Palka  ---
Looks like this is fixed for GCC 12.3+ by the fix for PR107079

[Bug fortran/104630] module subroutine not accessible from submodule

[daryl.00179 at gmail dot com via Gcc-bugs]

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

Pablo  changed:

   What|Removed |Added

 CC||daryl.00179 at gmail dot com

--- Comment #3 from Pablo  ---
This issue is still present in v13.1.0. And it has also been reported in bug
#88632.

[Bug c++/107079] [10/11 Regression] ICE initializing lifetime-extended constexpr variable that stores its this pointer

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
   Target Milestone|10.5|12.3

[Bug fortran/88632] [F08] function contained in module invisible to submodule unless declared public

[daryl.00179 at gmail dot com via Gcc-bugs]

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

Pablo  changed:

   What|Removed |Added

 CC||daryl.00179 at gmail dot com

--- Comment #4 from Pablo  ---
This issue is still present in v13.1.0. And it has been also reported in bug
#104630.

[Bug libstdc++/110077] [14 regression] libstdc++-abi/abi_check FAILs on Solaris

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #10 from Jonathan Wakely  ---
> (In reply to Jonathan Wakely from comment #9)
>> One solution would be to just add the declaration to the header, and adjust
>> the exports so this new symbol is exported at GLIBCXX_3.4.32 not
>> GLIBCXX_3.4.31
>
> N.B. this is what we do for glibc-based linux targets. The symbol is present 
> in
> the library even when glibc doesn't provide strtof128. This means that we 
> don't
> have a different set of exported symbols when built on old or new glibc.
>
> If Solaris is ever going to get support for strtof128 and other _Float128
> support then that is probably what we should do here as well.

That would mean an implementation of C23 Annex H, right?  IIUC,
implementing that is optional.

However, I can reach out to determine if there are any plans for that.

[Bug tree-optimization/110499] New: malloc branch predictor is broken

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

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

Bug ID: 110499
   Summary: malloc branch predictor is broken
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

Malloc branch predictor currently predicts that malloc() call likely returns 1.
This is good for NULL pointer checks, but not good for checking pointers for
equality:

#include 
void
test()
{
 if (malloc(10) == malloc(20))
 printf ("Impossible!\n");
}

gets predicted as:

void test ()
{
  void * _1;
  void * _2;

   [local count: 1073741824]:
  _1 = malloc (10);
  _2 = malloc (20);
  if (_1 == _2)
goto ; [99.96%]
  else
goto ; [0.04%]

   [local count: 1073312329]:
  __builtin_puts (&"Impossible!"[0]);

   [local count: 1073741824]:
  return;

}

So we think that Impossible is output with 99.96 probability.

[Bug bootstrap/110467] Bootstrap with Ada enabled fails with --enable-host-pie

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

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

--- Comment #3 from Marek Polacek  ---
(In reply to Eric Botcazou from comment #2)
> Confirmed, but
> 
> Author: Marek Polacek 
> Date:   Wed May 3 17:06:13 2023 -0400
> 
> configure: Implement --enable-host-pie
> ada/
>  * gcc-interface/Make-lang.in (ALL_ADAFLAGS): Remove NO_PIE_CFLAGS.  Add
>  PICFLAG.  Use PICFLAG when building ada/b_gnat1.o and ada/b_gnatb.o.
>  * gcc-interface/Makefile.in: Use pic/libiberty.a if PICFLAG is set.
>  Remove NO_PIE_FLAG.
> 
> had first broken --enable-default-pie (and AFAICS was not approved by an Ada
> maintainer), so the aforementioned change restored the previous working
> state.

You were CC'd here:
, FWIW.

[Bug target/110478] RISC-V multilib gcc zicsr in the -march causing incorrect libgcc to be used

[bmeng.cn at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Bin Meng  ---
While I am figuring out the build failure, Palmer or Kito, are you able to
reproduce this libgcc bug with zicsr on the GCC HEAD?

[Bug c++/110497] Wrong error on non-static data member referenced in concept definition

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

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

Patrick Palka  changed:

   What|Removed |Added

 Blocks||67491
 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
It seems we're issuing a hard error during satisfaction here because
substitution failure didn't occur, and the substituted constraint is
non-constant which renders the program ill-formed as per
[temp.constr.atomic]/3:

> If substitution results in an invalid type or expression, the constraint is 
> not satisfied. Otherwise, the lvalue-to-rvalue conversion is performed if 
> necessary, and E shall be a constant expression of type bool.

One might argue substitution failure should occur for T::b with T=B, but this
seems to be permitted by [expr.prim.id.general]/3 since constraint-expressions
are unevaluated contexts.

Note that if we use B::b directly in the concept definition then Clang also
rejects the program due to non-constant satisfaction rule:

struct B { const bool b = true; };
template 
concept C = B::b;
static_assert( !C );

error: substitution into constraint expression resulted in a non-constant
expression

So GCC might be correct to reject the original program.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues