[Bug tree-optimization/110984] phiopt's spaceship_replacement should support cast and !=

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

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

--- Comment #2 from Andrew Pinski  ---
Note the main reason why this does not optimize down to `i <= j` without phiopt
on the trunk because of a few different reasons:
1) changing the return type to _Bool (or bool) allows us to get:
```
  _1 = i_2(D) < j_3(D);
  _4 = i_2(D) == j_3(D);
  _5 = _1 | _4;
```
2) Since that is not until phiopt4, there is no reassoc pass which does the
combining right now. We do handle integers just fine in match right now
(r14-2887-gac0e0966ebf08c and r14-2886-g0258b73680e21f). Adding real types to
match is on the plans to do too. (note also r14-1597-g64d90d06d2db43 was needed
to get the above IR).

Note this is all at `-O2 -ffast-math` so trapping and NaNs are not an issue.

[Bug tree-optimization/110984] phiopt's spaceship_replacement should support cast and !=

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2023-08-11
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=110982

--- Comment #1 from Andrew Pinski  ---
I have a patch already against phiopt.  Note PR 110982 is another way of fixing
this but that also needs to be fixed in VRP's simplify_casted_compare too.

[Bug tree-optimization/110984] New: phiopt's spaceship_replacement should support cast and !=

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

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

Bug ID: 110984
   Summary: phiopt's spaceship_replacement should support cast and
!=
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: pinskia at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Testcase:
```
int f5n (double i, double j)
{
signed char c;
if (i != j)
{
  if (i < j)
   c = 1;
 else
   c = -1;
}
else
   c = 0;
unsigned int t1 = c;
return t1 != (unsigned int)-1;
}
```

[Bug c/84510] C front-end does not utilise -Wuseless-cast

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Martin Uecker :

https://gcc.gnu.org/g:68783211f660a501dee203aec11dae99bf9808ba

commit r14-3139-g68783211f660a501dee203aec11dae99bf9808ba
Author: Martin Uecker 
Date:   Thu Aug 10 10:39:41 2023 +0200

c: Support for -Wuseless-cast [PR84510]

Add support for Wuseless-cast C (and ObjC).

PR c/84510

gcc/c/:
* c-typeck.cc (build_c_cast): Add warning.

gcc/c-family/:
* c.opt: Enable warning for C and ObjC.

gcc/:
* doc/invoke.texi: Update.

gcc/testsuite/:
* gcc.dg/Wuseless-cast.c: New test.

[Bug middle-end/110983] -fpatchable-function-entry is missing in Option Summary page

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-08-11
 Status|UNCONFIRMED |NEW
Version|unknown |14.0

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

I might take a look soonish on why.

[Bug web/110983] New: -fpatchable-function-entry is missing in Option Summary page

[sray at live dot com via Gcc-bugs]

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

Bug ID: 110983
   Summary: -fpatchable-function-entry is missing in Option
Summary page
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sray at live dot com
  Target Milestone: ---

In https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html, the
"-fpatchable-function-entry" is missing.

I managed to find it from the Option Index page. But I think it should also be
added to the summary page.

[Bug tree-optimization/110982] New: (unsigned)(signed_char) != (unsigned)-1 is never changed back into signed_char != -1

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

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

Bug ID: 110982
   Summary: (unsigned)(signed_char) != (unsigned)-1 is never
changed back into signed_char != -1
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

While looking into a failure after improving VRP, I see we never translate
this:
```
bool f(signed char t)
{
  unsigned int t1 = t;
  return t1 != (unsigned int)-1;
}
```
into:
```
bool f0(signed char t)
{
  return t != -1;
}
```

[Bug target/110792] [13/14 Regression] GCC 13 x86_32 miscompilation of Whirlpool hash function

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

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

--- Comment #15 from Sam James  ---
Roger, is this one ready to backport to releases/gcc-13 so we can pick it up
easily downstream via the branch snapshots, or do you want to let it bake on
trunk a bit longer? Cheers.

[Bug c++/110981] New: constexpr variable definition that requires dynamic destruction should be rejected

[de34 at live dot cn via Gcc-bugs]

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

Bug ID: 110981
   Summary: constexpr variable definition that requires dynamic
destruction should be rejected
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: de34 at live dot cn
  Target Milestone: ---

The following program is accepted by GCC and results in dynamic destruction
codes (because the lifetime-extended unique_ptr temporary object is not
trivially destructible and has no constant destruction)
(https://godbolt.org/z/8e9Y9E9jf):
```
#include 

constexpr std::unique_ptr&& r = {};

int main()
{
r = std::make_unique(42);
}
```

I think we should reject the definition of r due to CWG2529
(https://cplusplus.github.io/CWG/issues/2529.html).

Also, a slightly different example is also currently accepted by GCC
(https://godbolt.org/z/1rf768aKs):

```
#include 

struct S {
std::unique_ptr&& r;
};

constexpr S s{{}};

int main()
{
s.r = std::make_unique(42);
}
```

This seemly also needs to be rejected, although there's an open CWG issue
(https://cplusplus.github.io/CWG/issues/2702.html).

The rationale should be that
- every lifetime-extended temporary object created in the initialization of a
constexpr variable needs to have constant destruction, and
- such a non-const temporary object is not usable in constant expressions, so
lvalue-to-rvalue conversion from any of its subobjects makes the destruction
non-constant.

[Bug c++/110980] New: -flang-info-include-translate does not work with no argument

[namniav at gmail dot com via Gcc-bugs]

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

Bug ID: 110980
   Summary: -flang-info-include-translate does not work with no
argument
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: namniav at gmail dot com
  Target Milestone: ---

Docs says that with no argument -flang-info-include-translate will note all
include translation. (Docs link:
https://gcc.gnu.org/onlinedocs/gcc/gcc-command-options/c%2B%2B-modules.html)

However, it doesn't work with no argument: there is no note for translating
#include  to import when using -flang-info-include-translate. It does
note when using -flang-info-include-translate=.

$ cat mapper-file
/opt/homebrew/Cellar/gcc/13.1.0/include/c++/13/string string.gcm

$ cat test.cpp
#include 

$ g++ -std=c++20 -fmodules-ts -xc++-system-header -fmodule-mapper=mapper-file
string

$ g++ -std=c++20 -fmodules-ts -fmodule-mapper=mapper-file
-flang-info-include-translate -flang-info-module-cmi -E test.cpp -o test.cpp.E
In module imported at test.cpp:1:1:
/opt/homebrew/Cellar/gcc/13.1.0/include/c++/13/string: note: reading CMI
'string.gcm'

$ g++ -std=c++20 -fmodules-ts -fmodule-mapper=mapper-file
-flang-info-include-translate="" -flang-info-module-cmi -E test.cpp -o
test.cpp.E
test.cpp:1:10: note: include
'/opt/homebrew/Cellar/gcc/13.1.0/include/c++/13/string' translated to import
1 | #include 
  |  ^~~~
In module imported at test.cpp:1:1:
/opt/homebrew/Cellar/gcc/13.1.0/include/c++/13/string: note: reading CMI
'string.gcm'

[Bug target/110979] New: Miss-optimization for O2 fully masked loop on floating point reduction.

[crazylht at gmail dot com via Gcc-bugs]

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

Bug ID: 110979
   Summary: Miss-optimization for O2 fully masked loop on floating
point reduction.
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/YsaesW8zT

float
foo3 (float* __restrict a, int n)
{
float sum = 0.0f;
for (int i = 0; i != 100; i++)
  sum += a[i];
return sum;
}

-O2 -march=znver4 --param vect-partial-vector-usage=2, we get

   [local count: 66437776]:
  # sum_13 = PHI 
  # loop_mask_16 = PHI <_54(3), { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1, -1, -1 }(2)>
  # ivtmp.13_12 = PHI 
  # ivtmp.16_2 = PHI 
  # DEBUG i => NULL
  # DEBUG sum => NULL
  # DEBUG BEGIN_STMT
  _4 = (void *) ivtmp.13_12;
  _11 =   [(float *)_4];
  vect__4.6_17 = .MASK_LOAD (_11, 32B, loop_mask_16);
  cond_18 = .VCOND_MASK (loop_mask_16, vect__4.6_17, { 0.0, 0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0 });
  stmp_sum_10.7_19 = BIT_FIELD_REF ;
  stmp_sum_10.7_20 = sum_13 + stmp_sum_10.7_19;
  stmp_sum_10.7_21 = BIT_FIELD_REF ;
  stmp_sum_10.7_22 = stmp_sum_10.7_20 + stmp_sum_10.7_21;
  stmp_sum_10.7_23 = BIT_FIELD_REF ;
  stmp_sum_10.7_24 = stmp_sum_10.7_22 + stmp_sum_10.7_23;
  stmp_sum_10.7_25 = BIT_FIELD_REF ;
  stmp_sum_10.7_26 = stmp_sum_10.7_24 + stmp_sum_10.7_25;
  stmp_sum_10.7_27 = BIT_FIELD_REF ;
  stmp_sum_10.7_28 = stmp_sum_10.7_26 + stmp_sum_10.7_27;
  stmp_sum_10.7_29 = BIT_FIELD_REF ;
  stmp_sum_10.7_30 = stmp_sum_10.7_28 + stmp_sum_10.7_29;
  stmp_sum_10.7_31 = BIT_FIELD_REF ;
  stmp_sum_10.7_32 = stmp_sum_10.7_30 + stmp_sum_10.7_31;
  stmp_sum_10.7_33 = BIT_FIELD_REF ;
  stmp_sum_10.7_34 = stmp_sum_10.7_32 + stmp_sum_10.7_33;
  stmp_sum_10.7_35 = BIT_FIELD_REF ;
  stmp_sum_10.7_36 = stmp_sum_10.7_34 + stmp_sum_10.7_35;
  stmp_sum_10.7_37 = BIT_FIELD_REF ;
  stmp_sum_10.7_38 = stmp_sum_10.7_36 + stmp_sum_10.7_37;
  stmp_sum_10.7_39 = BIT_FIELD_REF ;
  stmp_sum_10.7_40 = stmp_sum_10.7_38 + stmp_sum_10.7_39;
  stmp_sum_10.7_41 = BIT_FIELD_REF ;
  stmp_sum_10.7_42 = stmp_sum_10.7_40 + stmp_sum_10.7_41;
  stmp_sum_10.7_43 = BIT_FIELD_REF ;
  stmp_sum_10.7_44 = stmp_sum_10.7_42 + stmp_sum_10.7_43;
  stmp_sum_10.7_45 = BIT_FIELD_REF ;
  stmp_sum_10.7_46 = stmp_sum_10.7_44 + stmp_sum_10.7_45;
  stmp_sum_10.7_47 = BIT_FIELD_REF ;
  stmp_sum_10.7_48 = stmp_sum_10.7_46 + stmp_sum_10.7_47;
  stmp_sum_10.7_49 = BIT_FIELD_REF ;
  sum_10 = stmp_sum_10.7_48 + stmp_sum_10.7_49;
  # DEBUG sum => sum_10
  # DEBUG BEGIN_STMT
  # DEBUG i => NULL
  # DEBUG sum => sum_10
  # DEBUG BEGIN_STMT
  _53 = {ivtmp.16_2, ivtmp.16_2, ivtmp.16_2, ivtmp.16_2, ivtmp.16_2,
ivtmp.16_2, ivtmp.16_2, ivtmp.16_2, ivtmp.16_2, ivtmp.16_2, ivtmp.16_2,
ivtmp.16_2, ivtmp.16_2, ivtmp.16_2, ivtmp.16_2, ivtmp.16_2};
  _54 = _53 > { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 };
  ivtmp.13_15 = ivtmp.13_12 + 64;
  ivtmp.16_3 = ivtmp.16_2 + 240;
  if (ivtmp.16_3 != 228)


Looks like an cost model issue?

For aarch64, it looks fine since they have FADDA(Floating-point add
strictly-ordered reduction, accumulating in scalar).

[Bug tree-optimization/109637] unnecessary range check in complete switch on bitfield

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Andrew Macleod from comment #2)
> 
> Why are we adding -1 to [0,3] ?  Thats the root of this issue I think? 
> seems strange

if we ignore the range for a second.

When switch conversion happens we have:
  switch (_1)  [INV], case 1:  [INV], case 2:  [INV],
case 3:  [INV]>

So when _1 is either 0 or > 3, default case will happen.

The real problem is switch conversion promotes to a 8 bit type when it does the
comparisons and does not take into the ranges.

Related testcase (ignoring that there is a bogus warning, see PR 95513 for that
and not fixed even with my VRP patch):
```
int f (unsigned t) {
switch(t & 0x3) {
case 0: return 0;
case 1: return 1;
case 2: return 2;
case 3: return 3;
}
}
```
my VRP patch also fixes the above. Now switch conversion should use the range
info too. I will look into adding that  But at least we get decent code for
the orginal and related cases now.

[Bug c++/105644] ICE in a fold expression with a requires expression: in iterative_hash_template_arg, at cp/pt.cc:1805

[namniav at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Namniav  ---
Now Clang also crashes on the original
example(https://github.com/llvm/llvm-project/issues/64607), although its cause
may be different to GCC's.

I can't remember why I used `get` instead of `std::get` in original code
because I didn't really know how ADL finds function templates. The issue still
exists with `std::get`.

Here is a modified and GCC-only reduced version:
https://godbolt.org/z/MMYMrGE3z

```c++
template
concept C = (sizeof(I) + sizeof(T) > 0);

template
constexpr bool check() {
return ((requires(T t) {
{ (I, t) } -> C;
}) && ...);
}

template
concept tuple_like = check();

static_assert(tuple_like);
```

Noted that GCC doesn't consider using `I` in `-> C` as using a parameter
pack, I have to use it in comma expression `(I, t)` to get a fold expression,
otherwise GCC complains "operand of fold expression has no unexpanded parameter
packs". I suspect that GCC has problem with such case. It some how explains,
for GCC only, why replacing `std::tuple_element_t&` with `int&` "fixes"
the issue.

[Bug tree-optimization/109637] unnecessary range check in complete switch on bitfield

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

For the simple example in comment #0, I have a patch.  This is the updating of
test_for_singularity patch.

For the GIMPLE_SWITCH issue in EVRP, I suspect the code in vr-values.c needs to
update and/or added to see if the default was taken or not.  I will handle this
too.

[Bug libstdc++/110968] format out of bounds read on format("{:05L}",-1.f)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed for 13.3, thanks again

[Bug libstdc++/110974] format out of bounds read on invalid format string "{:{}."

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
Fixed for 13.3, thanks again

[Bug libstdc++/110968] format out of bounds read on format("{:05L}",-1.f)

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:15b3fc6c1c5296662d0ffd7d3cfb8b669421e5ea

commit r13-7706-g15b3fc6c1c5296662d0ffd7d3cfb8b669421e5ea
Author: Jonathan Wakely 
Date:   Thu Aug 10 14:33:44 2023 +0100

libstdc++: Fix std::format for localized floats [PR110968]

The __formatter_fp::_M_localize function just returns an empty string if
the formatting locale is the C locale, as there is nothing to do. But
the caller was assuming that the returned string contains the localized
string. The caller should use the original string if _M_localize returns
an empty string.

libstdc++-v3/ChangeLog:

PR libstdc++/110968
* include/std/format (__formatter_fp::format): Check return
value of _M_localize.
* testsuite/std/format/functions/format.cc: Check classic
locale.

(cherry picked from commit f48a5423964f72e2e1ba0ad6a14d9d1464a78bed)

[Bug libstdc++/110974] format out of bounds read on invalid format string "{:{}."

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:

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

commit r13-7707-g6ac826917de970ebc789a5a1928d6d6987d85c0b
Author: Jonathan Wakely 
Date:   Thu Aug 10 23:15:29 2023 +0100

libstdc++: Fix out-of-bounds read in format string "{:{}." [PR110974]

libstdc++-v3/ChangeLog:

PR libstdc++/110974
* include/std/format (_Spec::_M_parse_precision): Check for
empty range before dereferencing iterator.
* testsuite/std/format/string.cc: Check for expected exception.
Fix expected exception message in test_pr110862() and actually
call it.

(cherry picked from commit ecfd8c7ffecf9e8f851c996ec149fbda7ef202f5)

[Bug rtl-optimization/66940] ifcvt.c:1907 signed integer overflow

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug c/107954] Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x

[romain.geissler at amadeus dot com via Gcc-bugs]

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

--- Comment #4 from Romain Geissler  ---
In the latest agenda published
(https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3156.pdf) it seems that now
the next C revision has been delayed a bit.

At this point, is it known already if it will be officially called C23 or C24 ?

[Bug c++/107687] [C++23] P2564 - consteval needs to propagate up

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
A (very) rudimentary patch that handles the simplest case so far:


>From be2950f8cf3fb5ca0571054b4196de35d9807519 Mon Sep 17 00:00:00 2001
From: Marek Polacek 
Date: Thu, 10 Aug 2023 17:06:11 -0400
Subject: [PATCH] c++: implement P2564, consteval needs to propagate up
 [PR107687]

---
 gcc/cp/call.cc   | 48 
 gcc/cp/cp-gimplify.cc| 26 +--
 gcc/testsuite/g++.dg/cpp23/consteval-if10.C  |  2 +-
 gcc/testsuite/g++.dg/cpp2a/consteval-prop1.C | 36 +++
 4 files changed, 108 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/consteval-prop1.C

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index 673ec91d60e..34b2fe1884d 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -9740,6 +9740,7 @@ build_trivial_dtor_call (tree instance, bool
no_ptr_deref)
 bool
 in_immediate_context ()
 {
+  // TODO update to say that manifestly constant eval ctx is an IFC
   return (cp_unevaluated_operand != 0
  || (current_function_decl != NULL_TREE
  && DECL_IMMEDIATE_FUNCTION_P (current_function_decl))
@@ -9762,6 +9763,34 @@ immediate_invocation_p (tree fn)
  && !in_immediate_context ());
 }

+/* Return true if FN is an immediate-escalating function.  */
+
+static bool
+immediate_escalating_function_p (tree fn)
+{
+  if (!fn)
+return false;
+
+  gcc_checking_assert (TREE_CODE (fn) == FUNCTION_DECL);
+
+  /* An immediate-escalating function is
+  -- the call operator of a lambda that is not declared with the consteval
+specifier  */
+  if (LAMBDA_FUNCTION_P (fn) && !DECL_IMMEDIATE_FUNCTION_P (fn))
+return true;
+  /* -- a defaulted special member function that is not declared with the
+   consteval specifier  */
+  special_function_kind sfk = special_memfn_p (fn);
+  if (sfk != sfk_none
+  && DECL_DEFAULTED_FN (fn)
+  && !DECL_IMMEDIATE_FUNCTION_P (fn))
+return true;
+  /* -- a function that results from the instantiation of a templated entity
+   defined with the constexpr specifier.  */
+  // TODO check if the DECL_DEFAULTED_FN part is actually OK here
+  return is_instantiation_of_constexpr (fn);
+}
+
 /* Subroutine of the various build_*_call functions.  Overload resolution
has chosen a winning candidate CAND; build up a CALL_EXPR accordingly.
ARGS is a TREE_LIST of the unconverted arguments to the call.  FLAGS is a
@@ -10484,6 +10513,7 @@ build_over_call (struct z_candidate *cand, int flags,
tsubst_flags_t complain)
   tree fndecl = STRIP_TEMPLATE (TREE_OPERAND (fn, 0));
   if (immediate_invocation_p (fndecl))
{
+ tree orig_call = call;
  tree obj_arg = NULL_TREE;
  /* Undo convert_from_reference called by build_cxx_call.  */
  if (REFERENCE_REF_P (call))
@@ -10508,6 +10538,24 @@ build_over_call (struct z_candidate *cand, int flags,
tsubst_flags_t complain)
obj_arg = TREE_OPERAND (addr, 0);
}
}
+
+ /* [expr.const]p16 "An expression or conversion is
+immediate-escalating if it is not initially in an immediate
+function context and it is either
+ -- an immediate invocation that is not a constant expression and
+ is not a subexpression of an immediate invocation."
+
+ If we are in an immediate-escalating function, the
+ immediate-escalating expression or conversion makes it an
+ immediate function.  So CALL does not need to produce a constant
+ expression.  ??? It's ugly to call cxx_constant_value twice in
+ some cases.  */
+ if (immediate_escalating_function_p (current_function_decl)
+ && cxx_constant_value (call, obj_arg, tf_none) ==
error_mark_node)
+   {
+ SET_DECL_IMMEDIATE_FUNCTION_P (current_function_decl);
+ return orig_call;
+   }
  call = cxx_constant_value (call, obj_arg, complain);
  if (obj_arg && !error_operand_p (call))
call = cp_build_init_expr (obj_arg, call);
diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc
index 206e791fcfd..5fc0e3cc84b 100644
--- a/gcc/cp/cp-gimplify.cc
+++ b/gcc/cp/cp-gimplify.cc
@@ -1017,6 +1017,20 @@ maybe_replace_decl (tree *tp, tree decl, tree
replacement)
   return true;
 }

+/* Maybe say that FN was initially not an immediate function, but was
+   promoted to one because its body contained an immediate-escalating
+   expression or conversion.  */
+
+static void
+maybe_explain_promoted_consteval (location_t loc, 

[Bug libstdc++/110974] format out of bounds read on invalid format string "{:{}."

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to CVS Commits from comment #3)
> * include/std/format (_Spec::_S_parse_width_or_precision): Check
> for empty range before dereferencing iterator.

Oops, I fixed it in _M_parse_precision instead, but forgot to change the commit
msg.

[Bug libstdc++/110974] format out of bounds read on invalid format string "{:{}."

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

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

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

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

commit r14-3136-gecfd8c7ffecf9e8f851c996ec149fbda7ef202f5
Author: Jonathan Wakely 
Date:   Thu Aug 10 23:15:29 2023 +0100

libstdc++: Fix out-of-bounds read in format string "{:{}." [PR110974]

libstdc++-v3/ChangeLog:

PR libstdc++/110974
* include/std/format (_Spec::_S_parse_width_or_precision): Check
for empty range before dereferencing iterator.
* testsuite/std/format/string.cc: Check for expected exception.
Fix expected exception message in test_pr110862() and actually
call it.

[Bug libstdc++/110968] format out of bounds read on format("{:05L}",-1.f)

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

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

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

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

commit r14-3135-gf48a5423964f72e2e1ba0ad6a14d9d1464a78bed
Author: Jonathan Wakely 
Date:   Thu Aug 10 14:33:44 2023 +0100

libstdc++: Fix std::format for localized floats [PR110968]

The __formatter_fp::_M_localize function just returns an empty string if
the formatting locale is the C locale, as there is nothing to do. But
the caller was assuming that the returned string contains the localized
string. The caller should use the original string if _M_localize returns
an empty string.

libstdc++-v3/ChangeLog:

PR libstdc++/110968
* include/std/format (__formatter_fp::format): Check return
value of _M_localize.
* testsuite/std/format/functions/format.cc: Check classic
locale.

[Bug libstdc++/110970] clang / c++23 missing 'typename' prior to dependent type name 'iterator_traits<_It>::iterator_category'

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

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

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

https://gcc.gnu.org/g:9cb2a7c8d54b1f6685bc509a07104c458262cb9f

commit r14-3134-g9cb2a7c8d54b1f6685bc509a07104c458262cb9f
Author: Jonathan Wakely 
Date:   Thu Aug 10 13:48:48 2023 +0100

libstdc++: Use alias template for iterator_category [PR110970]

This renames __iterator_category_t to __iter_category_t, for consistency
with std::iter_value_t, std::iter_difference_t and std::iter_reference_t
in C++20. Then use __iter_category_t in , which
fixes the problem of the missing 'typename' that Clang 15 incorrectly
still requires.

libstdc++-v3/ChangeLog:

PR libstdc++/110970
* include/bits/stl_iterator.h (__detail::__move_iter_cat): Use
__iter_category_t.
(iterator_traits>::_S_iter_cat): Likewise.
(__detail::__basic_const_iterator_iter_cat): Likewise.
* include/bits/stl_iterator_base_types.h (__iterator_category_t):
Rename to __iter_category_t.

[Bug tree-optimization/110923] [14 Regression] with-build-config=bootstrap-lto-lean and `make profile-bootstrap` ICEs during build during lsplit pass

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

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

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

https://gcc.gnu.org/g:39204ae9ddbfca710880d7f5fda48234a1e85e4e

commit r14-3133-g39204ae9ddbfca710880d7f5fda48234a1e85e4e
Author: Jan Hubicka 
Date:   Fri Aug 11 00:23:14 2023 +0200

Fix division by zero in loop splitting

Profile update I added to tree-ssa-loop-split can divide by zero in
situation that the conditional is predicted with 0 probability which
is triggered by jump threading update in the testcase.

gcc/ChangeLog:

PR middle-end/110923
* tree-ssa-loop-split.cc (split_loop): Watch for division by zero.

gcc/testsuite/ChangeLog:

PR middle-end/110923
* gcc.dg/tree-ssa/pr110923.c: New test.

[Bug tree-optimization/110131] [12/13/14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r12-6924-gc2b610e7c6c

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Andrew Macleod from comment #6)
> poking around for a minute, it looks like simplify_using_ranges from
> vr_values calls a routine called test_for_singularity which has never been
> converted to multi-ranges.  I wonder if reworking it might resolve this
> class of issues as well?  Eventually we planned to get to
> simplify_using-ranges and friends, but it hasnt happened yet

Yes that is actually better to change
simplify_compare_using_ranges_1/test_for_singularity use range_op_handler and
such. I have a new patch which does exactly that and it works .

[Bug libstdc++/110974] format out of bounds read on invalid format string "{:{}."

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-08-10
 Ever confirmed|0   |1
   Target Milestone|--- |13.3

--- Comment #2 from Jonathan Wakely  ---
This fixes it:

--- a/libstdc++-v3/include/std/format
+++ b/libstdc++-v3/include/std/format
@@ -465,6 +465,9 @@ namespace __format
  unsigned short& __val, bool& __arg_id,
  basic_format_parse_context<_CharT>& __pc)
   {
+   if (__first == __last)
+ return __first;
+
if (__format::__is_digit(*__first))
  {
auto [__v, __ptr] = __format::__parse_integer(__first, __last);

[Bug tree-optimization/110971] [14 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in operator/, at sreal.cc:261

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

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

--- Comment #1 from Jan Hubicka  ---
The problem here is that the split conditional is predicted with probability 0:

  if (b.0_1 > a.4_14)
goto ; [0.00%]
  else
goto ; [100.00%]

this is caused by jump threading;

   [local count: 118111600 freq: 1.00]:
  a = 0;
  goto ; [100.00%]

   [local count: 955630224 freq: 8.090909]:
  b.0_1 = b;
  if (b.0_1 > 2)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 477815112 freq: 4.045455]:
  c = 0;

   [local count: 955630224 freq: 8.090909]:
  if (b.0_1 > a.4_3)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 477815112 freq: 4.045455]:
  d = 0;

   [local count: 955630224 freq: 8.090909]:
  _2 = a.4_3 + 1;
  a = _2;

   [local count: 1073741824 freq: 9.090909]:
  a.4_3 = a;
  if (a.4_3 <= 1)
goto ; [89.00%]
  else
goto ; [11.00%]

So since b>2 implies a>2 we correctly thread but because both conditionals are
statically predicted with same probability we end up with probability 0.

   [local count: 118111600 freq: 1.00]:
  a = 0;
  goto ; [100.00%]

   [local count: 955630224 freq: 8.090909]:
  b.0_1 = b;
  if (b.0_1 > 2)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 477815112 freq: 4.045455]:
  c = 0;
  goto ; [100.00%]

   [local count: 477815112 freq: 4.045455]:
  if (b.0_1 > a.4_3)
goto ; [0.00%]
  else
goto ; [100.00%]

   [local count: 477815112 freq: 4.045455]:
  d = 0;

   [local count: 955630224 freq: 8.090909]:
  _2 = a.4_3 + 1;
  a = _2;

   [local count: 1073741824 freq: 9.090909]:
  a.4_3 = a;
  if (a.4_3 <= 1)
goto ; [89.00%]
  else
goto ; [11.00%]


Threading commonly causes such probabilities 0 which may be harmful.
Loop splitting then preconditions the loop:

   [local count: 118111600 freq: 1.00]:
  b.0_1 = b;
  if (b.0_1 > 0)
goto ; [0.00%]
  else
goto ; [100.00%]

That is bit of nonsence.  Since we expect loop to iterate and since we try to
keep it across preconditioning, we divide by 0.

[Bug libstdc++/106852] Implement C++23 P2465R3 Standard Library Modules std and std.compat

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://github.com/microsof
   ||t/STL/issues/3945

--- Comment #3 from Jonathan Wakely  ---
As per https://github.com/microsoft/STL/issues/3945 we should support the std
module in C++20 mode too.

[Bug c++/110978] ICE lambda constrained with to-be-deduced object

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-08-10

[Bug c++/110978] ICE lambda constrained with to-be-deduced object

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||12.3.0
Summary|[14 Regression] ICE lambda  |ICE lambda constrained with
   |constrained with|to-be-deduced object
   |to-be-deduced object|
   Keywords||error-recovery,
   ||ice-checking

--- Comment #1 from Andrew Pinski  ---
The ICE was there in GCC 12.3.0 also:
`confused by earlier errors, bailing out` is just covering up the ICE after an
error for releases.


Confirmed.

[Bug c/110976] Cryptic error message when incorrectly dereferencing a pointer in an anonymous union

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

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

--- Comment #1 from Andrew Pinski  ---
U here stands for unique as in UID. Yes it should not be exposed to the user.

[Bug bootstrap/103459] Make configury regenerate cleanly with `autoreconf -Wall`

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||arsen at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to Eric Gallager from comment #1)
> I've been working a bit on this in my autotools-tinkering branch in my
> userspace; it's nowhere near done yet, though... I'm also mirroring the
> branch on GitHub:
> https://github.com/cooljeanius/gcc/tree/me/autotools-tinkering
> I should probably also be opening some bugs against autoconf for some of the
> screw-ups I've noticed that autoupdate causes when running it on some of
> gcc's autoconfigury... (e.g. nested AC_TRY_COMPILEs leading to stray
> _au_m4_changequote([,])s when being upgraded to AC_COMPILE_IF_ELSE, macros
> in comments getting expanded, stuff inside AC_REQUIRE getting autoupdated
> even when that breaks the usage of AC_REQUIRE, config/multi.m4 getting
> broken due to something having to do with argument quoting,
> spacing/line-length getting ruined, etc.)

Some relevant upstream autoconf bugs related to some of the screw-ups I
mentioned:
https://savannah.gnu.org/support/?110886 (sr #110886: autoupdate produces
broken configure.ac)
https://savannah.gnu.org/support/?func=detailitem_id=110325 (sr #110325:
autoupdate introduces a second invocation of AC_OUTPUT)
https://savannah.gnu.org/support/?func=detailitem_id=110324 (sr #110324:
autoupdate does some nonsensical changes)

[Bug libstdc++/110653] Support std::stoi etc. without C99 APIs

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #23 from John David Anglin  ---
Fixed by last commit.

[Bug c++/110978] New: [14 Regression] ICE lambda constrained with to-be-deduced object

[johelegp at gmail dot com via Gcc-bugs]

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

Bug ID: 110978
   Summary: [14 Regression] ICE lambda constrained with
to-be-deduced object
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
  Target Milestone: ---

See .

```C++
int f(int);
int main() {
  auto f = [](auto obj) requires requires { f(obj); } { return f(obj); }(0);
}
```

```output
: In function 'int main()':
:3:45: error: use of 'f' before deduction of 'auto'
3 |   auto f = [](auto obj) requires requires { f(obj); } { return f(obj);
}(0);
  | ^
:3:12: error: constraints on a non-templated function
3 |   auto f = [](auto obj) requires requires { f(obj); } { return f(obj);
}(0);
  |^
:3:53: internal compiler error: in dependent_type_p, at cp/pt.cc:27895
3 |   auto f = [](auto obj) requires requires { f(obj); } { return f(obj);
}(0);
  | ^
0x24742fe internal_error(char const*, ...)
???:0
0xaca188 fancy_abort(char const*, int, char const*)
???:0
0xb8c067 start_preparsed_function(tree_node*, tree_node*, int)
???:0
0xbeaac9 start_lambda_function(tree_node*, tree_node*)
???:0
0xcb0974 c_parse_file()
???:0
0xdf1599 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.
Compiler returned: 1
```

[Bug tree-optimization/110923] [14 Regression] with-build-config=bootstrap-lto-lean and `make profile-bootstrap` ICEs during build during lsplit pass

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

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

--- Comment #1 from Andrew Pinski  ---
Note PR 110971 might contain a reduced testcase ...

[Bug tree-optimization/110971] [14 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in operator/, at sreal.cc:261

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE on valid code at -O3 on |[14 Regression] ICE on
   |x86_64-linux-gnu: in|valid code at -O3 on
   |operator/, at sreal.cc:261  |x86_64-linux-gnu: in
   ||operator/, at sreal.cc:261
   Target Milestone|--- |14.0

[Bug middle-end/110954] [14 Regression] Wrong code with -O0

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

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

--- Comment #5 from Andrew Pinski  ---
Created attachment 55718
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55718=edit
new patch which I am testing

The only thing is it is sometimes overly conserative with the check of
`!wascmp || element_precision (type) == 1` for vector types
but that is ok those were not handled before either anyways.

We do handle `a & ~a` and `a |^ ~a` for all cases (correctly) like we did
previously and before r14-2925-g2bae476b511dc441bf61da8a4 .

[Bug c++/110977] Should -fms-extensions define _MSC_EXTENSIONS?

[aaron at aaronballman dot com via Gcc-bugs]

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

--- Comment #2 from Aaron Ballman  ---
(In reply to Andrew Pinski from comment #1)
> I don't think GCC has all of MSVC extensions implemented so defining that
> might break code 

Clang doesn't either, FWIW. But the point is well-taken; code thinking this is
a feature testing macro that says we've implemented all MS extensions could be
tripped up. But not defining the macro means code guarding use of MS extensions
which are supported also gets tripped up, just in the opposite direction.

Microsoft adds new extensions with basically every significant release, so
we'll always be behind them in terms of implementation. Because of that, I
think treating _MSC_EXTENSIONS as meaning "the user enabled whatever MS
extensions we support" is a practical interpretation.

[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))

[ed at catmur dot uk via Gcc-bugs]

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

--- Comment #58 from Ed Catmur  ---
(In reply to Roman Krotov from comment #57)
> But I don't see any reasons not to implement the switch right now...
Making [[gnu::warn_unused_result]] mean the same as [[nodiscard]] would be a
reduction in expressivity.

> what about the projects
> what don't agree with the distinction of these 2 attributes? Or just want to
> be more compatible with clang?
They can use [[nodiscard]].

> Or they just may not agree with the choice of a library, that decided to put
> wur instead of nodiscard for a specific function.
Then they can write their own wrappers using [[nodiscard]].

[Bug c++/110977] Should -fms-extensions define _MSC_EXTENSIONS?

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |c++

--- Comment #1 from Andrew Pinski  ---
I don't think GCC has all of MSVC extensions implemented so defining that might
break code 

[Bug c/110976] Cryptic error message when incorrectly dereferencing a pointer in an anonymous union

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

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||diagnostic
 Ever confirmed|0   |1
   Last reconfirmed||2023-08-10
 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org

[Bug c/110977] New: Should -fms-extensions define _MSC_EXTENSIONS?

[aaron at aaronballman dot com via Gcc-bugs]

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

Bug ID: 110977
   Summary: Should -fms-extensions define _MSC_EXTENSIONS?
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aaron at aaronballman dot com
  Target Milestone: ---

This macro is predefined by MSVC when their extensions are enabled (/Ze in
cl.exe, on by default):
https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170

However, GCC does not define the macro when enabling Microsoft extensions. See
https://godbolt.org/z/MqKTz6ob7 for a reproducer.

Clang also does not define this macro when passing -fms-extensions, but we're
investigating defining the macro in this case
(https://reviews.llvm.org/D157334); if Clang goes that route, would GCC do the
same or are there reasons you're not defining this macro that we should be
aware of?

[Bug c/110976] New: Cryptic error message when incorrectly dereferencing a pointer in an anonymous union

[jesper.oqvist at gmail dot com via Gcc-bugs]

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

Bug ID: 110976
   Summary: Cryptic error message when incorrectly dereferencing a
pointer in an anonymous union
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jesper.oqvist at gmail dot com
  Target Milestone: ---

The following program gives me a cryptic error message when compiled with GCC
14 snapshot 20230806:

struct S { union { struct S* x; }; };
struct S* f(struct S s)
{
  return s.x.x;
}

Compiling this program with $HOME/opt/gcc-14/bin/gcc anon_union.c gives the
error message below:

anon_union.c: In function 'f':
anon_union.c:4:13: error: 's..x' is a pointer; did you mean to use '->'?
4 |   return s.x.x;
  | ^
  | ->

I presume the  part is how GCC names the anonymous union in struct S,
but it seems like this could be formatted a bit nicer to make the error message
easier to understand. Each time I re-run the compiler on the same program the
part in angle brackets changes to another 5-letter string starting with U.

Below is the gcc -v output:
$HOME/opt/gcc-14/bin/gcc -v anon_union.c 
Using built-in specs.
COLLECT_GCC=/home/jesper/opt/gcc-14/bin/gcc
COLLECT_LTO_WRAPPER=/home/jesper/opt/gcc-14/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-14-20230806/configure --prefix=/home/jesper/opt/gcc-14
--disable-nls --disable-werror --disable-bootstrap --enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230806 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
 /home/jesper/opt/gcc-14/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/cc1 -quiet -v
-imultiarch x86_64-linux-gnu anon_union.c -quiet -dumpdir a- -dumpbase
anon_union.c -dumpbase-ext .c -mtune=generic -march=x86-64 -version -o
/tmp/ccsUEV7J.s
GNU C17 (GCC) version 14.0.0 20230806 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 11.4.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/home/jesper/opt/gcc-14/lib/gcc/x86_64-pc-linux-gnu/14.0.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/jesper/opt/gcc-14/lib/gcc/x86_64-pc-linux-gnu/14.0.0/include
 /usr/local/include
 /home/jesper/opt/gcc-14/include

/home/jesper/opt/gcc-14/lib/gcc/x86_64-pc-linux-gnu/14.0.0/include-fixed/x86_64-linux-gnu
 /home/jesper/opt/gcc-14/lib/gcc/x86_64-pc-linux-gnu/14.0.0/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
Compiler executable checksum: 020a05d35e6345424c620c1d2d7de9eb

[Bug middle-end/110975] Missed unlooping

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

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #1 from Jan Hubicka  ---
Sorry, got the testcase wrong. Fixed one

int *a;
void
test (int n)
{
int i;
for (i=0 ; i < n; i++)
a[i]++;
for (; i <= n; i++)
a[i]--;
}
seems to work correctly so I need to figure out why it does not when produced
by loop-split.

[Bug tree-optimization/106293] [13 regression] 456.hmmer at -Ofast -march=native regressed by 19% on zen2 and zen3 in July 2022

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

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #28 from Jan Hubicka  ---
Added PR for the missed iteration count

[Bug middle-end/110975] New: Missed unlooping

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

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

Bug ID: 110975
   Summary: Missed unlooping
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

This is what we generate from loop-split for hmmer benchmark:

int *a;
void
test (int n)
{
int i;
for (i=0 ; i < n; i++)
a[i]++;
for (i=0 ; i <= n; i++)
a[i]--;
}

The second loop never iterates but we don't seem to be able to figure this out
and leave the loop around.

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

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

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

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

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

commit r14-3128-g8afe9d5d2fdd047cbd4e3531170af6b66d30e74a
Author: Jakub Jelinek 
Date:   Thu Aug 10 17:29:23 2023 +0200

phiopt: Fix phiopt ICE on vops [PR102989]

I've ran into ICE on gcc.dg/torture/bitint-42.c with -O1 or -Os
when enabling expensive tests, and unfortunately I can't reproduce without
_BitInt.  The IL before phiopt3 has:
   [local count: 203190070]:
  # .MEM_428 = VDEF <.MEM_367>
  bitint.159 = VIEW_CONVERT_EXPR(*.LC3);
  goto ; [100.00%]

   [local count: 203190070]:
  # .MEM_427 = VDEF <.MEM_367>
  bitint.159 = VIEW_CONVERT_EXPR(*.LC4);

   [local count: 406380139]:
  # .MEM_368 = PHI <.MEM_428(87), .MEM_427(88)>
  # VUSE <.MEM_368>
  _123 = VIEW_CONVERT_EXPR(r495[i_107].D.2780)[0];
and factor_out_conditional_operation is called on the vop PHI, it
sees it has exactly two operands and defining statements of both
PHI arguments are converts (VCEs in this case), so it thinks it is
a good idea to try to optimize that and while doing that it constructs
void type SSA_NAMEs and the like.

2023-08-10  Jakub Jelinek  

PR c/102989
* tree-ssa-phiopt.cc (single_non_singleton_phi_for_edges): Never
return virtual phis and return NULL if there is a virtual phi
where the arguments from E0 and E1 edges aren't equal.

[Bug libstdc++/110974] format out of bounds read on invalid format string "{:{}."

[gcc at pauldreik dot se via Gcc-bugs]

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

--- Comment #1 from Paul Dreik  ---
This is very similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110862
which has already been fixed on trunk.

[Bug libstdc++/110974] New: format out of bounds read on invalid format string "{:{}."

[gcc at pauldreik dot se via Gcc-bugs]

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

Bug ID: 110974
   Summary: format out of bounds read on invalid format string
"{:{}."
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at pauldreik dot se
  Target Milestone: ---

The following code:

#include 
#include 
#include 

int main() {
double v = 0;
// use a char buffer instead of a literal
// to avoid the implicit null terminator
char fmtbuf[] = {'{', ':', '{', '}', '.'};
std::string_view fmt{[0], sizeof(fmtbuf)};
std::puts(std::vformat(fmt, std::make_format_args(v)).c_str());
}

causes an out of bounds read when compiled with gcc 13.2, as well as the
current trunk.

Link to reproducer: https://godbolt.org/z/6qPMdse5o

[Bug middle-end/110973] New: 9% namd regression between g:c2a447d840476dbd (2023-08-03 18:47) and g:73da34a538ddc2ad (2023-08-09 20:17)

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

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

Bug ID: 110973
   Summary: 9% namd regression between g:c2a447d840476dbd
(2023-08-03 18:47) and g:73da34a538ddc2ad (2023-08-09
20:17)
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

All is -Ofast -march=native
zen2
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=300.120.0
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=301.120.0
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=301.120.0
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=288.120.0
Icelake
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=789.120.0
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=790.120.0
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=785.120.0
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=791.120.0

[Bug modula2/110779] SysClock can not read the clock

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

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

--- Comment #12 from Gaius Mulley  ---
Created attachment 55717
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55717=edit
Another patch for Darwin

More portability configure checks and fixes to wrapclock.cc.

[Bug libgcc/110955] SIGSEGV in libgcc_s.so.1`classify_object_over_fdes+0x140 on Solaris SPARC with GCC 13 runtime

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

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

--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #12 from Petr Sumbera  ---
> (In reply to Petr Sumbera from comment #9)
>> (In reply to r...@cebitec.uni-bielefeld.de from comment #8)
>> > > without the JIT patch (033-solaris-LLVM-JIT.patch)?  It may be worth a 
>> > > try
>> > > until someone fixes and integrates SPARC JIT support for real.
>> 
>> I will try to build LLVM without the patch and will see. But the patch says
>> it
>> was created because of gnome-shell.
>
> When I updated test system with LLVM built without 033-solaris-LLVM-JIT.patch
> (without rebuilding any other component) it fails in different way (probably
> earlier). See bellow. I think that the patch is really needed.
[...]
> libLLVM-13.so`_ZN4llvm14RuntimeDyldELF23resolveX86_64RelocationERKNS_12SectionEntryEmmjlm+0x64(969a060b00?,
> 9699f673c0?, 20?, 7af3bfb12000?, 18?, 0?)

Seems so.  Calling llvm::RuntimeDyldELF::resolveX86_64Relocation on a
SPARC ELF file is obviously complete bullshit.  Might be something
already fixed in newer LLVM versions.  Somehow, the architecture
detection is amiss...

However, given my impression from the mesa code is that even a proper
error handling in RuntimeDyLD wouldn't help there.

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

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

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

Gaius Mulley  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #11 from Gaius Mulley  ---
Closing as the problem has gone away.  For reference another bug disappeared in
modula2/108404 when the select use was re-written.

[Bug libgcc/110955] SIGSEGV in libgcc_s.so.1`classify_object_over_fdes+0x140 on Solaris SPARC with GCC 13 runtime

[sumbera at volny dot cz via Gcc-bugs]

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

--- Comment #12 from Petr Sumbera  ---
(In reply to Petr Sumbera from comment #9)
> (In reply to r...@cebitec.uni-bielefeld.de from comment #8)
> > > without the JIT patch (033-solaris-LLVM-JIT.patch)?  It may be worth a try
> > > until someone fixes and integrates SPARC JIT support for real.
> 
> I will try to build LLVM without the patch and will see. But the patch says
> it
> was created because of gnome-shell.

When I updated test system with LLVM built without 033-solaris-LLVM-JIT.patch
(without rebuilding any other component) it fails in different way (probably
earlier). See bellow. I think that the patch is really needed.

7e0fbf09e3d1 libc.so.1`__lwp_sigqueue+8(6?, 2012d400?, 0?, 9697d5d9b0?,
9697d50170?, 0?)
7e0fbf09e481 dump_gjs_stack_on_signal_handler+0xb4(6?, 0?, 7e0fbf09f060?,
0?, 7af3c050012c?, 49?)
7e0fbf09e551 libc.so.1`__sighndlr+0xc(6?, 0?, 7e0fbf09f060?, 7af3c0303624?,
0?, 7af3bff0c7c8?)
7e0fbf09e601 libc.so.1`call_user_handler+0x400((int) 0?, (siginfo_t *) 0?,
(ucontext_t *) 0x12?)
7e0fbf09e6f1 libc.so.1`sigacthandler+0xd0((int) 6?, (siginfo_t *) 0?, (void
*) 0x7e0fbf09f060?)
7e0fbf09eb41 libc.so.1`__lwp_sigqueue+8(6?, 6?, 7e0fbf09f4c0?, 0?, 0?, 0?)
7e0fbf09ebf1 libc.so.1`abort+0xb4()
7e0fbf09ecd1
libLLVM-13.so`_ZN4llvm18report_fatal_errorERKNS_5TwineEb+0xb4(7e0fbf09f6e0?,
1?, 1?, 0?, 0?, 7e0fbf09f588?)
7e0fbf09ee31
libLLVM-13.so`_ZN4llvm18report_fatal_errorEPKcb+0x5c(7af3b1eb0168?, 1?, 0?, 1?,
9699b1b788?, 9699b1b690?)
7e0fbf09ef11
libLLVM-13.so`_ZN4llvm14RuntimeDyldELF23resolveX86_64RelocationERKNS_12SectionEntryEmmjlm+0x64(969a060b00?,
9699f673c0?, 20?, 7af3bfb12000?, 18?, 0?)
7e0fbf09efd1
libLLVM-13.so`_ZN4llvm14RuntimeDyldELF17resolveRelocationERKNS_12SectionEntryEmmjlmj+0x6c(969a060b00?,
9699f673c0?, 20?, 7af3bfb12000?, 6?, 0?)
7e0fbf09f0a1
libLLVM-13.so`_ZN4llvm14RuntimeDyldELF17resolveRelocationERKNS_15RelocationEntryEm+0xd8(969a060b00?,
9699f6b6d0?, 7af3bfb12000?, 9699b28a40?, 0?,
9699b166e8?)
7e0fbf09f171
libLLVM-13.so`_ZN4llvm15RuntimeDyldImpl21resolveRelocationListERKNS_11SmallVectorINS_15RelocationEntryELj64EEEm+0xa4(969a060b00?,
9699f6b6c0?,
7af3bfb12000?, 9699b166e8?, 70?, 0?)
7e0fbf09f231
libLLVM-13.so`_ZN4llvm15RuntimeDyldImpl23resolveLocalRelocationsEv+0x8c(969a060b00?,
0?, 0?, 9699b166e8?, 0?, 9699f6b6b0?)
7e0fbf09f2f1
libLLVM-13.so`_ZN4llvm15RuntimeDyldImpl18resolveRelocationsEv+0x200(969a060b00?,
1?, 0?, 0?, 1?, 969a060bf0?)
7e0fbf09f3e1
libLLVM-13.so`_ZN4llvm11RuntimeDyld18resolveRelocationsEv+0x30(9699b1b6f0?, 6?,
1?, 0?, 9699b1b690?, 0?)
7e0fbf09f4a1
libLLVM-13.so`_ZN4llvm5MCJIT21finalizeLoadedModulesEv+0x60(9699b1b420?,
9699b1b6f0?, 0?, 1?, 9699b1b788?, 9699b1b690?)
7e0fbf09f5b1
libLLVM-13.so`_ZN4llvm5MCJIT14finalizeObjectEv+0x290(9699b1b420?, 9699b1b748?,
7e0fbf09fe60?, 9699b1b770?, 7e0fbf09fea0?, 7e0fbf09fea0?)
7e0fbf09f721 libLLVM-13.so`LLVMGetPointerToGlobal+0x38(9699b1b420?,
9699b12078?, 291c00?, 0?, 0?, 336?)
7e0fbf09f7e1 swrast_dri.so`llvmpipe_update_fs+0xe94(96978b7d00?,
9699b0b344?, 969793d560?, 9697b91a40?, 9699b0b290?, 0?)
..

[Bug libgcc/110955] SIGSEGV in libgcc_s.so.1`classify_object_over_fdes+0x140 on Solaris SPARC with GCC 13 runtime

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

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

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
>> --- Comment #9 from Petr Sumbera  ---
>> (In reply to r...@cebitec.uni-bielefeld.de from comment #8)
>>> > I'm not sure if we taked about this before: have you tried building
>>> > SPARC LLVM
>>> > without the JIT patch (033-solaris-LLVM-JIT.patch)?  It may be worth a try
>>> > until someone fixes and integrates SPARC JIT support for real.
>>
>> I will try to build LLVM without the patch and will see. But the patch says 
>> it
>> was created because of gnome-shell.
>
> Fine, thanks.

I think I re-discovered what's going on: gnome-shell (directly or
indirectly) seems to depend on mesa, which again has a hard dependency on
LLVM's MCJIT in src/gallium/auxiliary/gallivm/lp_bld_{init,misc}.*.
What a mess...

[Bug target/110960] TestSatWidenMulPairwiseAdd in the Google Highway test suite fails when compiled with GCC 12 or later with the -mcpu=power9 option

[john_platts at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from John Platts  ---
Need to use revision ff1ad85a96c0bc8483b582d6dbceb8bc07edd226 of Google Highway
to reproduce the PPC9 codegen bug with GCC 12 as the TestSatWidenMulPairwiseAdd
will now pass on PPC9 due to a recent update to TestSatWidenMulPairwiseAdd in
the master branch of the Google Highway Git repository.

[Bug middle-end/110972] 13% fatigue regression between g:bb3ceeb6520c13fc (2023-08-07 21:09) and g:d9dc70cc65becca9 (2023-08-08 13:30)

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

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

--- Comment #1 from Jan Hubicka  ---
The following patches in the range looks like they may cause the difference

commit d9f3ea61fe36e2de3354b90b65ff8245099114c9
Author: Richard Biener 
Date:   Mon Aug 7 14:44:20 2023 +0200

tree-optimization/49955 - BB reduction with odd number of lanes

commit 02a015fa320229a057ef721eaf663f3eb22a8ace
Author: Ju-Zhe Zhong 
Date:   Mon Aug 7 17:38:12 2023 +0800

VECT: Support CALL vectorization for COND_LEN_*

commit 31ec413098bd334115aff73fc755e49afd3ac371
Author: Richard Biener 
Date:   Tue Aug 8 12:46:42 2023 +0200

tree-optimization/110924 - fix vop liveness for noreturn const CFG parts

[Bug middle-end/110972] New: 13% fatigue regression between g:bb3ceeb6520c13fc (2023-08-07 21:09) and g:d9dc70cc65becca9 (2023-08-08 13:30)

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

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

Bug ID: 110972
   Summary: 13% fatigue regression between g:bb3ceeb6520c13fc
(2023-08-07 21:09) and g:d9dc70cc65becca9 (2023-08-08
13:30)
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

With -Ofast -march native. 
zen2:
https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=171.767.0
zen3:
https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=283.767.0

[Bug libstdc++/110968] format out of bounds read on format("{:05L}",-1.f)

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

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

--- Comment #2 from Jonathan Wakely  ---
--- a/libstdc++-v3/include/std/format
+++ b/libstdc++-v3/include/std/format
@@ -1634,7 +1634,8 @@ namespace __format
__wstr = _M_localize(__str, __expc, __fc.locale());
  else
__wstr = _M_localize(__str, __expc, __loc.value());
- __str = __wstr;
+ if (!__wstr.empty())
+   __str = __wstr;
}

  size_t __width = _M_spec._M_get_width(__fc);

[Bug middle-end/110962] RISC-V vector Fortran ICE in expand_expr_real_2

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Pan Li :

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

commit r14-3126-gda7b43fb0224cdce5157a747fdd6975b7c81c6cf
Author: Juzhe-Zhong 
Date:   Thu Aug 10 18:37:05 2023 +0800

RISC-V: Add MASK vec_duplicate pattern[PR110962]

This patch fix bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110962

SUBROUTINE a(b,c,d)
  LOGICAL,DIMENSION(INOUT)  :: b
  LOGICAL e
  REAL, DIMENSION(IN) ::  c
  REAL, DIMENSION(INOUT)  ::  d
  REAL, DIMENSION(SIZE(c))   :: f
  WHERE (b.AND.e)
 WHERE (f>=0.)
d = g
 ENDWHERE
  ENDWHERE
END SUBROUTINE a

   PR target/110962

gcc/ChangeLog:
PR target/110962
* config/riscv/autovec.md (vec_duplicate): New pattern.

[Bug libstdc++/110968] format out of bounds read on format("{:05L}",-1.f)

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

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

--- Comment #1 from Jonathan Wakely  ---
Oh dear, I must have broken this function at some point while implementing
std::format:

  // Locale-specific format.
  basic_string<_CharT>
  _M_localize(basic_string_view<_CharT> __str, char __expc,
  const locale& __loc) const
  {
basic_string<_CharT> __lstr;

if (__loc == locale::classic())
  return __lstr; // Nothing to do.

That just returns an empty string, which the caller then uses assuming it's
valid.

[no subject]

[ดวงกมล ทองฟู via Gcc-bugs]

สวัสดีครับ บริษัท เอกทรัพย์เจริญ เครดิต
*บริการเงินทุนฉุกเฉินระยะสั้น*
ไม่เรียกเก็บเงินก่อนทำสัญญาทุกกรณี
ดอกเบี้ยเริ่มต้น 1.5%
วงเงินสูง 5 ล้านบาท
✅หากคุณสนใจบริการของเราโทรด่วนหาเรา
LINE esc.credit
โทร 082 5928519 คุณเอก
โทร 063 2543219 คุณตะวัน
เราพร้อมสนับสนุนธุรกิจคุณ อย่างมั่นคง

[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||patch
   Last reconfirmed|2017-11-20 00:00:00 |2023-08-10

--- Comment #5 from Jonathan Wakely  ---
New patch dropped:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626925.html

[Bug libstdc++/65762] --with-default-libstdcxx-abi=c++11 is silently ignored when --disable-libstdcxx-dual-abi is used

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2015-04-14 00:00:00 |2023-8-10
 Depends on||83077

--- Comment #2 from Jonathan Wakely  ---
(In reply to Iain Sandoe from comment #1)
> so, FAOD, that means that 
> versioned namespace => disables dual ABI 
> => forces the old string impl?

Yes, that's PR 83077

> What's the blocker to making it work?
> (just time - or ABI issues?)

As it happens, François posted a patch for 83077 this morning:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626925.html

I haven't reviewed it yet.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077
[Bug 83077] sso-string @ gnu-versioned-namespace.

[Bug libstdc++/110970] clang / c++23 missing 'typename' prior to dependent type name 'iterator_traits<_It>::iterator_category'

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|NEW |ASSIGNED
   Target Milestone|--- |13.3
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

--- Comment #3 from Jonathan Wakely  ---
We aim to support at least two versions of Clang, so we have to wait for 17
before we can consider 15 too old. That said, the combination of the newest
-std and not-the-latest Clang is usually going to be a bit risky.

Anyway, I have a patch to fix this, which also cleans the code up a little.

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

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

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

--- Comment #10 from Iain Sandoe  ---
(In reply to Gaius Mulley from comment #9)
> This looks fixed from the commit trail - can this PR be closed now?

It's "fixed" - in that the more defensive coding around the select calls no
longer triggers the hanging case.

Unfortunately, I was not able to find any conclusive reason why the select
calls are getting incorrect input in the first place.  So, we can close this
bug but perhaps remember in the back of the mind that something (unknown) is
still not quite right with the select usage.

[Bug modula2/108404] M2RTS_Halt fails with a segv (it should emit a diagnostic and exit).

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #9 from Gaius Mulley  ---
Thanks!  Closing now that the bug has disappeared.

[Bug libstdc++/110970] clang / c++23 missing 'typename' prior to dependent type name 'iterator_traits<_It>::iterator_category'

[gcc-bugzilla at zulan dot net via Gcc-bugs]

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

--- Comment #2 from gcc-bugzilla at zulan dot net ---
Yes, apologies for the missing information

clang version 15.0.7
g++ (GCC) 13.2.1 20230801
(Arch)

According to https://clang.llvm.org/cxx_status.html
P0634R3 / "Down with typename!" is implemented since Clang 16 (released in
March). So maybe this is actually not a problem for much longer. Might only
affect the combination of a very recent GCC with slightly outdated Clang.

[Bug libstdc++/65762] --with-default-libstdcxx-abi=c++11 is silently ignored when --disable-libstdcxx-dual-abi is used

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

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

--- Comment #1 from Iain Sandoe  ---
so, FAOD, that means that 
versioned namespace => disables dual ABI 
=> forces the old string impl?

What's the blocker to making it work?
(just time - or ABI issues?)

[Bug target/110964] RISC-V vector ICE in expand_cond_len_ternop

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Pan Li :

https://gcc.gnu.org/g:887f13916b18f46b563d527ad5001c6384e44a60

commit r14-3123-g887f13916b18f46b563d527ad5001c6384e44a60
Author: Juzhe-Zhong 
Date:   Thu Aug 10 17:21:46 2023 +0800

RISC-V: Support TU for integer ternary OP[PR110964]

PR target/110964

gcc/ChangeLog:
PR target/110964
* config/riscv/riscv-v.cc (expand_cond_len_ternop): Add integer
ternary.

gcc/testsuite/ChangeLog:
PR target/110964
* gcc.target/riscv/rvv/autovec/pr110964.c: New test.

[Bug libstdc++/110970] clang / c++23 missing 'typename' prior to dependent type name 'iterator_traits<_It>::iterator_category'

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-08-10

--- Comment #1 from Jonathan Wakely  ---
Clang 15, I assume?

[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))

[romato.san1337 at gmail dot com via Gcc-bugs]

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

--- Comment #57 from Roman Krotov  ---
(In reply to Ed Catmur from comment #55)
> So this problem will resolve itself, over time.

But I don't see any reasons not to implement the switch right now...
Late is better than never.

> we can expect that attribute to be adopted where people intend that behavior
> as opposed to the
> warning not suppressible by cast to void

I see your point and I partially agree with it, but what about the projects
what don't agree with the distinction of these 2 attributes? Or just want to be
more compatible with clang?
Or they just may not agree with the choice of a library, that decided to put
wur instead of nodiscard for a specific function.
Something like -Wno-void-unused would still be better for them than
-Wno-unused-result, for the reasons in my previous comment.

(In reply to Martin Uecker from comment #56)
> works as expected and is supported for older language modes

Even if one day projects, that will prefer to stay on C99 or C11 and use
-Wpedantic (which warns about [[]] right now), will be able to use [[syntax]]
without any warning, they may still not like it. Even if gcc will include
nodiscard into the __attribute__ syntax, there, for sure, will be the libraries
that won't prefer to update or use the new attribute.
For these situations, or even if they **will** use the new attribute, see my
previous paragraph.

[Bug libgcc/102968] macOS Monterey not yet supported in configure

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #4 from Iain Sandoe  ---
was fixed for 10.4 and is fixed on all open branches.

[Bug tree-optimization/110963] [14 Regression] Dead Code Elimination Regression since r14-2946-g46c8c225455

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

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

--- Comment #7 from Jan Hubicka  ---
We don't consider main cold, but executed once: code out of loops is optimized
for size, but anything in loops is optimized according to -O setting.  I did
not really think of users overwriting it by hot attribute, but looking into
implementation it will work :)

[Bug modula2/108404] M2RTS_Halt fails with a segv (it should emit a diagnostic and exit).

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

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

--- Comment #8 from Iain Sandoe  ---
(In reply to Gaius Mulley from comment #7)
> I wonder if this bug has now been fixed via the other PR fixes. 
> Specifically the rewrite of RTco.cc, the defensive use of select, bugfixes
> to HIGH and FIO.mod (memcpy parameters)?  It might be worth a re-run just to
> explore the effect of these fixes.

I guess we can say this bug is fixed, indeed.
...the other hanging tests have been 'fixed' by a more defensive implementation
of the select functionality (although it remains unclear why select is failing
in the first place).

[Bug tree-optimization/110963] [14 Regression] Dead Code Elimination Regression since r14-2946-g46c8c225455

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #6 from rguenther at suse dot de  ---
On Thu, 10 Aug 2023, theodort at inf dot ethz.ch wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110963
> 
> --- Comment #5 from Theodoros Theodoridis  ---
> (In reply to Richard Biener from comment #4)
> > Alternatively you can put __attribute__((hot)) on 'main' which we otherwise
> > consider cold.  Maybe that's a good idea for future DCE regression searches?
> 
> 
> Thanks for the feedback. IIRC, I have reported at least one more case where
> renaming 'main' would make the issue go away. So if adding 
> __attribute__((hot))
> makes sense, then I'll include it when searching.

I think it makes sense, it properly distinguishes -Os from -O2 where
otherwise those would behave too similar.

[Bug tree-optimization/110963] [14 Regression] Dead Code Elimination Regression since r14-2946-g46c8c225455

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

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

--- Comment #5 from Theodoros Theodoridis  ---
(In reply to Richard Biener from comment #4)
> Alternatively you can put __attribute__((hot)) on 'main' which we otherwise
> consider cold.  Maybe that's a good idea for future DCE regression searches?


Thanks for the feedback. IIRC, I have reported at least one more case where
renaming 'main' would make the issue go away. So if adding __attribute__((hot))
makes sense, then I'll include it when searching.

[Bug tree-optimization/110963] [14 Regression] Dead Code Elimination Regression since r14-2946-g46c8c225455

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

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

--- Comment #4 from Richard Biener  ---
(In reply to Andrew Pinski from comment #1)
> Confirmed.
> PRE seems to have missed an obvious redundant load here though:

Skipping partial redundancy for expression {mem_ref<0B>,addr_expr<>}@.MEM_21
(0008), no redundancy on to be optimized for speed edge

renaming 'main' into 'bar' fixes this:

Found partial redundancy for expression {mem_ref<0B>,addr_expr<>}@.MEM_22
(0007)
Created phi prephitmp_7 = PHI <_10(11), 0B(6)>
 in block 7 (0007)
...


then the call to 'foo' is eliminated already in FRE5 (before the sinking pass
affected by r14-2946-g46c8c225455).

IMHO this isn't a bug worth pursuing.

Alternatively you can put __attribute__((hot)) on 'main' which we otherwise
consider cold.  Maybe that's a good idea for future DCE regression searches?

Maybe we can consider the special case worthwhile also when optimizing for
size.

[Bug c/84510] C front-end does not utilise -Wuseless-cast

[muecker at gwdg dot de via Gcc-bugs]

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

Martin Uecker  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

--- Comment #2 from Martin Uecker  ---
PATCH https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626973.html

[Bug libgcc/110955] SIGSEGV in libgcc_s.so.1`classify_object_over_fdes+0x140 on Solaris SPARC with GCC 13 runtime

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

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

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #9 from Petr Sumbera  ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #8)
>> > I'm not sure if we taked about this before: have you tried building
>> > SPARC LLVM
>> > without the JIT patch (033-solaris-LLVM-JIT.patch)?  It may be worth a try
>> > until someone fixes and integrates SPARC JIT support for real.
>
> I will try to build LLVM without the patch and will see. But the patch says it
> was created because of gnome-shell.

Fine, thanks.

>> Another question: do you have a way to reliably reproduce that SEGV?
>> When I run gnome-shell with X11 forwarding (i.e. without a full GNOME
>> session), I get this instead:
>
> Yes, it fails everytime one try to run vncserver on SPARC on st-152.
>
> Maybe you need install pkg:/group/feature/multi-user-desktop?!

I'm a bit reluctant to do so, honestly.  The gnome-shell installation
already dragged in almost 100 packages I don't need on that system.
Perhaps do it in a scratch local zone instead...

[Bug libgcc/110955] SIGSEGV in libgcc_s.so.1`classify_object_over_fdes+0x140 on Solaris SPARC with GCC 13 runtime

[sumbera at volny dot cz via Gcc-bugs]

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

--- Comment #9 from Petr Sumbera  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #8)
> > I'm not sure if we taked about this before: have you tried building SPARC 
> > LLVM
> > without the JIT patch (033-solaris-LLVM-JIT.patch)?  It may be worth a try
> > until someone fixes and integrates SPARC JIT support for real.

I will try to build LLVM without the patch and will see. But the patch says it
was created because of gnome-shell.

> Another question: do you have a way to reliably reproduce that SEGV?
> When I run gnome-shell with X11 forwarding (i.e. without a full GNOME
> session), I get this instead:

Yes, it fails everytime one try to run vncserver on SPARC on st-152.

Maybe you need install pkg:/group/feature/multi-user-desktop?!

[Bug tree-optimization/110971] New: ICE on valid code at -O3 on x86_64-linux-gnu: in operator/, at sreal.cc:261

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

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

Bug ID: 110971
   Summary: ICE on valid code at -O3 on x86_64-linux-gnu: in
operator/, at sreal.cc:261
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a recent regression.

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

[532] % 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 --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230810 (experimental) (GCC)
[533] %
[533] % gcctk -O3 small.c
during GIMPLE pass: lsplit
small.c: In function ‘main’:
small.c:2:5: internal compiler error: in operator/, at sreal.cc:261
2 | int main() {
  | ^~~~
0x7e52f5 sreal::operator/(sreal const&) const
../../gcc-trunk/gcc/sreal.cc:261
0x7e52f5 sreal::operator/(sreal const&) const
../../gcc-trunk/gcc/sreal.cc:259
0x118e47b split_loop
../../gcc-trunk/gcc/tree-ssa-loop-split.cc:719
0x118ed4b tree_ssa_split_loops
../../gcc-trunk/gcc/tree-ssa-loop-split.cc:1769
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[534] %
[534] % cat small.c
int a, b, c, d;
int main() {
  for (a = 0; a < 2; a++) {
if (b > 2)
  c = 0;
if (b > a)
  d = 0;
  }
  return 0;
}

[Bug tree-optimization/110963] [14 Regression] Dead Code Elimination Regression since r14-2946-g46c8c225455

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

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

--- Comment #3 from Richard Biener  ---
So we're now doing an additional sinking:

Sinking # VUSE <.MEM_2(D)>
pretmp_12 = h;
 from bb 2 to bb 4
Removing basic block 9

that's the only IL difference on GIMPLE, without this we optimize away foo
during RTL optimization during RTL PRE.

[Bug libgcc/110956] [13/14 regression] gcc_assert is hit at gcc-13.2.0/libgcc/unwind-dw2-fde.c#L291 with some special library

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

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

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
[...]
> I'm currently running a full i386-pc-solaris2.11 bootstrap.

... which just completed without regressions.

Thanks again.

[Bug libgcc/110955] SIGSEGV in libgcc_s.so.1`classify_object_over_fdes+0x140 on Solaris SPARC with GCC 13 runtime

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

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #7 from Rainer Orth  ---
> (In reply to Petr Sumbera from comment #3)
>> (In reply to Andrew Pinski from comment #1)
>> > Are you sure this is NOT a LLVM JIT issue?
>> > There was a similar issue on aarch64 too; PR 108994 which was fixed in LLVM
>> > side.
>> 
>> Don't really know. But the binary gnome-shell which was compiled by GCC 12
>> doesn't run with GCC 13 runtime.
>> 
>> Also when I copy gcc/libgcc/unwind-dw2-fde.(c|h) from GCC 12 to GCC 13 it
>> doesn't crash then.
>
> I'm not sure if we taked about this before: have you tried building SPARC LLVM
> without the JIT patch (033-solaris-LLVM-JIT.patch)?  It may be worth a try
> until someone fixes and integrates SPARC JIT support for real.

Another question: do you have a way to reliably reproduce that SEGV?
When I run gnome-shell with X11 forwarding (i.e. without a full GNOME
session), I get this instead:

mutter-Message: 12:43:16.908: Running GNOME Shell (using mutter 41.9) as a X11
window and compositing manager

(gnome-shell:17373): GLib-GIO-ERROR **: 12:43:18.865: Settings schema
'org.gnome.mutter' is not installed
Trace/Breakpoint Trap

and under mdb (gdb gets an internal error):

mutter-Message: 12:40:24.426: Running GNOME Shell (using mutter 41.9) as a X11
window and compositing manager

(gnome-shell:17027): GLib-GIO-ERROR **: 12:40:24.547: Settings schema
'org.gnome.mutter' is not installed
mdb: stop on SIGTRAP
mdb: target stopped at:
libc.so.1`__lwp_sigqueue+8: bcc,a,pt  %icc, +0x10  

mdb: You've got symbols!
gnome-shell:17027*> $C
7c11b6412e71 libc.so.1`__lwp_sigqueue+8(5?, 7c11b64137d0?, 4?, 0?,
7b107f7e2e44?, 7b107fa005b0?)
7c11b6412f21 libglib-2.0.so.0.7000.5`g_log_default_handler+0xbc(
7b107e48e070?, 6?, 7b76f39c00?, 0?, ?, 7b107f78cb68?)
7c11b6413031 libglib-2.0.so.0.7000.5`g_logv+0x220(7b76f39c00?,
7b107fa005d0?, 0?, 7b107e48e070?, 6?, 4?)
7c11b6413141 libglib-2.0.so.0.7000.5`g_log+0x20(7b107e48e070?, 4?,
7b107e4a1c78?, 7b76f26860?, 0?, 0?)
7c11b6413201 libgio-2.0.so.0.7000.5`g_settings_set_property+0x170(
7b76ee44a0?, 2?, 7c11b6413b70?, 7b76ed0de0?, 7b76ee4480?, 7b76f26860?)
7c11b64132b1 libgobject-2.0.so.0.7000.5`g_object_new_internal+0x318(
7b76f1e340?, 7c11b6413cc0?, 1?, 7b76ece230?, 7c11b6413cd0?, 7b76f1e340?)
7c11b64133a1 libgobject-2.0.so.0.7000.5`g_object_new_valist+0x120(
7b76ee4c90?, 1?, 0?, 7c11b6413cc0?, 7c11b6413dc0?, 1?)
7c11b6413741 libgobject-2.0.so.0.7000.5`g_object_new+0x24(7b76ee4c90?,
7b107e4a2068?, 7b107f16e340?, 0?, 0?, 0?)
7c11b6413801 libmutter-9.so.0.0.0`meta_settings_init+0x58(7b76ee8800?,
7b76f05db0?, ff00?, 2946?, 7b107fe18944?, 7b107f16aad0?)
7c11b64138b1 libgobject-2.0.so.0.7000.5`g_type_create_instance+0x1cc(
7b76ee8800?, 0?, 7b76f05db0?, 7b76f0e2b8?, 7b76f0e270?, 7b76f0e2b8?)
7c11b6413961 
libgobject-2.0.so.0.7000.5`g_object_new_internal.constprop.0+0x34(7b76f05db0?,
7b107ed00250?, 0?, 0?, 0?, 7b76f0e270?)
7c11b6413a41 libgobject-2.0.so.0.7000.5`g_object_new_with_properties+0x2a0(
7b76f0e270?, 0?, 0?, 0?, 7b1080442a40?, 0?)
7c11b6413af1 libgobject-2.0.so.0.7000.5`g_object_new+0x40(7b76f0e270?, 0?,
1b3000?, 7b76f1c7b0?, 7b107fa00878?, 7b76ec4350?)
7c11b6413bb1 libmutter-9.so.0.0.0`meta_settings_new+0x6c(7b76ee1150?,
7b76ed3d60?, ff00?, 7b76ed3d60?, 7b76ed2c00?, 7b76ed3d60?)
7c11b6413c61 libmutter-9.so.0.0.0`meta_backend_initable_init+0x38(
7b76ee1150?, 0?, 7c11b6414b88?, 7b107f4001f8?, 7b76ee1090?, 7b76ee1150?)
7c11b6413d11 libmutter-9.so.0.0.0`meta_backend_x11_initable_init+0x104(
7b76ee1150?, 0?, 7c11b6414b88?, 7b107f400830?, 7b76f0e270?, 7b76ee1010?)
7c11b6413dc1 libgio-2.0.so.0.7000.5`g_initable_init+0x68(7b76ee1150?, 0?,
7c11b6414b88?, 7c11b6414400?, 7c11b64143f8?, 7b76ee02c0?)
7c11b6413e81 libgio-2.0.so.0.7000.5`g_initable_new_valist+0x78(
7b76ee1150?, 7b107f16a2a8?, 7c11b6414890?, 0?, 7c11b6414b88?, 7b76ec4350?)
7c11b6413f31 libgio-2.0.so.0.7000.5`g_initable_new+0x20(7b76ed2c00?, 0?,
7c11b6414b88?, 7b107f16a2a8?, 7b76ed2060?, 7b107f16d178?)
7c11b6413ff1 libmutter-9.so.0.0.0`meta_context_main_create_backend+0x80(
7b76ed2060?, 7c11b6414b88?, 7b107f208110?, 7b107f1dcbc8?, 7b10801eb280?,
7b76ed2060?)
7c11b64140b1 libmutter-9.so.0.0.0`meta_context_real_setup+0x30(
7b76ed2010?, 7c11b6414b88?, 0?, 7b76ecfd10?, 7b76ecfca0?, 7b76ecfca0?)
7c11b6414161 libmutter-9.so.0.0.0`meta_context_main_setup+0x64(
7b76ed2060?, 7c11b6414b88?, 7b107f176268?, 7b76ec3fb0?, 7b76ecff00?,
7b76ed2060?)
7c11b6414211 libmutter-9.so.0.0.0`meta_context_setup+0x168(7b76ed2060?,
7c11b6414b88?, 103000?, 7b76ed2060?, ffb0?, 7b76ed2010?)
7c11b64142c1 main+0x1ac(7c11b6414b90?, 7b76ec40b0?, 7c11b6414b88?,
7c11b6414ba0?, 7b1080400138?, 7b76ed2060?)
7c11b64143c1 

[Bug sanitizer/110876] AddressSanitizer: false positive bad-free

[dvirtz at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Dvir Yitzchaki  ---
Thanks @Andrew. 
Is it undefined behavior to recover from SIGABRT? I didn't find a source for
that.
The fact is that the memory ASAN is complaining about was allocated.

[Bug libstdc++/110970] New: clang / c++23 missing 'typename' prior to dependent type name 'iterator_traits<_It>::iterator_category'

[gcc-bugzilla at zulan dot net via Gcc-bugs]

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

Bug ID: 110970
   Summary: clang / c++23 missing 'typename' prior to dependent
type name 'iterator_traits<_It>::iterator_category'
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at zulan dot net
  Target Milestone: ---

Using clang with the current libstdc++ and c++23 (2b) fails:

echo "#include " | clang++ -std=c++2b -stdlib=libstdc++ -c -x c++ -
In file included from :1:
In file included from
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/algorithm:60:
In file included from
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/stl_algobase.h:67:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/stl_iterator.h:2618:35:
error: missing 'typename' prior to dependent type name
'iterator_traits<_It>::iterator_category'
  { using iterator_category = iterator_traits<_It>::iterator_category; };


The line is unchanged in the current git, so I presume this is not fixed yet.

Simply adding `typename` to the line does fix the issue with clang.

This is similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100900. I won't
try to language lawyer what is technically correct here. In the other issue it
was decided to be nice and support other implementations even though it is a
(very low cost) workaround.

[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))

[muecker at gwdg dot de via Gcc-bugs]

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

Martin Uecker  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

--- Comment #56 from Martin Uecker  ---
[[nodiscard]] works as expected and is supported for older language modes since
GCC 11 (and the syntax is ignored with a warning in GCC 10). Clang supports it
with -std=c2x since version 9 and it seems Clang will also support it in older
language modes in future releases.

[Bug libstdc++/110968] format out of bounds read on format("{:05L}",-1.f)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |13.3
   Last reconfirmed||2023-08-10
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

[Bug middle-end/110969] ICE in to_constant, at poly-int.h:504 on aarch64

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Still a dup.

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

[Bug tree-optimization/102587] ICE in tree_to_uhwi, at tree.h:4668

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

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

[Bug libgcc/110955] SIGSEGV in libgcc_s.so.1`classify_object_over_fdes+0x140 on Solaris SPARC with GCC 13 runtime

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

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

--- Comment #7 from Rainer Orth  ---
(In reply to Petr Sumbera from comment #3)
> (In reply to Andrew Pinski from comment #1)
> > Are you sure this is NOT a LLVM JIT issue?
> > There was a similar issue on aarch64 too; PR 108994 which was fixed in LLVM
> > side.
> 
> Don't really know. But the binary gnome-shell which was compiled by GCC 12
> doesn't run with GCC 13 runtime.
> 
> Also when I copy gcc/libgcc/unwind-dw2-fde.(c|h) from GCC 12 to GCC 13 it
> doesn't crash then.

I'm not sure if we taked about this before: have you tried building SPARC LLVM
without the JIT patch (033-solaris-LLVM-JIT.patch)?  It may be worth a try
until someone fixes and integrates SPARC JIT support for real.

[Bug middle-end/110969] New: ICE in to_constant, at poly-int.h:504 on aarch64

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

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

Bug ID: 110969
   Summary: ICE in to_constant, at poly-int.h:504 on aarch64
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
  Target Milestone: ---
  Host: aarch64-linux
Target: aarch64-linux

With master revision r14-3032-g831017d5e72173 targeting aarch64 (both native
and cross-compiler from x86_64), the compiler ICEs when compiling our testcase
gcc/testsuite/gcc.target/aarch64/sve/pr102587-2.c with option
-ftrivial-auto-var-init=pattern

mjambor@space:~/gcc/mine/tests/bb$ ~/gcc/mine/inst/bin/gcc
/home/mjambor/gcc/mine/src/gcc/testsuite/gcc.target/aarch64/sve/pr102587-2.c
-ftrivial-auto-var-init=pattern
during RTL pass: expand
/home/mjambor/gcc/mine/src/gcc/testsuite/gcc.target/aarch64/sve/pr102587-2.c:
In function ‘foo’:
/home/mjambor/gcc/mine/src/gcc/testsuite/gcc.target/aarch64/sve/pr102587-2.c:4:28:
internal compiler error: in to_constant, at poly-int.h:504
4 | void foo() { __SVFloat64_t f64; }
  |^~~
0xae7253 poly_int_pod<2u, unsigned long>::to_constant() const
/home/mjambor/gcc/mine/src/gcc/poly-int.h:504
0xad18bf expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/mjambor/gcc/mine/src/gcc/expr.cc:11039
0xaddf3f store_expr(tree_node*, rtx_def*, int, bool, bool)
/home/mjambor/gcc/mine/src/gcc/expr.cc:6325
0xadfdab expand_assignment(tree_node*, tree_node*, bool)
/home/mjambor/gcc/mine/src/gcc/expr.cc:6043
0xc24c8f expand_DEFERRED_INIT
/home/mjambor/gcc/mine/src/gcc/internal-fn.cc:3385
0x968f3f expand_call_stmt
/home/mjambor/gcc/mine/src/gcc/cfgexpand.cc:2737
0x968f3f expand_gimple_stmt_1
/home/mjambor/gcc/mine/src/gcc/cfgexpand.cc:3880
0x968f3f expand_gimple_stmt
/home/mjambor/gcc/mine/src/gcc/cfgexpand.cc:4044
0x970c5b expand_gimple_basic_block
/home/mjambor/gcc/mine/src/gcc/cfgexpand.cc:6096
0x97354f execute
/home/mjambor/gcc/mine/src/gcc/cfgexpand.cc:6831
Please submit a full bug report, with preprocessed source (by using
-freport-bug).

[Bug libgcc/110956] [13/14 regression] gcc_assert is hit at gcc-13.2.0/libgcc/unwind-dw2-fde.c#L291 with some special library

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

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

--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #8 from Thomas Neumann  ---
> Created attachment 55715
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55715=edit
> patch to use the correct base pointer
>
> The attached patch fixes the test case by using the correct base pointer 
> during
> frame deregistration.

Amazing: thanks for the analysis and the patch.

I'm currently running a full i386-pc-solaris2.11 bootstrap.

FWIW, the problematic library was apparently built with the original
CodeSourcery GCC 3.4.3 port to support Solaris 10/amd64.

[Bug rtl-optimization/110867] [14 Regression] ICE in combine after 7cdd0860949c6c3232e6cff1d7ca37bb5234074c

[stefansf at linux dot ibm.com via Gcc-bugs]

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

--- Comment #9 from Stefan Schulze Frielinghaus  
---
It looks like as if the first fix didn't entirely solve the problem.  It turns
out that the normal form of const_int is not always met.  Before releasing a
new patch, could you test it first in order to make sure that I do not break
bootstrapping again.  I already gave it a try against the reproducer but would
like to make sure that the whole bootstrap is successful.

[Bug rtl-optimization/110867] [14 Regression] ICE in combine after 7cdd0860949c6c3232e6cff1d7ca37bb5234074c

[stefansf at linux dot ibm.com via Gcc-bugs]

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

--- Comment #8 from Stefan Schulze Frielinghaus  
---
Created attachment 55716
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55716=edit
Really fix narrow comparison

[Bug libfortran/110966] should matmul_c8_avx512f be updated with matmul_c8_x86-64-v4.

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
(In reply to Richard Biener from comment #1)
> I think matmul is fine with avx512f or avx, so requiring/using only the base
> ISA level sounds fine to me.

Could be potential miss-optimization.

[Bug libstdc++/110968] New: format out of bounds read on format("{:05L}",-1.f)

[gcc at pauldreik dot se via Gcc-bugs]

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

Bug ID: 110968
   Summary: format out of bounds read on format("{:05L}",-1.f)
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at pauldreik dot se
  Target Milestone: ---

The following program:

#include 
#include 

int main() {
float v = -1;
std::puts(std::vformat("{:05L}", std::make_format_args(v)).c_str());
}

generates an out of bounds read when compiled with gcc 13.2 (and current trunk,
as of 2023-08-10).

Link to reproducer: https://godbolt.org/z/PjeTsK89E