[Bug libgcc/109270] New: ssp/ssp.h should be adapted to use __builtin_dynamic_object_size()

[arthur200126 at gmail dot com via Gcc-bugs]

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

Bug ID: 109270
   Summary: ssp/ssp.h should be adapted to use
__builtin_dynamic_object_size()
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur200126 at gmail dot com
  Target Milestone: ---

GCC 12.0 introduced __builtin_dynamic_object_size() in support of Glibc's
_FORTIFY_SOURCE 3, but gcc's own implementation in libssp/ssp/ssp.h.in still
lags behind in using the new builtin as of commit 378ec7b. GCC should use the
new stuff for its __ssp_bos{,0} definitions at level 3.

[Bug c/109269] [sve] should check the upper bound for predicate sve

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
But that would be undefined code still.
If num was INT_MAX-3 in the int case, it might be valid.
I have to think further on that.

But that is a corner case where you would have an array which is huge.

[Bug c/109269] [sve] should check the upper bound for predicate sve

[zhongyunde at huawei dot com via Gcc-bugs]

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

--- Comment #3 from vfdff  ---
* test: https://gcc.godbolt.org/z/5s4Wbs466
```
void mset (int *a, int num) {
   for (int i=0; i< num; i++)
 a[i] = 2;
}
```

* the issue is still exist with int type as we use 32-bits register? . see
detail on gcc's assemble:

```
mset:
cmp w1, 0
ble .L1
mov x2, 0
cntwx3
whilelo p0.s, wzr, w1
mov z0.s, #2
.L3:
st1wz0.s, p0, [x0, x2, lsl 2]
add x2, x2, x3   --  overflow a 32-bit value ?
whilelo p0.s, w2, w1   
b.any   .L3
.L1:
ret
```

[Bug c/109269] [sve] should check the upper bound for predicate sve

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Pointers cannot wrap that is once a pointer is a valid pointer, adding anything
to it cannot get you a null pointer.
In this case a large argument to num would cause an for the pointers so gcc
knows num has to be less than LONG_LONG_MAX/sizeof(int).

[Bug c/109269] [sve] should check the upper bound for predicate sve

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

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

--- Comment #1 from Andrew Pinski  ---
That would be undefined code as the largest array is 63bits.

[Bug c/109269] New: [sve] should check the upper bound for predicate sve

[zhongyunde at huawei dot com via Gcc-bugs]

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

Bug ID: 109269
   Summary: [sve] should check the upper bound for predicate sve
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhongyunde at huawei dot com
  Target Milestone: ---

* test case:https://gcc.godbolt.org/z/jde11xv53
```
void mset (int *a, long long num) {
   for (long long i=0; i< num; i++)
 a[i] = 2;
}
```
* Base on above case, gcc don't check the upper bound,
  so when the input num is very large, such as 0xfffe, and the
vscale is 4 (512-bit scalable vector), so the "add x2, x2, x3" in the loop
body may be overflow, when the check "whilelo p0.s, x2, x1" will always be true
?

* see detail for gcc's assemble
```
mset:
cmp x1, 0
ble .L1
mov x2, 0
cntwx3
whilelo p0.s, xzr, x1
mov z0.s, #2
.L3:
st1wz0.s, p0, [x0, x2, lsl 2]
add x2, x2, x3--  may be overflow ?
whilelo p0.s, x2, x1
b.any   .L3
.L1:
ret
```

[Bug target/103628] ICE: Segmentation fault (in gfc_conv_tree_to_mpfr)

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

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

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

https://gcc.gnu.org/g:3b67db31236631432e7f6d74ed49af9ae2183a4d

commit r13-6843-g3b67db31236631432e7f6d74ed49af9ae2183a4d
Author: Haochen Gui 
Date:   Fri Mar 24 10:45:52 2023 +0800

Fortran: Escalate failure when Hollerith constant to real conversion fails

gcc/fortran/
PR target/103628
* target-memory.cc (gfc_interpret_float): Return FAIL when
native_interpret_expr gets a NULL tree.
* arith.cc (gfc_hollerith2real): Return NULL when
gfc_interpret_float fails.
* error.cc (gfc_buffered_p): Define.
* gfortran.h (gfc_buffered_p): Declare.
* intrinsic.cc: Add diagnostic.h to include list.
(do_simplify): Save errorcount and check it at finish.  Report a
"Cannot simplify expression" error on a bad result if error count
doesn't change and no other errors buffered.

gcc/testsuite/
PR target/103628
* gfortran.dg/assumed_size_refs_2.f90: Check "Cannot simplify
expression" error.
* gfortran.dg/unpack_field_1.f90: Likewise.
* gfortran.dg/pr103628.f90: New.

Co-Authored-By: Tobias Burnus 

[Bug c++/109268] Guard variable still provided for static constinit variable

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
It is the deconstructor which is causing the need for the guard variable.
Very much related to PR 19661 .

[Bug c++/109268] Guard variable still provided for static constinit variable

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization

[Bug c++/109268] New: Guard variable still provided for static constinit variable

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

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

Bug ID: 109268
   Summary: Guard variable still provided for static constinit
variable
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

This program: 

struct X {
constexpr X() { }
constexpr ~X() { }
};

int main()
{
static constinit X data;
}

compiled on gcc trunk with -std=c++2b -O3 emits:

X::~X() [base object destructor]:
ret
main:
movzx   eax, BYTE PTR guard variable for main::data[rip]
testal, al
je  .L14
xor eax, eax
ret
.L14:
pushrcx
mov edi, OFFSET FLAT:guard variable for main::data
call__cxa_guard_acquire
testeax, eax
jne .L15
.L5:
xor eax, eax
pop rdx
ret
.L15:
mov edx, OFFSET FLAT:__dso_handle
mov esi, OFFSET FLAT:_ZZ4mainE4data
mov edi, OFFSET FLAT:_ZN1XD1Ev
call__cxa_atexit
mov edi, OFFSET FLAT:guard variable for main::data
call__cxa_guard_release
jmp .L5

But data is constant-initialized (enforced by constinit), so there shouldn't be
a need for a guard variable in this context? clang does not generate one in
this case.

[Bug c++/109267] -Og generates empty functions with .cfi_startproc/.cfi_endproc that conflict with other functions

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #3 from Andrew Pinski  ---
Actually I missed -DNDEBUG. But again clang produces the same bad assembly too.

[Bug c++/109267] -Og generates empty functions with .cfi_startproc/.cfi_endproc that conflict with other functions

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-03-23
 Status|UNCONFIRMED |WAITING

--- Comment #2 from Andrew Pinski  ---
The only time you get an empty function is for:
void f(){__builtin_unreachable();}

Which does produce:
_Z1fv:
.LFB0:
.file 1 "/app/example.cpp"
.loc 1 1 9 view -0
.cfi_startproc
.loc 1 1 10 view .LVU1
.cfi_endproc

clang even produces a similar thing for that too:
_Z1fv:  # @_Z1fv
.Lfunc_begin0:
.cfi_startproc
# %bb.0:
.Lfunc_end0:
.size   _Z1fv, .Lfunc_end0-_Z1fv
.cfi_endproc

Can you attach the preprocessed source for the lib.cpp?

[Bug c++/109267] -Og generates empty functions with .cfi_startproc/.cfi_endproc that conflict with other functions

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://github.com/llvm/llv
   ||m-project/issues/61434

--- Comment #1 from Andrew Pinski  ---
The functions are not empty as far as I can tell:
.type  
_ZN5boost6detail7variant22visitation_impl_invokeINS1_14invoke_visitorINS1_15result_wrapper1IZ4testRKNS_7variantINS1_14recursive_flagI5Obj_1EEJ5Obj_2UlRKT_E_SC_EELb0EEEPKvNSA_18has_fallback_type_EEENSD_11result_typeEiRSD_T0_PNS1_22apply_visitor_unrolledET1_l,
@function
_ZN5boost6detail7variant22visitation_impl_invokeINS1_14invoke_visitorINS1_15result_wrapper1IZ4testRKNS_7variantINS1_14recursive_flagI5Obj_1EEJ5Obj_2UlRKT_E_SC_EELb0EEEPKvNSA_18has_fallback_type_EEENSD_11result_typeEiRSD_T0_PNS1_22apply_visitor_unrolledET1_l:
.LFB3869:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
call_ZN5boost6detail7variant13forced_returnIvEET_v
.cfi_endproc
.LFE3869:
.size  
_ZN5boost6detail7variant22visitation_impl_invokeINS1_14invoke_visitorINS1_15result_wrapper1IZ4testRKNS_7variantINS1_14recursive_flagI5Obj_1EEJ5Obj_2UlRKT_E_SC_EELb0EEEPKvNSA_18has_fallback_type_EEENSD_11result_typeEiRSD_T0_PNS1_22apply_visitor_unrolledET1_l,
.-_ZN5boost6detail7variant22visitation_impl_invokeINS1_14invoke_visitorINS1_15result_wrapper1IZ4testRKNS_7variantINS1_14recursive_flagI5Obj_1EEJ5Obj_2UlRKT_E_SC_EELb0EEEPKvNSA_18has_fallback_type_EEENSD_11result_typeEiRSD_T0_PNS1_22apply_visitor_unrolledET1_l



What version of boost is being used?

[Bug c++/109267] New: -Og generates empty functions with .cfi_startproc/.cfi_endproc that conflict with other functions

[i at maskray dot me via Gcc-bugs]

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

Bug ID: 109267
   Summary: -Og generates empty functions with
.cfi_startproc/.cfi_endproc that conflict with other
functions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i at maskray dot me
  Target Milestone: ---

cat > lib.cpp <<'eof'
#include "lib.h"
#include 

void test(const T_value& entry_value) {
boost::apply_visitor([](const auto& value) { test(value); },
 entry_value);
}
void test(const Obj_1& ) {
throw std::runtime_error("Obj_1");
}
void test(const Obj_2& ) {
throw std::runtime_error("Obj_2");
}
eof
cat > lib.h <<'eof'
#pragma once

#include 

struct Obj_1 {
  int i;
};
struct Obj_2 {
  int i;
};

using T_value = boost::make_recursive_variant<
Obj_1,
Obj_2>::type;
void test(const T_value&);
void test(const Obj_2&);
void test(const Obj_1&);
eof
cat > main.cpp <<'eof'
#include "lib.h"
#include 

int main() {
try {
test(Obj_2{2});

} catch (const std::runtime_error& e) {
}
try {
test(Obj_1{1});

} catch (const std::runtime_error& e) {
}
} 
eof

g++ -isystem /usr/include/boost -Og -g -DNDEBUG -S lib.cpp main.cpp
g++ -isystem /usr/include/boost -Og -g -DNDEBUG -fuse-ld=lld lib.cpp main.cpp
return

lib.s has unusual empty functions with .cfi_startproc/.cfi_endproc . I think
this behavior is incorrect since CFI FDE associated to the empty functions may
conflict with FDE of another function.
When linking with GNU ld, GNU ld drops FDE associated to the empty functions,
and therefore the output executable will be correct.
However, I think linkers are not obliged to behave like GNU ld. ld.lld doesn't
discard FDE associated to the empty functions, and the output executable will
call std::terminate.

```
% ./a.out
terminate called after throwing an instance of 'std::runtime_error'
  what():  Obj_1
[1]2826366 IOT instruction  ./a.out
```

-O1/-O2/-O3 discard such empty functions to avoid the problem. In -O0 codegen,
the function becomes non-empty, avoiding the problem as well.

```
% g++ -isystem /usr/include/boost -Og -g -DNDEBUG -S lib.cpp -o - | grep
11result_typeEiRSD_T0_PNS1_22apply_visitor_unrolledET1_l
.type  
_ZN5boost6detail7variant22visitation_impl_invokeINS1_14invoke_visitorINS1_15result_wrapper1IZ4testRKNS_7variantINS1_14recursive_flagI5Obj_1EEJ5Obj_2UlRKT_E_SC_EELb0EEEPKvNSA_18has_fallback_type_EEENSD_11result_typeEiRSD_T0_PNS1_22apply_visitor_unrolledET1_l,
@function
_ZN5boost6detail7variant22visitation_impl_invokeINS1_14invoke_visitorINS1_15result_wrapper1IZ4testRKNS_7variantINS1_14recursive_flagI5Obj_1EEJ5Obj_2UlRKT_E_SC_EELb0EEEPKvNSA_18has_fallback_type_EEENSD_11result_typeEiRSD_T0_PNS1_22apply_visitor_unrolledET1_l:
.size  
_ZN5boost6detail7variant22visitation_impl_invokeINS1_14invoke_visitorINS1_15result_wrapper1IZ4testRKNS_7variantINS1_14recursive_flagI5Obj_1EEJ5Obj_2UlRKT_E_SC_EELb0EEEPKvNSA_18has_fallback_type_EEENSD_11result_typeEiRSD_T0_PNS1_22apply_visitor_unrolledET1_l,
.-_ZN5boost6detail7variant22visitation_impl_invokeINS1_14invoke_visitorINS1_15result_wrapper1IZ4testRKNS_7variantINS1_14recursive_flagI5Obj_1EEJ5Obj_2UlRKT_E_SC_EELb0EEEPKvNSA_18has_fallback_type_EEENSD_11result_typeEiRSD_T0_PNS1_22apply_visitor_unrolledET1_l
% g++ -isystem /usr/include/boost -O1 -g -DNDEBUG -S lib.cpp -o - | grep
11result_typeEiRSD_T0_PNS1_22apply_visitor_unrolledET1_l
% g++ -isystem /usr/include/boost -O2 -g -DNDEBUG -S lib.cpp -o - | grep
11result_typeEiRSD_T0_PNS1_22apply_visitor_unrolledET1_l
% g++ -isystem /usr/include/boost -O3 -g -DNDEBUG -S lib.cpp -o - | grep
11result_typeEiRSD_T0_PNS1_22apply_visitor_unrolledET1_l
```

Link: https://github.com/llvm/llvm-project/issues/61434

[Bug tree-optimization/108915] invalid pointer access preserved in optimized code

[hiraditya at msn dot com via Gcc-bugs]

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

--- Comment #6 from AK  ---
For reference, I had opened a related bug in clang:
https://github.com/llvm/llvm-project/issues/60967

[Bug analyzer/109266] New: Wanalyzer-null-dereference does not warn when struct is at null

[jg at jguk dot org via Gcc-bugs]

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

Bug ID: 109266
   Summary: Wanalyzer-null-dereference does not warn when struct
is at null
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

Couldn't find an existing report for this.
Hope the very useful Analyzer can be enhanced to handle nullptr for structs.
Which means that when reading members of the struct they might be at 0x4 etc,
not directly 0x0

Analyzer does detect if the first 'int' in this struct at address nullptr is
read. If the code reads the bytes after in the struct, it doesn't identify that
0x4 address is also inaccessible.

Only way to ensure to get a warning is to copy the struct to a local variable
(before reading those bytes at offset 0x4 from the copy).

Try it live:
https://godbolt.org/z/9a611jvfM

-fanalyzer -Wall -O2

typedef struct a
{
int b;
char c[3];
} a_t;

void f(a_t * s)
{
//s->b = 0;
s->c[0] = 'b';
}

int main()
{
a_t * s = nullptr;
f(s);
}

[Bug c++/105481] [10/11/12/13 Regression] ICE: unexpected expression of kind template_parm_index

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/105996] [10/11/12/13 Regression] reinterpret_cast in constexpr failure creating a pair with a function pointer of class parent

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

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

--- Comment #5 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r13-6840-gc4792bd1de0621932a47fb86aca09fafafdb2972
Author: Jason Merrill 
Date:   Thu Mar 23 16:50:09 2023 -0400

c++: constexpr PMF conversion [PR105996]

Here, we were calling build_reinterpret_cast regardless of whether there
was
actually a cast, and that now sets REINTERPRET_CAST_P.  But that
optimization seems dodgy anyway, as it involves NOP_EXPR from one
RECORD_TYPE to another and we try to reserve NOP_EXPR for fundamental
types.
And the generated code seems the same, so let's drop it.  And also strip
location wrappers.

PR c++/105996

gcc/cp/ChangeLog:

* typeck.cc (build_ptrmemfunc): Drop 0-offset optimization
and location wrappers.

gcc/testsuite/ChangeLog:

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

[Bug c++/105996] [10/11/12/13 Regression] reinterpret_cast in constexpr failure creating a pair with a function pointer of class parent

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/109260] -fdump-ada-spec does not support C++ namespaces

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

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

--- Comment #2 from Andrew Pinski  ---
https://gcc.gnu.org/onlinedocs/gnat_ugn/Interfacing-with-C_002b_002b-at-the-Class-Level.html#Interfacing-with-C_002b_002b-at-the-Class-Level

[Bug c++/109260] -fdump-ada-spec does not support C++ namespaces

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

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

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/onlinedocs/gnat_ugn/Generating-Bindings-for-C_002b_002b-Headers.html#Generating-Bindings-for-C_002b_002b-Headers

https://gcc.gnu.org/onlinedocs/gnat_ugn/Interfacing-to-C_002b_002b.html#Interfacing-to-C_002b_002b

I think this is all by design this way. Since it is hard to get the mangled
names and all.

[Bug c++/109247] [13 Regression] optional o; o = {x}; wants to use explicit optional(U) constructor since r13-6765-ga226590fefb35ed6

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

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

--- Comment #7 from Jason Merrill  ---
Created attachment 54739
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54739=edit
possible patch

An implementation of my guess at the clang rule, if we end up wanting to go
that way.

[Bug c++/107163] [10/11/12/13 Regression] huge Compile time increase when using templated base classes, virtual method, and Wall since r10-2823-g6a07489267e55084

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
This isn't specific to virtual functions; the same slowdown can be seen with

struct BaseType  {
  int i;
};

template< int Seq >
class DerivedType : public DerivedType< Seq - 1 > { };

template<>
class DerivedType< -1 > : public BaseType { };

int main() {
  DerivedType< COUNT > d;
  d.i = 42;
}

The reference to the base member is represented with a long sequence of
COMPONENT_REFs, like
d.derived<5>.derived<4>.derived<3>.derived<2>.derived<1>.derived<0>.derived<-1>.base.i
= 42

and with r10-2823 we check sequence points across each of those .s, with high
algorithmic complexity.  Checking across COMPONENT_REF seems unnecessary, since
it just selects a subobject of the LHS, there's no additional evaluation.

[Bug middle-end/21161] [10/11/12/13 Regression] "clobbered by longjmp" warning ignores the data flow

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

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

--- Comment #25 from Andrew Pinski  ---
(In reply to Peter Bergner from comment #14)

For the testcase in comment #14, we don't get a warning since GCC 7 but the
original testcase we still get a warning on the trunk.
I have not looked into why though.

[Bug middle-end/109265] [13 Regression] ICE for 527.cam4_r after r13-6787-g0963cb5fde158c

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE for 527.cam4_r after|[13 Regression] ICE for
   |r13-6787-g0963cb5fde158c|527.cam4_r after
   ||r13-6787-g0963cb5fde158c
   Keywords||ice-on-valid-code,
   ||needs-reduction
   Target Milestone|--- |13.0

[Bug tree-optimization/109238] [13 Regression] tst-realloc.i:42:19: error: pointer ‘p’ may be used after ‘realloc’ [-Werror=use-after-free] in glibc tests

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Reduced testcase:
/* PR tree-optimization/10923 */
/* { dg-do compile } */
/* { dg-options "-O2 -Wall" } */

void foo (void) __attribute__((noreturn));
void bar (void *);

void
baz (void *p)
{
  void *c = __builtin_realloc (p, 16);
  if (c)
foo ();
  for (;;)
bar (__builtin_realloc (p, 8)); /* { dg-bogus "pointer 'p' may be used
after '__builtin_realloc'" } */
}

[Bug libstdc++/103387] powerpc64le: segmentation fault on std::cout with ieee128 long double variable

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

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

Peter Bergner  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org

--- Comment #5 from Peter Bergner  ---
I think this is fixed now due to Jonathan's fix for PR100912, correct?


bergner@ltcden2-lp1:PR103387$ cat foo.cc 
#include 

int main()
{
long double n = 0.1L;
std::cout << n << std::endl;
return 0;
}

bergner@ltcden2-lp1:PR103387$
/home/bergner/gcc/install/gcc-fsf-mainline-base/bin/g++
-L/home/bergner/gcc/install/gcc-fsf-mainline-base/lib64
-R/home/bergner/gcc/install/gcc-fsf-mainline-base/lib64 -mabi=ibmlongdouble
foo.cc 
bergner@ltcden2-lp1:PR103387$ ./a.out 
0.1

So can we mark this P1 bug as RESOLVED/FIXED?

[Bug c++/105229] [11/12/13 Regression] ICE in lookup_template_class_1, at cp/pt.cc:10111

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
  Known to fail||12.1.0
  Known to work||12.2.0, 13.0

--- Comment #3 from Andrew Pinski  ---
Seems fixed for GCC 12.2.0 and the trunk.

[Bug target/100955] varargs causes extra stores to/from stack

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-03-23
Version|12.0|13.0

--- Comment #1 from Xi Ruoyao  ---
This is happening on many ports (see https://godbolt.org/z/n1YqWq9c9) and it
seems not trivial to fix.  stdarg pass already checks if the va_list escapes,
and if not we should avoid saving the register onto the stack if possible.  But
currently there seems no way to take this opportunity in target code
(TARGET_SETUP_INCOMING_VARARGS mandates a store on stack and disallows to use
registers instead of stack).

[Bug c++/109247] [13 Regression] optional o; o = {x}; wants to use explicit optional(U) constructor since r13-6765-ga226590fefb35ed6

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

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|SUSPENDED
   Priority|P1  |P3

--- Comment #6 from Jason Merrill  ---
Suspending for now.

[Bug c++/109247] [13 Regression] optional o; o = {x}; wants to use explicit optional(U) constructor since r13-6765-ga226590fefb35ed6

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
(In reply to Patrick Palka from comment #4)
> Oops, this testcase from PR84849 might be strictly speaking invalid and GCC
> correct to reject.  Is this PR not invalid for the same reason?

Indeed, this seems to be a template form of CWG1228, and thus ill-formed.  But
it was accepted by GCC 9-12 and is also accepted by MSVC, EDG, and Clang, so I
wonder if the committee wants to adjust the standard to match the
implementations; I've asked.

But webkit should probably fix their code anyway, perhaps by changing 

 m_brush = {setPattern_pattern};

to

 m_brush = Brush{setPattern_pattern};

[Bug fortran/108961] Segfault when associating to pointer from C_F_POINTER

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

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

Paul Thomas  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||pault at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Blocks||87477
   Last reconfirmed||2023-03-23

--- Comment #2 from Paul Thomas  ---
Good catch. Thanks for the report.

Paul


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
[Bug 87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

[Bug lto/109263] [10/11/12/13 Regression] '-g0 -ggdb -flto' gives linker error

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|'-g0 -ggdb -flto' gives |[10/11/12/13 Regression]
   |linker error|'-g0 -ggdb -flto' gives
   ||linker error
   Target Milestone|--- |10.5
   Keywords||link-failure

[Bug target/109137] [12 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2023-03-23
Summary|[12/13 regression]  |[12 regression] Compiling
   |Compiling ffmpeg with -m32  |ffmpeg with -m32 on
   |on x86_64-pc-linux-gnu  |x86_64-pc-linux-gnu hangs
   |hangs on|on libavcodec/h264_cabac.c
   |libavcodec/h264_cabac.c |since
   |since   |r12-9086-g489c81db7d4f75
   |r12-9086-g489c81db7d4f75|
 Ever confirmed|0   |1
 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #18 from Jakub Jelinek  ---
Actually, only fixed on the trunk so far.
But on 12 branch as discussed I think we should instead revert the zen1-3
changes and only keep zen4.

[Bug tree-optimization/101150] [11/12/13 Regression] null pointer dereference false positive disappears when compiling an additional function

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
  Known to work||13.0

--- Comment #5 from Andrew Pinski  ---
On the trunk, the warning is gone so is the missed optimization mentioned in
comment #1.

We do have another missed optimization though:
  _12 = _9 - _15;
  _7 = _12 /[ex] 4;
  _18 = (long unsigned int) _7;
  _120 = _18 != 0;
  _54 = _12 != 0;
  _127 = _54 & _120;
  if (_127 != 0)
goto ; [16.50%]
  else
goto ; [83.50%]
...
   [local count: 98623186]:
  if (_9 != _15)
goto ; [89.00%]
  else
goto ; [11.00%]

Only one of those comparisons is actually needed. and then another missing jump
threading because _9 be equal _15 on the goto  branch.

[Bug tree-optimization/99739] [11/12 Regression] missing optimization of a repeated conditional

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
r13-1268-g8c99e307b20c502e55c4258

[Bug tree-optimization/99739] [11/12 Regression] missing optimization of a repeated conditional

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||13.0
   Keywords||needs-bisection
Summary|[11/12/13 Regression]   |[11/12 Regression] missing
   |missing optimization of a   |optimization of a repeated
   |repeated conditional|conditional

--- Comment #5 from Andrew Pinski  ---
This seems to have been fixed on the trunk ... It would be a nice idea to see
what fixed it.
Note dom3 is able to figure out they are the same.

[Bug tree-optimization/109238] [13 Regression] tst-realloc.i:42:19: error: pointer ‘p’ may be used after ‘realloc’ [-Werror=use-after-free] in glibc tests

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #6 from Andrew Macleod  ---
Created attachment 54738
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54738=edit
Patch to fix the issue

Ah, sorry I missed that.

OK, I traced it through. The problem turns out to be in the dom_resolve code.
when we are trying to pick up a value via dominators, we walk the dominator
chain looking for outgoing edges which change the value and/or existing values.
 As we find these values, will fill the on-entry cache so that future queries
will be faster.

When we encounter a dominator node that has multiple incoming edges, as BB 33
does, we separately ask for a "quick" read-only fill and accumulate each
incoming edges values.  this allows us to pick up things where ranges are
adjusted on edges from non-dominator block ie

bb2:
   if (foo)
 if (a < 10) goto A: else goto B;
   else
 if (a >= 10) goto C:  else goto A:
   
   goto D:
A:

Block A's dominator is bb2.  It has 2 predecessors however, and on each of
those incoming edges, a has a range of [0, 10].

So by querying the outgoing range of a on each predecessor we come up with
[0,10] for a range of A, which would not be possible simply by examining the
dominator itself.

This query is done in a read-only mode so we dont go polluting the cache with a
bunch of things we may not need.  Anyway, it all works swimmingly.  usually.

What happened in this case is BB 33 has 2 predecessors. BB 28 and BB 32.
The edge from BB28 correctly picked up the range of ~[0,0], but the query for
BB32 went wrong.  BB32 is a back edge, and the query leads back to BB 33, and
in read only mode, we do not deal with these multiple incoming edges.. (and it
avoids an infinite loop).. so that query bails, and we end up with VARYING. 
that is what was generating the confusing output:

CACHE: BB 32 DOM query for c_24, found [irange] unsigned char * VARYING at BB28
CACHE: Range for DOM returns : [irange] unsigned char * VARYING
CACHE: Range for DOM returns : [irange] unsigned char * VARYING

When we are doing this inferior DOM query in read-only like this like this, we
do not need to incorporate anything from a back edge. Its intended to be
pulling a value from dominators, and there is no additional information on that
edge.  Any values from that edge can only be subsets of what the other incoming
edges have, and with the results being unioned... its pointless.

I have not yet managed to produce a reduced testcase.

[Bug c++/96437] [10/11/12 Regression] ICE in tree check: expected tree that contains ‘decl common’ structure, have ‘error_mark’ in synthesize_implicit_template_parm, at cp/parser.c:44246

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||hewillk at gmail dot com

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

[Bug c++/99659] [10/11/12/13 Regression] internal compiler error: tree check: expected tree that contains 'decl common' structure, have 'error_mark' in synthesize_implicit_template_parm, at cp/parser.

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #4 from Andrew Pinski  ---
Dup of bug 96437.

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

[Bug c/84900] [10/11/12/13 Regression] cast of compound literal does not cause the code to become a non-lvalue

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|10.5|13.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Andrew Pinski  ---
Fixed for GCC 13. This has been broken since GCC 4.5 almost 14 years ago and
since it is just an accepts invalid I am going to close it as fixed for GCC 13.

[Bug c/84900] [10/11/12/13 Regression] cast of compound literal does not cause the code to become a non-lvalue

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

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

--- Comment #9 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:80ed2a6471a39dd95192a334789fd63d5efd2e8a

commit r13-6836-g80ed2a6471a39dd95192a334789fd63d5efd2e8a
Author: Andrew Pinski 
Date:   Thu Mar 23 02:10:11 2023 +

c: [PR84900] cast of compound literal does not cause the code to become a
non-lvalue

The problem here is after r0-92187-g2ec5deb5c3146c, maybe_lvalue_p would
return false for compound literals which causes non_lvalue_loc not
to wrap the expression with a NON_LVALUE_EXPR unlike before when it
return true as it returns true for all language specific tree codes.

This fixes that oversight and fixes the testcase to have the cast as
a non-lvalue.

Committed to the trunk as obvious after a bootstrap/test on
x86_64-linux-gnu.

PR c/84900

gcc/ChangeLog:

* fold-const.cc (maybe_lvalue_p): Treat COMPOUND_LITERAL_EXPR
as a lvalue.

gcc/testsuite/ChangeLog:

* gcc.dg/compound-literal-cast-lvalue-1.c: New test.

[Bug middle-end/109265] ICE for 527.cam4_r after r13-6787-g0963cb5fde158c

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

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

--- Comment #1 from Jakub Jelinek  ---
I think one way is to include all the needed modules by hand into the same
*.f90 source
(for each module, find in which source file it is defined and copy the module
... end module stuff) and repeat until you have it all.
Another one is try multi-file delta or the script from
https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction

[Bug target/109254] Bug in gcc (13.0.1) support for ARM SVE, which randomly modifies the prediction register

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

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

--- Comment #4 from Jakub Jelinek  ---
And
--- gcc/config/aarch64/aarch64.cc.jj2023-03-13 00:11:52.328213351 +0100
+++ gcc/config/aarch64/aarch64.cc   2023-03-23 16:57:29.957866005 +0100
@@ -7388,6 +7388,9 @@ aarch64_function_value_regno_p (const un
   if (regno >= V0_REGNUM && regno < V0_REGNUM + HA_MAX_NUM_FLDS)
 return TARGET_FLOAT;

+  if (regno == P0_REGNUM)
+return TARGET_SVE;
+
   return false;
 }

Or can one actually return in more than p0?  Tried struct S { svbool_t a, b; };
but that is rejected...

[Bug modula2/109264] Compiler hangs trying to resolve opaque type

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

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

[Bug modula2/109264] Compiler hangs trying to resolve opaque type

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Gaius Mulley :

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

commit r13-6835-g5ededfa5b23781c3be6fcf6bb373418aa8bd6541
Author: Gaius Mulley 
Date:   Thu Mar 23 16:37:11 2023 +

PR modula2/109264 Bugfix resolve opaque types containing sets

Resolve opaque type handling.  The bug is caused by the compiler
attempting to resolve the meta types of a constant constructor.
It incorrectly attempts to get the type on an enumeration type
(resulting in NulSym) which causes the meta resolver to spin.
Some PHBuild rules (building records need to be copied from P3Build
so that hidden types are resolved in order across the compile.

gcc/m2/ChangeLog:

PR modula2/109264
* gm2-compiler/M2Quads.mod (BuildConstFunctionCall): Comment
out ErrorString in debugging block.
(BuildConstructorStart): Replace Assert with a call to
MetaErrorT3.  Import MetaErrorT3.
* gm2-compiler/PCSymBuild.mod (buildConstFunction): Rename
local variables.
(WalkFunctionParam): Remove test for IsEnumeration when
resolving MIN or MAX parameters.
* gm2-compiler/PHBuild.bnf (BlockAssert): New procedure.
(ErrorArrayat): New procedure.
(Expect): Renamed parameter t to tok.
(PushQualident): New rule.
(ConstSetOrQualidentOrFunction): Force AutoOn.
(TypeDeclaration): Add debugging assert.
(SimpleType): Add debugging assert.
(DefaultRecordAttributes): New rule (and bugfix).
(FieldPragmaExpression): New rule (and bugfix).
(PragmaConstExpression): New rule (and bugfix).
(SetOrDesignatorOrFunction): Add debugging assert.
(Block): Add debugging assert.
* gm2-gcc/m2expr.cc (m2expr_ConstantExpressionWarning): int
to bool.
* gm2-gcc/m2expr.h (m2expr_TreeOverflow): int to bool.
(m2expr_GetBooleanTrue): Remove.
(m2expr_GetBooleanFalse): Remove.
* gm2-gcc/m2options.h (M2Options_SetStatistics): Replace
int with bool.

gcc/testsuite/ChangeLog:

PR modula2/109264
* gm2/iso/extended-opaque/pass/iso-extended-opaque-pass.exp:
New test.
* gm2/iso/extended-opaque/pass/stressset.def: New test.
* gm2/iso/extended-opaque/pass/stressset.mod: New test.
* gm2/iso/extended-opaque/pass/testset.mod: New test.
* gm2/projects/iso/small/run/pass/iso-extended-opaque-run-pass.exp:
New test.
* gm2/projects/iso/small/run/pass/stressset.def: New test.
* gm2/projects/iso/small/run/pass/stressset.mod: New test.
* gm2/projects/iso/small/run/pass/test1.mod: New test.
* gm2/projects/iso/small/run/pass/testlib.def: New test.
* gm2/projects/iso/small/run/pass/testlib.mod: New test.
* gm2/projects/iso/small/run/pass/testset.mod: New test.

Signed-off-by: Gaius Mulley 

[Bug target/109257] `-masm=intel` generates weird syntax for indirect jumps

[lh_mouse at 126 dot com via Gcc-bugs]

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

--- Comment #5 from LIU Hao  ---
(In reply to jbeulich from comment #4)
> Being as compatible as possible with MASM has been the primary goal of
> supporting Intel syntax. Intel's SDM doesn't specify complete assembly
> language; it serves as a reference where possible/sensible.

GAS may accept it at any cost but GCC should not generate it. This is an issue
about GCC, not GAS.

[Bug target/104713] gcc does not reject -march=i686 -fcf-protection

[jay+ggcc--- via Gcc-bugs]

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

--- Comment #8 from James Addison  ---
(In reply to James Addison from comment #7)
> (In reply to Adrian Bunk from comment #6)
> > (In reply to James Addison from comment #5)
> > > Could the findings indicate that there are two bugs here?
> > > 
> > >   - The Geode LX target capable of supporting fcf-protection but GCC-11
> > > currently rejects that architecture and flag combination
> > 
> > The problem is the opposite.
> 
> Ok, thank you.
> 
> Something that's unclear to me is whether fcf-protection requires NOPL
> (multi-byte NOP).  I understand that it requires endbr32.
> 
> Was my second statement (re: GCC-11 emitting NOPL for i686) correct?

I haven't been able to replicate generation of NOPL instructions using GCC-11
(with GNU binutils); my apologies for the distraction.

[Bug target/109257] `-masm=intel` generates weird syntax for indirect jumps

[jbeulich at suse dot com via Gcc-bugs]

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

--- Comment #4 from jbeulich at suse dot com ---
(In reply to LIU Hao from comment #3)
> (In reply to jbeulich from comment #2)
> > Sure, but there's no reason for gas to not accept what MASM would. You also
> > don't really make clear why you think this is an issue, and hence why it
> > should be changed in gcc.
> 
> Why not? The syntax is invalid because Intel software developer manual has
> no reference to such construction. The fact that MASM would accept it
> doesn't render it valid.

Being as compatible as possible with MASM has been the primary goal of
supporting Intel syntax. Intel's SDM doesn't specify complete assembly
language; it serves as a reference where possible/sensible.

[Bug target/109137] [12/13 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #17 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596

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

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

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

https://gcc.gnu.org/g:41ade3399bd1ec9927be1bb818965831232eda4b

commit r13-6834-g41ade3399bd1ec9927be1bb818965831232eda4b
Author: Richard Biener 
Date:   Thu Mar 23 14:52:01 2023 +0100

tree-optimization/107569 - avoid wrecking earlier folding in FRE/PRE

The following avoids picking up dead code left over from folding
during FRE/PRE, effectively undoing propagations.

PR tree-optimization/107569
* tree-ssa-sccvn.cc (eliminate_dom_walker::eliminate_stmt):
Do not push SSA names with zero uses as available leader.
(process_bb): Likewise.

* g++.dg/opt/pr107569.C: New testcase.

[Bug target/109257] `-masm=intel` generates weird syntax for indirect jumps

[lh_mouse at 126 dot com via Gcc-bugs]

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

--- Comment #3 from LIU Hao  ---
(In reply to jbeulich from comment #2)
> Sure, but there's no reason for gas to not accept what MASM would. You also
> don't really make clear why you think this is an issue, and hence why it
> should be changed in gcc.

Why not? The syntax is invalid because Intel software developer manual has no
reference to such construction. The fact that MASM would accept it doesn't
render it valid.


> > The `foo[rip]` part is also invalid but it's a common issue for all
> > addressing operands for x86_64, not specifically about jmp.
> 
> Why's that invalid? foo[eax] and [foo+eax] have always been equivalent in
> MASM, and I see no reason why this shouldn't hold for rip-relative
> addressing as well.

Ok that's fine, just not intuitive. I wouldn't argue on this.

[Bug target/109253] libbpf: failed to find BTF info for global/extern symbol '__divdi3'

[david.faust at oracle dot com via Gcc-bugs]

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

--- Comment #1 from David Faust  ---
See:
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608152.html

Also related as Andrew pointed out in the above thread:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783

[Bug target/109254] Bug in gcc (13.0.1) support for ARM SVE, which randomly modifies the prediction register

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

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

--- Comment #3 from Jakub Jelinek  ---
2023-03-23  Jakub Jelinek  

PR target/109254
* config/aarch64/aarch64.cc (aarch64_function_arg_regno_p): Also
return true for p0-p3.

--- gcc/config/aarch64/aarch64.cc.jj2023-03-13 00:11:52.328213351 +0100
+++ gcc/config/aarch64/aarch64.cc   2023-03-23 16:57:29.957866005 +0100
@@ -7959,7 +7959,8 @@ bool
 aarch64_function_arg_regno_p (unsigned regno)
 {
   return ((GP_REGNUM_P (regno) && regno < R0_REGNUM + NUM_ARG_REGS)
- || (FP_REGNUM_P (regno) && regno < V0_REGNUM + NUM_FP_ARG_REGS));
+ || (FP_REGNUM_P (regno) && regno < V0_REGNUM + NUM_FP_ARG_REGS)
+ || (PR_REGNUM_P (regno) && regno < P0_REGNUM + NUM_PR_ARG_REGS));
 }

 /* Implement FUNCTION_ARG_BOUNDARY.  Every parameter gets at least

fixes this.  Or do we want to return true for p0-p3 only if SVE is enabled?
Not familiar with SVE enough to turn the testcase into gcc.target/aarch64/sve
runtime tests (bet we need __attribute__((noipa)) on the function, but unsure
how to initialize the arguments in the caller and how to verify the result is
correct in it after the call.

[Bug lto/109263] '-g0 -ggdb -flto' gives linker error

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
So we stream -g in .lto_options and we do have early LTO debug.  But then
nothing combines -g0 -ggdb in the driver so lto-wrapper also sees -g0
and thinks that will prevail, setting skip_debug to true.

Unfortunately -ggdb isn't just -g with "gdb" as arg but an entirely separate
option.

Interestingly -gno-dwarf enables debug info as well.

[Bug target/108927] error: too few arguments to function 'long unsigned int __riscv_vsetvlmax_e8mf8(void)'

[malat at debian dot org via Gcc-bugs]

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

Mathieu Malaterre  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||kito at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #5 from Mathieu Malaterre  ---
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f8ba8a45edcff7fe117f88deff7184dffe3af311

[Bug middle-end/109265] New: ICE for 527.cam4_r after r13-6787-g0963cb5fde158c

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

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

Bug ID: 109265
   Summary: ICE for 527.cam4_r after r13-6787-g0963cb5fde158c
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at linux dot ibm.com
  Target Milestone: ---

$ gfortran -c -o sgexx.fppized.o -I. -Iinclude -Inetcdf/include -O3 -std=legacy
-fconvert=big-endian sgexx.F90
during GIMPLE pass: dom
sgexx.F90:8996:23:

 8996 |   SUBROUTINE SLAMC2( BETA, T, RND, EPS, EMIN, RMIN, EMAX, RMAX )
  |   ^
internal compiler error: in in_chain_p, at gimple-range-gori.cc:119
0x24e31cf range_def_chain::in_chain_p(tree_node*, tree_node*)
/devel/gcc/src/gcc/gimple-range-gori.cc:119
0x24e47e9 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
/devel/gcc/src/gcc/gimple-range-gori.cc:667
0x24e5b47 gori_compute::compute_operand1_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
/devel/gcc/src/gcc/gimple-range-gori.cc:1174
0x24e4739 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
/devel/gcc/src/gcc/gimple-range-gori.cc:726
0x24e6505 gori_compute::compute_operand2_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
/devel/gcc/src/gcc/gimple-range-gori.cc:1254
0x24e6a91 gori_compute::compute_operand1_and_operand2_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
/devel/gcc/src/gcc/gimple-range-gori.cc:1274
0x24e4911 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
/devel/gcc/src/gcc/gimple-range-gori.cc:723
0x24e8b75 gori_compute::outgoing_edge_range_p(vrange&, edge_def*, tree_node*,
range_query&)
/devel/gcc/src/gcc/gimple-range-gori.cc:1384
0x24d71c5 ranger_cache::edge_range(vrange&, edge_def*, tree_node*,
ranger_cache::rfd_mode)
/devel/gcc/src/gcc/gimple-range-cache.cc:964
0x24d732d ranger_cache::range_on_edge(vrange&, edge_def*, tree_node*)
/devel/gcc/src/gcc/gimple-range-cache.cc:1001
0x24df129 fold_using_range::range_of_range_op(vrange&,
gimple_range_op_handler&, fur_source&)
/devel/gcc/src/gcc/gimple-range-fold.cc:558
0x24e11c1 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
/devel/gcc/src/gcc/gimple-range-fold.cc:489
0x24e171d fold_range(vrange&, gimple*, edge_def*, range_query*)
/devel/gcc/src/gcc/gimple-range-fold.cc:326
0x24e8e03 gori_compute::outgoing_edge_range_p(vrange&, edge_def*, tree_node*,
range_query&)
/devel/gcc/src/gcc/gimple-range-gori.cc:1411
0x24d6c55 ranger_cache::range_from_dom(vrange&, tree_node*, basic_block_def*,
ranger_cache::rfd_mode)
/devel/gcc/src/gcc/gimple-range-cache.cc:1524
0x24d8e9b ranger_cache::range_from_dom(vrange&, tree_node*, basic_block_def*,
ranger_cache::rfd_mode)
/devel/gcc/src/gcc/gimple-range-cache.cc:1421
0x24d8e9b ranger_cache::fill_block_cache(tree_node*, basic_block_def*,
basic_block_def*)
/devel/gcc/src/gcc/gimple-range-cache.cc:1212
0x24d9d2f ranger_cache::block_range(vrange&, basic_block_def*, tree_node*,
bool)
/devel/gcc/src/gcc/gimple-range-cache.cc:1039
0x24cedc9 gimple_ranger::range_on_entry(vrange&, basic_block_def*, tree_node*)
/devel/gcc/src/gcc/gimple-range.cc:156
0x24d23b3 gimple_ranger::range_of_expr(vrange&, tree_node*, gimple*)
/devel/gcc/src/gcc/gimple-range.cc:130
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.

Started after r13-6787-g0963cb5fde158c

I have no experience with reducing a Fortran program. Is there an equivalent
way of -E for gfortran? Reducing via delta results in dependencies like

9 | use shr_kind_mod,only: r8 => shr_kind_r8
  | 1
Fatal Error: Cannot open module file 'shr_kind_mod.mod' for reading at (1): No
such file or directory
compilation terminated.

Currently I circumvent those errors by copying modules into my temp directory
but of course in the end I cannot upload those modules.

[Bug target/109257] `-masm=intel` generates weird syntax for indirect jumps

[jbeulich at suse dot com via Gcc-bugs]

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

--- Comment #2 from jbeulich at suse dot com ---
(In reply to LIU Hao from comment #0)
> ptc_to_foo:
> jmp [QWORD PTR foo[rip]]
> ```
> 
> The outer pair of brackets are superfluous.

Sure, but there's no reason for gas to not accept what MASM would. You also
don't really make clear why you think this is an issue, and hence why it should
be changed in gcc.

> The `foo[rip]` part is also invalid but it's a common issue for all
> addressing operands for x86_64, not specifically about jmp.

Why's that invalid? foo[eax] and [foo+eax] have always been equivalent in MASM,
and I see no reason why this shouldn't hold for rip-relative addressing as
well.

[Bug modula2/109264] Compiler hangs trying to resolve opaque type

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

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

--- Comment #2 from Gaius Mulley  ---
Created attachment 54737
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54737=edit
Proposed fix

[Bug modula2/109264] Compiler hangs trying to resolve opaque type

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

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

Gaius Mulley  changed:

   What|Removed |Added

   Last reconfirmed||2023-03-23
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from Gaius Mulley  ---
Reproduced on x86_64 and aarch64 systems.

[Bug modula2/109264] New: Compiler hangs trying to resolve opaque type

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

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

Bug ID: 109264
   Summary: Compiler hangs trying to resolve opaque type
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54736
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54736=edit
Test module which provokes the bug

gm2 hangs if it compiles a module using an opaque type whose implementation
module contains a set.  For example see attachment and the following library
files:

DEFINITION MODULE stressset ;

TYPE
   dataType ;

END stressset.

o

[Bug tree-optimization/109262] [13 Regression] ICE: verify_gimple failed (error: statement marked for throw in middle of block) since r13-6624

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

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

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

https://gcc.gnu.org/g:25979b6761516b9039004385e08141e0925e1a17

commit r13-6833-g25979b6761516b9039004385e08141e0925e1a17
Author: Richard Biener 
Date:   Thu Mar 23 15:50:59 2023 +0100

tree-optimization/109262 - ICE with non-call EH and forwprop

The recent combining of complex part loads to a complex load missed
to account for non-call EH.

PR tree-optimization/109262
* tree-ssa-forwprop.cc (pass_forwprop::execute): When
combining a piecewise complex load avoid touching loads
that throw internally.  Use fun, not cfun throughout.

* g++.dg/torture/pr109262.C: New testcase.

[Bug tree-optimization/109262] [13 Regression] ICE: verify_gimple failed (error: statement marked for throw in middle of block) since r13-6624

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[gcc-bugzilla at al42and dot me via Gcc-bugs]

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

--- Comment #29 from Andrey Alekseenko  ---
> it seems like we should treat *any* class with a reference member as a 
> reference wrapper. 

And any class with a pointer, I suspect.

This is a reduced/simplified example from our codebase still triggering the
error even with 59bfdd5f467292a368d0d628084a4b65d1bb06bb:

$ cat test.cpp 
struct ArrayRef
{
ArrayRef(int* ptr) : ptr_(ptr) {}
int& operator[](int n) const { return ptr_[n]; }
int* ptr_;
};

int main()
{
inta;
const int& r = ArrayRef()[0];
}

$ g++ -std=c++17 -Wdangling-reference test.cpp -o test
test.cpp: In function ‘int main()’:
test.cpp:11:16: warning: possibly dangling reference to a temporary
[-Wdangling-reference]
   11 | const int& r = ArrayRef()[0];
  |^
test.cpp:11:34: note: the temporary was destroyed at the end of the full
expression ‘ArrayRef((& a)).ArrayRef::operator[](0)’
   11 | const int& r = ArrayRef()[0];
  |  ^

[Bug target/65010] ppc backend generates unnecessary signed extension

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

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

Peter Bergner  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org
   Last reconfirmed|2016-01-27 00:00:00 |2023-3-23

--- Comment #12 from Peter Bergner  ---
(In reply to pthaugen from comment #11)
> Another example to clean up. The back to back constant load/sign extend
> sequence of rtl insns is created in each block by the block reordering pass
> (.bbo) duplicating the common return block.
> 
> int foo(int in)
> {
>if (in == 1)
>  return 123;
>return 0;
> }
> 
> 
> foo:
> .LFB0:
>   .cfi_startproc
>   cmpwi 0,3,1
>   beq 0,.L5
>   li 3,0
>   extsw 3,3
>   blr
>   .p2align 4,,15
> .L5:
>   li 3,123
>   extsw 3,3
>   blr

Cuurent trunk code for this is now:

foo:
cmpwi 0,3,1
beq 0,.L3
li 3,0
rldicl 3,3,0,32
blr
.p2align 4,,15
.L3:
li 3,123
rldicl 3,3,0,32
blr

It's interested that we seem to have switched from a sign extension to a zero
extension.

[Bug lto/109263] '-g0 -ggdb -flto' gives linker error

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Btw. started with r10-3107-g5a307ee54bca6386.

[Bug lto/109263] New: '-g0 -ggdb -flto' gives linker error

[lukeocamden at gmail dot com via Gcc-bugs]

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

Bug ID: 109263
   Summary: '-g0 -ggdb -flto' gives linker error
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lukeocamden at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Hello,

I have not seen this before!

$ echo 'int main() { }' | g++ -g0 -ggdb -flto -xc++ -
/usr/bin/ld: /tmp/ccgMzjuI.ltrans0.ltrans.o:(.debug_info+0x2f): undefined
reference to `g_stdin_.7138a6a3'
collect2: error: ld returned 1 exit status

$ g++ --version
g++ (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Unfortunately my build too insists on -g0 so I am using this as a workaround:

$ echo 'int main() { }' | g++ -g0 -g -ggdb -flto -xc++ -

Thanks!

[Bug target/98850] ICE in expand_debug_locations, at cfgexpand.c:5458

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Martin Liška  ---
I can confirm the package builds now with LTO enabled for gcc-13.

[Bug tree-optimization/109262] [13 Regression] ICE: verify_gimple failed (error: statement marked for throw in middle of block) since r13-6624

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||jakub at gcc dot gnu.org
Summary|[13 Regression] ICE:|[13 Regression] ICE:
   |verify_gimple failed|verify_gimple failed
   |(error: statement marked|(error: statement marked
   |for throw in middle of  |for throw in middle of
   |block)  |block) since r13-6624

--- Comment #4 from Jakub Jelinek  ---
Started with r13-6624-geb337d28c32b1b460cc85b3c00f8418ca535c77b

[Bug target/109254] Bug in gcc (13.0.1) support for ARM SVE, which randomly modifies the prediction register

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Yeah, before rnreg pass the fcmlt has p1 as destination and fsub/fsel use p0
(i.e. the parameter) while sel in between them uses p1.
I see this behavior already in r10-5107-gb789efeae8c0620b8 and shortly before
that
it has been rejected with "variable-sized object may not be initialized"
errors.

[Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596

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

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

--- Comment #49 from Jakub Jelinek  ---
Does the has_zero_uses patch work for this?  As there is both:
  _4 = _6 u> 1.79769313486231570814527423731704356798070567525844996599e+308;
  _8 = ~_4;
and _8 has_zero_uses while _4 has uses but all are dead.  So, I assume we
wouldn't try
to reuse _8 but perhaps we'd reuse _4?

[Bug tree-optimization/109262] [13 Regression] ICE: verify_gimple failed (error: statement marked for throw in middle of block)

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2023-03-23
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Likely mine.

[Bug tree-optimization/109262] [13 Regression] ICE: verify_gimple failed (error: statement marked for throw in middle of block)

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection
   Target Milestone|--- |13.0

--- Comment #2 from Richard Biener  ---
(In reply to Arseny Solokha from comment #1)
> Sadly, this is likely my final GCC PR, at least for the foreseeable future.
> I would like to thank all GCC contributors, past and present, for their
> tireless effort of keeping GCC going. It was a real joy for me to work with
> you for the last nine years. I hope I will be able to get around to my
> casual semi-automated GCC testing trifle some day in the future; till then,
> I wish you all the best guys. Thank you for all your work. Please keep GCC
> thriving for the next decade.

Thanks a lot for all your work!  It has been very much appreciated!

[Bug c++/109247] [13 Regression] optional o; o = {x}; wants to use explicit optional(U) constructor since r13-6765-ga226590fefb35ed6

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

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

--- Comment #4 from Patrick Palka  ---
(In reply to Patrick Palka from comment #3)
> PR84849 seems related, especially the comment #5 testcase from ensadc:
> 
> template
> struct in_place_type_t { explicit in_place_type_t() = default; };
> 
> struct A { };
> 
> int f(A);
> int f(in_place_type_t);
> 
> int x = f({});

Oops, this testcase from PR84849 might be strictly speaking invalid and GCC
correct to reject as per
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102247#c2.  Is this PR not invalid
for the same reason?

[Bug middle-end/41742] Unnecessary zero-extension at -O2 but not -O1

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

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

Peter Bergner  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org

--- Comment #3 from Peter Bergner  ---
Update: current code (both powerpc64-linux and powerpc64le-linux) still contain
the unneeded rlwinm, but now we've replaced the loop with a call to libc's
memset and we do not shrink-wrap the call due to the use of the non-volatile
r31 in the entry block. 

foo:
cmpdi 0,5,0
std 31,-8(1)
stdu 1,-128(1)
mr 31,3
beq 0,.L4
mflr 0
rlwinm 4,4,0,0xff
std 0,144(1)
bl memset
nop
ld 0,144(1)
mtlr 0
.L4:
addi 1,1,128
mr 3,31
ld 31,-8(1)
blr

[Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596

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

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

--- Comment #48 from Richard Biener  ---
So instead of an extra DCE pass one could try harder to not leave around dead
code after folding, for example with the following (doesn't fix the testcase
yet, all the custom folding code would need adjustments as well).  But it's
not 100% reliable and it comes at a cost even when folding isn't successful
(while we don't update stmt operands immediately, what they point to is
changed by the actual folding already).

diff --git a/gcc/tree-ssa-forwprop.cc b/gcc/tree-ssa-forwprop.cc
index e34f0888954..133619899cd 100644
--- a/gcc/tree-ssa-forwprop.cc
+++ b/gcc/tree-ssa-forwprop.cc
@@ -53,6 +53,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "cgraph.h"
 #include "tree-ssa.h"
 #include "gimple-range.h"
+#include "tree-ssa-dce.h"

 /* This pass propagates the RHS of assignment statements into use
sites of the LHS of the assignment.  It's basically a specialized
@@ -3466,6 +3467,7 @@ pass_forwprop::execute (function *fun)
   auto_vec to_remove;
   to_purge = BITMAP_ALLOC (NULL);
   bitmap need_ab_cleanup = BITMAP_ALLOC (NULL);
+  auto_bitmap simple_dce_seed;
   for (int i = 0; i < postorder_num; ++i)
 {
   gimple_stmt_iterator gsi;
@@ -3846,8 +3848,16 @@ pass_forwprop::execute (function *fun)
   && gimple_call_noreturn_p (stmt));
  changed = false;

+ auto_vec seeds;
+ use_operand_p use_p;
+ ssa_op_iter iter;
+ FOR_EACH_SSA_USE_OPERAND (use_p, orig_stmt, iter, SSA_OP_USE)
+   seeds.safe_push (SSA_NAME_VERSION (USE_FROM_PTR (use_p)));
+
  if (fold_stmt (, fwprop_ssa_val))
{
+ for (int seed : seeds)
+   bitmap_set_bit (simple_dce_seed, seed);
  changed = true;
  stmt = gsi_stmt (gsi);
  /* Cleanup the CFG if we simplified a condition to
@@ -4037,6 +4047,8 @@ pass_forwprop::execute (function *fun)
   cfg_changed |= fixup_noreturn_call (stmt);
 }

+  simple_dce_from_worklist (simple_dce_seed);
+
   cfg_changed |= gimple_purge_all_dead_eh_edges (to_purge);
   cfg_changed |= gimple_purge_all_dead_abnormal_call_edges (need_ab_cleanup);
   BITMAP_FREE (to_purge);


Another possibility is preventing FRE/PRE from picking up dead stmts, as
suggested this does fix the testcase.  The extra stmt removal is not
strictly necessary.  I'm going to test sth like this.

diff --git a/gcc/tree-ssa-sccvn.cc b/gcc/tree-ssa-sccvn.cc
index d5b081a309f..9f77b7a5647 100644
--- a/gcc/tree-ssa-sccvn.cc
+++ b/gcc/tree-ssa-sccvn.cc
@@ -6683,6 +6683,12 @@ eliminate_dom_walker::eliminate_stmt (basic_block b,
gimple_stmt_iterator *gsi)
   && DECL_HARD_REGISTER (gimple_assign_rhs1 (stmt))
   && is_global_var (gimple_assign_rhs1 (stmt)
 {
+  if (has_zero_uses (lhs))
+   {
+ to_remove.safe_push (stmt);
+ return;
+   }
+
   sprime = eliminate_avail (b, lhs);
   if (!sprime)
{
@@ -7200,7 +7206,8 @@ eliminate_dom_walker::eliminate_stmt (basic_block b,
gimple_stmt_iterator *gsi)
  continue with the next stmt above and skip this.  */
   def_operand_p defp;
   FOR_EACH_SSA_DEF_OPERAND (defp, stmt, iter, SSA_OP_DEF)
-eliminate_push_avail (b, DEF_FROM_PTR (defp));
+if (! has_zero_uses (DEF_FROM_PTR (defp)))
+  eliminate_push_avail (b, DEF_FROM_PTR (defp));
 }

 /* Perform elimination for the basic-block B during the domwalk.  */
@@ -8048,7 +8055,8 @@ process_bb (rpo_elim , basic_block bb,
/* If not eliminating, make all not already available defs
   available.  */
FOR_EACH_SSA_TREE_OPERAND (op, gsi_stmt (gsi), i, SSA_OP_DEF)
- if (! avail.eliminate_avail (bb, op))
+ if (! has_zero_uses (op)
+ && ! avail.eliminate_avail (bb, op))
avail.eliminate_push_avail (bb, op);
 }

[Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls

[broonie at kernel dot org via Gcc-bugs]

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

--- Comment #8 from Mark Brown  ---
Note that the issue was found in the Linux kernel - we were expecting to see
the BTI Cs there, it's certainly a lot simpler to work with.

[Bug c++/106040] gcc reports error in aggregate when member has explicit constructor

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ppalka at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Patrick Palka  ---
dup

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

[Bug c++/91319] Designated initializer doesn't support direct-initialization

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ldalessandro at gmail dot com

--- Comment #4 from Patrick Palka  ---
*** Bug 106040 has been marked as a duplicate of this bug. ***

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #28 from Marek Polacek  ---
Fixed some more.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

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

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

--- Comment #27 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:59bfdd5f467292a368d0d628084a4b65d1bb06bb

commit r13-6830-g59bfdd5f467292a368d0d628084a4b65d1bb06bb
Author: Marek Polacek 
Date:   Fri Mar 17 14:36:10 2023 -0400

c++: further -Wdangling-reference refinement [PR107532]

Based on ,
it seems like we should treat *any* class with a reference member
as a reference wrapper.  To suppress the warning in

  int i = 42;
  auto const& v = std::get<0>(std::tuple(i));

we have to look into base classes as well.  For std::tuple, this means
that we have to check the _Head_base subobject, which is a non-direct
base class of std::tuple.  So I've employed a DFS walk.

PR c++/107532

gcc/cp/ChangeLog:

* call.cc (class_has_reference_member_p): New.
(class_has_reference_member_p_r): New.
(reference_like_class_p): Don't look for a specific constructor.
Use a DFS walk with class_has_reference_member_p_r.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wdangling-reference11.C: New test.
* g++.dg/warn/Wdangling-reference12.C: New test.

[Bug c++/109247] [13 Regression] optional o; o = {x}; wants to use explicit optional(U) constructor since r13-6765-ga226590fefb35ed6

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=84849

--- Comment #3 from Patrick Palka  ---
PR84849 seems related, especially the comment #5 testcase from ensadc:

template
struct in_place_type_t { explicit in_place_type_t() = default; };

struct A { };

int f(A);
int f(in_place_type_t);

int x = f({});

[Bug c++/109247] [13 Regression] optional o; o = {x}; wants to use explicit optional(U) constructor since r13-6765-ga226590fefb35ed6

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

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

--- Comment #2 from Jason Merrill  ---
No templates (so it's ambiguous, but the problem is the same):

struct B { int a; };
struct C {
  explicit C (int);
  C& operator= (B);
  C& operator= (const C&);
};
void f(C x)
{
  x = { 42 };
}

[Bug target/98850] ICE in expand_debug_locations, at cfgexpand.c:5458

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

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

--- Comment #3 from Martin Liška  ---
Great, what about gcc-12 release? Please close it if it's also fine.

[Bug target/98850] ICE in expand_debug_locations, at cfgexpand.c:5458

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

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

--- Comment #2 from avieira at gcc dot gnu.org ---
I failed to reproduce it with a trunk build of arm-none-linux-gnueabihf.

[Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls

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

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||nsz at gcc dot gnu.org
 Status|NEW |WAITING

--- Comment #7 from nsz at gcc dot gnu.org ---
fixed in bfd ld 2.41 see
https://sourceware.org/bugzilla/show_bug.cgi?id=30076

we can also fix gcc to work with older ld (emit bti c in local functions), but
i don't plan to do that unless there is a reason to do so. (it increases the
emitted bti c considerably in some workloads, e.g. linux kernel, while the
linker fix is less intrusive in the common case with small binaries and no
weird section hacks).

[Bug target/98850] ICE in expand_debug_locations, at cfgexpand.c:5458

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2023-03-23
 Ever confirmed|0   |1
 CC||avieira at gcc dot gnu.org,
   ||ktkachov at gcc dot gnu.org,
   ||tnfchris at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
ARM folks: can you please test if the issue is still valid or not?

[Bug tree-optimization/109262] [13 Regression] ICE: verify_gimple failed (error: statement marked for throw in middle of block)

[asolokha at gmx dot com via Gcc-bugs]

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

--- Comment #1 from Arseny Solokha  ---
Sadly, this is likely my final GCC PR, at least for the foreseeable future. I
would like to thank all GCC contributors, past and present, for their tireless
effort of keeping GCC going. It was a real joy for me to work with you for the
last nine years. I hope I will be able to get around to my casual
semi-automated GCC testing trifle some day in the future; till then, I wish you
all the best guys. Thank you for all your work. Please keep GCC thriving for
the next decade.

[Bug tree-optimization/109262] New: [13 Regression] ICE: verify_gimple failed (error: statement marked for throw in middle of block)

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 109262
   Summary: [13 Regression] ICE: verify_gimple failed (error:
statement marked for throw in middle of block)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc 13.0.1 20230319 snapshot (g:5426ab34643d9e6502f3ee572891a03471fa33ed) ICEs
when compiling the following testcase, reduced from
gcc/testsuite/g++.dg/torture/pr88149.C, w/ -O1 -fnon-call-exceptions:

template < typename > struct au;
template < typename b > au< b > operator*(au< b >, au< b > ) {
  au< b > ax;
  ax *= p2;
  return p2;
}
template <> struct au< double > {
  double p() { return __real__ az; }
  double q() { return __imag__ az; }
  void operator*=(au ) {
_Complex bd = o.p();
__imag__ bd = o.q();
az *= bd;
  }
  _Complex az;
};
long bm, m;
au< double > h;
void bn() {
  for (long k; ;) {
au< double > br;
for (long j = 0; 0 < bm; ++j)
  au n = br * h;
  }
}

% g++-13 -O1 -fnon-call-exceptions -c a7nq8mzi.C
a7nq8mzi.C: In function 'void operator*(au, au&) [with b = double]':
a7nq8mzi.C:20:1: error: statement marked for throw in middle of block
   20 | }
  | ^
# VUSE <.MEM_1(D)>
_6 = REALPART_EXPR az>;
during GIMPLE pass: forwprop
a7nq8mzi.C:20:1: internal compiler error: verify_gimple failed
0x123bd51 verify_gimple_in_cfg(function*, bool, bool)
   
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230319/work/gcc-13-20230319/gcc/tree-cfg.cc:5648
0x1104820 execute_function_todo
   
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230319/work/gcc-13-20230319/gcc/passes.cc:2098
0x1104d8e execute_todo
   
/var/tmp/portage/sys-devel/gcc-13.0.1_p20230319/work/gcc-13-20230319/gcc/passes.cc:2152

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

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

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

--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #16 from Jakub Jelinek  ---
> Used
> PATH=/export/home/jakub/gcc-11-inst/bin:$PATH
> LD_LIBRARY_PATH=/export/home/jakub/gcc-11-inst/lib/ CC='gcc
> -L/export/home/jakub/gcc-11-inst/lib -R/export/home/jakub/gcc-11-inst/lib/'
> CXX='g++ -L/export/home/jakub/gcc-11-inst/lib
> -R/export/home/jakub/gcc-11-inst/lib/' GDC='gdc
> -L/export/home/jakub/gcc-11-inst/lib -R/export/home/jakub/gcc-11-inst/lib/'
> ../configure --prefix=/export/home/jakub/gcc-inst --enable-languages=c,c++,d
> --disable-libssp --disable-libsanitizer --disable-nls --with-gmp=/opt/csw
> --with-ld=/usr/ccs/bin/ld --without-gnu-ld --with-as=/opt/csw/bin/gas
> --with-gnu-as --with-libiconv-prefix=/opt/csw --with-mpfr=/opt/csw
> --enable-libphobos --disable-multilib --enable-obsolete
> in the end, which worked, but unfortunately I can't reproduce, gobjdump -dr
> on
> {prev-,}sparc-sun-solaris2.11/libphobos/libdruntime/rt/util/typeinfo.o
> and
> {prev-,}sparc-sun-solaris2.11/libphobos/libdruntime/rt/util/.libs/typeinfo.o
> is identical.

I haven't yet been able to reproduce the comparison failure: while last
night's trunk bootstrap with gas failed again with the typeinfo.o
comparison failure, when I try to rerun

make GDCFLAGS='-g -O2 -save-temps -fdump-tree-optimized -da'
rt/util/typeinfo.lo

in the stage 2 and stage 3 sparc-sun-solaris2.11/libphobos/libdruntime
(each time with all the stage directories restored to their
unprefixed names at the toplevel), I didn't get that difference.

Very weird: might be some memory corruption issue somewhere, influenced
by the exact environment variables used during the build e.g.  I have no
idea how to actually trace this down, though.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

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

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

--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #15 from Jakub Jelinek  ---
> So, after installing gcc 11 I've tried
[...]
> Undefined   first referenced
>  symbol in file
> _ZSt28__throw_bad_array_new_lengthv libbackend.a(auto-profile.o)
> ld: fatal: symbol referencing errors
> collect2: error: ld returned 1 exit status
> gmake[3]: *** [../../gcc/lto/Make-lang.in:96: lto1] Error 1
> Strangely, /export/home/jakub/gcc-11-inst/lib/gcc/sparc*/11*/ directory only
> contains *.a libraries and no *.so symlinks, I've linked there 
> ../../../lib*.so
> but it still fails with that.  Is that because the various --with-*=/opt/csw
> options added

Those only exist in $prefix/lib.

> -L/opt/csw/lib and that directory contains the oldish libstdc++.a?

When I tried building on gcc211 a long time ago, I had so many problems
with the stuff in /opt/csw that I completely ignored it.  I can't help
but feel that many issues with that system are admin-made and
unnecessary.

> Do I need to use CC='gcc -L/export/home/jakub/gcc-11-inst/lib
> -R/export/home/jakub/gcc-11-inst/lib/' CXX='g++
> -L/export/home/jakub/gcc-11-inst/lib -R/export/home/jakub/gcc-11-inst/lib/' as
> workaround?

Instead, I've build my own copies of gmp/mpfr/mpc in ~ro/gcc with ABI=32
--disable-shared to avoid RPATH issues.

I had no need for special -L/-R switches this way.  The 2020 build tree
is still in ~ro/gcc/obj/master.

[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

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

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

--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #12 from Jakub Jelinek  ---
> BTW, I have also backported the r13-6739 commit to 12 branch in r12-9293, does
> that branch fail to bootstrap too?

I usually try the gcc-12 branch only once a week.  So I ran a bootstrap
there last night: worked without issues.

[Bug c++/109247] [13 Regression] optional o; o = {x}; wants to use explicit optional(U) constructor since r13-6765-ga226590fefb35ed6

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/109257] `-masm=intel` generates weird syntax for indirect jumps

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com,
   ||jakub at gcc dot gnu.org,
   ||jbeulich at suse dot com

--- Comment #1 from Jakub Jelinek  ---
It isn't just for sibcalls, but also for calls:
extern int (*foo) (int, int);
int bar (int a, int b) { return foo (a, b);  }
int baz (int a, int b) { foo (a, b); return 0; }
gcc emits
jmp [QWORD PTR foo[rip]]
and
call[QWORD PTR foo[rip]]
icc emits
mov   rax, QWORD PTR foo[rip]   #2.33
jmp   rax   #2.33
and
call  QWORD PTR foo[rip]#3.26
clang emits
mov rax, qword ptr [rip + foo]
jmp rax # TAILCALL
and
callqword ptr [rip + foo]
gas testsuite doesn't have any tests with the []s around the whole thing, but
accepts it the same as without those.
And on the gcc side it is hardcoded that way in lots of spots:
grep '\[[QD]\?WORD' i386.cc i386.md 
i386.cc:xasm = "{%p0@GOTPCREL(%%rip)|[QWORD PTR
%p0@GOTPCREL[rip]]}";
i386.cc:xasm = "%!jmp\t{*%p0@GOTPCREL(%%rip)|[QWORD PTR
%p0@GOTPCREL[rip]]}";
i386.cc:xasm = "{%p0@GOT|[DWORD PTR %p0@GOT]}";
i386.cc:xasm = "%!jmp\t{*%p0@GOT|[DWORD PTR %p0@GOT]}";
i386.cc:xasm = "{%p0@GOTPCREL(%%rip)|[QWORD PTR
%p0@GOTPCREL[rip]]}";
i386.cc:xasm = "%!call\t{*%p0@GOTPCREL(%%rip)|[QWORD PTR
%p0@GOTPCREL[rip]]}";
i386.cc:xasm = "{%p0@GOT|[DWORD PTR %p0@GOT]}";
i386.cc:xasm = "%!call\t{*%p0@GOT|[DWORD PTR %p0@GOT]}";
i386.md:  return "call\t{*%p3@GOT(%1)|[DWORD PTR %p3@GOT[%1]]}";
i386.md:  return "call\t{*%p2@GOTPCREL(%%rip)|[QWORD PTR %p2@GOTPCREL[rip]]}";
i386.md:  return "call\t{*%p2@GOT(%1)|[DWORD PTR %p2@GOT[%1]]}";
i386.md:  return "call\t{*%p1@GOTPCREL(%%rip)|[QWORD PTR %p1@GOTPCREL[rip]]}";
i386.md:  "call\t{*%a1@TLSCALL(%2)|[DWORD PTR [%2+%a1@TLSCALL]]}"
i386.md:  "call\t{*%a1@TLSCALL(%2)|[QWORD PTR [%2+%a1@TLSCALL]]}"
and I'm sure I'm missing some.

[Bug middle-end/109258] [13 Regression] go.test/test/fixedbugs/bug207.go ICEs

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug middle-end/109258] [13 Regression] go.test/test/fixedbugs/bug207.go ICEs

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

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

--- Comment #5 from Jakub Jelinek  ---
Or we could fix the go FE to make memcmp properly pure:
2023-03-23  Jakub Jelinek  

PR middle-end/109258
* go-gcc.cc (Gcc_backend): Add new static data member builtin_pure.
(Gcc_backend::Gcc_backend): Pass builtin_pure for BUILT_IN_MEMCMP.
(Gcc_backend::define_builtin): Handle builtin_pure in flags.

--- gcc/go/go-gcc.cc.jj 2023-01-18 12:22:10.396234744 +0100
+++ gcc/go/go-gcc.cc2023-03-23 11:16:08.958054518 +0100
@@ -543,6 +543,7 @@ private:
   static const int builtin_const = 1 << 0;
   static const int builtin_noreturn = 1 << 1;
   static const int builtin_novops = 1 << 2;
+  static const int builtin_pure = 1 << 3;

   void
   define_builtin(built_in_function bcode, const char* name, const char*
libname,
@@ -601,7 +602,7 @@ Gcc_backend::Gcc_backend()
const_ptr_type_node,
size_type_node,
NULL_TREE),
-  0);
+  builtin_pure);

   // We use __builtin_memmove for copying data.
   this->define_builtin(BUILT_IN_MEMMOVE, "__builtin_memmove", "memmove",
@@ -3596,6 +3597,8 @@ Gcc_backend::define_builtin(built_in_fun
   libname, NULL_TREE);
   if ((flags & builtin_const) != 0)
 TREE_READONLY(decl) = 1;
+  if ((flags & builtin_pure) != 0)
+DECL_PURE_P(decl) = 1;
   if ((flags & builtin_noreturn) != 0)
 TREE_THIS_VOLATILE(decl) = 1;
   if ((flags & builtin_novops) != 0)
@@ -3608,6 +3611,8 @@ Gcc_backend::define_builtin(built_in_fun
  NULL, NULL_TREE);
   if ((flags & builtin_const) != 0)
TREE_READONLY(decl) = 1;
+  if ((flags & builtin_pure) != 0)
+   DECL_PURE_P(decl) = 1;
   if ((flags & builtin_noreturn) != 0)
TREE_THIS_VOLATILE(decl) = 1;
   if ((flags & builtin_novops) != 0)

Or both.

[Bug ipa/108959] [13 Regression] ice in modify_assignment, at ipa-param-manipulation.cc:1905 since r13-5681-ge8109bd87766be

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

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

--- Comment #8 from Martin Jambor  ---
I have proposed a fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614475.html

[Bug middle-end/109258] [13 Regression] go.test/test/fixedbugs/bug207.go ICEs

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #4 from Jakub Jelinek  ---
One possible fix is
2023-03-23  Jakub Jelinek  

PR middle-end/109258
* builtins.cc (inline_expand_builtin_bytecmp): Return NULL_RTX early
if target == const0_rtx.

--- gcc/builtins.cc.jj  2023-03-23 10:00:58.308100548 +0100
+++ gcc/builtins.cc 2023-03-23 11:05:38.308135309 +0100
@@ -7178,8 +7178,8 @@ inline_expand_builtin_bytecmp (tree exp,
   bool is_ncmp = (fcode == BUILT_IN_STRNCMP || fcode == BUILT_IN_MEMCMP);

   /* Do NOT apply this inlining expansion when optimizing for size or
- optimization level below 2.  */
-  if (optimize < 2 || optimize_insn_for_size_p ())
+ optimization level below 2 or if unused *cmp hasn't been DCEd.  */
+  if (optimize < 2 || optimize_insn_for_size_p () || target == const0_rtx)
 return NULL_RTX;

   gcc_checking_assert (fcode == BUILT_IN_STRCMP

[Bug middle-end/109258] [13 Regression] go.test/test/fixedbugs/bug207.go ICEs

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

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

--- Comment #3 from Jakub Jelinek  ---
I'm pretty sure it is r13-6690-g45641f3a99281bb0a4296 because that's where the
ICE is.