[Bug c++/69549] Named Address Spaces does not compile in C++

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org
   Keywords||patch

--- Comment #11 from Xi Ruoyao  ---
Generally a patch should be sent to gcc-patc...@gcc.gnu.org.  See
https://gcc.gnu.org/contribute.html.  The patches attached to a Bugzilla ticket
are considered prototypes and for discussion only.

[Bug c++/69549] Named Address Spaces does not compile in C++

[abelay at mit dot edu via Gcc-bugs]

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

Adam Belay  changed:

   What|Removed |Added

 CC||abelay at mit dot edu

--- Comment #10 from Adam Belay  ---
I realize this bug and patch is a couple years old, but I wanted to mention
that my research group is working on a new kernel in C++ and this feature would
be very useful to us. Without it, the FS and GS segment can only be accessed
via inline assembly, which is less convenient and more difficult for GCC to
optimize.

[Bug target/112327] RVV: Redundant vmv1r for widen reduction

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

JuzheZhong  changed:

   What|Removed |Added

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

--- Comment #2 from JuzheZhong  ---
Fixed

[Bug target/112327] RVV: Redundant vmv1r for widen reduction

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

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

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

https://gcc.gnu.org/g:1a0af6e5a99cd895a663f0221c25321ae802413f

commit r14-5067-g1a0af6e5a99cd895a663f0221c25321ae802413f
Author: Juzhe-Zhong 
Date:   Wed Nov 1 14:56:39 2023 +0800

RISC-V: Allow dest operand and accumulator operand overlap of widen
reduction instruction[PR112327]

Consider this following intrinsic code:

void rvv_dot_prod(int16_t *pSrcA, int16_t *pSrcB, uint32_t n, int64_t
*result)
{
size_t vl;
vint16m4_t vSrcA, vSrcB;
vint64m1_t vSum = __riscv_vmv_s_x_i64m1(0, 1);
while (n > 0) {
vl = __riscv_vsetvl_e16m4(n);
vSrcA = __riscv_vle16_v_i16m4(pSrcA, vl);
vSrcB = __riscv_vle16_v_i16m4(pSrcB, vl);
vSum =
__riscv_vwredsum_vs_i32m8_i64m1(__riscv_vwmul_vv_i32m8(vSrcA, vSrcB, vl), vSum,
vl);
pSrcA += vl;
pSrcB += vl;
n -= vl;
}
*result = __riscv_vmv_x_s_i64m1_i64(vSum);
}

https://godbolt.org/z/vWd35W7G6

Before this patch:

...
Loop:
...
vmv1r.v v2,v1
...
vwredsum.vs v1,v8,v2
...

After this patch:

...
Loop:
...
vwredsum.vs v1,v8,v1
...

PR target/112327

gcc/ChangeLog:

* config/riscv/vector.md: Add '0'.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr112327-1.c: New test.
* gcc.target/riscv/rvv/base/pr112327-2.c: New test.

[Bug target/109933] __atomic_test_and_set is broken for BIG ENDIAN riscv targets

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #13 from Patrick O'Neill  ---
Created attachment 56487
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56487=edit
Proposed fix

Hi Rory,

Sorry that this slipped off my plate for way too long.
I just got around to refactoring the surrounding code on trunk and revised your
patch to fix this for both test_and_set along with inline subword amo
sequences.
When you have the time can you please test this using your big-endian setup?
I'll handle the little-endian testing.

Patrick

[Bug debug/112343] [14 regression] ICE during GIMPLE pass: dse

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 112320.

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

[Bug tree-optimization/112320] [14 Regression] crash from insert_debug_temp_for_var_def since r14-5032-ge3da1d7bb288c8

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||gerald at pfeifer dot com

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

[Bug target/110551] [11/12/13/14 Regression] an extra mov when doing 128bit multiply

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

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

commit r14-5063-g80b1a371008c31982d35cff9b85ca6affd3ac949
Author: Roger Sayle 
Date:   Wed Nov 1 22:33:45 2023 +

PR target/110551: Tweak mulx register allocation using peephole2.

This patch is a follow-up to my previous PR target/110551 patch, this
time to address the additional move after mulx, seen on TARGET_BMI2
architectures (such as -march=haswell).  The complication here is
that the flexible multiple-set mulx instruction is introduced into
RTL after reload, by split2, and therefore can't benefit from register
preferencing.  This results in RTL like the following:

(insn 32 31 17 2 (parallel [
(set (reg:DI 4 si [orig:101 r ] [101])
(mult:DI (reg:DI 1 dx [109])
(reg:DI 5 di [109])))
(set (reg:DI 5 di [ r+8 ])
(umul_highpart:DI (reg:DI 1 dx [109])
(reg:DI 5 di [109])))
]) "pr110551-2.c":8:17 -1
 (nil))

(insn 17 32 9 2 (set (reg:DI 0 ax [107])
(reg:DI 5 di [ r+8 ])) "pr110551-2.c":9:40 90 {*movdi_internal}
 (expr_list:REG_DEAD (reg:DI 5 di [ r+8 ])
(nil)))

Here insn 32, the mulx instruction, places its results in si and di,
and then immediately after decides to move di to ax, with di now dead.
This can be trivially cleaned up by a peephole2.  I've added an
additional constraint that the two SET_DESTs can't be the same
register to avoid confusing the middle-end, but this has well-defined
behaviour on x86_64/BMI2, encoding a umul_highpart.

For the new test case, compiled on x86_64 with -O2 -march=haswell:

Before:
mulx64: movabsq $-7046029254386353131, %rdx
mulx%rdi, %rsi, %rdi
movq%rdi, %rax
xorq%rsi, %rax
ret

After:
mulx64: movabsq $-7046029254386353131, %rdx
mulx%rdi, %rsi, %rax
xorq%rsi, %rax
ret

2023-11-01  Roger Sayle  

gcc/ChangeLog
PR target/110551
* config/i386/i386.md (*bmi2_umul3_1): Tidy condition
as operands[2] with predicate register_operand must be !MEM_P.
(peephole2): Optimize a mulx followed by a register-to-register
move, to place result in the correct destination if possible.

gcc/testsuite/ChangeLog
PR target/110551
* gcc.target/i386/pr110551-2.c: New test case.

[Bug fortran/92887] [F2008] Passing nullified/disassociated pointer or unalloc allocatable to OPTIONAL + VALUE dummy fails

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Cleaned up patch submitted:

https://gcc.gnu.org/pipermail/fortran/2023-November/059883.html

[Bug pch/112319] [14 Regression] segfault with pch and #pragma GCC diagnostic

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

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

--- Comment #2 from Lewis Hyatt  ---
Patch sent for review:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/634931.html

[Bug c/71219] Warn about (struct S*)malloc(n) where n < sizeof(struct S)

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

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

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

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

commit r14-5059-gd880e093d92084f55b10626610ef059fd9194a6a
Author: Martin Uecker 
Date:   Thu Jul 27 13:36:05 2023 +0200

c: Add Walloc-size to warn about insufficient size in allocations [PR71219]

Add option Walloc-size that warns about allocations that have
insufficient storage for the target type of the pointer the
storage is assigned to. Added to Wextra.

PR c/71219
gcc:
* doc/invoke.texi: Document -Walloc-size option.

gcc/c-family:

* c.opt (Walloc-size): New option.

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

gcc/testsuite:

* gcc.dg/Walloc-size-1.c: New test.
* gcc.dg/Walloc-size-2.c: New test.

[Bug debug/112343] New: [14 regression] ICE during GIMPLE pass: dse

[gerald at pfeifer dot com via Gcc-bugs]

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

Bug ID: 112343
   Summary: [14 regression] ICE during GIMPLE pass: dse
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerald at pfeifer dot com
  Target Milestone: ---

Created attachment 56486
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56486=edit
Preprocessed C source

This started in the last 48 hours.

/home/gerald/gcc-ref12-amd64/bin/gcc> jcparam.i -O2 -g
during GIMPLE pass: dse
jcparam.c: In function ‘jpeg_simple_progression’:
jcparam.c:514:1: internal compiler error: Segmentation fault
  514 | jpeg_simple_progression (j_compress_ptr cinfo)
  | ^~~
0x829785baf handle_signal
/usr/src/lib/libthr/thread/thr_sig.c:248
0x82978516e thr_sighandler
/usr/src/lib/libthr/thread/thr_sig.c:191

If I use -O1 instead of -O2 or omit -g the ICE goes away.

[Bug bootstrap/111653] make bootstrap4 fails for -fchecking=2 code generation changes

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

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

Sergei Trofimovich  changed:

   What|Removed |Added

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

--- Comment #2 from Sergei Trofimovich  ---
The difference on the minimized example from #comment1 disappeared with
r14-4793-gdad311874ac3b3 "c++: remove NON_DEPENDENT_EXPR, part 1".

On r14-5058-g25f92179dea308 I don't get comparison failures on 'make
bootstrap4' anymore. Let's close it as FIXED.

[Bug c++/112341] error: insufficient contextual information to determine type on co_await result in function template

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-11-01
 Ever confirmed|0   |1
   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW

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

[Bug ada/112342] New: Crash when an unexpected ampersand is encountered

[rwconnelly at hotmail dot com via Gcc-bugs]

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

Bug ID: 112342
   Summary: Crash when an unexpected ampersand is encountered
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rwconnelly at hotmail dot com
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 56485
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56485=edit
Source code & build environment information

The compiler crashes when it encounters the "&" character in the following line
of code

Bar := Foo & 16#f0#;

[Bug c++/112341] New: error: insufficient contextual information to determine type on co_await result in function template

[ed at catmur dot uk via Gcc-bugs]

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

Bug ID: 112341
   Summary: error: insufficient contextual information to
determine type on co_await result in function template
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ed at catmur dot uk
  Target Milestone: ---

#include 
struct A { int j; };
struct B {
bool await_ready();
bool await_suspend(std::coroutine_handle<>);
A await_resume();
};
struct C {
struct promise_type {
std::suspend_always initial_suspend();
std::suspend_always final_suspend() noexcept;
void unhandled_exception();
C get_return_object();
void return_void();
};
};
C f(auto) { (co_await B()).j; }
void g() { f(0); }

: In function 'C f(auto:1)':
:17:14: error: insufficient contextual information to determine type
   17 | C f(auto) { (co_await B()).j; }
  | ~^

Writing 'auto&& a = co_await B(); a.j;' or even 'auto(co_await B()).j' accepts.

[Bug testsuite/112340] New: [14 regression] assembler instruction counts off for gcc.target/powerpc/pr106550_1.c

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

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

Bug ID: 112340
   Summary: [14 regression] assembler instruction counts off for
gcc.target/powerpc/pr106550_1.c
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:9119b008b4195e06012a485ec01a8bb0e43266be, r14-5037-g9119b008b4195e

Possibly the test cases just need revision.  This is BE only issue.  I first
saw this after this revision but I don't think it is the source of the issue as
it fixed an ICE in compiling this same test case.


make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
powerpc.exp=gcc.target/powerpc/pr106550_1.c"
. . .

spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/pr106550_1.c
-m64 -fdiagnostics-plain-output -O2 -mdejagnu-cpu=power10 -fdisable-rtl-split1
-ffat-lto-objects -fno-ident -S -o pr106550_1.s
cc1: note: disable pass rtl-split1 for functions in the range of [0,
4294967295]
PASS: gcc.target/powerpc/pr106550_1.c (test for excess errors)
PASS: gcc.target/powerpc/pr106550_1.c scan-assembler-times \\mpli\\M 3
PASS: gcc.target/powerpc/pr106550_1.c scan-assembler-times \\msldi\\M 3
PASS: gcc.target/powerpc/pr106550_1.c scan-assembler-times \\moris\\M 2
PASS: gcc.target/powerpc/pr106550_1.c scan-assembler-times \\mori\\M 2

[Bug tree-optimization/110116] [12/13/14 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed

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

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

--- Comment #2 from Thomas Koenig  ---
Looks like this has been fixed in the meantime:

tkoenig@gcc188:~> gcc -O3 small.c 
small.c: In function 'main':
small.c:6:21: warning: iteration 2147483646 invokes undefined behavior
[-Waggressive-loop-optimizations]
6 | for (b = 1; b; b++)
  |~^~
small.c:6:17: note: within this loop
6 | for (b = 1; b; b++)
  | ^
tkoenig@gcc188:~> gcc --version
gcc (GCC) 14.0.0 20231101 (experimental) [master r13-4915-g9b111debbfb]
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

tkoenig@gcc188:~> cat small.c 
unsigned char a[5];
int b, d;
char c;
int main() {
  if (d) {
for (b = 1; b; b++)
  c &= d = 1;
for (; d < 5; d++)
  c &= a[d];
  }
  return 0;
}

Still interesting which revision fixed it.

[Bug middle-end/110694] [11/12/13/14 Regression] False Positive -Werror=free-nonheap-object

[roman.zilka at gmail dot com via Gcc-bugs]

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

Roman Žilka  changed:

   What|Removed |Added

 CC||roman.zilka at gmail dot com

--- Comment #2 from Roman Žilka  ---
I can see it on 13.2.1 20230826. The warning triggers even without any -W*
args. The manpage implies that shouldn't be the case.

[Bug c++/109740] -Woverloaded-virtual is too aggressive

[emerg.reanimator at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Alexander Goomenuk  ---
https://en.cppreference.com/w/cpp/language/using_declaration

# In class definition
...
If the derived class already has a member with the same name, parameter list,
and qualifications, *the derived class member hides or overrides (doesn't
conflict with) the member that is introduced from the base class*.



https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/C_002b_002b-Dialect-Options.html#index-Woverloaded-virtual

In cases where the different signatures are not an accident, the simplest
solution is to add a *using-declaration to the derived class to un-hide the
base function*, e.g. add using A::f; to B. 



These two statements contradict each other, isn't it?

[Bug sanitizer/112339] ICE with clang::no_sanitize and -fsanitize=

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-11-01
 Ever confirmed|0   |1
 CC||dodji at gcc dot gnu.org,
   ||dvyukov at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||kcc at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
  Component|c++ |sanitizer

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

Happens with both front-ends.

I wonder if we should not add the attribute if using an unknown scope.

[Bug c++/112339] New: ICE with namespaced attribute on function

[s_gccbugzilla at nedprod dot com via Gcc-bugs]

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

Bug ID: 112339
   Summary: ICE with namespaced attribute on function
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: s_gccbugzilla at nedprod dot com
  Target Milestone: ---

This, if compiled with trunk GCC or any recent major version of GCC:

```
[[clang::no_sanitize("bounds")]] void foo() 
{
}
```

... with options `-Wno-attributes=clang::no_sanitize -fsanitize=undefined`
produces ICE:

```
: In function 'void foo()':
:3:1: internal compiler error: in tree_to_uhwi, at tree.cc:6469
3 | }
  | ^
0x266430e internal_error(char const*, ...)
???:0
0xb01c2c fancy_abort(char const*, int, char const*)
???:0
0xb97938 cp_genericize(tree_node*)
???:0
0xbe33ef finish_function(bool)
???:0
0xcebe49 c_parse_file()
???:0
0xe2ceb9 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1
```

Godbolt demo: https://godbolt.org/z/hs3xqeqn1

[Bug fortran/87448] ICE at trans-expr:3417 in allocate statement with type signature using an associated variable

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

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #4 from Paul Thomas  ---
Created attachment 56484
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56484=edit
Fix for this PR

Somehow this missed being a blocker for the ASSOCIATE meta-bug.

The patch is so unbelievably simple that I am going to think about it for 24
hours, even though it regtests just fine :-)

module mod

implicit none
public

contains

function fun(cs) result(rs)
   character(len=:), allocatable :: rs
   character(len=*), intent(in) :: cs

   associate(l => len(cs))
  allocate(character(len=1+l) :: rs)
  write (rs, '(i5)') l
   end associate
end function fun

end module mod

  use mod
  character(:), allocatable :: res
  res = fun("abcd")
  if (res /= '4') stop 1
end

Gives the expected result.

Paul

[Bug c++/109740] -Woverloaded-virtual is too aggressive

[emerg.reanimator at gmail dot com via Gcc-bugs]

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

Alexander Goomenuk  changed:

   What|Removed |Added

 CC||emerg.reanimator at gmail dot 
com

--- Comment #3 from Alexander Goomenuk  ---
Let consider the following case:
- There is a base class that implement virtual assignment operator with
arbitrary input argument (not copy operator).
- There is a derived class that inherits the assignment operator from base
class.

g++ version >= 13 produces the warning in this case because implicitly-defined
copy operator of derived class pretends to hide the user defined assignment
operator of base class. The code is totally fine and the assignment operator
works as expected. 

Even worse, the warning is produced by compiler even if no implicitly-defined
copy operator is NOT generated by the compiler and the code fails to build due
to the lack of copy operator. So the warning is misleading and incorrect in
this case.

See
https://stackoverflow.com/questions/77378553/woverloaded-virtual-with-default-shallow-copy-operator
for more details.

[Bug fortran/112338] ieee_set_halting_mode only affects the master thread outside of an OpenMP parallel region

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

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

--- Comment #1 from Andrew Pinski  ---
My bet it is not described ...

[Bug middle-end/111921] [11/12/13/14 Regression] ICE with nested function after an error since r6-205-g5c4abbb8e80153

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

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

Thomas Koenig  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11/12/13/14 Regression]
   |ICE with nested function|ICE with nested function
   |after an error  |after an error since
   ||r6-205-g5c4abbb8e80153
   Keywords|needs-bisection |
 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Thomas Koenig  ---
Bisection finally found the relevant patch: r6-205-g5c4abbb8e80153

5c4abbb8e80153999b0298e4b2fe81d512f133c8 is the first bad commit
commit 5c4abbb8e80153999b0298e4b2fe81d512f133c8
Author: Marek Polacek 
Date:   Thu Apr 23 14:35:12 2015 +

re PR c/65345 (ICE with _Generic selection on _Atomic int)

PR c/65345
* c-decl.c (set_labels_context_r): New function.
(store_parm_decls): Call it via walk_tree_without_duplicates.
* c-typeck.c (convert_lvalue_to_rvalue): Use create_tmp_var_raw
instead of create_tmp_var.  Build TARGET_EXPR instead of
COMPOUND_EXPR.
(build_atomic_assign): Use create_tmp_var_raw instead of
create_tmp_var.  Build TARGET_EXPRs instead of MODIFY_EXPR.

* gcc.dg/pr65345-1.c: New test.
* gcc.dg/pr65345-2.c: New test.

From-SVN: r222370

Bisection actually needed a patch for bootstrap to succeed:

diff --git a/gcc/cp/cfns.gperf b/gcc/cp/cfns.gperf
index 68acd3d..5ecf86a 100644
--- a/gcc/cp/cfns.gperf
+++ b/gcc/cp/cfns.gperf
@@ -23,7 +23,7 @@ static unsigned int hash (const char *, unsigned int);
 #ifdef __GNUC__
 __inline
 #endif
-const char * libc_name_p (const char *, unsigned int);
+# const char * libc_name_p (const char *, unsigned int);
 %}
 %%
 # The standard C library functions, for feeding to gperf; the result is used
diff --git a/gcc/cp/cfns.h b/gcc/cp/cfns.h
index 1c6665d..ee38f6a 100644
--- a/gcc/cp/cfns.h
+++ b/gcc/cp/cfns.h
@@ -51,9 +51,6 @@ along with GCC; see the file COPYING3.  If not see
 __inline
 #endif
 static unsigned int hash (const char *, unsigned int);
-#ifdef __GNUC__
-__inline
-#endif
 const char * libc_name_p (const char *, unsigned int);
 /* maximum key range = 391, duplicates = 0 */

[Bug fortran/112338] New: ieee_set_halting_mode only affects the master thread outside of an OpenMP parallel region

[vladimir.fuka at gmail dot com via Gcc-bugs]

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

Bug ID: 112338
   Summary: ieee_set_halting_mode only  affects the master thread
outside of an OpenMP parallel region
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vladimir.fuka at gmail dot com
  Target Milestone: ---

Calling ieee_set_halting_mode only affects the master thread if other threads
already exist and the call is done outside of a parallel region. I am not sure
what the Fortran standard and the OpenMP specifications prescribe, but the
following code produces different results with GCC and with Intel.

use ieee_exceptions 

implicit none

integer, parameter :: n = 100
real :: nom(n)
integer :: denom(n)

logical :: saved_fpe_mode(size(ieee_all))
integer :: i

nom = 1
denom = 0

call ieee_set_halting_mode(ieee_overflow, .true.)
call ieee_set_halting_mode(ieee_invalid, .true.)
call ieee_set_halting_mode(ieee_divide_by_zero, .true.)

!$omp parallel
print *,"hello from a thread"
!$omp end parallel

call ieee_get_halting_mode(ieee_all, saved_fpe_mode)
call ieee_set_halting_mode(ieee_all, .false.)

!$omp parallel do
do i = 1, n
  nom(i) = nom(i) / denom(i)
end do
!$omp end parallel do


nom = min(max(0., nom), 1.)

!$omp parallel
call ieee_set_halting_mode(ieee_all, saved_fpe_mode)
!$omp end parallel

print *, nom
end




With GCC 

gfortran-13 -fopenmp -g fpe.f90

the code halts on line 28 (nom(i) = nom(i) / denom(i)) with SIGFPE:
Floating-point exception - erroneous arithmetic operation.


With Intel

ifx -qopenmp -g fpe.f90

the code does not halt and prints all 1.00s.

[Bug tree-optimization/112328] [14 Regression] ice in rdg_vertex_for_stmt, at tree-loop-distribution.cc:418

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-11-01
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

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

[Bug tree-optimization/112328] [14 Regression] ice in rdg_vertex_for_stmt, at tree-loop-distribution.cc:418

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
  Component|c   |tree-optimization
   Keywords||ice-on-valid-code
Summary|ice in rdg_vertex_for_stmt, |[14 Regression] ice in
   |at  |rdg_vertex_for_stmt, at
   |tree-loop-distribution.cc:4 |tree-loop-distribution.cc:4
   |18  |18

[Bug tree-optimization/106884] ifcombine may move shift so it shifts more than bitwidth

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

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

--- Comment #7 from Andrew Pinski  ---
PR 111000 was similar one but for LIM.

[Bug c++/112335] missed optimization on reset and assign unique_ptr

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

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

--- Comment #1 from Andrew Pinski  ---
  __old_p_6 = MEM[(struct s * &)ps1_2(D)];
  MEM[(struct s * &)ps1_2(D)] = 0B;
  if (__old_p_6 != 0B)
goto ; [53.47%]
  else
goto ; [46.53%]

   [local count: 574129752]:
  s::~s (__old_p_6);
  operator delete (__old_p_6, 1);

   [local count: 1073741824]:
  __p_4 = MEM[(struct s * &)ps2_3(D)];
  MEM[(struct s * &)ps2_3(D)] = 0B;
  __old_p_5 = MEM[(struct s * &)ps1_2(D)];

Well s::~s could touch the reference std::unique_ptr (ps1).

So this could in theory be an invalid optimization.

I am not sure if that is the only issue here though.

[Bug target/112337] New: arm: ICE in arm_effective_regno

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

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

Bug ID: 112337
   Summary: arm: ICE in arm_effective_regno
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stammark at gcc dot gnu.org
  Target Milestone: ---

Hi all,

I found this ICE when compiling CMSIS-NN with latest trunk:

./build-arm-eabi-armv8.1-m.main+mve.fp+fp.dp/install/bin/arm-eabi-gcc
-mcpu=cortex-m55
~/gnu/CMSIS-NN/Source/NNSupportFunctions/arm_nn_depthwise_conv_nt_t_padded_s8.c
-I ~/gnu/CMSIS-NN/Include/ -O3 -S
during RTL pass: ira
/home/stamar01/gnu/CMSIS-NN/Source/NNSupportFunctions/arm_nn_depthwise_conv_nt_t_padded_s8.c:
In function 'arm_nn_depthwise_conv_nt_t_padded_s8':
/home/stamar01/gnu/CMSIS-NN/Source/NNSupportFunctions/arm_nn_depthwise_conv_nt_t_padded_s8.c:172:1:
internal compiler error: in arm_effective_regno, at config/arm/arm.cc:13671
  172 | }
  | ^
0x1b590f2 arm_effective_regno
/home/stamar01/gnu/v8.X-M/src/gcc/gcc/config/arm/arm.cc:13671
0x1b5923a mve_vector_mem_operand(machine_mode, rtx_def*, bool)
/home/stamar01/gnu/v8.X-M/src/gcc/gcc/config/arm/arm.cc:13701
0x23015c2 mve_memory_operand(rtx_def*, machine_mode)
/home/stamar01/gnu/v8.X-M/src/gcc/gcc/config/arm/predicates.md:39
0x23d79fa recog_235
/home/stamar01/gnu/v8.X-M/src/gcc/gcc/config/arm/mve.md:3636
0x241db9c recog_287
/home/stamar01/gnu/v8.X-M/src/gcc/gcc/config/arm/neon.md:6161
0x24540af recog_344
/home/stamar01/gnu/v8.X-M/src/gcc/gcc/config/arm/mve.md:6390
0x2459355 recog(rtx_def*, rtx_insn*, int*)
/home/stamar01/gnu/v8.X-M/src/gcc/gcc/config/arm/sync.md:462
0x15663f5 insn_invalid_p(rtx_insn*, bool)
/home/stamar01/gnu/v8.X-M/src/gcc/gcc/recog.cc:358
0x15667ad verify_changes(int)
/home/stamar01/gnu/v8.X-M/src/gcc/gcc/recog.cc:469
0x1350f89 equiv_can_be_consumed_p
/home/stamar01/gnu/v8.X-M/src/gcc/gcc/ira-costs.cc:1767
0x13518f0 calculate_equiv_gains
/home/stamar01/gnu/v8.X-M/src/gcc/gcc/ira-costs.cc:1887
0x1351fbe find_costs_and_classes
/home/stamar01/gnu/v8.X-M/src/gcc/gcc/ira-costs.cc:2007
0x135404c ira_costs()
/home/stamar01/gnu/v8.X-M/src/gcc/gcc/ira-costs.cc:2564
0x1347e82 ira_build()
/home/stamar01/gnu/v8.X-M/src/gcc/gcc/ira-build.cc:3481
0x133d895 ira
/home/stamar01/gnu/v8.X-M/src/gcc/gcc/ira.cc:5793
0x133e215 execute
/home/stamar01/gnu/v8.X-M/src/gcc/gcc/ira.cc:6117
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.

opening this up in GDB I see that:

#1  0x01b590f3 in arm_effective_regno (op=0x76e130a8, strict=false)
at /home/stamar01/gnu/v8.X-M/src/gcc/gcc/config/arm/arm.cc:13671
13671 gcc_assert (REG_P (op));
(gdb) p debug_rtx (op)
(mem/f/c:SI (plus:SI (reg/f:SI 103 afp)
(const_int 28 [0x1c])) [2 output_bias+0 S4 A32])


And slightly further up:

#3  0x023015c3 in mve_memory_operand (op=0x76e24b70,
mode=E_V4SImode) at
/home/stamar01/gnu/v8.X-M/src/gcc/gcc/config/arm/predicates.md:39
39  && mve_vector_mem_operand (GET_MODE (op), XEXP (op,
0),
(gdb) p debug_rtx (op)
(mem:V4SI (post_inc:SI (mem/f/c:SI (plus:SI (reg/f:SI 103 afp)
(const_int 28 [0x1c])) [2 output_bias+0 S4 A32])) [0
MEM[(int[4] *)bias_176]+0 S16 A32])



I've started a bisect.

[Bug rtl-optimization/111835] Suboptimal codegen: zero extended load instead of sign extended one

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Siarhei Volkau from comment #3)
> I don't think that it is duplicate of the bug 104387 because there's only
> one store.
> And this bug is simply disappears if we change the source code a bit.
> e.g.
>  - change (int8_t)*src; to *(int8_t*)src;
> or change argument uint8_t * dst to int8_t * dst
> 
> But if we have multiple stores, extension will remain in any condition.

One store but 2 uses.

[Bug sanitizer/112336] fsanitize=address vs _BitInt with a non-mode size (smaller than max mode size)

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

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

--- Comment #2 from Andrew Pinski  ---
Well sizes than 128 that is.

[Bug sanitizer/112336] fsanitize=address vs _BitInt with a non-mode size (smaller than max mode size)

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |sanitizer
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-11-01
Summary|ICE in gen_reg_rtx  |fsanitize=address vs
   |emit-rtl.cc:1208 while  |_BitInt with a non-mode
   |compiling "unsigned |size (smaller than max mode
   |_BitInt(1) Foo;" with   |size)
   |-fsanitize=address  |
 CC||dodji at gcc dot gnu.org,
   ||dvyukov at gcc dot gnu.org,
   ||kcc at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org,
   ||pinskia at gcc dot gnu.org

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

8, 16, 32, and 64 all work.
Any other size does not.

[Bug target/112336] New: ICE in gen_reg_rtx emit-rtl.cc:1208 while compiling "unsigned _BitInt(1) Foo;" with -fsanitize=address

[fkastl at suse dot cz via Gcc-bugs]

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

Bug ID: 112336
   Summary: ICE in gen_reg_rtx emit-rtl.cc:1208 while compiling
"unsigned _BitInt(1) Foo;" with -fsanitize=address
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

Compiling a file with a single line (a reduced ext-int.c from llvm testsuite):

--- ice.c ---
unsigned _BitInt(1) GlobSize1;
---

with -fsanitize=address:

gcc -fsanitize=address ice.c

results in an ICE:

ice.c:1:1: internal compiler error: in gen_reg_rtx, at emit-rtl.cc:1208
1 | unsigned _BitInt(1) GlobSize1;
  | ^~~~
0x77249b gen_reg_rtx(machine_mode)
../../src/gcc/emit-rtl.cc:1208
0xe94b89 maybe_legitimize_operand
../../src/gcc/optabs.cc:8044
0xe94b89 maybe_legitimize_operands(insn_code, unsigned int, unsigned int,
expand_operand*)
../../src/gcc/optabs.cc:8199
0xe90ee9 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
../../src/gcc/optabs.cc:8218
0xe99c0c expand_binop_directly
../../src/gcc/optabs.cc:1457
0xe97b29 expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*,
int, optab_methods)
../../src/gcc/optabs.cc:1544
0xbde1c0 expand_and(machine_mode, rtx_def*, rtx_def*, rtx_def*)
../../src/gcc/expmed.cc:5483
0xbf8544 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../src/gcc/expr.cc:11005
0xc01fce expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
../../src/gcc/expr.h:310
0xc01fce expand_expr_addr_expr_1
../../src/gcc/expr.cc:8728
0xc02639 expand_expr_addr_expr
../../src/gcc/expr.cc:8849
0xbf7894 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../src/gcc/expr.cc:12163
0x1370de3 expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
../../src/gcc/expr.h:310
0x1370de3 output_constant
../../src/gcc/varasm.cc:5261
0x136fee8 output_constructor_regular_field
../../src/gcc/varasm.cc:5612
0x136fee8 output_constructor
../../src/gcc/varasm.cc:5878
0x136fee8 output_constructor_regular_field
../../src/gcc/varasm.cc:5612
0x136fee8 output_constructor
../../src/gcc/varasm.cc:5878
0x1371df5 assemble_variable_contents
../../src/gcc/varasm.cc:2231
0x1376f8d assemble_variable(tree_node*, int, int, int)
../../src/gcc/varasm.cc:2410

[Bug c++/107513] [Feature Request] Implement __attribute__((__nodebug__))

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

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #6)
> The patch for PR 96780 added -ffold-simple-inlines which works for some
> specific functions. This attribute would extend that to arbitrary functions.

I discussed this with Jason and Patrick, and the -ffold-simple-inlines effects
are not appropriate for implementing this attribute, because the attribute
might get used on functions which cannot be trivially folded by the front end.

It would need to be implemented differently, but probably wouldn't be
difficult.

[Bug c/70954] -Wmisleading-indentation false positive on code from GNU "ed" (featuring a label)

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

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

Eric Gallager  changed:

   What|Removed |Added

Summary|-Wmisleading-indentation|-Wmisleading-indentation
   |false positive on GNU "ed"  |false positive on code from
   ||GNU "ed" (featuring a
   ||label)
 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
(In reply to Martin Uecker from comment #2)
> Here is another example of what appears to be the same bug. Reported here:
> https://gcc.gnu.org/pipermail/gcc/2023-November/242803.html
> 
> I think it would be useful of the title of this report could be changed to
> mention "label".

OK, updated.

[Bug rtl-optimization/104387] aarch64: Redundant SXTH for “bag of bits” moves

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #5 from Jeffrey A. Law  ---
As noted in bz111384, this can be addressed via Joern's extension DCE pass that
we're beating on right now.  Conceptually it tracks liveness of sub-word
objects within a register and when it encounters an extension that sets bits
that are never read, it eliminates the extension. Conceptually simple and we've
confirmed it addresses the issue in 111384.  I strongly suspect it would fix
this one as well.

It's still got bugs and isn't really for integration, but to date Joern's basic
approach seems the most viable for eliminating unnecessary extensions.

[Bug modula2/111956] Many powerpc platforms do _not_ have support for IEEE754 long double

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

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

--- Comment #3 from Eric Gallager  ---
(In reply to Thomas Schwinge from comment #2)
> While you (Gaius) here report test failure, similar to what Maciej had
> reported in PR112091 "rs6000: redefinition of 'constexpr long double
> std::abs(long double)', while building libgm2", I can't even build libgm2
> anymore.
> 
> Similar had reported Eric (CCed here) on GCC IRC, 2023-10-20:
> 
>  ok now this is an error I haven't seen before
> 
> /home/egallager/gcc/.cfarm135_build.build/powerpc64le-unknown-linux-gnu/
> libstdc++-v3/include/bits/std_abs.h:137:3: error: redefinition of 'constexpr
> long double std::abs(long double)'
>  seen on cfarm135
>  I think I remember something about __float128 being weird
> on certain powerpc systems? Is there a configure flag that affects it?
>  I'll open a bug about it...
>  although actually wait... I'm not quite sure the
> component, though... it's an error from a libstdc++ header, but it shows up
> while building KeyBoardLEDs.lo for libm2cor in libgm2, but only for a
> specific target...

Ah, thanks for the cc! I'd meant to look further into this, but got distracted
by other things...

[Bug c++/112335] New: missed optimization on reset and assign unique_ptr

[federico at kircheis dot it via Gcc-bugs]

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

Bug ID: 112335
   Summary: missed optimization on reset and assign unique_ptr
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: federico at kircheis dot it
  Target Milestone: ---

Given following snippet


#include 

struct s{
s();
~s() noexcept;
};



void bar1(std::unique_ptr& ps1, std::unique_ptr& ps2){
ps1.reset();
ps1 = std::move(ps2);
}

void bar2(std::unique_ptr& ps1, std::unique_ptr& ps2){
ps1 = std::move(ps2);
}


If I am not mistaken, bar1 and bar2 should have exactly the same behavior, but
on https://godbolt.org/z/q4nKsPq7z it is possible to see that the generated
code differs.

[Bug target/112334] New: ICE in gen_untyped_return arm.md:9197 while compiling harden-cfr-bret.c

[fkastl at suse dot cz via Gcc-bugs]

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

Bug ID: 112334
   Summary: ICE in gen_untyped_return arm.md:9197 while compiling
harden-cfr-bret.c
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: x86_64-linux
Target: arm-linux-gnueabi

Compiling the harden-cfr-bret-never.c  file from testsuite

arm-linux-gnueabi-gcc testsuite/c-c++-common/torture/harden-cfr-bret-never.c
-mflip-thumb

results in an ICE

during RTL pass: expand
In file included from
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/c-c++-common/torture/harden-cfr-bret-never.c:8:
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/c-c++-common/torture/harden-cfr-bret.c:
In function ‘g’:
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/c-c++-common/torture/harden-cfr-bret.c:11:3:
internal compiler error: Segmentation fault
   11 |   __builtin_return ();
  |   ^
0xc7585f crash_signal
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/toplev.cc:315
0x132d068 gen_untyped_return(rtx_def*, rtx_def*)
   
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/config/arm/arm.md:9197
0xfa6e85 target_gen_untyped_return
   
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/config/arm/arm.md:9140
0x7c6053 expand_builtin_return
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/builtins.cc:1805
0x7d7acc expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/builtins.cc:7550
0x8f673d expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/expr.cc:11932
0x7f41e6 expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/expr.h:310
0x7f41e6 expand_call_stmt
   
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/cfgexpand.cc:2831
0x7f41e6 expand_gimple_stmt_1
   
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/cfgexpand.cc:3880
0x7f41e6 expand_gimple_stmt
   
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/cfgexpand.cc:4044
0x7f8e07 expand_gimple_basic_block
   
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/cfgexpand.cc:6100
0x7fab0e execute
   
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/cfgexpand.cc:6835

[Bug libbacktrace/112263] [C++23] std::stacktrace does not identify symbols in shared library

[vincenzo.innocente at cern dot ch via Gcc-bugs]

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

--- Comment #6 from vincenzo Innocente  ---
Sorry, made the (almost) full exercise:
read the doc in 
https://en.cppreference.com/w/cpp/utility/stacktrace_entry
and the code in stacktrace header file and in
libstdc++-v3/src/c++23/stacktrace.cc
(have not read the specs in the C++23 standard)
indeed the entry implementation has just the handle as data member
and the details are retrieved when the "Query" methods are called.
This appears to happen in
stacktrace_entry::_Info::_M_populate(native_handle_type pc)
which in turn calls
::__glibcxx_backtrace_pcinfo
if this fails it calls
::__glibcxx_backtrace_syminfo

so most probably the issue is in this last function unless there is a problem
with the logic in _M_populate that I failed to identify.

[Bug target/112332] [14 regression] ICE: internal compiler error: in extract_constrain_insn, at recog.cc:2705

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

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

--- Comment #6 from Sergei Trofimovich  ---
I confirm that the fix also fixes original python-3.11.6 build failure. Thank
you!

[Bug sanitizer/98608] missing sanitizer detection for arrays with invalid length defind using typeof

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #3 from Martin Uecker  ---

PATCH (but unclear about n == 0)
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/634896.html

[Bug target/112112] Improper Arithmetic Type Conversion in s390x-linux-gnu-gcc

[22s302h0659 at sonline20 dot sen.go.kr via Gcc-bugs]

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

--- Comment #8 from 김대영 <22s302h0659 at sonline20 dot sen.go.kr> ---
I'm sorry, I also didn't fully understand these bugs, my friend.

[Bug tree-optimization/112320] [14 Regression] crash from insert_debug_temp_for_var_def since r14-5032-ge3da1d7bb288c8

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/112333] ICE on valid code at -O2 and -O3: Segmentation fault

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug tree-optimization/112333] New: ICE on valid code at -O2 and -O3: Segmentation fault

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

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

Bug ID: 112333
   Summary: ICE on valid code at -O2 and -O3: Segmentation fault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a recent regression.

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

With my local build, -g is needed to reproduce the ICE. 

[512] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231101 (experimental) (GCC) 
[513] % 
[513] % gcctk -O3 -g small.c
during GIMPLE pass: ccp
small.c: In function ‘main’:
small.c:3:5: internal compiler error: Segmentation fault
3 | int main() {
  | ^~~~
0x111dc93 crash_signal
../../gcc-trunk/gcc/toplev.cc:315
0x7f658ef6c08f ???
   
/build/glibc-BHL3KM/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xd70a7b gsi_for_stmt(gimple*)
../../gcc-trunk/gcc/gimple-iterator.cc:615
0x13a2e72 insert_debug_temp_for_var_def(gimple_stmt_iterator*, tree_node*)
../../gcc-trunk/gcc/tree-ssa.cc:471
0x13a329a insert_debug_temps_for_defs(gimple_stmt_iterator*)
../../gcc-trunk/gcc/tree-ssa.cc:506
0xd707e4 gsi_remove(gimple_stmt_iterator*, bool)
../../gcc-trunk/gcc/gimple-iterator.cc:567
0x12624c2 simple_dce_from_worklist(bitmap_head*, bitmap_head*)
../../gcc-trunk/gcc/tree-ssa-dce.cc:2206
0x1314c1a substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
../../gcc-trunk/gcc/tree-ssa-propagate.cc:1001
0x1242db8 ccp_finalize
../../gcc-trunk/gcc/tree-ssa-ccp.cc:1031
0x1243468 do_ssa_ccp
../../gcc-trunk/gcc/tree-ssa-ccp.cc:2980
0x1243468 execute
../../gcc-trunk/gcc/tree-ssa-ccp.cc:3025
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[514] % 
[514] % cat small.c
int printf(const char *, ...);
int a, b, c, d, e;
int main() {
  long g;
  int h = a, i;
  if (e)
goto j;
  i = 0;
  for (; i < 1; i++) {
int k = d | c, l = ~a;
if (k) {
m:
  e = 0;
j:
  b = l;
  if (c)
goto m;
}
  }
  if (a) {
while (a > 1)
  a--;
g = a;
printf("%d", h);
  }
  while (a)
;
  return 0;
}

[Bug libbacktrace/112263] [C++23] std::stacktrace does not identify symbols in shared library

[vincenzo.innocente at cern dot ch via Gcc-bugs]

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

--- Comment #5 from vincenzo Innocente  ---
so if I add to
std::cout << std::stacktrace::current() << '\n';
I get what needed
   Dl_info dlinfo;
   for (auto & entry : std::stacktrace::current() ) {
 dladdr((const void*)(entry.native_handle()),);
 std::cout << dlinfo.dli_sname << ' ' << dlinfo.dli_fname <<'\n';
   }

 c++ -std=c++23 testStacktrace.cpp -lstdc++exp -g -DINLIB -fpic -shared -o
liba.so -ldl ; c++ -std=c++23 testStacktrace.cpp -lstdc++exp -g -DINMAIN -L.
-la -Wl,-rpath=. ; ./a.out
   0#  at :0
   1#  at :0
   2# func(int) at
/data/user/innocent/MallocProfiler/tests/testStacktrace.cpp:44
   3# main at /data/user/innocent/MallocProfiler/tests/testStacktrace.cpp:49
   4#  at :0
   5# _start at :0
   6#

_Z12nested_func2i ./liba.so
_Z11nested_funci ./liba.so

of course not de-mangled

so is it a feature or a defect?

I'm not sure how the implementation works (did not look to the code)
dladdr can be slow and may "hang" in some situations.
so it would be useful to have an option that the "name" is not immediately
resolved
and have a function that returns the name from the native_handle
"asynchronously"

[Bug target/112332] [14 regression] ICE: internal compiler error: in extract_constrain_insn, at recog.cc:2705

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Target||x86
 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |14.0

--- Comment #5 from Uroš Bizjak  ---
Fixed.

[Bug target/112332] [14 regression] ICE: internal compiler error: in extract_constrain_insn, at recog.cc:2705

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:64f3a1937a2b87ebe5f3c1bf2ceec48bfbcd4ccf

commit r14-5056-g64f3a1937a2b87ebe5f3c1bf2ceec48bfbcd4ccf
Author: Uros Bizjak 
Date:   Wed Nov 1 12:06:36 2023 +0100

i386: Fix stack protector peephole2 operand predicate [PR112332]

PR target/112332

gcc/ChangeLog:

* config/i386/i386.md (stack_protexct_set_2 peephole2):
Use general_gr_operand as operand 4 predicate.

[Bug target/112332] [14 regression] ICE: internal compiler error: in extract_constrain_insn, at recog.cc:2705

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Uroš Bizjak  ---
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 35d073c9a21..75c75f610c2 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -25748,7 +25748,7 @@ (define_peephole2
  (set (match_operand:W 2 "general_reg_operand") (const_int 0))
  (clobber (reg:CC FLAGS_REG))])
(set (match_operand:SWI48 3 "general_reg_operand")
-   (match_operand:SWI48 4 "general_operand"))]
+   (match_operand:SWI48 4 "general_gr_operand"))]
   "peep2_reg_dead_p (0, operands[3])
&& peep2_reg_dead_p (1, operands[2])"
   [(parallel [(set (match_dup 0)

[Bug target/112332] [14 regression] ICE: internal compiler error: in extract_constrain_insn, at recog.cc:2705

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Uroš Bizjak  ---
(In reply to Sergei Trofimovich from comment #1)
> Slightly shorter example:
> 
> typedef union {
>   double d;
>   int L[2];
> } U;
> void d2b(int*);
> void _Py_dg_dtoa(double dd) {
>   int be;
>   U u;
>   u.d = dd;
>   if (()->L[1])
> d2b();
> }

Let's put back those extran constraints...

[Bug target/112332] [14 regression] ICE: internal compiler error: in extract_constrain_insn, at recog.cc:2705

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

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

--- Comment #1 from Sergei Trofimovich  ---
Slightly shorter example:

typedef union {
  double d;
  int L[2];
} U;
void d2b(int*);
void _Py_dg_dtoa(double dd) {
  int be;
  U u;
  u.d = dd;
  if (()->L[1])
d2b();
}

[Bug target/112332] New: [14 regression] ICE: internal compiler error: in extract_constrain_insn, at recog.cc:2705

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

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

Bug ID: 112332
   Summary: [14 regression] ICE: internal compiler error: in
extract_constrain_insn, at recog.cc:2705
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Noticed ICE today when attempted to build python-3.11.6 with gcc-master
r14-5055-g7480dbb6e7891f.

Extracted reproducer:

// $ cat dtoa.c.c
typedef union {
  double d;
  int L[2];
} U;
void d2b();
char _Py_dg_dtoa(double dd) {
  int be;
  U u;
  u.d = dd;
  if (()->L[1])
d2b();
  goto failed_malloc;
  goto fast_failed;
  goto one_digit;
  goto no_digits;
  goto ret1;
  goto bump_up;
fast_failed:
bump_up:
no_digits:
one_digit:
ret1:
failed_malloc:
  return 0;
}

Crashing:

./gcc/xgcc -Bgcc -O2 -fstack-protector-strong dtoa.c.c -o a.o
dtoa.c.c: In function ‘_Py_dg_dtoa’:
dtoa.c.c:25:1: error: insn does not satisfy its constraints:
   25 | }
  | ^
(insn 51 3 9 2 (parallel [
(set (mem/v/f/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])) [4 D.2786+0 S8 A64])
(unspec:DI [
(mem/v/f:DI (const_int 40 [0x28]) [5
MEM[( long unsigned int *)40B]+0 S8 A64 AS1])
] UNSPEC_SP_SET))
(set (reg:DI 0 ax [orig:103 dd ] [103])
(reg:DI 20 xmm0 [109]))
]) "dtoa.c.c":10:6 1461 {*stack_protect_set_2_di_di}
 (expr_list:REG_DEAD (reg:DI 20 xmm0 [109])
(nil)))
during RTL pass: cprop_hardreg
dtoa.c.c:25:1: internal compiler error: in extract_constrain_insn, at
recog.cc:2705
0x7ef71b _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/slyfox/dev/git/gcc/gcc/rtl-error.cc:108
0x7ef741 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/slyfox/dev/git/gcc/gcc/rtl-error.cc:118
0x7eddcb extract_constrain_insn(rtx_insn*)
/home/slyfox/dev/git/gcc/gcc/recog.cc:2705
0xf60c47 copyprop_hardreg_forward_1
/home/slyfox/dev/git/gcc/gcc/regcprop.cc:836
0xf61d44 execute
/home/slyfox/dev/git/gcc/gcc/regcprop.cc:1423

Compiler:

$ ./gcc/xgcc -Bgcc -v
Reading specs from gcc/specs
COLLECT_GCC=./gcc/xgcc
COLLECT_LTO_WRAPPER=gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/slyfox/dev/git/gcc/configure --disable-bootstrap
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231101 (experimental) (GCC)

[Bug target/110551] [11/12/13/14 Regression] an extra mov when doing 128bit multiply

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Uroš Bizjak  ---
(In reply to CVS Commits from comment #5)
> The master branch has been updated by Roger Sayle :
> 
> https://gcc.gnu.org/g:89e5d902fc55ad375f149f25a84c516ad360a606
> 
> commit r14-4968-g89e5d902fc55ad375f149f25a84c516ad360a606
> Author: Roger Sayle 
> Date:   Fri Oct 27 10:03:53 2023 +0100

Looks like the patch regressed -march=cascadelake.

https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634660.html

[Bug target/112330] [14 Regression] LoongArch: Bootstrap failure with GAS 2.41

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

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

Xi Ruoyao  changed:

   What|Removed |Added

Summary|[14 Regression] LoongArch:  |[14 Regression] LoongArch:
   |LTO bootstrap failure with  |Bootstrap failure with GAS
   |GAS 2.41|2.41

--- Comment #9 from Xi Ruoyao  ---
Xuerui informed me that non-LTO bootstrapping is broken too.

[Bug target/112330] [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41

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

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

--- Comment #8 from Xi Ruoyao  ---
(In reply to chenglulu from comment #7)

> Uh, I also thought about this gcc and binutils matching issue when I
> submitted r14-4674, but I didn't think about whether this should be solved?
> How to fix it？

I'm not sure either.

The easiest way is just claiming we need Binutils 2.42 for GCC 14 (documenting
this in "Host/target specific installation notes for GCC", install.texi).

If we want to maintain the compatibility with 2.41, I think the best solution
would be probing the capability of GAS and disable relaxation by default if
necessary.

There is already another issue breaking relaxation with Binutils 2.41 anyway:
https://sourceware.org/bugzilla/show_bug.cgi?id=30944. Mengqinggang has posted
a fix at https://sourceware.org/pipermail/binutils/2023-October/129941.html but
it's still under testing. Hopefully the fix will be committed before Binutils
2.42 freeze.

[Bug target/112330] [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #7 from chenglulu  ---
(In reply to Xi Ruoyao from comment #6)
> (In reply to chenglulu from comment #5)
> > (In reply to Xi Ruoyao from comment #4)
> > > (In reply to chenglulu from comment #3)
> > > > (In reply to Xi Ruoyao from comment #1)
> > > > > (In reply to Xi Ruoyao from comment #0)
> > > > > 
> > > > > > I guess the easiest solution is raising the minimal GAS requirement 
> > > > > > of
> > > > > > bootstrapping GCC 14 on LoongArch to 2.42.
> > > > > 
> > > > > Another solution might be default to -mno-relax if GAS is 2.41, but 
> > > > > I'm not
> > > > > sure if it's enough.
> > > > 
> > > > This issue really doesn't happen after adding -mno-relax, but is it 
> > > > really
> > > > necessary to judge the version of binutils because of this?
> > > 
> > > I'm not sure if -mno-relax is the proper fix.  For now I've reduced the 
> > > test
> > > case to:
> > > 
> > > a:
> > > .rept 10
> > > nop
> > > .endr
> > > beq $r12, $r13, a
> > > 
> > > but this still does not work with GAS 2.41 even if -mno-relax.
> > 
> > If this is the assembly code compiled by gcc, then I think it's a gcc bug,
> > although AS shouldn't be an internal error.
> 
> The internal error issue is fixed by Binutils commit
> f87cf663af71e5d78c8d647fa48562102f3b0615.
> 
> I think I've over-simplified the test case.  GCC does not generate something
> like this.

Uh, I also thought about this gcc and binutils matching issue when I submitted
r14-4674, but I didn't think about whether this should be solved? How to fix
it？

[Bug c/112331] middle-end: Fail vectorization

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #1 from JuzheZhong  ---
I suspect it is SRA issue again ?

[Bug target/112330] [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41

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

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

--- Comment #6 from Xi Ruoyao  ---
(In reply to chenglulu from comment #5)
> (In reply to Xi Ruoyao from comment #4)
> > (In reply to chenglulu from comment #3)
> > > (In reply to Xi Ruoyao from comment #1)
> > > > (In reply to Xi Ruoyao from comment #0)
> > > > 
> > > > > I guess the easiest solution is raising the minimal GAS requirement of
> > > > > bootstrapping GCC 14 on LoongArch to 2.42.
> > > > 
> > > > Another solution might be default to -mno-relax if GAS is 2.41, but I'm 
> > > > not
> > > > sure if it's enough.
> > > 
> > > This issue really doesn't happen after adding -mno-relax, but is it really
> > > necessary to judge the version of binutils because of this?
> > 
> > I'm not sure if -mno-relax is the proper fix.  For now I've reduced the test
> > case to:
> > 
> > a:
> > .rept 10
> > nop
> > .endr
> > beq $r12, $r13, a
> > 
> > but this still does not work with GAS 2.41 even if -mno-relax.
> 
> If this is the assembly code compiled by gcc, then I think it's a gcc bug,
> although AS shouldn't be an internal error.

The internal error issue is fixed by Binutils commit
f87cf663af71e5d78c8d647fa48562102f3b0615.

I think I've over-simplified the test case.  GCC does not generate something
like this.

[Bug c/112331] New: middle-end: Fail vectorization

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

Bug ID: 112331
   Summary: middle-end: Fail vectorization
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juzhe.zhong at rivai dot ai
  Target Milestone: ---

https://gcc.godbolt.org/z/x7GGzezGh


#include 
#define LEN 32000
#define ntimes 20
#define TYPE float
#define lll LEN
#define LEN2 256
#define ALIGNMENT 16
__attribute__ ((aligned(ALIGNMENT))) TYPE X[lll],Y[lll],Z[lll],U[lll],V[lll];

struct GlobalData {
  __attribute__((aligned(ALIGNMENT))) TYPE a[LEN];
  int pad1[3];
  __attribute__((aligned(ALIGNMENT))) TYPE b[LEN];
  int pad2[5];
  __attribute__((aligned(ALIGNMENT))) TYPE c[LEN];
  int pad3[7];
  __attribute__((aligned(ALIGNMENT))) TYPE d[LEN];
  int pad4[11];
  __attribute__((aligned(ALIGNMENT))) TYPE e[LEN];

  int pad5[13];
  __attribute__((aligned(ALIGNMENT))) TYPE aa[LEN2][LEN2];
  int pad6[17];
  __attribute__((aligned(ALIGNMENT))) TYPE bb[LEN2][LEN2];
  int pad7[19];
  __attribute__((aligned(ALIGNMENT))) TYPE cc[LEN2][LEN2];
  int pad8[23];
  __attribute__((aligned(ALIGNMENT))) TYPE tt[LEN2][LEN2];
} global_data;

__attribute__((aligned(ALIGNMENT))) TYPE * const a = global_data.a;
__attribute__((aligned(ALIGNMENT))) TYPE * const b = global_data.b;
__attribute__((aligned(ALIGNMENT))) TYPE * const c = global_data.c;
__attribute__((aligned(ALIGNMENT))) TYPE * const d = global_data.d;
__attribute__((aligned(ALIGNMENT))) TYPE * const e = global_data.e;
__attribute__((aligned(ALIGNMENT))) TYPE (* const aa)[LEN2] = global_data.aa;
__attribute__((aligned(ALIGNMENT))) TYPE (* const bb)[LEN2] = global_data.bb;
__attribute__((aligned(ALIGNMENT))) TYPE (* const cc)[LEN2] = global_data.cc;
__attribute__((aligned(ALIGNMENT))) TYPE (* const tt)[LEN2] = global_data.tt;

int foo()
{

//  linear dependence testing
//  no dependence - vectorizable


for (int nl = 0; nl < 2*ntimes; nl++) {
//  #pragma vector always
for (int i = 1; i < LEN; i += 2) {
a[i] = a[i - 1] + b[i];
}
}

return 0;
}

Both RVV and ARM SVE faild to vectorize it wheras Clang can vectorize it.

[Bug target/112112] Improper Arithmetic Type Conversion in s390x-linux-gnu-gcc

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

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

Thomas Koenig  changed:

   What|Removed |Added

   Last reconfirmed||2023-11-01
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #7 from Thomas Koenig  ---
(In reply to 김대영 from comment #6)
> ```
> z3rodae0@z3rodae0:~$ ./sh.sh
> result for -O0 "signed" = 1
> result for -O1 "signed" = 1
> result for -O2 "signed" = 1
> result for -O3 "signed" = 1
> result for -O0 "unsigned" = 0
> result for -O1 "unsigned" = 0
> result for -O2 "unsigned" = 0
> result for -O3 "unsigned" = 0
> result for -O0 "" = 1
> result for -O1 "" = 1
> result for -O2 "" = 1
> result for -O3 "" = 1
> ```
> 
> That's correct. I ran your code and script in my environment, and it
> produced the same results

That is weird.

I don't see a meaningful difference between the version without signed or
unsigned and your program, and you get inconsistent results with your
original program and consistent results with the other one.

Or am I missing something?

[Bug target/112330] [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #5 from chenglulu  ---
(In reply to Xi Ruoyao from comment #4)
> (In reply to chenglulu from comment #3)
> > (In reply to Xi Ruoyao from comment #1)
> > > (In reply to Xi Ruoyao from comment #0)
> > > 
> > > > I guess the easiest solution is raising the minimal GAS requirement of
> > > > bootstrapping GCC 14 on LoongArch to 2.42.
> > > 
> > > Another solution might be default to -mno-relax if GAS is 2.41, but I'm 
> > > not
> > > sure if it's enough.
> > 
> > This issue really doesn't happen after adding -mno-relax, but is it really
> > necessary to judge the version of binutils because of this?
> 
> I'm not sure if -mno-relax is the proper fix.  For now I've reduced the test
> case to:
> 
> a:
> .rept 10
> nop
> .endr
> beq $r12, $r13, a
> 
> but this still does not work with GAS 2.41 even if -mno-relax.

If this is the assembly code compiled by gcc, then I think it's a gcc bug,
although AS shouldn't be an internal error.

[Bug target/112330] [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41

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

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

--- Comment #4 from Xi Ruoyao  ---
(In reply to chenglulu from comment #3)
> (In reply to Xi Ruoyao from comment #1)
> > (In reply to Xi Ruoyao from comment #0)
> > 
> > > I guess the easiest solution is raising the minimal GAS requirement of
> > > bootstrapping GCC 14 on LoongArch to 2.42.
> > 
> > Another solution might be default to -mno-relax if GAS is 2.41, but I'm not
> > sure if it's enough.
> 
> This issue really doesn't happen after adding -mno-relax, but is it really
> necessary to judge the version of binutils because of this?

I'm not sure if -mno-relax is the proper fix.  For now I've reduced the test
case to:

a:
.rept 10
nop
.endr
beq $r12, $r13, a

but this still does not work with GAS 2.41 even if -mno-relax.

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

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

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

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

https://gcc.gnu.org/g:9693459e030977d6e906ea7eb587ed09ee4fddbd

commit r14-5054-g9693459e030977d6e906ea7eb587ed09ee4fddbd
Author: Gaius Mulley 
Date:   Wed Nov 1 09:05:10 2023 +

PR modula2/102989: reimplement overflow detection in ztype though
WIDE_INT_MAX_PRECISION

The ZTYPE in iso modula2 is used to denote intemediate ordinal type const
expressions and these are always converted into the
approriate language or user ordinal type prior to code generation.
The increase of bits supported by _BitInt causes the modula2 largeconst.mod
regression failure tests to pass.  The largeconst.mod test has been
increased to fail, however the char at a time overflow check is now too
slow
to detect failure.  The overflow detection for the ZTYPE has been
rewritten to check against exceeding WIDE_INT_MAX_PRECISION (many orders of
magnitude faster).

gcc/m2/ChangeLog:

PR modula2/102989
* gm2-compiler/SymbolTable.mod (OverflowZType): Import from m2expr.
(ConstantStringExceedsZType): Remove import.
(GetConstLitType): Replace ConstantStringExceedsZType with
OverflowZType.
* gm2-gcc/m2decl.cc (m2decl_ConstantStringExceedsZType): Remove.
(m2decl_BuildConstLiteralNumber): Re-write.
* gm2-gcc/m2decl.def (ConstantStringExceedsZType): Remove.
* gm2-gcc/m2decl.h (m2decl_ConstantStringExceedsZType): Remove.
* gm2-gcc/m2expr.cc (m2expr_StrToWideInt): Rewrite to check
overflow.
(m2expr_OverflowZType): New function.
(ToWideInt): New function.
* gm2-gcc/m2expr.def (OverflowZType): New procedure function
declaration.
* gm2-gcc/m2expr.h (m2expr_OverflowZType): New prototype.

gcc/testsuite/ChangeLog:

PR modula2/102989
* gm2/pim/fail/largeconst.mod: Updated foo to an outrageous value.
* gm2/pim/fail/largeconst2.mod: Duplicate test removed.

Signed-off-by: Gaius Mulley 

[Bug target/112330] [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #3 from chenglulu  ---
(In reply to Xi Ruoyao from comment #1)
> (In reply to Xi Ruoyao from comment #0)
> 
> > I guess the easiest solution is raising the minimal GAS requirement of
> > bootstrapping GCC 14 on LoongArch to 2.42.
> 
> Another solution might be default to -mno-relax if GAS is 2.41, but I'm not
> sure if it's enough.

This issue really doesn't happen after adding -mno-relax, but is it really
necessary to judge the version of binutils because of this?

[Bug target/112330] [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41

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

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

--- Comment #2 from Xi Ruoyao  ---
Created attachment 56483
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56483=edit
The generated assembly triggering the GAS internal error

[Bug target/112330] [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41

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

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

--- Comment #1 from Xi Ruoyao  ---
(In reply to Xi Ruoyao from comment #0)

> I guess the easiest solution is raising the minimal GAS requirement of
> bootstrapping GCC 14 on LoongArch to 2.42.

Another solution might be default to -mno-relax if GAS is 2.41, but I'm not
sure if it's enough.

[Bug target/112330] New: [14 Regression] LoongArch: LTO bootstrap failure with GAS 2.41

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

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

Bug ID: 112330
   Summary: [14 Regression] LoongArch: LTO bootstrap failure with
GAS 2.41
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xry111 at gcc dot gnu.org
  Target Milestone: ---

r14-5053 fails to LTO bootstrap with GAS 2.41 and the following configuration:

../gcc/configure --prefix=/home/xry111/gcc-dev --with-system-zlib
--disable-fixincludes --enable-default-ssp --enable-default-pie
--disable-werror --disable-multilib --with-build-config=bootstrap-lto && make
-j32

The error message is:

/usr/bin/as: /usr/bin/as: BFD (Gentoo 2.41 p2) 2.41.0 internal error, aborting
at /tmp/portage/sys-devel/binutils-2.41-r2/work/binutils-2.41/bfd/bfd.c:1185 in
_bfd_doprnt

/usr/bin/as: Please report this bug.

The problem is since r14-4674 we are relying on Binutils commit
1fb3cdd87ec61715a5684925fb6d6a6cf53bb97c, which is not available in GAS 2.41.

I guess the easiest solution is raising the minimal GAS requirement of
bootstrapping GCC 14 on LoongArch to 2.42.

[Bug c/70954] -Wmisleading-indentation false positive on GNU "ed"

[muecker at gwdg dot de via Gcc-bugs]

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

Martin Uecker  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

--- Comment #2 from Martin Uecker  ---

Here is another example of what appears to be the same bug. Reported here:
https://gcc.gnu.org/pipermail/gcc/2023-November/242803.html

I think it would be useful of the title of this report could be changed to
mention "label".

/*
 * miside.c
 * MWE for a wrong warning shown with gcc -Wmisleading-indentation
 */

void
good(int c)
{
label:
while (c != '-');
if (c != '-')
goto label;
}

void
bad(int c)
{
label:  while (c != '-');
if (c != '-')
goto label;
}

https://gcc.godbolt.org/z/6MMsds1bd

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

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

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

--- Comment #115 from Gaius Mulley  ---
Created attachment 56482
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56482=edit
modula2: proposed fix to fix largeconst.mod

Here is a patch set for the modula2 fe which re-implements the ZTYPE overflow
detection.

Bootstrapped on x86_64 all regressions pass.

The ZTYPE in iso modula2 is used to denote intemediate ordinal type const
expressions and these are always converted into the
approriate language or user ordinal type prior to code generation.
The increase of bits supported by _BitInt causes the modula2 largeconst.mod
regression failure tests to pass.  The largeconst.mod test has been
increased to fail, however the char at a time overflow check is now too slow
to detect failure.  The overflow detection for the ZTYPE has been
rewritten to check against exceeding WIDE_INT_MAX_PRECISION (many orders of
magnitude faster).

gcc/m2/ChangeLog:

* gm2-compiler/SymbolTable.mod (OverflowZType): Import from m2expr.
(ConstantStringExceedsZType): Remove import.
(GetConstLitType): Replace ConstantStringExceedsZType with
OverflowZType.
* gm2-gcc/m2decl.cc (m2decl_ConstantStringExceedsZType): Remove.
(m2decl_BuildConstLiteralNumber): Re-write.
* gm2-gcc/m2decl.def (ConstantStringExceedsZType): Remove.
* gm2-gcc/m2decl.h (m2decl_ConstantStringExceedsZType): Remove.
* gm2-gcc/m2expr.cc (m2expr_StrToWideInt): Rewrite to check overflow.
(m2expr_OverflowZType): New function.
(ToWideInt): New function.
* gm2-gcc/m2expr.def (OverflowZType): New procedure function
declaration.
* gm2-gcc/m2expr.h (m2expr_OverflowZType): New prototype.

gcc/testsuite/ChangeLog:

* gm2/pim/fail/largeconst.mod: Updated foo to an outrageous value.
* gm2/pim/fail/largeconst2.mod: Duplicate test removed.

[Bug c/112328] ice in rdg_vertex_for_stmt, at tree-loop-distribution.cc:418

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from David Binderman  ---
After a bisect, range seems to be g:1cf5dc05c678232b
to g:9119b008b4195e06.

Richard's commit e3da1d7bb288c8c864f0284bc4bc5877b466a2f7 looks a strong
candidate.

[Bug c/112329] New: Faulty arithmetic comparison in O2, O3 of s390x-gcc

[22s302h0659 at sonline20 dot sen.go.kr via Gcc-bugs]

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

Bug ID: 112329
   Summary: Faulty arithmetic comparison in O2, O3 of s390x-gcc
   Product: gcc
   Version: 11.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 22s302h0659 at sonline20 dot sen.go.kr
  Target Milestone: ---

### Environment

- Compiler: s390x-linux-gnu-gcc (64bit)
- Version: gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
- Platform: Windows 11_5.15.90.1-microsoft-standard-WSL2
- Build Optimization Options: O0, O1, O2, O3

I installed the s390x-linux-gnu toolchain using the 'apt' package manager in
Ubuntu and utilized s390x-linux-gnu-gcc (version 11.4.0) from it.

### build script & excution script

```bash
# build scripts
s390x-linux-gnu-gcc ./bug_Poc.c -o test_O0 -I"/home/z3rodae0/csmith/include" -g
-O0 -fsanitize=undefined -Wall -Wextra -fno-strict-aliasing -fwrapv
s390x-linux-gnu-gcc ./bug_Poc.c -o test_O1 -I"/home/z3rodae0/csmith/include" -g
-O1 -fsanitize=undefined -Wall -Wextra -fno-strict-aliasing -fwrapv
s390x-linux-gnu-gcc ./bug_Poc.c -o test_O2 -I"/home/z3rodae0/csmith/include" -g
-O2 -fsanitize=undefined -Wall -Wextra -fno-strict-aliasing -fwrapv
s390x-linux-gnu-gcc ./bug_Poc.c -o test_O3 -I"/home/z3rodae0/csmith/include" -g
-O3 -fsanitize=undefined -Wall -Wextra

gcc ./bug_Poc.c -o gcc_O0 -I"/home/z3rodae0/csmith/include" -g -O0
-fsanitize=undefined -Wall -Wextra -fno-strict-aliasing -fwrapv
gcc ./bug_Poc.c -o gcc_O1 -I"/home/z3rodae0/csmith/include" -g -O1
-fsanitize=undefined -Wall -Wextra -fno-strict-aliasing -fwrapv
gcc ./bug_Poc.c -o gcc_O2 -I"/home/z3rodae0/csmith/include" -g -O2
-fsanitize=undefined -Wall -Wextra -fno-strict-aliasing -fwrapv
gcc ./bug_Poc.c -o gcc_O3 -I"/home/z3rodae0/csmith/include" -g -O3
-fsanitize=undefined -Wall -Wextra -fno-strict-aliasing -fwrapv

clang ./bug_Poc.c -o clang_O0 -I"/home/z3rodae0/csmith/include" -g -O0
-fsanitize=undefined -Wall -Wextra -fno-strict-aliasing -fwrapv
clang ./bug_Poc.c -o clang_O1 -I"/home/z3rodae0/csmith/include" -g -O1
-fsanitize=undefined -Wall -Wextra -fno-strict-aliasing -fwrapv
clang ./bug_Poc.c -o clang_O2 -I"/home/z3rodae0/csmith/include" -g -O2
-fsanitize=undefined -Wall -Wextra -fno-strict-aliasing -fwrapv
clang ./bug_Poc.c -o clang_O3 -I"/home/z3rodae0/csmith/include" -g -O3
-fsanitize=undefined -Wall -Wextra -fno-strict-aliasing -fwrapv
```

```bash
# run scripts
qemu-s390x-static -L /usr/s390x-linux-gnu/ ./test_O0
qemu-s390x-static -L /usr/s390x-linux-gnu/ ./test_O1
qemu-s390x-static -L /usr/s390x-linux-gnu/ ./test_O2
qemu-s390x-static -L /usr/s390x-linux-gnu/ ./test_O3

./gcc_O0
./gcc_O1
./gcc_O2
./gcc_O3

./clang_O0
./clang_O1
./clang_O2
./clang_O3
```

When casting the negative value -1 to an unsigned char at the 6th line, it
becomes the value 255. Then, comparing it with g_89, the expression 255 <= 1 is
false, so it is correct to return 0. However, with optimization options O2, O3,
it returns the value 1.

### Source Code

```c
1 #include 
2 short g_14 = -1;
3 short g_89 = 1;
4 int main ()
5 { 
6 printf("bug== %d\n", ((unsigned char)(g_14)) <= g_89); 
7 return 0;
8 }
```

### Result

```bash
bug== 0
bug== 0
bug== 1
bug== 1
bug== 0
bug== 0
bug== 0
bug== 0
bug== 0
bug== 0
bug== 0
bug== 0
```

### Coclusion

I'm reporting this issue due to incorrect results in integer comparison
operations. I've reported bugs twice before that occurred in the s390x
architecture. Although the cross-compiler I'm using is not the latest version,
I consider this to be quite important. This is because most people install the
cross-compiler via 'apt install', so incorrect code generation in this version
poses a risk.

[Bug c/112328] ice in rdg_vertex_for_stmt, at tree-loop-distribution.cc:418

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
Reduced code seems to be:

int allchars, palsetup_p, palsetup_b, palsetup_e;
int *palsetup_palette;
void palsetup() {
  int g;
  char *s;
  switch (palsetup_p)
  case 6:
s = allchars;
  g = 0;
  for (; g < palsetup_p; g++) {
palsetup_b = 0;
for (; palsetup_b < palsetup_p; palsetup_b++)
  palsetup_e = palsetup_palette[*s++];
  }
}

[Bug target/111720] RISC-V: Ugly codegen in RVV

[pan2.li at intel dot com via Gcc-bugs]

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

--- Comment #27 from Li Pan  ---
Hi Richard and Juzhe.

I investigated this issue recently and noticed that it may be related to the
array size of the constant memory. Assume we have 2 functions as below.

vuint8m1_t fn_0 () {
  uint8_t arr[32] = {1, 2, 7, 1, 3, 4, 5, 3, 1, 0, 1, 2, 4, 4, 9, 9, 1, 2, 7,
1, 3, 4, 5, 3, 1, 0, 1, 2, 4, 4, 9, 9};

  return __riscv_vle8_v_u8m1(arr, 32);
}

vuint8m2_t fn_1 () {
  uint8_t arr[32] = {1, 2, 7, 1, 3, 4, 5, 3, 1, 0, 1, 2, 4, 4, 9, 9, 1, 2, 7,
1, 3, 4, 5, 3, 1, 0, 1, 2, 4, 4, 9, 9};

  return __riscv_vle8_v_u8m2(arr, 32);
}

The vuint8m1 will have stack variables but the vuint8m2 doesn't. Thus I guess
there may be some limitations when optimization. Finally, I located
extract_low_bits when get_stored_val in dse. Looks like it can only take care
of scalar mode if the nunits are not equal.

rtx extract_low_bits (machine_mode mode, machine_mode src_mode, rtx src)
{
  ...
  if (!int_mode_for_mode (src_mode).exists (_int_mode)
  || !int_mode_for_mode (mode).exists (_mode))
return NULL_RTX;
  ...
}

I try to allow the vector mode for the gen_lowpart here if and only if the size
of mode is not greater than src mode. It can eliminate the stack variables as
we expected up to a point for the above functions.

I tested RVV regression and looks good for now. But I would like to double
confirm with you that it is reasonable? Before we start to do more testing. ;).

Thanks.

[Bug tree-optimization/111043] [14 regression] ICE in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1068

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

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

--- Comment #9 from Zhendong Su  ---
Another at -O2 and -O3:

[545] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231101 (experimental) (GCC) 
[546] % 
[546] % gcctk -O2 small.c
during GIMPLE pass: ch_vect
small.c: In function ‘main’:
small.c:21:5: internal compiler error: in adjust_loop_info_after_peeling, at
tree-ssa-loop-ivcanon.cc:1069
   21 | int main() {
  | ^~~~
0x8736bd adjust_loop_info_after_peeling(loop*, int, bool)
../../gcc-trunk/gcc/tree-ssa-loop-ivcanon.cc:1069
0x1287a14 copy_headers
../../gcc-trunk/gcc/tree-ssa-loop-ch.cc:1108
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[547] % 
[547] % cat small.c
int a, *b, c, *d, e, f;
static void g() {
  int h;
while (1)
  while (1) {
int *i = 0;
h = 0;
while (c)
  *d = 1;
if (e)
  break;
if ((h ^ f) > f)
  for (; e < 1; e++)
;
for (a = 0; a < 1; a++)
  if (*i)
break;
b = 
  }
}
int main() {
  if (a)
g();
  return 0;
}

[Bug tree-optimization/112320] [14 Regression] crash from insert_debug_temp_for_var_def since r14-5032-ge3da1d7bb288c8

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #7 from David Binderman  ---
(In reply to Hans-Peter Nilsson from comment #4)
> What target?

Sorry, I should have mentioned x86_64. 

In my opinion, bugs in the middle end tend to occur on all targets.

[Bug c/112328] New: ice in rdg_vertex_for_stmt, at tree-loop-distribution.cc:418

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 112328
   Summary: ice in rdg_vertex_for_stmt, at
tree-loop-distribution.cc:418
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 56481
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56481=edit
C source code

For the attached C code, compiled with recent gcc, does this:

foundBugs $ ../results/bin/gcc -c -w bug973.c
foundBugs $ ../results/bin/gcc -c -w -g bug973.c
foundBugs $ ../results/bin/gcc -c -w -g -O1 bug973.c
foundBugs $ ../results/bin/gcc -c -w -g -O2 bug973.c
during GIMPLE pass: ldist
rcolor.r: In function ‘palsetup’:
rcolor.r:570:18: internal compiler error: in rdg_vertex_for_stmt, at
tree-loop-distribution.cc:418
0xf6291d rdg_vertex_for_stmt(graph*, gimple*)
../../trunk.year/gcc/tree-loop-distribution.cc:418
0xf6291d create_rdg_edges_for_scalar(graph*, tree_node*, int)
../../trunk.year/gcc/tree-loop-distribution.cc:434

The bug first seems to occur sometime between g:8c40b72036c967fb
and g:9119b008b4195e06.

I will have a go at a reduction.

[Bug rtl-optimization/111835] Suboptimal codegen: zero extended load instead of sign extended one

[lis8215 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Siarhei Volkau  ---
I don't think that it is duplicate of the bug 104387 because there's only one
store.
And this bug is simply disappears if we change the source code a bit.
e.g.
 - change (int8_t)*src; to *(int8_t*)src;
or change argument uint8_t * dst to int8_t * dst

But if we have multiple stores, extension will remain in any condition.

[Bug rtl-optimization/111384] missed optimization: GCC adds extra any extend when storing subreg#0 multiple times

[lis8215 at gmail dot com via Gcc-bugs]

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

Siarhei Volkau  changed:

   What|Removed |Added

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

--- Comment #5 from Siarhei Volkau  ---
Dup of bug 104387.

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

[Bug rtl-optimization/104387] aarch64: Redundant SXTH for “bag of bits” moves

[lis8215 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Siarhei Volkau  ---
*** Bug 111384 has been marked as a duplicate of this bug. ***

[Bug c/112327] New: RVV: Redundant vmv1r for widen reduction

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

Bug ID: 112327
   Summary: RVV: Redundant vmv1r for widen reduction
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juzhe.zhong at rivai dot ai
  Target Milestone: ---

#include "riscv_vector.h"

void rvv_dot_prod(int16_t *pSrcA, int16_t *pSrcB, uint32_t n, int64_t *result)
{
size_t vl;
vint16m4_t vSrcA, vSrcB;
vint64m1_t vSum = __riscv_vmv_s_x_i64m1(0, 1);
while (n > 0) {
vl = __riscv_vsetvl_e16m4(n);
vSrcA = __riscv_vle16_v_i16m4(pSrcA, vl);
vSrcB = __riscv_vle16_v_i16m4(pSrcB, vl);
vSum = __riscv_vwredsum_vs_i32m8_i64m1(__riscv_vwmul_vv_i32m8(vSrcA,
vSrcB, vl), vSum, vl);
pSrcA += vl;
pSrcB += vl;
n -= vl;
}
*result = __riscv_vmv_x_s_i64m1_i64(vSum);
}

https://godbolt.org/z/sb8G7ExKP

GCC:

...
vmv1r.v v2,v1
...
vwredsum.vs v1,v8,v2

Clang:

vwredsum.vs v8, v24, v8

The root cause is that we don't allow vwredsum.vs vd,vs2,vs1, vs1 overlaps vd.