[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #186 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #185)
> It is not at all clear what is causing the wrong value or code, though.  We
> are still at the starting point of the bugfix.

That's still great progress in any case. Thanks a lot!

[Bug tree-optimization/116460] ppc64le: LTO ICE during GIMPLE pass: forwprop

[ales.astone at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Alessandro Astone  ---
Here's the preprocessed files: https://aleasto.fedorapeople.org/ii.tar.gz

Let me know if you'd like other intermediate outputs.

[Bug fortran/86468] [12/13/14/15 regression][Coarray] ICE verify_gimple failed

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

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

--- Comment #14 from GCC Commits  ---
The master branch has been updated by Andre Vehreschild :

https://gcc.gnu.org/g:0636de8c5202d8fe58af42afdf24dd93d1a90abd

commit r15-3099-g0636de8c5202d8fe58af42afdf24dd93d1a90abd
Author: Andre Vehreschild 
Date:   Wed Aug 21 11:22:57 2024 +0200

Remove unnecessary view_convert obsoleted by [PR86468].

This patch removes an unnecessary view_convert in trans_associate to
prevent hard to find runtime errors in the future.  The view_convert was
erroneously introduced not understanding why ranks of the arrays to
assign are different.  The ranks are fixed by PR86468 now and the
view_convert is obsolete.

gcc/fortran/ChangeLog:

PR fortran/86468

* trans-stmt.cc (trans_associate_var): Remove superfluous
view_convert.

[Bug c++/116469] New: Inconsistent Zero Initialization of Nested Structures

[jonassonarvid02 at gmail dot com via Gcc-bugs]

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

Bug ID: 116469
   Summary: Inconsistent Zero Initialization of Nested Structures
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jonassonarvid02 at gmail dot com
  Target Milestone: ---

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

Description:
Following up on Bug 112666, I've discovered inconsistencies in GCC's
zero-initialization behavior for structs containing subobjects with
user-provided default constructors. The behavior varies depending on the
struct's composition and the size of arrays within inner structs, contradicting
the expected behavior based on the C++ standard and the previous bug
discussion.

---Examples---
Example 1:
--
#include 

struct Inner {
Inner(){}
unsigned char arr[10];
};

// Struct 1: Zero-initialized
struct Outer1 {
int dummy;
Inner inner;
};

// Struct 2: Not zero-initialized
struct Outer2 {
Inner inner;
};

// Struct 3: Not zero-initialized
struct Outer3 {
Inner inner;
int dummy;
};

int main() {
std::cout << "Outer1:\n";
for(int i = 0; i < 2; ++i) {
unsigned char counter = 0;
Outer1 outer{};
for(auto &c : outer.inner.arr) {
std::cout << int(c) << ' ';
c = counter++;
}
std::cout << '\n';
}

std::cout << "Outer2:\n";
for(int i = 0; i < 2; ++i) {
unsigned char counter = 0;
Outer2 outer{};
for(auto &c : outer.inner.arr) {
std::cout << int(c) << ' ';
c = counter++;
}
std::cout << '\n';
}

std::cout << "Outer3:\n";
for(int i = 0; i < 2; ++i) {
unsigned char counter = 0;
Outer3 outer{};
for(auto &c : outer.inner.arr) {
std::cout << int(c) << ' ';
c = counter++;
}
std::cout << '\n';
}
}
--


Example 2:
--
#include 
#include 
#include 

template
struct Inner {
Inner() {}
unsigned char arr[N];
};


struct Outer1 {
template
struct Outer {
int dummy;
Inner inner;
};
};

struct Outer2 {
template
struct Outer {
Inner inner;
};
};

struct Outer3 {
template
struct Outer {
Inner inner;
int dummy;
};
};

template
bool isZeroInit() {
for(int i = 0; i < 2; i++) {
typename T::template Outer outer{};
for(auto &c : outer.inner.arr) {
if(c != 0) {
return false;
}
c = 1;
}
}
return true;
}

template 
auto checkZeroInit(std::vector v, std::integer_sequence)
{
if constexpr (N != 0)
v.push_back(isZeroInit());
return v;
}

template 
auto checkZeroInit(std::vector v, std::integer_sequence) {
if constexpr (N != 0)
v.push_back(isZeroInit());
return checkZeroInit(std::move(v), std::integer_sequence{});
}


int main() {
auto v = checkZeroInit(std::vector{},
std::make_integer_sequence{});
std::cout << "Outer1: ";
for(auto b : v)
std::cout << b;
std::cout << std::endl;

v = checkZeroInit(std::vector{},
std::make_integer_sequence{});
std::cout << "Outer2: ";
for(auto b : v)
std::cout << b;
std::cout << std::endl;

v = checkZeroInit(std::vector{},
std::make_integer_sequence{});
std::cout << "Outer3: ";
for(auto b : v)
std::cout << b;
std::cout << std::endl;
return 0;
}
--


Expected Behavior:
According to the C++ standard and the discussion in Bug 112666, structs without
user-provided constructors should have all their members zero-initialized
during value initialization, regardless of the struct's composition or the size
of array members.

Actual Behavior:
The zero-initialization behavior is inconsistent and depends on:
 * The struct's composition (presence and position of other members)
 * The size of array members within inner structs

Observations:
Outer1 (int member before Inner): Inconsistent for most array lengths,
consistent only for larger arrays
Outer2 (only Inner member): Zero-initialized only for small array sizes
Outer3 (Inner member before int): Zero-initialized for small and large array
sizes, but not for medium sizes


---Outputs---
arvidjonasson@Arvids-MacBook-Air ~/testZeroInit
% g++-14 -O3 -std=c++11 -Wall -Wextra example1.

[Bug c++/116469] Inconsistent Zero Initialization of Nested Structures

[jonassonarvid02 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Arvid Jonasson  ---
Created attachment 58981
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58981&action=edit
Example 2 preprocessed

[Bug debug/116470] New: [15 regression] Enabling -gvariable-location-views breaks Solaris/x86 bootstrap

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

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

Bug ID: 116470
   Summary: [15 regression] Enabling -gvariable-location-views
breaks Solaris/x86 bootstrap
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: edlinger at gcc dot gnu.org
  Target Milestone: ---
Target: i386-pc-solaris2.11

Between 20240821 (f577959f420ae404f99f630dadc1c0370734d0da) and 20240822
(51761c50f843d5be4e24172535e4524b5072f24c), Solaris/x86 bootstrap with the
native assembler got broken, e.g.

Assembler: ipa-icf.cc
"ipa-icf.s", line 754737 : Illegal subtraction - symbols from different
sections: ".LM19368", ".LM19367"

and a couple of more.  I could trace this to

commit 76c29548b3de8bd06c3eef6084c19696019a7a2f
Author: Bernd Edlinger 
Date:   Mon Aug 19 07:11:18 2024 +0200

RISC-V: Enable -gvariable-location-views by default

I'll try attaching the good and bad assembler outputs, but they may be too
large.
Compiling with -dA -fverbose-asm doesn't annotate the assembler output as it
used to, so diffing the files won't help much either.

[Bug debug/116470] [15 regression] Enabling -gvariable-location-views breaks Solaris/x86 bootstrap

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

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

--- Comment #1 from Rainer Orth  ---
Created attachment 58982
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58982&action=edit
ipa-icf.s without patch

[Bug debug/116470] [15 regression] Enabling -gvariable-location-views breaks Solaris/x86 bootstrap

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

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

--- Comment #2 from Rainer Orth  ---
Created attachment 58983
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58983&action=edit
ipa-icf.s with patch

[Bug debug/116470] [15 regression] Enabling -gvariable-location-views breaks Solaris/x86 bootstrap

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug c++/112666] Missed optimization: Value initialization zero-initializes members with user-defined constructor

[jonassonarvid02 at gmail dot com via Gcc-bugs]

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

Arvid Jonasson  changed:

   What|Removed |Added

 CC||jonassonarvid02 at gmail dot 
com

--- Comment #6 from Arvid Jonasson  ---
I've submitted a new bug report (bug 116469) that expands on this issue. The
zero-initialization behavior appears to also depend on struct composition and
array member sizes, not just user-provided constructors.

[Bug debug/116470] [15 regression] Enabling -gvariable-location-views breaks Solaris/x86 bootstrap

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Severity|normal  |blocker
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-08-23

--- Comment #3 from Andrew Pinski  ---
And x86 linux:
https://gcc.gnu.org/pipermail/gcc-testresults/2024-August/823031.html

[Bug c++/113746] [14/15 Regression] ICE: tree check: expected enumeral_type, have error_mark in tsubst_expr, at cp/pt.cc:21458 with missing typename since r14-4796-g3e3d73ed5e85e7

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

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

--- Comment #10 from Simon Martin  ---
The ICE has disappeared since
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=f04dc89a991ddc6c08ac92c8ad29c6915c4ecafa

[Bug libstdc++/101867] avr libc build error for libstdc++

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

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

--- Comment #17 from Jonathan Wakely  ---
(In reply to cqwrteur from comment #2)
> ../gcc/configure --disable-nls --disable-werror --disable-libstdcxx-verbose
> --enable-libstdc++ --disable-ssp --enable-languages=c,c++ --prefix=$PREFIX
> --target=avr --disable-shared --with-newlib

N.B. it should be --enable-libstdcxx not --enable-libstdc++ because of how
autoconf handles + symbols.

[Bug libstdc++/101867] avr libc build error for libstdc++

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #18 from Jonathan Wakely  ---
I think this can be closed, since it does build with the right options.

[Bug fortran/85002] [12/13/14/15 Regression][Coarray] ICE in fold_ternary_loc, at fold-const.c:11360

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #13 from Andre Vehreschild  ---
Patch proposed: https://gcc.gnu.org/pipermail/fortran/2024-August/060917.html

Waiting for review.

[Bug c/96290] nonsensical bounds in VLA types in -Warray-bounds

[gabravier at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Gabriel Ravier  ---
Well, nonsensical from the point of view of the user - it didn't seem to be
particularly different to me for the error to evoke an object as " + 1"
when it just means a VLA and "" when it just means an empty array (both
seem incomprehensible or at the very least pretty unexpected to the typical
user imo). Though, if you think this is a completely different bug I wouldn't
mind opening a different one, this just seemed like it had the same cause on
account of the instances of "" being particularly similar.

[Bug other/116462] [15 regression] new test case gcc.dg/debug/dwarf2/inline7.c from r15-3083-gbcb33b1237042e fails

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Bernd Edlinger :

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

commit r15-3118-ga8ae8f9c2ed055b9e4408209f1c724493c5a3e3c
Author: Bernd Edlinger 
Date:   Fri Aug 23 06:22:55 2024 +0200

Fix test failure on powerpc targets

Apparently due to slightly different optimization levels
not always both subroutines have multiple subranges,
but having at least one such, and no lexical blocks
is sufficient to prove that the fix worked.  Q.E.D.
So reduce the test expectations to only at least one
inlined subroutine with multiple subranges.

gcc/testsuite/ChangeLog:

PR other/116462
* gcc.dg/debug/dwarf2/inline7.c: Reduce test expectations.

[Bug c++/108620] coroutines: ICE: in instantiate_type, at cp/class.cc:8742 when assign the return value of co_yield to a member of class/struct

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

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

Arsen Arsenović  changed:

   What|Removed |Added

 CC||arsen at gcc dot gnu.org

--- Comment #6 from Arsen Arsenović  ---
I think it'd be okay to just add the testcase as a regression test consider
this resolved.  WDYT, Iain?

[Bug debug/116470] [15 regression] Enabling -gvariable-location-views breaks Solaris/x86 bootstrap

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #4 from Bernd Edlinger  ---
Hmm, begin to understand,

in dwarf2out.cc (dwarf2out_source_line)
we have here the wrong decision that advance the address,
but the locations are in different segments:

  if (debug_variable_location_views && !RESETTING_VIEW_P (table->view))
push_dw_line_info_entry (table, LI_adv_address, label_num);
  else
push_dw_line_info_entry (table, LI_set_address, label_num);

[Bug middle-end/115495] [15 Regression] ICE in smallest_mode_for_size, at stor-layout.cc:356 during combine on RISC-V rv64gcv_zvl256b at -O3 since r15-1042-g68b0742a49d

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

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

--- Comment #9 from GCC Commits  ---
The master branch has been updated by Robin Dapp :

https://gcc.gnu.org/g:96fe95bac67c7303dc811c04f5e99cc959a7182a

commit r15-3120-g96fe95bac67c7303dc811c04f5e99cc959a7182a
Author: Robin Dapp 
Date:   Tue Aug 20 14:02:09 2024 +0200

optabs-query: Use opt_machine_mode for smallest_int_mode_for_size
[PR115495].

In get_best_extraction_insn we use smallest_int_mode_for_size with
struct_bits as size argument.  PR115495 has struct_bits = 256 and we
don't have a mode for that.  This patch makes smallest_mode_for_size
and smallest_int_mode_for_size return opt modes so we can just skip
over the loop when there is no mode.

PR middle-end/115495

gcc/ChangeLog:

* cfgexpand.cc (expand_debug_expr): Require mode.
* combine.cc (make_extraction): Ditto.
* config/aarch64/aarch64.cc (aarch64_expand_cpymem): Ditto.
(aarch64_expand_setmem): Ditto.
* config/arc/arc.cc (arc_expand_cpymem): Ditto.
* config/arm/arm.cc (arm_expand_divmod_libfunc): Ditto.
* config/i386/i386.cc (ix86_get_mask_mode): Ditto.
* config/rs6000/predicates.md: Ditto.
* config/rs6000/rs6000.cc (vspltis_constant): Ditto.
* config/s390/s390.cc (s390_expand_insv): Ditto.
* config/sparc/sparc.cc (assign_int_registers): Ditto.
* coverage.cc (get_gcov_type): Ditto.
(get_gcov_unsigned_t): Ditto.
* dse.cc (find_shift_sequence): Ditto.
* expmed.cc (store_integral_bit_field): Ditto.
* expr.cc (convert_mode_scalar): Ditto.
(op_by_pieces_d::smallest_fixed_size_mode_for_size): Ditto.
(emit_block_move_via_oriented_loop): Ditto.
(copy_blkmode_to_reg): Ditto.
(store_field): Ditto.
* internal-fn.cc (expand_arith_overflow): Ditto.
* machmode.h (HAVE_MACHINE_MODES): Ditto.
(smallest_mode_for_size): Use opt_machine_mode.
(smallest_int_mode_for_size): Use opt_scalar_int_mode.
* optabs-query.cc (get_best_extraction_insn): Require mode.
* optabs.cc (expand_twoval_binop_libfunc): Ditto.
* stor-layout.cc (smallest_mode_for_size): Return
opt_machine_mode.
(layout_type): Require mode.
(initialize_sizetypes): Ditto.
* tree-ssa-loop-manip.cc (canonicalize_loop_ivs): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/pr115495.c: New test.

gcc/ada/ChangeLog:

* gcc-interface/utils2.cc (fast_modulo_reduction): Require mode.
(nonbinary_modular_operation): Ditto.

[Bug middle-end/115495] [15 Regression] ICE in smallest_mode_for_size, at stor-layout.cc:356 during combine on RISC-V rv64gcv_zvl256b at -O3 since r15-1042-g68b0742a49d

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

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

Robin Dapp  changed:

   What|Removed |Added

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

--- Comment #10 from Robin Dapp  ---
Fixed.

[Bug debug/116470] [15 regression] Enabling -gvariable-location-views breaks Solaris/x86 bootstrap

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #5 from Bernd Edlinger  ---
but one thing is funnny, in the bad asm
both symbols.LM19367 and .LM19368 appear to be in the same section:


.section.text.unlikely
.align 2
.LCOLDB277:
.text
.LHOTB277:
.align 2
.p2align 4
.globl 
_ZN7ipa_icf18sem_item_optimizer20varpool_removal_hookEP12varpool_nodePv
.type  
_ZN7ipa_icf18sem_item_optimizer20varpool_removal_hookEP12varpool_nodePv,
@function
_ZN7ipa_icf18sem_item_optimizer20varpool_removal_hookEP12varpool_nodePv:
.LFB7202:
.LM19367:
pushl   %ebp
.LCFI1137:
movl%esp, %ebp
.LCFI1138:
[...]
call   
_ZN8hash_setIP11symtab_nodeLb0E19default_hash_traitsIS1_EE3addERKS1_.isra.0
leave
.LCFI1139:
ret
.section.text.unlikely
.LM19368:
.type  
_ZN7ipa_icf18sem_item_optimizer20varpool_removal_hookEP12varpool_nodePv.cold,
@function
_ZN7ipa_icf18sem_item_optimizer20varpool_removal_hookEP12varpool_nodePv.cold:
.LFSB7202:
.L4466:
.LCFI1140:
call   
_ZN7ipa_icf18sem_item_optimizer18remove_symtab_nodeEP11symtab_node.part.0
.LFE7202:



What is going on here, is it possible that it is a bug in the assembler?

[Bug preprocessor/116458] [15 regression] New valgrind error in search_line_ssse3

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

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

--- Comment #10 from GCC Commits  ---
The master branch has been updated by Alexander Monakov :

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

commit r15-3121-gb2c1d7c4573d3b938f44b3bda202adeb292b1cbc
Author: Alexander Monakov 
Date:   Thu Aug 22 21:09:47 2024 +0300

libcpp: bump padding size in _cpp_convert_input [PR116458]

The recently introduced search_line_fast_ssse3 raised padding
requirement from 16 to 64, which was adjusted in read_file_guts,
but the corresponding ' + 16' in _cpp_convert_input was overlooked.

libcpp/ChangeLog:

PR preprocessor/116458
* charset.cc (_cpp_convert_input): Bump padding to 64 if
HAVE_SSSE3.

[Bug libstdc++/116471] New: Strange/bogus static_assert in ranges::copy / move algorithms

[dangelog at gmail dot com via Gcc-bugs]

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

Bug ID: 116471
   Summary: Strange/bogus static_assert in ranges::copy / move
algorithms
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dangelog at gmail dot com
  Target Milestone: ---

Hi,

This code fails to build on GCC 14 (CE link:
https://gcc.godbolt.org/z/qnYGd48Ko )


#include 

struct X {
X& operator=(X&) = default; // non-const
};

int main() {
extern X *b, *e, *out;
std::ranges::copy(b, e, out);
}



/opt/compiler-explorer/gcc-14.2.0/include/c++/14.2.0/bits/ranges_algobase.h:259:23:
error: static assertion failed
  258 |   static_assert(_IsMove
  | ~~~
  259 |   ? is_move_assignable_v<_ValueTypeI>
  |   ^~~
  260 |   : is_copy_assignable_v<_ValueTypeI>);
  |   ~~~
/opt/compiler-explorer/gcc-14.2.0/include/c++/14.2.0/bits/ranges_algobase.h:259:23:
note: '(false ?  std::is_move_assignable_v : std::is_copy_assignable_v)'
evaluates to false



Indeed X fails is_copy_assignable because its copy assignment operator takes by
non-const reference.

It's not entirely clear why that static_assert is there, given that
ranges::copy/move algorithms are already constrained on concepts (like
indirectly_copyable). 

It's also worth noting that the static_assert is into a if constexpr(
__memcpyable<_Iter, _Out>::__value) branch. memcpyable basically means
trivially copyable (except for pointers to volatile), however trivially
copyable does NOT imply is_copy_assignable (because it just checks that
eligible copy assignments are trivial, not that they work from a `const T`).

I can send a patch, but I'm not sure in which direction this should go. I
stumbled upon this while extending the fix PR108846 to range algorithms.

[Bug other/116462] [15 regression] new test case gcc.dg/debug/dwarf2/inline7.c from r15-3083-gbcb33b1237042e fails

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Should be fixed.

[Bug tree-optimization/116463] [15 Regression] fast-math-complex-mls-{double,float}.c fail after r15-3087-gb07f8a301158e5

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

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

--- Comment #6 from Richard Biener  ---
I think

  a - ((b * -c) + (d * -e))  ->  a + (b * c) + (d * e)

is a good simplification to be made, but it's difficult to do this with
canonicalization only.  Like a * -b -> -(a * b) as the negate might
combine with both other negates down and upstream.  But for
a*-b + c * -d it might be more obvious to turn that into
-a*b - c*d.

Maybe reassoc can be of help here - IIRC it turns b * -c into
b * c * -1, undistribute_ops_list might get that.

Note one issue is that complex lowering leaves around dead stmts,
confusing reassoc and forwprop, in particular

-  _10 = COMPLEX_EXPR <_18, _6>;

stay around until reassoc.  scheduling dce for testing shows reassoc
does something.

It's update_complex_assignment who replaces existing complex
stmts with COMPLEX_EXPRs, we should possibly resort do simple_dce_from_worklist
to clean those.  Let me try to do that.

[Bug middle-end/116465] __builtin_eh_pointer and __builtin_eh_filter ICE when not assigned to anything

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-08-23
 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code

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

[Bug target/116467] missed optimization: zero-extension duplicated on xtensa

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||xtensa
   Keywords||missed-optimization

--- Comment #1 from Richard Biener  ---
It probably can, but it depends on the guarantees set by the ABI if there is
any such written.

[Bug tree-optimization/116348] [15 regression] ICE when building gavl-1.4.0 with -O3 -march=znver4 since r15-2791-g2083389a18d366

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #11 from rguenther at suse dot de  ---
On Thu, 22 Aug 2024, xry111 at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116348
> 
> --- Comment #10 from Xi Ruoyao  ---
> I've tested the change and it fixes PR116314 case as well.
> 
> Richard: do you want me to send your change as a patch like before (the
> PR116142 fix)?

Yes pleae.

[Bug libstdc++/115098] std::vector::iterator::reference is default-constructible

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r15-3124-gb25b101bc380004b82e25d2b1ef306856c75d864
Author: Jonathan Wakely 
Date:   Wed Aug 21 21:19:46 2024 +0100

libstdc++: Make std::vector::reference constructor private [PR115098]

The standard says this constructor should be private.  LWG 4141 proposes
to remove it entirely. We still need it, but it doesn't need to be
public.

For std::bitset the default constructor is already private (and never
even defined) but there's a non-standard constructor that's public, but
doesn't need to be.

libstdc++-v3/ChangeLog:

PR libstdc++/115098
* include/bits/stl_bvector.h (_Bit_reference): Make default
constructor private. Declare vector and bit iterators as
friends.
* include/std/bitset (bitset::reference): Make constructor and
data members private.
* testsuite/20_util/bitset/115098.cc: New test.
* testsuite/23_containers/vector/bool/115098.cc: New test.

[Bug c++/116369] [12/13/14/15 Regression] temporary variable bounded to const reference with mutable field incorrectly marked as rodata since r9-869-g5603790dbf233c

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

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

--- Comment #11 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r15-3127-ga35dd276cbf6236e08bcf6e56e62c2be41cf6e3c
Author: Jonathan Wakely 
Date:   Wed Aug 21 12:29:32 2024 +0100

libstdc++: Make debug sequence members mutable [PR116369]

We need to be able to attach debug mode iterators to const containers,
so the safe iterator constructor uses const_cast to get a modifiable
pointer to the container. If the container was defined as const, that
const_cast to access its members results in undefined behaviour.  PR
116369 shows a case where it results in a segfault because the container
is in a rodata section (which shouldn't have happened, but the undefined
behaviour in the library still exists in any case).

This makes the _M_iterators and _M_const_iterators data members mutable,
so that it's safe to modify them even if the declared type of the
container is a const type.

Ideally we would not need the const_cast at all. Instead, the _M_attach
member (and everything it calls) should be const-qualified. That would
work fine now, because the members that it ends up modifying are
mutable. Making that change would require a number of new exports from
the shared library, and would require retaining the old non-const member
functions (maybe as symbol aliases) for backwards compatibility. That
might be worth changing at some point, but isn't done here.

libstdc++-v3/ChangeLog:

PR c++/116369
* include/debug/safe_base.h (_Safe_sequence_base::_M_iterators):
Add mutable specifier.
(_Safe_sequence_base::_M_const_iterators): Likewise.

[Bug libstdc++/116471] Strange/bogus static_assert in ranges::copy / move algorithms

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

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

--- Comment #1 from Jonathan Wakely  ---
That assertion originated in std::copy, where we needed to ensure that
std::copy would be ill-formed for non-assignable types when we take the memcpy
branch. That code was removed from std::copy in r13-6372-g822a11a1e642e0 (the
PR108846 fix) but lives on in ranges::copy.

It was needed in std::copy because the assignment might happen in a discarded
statement, if we take the if-constexpr(__memcpyable) branch, and the memcpy
would compile for types that should not be usable with std::copy.

We don't need it in std::copy now, because even when we take the memcpy branch,
there's still a non-discarded statement that does the assignment (for the
1-element case).

You might be right that we never needed it in ranges::copy because it's already
constrained correctly.

[Bug libstdc++/116471] Strange/bogus static_assert in ranges::copy / move algorithms

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Giuseppe D'Angelo from comment #0)
> It's also worth noting that the static_assert is into a if constexpr(
> __memcpyable<_Iter, _Out>::__value) branch. memcpyable basically means
> trivially copyable (except for pointers to volatile), however trivially
> copyable does NOT imply is_copy_assignable (because it just checks that
> eligible copy assignments are trivial, not that they work from a `const T`).

N.B. That's not quite accurate, which is why we needed the check in std::copy.

A type with deleted assignment operators can also be trivially copyable.

[Bug tree-optimization/116463] [15 Regression] fast-math-complex-mls-{double,float}.c fail after r15-3087-gb07f8a301158e5

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Richard Biener :

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

commit r15-3128-gde1923f9f4d5344694c22ca883aeb15caf635734
Author: Richard Biener 
Date:   Fri Aug 23 13:44:29 2024 +0200

tree-optimization/116463 - complex lowering leaves around dead stmts

Complex lowering generally replaces existing complex defs with
COMPLEX_EXPRs but those might be dead when it can always refer to
components from the lattice.  This in turn can pessimize followup
transforms like forwprop and reassoc, the following makes sure to
get rid of dead COMPLEX_EXPRs generated by using
simple_dce_from_worklist.

PR tree-optimization/116463
* tree-complex.cc: Include tree-ssa-dce.h.
(dce_worklist): New global.
(update_complex_assignment): Add SSA def to the DCE worklist.
(tree_lower_complex): Perform DCE.

[Bug libstdc++/115098] std::vector::iterator::reference is default-constructible

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Fixed for GCC 15

[Bug libstdc++/88935] std::random_shuffle does not work if the sequence is longer than RAND_MAX elements

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

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

--- Comment #14 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:125bab23ad75449333983c9389898c5b92b3aa0d

commit r15-3129-g125bab23ad75449333983c9389898c5b92b3aa0d
Author: Giovanni Bajo 
Date:   Wed Jul 31 20:03:40 2024 +0100

libstdc++: Fix std::random_shuffle for low RAND_MAX [PR88935]

When RAND_MAX is small and the number of elements being shuffled is
close to it, we get very uneven distributions in std::random_shuffle.

This uses a simple xorshift generator seeded by std::rand if we can't
rely on std::rand itself.

libstdc++-v3/ChangeLog:

PR libstdc++/88935
* include/bits/stl_algo.h (random_shuffle) [RAND_MAX < INT_MAX]:
Use xorshift instead of rand().
* testsuite/25_algorithms/random_shuffle/88935.cc: New test.

Co-authored-by: Jonathan Wakely 
Signed-off-by: Giovanni Bajo 

[Bug libstdc++/108619] Compilation error if the construct method of the allocator isn't implemented and the detructor of value_type is private

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

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

--- Comment #14 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r15-3132-g8cf51d7516b92b352c358c14ab4e456ae53c3371
Author: Jonathan Wakely 
Date:   Wed Jul 10 23:14:19 2024 +0100

libstdc++: Fix std::allocator_traits::construct constraints [PR108619]

Using std::is_constructible in the constraints introduces a spurious
dependency on the type being destructible, which should not be required
for constructing with an allocator. The test case shows a case where the
type has a private destructor, which can be destroyed by the allocator,
but std::is_destructible and std::is_constructible are false.

Similarly, using is_nothrow_constructible in the noexcept-specifiers
for the construct members of allocator_traits and std::allocator,
__gnu_cxx::__new_allocator, and __gnu_cxx::__malloc_allocator gives the
wrong answer if the type isn't destructible.
We need a new type trait to define those correctly, so that we only
check if the placement new-expression is nothrow after using
is_constructible to check that it would be well-formed.

Instead of just fixing the overly restrictive constraint to check for
placement new, rewrite allocator_traits in terms of 'if constexpr' using
variable templates and the detection idiom.

Although we can use 'if constexpr' and variable templates in C++11 with
appropriate uses of diagnostic pragmas, we can't have constexpr
functions with multiple return statements. This means that in C++11 mode
the _S_nothrow_construct and _S_nothrow_destroy helpers used for
noexcept-specifiers still need to be overlaods using enable_if. Nearly
everything else can be simplified to reduce overload resolution and
enable_if checks.

libstdc++-v3/ChangeLog:

PR libstdc++/108619
* include/bits/alloc_traits.h (__allocator_traits_base): Add
variable templates for detecting which allocator operations are
supported.
(allocator_traits): Use 'if constexpr' instead of dispatching to
overloads constrained with enable_if.
(allocator_traits>::construct): Use Construct if
construct_at is not supported. Use
__is_nothrow_new_constructible for noexcept-specifier.
(allocator_traits>::construct): Use
__is_nothrow_new_constructible for noexcept-specifier.
* include/bits/new_allocator.h (construct): Likewise.
* include/ext/malloc_allocator.h (construct): Likewise.
* include/std/type_traits (__is_nothrow_new_constructible): New
variable template.
* testsuite/20_util/allocator/89510.cc: Adjust expected results.
* testsuite/ext/malloc_allocator/89510.cc: Likewise.
* testsuite/ext/new_allocator/89510.cc: Likewise.
* testsuite/20_util/allocator_traits/members/108619.cc: New test.

[Bug libstdc++/115939] Cannot unambiguously compare iterators in std::unordered_map with mapped type std::expected>

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:591b71993f15ed95eb38f3314f3d9ac159b9d051

commit r15-3130-g591b71993f15ed95eb38f3314f3d9ac159b9d051
Author: Jonathan Wakely 
Date:   Tue Jul 16 09:43:06 2024 +0100

libstdc++: Define operator== for hash table iterators [PR115939]

Currently iterators for unordered containers do not directly define
operator== and operator!= overloads. Instead they rely on the base class
defining them, which is done so that iterator and const_iterator
comparisons work using the same overloads.

However this means a derived-to-base conversion is needed to call those
operators, and PR libstdc++/115939 shows that this can be ambiguous (for
-pedantic) when another overloaded operator could be used after an
implicit conversion.

This change defines operator== and operator!= directly for
_Node_iterator and _Node_const_iterator so that no derived-to-base
conversions are needed. The new overloads just forward to the base class
ones, so the implementation is still shared and doesn't need to be
duplicated.

libstdc++-v3/ChangeLog:

PR libstdc++/115939
* include/bits/hashtable_policy.h (_Node_iterator): Add
operator== and operator!=.
(_Node_const_iterator): Likewise.
* testsuite/23_containers/unordered_map/115939.cc: New test.

[Bug tree-optimization/116463] [15 Regression] fast-math-complex-mls-{double,float}.c fail after r15-3087-gb07f8a301158e5

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

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

--- Comment #8 from Richard Biener  ---
As of r15-3128-gde1923f9f4d534 now

FAIL: gcc.target/i386/avx512fp16-vector-complex-float.c scan-assembler-not
vfmadd[123]*ph[ t]
FAIL: gcc.target/i386/avx512fp16-vector-complex-float.c scan-assembler-times
vfmaddcph[ t] 1
FAIL: gcc.target/i386/part-vect-complexhf.c scan-assembler-times vfmaddcph[
t] 1

fail which look similar to the aarch64 fails (I have no idea if the patch
helped for those).

For the first test it's fma0 which is no longer vectorized as

vmovdqu16   (%rdx), %zmm0
vmovdqu16   (%rsi), %zmm1
vfmaddcph   (%rdi), %zmm1, %zmm0
vmovdqu16   %zmm0, (%rdx)

but

vmovdqu16   (%rsi), %zmm0
vmovdqu16   (%rdi), %zmm2
movl$1431655765, %eax
kmovd   %eax, %k1
vpshufb .LC1(%rip), %zmm0, %zmm1
vfmadd213ph (%rdx), %zmm2, %zmm1
vpshufb .LC2(%rip), %zmm0, %zmm0
vpshufb .LC0(%rip), %zmm2, %zmm3
vmovdqa64   %zmm0, %zmm2
vfmadd132ph %zmm3, %zmm1, %zmm2
vfnmadd132ph%zmm3, %zmm1, %zmm0
vpblendmw   %zmm0, %zmm2, %zmm0{%k1}
vmovdqu16   %zmm0, (%rdx)

where instead of

note:Found COMPLEX_FMA pattern in SLP tree

we have

note:Found VEC_ADDSUB pattern in SLP tree
note:Target does not support VEC_ADDSUB for vector type vector(32) _Float16 

with the IL difference being (- is good, + is bad)

  _12 = REALPART_EXPR <*_3>;
  _11 = IMAGPART_EXPR <*_3>;
...
@@ -46,10 +46,10 @@
   _27 = _19 * _25;
   _28 = _20 * _25;
   _29 = _19 * _24;
-  _30 = _26 - _27;
-  _31 = _28 + _29;
-  _32 = _12 + _30;
-  _33 = _11 + _31;
+  _9 = _12 + _26;
+  _10 = _11 + _28;
+  _32 = _9 - _27;
+  _33 = _10 + _29;
   REALPART_EXPR <*_3> = _32;
   IMAGPART_EXPR <*_3> = _33;
   i_18 = i_21 + 1;

which is different association, enabled by deleting dead uses that confuse
reassoc.

[Bug libstdc++/108619] Compilation error if the construct method of the allocator isn't implemented and the detructor of value_type is private

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

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

--- Comment #15 from Jonathan Wakely  ---
Fixed on trunk only so far.

[Bug debug/116470] [15 regression] Enabling -gvariable-location-views breaks Solaris/x86 bootstrap

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #6 from H.J. Lu  ---
They are in different sections:

[hjl@gnu-cfl-3 tmp]$ cat foo.s
.text
.align 2
.p2align 4
.LM19367:
pushl   %ebp
.section.text.unlikely
.LM19368:
nop
.section.debug_line,"",@progbits
.dc.a .LM19368-.LM19367
[hjl@gnu-cfl-3 tmp]$ gcc -c foo.s -m32
foo.s: Assembler messages:
foo.s:10: Error: can't resolve .text.unlikely - .LM19367
[hjl@gnu-cfl-3 tmp]$

[Bug debug/116470] [15 regression] Enabling -gvariable-location-views breaks Solaris/x86 bootstrap

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #7 from H.J. Lu  ---
(In reply to Bernd Edlinger from comment #5)
> but one thing is funnny, in the bad asm
> both symbols.LM19367 and .LM19368 appear to be in the same section:
> 
> 
> .section.text.unlikely
> .align 2
> .LCOLDB277:
> .text
^^ section switch.
> .LHOTB277:
> .align 2
> .p2align 4
> .globl 
> _ZN7ipa_icf18sem_item_optimizer20varpool_removal_hookEP12varpool_nodePv
> .type  
> _ZN7ipa_icf18sem_item_optimizer20varpool_removal_hookEP12varpool_nodePv,
> @function
> _ZN7ipa_icf18sem_item_optimizer20varpool_removal_hookEP12varpool_nodePv:
> .LFB7202:
> .LM19367:
> pushl   %ebp
> .LCFI1137:
> movl%esp, %ebp
> .LCFI1138:
> [...]
> call   
> _ZN8hash_setIP11symtab_nodeLb0E19default_hash_traitsIS1_EE3addERKS1_.isra.0
> leave
> .LCFI1139:
> ret
> .section.text.unlikely
> .LM19368:
> .type  
> _ZN7ipa_icf18sem_item_optimizer20varpool_removal_hookEP12varpool_nodePv.cold,
> @function
> _ZN7ipa_icf18sem_item_optimizer20varpool_removal_hookEP12varpool_nodePv.cold:
> .LFSB7202:
> .L4466:
> .LCFI1140:
> call   
> _ZN7ipa_icf18sem_item_optimizer18remove_symtab_nodeEP11symtab_node.part.0
> .LFE7202:
> 
> 
> 
> What is going on here, is it possible that it is a bug in the assembler?

[Bug lto/116361] lto1: fatal error: multiple prevailing defs when using both LTO and OpenMP named critical sections with static libraries

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r15-3135-gcb51e0b236c7d492af2033582230e78d8b55290f
Author: H.J. Lu 
Date:   Fri Aug 23 05:36:45 2024 -0700

lto: Don't check obj.found for offload section

obj.found is the number of LTO symbols.  We should include the offload
section when it is used by linker even if there are no LTO symbols.

PR lto/116361
* lto-plugin.c (claim_file_handler_v2): Don't check obj.found
for the offload section.

Signed-off-by: H.J. Lu 

[Bug fortran/116261] [15 regression] gfortran.dg/sizeof_6.f90 -O1 timeout since r15-2739-g4cb07a38233

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

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #12 from Paul Thomas  ---
Reverted in commit r15-3123-gf9f599a44e3156a5f5679adc048ec6ff2f44cc0e

Closing as fixed

Paul

[Bug libstdc++/116471] Strange/bogus static_assert in ranges::copy / move algorithms

[dangelog at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Giuseppe D'Angelo  ---
> You might be right that we never needed it in ranges::copy because it's 
> already constrained correctly.

So would it be OK to just remove the static_assert from the range-based
algorithms?

> N.B. That's not quite accurate, which is why we needed the check in std::copy.
> A type with deleted assignment operators can also be trivially copyable.

I think I worded myself poorly, what I meant to say is that the check *is*
checking something, precisely because is_copy_assignable is not implied by
__memcpyable. In other words, the check wasn't "useless".

[Bug libstdc++/116471] Strange/bogus static_assert in ranges::copy / move algorithms

[dangelog at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Giuseppe D'Angelo  ---
Created attachment 58984
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58984&action=edit
patch v1

Attaching a patch for this + PR108846 , since the testcases basically cover
both in one go.

[Bug other/116472] New: Wrong offset format when generating assembly with -S and -masm=intel

[8dcc.git at gmail dot com via Gcc-bugs]

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

Bug ID: 116472
   Summary: Wrong offset format when generating assembly with -S
and -masm=intel
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 8dcc.git at gmail dot com
  Target Milestone: ---

The following C code:

#include 

int main(void) {
int arr[2];
arr[0] = 123;
arr[1] = 456;
printf("%d, %d\n", arr[0], arr[1]);
return 0;
}

Is compiled with:

gcc -S -masm=intel -o output.s source.c

This is a chunk of the generated assembly in output.s:

...
mov QWORD PTR -8[rbp], rax
xor eax, eax
mov DWORD PTR -16[rbp], 123
mov DWORD PTR -12[rbp], 456
...

As far as I know, in intel syntax the offset of the effective addresses should
be inside the square brackets, next to the register:

...
mov QWORD PTR [rbp-8], rax
xor eax, eax
mov DWORD PTR [rbp-16], 123
mov DWORD PTR [rbp-12], 456
...

-

My GCC version:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust
--enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.2.1 20240805 (GCC)

[Bug c++/116439] [14/15 Regression] decltype(auto) in return type of lambda uses the type of the outer scope, not the capture

[valentin at tolmer dot fr via Gcc-bugs]

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

--- Comment #3 from Valentin Tolmer  ---
Digging a little bit into it, there is definitely a bug that was in 14.1 only
(and got fixed in 14.2):

struct S {
  S() = default;
  S(const S&) = delete;
};

int main() {
  S source;
  S& source2 = source;
  // Fails only in 14.1
  [](auto& key) -> S& {
return [&] -> decltype(auto) { return key; }();
  }(source);
  [&] -> decltype(auto) { return source2; }();
  // Fails on clang++, gcc 14.1 and 14.2
  [&]() -> S& {
return [&] -> decltype(auto) { return source; }();
  }();
  [&] -> decltype(auto) { return source; }();
}

The first 2 lambdas should clearly deduce S& for the decltype(auto), but don't
in 14.1.

Patrick, I don't think the note you linked applies here: it's not within the
compounds statement of a lambda, and it doesn't refer to a capture by value.

I think the relevant part is
"An id-expression within the compound-statement of a lambda-expression that is
an odr-use of a reference captured by reference refers to the entity to which
the captured reference is bound and not to the captured reference." which would
mean that it gets resolved to decltype(source) and thus S.

[Bug libstdc++/88935] std::random_shuffle does not work if the sequence is longer than RAND_MAX elements

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #15 from Jonathan Wakely  ---
Fixed for GCC 15

[Bug libstdc++/115939] Cannot unambiguously compare iterators in std::unordered_map with mapped type std::expected>

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

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

--- Comment #9 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug debug/116470] [15 regression] Enabling -gvariable-location-views breaks Solaris/x86 bootstrap

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #8 from Jeffrey A. Law  ---
Note the patch causes a build failure for ft32-elf as well.  That might make a
simpler testcase that solaris native.

Configure, build and install binutils for ft32-elf (using some --prefix
option).

Configure gcc using the same prefix & target options, then
make all-gcc && make all-target-libgcc

The all-target-libgcc step will fail due to a failure to configure the target
libraries.  Digging into config.log:

/tmp/cc7t7fxJ.s: Assembler messages:
/tmp/cc7t7fxJ.s:211: Error: can't resolve .text.startup - .LM1
/tmp/cc7t7fxJ.s:216: Error: can't resolve .text.startup - .LM2
/tmp/cc7t7fxJ.s:221: Error: can't resolve .text.startup - .LM3

[Bug libstdc++/116471] Strange/bogus static_assert in ranges::copy / move algorithms

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #5 from Jonathan Wakely  ---
(In reply to Giuseppe D'Angelo from comment #3)
> So would it be OK to just remove the static_assert from the range-based
> algorithms?

I think so, yes.

[Bug libstdc++/116471] Strange/bogus static_assert in ranges::copy / move algorithms

[dangelog at gmail dot com via Gcc-bugs]

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

Giuseppe D'Angelo  changed:

   What|Removed |Added

  Attachment #58984|0   |1
is obsolete||

--- Comment #6 from Giuseppe D'Angelo  ---
Created attachment 58985
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58985&action=edit
patch v2

Better patch, that makes use of __assign_one in a few more places.

[Bug libstdc++/114865] [13/14/15 Regression] std::atomic::compare_exchange_strong seems to hang under GCC 13 for C++11

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed|2024-04-26 00:00:00 |2024-08-23
 Status|UNCONFIRMED |NEW

[Bug c++/109918] [12/13/14/15 Regression] Unexpected -Woverloaded-virtual with virtual conversion operators

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

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

Simon Martin  changed:

   What|Removed |Added

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

--- Comment #5 from Simon Martin  ---
Working on this one.

[Bug c++/101367] [coroutines] destructor for capture in lambda temporary operand to co_yield expression called twice

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

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

Arsen Arsenović  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||arsen at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #14 from Arsen Arsenović  ---
fixed in 13+

[Bug c++/54367] [meta-bug] lambda expressions

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

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

Bug 101367 Summary: [coroutines] destructor for capture in lambda temporary 
operand to co_yield expression called twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101367

   What|Removed |Added

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

[Bug fortran/106606] Internal compiler error with abstract derived type using recursive class() components. since r7-4096-gbf9f15ee55f5b291

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 CC||vehre at gcc dot gnu.org

--- Comment #6 from Andre Vehreschild  ---
Created attachment 58986
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58986&action=edit
WIP patch

Hi Paul,

I took a look and after same stabbing around in the dark, figured that a
derived type that has been resolved already should not be resolved again. I
therefore decided to use the gfc_symbol::mark to figure, if the type has been
setup already. This worked remarkably well. Unfortunately does the current
patch regress in select_type_4.f90 (the only regression). I am preparing to go
on holiday, so I can't spent more time on this. 

Oh, btw, with your patch the runtime crash is due to the root%_data =
__builtin_malloc(4); which is clearly to less memory to accommodate two
class-_datas and _vptrs as well as the int. I assume that by bad luck you ended
up overwriting your roots%_vptr. 

Feel free to use the attached patch as start to fix this finally. What I don't
get yet is, why there is a need for pointer and proc_pointer components to be
excluded from not re-resolving an existing type. Any idea? May be the issue
with select_type_4 is by some other location making a similar assumption.

The reason why I added the coarray-check is, that this may copy the type for a
different corank, which unfortunately is encoded in the type name.

So long. I will be sporadically online only in the next three weeks. Have fun.

- Andre

[Bug c++/116439] [14/15 Regression] decltype(auto) in return type of lambda uses the type of the outer scope, not the capture

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

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

--- Comment #4 from Patrick Palka  ---
Ah yes, that's PR115504 I think.  The original fix was incorrectly stripping
references from the captured variable type which was fixed for 14.2 by
r15-1631.

It's correct but certainly weird that the current rules mean the second to last
decltype(auto) is invalid, because decltype(source) is S& but the closure
member is const S&..

[Bug c++/116439] [14/15 Regression] decltype(auto) in return type of lambda uses the type of the outer scope, not the capture

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

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

--- Comment #5 from Patrick Palka  ---
(In reply to Patrick Palka from comment #4)
> It's correct but certainly weird that the current rules mean the second to
> last decltype(auto) is invalid, because decltype(source) is S& but the
> closure member is const S&..
D'oh, ignore this, I totally misinterpreted the testcase.   The weird example I
had in mind was https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655632.html
FWIW

[Bug libstdc++/116473] New: std::ranges::to vs constexpr

[terra at gnome dot org via Gcc-bugs]

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

Bug ID: 116473
   Summary: std::ranges::to vs constexpr
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: terra at gnome dot org
  Target Milestone: ---

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

I *think* the following ought to work with the "constexpr".  It works fine
without and in that case generates code with 3 run-time calls to operator new
and operator delete each.


# cat ttt-ranges-to.C

#include 
#include 

int
oink(void)
{
constexpr auto v = std::views::iota(1,5) |
std::ranges::to>();
return v.front();
}


# /usr/local/products/gcc/14.1.0/bin/g++ -std=c++23 -c ttt-ranges-to.C
In file included from
/usr/local/products/gcc/14.1.0/include/c++/14.1.0/string:43,
 from
/usr/local/products/gcc/14.1.0/include/c++/14.1.0/bits/locale_classes.h:40,
 from
/usr/local/products/gcc/14.1.0/include/c++/14.1.0/bits/ios_base.h:41,
 from
/usr/local/products/gcc/14.1.0/include/c++/14.1.0/streambuf:43,
 from
/usr/local/products/gcc/14.1.0/include/c++/14.1.0/bits/streambuf_iterator.h:35,
 from
/usr/local/products/gcc/14.1.0/include/c++/14.1.0/iterator:66,
 from
/usr/local/products/gcc/14.1.0/include/c++/14.1.0/ranges:43,
 from ttt-ranges-to.C:1:
/usr/local/products/gcc/14.1.0/include/c++/14.1.0/bits/allocator.h: In function
‘int oink()’:
/usr/local/products/gcc/14.1.0/include/c++/14.1.0/bits/allocator.h:193:52:
error: ‘std::ranges::views::__adaptor::operator|(_Range&&, _Self&&) [with _Self
= _Partial > >; _Range =
std::ranges::iota_view](std::ranges::to >())’ is not
a constant expression because it refers to a result of ‘operator new’
  193 | return static_cast<_Tp*>(::operator new(__n));
  |  ~~^

[Bug target/115054] __float128 and _Float16 use incorrect ABI on x86-64 MinGW

[chorman64 at gmail dot com via Gcc-bugs]

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

connor horman  changed:

   What|Removed |Added

 CC||chorman64 at gmail dot com

--- Comment #6 from connor horman  ---
According to: https://cs61.seas.harvard.edu/site/pdf/x86-64-abi-20210928.pdf

> Arguments of types _Float16, float, double, _Decimal32, _Decimal64 and __m64 
> are
in class SSE.

So `_Float16` is SSE as well.

[Bug debug/116470] [15 regression] Enabling -gvariable-location-views breaks Solaris/x86 bootstrap

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #9 from Bernd Edlinger  ---
Thanks Jeff for this advice,
It could be that this are two different issues, but
The ft32-issue might be solved by this completely untested patch:

--- a/gcc/dwarf2out.cc
+++ b/gcc/dwarf2out.cc
@@ -13019,9 +13019,9 @@ output_one_line_info_table (dw_line_info_table *table)

view++;

-   dw2_asm_output_data (1, DW_LNS_fixed_advance_pc, "fixed advance PC,
increment view to %i", view);
-   dw2_asm_output_delta (2, line_label, prev_label,
- "from %s to %s", prev_label, line_label);
+   dw2_asm_output_data (1, DW_LNS_advance_pc, "advance PC, increment
view to %i", view);
+   dw2_asm_output_delta_uleb128 (line_label, prev_label,
+ "from %s to %s", prev_label,
line_label);

prev_addr = ent;
break;

[Bug c/116474] New: GCC somehow confuses "unsigned __int128_t" with a nested function

[gabravier at gmail dot com via Gcc-bugs]

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

Bug ID: 116474
   Summary: GCC somehow confuses "unsigned __int128_t" with a
nested function
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

int main(){
unsigned __int128_t x = 0;
}

Compiled with -pedantic, results in the following warning:

: In function 'main':
:2:9: warning: ISO C forbids nested functions [-Wpedantic]
2 | unsigned __int128_t x = 0;
  | ^~~~
:2:29: error: expected '=', ',', ';', 'asm' or '__attribute__' before
'x'
2 | unsigned __int128_t x = 0;
  | ^
:2:29: error: 'x' undeclared (first use in this function)
:2:29: note: each undeclared identifier is reported only once for each
function it appears in

It seems quite odd that a warning for a nested function is emitted here.

[Bug target/116466] The standard instruction pattern of RISC-V addv has generated an unnecessary instruction.

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #1 from Jeffrey A. Law  ---
Yes, we're aware that the overflow related support is emitting unnecessary sign
extensions.  I've got a hack from the RAU team, but I haven't really dug into
it to see if it should go in as-is or if we should be catching these cases
elsewhere.

[Bug target/116415] [12/13/14/15 Regression][PPC64LE] atomics wrongly use vector instructions in DWCAS.

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

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

--- Comment #9 from GCC Commits  ---
The master branch has been updated by Peter Bergner :

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

commit r15-3136-g6e68c3df1540c5bafbb47343698bf4e270333fdb
Author: Peter Bergner 
Date:   Fri Aug 23 11:45:40 2024 -0500

rs6000: Fix PTImode handling in power8 swap optimization pass [PR116415]

Our power8 swap optimization pass has some special handling for optimizing
swaps of TImode variables.  The test case reported in bugzilla uses a call
to  __atomic_compare_exchange, which introduces a variable of PTImode and
that does not get the same treatment as TImode leading to wrong code
generation.  The simple fix is to treat PTImode identically to TImode.

2024-08-23  Peter Bergner  

gcc/
PR target/116415
* config/rs6000/rs6000.h (TI_OR_PTI_MODE): New define.
* config/rs6000/rs6000-p8swap.cc (rs6000_analyze_swaps): Use it to
handle PTImode identically to TImode.

gcc/testsuite/
PR target/116415
* gcc.target/powerpc/pr116415.c: New test.

[Bug target/116415] [12/13/14/15 Regression][PPC64LE] atomics wrongly use vector instructions in DWCAS.

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

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

--- Comment #10 from Peter Bergner  ---
Fixed on trunk with a slightly different (but functionally identical) patch
than posted above.  I'll let it sit there for a few days to ensure we didn't
expose any other issues with the patch before backporting it to the release
branches.

[Bug c++/113457] Nesting coroutine definitions (e.g. via a lambda or a template expansion) can ICE the compiler

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

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

Arsen Arsenović  changed:

   What|Removed |Added

Summary|Trying to emulate   |Nesting coroutine
   |views::concat with  |definitions (e.g. via a
   |std::generator gives ICE on |lambda or a template
   |co_yield: "internal |expansion) can ICE the
   |compiler error: in  |compiler
   |canonicalize_component_ref, |
   |at gimplify.cc" |
   Assignee|unassigned at gcc dot gnu.org  |arsen at gcc dot gnu.org
 Status|NEW |ASSIGNED

--- Comment #8 from Arsen Arsenović  ---
reduced more:

#include 

struct coro
{
  struct promise_type
  {
std::suspend_never initial_suspend ();
std::suspend_never final_suspend () noexcept;
void return_void ();
void unhandled_exception ();
coro get_return_object ();
  };
};

struct not_quite_suspend_never : std::suspend_never
{};

coro
foo ()
{
  co_await std::suspend_never{},
[] () -> coro { co_return; },
co_await not_quite_suspend_never{};
}

[Bug c/83324] [feature request] Pragma or special syntax for guaranteed tail calls

[lucier at math dot purdue.edu via Gcc-bugs]

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

--- Comment #30 from lucier at math dot purdue.edu ---
Thanks.

I asked for some help in testing this new attribute at gcc-help:

https://gcc.gnu.org/pipermail/gcc-help/2024-August/143676.html

[Bug middle-end/116358] [15 Regression] undefined reference to `__umindi3' at -O3 when compiling with SVE since r15-2890-g72c9b5f438f22c

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

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

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Philipp Tomsich :

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

commit r15-3137-gc9e2d0ec6eabc2a6b8c00984b2b2bc48565bb99b
Author: Manolis Tsamis 
Date:   Thu Aug 22 02:59:11 2024 -0700

ifcvt: disallow call instructions in noce_convert_multiple_sets [PR116358]

Similar to not allowing jump instructions in the generated code, we
also shouldn't allow call instructions in noce_convert_multiple_sets.
In the case of PR116358 a libcall was generated from force_operand.

PR middle-end/116358

gcc/ChangeLog:

* ifcvt.cc (noce_convert_multiple_sets): Disallow call insns.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/pr116358.c: New test.

[Bug rtl-optimization/116405] [15 regression] wrong code at -O{2,3} with "-fno-ssa-phiopt -fno-tree-dce" on x86_64-linux-gnu since r15-2890-g72c9b5f438f22c

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Philipp Tomsich :

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

commit r15-3138-ga9f5e23aba1a6f4ec32f1147b340a8145d827da9
Author: Manolis Tsamis 
Date:   Tue Aug 20 09:16:29 2024 +0200

ifcvt: Do not overwrite results in noce_convert_multiple_sets [PR116372,
PR116405]

Now that more operations are allowed for noce_convert_multiple_sets,
it is possible that the same register appears multiple times as target
in a basic block.  After noce_convert_multiple_sets_1 is called we
potentially also emit register moves from temporaries back to the
original targets.  In some cases where the target registers overlap
with the block's condition, these register moves may overwrite
intermediate variables because they're emitted after the if-converted
code.  To address this issue we now iterate backwards and keep track
of seen registers when emitting these final register moves.

PR rtl-optimization/116372
PR rtl-optimization/116405

gcc/ChangeLog:

* ifcvt.cc (noce_convert_multiple_sets): Iterate backwards and
track
target registers.

gcc/testsuite/ChangeLog:

* gcc.dg/pr116372.c: New test.
* gcc.dg/pr116405.c: New test.

[Bug rtl-optimization/116372] [15 Regression] Ada bootstrap failure ada/gcc-interface/trans.cc:6423 since r15-2890-g72c9b5f438f22c

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

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

--- Comment #10 from GCC Commits  ---
The master branch has been updated by Philipp Tomsich :

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

commit r15-3138-ga9f5e23aba1a6f4ec32f1147b340a8145d827da9
Author: Manolis Tsamis 
Date:   Tue Aug 20 09:16:29 2024 +0200

ifcvt: Do not overwrite results in noce_convert_multiple_sets [PR116372,
PR116405]

Now that more operations are allowed for noce_convert_multiple_sets,
it is possible that the same register appears multiple times as target
in a basic block.  After noce_convert_multiple_sets_1 is called we
potentially also emit register moves from temporaries back to the
original targets.  In some cases where the target registers overlap
with the block's condition, these register moves may overwrite
intermediate variables because they're emitted after the if-converted
code.  To address this issue we now iterate backwards and keep track
of seen registers when emitting these final register moves.

PR rtl-optimization/116372
PR rtl-optimization/116405

gcc/ChangeLog:

* ifcvt.cc (noce_convert_multiple_sets): Iterate backwards and
track
target registers.

gcc/testsuite/ChangeLog:

* gcc.dg/pr116372.c: New test.
* gcc.dg/pr116405.c: New test.

[Bug debug/116470] [15 regression] Enabling -gvariable-location-views breaks Solaris/x86 bootstrap

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #10 from Bernd Edlinger  ---
And the other issue could be this:

@@ -28976,7 +28982,7 @@ dwarf2out_set_ignored_loc (unsigned int line, unsigned
int column,
   dw_fde_ref fde = cfun->fde;

   fde->ignored_debug = false;
-  set_cur_line_info_table (function_section (fde->decl));
+  set_cur_line_info_table (current_function_section ());

   dwarf2out_source_line (line, column, filename, 0, true);
 }

set_ignored_loc seems to switch to the wrong table...

[Bug c/116474] GCC somehow confuses "unsigned typedef_t" with a nested function

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Summary|GCC somehow confuses|GCC somehow confuses
   |"unsigned __int128_t" with  |"unsigned typedef_t" with a
   |a nested function   |nested function
 Ever confirmed|0   |1
   Last reconfirmed||2024-08-23

--- Comment #1 from Andrew Pinski  ---
__int128_t is a typedef.

The same result can be show with just a normal typedef:
```
typedef int typedef_t;
int main(){
unsigned typedef_t x = 0;
}
```

[Bug c/116474] GCC somehow confuses "unsigned typedef_t" with a nested function

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

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

--- Comment #2 from Andrew Pinski  ---
Looks like the parser thinks typedef_t starts the name of a nested function ...

[Bug target/116472] Wrong offset format when generating assembly with -S and -masm=intel

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-08-23
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Andrew Pinski  ---
I can't reproduce this with the trunk nor with GCC 14, I get:
```
main:
.LFB0:
.cfi_startproc
lea ecx, [esp+4]
.cfi_def_cfa 1, 0
and esp, -16
pushDWORD PTR [ecx-4]
pushebp
mov ebp, esp
.cfi_escape 0x10,0x5,0x2,0x75,0
pushecx
.cfi_escape 0xf,0x3,0x75,0x7c,0x6
sub esp, 20
mov DWORD PTR [ebp-16], 123
mov DWORD PTR [ebp-12], 456
mov edx, DWORD PTR [ebp-12]
mov eax, DWORD PTR [ebp-16]
sub esp, 4
pushedx
pusheax
pushOFFSET FLAT:.LC0
callprintf
add esp, 16
mov eax, 0
mov ecx, DWORD PTR [ebp-4]
.cfi_def_cfa 1, 0
leave
.cfi_restore 5
lea esp, [ecx-4]
.cfi_def_cfa 4, 4
ret

```

Are you sure you don't have some patch which breaks this?

[Bug target/116472] Wrong offset format when generating assembly with -masm=intel and -fPIE/-fPIC

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Wrong offset format when|Wrong offset format when
   |generating assembly with -S |generating assembly with
   |and -masm=intel |-masm=intel and -fPIE/-fPIC
 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #2 from Andrew Pinski  ---
Oh -fPIE is needed to get the "broken" assembly.

[Bug tree-optimization/49857] [patch] Put constant switch-tables into flash

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|WONTFIX |---

[Bug c++/116469] Inconsistent Zero Initialization of Nested Structures

[jonassonarvid02 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Arvid Jonasson  ---
Quick update: I initially overlooked that the classes were aggregate types,
which don't require zero-initialization. However, the issue persists with
non-aggregate types. To demonstrate this, I've modified example 1 for Outer1
and Outer3 by making the dummy integer private, which makes them non-aggregate
(https://eel.is/c++draft/dcl.init.aggr#1.2).


--
#include 

struct Inner {
Inner(){}
unsigned char arr[10];
};

// Struct 1: Zero-initialized
struct Outer1 {
private:
int dummy;
public:
Inner inner;
};

// Struct 3: Not zero-initialized
struct Outer3 {
public:
Inner inner;
private:
int dummy;
};

int main() {
std::cout << "Outer1:\n";
for(int i = 0; i < 2; ++i) {
unsigned char counter = 0;
Outer1 outer{};
for(auto &c : outer.inner.arr) {
std::cout << int(c) << ' ';
c = counter++;
}
std::cout << '\n';
}

std::cout << "Outer3:\n";
for(int i = 0; i < 2; ++i) {
unsigned char counter = 0;
Outer3 outer{};
for(auto &c : outer.inner.arr) {
std::cout << int(c) << ' ';
c = counter++;
}
std::cout << '\n';
}
}
--

Output:
arvidjonasson@Arvids-MacBook-Air ~/testZeroInit
% g++-14 -O3 -std=c++11 -Wall -Wextra example1.cpp -o example1.out -save-temps
arvidjonasson@Arvids-MacBook-Air ~/testZeroInit
% ./example1.out
Outer1:
0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 
Outer3:
0 0 0 0 0 1 2 3 4 5 
0 1 2 3 4 5 6 7 8 9

--
Expected behavior:
Both Outer1 and Outer3 objects should be list-initialized
(https://eel.is/c++draft/dcl.init#list-3.5), leading to value-initialization.
This should zero-initialize the objects before default-initializing them
(https://eel.is/c++draft/dcl.init#general-9), resulting in all zeroes being
printed.

Actual behaviour:
 * Outer1 is properly zero-initialized.
 * Outer3 is not properly zero-initialized.

[Bug tree-optimization/115544] ICE: in lower_complexexpr_stmt, at gimple-lower-bitint.cc:4719 with -O -fno-tree-fre -fno-tree-ccp -fno-tree-forwprop and _BitInt() __builtin_mul_overflow()

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> I am not sure if complex lowering should do some simple DCE or if it matters
> if it does not do it.

Note complex lowering now does the simple DCE after r15-3128-gde1923f9f4d534 :
Removing dead stmt:_6 = COMPLEX_EXPR ;

And the unused statement is removed.

[Bug target/115054] __float128 and _Float16 use incorrect ABI on x86-64 MinGW

[tmgross at umich dot edu via Gcc-bugs]

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

--- Comment #7 from Trevor Gross  ---
(In reply to connor horman from comment #6)
> According to: https://cs61.seas.harvard.edu/site/pdf/x86-64-abi-20210928.pdf
> 
> > Arguments of types _Float16, float, double, _Decimal32, _Decimal64 and 
> > __m64 are
> in class SSE.
> 
> So `_Float16` is SSE as well.

I must have been looking at an ancient version of the psABI, it looks like
_Float16 was added five years ago [1]. Thanks for the update.

I think all of this is substantial enough reasoning for GCC to be the one to
change its behavior. If Microsoft winds up adding these types then it seems
rather likely for them to follow the precedent of SysV and their own
float/double ABI, especially if the MinGW ecosystem does the same.

Doesn't help anything here but I found some discussion on MSVC
_Float16/_Float128 at [2].

[1]:
https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/71d1183e7bb95e9f8ad732e0f2b5a4f127796e2a
[2]:
https://developercommunity.visualstudio.com/t/Implement-the-C23-Extended-Precision-P/10374212?viewtype=all

[Bug c++/112666] Missed optimization: Value initialization zero-initializes members with user-defined constructor

[jonassonarvid02 at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Arvid Jonasson  ---
(In reply to Jonathan Wakely from comment #1)
> 
> C does not have a user-provided default constructor, so value-initialization
> means:
> 
> "- the object is zero-initialized and the semantic constraints for
> default-initialization are checked, and if T has a non-trivial default
> constructor, the object is default-initialized;"
> 

>From my understanding, since C is an aggregate type, it should be initialized
using aggregate initialization as outlined in [dcl.init.list]
(https://eel.is/c++draft/dcl.init#list-3.4). This process should construct the
b member without first zero-initializing it, as specified in [dcl.init.aggr]
(https://eel.is/c++draft/dcl.init#aggr-5.2), [dcl.init.list]
(https://eel.is/c++draft/dcl.init#list-3.5) and [dcl.init.general]
(https://eel.is/c++draft/dcl.init#general-9.1).

Given this, it seems that the inclusion of the memset instruction might be
unnecessary. Could someone confirm whether this interpretation is correct? If
so, it might be worth revisiting and potentially reopening the issue.

[Bug c++/116469] Inconsistent Zero Initialization of Nested Structures

[jonassonarvid02 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Arvid Jonasson  ---
Modified Example 2 with non-aggregate types:

--
#include 
#include 
#include 

template
struct Inner {
Inner() {}
unsigned char arr[N];
};


struct Outer1 {
template
class Outer {
int dummy;
Inner inner;
public:
Inner& getInner() { return inner; }
};
};

struct Outer2 {
template
class Outer {
Inner inner;
public:
Inner& getInner() { return inner; }
};
};

struct Outer3 {
template
class Outer {
Inner inner;
int dummy;
public:
Inner& getInner() { return inner; }
};
};

template
bool isZeroInit() {
for(int i = 0; i < 2; i++) {
typename T::template Outer outer{};
for(auto &c : outer.getInner().arr) {
if(c != 0) {
return false;
}
c = 1;
}
}
return true;
}

template 
auto checkZeroInit(std::vector v, std::integer_sequence)
{
if constexpr (N != 0)
v.push_back(isZeroInit());
return v;
}

template 
auto checkZeroInit(std::vector v, std::integer_sequence) {
if constexpr (N != 0)
v.push_back(isZeroInit());
return checkZeroInit(std::move(v), std::integer_sequence{});
}


int main() {
auto v = checkZeroInit(std::vector{},
std::make_integer_sequence{});
std::cout << "Outer1: ";
for(auto b : v)
std::cout << b;
std::cout << std::endl;

v = checkZeroInit(std::vector{},
std::make_integer_sequence{});
std::cout << "Outer2: ";
for(auto b : v)
std::cout << b;
std::cout << std::endl;

v = checkZeroInit(std::vector{},
std::make_integer_sequence{});
std::cout << "Outer3: ";
for(auto b : v)
std::cout << b;
std::cout << std::endl;
return 0;
}
--

Output:
arvidjonasson@Arvids-MacBook-Air ~/testZeroInit
% g++-14 -O3 -std=c++17 -Wall -Wextra example2.cpp -o example2.out

--[ lots of -Wmaybe-uninitialized warnings ]--

inlined from 'int main()' at example2.cpp:83:30:
example2.cpp:46:18: warning:
'outer.Outer3::Outer<17>::inner.Inner<17>::arr[16]' may be used uninitialized
[-Wmaybe-uninitialized]
   46 | if(c != 0) {
  |~~^~~~
example2.cpp: In function 'int main()':
example2.cpp:44:39: note: 'outer' declared here
   44 | typename T::template Outer outer{};
  |
arvidjonasson@Arvids-MacBook-Air ~/testZeroInit
% ./example2.out  
Outer1:
110101101110111011101110111011101110111011101110111011101110111011101110111011101110111011101110111011101110111011101110111011101110111011101110111011101110111011101110111011101110111011101110111011101110111011101110111011101110111011101110111
Outer2:
1110100
Outer3:
1000111
--

Expected behaviour:
Program should output all 1's since all objects should be zero initialized.

Actual behaviour:
Program doesn't output all 1's since all objects are not zero initialized.

[Bug tree-optimization/116460] ppc64le: LTO ICE during GIMPLE pass: forwprop

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

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

--- Comment #6 from Andrew Pinski  ---
So the good news is I am able to reproduce it on the trunk (on cfarm29 which is
powerpc64le):
```
pinskia@cfarm29:~/src/t$ ~/ugcc/bin/g++ -shared -fPIC -g -O3 -flto *.ii
lto-wrapper: warning: using serial compilation of 11 LTRANS jobs
lto-wrapper: note: see the ‘-flto’ option documentation for more information
during GIMPLE pass: forwprop
../../../../tmp/lerc/src/LercLib/Lerc.cpp: In function
‘EncodeInternal.constprop’:
../../../../tmp/lerc/src/LercLib/Lerc.cpp:606:9: internal compiler error: in
build2, at tree.cc:5103
0x120f7dff internal_error(char const*, ...)
/home/pinskia/src/gcc/gcc/diagnostic-global-context.cc:491
0x102ebbdf fancy_abort(char const*, int, char const*)
/home/pinskia/src/gcc/gcc/diagnostic.cc:1772
0x110963bb build2(tree_code, tree_node*, tree_node*, tree_node*)
/home/pinskia/src/gcc/gcc/tree.cc:5103
0x103ef03b gimple_assign_rhs_to_tree(gimple*)
/home/pinskia/src/gcc/gcc/cfgexpand.cc:116
0x10f69763 insert_debug_temp_for_var_def(gimple_stmt_iterator*, tree_node*)
/home/pinskia/src/gcc/gcc/tree-ssa.cc:408
0x10f69c67 insert_debug_temps_for_defs(gimple_stmt_iterator*)
/home/pinskia/src/gcc/gcc/tree-ssa.cc:506
0x1069cd6b gsi_remove(gimple_stmt_iterator*, bool)
/home/pinskia/src/gcc/gcc/gimple-iterator.cc:568
0x10db4d63 simple_dce_from_worklist(bitmap_head*, bitmap_head*)
/home/pinskia/src/gcc/gcc/tree-ssa-dce.cc:2263
0x10dd68ff execute
/home/pinskia/src/gcc/gcc/tree-ssa-forwprop.cc:4154
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.
lto-wrapper: fatal error: /home/pinskia/ugcc/bin/g++ returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

```

[Bug tree-optimization/116460] ppc64le: LTO ICE during GIMPLE pass: forwprop

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

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

--- Comment #7 from Andrew Pinski  ---
Created attachment 58988
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58988&action=edit
non-reduced preprocessed source

This is just the needed 2 preprocessed source to reproduce the failure:
pinskia@cfarm29:~/src/t$ /home/pinskia/ugcc/bin/g++ -Wfatal-errors -shared
-fPIC -g -O3 -flto a-Lerc.ii a-Lerc2.ii
lto-wrapper: warning: using serial compilation of 9 LTRANS jobs
lto-wrapper: note: see the ‘-flto’ option documentation for more information
during GIMPLE pass: forwprop
../../../../tmp/lerc/src/LercLib/Lerc.cpp: In function
‘EncodeInternal.constprop’:
../../../../tmp/lerc/src/LercLib/Lerc.cpp:606:9: internal compiler error: in
build2, at tree.cc:5103

[Bug tree-optimization/116463] [15 Regression] fast-math-complex-mls-{double,float}.c fail after r15-3087-gb07f8a301158e5

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

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Richard Biener from comment #8)
> fail which look similar to the aarch64 fails (I have no idea if the patch
> helped for those).

The aarch64 ones still fail. And yes they look very similar.

[Bug tree-optimization/116460] [14/15 Regression] LTO ICE with -g during GIMPLE pass: forwprop

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ppc64le: LTO ICE during |[14/15 Regression] LTO ICE
   |GIMPLE pass: forwprop   |with -g during GIMPLE pass:
   ||forwprop
   Target Milestone|--- |14.3

--- Comment #8 from Andrew Pinski  ---
./a.ltrans6.ltrans.212t.forwprop4

Removing dead stmt noDataCandVec$_M_start_888 = PHI <_1783(176), _577(186)>
...
Removing dead stmt:_598 = _888 + 16;

So it looks like we remove the statement defining _888 and then removing the
use.
The removal of _888 happens directly from forwprop while _598 definition
removal comes from simple_dce_from_worklist .

The ICE happens because the ssa name _888 has already been freed so the type is
null (and not in this case a pointer) since this was originally a pointer plus.

Trying to reduce this further.

[Bug ada/116438] Ada FE should use libbacktrace to print backtraces on ICE with bug boxes

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

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

--- Comment #4 from Eric Gallager  ---
(In reply to Eric Botcazou from comment #3)
> In my experience a backtrace is not sufficient to debug compiler issues.

It might not be sufficient on its own, but it'd at least be an improvement

[Bug tree-optimization/116475] New: autovect: may be optimized for min/max

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

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

Bug ID: 116475
   Summary: autovect: may be optimized for min/max
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: syq at gcc dot gnu.org
  Target Milestone: ---

If we need get the minimal of 8 floats in an array.
We may have code like this

float min(float *x) {
float ret = x[0];
for (int i=0; i<8; i++) {   // from 0 in this line
ret = ret

[Bug tree-optimization/116475] autovect: may be optimized for min/max

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||53947

--- Comment #1 from Andrew Pinski  ---
I thought I saw this before.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug tree-optimization/116475] autovect: may be optimized for min/max

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug tree-optimization/116475] autovect: may be optimized for min/max

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Yep pr 102512

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

[Bug tree-optimization/102512] Redundant max/min operation before vector reduction

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||syq at gcc dot gnu.org

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

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

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

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

Bug 116475 Summary: autovect: may be optimized for min/max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116475

   What|Removed |Added

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

[Bug target/55212] [SH] Switch to LRA

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

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

--- Comment #187 from Kazumoto Kojima  ---
Created attachment 58989
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58989&action=edit
a testcase for wrong code which is pre-processed gcc/gimple-fold.cc

One other segfault is seen when compiling libgcc/libgcov-driver.c. 
It seems that gcc/gimple-fold.cc: fold_const_aggregate_ref_1(tree_node*,
tree_node* (*)(tree_node*)) is miscompiled with -O2 -mlra.  The asm code
sequences in question are

[-O2 -mno-lra]
...
mov.l   .L13907,r1  ! 2387  [c=10 l=2]  movsi_ie/0
mov #0,r6   ! 2383  [c=4 l=2]  movsi_ie/2
mov.l   r3,@(4,r0)  ! 542   [c=4 l=2]  movsi_ie/8
mov.l   r5,@(8,r0)  ! 546   [c=4 l=2]  movsi_ie/8
mov #96,r0  ! 2385  [c=4 l=2]  movsi_ie/2
mov.l   r3,@(8,r15) ! 556   [c=4 l=2]  movsi_ie/8
mov.l   r5,@(4,r15) ! 558   [c=4 l=2]  movsi_ie/8
mov.l   r3,@r15 ! 560   [c=4 l=2]  movsi_ie/8
mov.l   r6,@(16,r15)! 552   [c=4 l=2]  movsi_ie/8
mov.l   r6,@(12,r15)! 554   [c=4 l=2]  movsi_ie/8
mov.l   @(r0,r15),r6! 563   [c=3 l=2]  movsi_ie/5
mov.l   @(56,r15),r5! 564   [c=1 l=2]  movsi_ie/5
jsr @r1 ! 566   [c=5 l=2]  call_valuei
mov.l   @(60,r15),r4! 565   [c=1 l=2]  movsi_ie/5
mov.l   @(60,r15),r10   ! 2388  [c=1 l=2]  movsi_ie/5
mov r0,r7   ! 1828  [c=4 l=2]  movsi_ie/1
mov.l   @(56,r15),r4! 576   [c=1 l=2]  movsi_ie/5
mov.l   r0,@(16,r10)! 570   [c=4 l=2]  movsi_ie/8
mov r10,r5  ! 577   [c=4 l=2]  movsi_ie/1
mov.l   .L13908,r10 ! 2389  [c=10 l=2]  movsi_ie/0
jsr @r10! 579   [c=1 l=2]  block_lump_real_i4/0
mov #1,r6   ! 578   [c=4 l=2]  movsi_ie/2

[-O2 -mlra]
...
mov.l   .L13994,r14 ! 2172  [c=10 l=2]  movsi_ie/0
mov.l   r0,@(16,r10)! 524   [c=4 l=2]  movsi_ie/8
mov #1,r6   ! 532   [c=4 l=2]  movsi_ie/2
mov.l   r0,@(56,r15)! 2562  [c=4 l=2]  movsi_ie/8
jsr @r14! 533   [c=1 l=2]  block_lump_real_i4/0
mov r10,r5  ! 531   [c=4 l=2]  movsi_ie/1
mov.l   @(40,r15),r7! 2173  [c=1 l=2]  movsi_ie/5
mov #0,r3   ! 2694  [c=4 l=2]  movsi_ie/2
mov #8,r2   ! 2693  [c=4 l=2]  movsi_ie/2
mov.w   .L13995,r1  ! 2561  [c=10 l=2]  *movhi/0
mov.l   r2,@(44,r7) ! 2695  [c=4 l=2]  movsi_ie/8
mov r4,r5   ! 567   [c=4 l=2]  movsi_ie/1
mov.l   r3,@(48,r7) ! 2696  [c=4 l=2]  movsi_ie/8
mov r10,r4  ! 568   [c=4 l=2]  movsi_ie/1
mov.l   @(60,r15),r7! 2419  [c=1 l=2]  movsi_ie/5
mov.l   .L13996,r2  ! 2566  [c=10 l=2]  movsi_ie/0
mov.l   r7,@r13 ! 541   [c=4 l=2]  movsi_ie/8
mov.l   r1,@(8,r13) ! 549   [c=4 l=2]  movsi_ie/8
mov.l   r12,@(4,r13)! 2176  [c=4 l=2]  movsi_ie/8
mov.l   @(56,r15),r6! 566   [c=1 l=2]  movsi_ie/5
mov.l   r1,@(4,r15) ! 561   [c=4 l=2]  movsi_ie/8
mov.l   r11,@(16,r15)   ! 2179  [c=4 l=2]  movsi_ie/8
mov.l   r11,@(12,r15)   ! 2180  [c=4 l=2]  movsi_ie/8
mov.l   r12,@(8,r15)! 2181  [c=4 l=2]  movsi_ie/8
jsr @r2 ! 569   [c=5 l=2]  call_valuei
mov.l   r12,@r15! 2183  [c=4 l=2]  movsi_ie/8
mov #1,r6   ! 581   [c=4 l=2]  movsi_ie/2
mov.l   r0,@(16,r10)! 573   [c=4 l=2]  movsi_ie/8
mov r0,r7   ! 1839  [c=4 l=2]  movsi_ie/1
jsr @r14! 582   [c=1 l=2]  block_lump_real_i4/0
mov r10,r5  ! 580   [c=4 l=2]  movsi_ie/1

In the latter case,  the last jsr @r14 that is calling __movstr_i4_odd libgcc
asm function of which arguments are r4, r5, r6.  We can't see any explicit insn
to set r4 after jsr@r2 that is calling wi::mul_internal c++ function which may
clobber r4.  We can find mov.l   @(56,r15),r4 before jsr @r10 which is
__movstr_i4_odd call in the former -mno-lra case.

In the -mlra case, r4 is 0x1 when  __movstr_i4_odd is called.  Looks a wrong
code.

[Bug target/55212] [SH] Switch to LRA

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

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

--- Comment #188 from Kazumoto Kojima  ---
(In reply to Kazumoto Kojima from comment #187)

Looking at the RTL dumps in -mlra case, there is an instruction to set r4 in
the postreload dump:

(insn 579 573 580 49 (set (reg:SI 4 r4)
(reg/f:SI 11 r11 [1021])) "/git/gcc/gcc/wide-int.h":822:94 191
{movsi_ie}
 (expr_list:REG_EQUAL (plus:SI (reg/f:SI 153 sfp)
(const_int -88 [0xffa8]))
(nil)))
(insn 580 579 581 49 (set (reg:SI 5 r5)
(reg/f:SI 10 r10 [1023])) "/git/gcc/gcc/wide-int.h":822:94 191
{movsi_ie}
 (expr_list:REG_EQUAL (plus:SI (reg/f:SI 153 sfp)
(const_int -60 [0xffc4]))
(nil)))
(insn 581 580 2186 49 (set (reg:SI 6 r6)
(const_int 1 [0x1])) "/git/gcc/gcc/wide-int.h":822:94 191 {movsi_ie}
 (nil))
(note 2186 581 582 49 NOTE_INSN_DELETED)
(insn 582 2186 2187 49 (parallel [
(set (mem:BLK (reg:SI 4 r4) [0  A8])
(mem:BLK (reg:SI 5 r5) [0  A8]))
(use (reg:SI 14 r14 [1193]))
(use (const_int 0 [0]))
(use (reg:SI 6 r6))
(clobber (reg:SI 146 pr))
(clobber (reg:SI 147 t))
(clobber (reg:SI 4 r4))
(clobber (reg:SI 5 r5))
(clobber (reg:SI 6 r6))
(clobber (reg:SI 0 r0))
(clobber (reg:SI 1 r1))
(clobber (reg:SI 2 r2))
(clobber (reg:SI 3 r3))
]) "/git/gcc/gcc/wide-int.h":822:94 326 {block_lump_real_i4}
 (nil))

but the insn 579 is dissapeared in late_combine2 dump:

(insn 573 1839 580 49 (set (mem/c:SI (plus:SI (reg/f:SI 10 r10 [1023])
(const_int 16 [0x10])) [6 MEM[(struct fixed_wide_int_storage
*)_301].len+0 S4 A32])
(reg:SI 7 r7 [1042])) "/git/gcc/gcc/wide-int.h":1435:7 191 {movsi_ie}
 (nil))
(insn 580 573 581 49 (set (reg:SI 5 r5)
(reg/f:SI 10 r10 [1023])) "/git/gcc/gcc/wide-int.h":822:94 191
{movsi_ie}
 (expr_list:REG_EQUAL (plus:SI (reg/f:SI 153 sfp)
(const_int -60 [0xffc4]))
(nil)))

I confirmed that -fno-late-combine-instructions fixes this issue.  I'm not sure
what is going on, though.
As pointed out in c#184, -fno-late-combine-instructions doesn't help __muldi3
case.

[Bug target/55212] [SH] Switch to LRA

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

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

--- Comment #189 from Kazumoto Kojima  ---
There is another segfault during compiling libgcc/fp-bit.c.
In that case, the 2nd visit to tree-ssa-sccvn.cc:3567 in vn_reference_lookup_3

  FOR_EACH_VEC_ELT (rhs, j, vro)
vr->operands[i + 1 + j] = *vro;

shows a bad *vro in the 2nd iteration of this FOR_EACH_VEC_ELT:

(gdb) p *vro
$13 = {opcode = 0x17, clique = 0x0, base = 0x19, reverse = 0x0, align = 0x0, 
  off = {coeffs = {0x1a001b}}, type = 0x1c, op0 = 0x1e, op1 = 0x20, 
  op2 = 0x21}

where the type and op[0-2] fields are pointers with wrong value.
The fault is avoided with compiling tree-ssa-sccvn.cc and tree-ssa-alias.cc
with -O0 -mlra.  This issue may be hard to investigate because the function
vn_reference_lookup_3 is huge and complex.

[Bug target/55212] [SH] Switch to LRA

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

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

--- Comment #190 from Kazumoto Kojima  ---
Another two segfaults are observed when building libstdc++v3.

Compiling   Segfault in
libsupc++/dyncast.cctree-ssa-reassoc.cc
src/c++11/locale-inst.cctree-ssa-strlen.cc

I have not looked into these in detail yet.
Anyway, the target libgcc & libstdc++v3 can be built successfuly when the files

gimple-fold.cc
pointer-query.cc
tree-ssa-sccvn.cc tree-ssa-alias.cc
tree-ssa-reassoc.cc
tree-ssa-strlen.cc

were compiled with -O0 -mlra.

[Bug target/55212] [SH] Switch to LRA

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

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

--- Comment #191 from Oleg Endo  ---
(In reply to Kazumoto Kojima from comment #188)
> (In reply to Kazumoto Kojima from comment #187)
> 
> Looking at the RTL dumps in -mlra case, there is an instruction to set r4 in
> the postreload dump:
> 
> (insn 579 573 580 49 (set (reg:SI 4 r4)
> (reg/f:SI 11 r11 [1021])) "/git/gcc/gcc/wide-int.h":822:94 191
> {movsi_ie}
>  (expr_list:REG_EQUAL (plus:SI (reg/f:SI 153 sfp)
> (const_int -88 [0xffa8]))
> (nil)))
> (insn 580 579 581 49 (set (reg:SI 5 r5)
> (reg/f:SI 10 r10 [1023])) "/git/gcc/gcc/wide-int.h":822:94 191
> {movsi_ie}
>  (expr_list:REG_EQUAL (plus:SI (reg/f:SI 153 sfp)
> (const_int -60 [0xffc4]))
> (nil)))
> (insn 581 580 2186 49 (set (reg:SI 6 r6)
> (const_int 1 [0x1])) "/git/gcc/gcc/wide-int.h":822:94 191 {movsi_ie}
>  (nil))
> (note 2186 581 582 49 NOTE_INSN_DELETED)
> (insn 582 2186 2187 49 (parallel [
> (set (mem:BLK (reg:SI 4 r4) [0  A8])
> (mem:BLK (reg:SI 5 r5) [0  A8]))
> (use (reg:SI 14 r14 [1193]))
> (use (const_int 0 [0]))
> (use (reg:SI 6 r6))
> (clobber (reg:SI 146 pr))
> (clobber (reg:SI 147 t))
> (clobber (reg:SI 4 r4))
> (clobber (reg:SI 5 r5))
> (clobber (reg:SI 6 r6))
> (clobber (reg:SI 0 r0))
> (clobber (reg:SI 1 r1))
> (clobber (reg:SI 2 r2))
> (clobber (reg:SI 3 r3))
> ]) "/git/gcc/gcc/wide-int.h":822:94 326 {block_lump_real_i4}
>  (nil))
> 
> but the insn 579 is dissapeared in late_combine2 dump:
> 
> (insn 573 1839 580 49 (set (mem/c:SI (plus:SI (reg/f:SI 10 r10 [1023])
> (const_int 16 [0x10])) [6 MEM[(struct fixed_wide_int_storage
> *)_301].len+0 S4 A32])
> (reg:SI 7 r7 [1042])) "/git/gcc/gcc/wide-int.h":1435:7 191 {movsi_ie}
>  (nil))
> (insn 580 573 581 49 (set (reg:SI 5 r5)
> (reg/f:SI 10 r10 [1023])) "/git/gcc/gcc/wide-int.h":822:94 191
> {movsi_ie}
>  (expr_list:REG_EQUAL (plus:SI (reg/f:SI 153 sfp)
> (const_int -60 [0xffc4]))
> (nil)))
> 
> I confirmed that -fno-late-combine-instructions fixes this issue.  I'm not
> sure what is going on, though.
> As pointed out in c#184, -fno-late-combine-instructions doesn't help
> __muldi3 case.

Maybe Richard Sandiford can help with this, since he's the original author of
the late-combine, from what I remember.