[Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6

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

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

Kewen Lin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||linkw at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
   Last reconfirmed||2023-12-01

--- Comment #1 from Kewen Lin  ---
Confirmed.

A reduced test case:

long double a, b, c;
long double d() { return -__builtin_fmaf128_round_to_odd(c, b, a); }

c.0_1 = c;
b.1_2 = b;
a.2_3 = a;
_4 = __builtin_fmaf128_round_to_odd (c.0_1, b.1_2, a.2_3);
_6 = -_4;
return _6;

 206├───> gcc_assert (m_operator->operand_check_p (type, lh.type (), rh.type
()));

stmt: _6 = -_4;

(gdb) pge lh.type()
_Float128
(gdb) pge rh.type()
long double

The root cause is the same to what's in PR107299, TYPE_PRECISION of rh.type is
127 while that of lh.type is 128, some attempts were tried to fix this
precision difference before but failed to, like:
https://inbox.sourceware.org/gcc-patches/718677e7-614d-7977-312d-05a75e1fd...@linux.ibm.com/.

ranger makes use of type precision directly instead of something like
types_compatible_p. I wonder if we can introduce a target hook (or hookpod) to
make ranger unrestrict this check a bit, the justification is that for float
type its precision information is encoded in its underlying real_format, if two
float types underlying modes are the same, the precision are actually the same. 

btw, the operand_check_ps seems able to call range_compatible_p?

[Bug target/112804] New: ICE in aarch64 crosscompiler in plus_constant, at explow.cc:102

[fkastl at suse dot cz via Gcc-bugs]

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

Bug ID: 112804
   Summary: ICE in aarch64 crosscompiler in plus_constant, at
explow.cc:102
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, needs-bisection
  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: aarch64-gnu-linux

Created attachment 56748
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56748&action=edit
Log of found plus_constant ICEs

While compiling the gcc.dg/tree-ssa/pr111583-2.c testcase from GCC testsuite
using the aarch64 cross compiler with the following options:

aarch64-linux-gnu-gcc
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/tree-ssa/pr111583-2.c
-mabi=ilp32 -finline-stringops -ftrivial-auto-var-init=zero

the following ICE occurs:

during RTL pass: expand
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/tree-ssa/pr111583-2.c:
In function ‘m’:
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/tree-ssa/pr111583-2.c:18:25:
internal compiler error: in plus_constant, at explow.cc:102
   18 |   const unsigned short *n[65];
  | ^
0x73fa6c plus_constant(machine_mode, rtx_def*, poly_int<2u, long>, bool)
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/explow.cc:102
0x89f52f try_store_by_multiple_pieces(rtx_def*, rtx_def*, unsigned int,
unsigned long, unsigned long, rtx_def*, char, unsigned int)
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/builtins.cc:4517
0x9d8870 clear_storage_hints(rtx_def*, rtx_def*, block_op_methods, unsigned
int, long, unsigned long, unsigned long, unsigned long, unsigned int)
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/expr.cc:3888
0x8a619b expand_builtin_memset_args
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/builtins.cc:4674
0xac23f7 expand_DEFERRED_INIT
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/internal-fn.cc:3357
0x8c6a37 expand_call_stmt
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/cfgexpand.cc:2738
0x8c6a37 expand_gimple_stmt_1
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/cfgexpand.cc:3881
0x8c6a37 expand_gimple_stmt
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/cfgexpand.cc:4045
0x8cbac7 expand_gimple_basic_block
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/cfgexpand.cc:6101
0x8cd7be execute
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/cfgexpand.cc:6836
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.


The same bug (the same stacktrace) occurs on these testcases:

aarch64-linux-gnu-gcc
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/aarch64/mops_4.c
-mabi=ilp32 -finline-stringops

aarch64-linux-gnu-gcc
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/pr34457-1.c
-mabi=ilp32 -finline-stringops

aarch64-linux-gnu-gfortran
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gfortran.dg/pr49308.f90
-finline-stringops -mabi=ilp32

aarch64-linux-gnu-gcc
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/ubsan/bounds-4b.c
-finline-stringops -mabi=ilp32 -Os

aarch64-linux-gnu-gfortran
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gfortran.dg/analyzer/deferred_character_25.f90
-mabi=ilp32 -finline-stringops


ICE in plus_constant (similar, but different stacktrace) also occurs here:

aarch64-linux-gnu-gcc
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/aarch64/test_frame_5.c
-mabi=ilp32 -ftrivial-auto-var-init=pattern -finline-stringops

aarch64-linux-gnu-gcc
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/aarch64/stack-check-prologue-15.c
-ftrivial-auto-var-init=pattern -mabi=ilp32 -finline-stringops

aarch64-linux-gnu-g++
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/g++.dg/vect/pr84362.cc
-ftrivial-auto-var-init=pattern -mabi=ilp32 -finline-stringops


There are many more testcases that currently produce an ICE in plus_constant.
I'm attaching a full log of the ICEs.


Configuration of the compiler:

Using built-in specs.
COLLECT_GCC=/home/worker/cross/bin/aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/worker/cross/libexec/gcc/aarch64-linux-gnu/14.0.0/lto-wrapper
Target: aarch64-linux-gnu
Configured with:
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/configure
--enable-languages=c,c++,fortran,rust,m2 --disable-bootstrap
--disable-libsanitizer --disable-multil

[Bug target/112804] ICE in aarch64 crosscompiler in plus_constant, at explow.cc:102 with -mabi=ilp32

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

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

--- Comment #1 from Andrew Pinski  ---
Looks like -finline-stringops is not correc5 for the case where ptrmode !=
Pmode. I might take a look next week or the week afterwards.

I also suspect you might hit it on x32 also.

[Bug c/91092] Error on implicit function declarations by default

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug c/106416] -Wint-conversion should be an error, not a pedwarn

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug c/91093] Error on implicit int by default

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug c/96284] Outdated C features should be made errors with newer standards

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

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

Sam James  changed:

   What|Removed |Added

 Depends on||108476, 85678
   See Also|https://gcc.gnu.org/bugzill |
   |a/show_bug.cgi?id=108476|
   Target Milestone|--- |14.0

--- Comment #14 from Sam James  ---
I'm going to boldly call this done for 14 given we've covered all the major
stuff, with the exception of prototypes which as discussed elsewhere are not
easy to split up into obsolete/not.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
[Bug 85678] -fno-common should be default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108476
[Bug 108476] Please turn -Wreturn-type on by default for C

[Bug c/96284] Outdated C features should be made errors with newer standards

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #15 from Sam James  ---
.

[Bug target/112801] [14] RISC-V vector: failure to mask top bits during type conversion

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

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

--- Comment #3 from JuzheZhong  ---
(In reply to Richard Biener from comment #2)
> I think wrong-code should be high-priority ;)

Oh. I see. Sorry. I thought it was the previous RVV shift ISA issue.
since I saw c(g[1] >> 32);

Confirm it is wrong code. Will take a look at it.

Thanks for remind.

[Bug middle-end/112750] wrong code with _BitInt(256) and above with __builtin_sub_overflow_p() at -O0

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:364332658ef790d09d250db39c5b13e27c3543f1

commit r14-6042-g364332658ef790d09d250db39c5b13e27c3543f1
Author: Jakub Jelinek 
Date:   Fri Dec 1 09:25:45 2023 +0100

lower-bitint: Fix _BitInt .{ADD,SUB}_OVERFLOW lowering [PR112750]

The .{ADD,SUB}_OVERFLOW lowering is implemented by performing normal
addition/subtraction (perhaps extended to even more bits than normally by
continuing with extended values of operands after running of normal bits)
and in addition to that trying to compute if certain sets of bits are
either
all zero or all sign extensions of the least significant bit.

That code is in a lot of cases guarded just by a single condition (which
can be idx > startlimb, idx >= startlimb or idx == startlimb) or by
2 conditions - if (idx >= startlimb) { if (idx == startlimb) ... else ... }
Now, if_then_if_then_else when the second argument is NULL works just as
if_then and sets m_gsi to be within the initially empty then block and that
is
where we emit code for constant tidx startlimb + (cmp_code == GT_EXPR).
But in the 2 conditions case, m_gsi is set to the initially empty else
block, so using EQ_EXPR for the condition was incorrect (and strangely
nothing in the testsuite caught that), because the code for extracting the
lowest set of bits (i.e. when tidx is startlimb) is then done when idx
is not startlimb rather than when it is.
The following patch fixes that.

Note, when developing the lowering, I was using gcov to make sure all code
is covered by the testsuite with minimum exceptions, so no idea how this
slipped out.

2023-12-01  Jakub Jelinek  

PR middle-end/112750
* gimple-lower-bitint.cc
(bitint_large_huge::lower_addsub_overflow):
Use NE_EXPR rather than EQ_EXPR for g2 if !single_comparison and
adjust probabilities.

* gcc.dg/bitint-41.c: Use -std=c23 rather than -std=c2x.
* gcc.dg/torture/bitint-43.c: Likewise.
* gcc.dg/torture/bitint-44.c: Likewise.
* gcc.dg/torture/bitint-45.c: New test.

[Bug middle-end/112750] wrong code with _BitInt(256) and above with __builtin_sub_overflow_p() at -O0

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Fixed now.

[Bug c/96284] Outdated C features should be made errors with newer standards

[david at westcontrol dot com via Gcc-bugs]

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

--- Comment #16 from David Brown  ---
Thank you for making these changes.  There's always a trade-off between
supporting code that "has always compiled fine and works in testing", and
making it harder for people to write new poor quality code with a high risk of
bugs.  I believe, however, that changes like this help all developers - and
more importantly, help all the end-users by reducing software bug rates, even
if it is just by a very small step.

[Bug c/111400] Missing return sanitization only works in C++

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

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

--- Comment #6 from Sam James  ---
(In reply to David Brown from comment #4)
> (In reply to Andreas Schwab from comment #3)
> > You already have -W[error=]return-type.
> 
> Yes, and that is what I normally use - I am a big fan of gcc's static
> warnings.
> 
> Sometimes, however, there are false positives, or perhaps other reasons why
> the programmer thinks it is safe to ignore the warning in a particular case.

Note that we now have -Wreturn-mismatch for definite errors.

[Bug c/108224] Suggest stdlib.h header for rand

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

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

Sam James  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #6 from Sam James  ---
https://inbox.sourceware.org/gcc-patches/881e795d-34c8-0445-74cf-cb68192d2...@jguk.org/

[Bug c/106537] GCC doesn't support -W[no-]compare-distinct-pointer-types

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

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

Sam James  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |jemarch at gcc dot 
gnu.org
   Target Milestone|--- |14.0
 Resolution|--- |FIXED

--- Comment #10 from Sam James  ---
Done for 14, I think?

[Bug other/44209] [meta-bug] Some warnings are not linked to diagnostics options

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

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

Bug 106537 Summary: GCC doesn't support -W[no-]compare-distinct-pointer-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106537

   What|Removed |Added

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

[Bug target/112777] [14 Regression] profiled bootstrap fails on powerpc-linux-gnu, undefined references to __atomic_fetch_add_8

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Sebastian Huber :

https://gcc.gnu.org/g:4b8078142ee816e2bd484358b935ba1116ed9931

commit r14-6046-g4b8078142ee816e2bd484358b935ba1116ed9931
Author: Sebastian Huber 
Date:   Thu Nov 30 17:16:53 2023 +0100

gcov: Fix use of __LIBGCC_HAVE_LIBATOMIC

libgcc/ChangeLog:

PR target/112777

* libgcov.h (GCOV_SUPPORTS_ATOMIC):  Honor that
__LIBGCC_HAVE_LIBATOMIC is
always defined as either 0 or 1.

[Bug c++/112805] New: Failed to compile C++20 code with usage of modules

[ma.anshukov at gmail dot com via Gcc-bugs]

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

Bug ID: 112805
   Summary: Failed to compile C++20 code with usage of modules
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ma.anshukov at gmail dot com
  Target Milestone: ---

Created attachment 56749
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56749&action=edit
Bug report generated by g++

Failed to compile little sample of code, that use modules.
g++ asked to send bug-report.
'bug-report' file has a detailed description of a problem.

[Bug c/82919] Docs don't mention -Wimplicit-int is enabled in C99 mode

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

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

Sam James  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||sjames at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |10.0

--- Comment #2 from Sam James  ---
Fixed in r10-6882-gcf70bb0fbd7fb0.

[Bug c++/112805] Failed to compile C++20 code with usage of modules

[ma.anshukov at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Mikhail Anshukov  ---
Created attachment 56750
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56750&action=edit
Bug report generated by g++

[Bug c++/112588] ICE in make_decl_rtl when returning str literal when string header imported in module

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||ma.anshukov at gmail dot com

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

[Bug c++/112805] Failed to compile C++20 code with usage of modules

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 112805 Summary: Failed to compile C++20 code with usage of modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112805

   What|Removed |Added

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

[Bug gcov-profile/112806] Profile-Guided Optimization (PGO) policy regarding explicit user optimization hint behavior

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

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

--- Comment #1 from Andrew Pinski  ---
[[likely]]/__builtin_expect is kinda of documented:

https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Other-Builtins.html#index-fprofile-arcs-1

Everything else is just a hint.

[Bug gcov-profile/112806] Profile-Guided Optimization (PGO) policy regarding explicit user optimization hint behavior

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> [[likely]]/__builtin_expect is kinda of documented:
> 
> https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Other-Builtins.html#index-
> fprofile-arcs-1
> 
> Everything else is just a hint.

I should say a hint and mostly ignored.

[Bug gcov-profile/112806] Profile-Guided Optimization (PGO) policy regarding explicit user optimization hint behavior

[zamazan4ik at tut dot by via Gcc-bugs]

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

--- Comment #3 from Alexander Zaitsev  ---
> https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Other-Builtins.html#index-fprofile-arcs-1

I already read this and still do not understand the actual behavior. If PGO
profiles show that the branch is "cold" but a user write for this branch via
__builtin_expect/[[likely]] that the branch is "hot" - what decision will be
made by the optimizer?

On the link above there is only "In general, you should prefer to use actual
profile feedback for this (-fprofile-arcs), as programmers are notoriously bad
at predicting how their programs actually perform.". But it does not specify
the actual behavior - it's just a recommendation to use PGO instead of manual
[[likely]] hints.

[Bug target/112698] gcc r14-5617-gb8592186611 introduces regressions in bfloat16_vector_typecheck_1.c for cortex-m0 and cortex-m3

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

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org,
   ||rearnsha at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #6 from Christophe Lyon  ---
adding maintainers who might provide larger context wrt compatibility with
other compilers.

[Bug target/91035] [11/12/13/14 Regression] gotools fails to build on s390x-linux-gnu

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

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

Matthias Klose  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||doko at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #15 from Matthias Klose  ---
closing, fixed

[Bug target/102260] amdgcn offload compiler fails to configure, not matching target directive's target id

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

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

Matthias Klose  changed:

   What|Removed |Added

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

--- Comment #2 from Matthias Klose  ---
closing this one, LLVM 15, 16, 17 are known to work

[Bug modula2/93575] the modula2 frontend fails to build with a profiled bootstrap

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

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

Matthias Klose  changed:

   What|Removed |Added

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

--- Comment #4 from Matthias Klose  ---
closing this one, works with 13.2.1 and 14.0

[Bug libgcc/109289] Conflicting types for built-in functions in libgcc/emutls.c

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   Last reconfirmed||2023-12-01
 CC||ams at gcc dot gnu.org,
   ||fw at gcc dot gnu.org,
   ||jules at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Thomas Schwinge  ---
Similarly seen for GCN target, and this is now fatal after Florian's recent
changes (I presume -- and I fully do support those, for avoidance of doubt):

[...]/source-gcc/libgcc/emutls.c:61:7: warning: conflicting types for
built-in function ‘__emutls_get_address’; expected ‘void *(void *)’
[-Wbuiltin-declaration-mismatch]
   61 | void *__emutls_get_address (struct __emutls_object *);
  |   ^~~~
[...]/source-gcc/libgcc/emutls.c:63:6: warning: conflicting types for
built-in function ‘__emutls_register_common’; expected ‘void(void *, unsigned
int,  unsigned int,  void *)’ [-Wbuiltin-declaration-mismatch]
   63 | void __emutls_register_common (struct __emutls_object *, word,
word, void *);
  |  ^~~~
[...]/source-gcc/libgcc/emutls.c:140:1: warning: conflicting types for
built-in function ‘__emutls_get_address’; expected ‘void *(void *)’
[-Wbuiltin-declaration-mismatch]
  140 | __emutls_get_address (struct __emutls_object *obj)
  | ^~~~
[...]/source-gcc/libgcc/emutls.c: In function ‘__emutls_get_address’:
[...]/source-gcc/libgcc/emutls.c:172:13: error: implicit declaration of
function ‘calloc’ [-Wimplicit-function-declaration]
  172 |   arr = calloc (size + 1, sizeof (void *));
  | ^~
[...]/source-gcc/libgcc/emutls.c:32:1: note: include ‘’ or
provide a declaration of ‘calloc’
   31 | #include "gthr.h"
  +++ |+#include 
   32 |
[...]/source-gcc/libgcc/emutls.c:172:13: warning: incompatible implicit
declaration of built-in function ‘calloc’ [-Wbuiltin-declaration-mismatch]
  172 |   arr = calloc (size + 1, sizeof (void *));
  | ^~
[...]/source-gcc/libgcc/emutls.c:172:13: note: include ‘’ or
provide a declaration of ‘calloc’
[...]/source-gcc/libgcc/emutls.c:184:13: error: implicit declaration of
function ‘realloc’ [-Wimplicit-function-declaration]
  184 |   arr = realloc (arr, (size + 1) * sizeof (void *));
  | ^~~
[...]/source-gcc/libgcc/emutls.c:184:13: note: include ‘’ or
provide a declaration of ‘realloc’
[...]/source-gcc/libgcc/emutls.c:184:13: warning: incompatible implicit
declaration of built-in function ‘realloc’ [-Wbuiltin-declaration-mismatch]
[...]/source-gcc/libgcc/emutls.c:184:13: note: include ‘’ or
provide a declaration of ‘realloc’
[...]/source-gcc/libgcc/emutls.c: At top level:
[...]/source-gcc/libgcc/emutls.c:204:1: warning: conflicting types for
built-in function ‘__emutls_register_common’; expected ‘void(void *, unsigned
int,  unsigned int,  void *)’ [-Wbuiltin-declaration-mismatch]
  204 | __emutls_register_common (struct __emutls_object *obj,
  | ^~~~
make[2]: *** [[...]/source-gcc/libgcc/static-object.mk:17: emutls.o] Error
1

GCC's suggestion to "include ‘’" needs to be carefully reviewed, in
case this is meant to be buildable in an environment without C library headers?

[Bug tree-optimization/112807] New: ICE: SIGSEGV in contains_struct_check (tree.h:3747) with _BitInt() at -O1 and above

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 112807
   Summary: ICE: SIGSEGV in contains_struct_check (tree.h:3747)
with _BitInt() at -O1 and above
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 56751
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56751&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c -wrapper valgrind,-q
==11799== Invalid read of size 2
==11799==at 0x253EF3F: contains_struct_check (tree.h:3747)
==11799==by 0x253EF3F: (anonymous
namespace)::bitint_large_huge::lower_addsub_overflow(tree_node*, gimple*)
(gimple-lower-bitint.cc:3951)
==11799==by 0x2543129: (anonymous
namespace)::bitint_large_huge::lower_call(tree_node*, gimple*)
(gimple-lower-bitint.cc:5039)
==11799==by 0x254D626: gimple_lower_bitint() (gimple-lower-bitint.cc:6386)
==11799==by 0x13A2D3A: execute_one_pass(opt_pass*) (passes.cc:2641)
==11799==by 0x13A361F: execute_pass_list_1(opt_pass*) (passes.cc:2750)
==11799==by 0x13A3631: execute_pass_list_1(opt_pass*) (passes.cc:2751)
==11799==by 0x13A3658: execute_pass_list(function*, opt_pass*)
(passes.cc:2761)
==11799==by 0xFB0755: expand (cgraphunit.cc:1841)
==11799==by 0xFB0755: cgraph_node::expand() (cgraphunit.cc:1794)
==11799==by 0xFB1A9A: expand_all_functions (cgraphunit.cc:2024)
==11799==by 0xFB1A9A: symbol_table::compile() [clone .part.0]
(cgraphunit.cc:2398)
==11799==by 0xFB4607: compile (cgraphunit.cc:2311)
==11799==by 0xFB4607: symbol_table::finalize_compilation_unit()
(cgraphunit.cc:2583)
==11799==by 0x14E5F21: compile_file() (toplev.cc:473)
==11799==by 0xDD221B: do_compile (toplev.cc:2150)
==11799==by 0xDD221B: toplev::main(int, char**) (toplev.cc:2306)
==11799==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==11799== 
during GIMPLE pass: bitintlower
testcase.c: In function 'foo':
testcase.c:2:1: internal compiler error: Segmentation fault
2 | foo (unsigned a, _BitInt (2) b, _BitInt (256) c)
  | ^~~
0x14e5a3f crash_signal
/repo/gcc-trunk/gcc/toplev.cc:316
0x253ef3f contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/repo/gcc-trunk/gcc/tree.h:3747
0x253ef3f lower_addsub_overflow
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:3951
0x2543129 lower_call
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:5039
0x254d626 gimple_lower_bitint
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:6386
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.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-6048-20231201170246-g6563d6767ed-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-6048-20231201170246-g6563d6767ed-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231201 (experimental) (GCC)

[Bug middle-end/112771] during GIMPLE pass: bitintlower0 ICE: in build_bitint_type, at tree.cc:7178 with _BitInt(65535) and division by zero

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r14-6050-g9bfebcb1b7ae4e7160644f2104424d6bab4a23f7
Author: Jakub Jelinek 
Date:   Fri Dec 1 10:55:49 2023 +0100

lower-bitint: Fix up handle_operand_addr for 0 constants [PR112771]

handle_operand_addr for INTEGER_CSTs uses wi::min_precision (UNSIGNED
for non-negative constants, SIGNED for negative ones) and from that
computes mp as minimum number of limbs which can represent that value,
and in some cases creates a test BITINT_TYPE with that precision to
categorize it and decide based on that what types to use on the constant
emitted into memory.  For the actual precisions (what will be passed
to libgcc) it actually already uses MAX/MIN to adjust the corner cases:
  *prec = MAX (min_prec, 1);
...
  *prec = MIN ((int) -min_prec, -2);
but for integer_zerop min_prec will be 0,
mp = CEIL (min_prec, limb_prec) * limb_prec;
will be also 0 and we ICE trying to build unsigned BITINT_TYPE with
0 precision.

Fixed thusly by noting even 0 has to be encoded at least as one limb.

2023-12-01  Jakub Jelinek  

PR middle-end/112771
* gimple-lower-bitint.cc (bitint_large_huge::handle_operand_addr):
Use mp = 1 if it is zero.

* gcc.dg/bitint-44.c: New test.

[Bug other/91209] gm2 bootstrap comparison failure

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

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

Matthias Klose  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME
 CC||doko at gcc dot gnu.org

--- Comment #5 from Matthias Klose  ---
closing this one, works on GCC 13 and 14

[Bug middle-end/112770] during GIMPLE pass: bitintlower0 ICE: verify_gimple failed: statement marked for throw in middle of block with -fnon-call-exceptions and _BitInt(128)

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r14-6051-gb1fe98dee21773b9d908469effe2580567b903fb
Author: Jakub Jelinek 
Date:   Fri Dec 1 10:56:52 2023 +0100

lower-bitint: Fix lowering of middle sized _BitInt operations which can
throw [PR112770]

The middle kind _BitInt lowering is mostly done by casting the BITINT_TYPE
operands (if any) to a signed/unsigned integer type which has larger/equal
precision, using such integer type also for the lhs (if BITINT_TYPE) and
and adding a cast after the statement from that new lhs to the old
(BITINT_TYPE) lhs.  Note, for middle kind this isn't done for GIMPLE_CALLs.
Most of the time that works nicely, the exception as the following testcase
shows is -fnon-call-exceptions and some operations which can trap.  Because
inserting the cast to a new lhs after the statement results in a trapping
statement in the middle of a basic block.
The following patch fixes that by emitting the cast on the fallthru edge
instead.

2023-12-01  Jakub Jelinek  

PR middle-end/112770
* gimple-lower-bitint.cc (gimple_lower_bitint): When adjusting
lhs of middle _BitInt setter which ends bb, insert cast on
the fallthru edge rather than after stmt.

* gcc.dg/bitint-45.c: New test.

[Bug modula2/92148] gm2: race condition building gm2 on trunk

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

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

Matthias Klose  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|WAITING |RESOLVED
 CC||doko at gcc dot gnu.org

--- Comment #4 from Matthias Klose  ---
closing, works with GCC 13 and 14

[Bug middle-end/112770] during GIMPLE pass: bitintlower0 ICE: verify_gimple failed: statement marked for throw in middle of block with -fnon-call-exceptions and _BitInt(128)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug middle-end/112771] during GIMPLE pass: bitintlower0 ICE: in build_bitint_type, at tree.cc:7178 with _BitInt(65535) and division by zero

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug bootstrap/79792] configuring a nvptx-none build with --program-suffix=-7 results in a misnamed installed binary

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

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

Matthias Klose  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Matthias Klose  ---
closing, works with GCC 13 and 14

[Bug libgcc/109289] Conflicting types for built-in functions in libgcc/emutls.c

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

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

--- Comment #3 from Florian Weimer  ---
Jan, do you actually experience a build failure? The part you quoted only shows
warnings.

Thomas, the safe thing to do would be to use __builtin_calloc and
__builtin_realloc in those spots because it avoids a dependency on an external
header that might not exist at this point.

[Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b

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

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

--- Comment #8 from Robin Dapp  ---
Thanks for the testcase.  It looks pretty similar to the situation why I
introduced the bitmask extract in the first place and I don't think that's the
root cause.

As last time the problem is that the generic bit_field_ref expansion code does
not handle bitmask extraction with a precision < 8 very well and this is why we
run into an assertion failure.  I worked around this by providing the extract
expander so we don't go down that road.

The difference to before is that the bit_field_ref occurs in the epilogue (i.e.
not LOOP_VINFO_FULLY_WITH_LENGTH_P) so we fall back.

Maybe we can work around it by providing a fold_extract_last implementation for
masks (even though the operation itself seems a bit weird).  Will see how far I
get with it.

[Bug libstdc++/112808] New: Consider enabling _GLIBCXX_ASSERTIONS checks by default for debug builds

[helge at penne dot no via Gcc-bugs]

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

Bug ID: 112808
   Summary: Consider enabling _GLIBCXX_ASSERTIONS checks by
default for debug builds
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helge at penne dot no
  Target Milestone: ---

In my experience, the assertions enabled by _GLIBCXX_ASSERTIONS are incredidbly
important and effective, but sadly nowhere near as well known or widely used as
they deserve to be.

Lately, C++ has been attracting negative attention for security, and using
_GLIBCXX_ASSERTIONS is probably one of the most efficient and easy ways to
improve things in the short term.

Should the checks enabled by _GLIBCXX_ASSERTIONS enabled by default in debug
builds (somewhat like with NDEBUG and the assert macro), effectlively making
them "opt-out" instead of "opt-in"?  This will allow a lot of latent security
bugs to be detected before software is put into production.

This will have a performance hit on unoptimized builds, but my experience so
far is that the performance hit on optimized builds is small because the
optimizer is very often able to figure out that the checks are redundant, and
will remove them.

I think making these checks enabled by default in debug builds will have huge
positive impact on the security of C++ code bases, at an acceptable cost.  It
also sends a message that the language add tools is evolving in a more secure
direction.

[Bug gcov-profile/112806] Profile-Guided Optimization (PGO) policy regarding explicit user optimization hint behavior

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
Version|unknown |14.0

--- Comment #4 from Richard Biener  ---
I think it depends on whether the code was executed at all during training
dependent on -fprofile-partial-training which does regular profile guessing
for untrained parts of the program.

In general the situation is complicated and it's difficult to document
behavior with a short description.

[Bug sanitizer/112644] [14 Regression] Some of the hwasan testcase fail after the recent merge

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

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

--- Comment #6 from Tamar Christina  ---
Matthew has been working on this and so far has concluded:

Summary of main problem:

New libhwasan runtime libraries have added interceptors for various mem*, str*
functions (and I think others -- I do not have full list).

With old runtime libraries these were not intercepted, and we emitted inline
instrumentation to accommodate.
Removing our instrumentation is fine (though with the caveat that we need to
ensure we have the full list of functions which are now intercepted).

However, the libraries hard-code the choice to abort on error, which means the
HWASAN_OPTIONS environment variable can no longer be used to ensure recover on
error (-fsanitize-recover=hwaddress option).

Changes I believe should happen:
- LLVM upstream libsanitizer code be changed to allow recovery -- AFAIK there
is no functional loss from using ErrorAction::Recover in the checking.
- We find the list of functions which are now instrumented, and update
asan_instrumented_p accordingly (plus a testcase or two for this).

The first one was discussed on the LLVM discourse and it was deemed a bug
https://discourse.llvm.org/t/hwasan-question-about-the-recent-interceptors-being-added/75351/4
and a PR made to fix it https://github.com/llvm/llvm-project/pull/74000

Once that's merged we can re-sync and we need to update the list of intercepted
functions in asan_intercepted_p (in gcc/asan.h).  One of the reasons for the
change is that LLVM now replaces calls to e.g. memset with __hwasan_memset to
avoid later passes optimizing the call.  It looks like we need to do that for
GCC as well.

Matthew will be away for a while so will take over the patch from him in
stage-4.

[Bug sanitizer/112644] [14 Regression] Some of the hwasan testcase fail after the recent merge

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

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

Tamar Christina  changed:

   What|Removed |Added

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

[Bug tree-optimization/112809] New: during GIMPLE pass: bitintlower ICE: in limb_access_type, at gimple-lower-bitint.cc:563 at -O1 and above

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 112809
   Summary: during GIMPLE pass: bitintlower ICE: in
limb_access_type, at gimple-lower-bitint.cc:563 at -O1
and above
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 56752
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56752&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c 
during GIMPLE pass: bitintlower
testcase.c: In function 'foo':
testcase.c:6:1: internal compiler error: in limb_access_type, at
gimple-lower-bitint.cc:563
6 | foo (void)
  | ^~~
0xd520e1 limb_access_type
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:563
0x2535e97 limb_access_type
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:559
0x2535e97 limb_access
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:578
0x2546609 lower_mergeable_stmt
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:2693
0x254af8d lower_stmt
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:5265
0x254d626 gimple_lower_bitint
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:6394
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.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-6051-20231201105652-gb1fe98dee21-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-6051-20231201105652-gb1fe98dee21-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231201 (experimental) (GCC)

[Bug middle-end/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0

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

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

--- Comment #11 from Richard Biener  ---
The only thing that's maybe suspicious is that

machine_mode mode = GET_MODE (target);

but we test

/* Use sign-extension for uniform boolean vectors with
   integer modes.  Effectively "vec_duplicate" for bitmasks.  */
if (!TREE_SIDE_EFFECTS (exp)
&& VECTOR_BOOLEAN_TYPE_P (type)
&& SCALAR_INT_MODE_P (mode)

where we might want to test SCALAR_INT_MODE_P (TYPE_MODE (type)) instead.
Not sure if we ever call store_constructor with target not having the same
mode as 'exp' though ...  Or we should check that mode == TYPE_MODE (type)
since we're moving to target anyway.

[Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b

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

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

--- Comment #9 from Robin Dapp  ---
Ok, it's not the fold_extract_last expander.  It just appeared that way here
because I disabled some other things.

What we want to do is extract the last element from a vector.  This works as
long as we have a loop length (or a loop mask) as we can defer that to
vec_extract with element index len - 1.

In the epilog here we don't have either so the only workaround I can quickly
think of is allowing a poly_int constant as vec_extract index (where we know
the vector length and can extract the proper thing with a bit of extra work).

Richi, Richard:  Is that somehow viable or am I on the wrong track?

[Bug target/112753] [14 Regression] unrecognizable insn building glibc for s390x

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|jakub at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

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

[Bug c++/112810] New: bogus ambiguous overload resolution when taking address of static/xobj member function template introduced by using declaration where candidates have a mismatched deduced return

[waffl3x at protonmail dot com via Gcc-bugs]

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

Bug ID: 112810
   Summary: bogus ambiguous overload resolution when taking
address of static/xobj member function template
introduced by using declaration where candidates have
a mismatched deduced return type
   Product: gcc
   Version: 4.9.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: waffl3x at protonmail dot com
  Target Milestone: ---

struct B {
  static auto f(auto) { return 10; }
  static int g(auto) { return 10; }
};

struct S0 : B {
  using B::f;
  using B::g;
  static auto f(auto) { return 5; }
  static auto g(auto) { return 5; }
};

struct S1 : B {
  using B::f;
  using B::g;
  static int f(auto) { return 5; }
  static int g(auto) { return 5; }
};

void test()
{
  int (*p0)(int) = &S0::f;
  int (*p1)(int) = &S0::g;
  int (*p2)(int) = &S1::f;
  int (*p3)(int) = &S1::g;
}


https://godbolt.org/z/ebcjshfYd

This does not present in other cases of overload resolution as far as
I've seen. It did not seem to manifest for implicit object member
functions at all.

The godbolt reproducer uses a slightly different test case to test much
older versions of the compiler. I was shocked to find out just how far
back this goes. And I was investigating it to make sure my patch wasn't
causing it!

I can look into fixing it after I finish my patch, if I remember, but
that's why I'm posting this report, just in case I don't remember. :^)

[Bug target/112777] [14 Regression] profiled bootstrap fails on powerpc-linux-gnu, undefined references to __atomic_fetch_add_8

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Biener  ---
The issue might be we do not use vec_extract for memory arguments:

  /* Use vec_extract patterns for extracting parts of vectors whenever
 available.  If that fails, see whether the current modes and bitregion
 give a natural subreg.  */  
  machine_mode outermode = GET_MODE (op0);
  if (VECTOR_MODE_P (outermode) && !MEM_P (op0))
{   

and somehow the original reg operand got spilled inbetween.  That happens
here, after we could make vec_extract work for this.

  /* Make sure we are playing with integral modes.  Pun with subregs
 if we aren't.  */
  opt_scalar_int_mode op0_mode = int_mode_for_mode (GET_MODE (op0));
  scalar_int_mode imode;
  if (!op0_mode.exists (&imode) || imode != GET_MODE (op0))
{ 
...
  else
{
  poly_int64 size = GET_MODE_SIZE (GET_MODE (op0));
  rtx mem = assign_stack_temp (GET_MODE (op0), size);
  emit_move_insn (mem, op0);
  op0 = adjust_bitfield_address_size (mem, BLKmode, 0, size);
}

now, if we spilled we can elide the round-down I think (which is for
the fear of accessing invalid memory).  Thus like the following?

diff --git a/gcc/expmed.cc b/gcc/expmed.cc
index b294eabb08d..e2b38b87bdf 100644
--- a/gcc/expmed.cc
+++ b/gcc/expmed.cc
@@ -1856,7 +1856,7 @@ extract_bit_field_1 (rtx str_rtx, poly_uint64 bitsize,
poly_uint64 bitnum,
   /* If we have a memory source and a non-constant bit offset, restrict
  the memory to the referenced bytes.  This is a worst-case fallback
  but is useful for things like vector booleans.  */
-  if (MEM_P (op0) && !bitnum.is_constant ())
+  if (MEM_P (str_rtx) && !bitnum.is_constant ())
 {
   bytenum = bits_to_bytes_round_down (bitnum);
   bitnum = num_trailing_bits (bitnum);

but that defers the ICE to

during RTL pass: expand
t.c: In function 'e':
t.c:4:6: internal compiler error: in to_constant, at poly-int.h:588
4 | void e(unsigned f) {
  |  ^
0x10ea530 poly_int<2u, unsigned long>::to_constant() const
/home/rguenther/src/trunk/gcc/poly-int.h:588
0x13cec67 extract_bit_field_1
/home/rguenther/src/trunk/gcc/expmed.cc:1872

so I guess we really need to match the vec_extract pattern.

So you need to debug why that doesn't match here.

[Bug target/112431] RISC-V GCC-15 feature: Support register overlap on widen RVV instructions

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

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

--- Comment #10 from GCC Commits  ---
The trunk branch has been updated by Lehua Ding :

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

commit r14-6055-ga23415d7572774701d7ec04664390260ab9a3f63
Author: Juzhe-Zhong 
Date:   Fri Dec 1 15:00:27 2023 +0800

RISC-V: Support highpart register overlap for widen vx/vf instructions

This patch leverages the same approach as vwcvt.

Before this patch:

.L5:
add a3,s0,s1
add a4,s6,s1
add a5,s7,s1
vsetvli zero,s0,e32,m4,ta,ma
vle32.v v16,0(s1)
vle32.v v12,0(a3)
mv  s1,s2
vle32.v v8,0(a4)
vle32.v v4,0(a5)
nop
vfwadd.vf   v24,v16,fs0
vfwadd.vf   v16,v12,fs0
vs8r.v  v16,0(sp)-> spill
vfwadd.vf   v16,v8,fs0
vfwadd.vf   v8,v4,fs0
nop
vsetvli zero,zero,e64,m8,ta,ma
vfmv.f.sfa4,v24
vl8re64.v   v24,0(sp)   -> reload
vfmv.f.sfa5,v24
fcvt.lu.d a0,fa4,rtz
fcvt.lu.d a1,fa5,rtz
vfmv.f.sfa4,v16
vfmv.f.sfa5,v8
fcvt.lu.d a2,fa4,rtz
fcvt.lu.d a3,fa5,rtz
add s2,s2,s5
callsumation
add s3,s3,a0
bgeus4,s2,.L5

After this patch:

.L5:
add a3,s0,s1
add a4,s6,s1
add a5,s7,s1
vsetvli zero,s0,e32,m4,ta,ma
vle32.v v4,0(s1)
vle32.v v28,0(a3)
mv  s1,s2
vle32.v v20,0(a4)
vle32.v v12,0(a5)
vfwadd.vf   v0,v4,fs0
vfwadd.vf   v24,v28,fs0
vfwadd.vf   v16,v20,fs0
vfwadd.vf   v8,v12,fs0
vsetvli zero,zero,e64,m8,ta,ma
vfmv.f.sfa4,v0
vfmv.f.sfa5,v24
fcvt.lu.d a0,fa4,rtz
fcvt.lu.d a1,fa5,rtz
vfmv.f.sfa4,v16
vfmv.f.sfa5,v8
fcvt.lu.d a2,fa4,rtz
fcvt.lu.d a3,fa5,rtz
add s2,s2,s5
callsumation
add s3,s3,a0
bgeus4,s2,.L5

PR target/112431

gcc/ChangeLog:

* config/riscv/vector.md: Support highpart overlap for vx/vf.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr112431-22.c: New test.
* gcc.target/riscv/rvv/base/pr112431-23.c: New test.
* gcc.target/riscv/rvv/base/pr112431-24.c: New test.
* gcc.target/riscv/rvv/base/pr112431-25.c: New test.
* gcc.target/riscv/rvv/base/pr112431-26.c: New test.
* gcc.target/riscv/rvv/base/pr112431-27.c: New test.

[Bug target/112431] RISC-V GCC-15 feature: Support register overlap on widen RVV instructions

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

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

--- Comment #9 from GCC Commits  ---
The trunk branch has been updated by Lehua Ding :

https://gcc.gnu.org/g:4418d55bcd1b7e0ef823981b6a781d7de5c38cce

commit r14-6054-g4418d55bcd1b7e0ef823981b6a781d7de5c38cce
Author: Juzhe-Zhong 
Date:   Fri Dec 1 16:09:59 2023 +0800

RISC-V: Support highpart overlap for indexed load with SRC EEW < DEST EEW

Leverage previous approach.

Before this patch:

.L5:
add a3,s0,s2
add a4,s6,s2
add a5,s7,s2
vsetvli zero,s0,e64,m8,ta,ma
vle8.v  v4,0(s2)
vle8.v  v3,0(a3)
mv  s2,s1
vle8.v  v2,0(a4)
vle8.v  v1,0(a5)
nop
vluxei8.v   v8,(s1),v4
vs8r.v  v8,0(sp)  ---> spill
vluxei8.v   v8,(s1),v3
vluxei8.v   v16,(s1),v2
vluxei8.v   v24,(s1),v1
nop
vmv.x.s a1,v8
vl8re64.v   v8,0(sp) ---> reload
vmv.x.s a3,v24
vmv.x.s a2,v16
vmv.x.s a0,v8
add s1,s1,s5
callsumation
add s3,s3,a0
bgeus4,s1,.L5

After this patch:

.L5:
add a3,s0,s2
add a4,s6,s2
add a5,s7,s2
vsetvli zero,s0,e64,m8,ta,ma
vle8.v  v15,0(s2)
vle8.v  v23,0(a3)
mv  s2,s1
vle8.v  v31,0(a4)
vle8.v  v7,0(a5)
vluxei8.v   v8,(s1),v15
vluxei8.v   v16,(s1),v23
vluxei8.v   v24,(s1),v31
vluxei8.v   v0,(s1),v7
vmv.x.s a3,v0
vmv.x.s a2,v24
vmv.x.s a1,v16
vmv.x.s a0,v8
add s1,s1,s5
callsumation
add s3,s3,a0
bgeus4,s1,.L5

PR target/112431

gcc/ChangeLog:

* config/riscv/vector.md: Support highpart overlap for indexed
load.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr112431-28.c: New test.
* gcc.target/riscv/rvv/base/pr112431-29.c: New test.
* gcc.target/riscv/rvv/base/pr112431-30.c: New test.
* gcc.target/riscv/rvv/base/pr112431-31.c: New test.
* gcc.target/riscv/rvv/base/pr112431-32.c: New test.
* gcc.target/riscv/rvv/base/pr112431-33.c: New test.

[Bug rtl-optimization/112760] [14 Regression] wrong code with -O2 -fno-dce -fno-guess-branch-probability -m8bit-idiv -mavx --param=max-cse-insns=0 and __builtin_add_overflow_p() since r14-5355

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[14 Regression] wrong code  |[14 Regression] wrong code
   |with -O2 -fno-dce   |with -O2 -fno-dce
   |-fno-guess-branch-probabili |-fno-guess-branch-probabili
   |ty -m8bit-idiv -mavx|ty -m8bit-idiv -mavx
   |--param=max-cse-insns=0 and |--param=max-cse-insns=0 and
   |__builtin_add_overflow_p()  |__builtin_add_overflow_p()
   ||since r14-5355
 CC||jakub at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r14-5355-g3cd3a09b3f91a1d023cb180763d40598d6bb274b

[Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b

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

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

--- Comment #11 from Robin Dapp  ---
When I define a vec_extract...bi pattern we don't enter the if (vec_extract) in
expmed because e.g.

bitsize = {1, 0}
bitnum = {3, 4}

and GET_MODE_BITSIZE (innermode) = {1, 0} with innermode = BImode.

This fails multiple_p (bitnum, GET_MODE_BITSIZE (innermode), &pos).

It is a multiple of course, but still dependent on the actual vector length.
(So we would also need to extract a [3 4] from the vector).

That would be the same as an extract_last with a CONST_M1 mask.  Maybe that's
an option?  So if we have an extract_last and no loop len or mask fall back to
an extract_last with a full mask?  That would delegate the length calculation
to the backend.

[Bug rtl-optimization/112760] [14 Regression] wrong code with -O2 -fno-dce -fno-guess-branch-probability -m8bit-idiv -mavx --param=max-cse-insns=0 and __builtin_add_overflow_p() since r14-5355

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #4 from Jakub Jelinek  ---
In reload dump I see no changes (except function_decl/var_decl addresses), in
vzeroupper, postreload, split2, ree and cmpelim dumps a bunch of extra REG_DEAD
notes
here and there in r14-5355 compared to r14-5354, and finally pro_and_epilogue
deletes
(insn 20 19 62 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 0 ax [110])
(reg:SI 1 dx [111]))) "pr112760.c":6:22 11 {*cmpsi_1}
 (expr_list:REG_UNUSED (reg:CCZ 17 flags)
(nil)))
insn.
In reload dump there is:
(insn 20 19 44 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 0 ax [110])
(reg:SI 1 dx [111]))) "pr112760.c":6:22 11 {*cmpsi_1}
 (nil))
(insn 44 20 62 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 0 ax [110])
(reg:SI 1 dx [111]))) "pr112760.c":6:22 11 {*cmpsi_1}
 (nil))
(insn 62 44 46 2 (set (reg:HI 0 ax [118])
(const_int 1 [0x1])) "pr112760.c":6:22 86 {*movhi_internal}
 (expr_list:REG_EQUIV (const_int 1 [0x1])
(nil)))
(insn 46 62 25 2 (set (reg:HI 3 bx [orig:103 _8+2 ] [103])
(if_then_else:HI (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(reg:HI 3 bx [orig:103 _8+2 ] [103])
(reg:HI 0 ax [118]))) "pr112760.c":6:22 1381 {*movhicc_noc}
 (nil))
so the insn 20 is indeed useless and in vzeroupper pass that was correctly
marked in
the notes:
(insn 20 19 44 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 0 ax [110])
(reg:SI 1 dx [111]))) "pr112760.c":6:22 11 {*cmpsi_1}
 (expr_list:REG_UNUSED (reg:CCZ 17 flags)
(nil)))
(insn 44 20 62 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 0 ax [110])
(reg:SI 1 dx [111]))) "pr112760.c":6:22 11 {*cmpsi_1}
 (expr_list:REG_DEAD (reg:SI 1 dx [111])
(expr_list:REG_DEAD (reg:SI 0 ax [110])
(nil
(insn 62 44 46 2 (set (reg:HI 0 ax [118])
(const_int 1 [0x1])) "pr112760.c":6:22 86 {*movhi_internal}
 (expr_list:REG_EQUIV (const_int 1 [0x1])
(nil)))
(insn 46 62 25 2 (set (reg:HI 3 bx [orig:103 _8+2 ] [103])
(if_then_else:HI (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(reg:HI 3 bx [orig:103 _8+2 ] [103])
(reg:HI 0 ax [118]))) "pr112760.c":6:22 1381 {*movhicc_noc}
 (expr_list:REG_DEAD (reg:CCZ 17 flags)
(expr_list:REG_DEAD (reg:HI 0 ax [118])
(nil
But then postreload deletes insn 44 rather than 20 and keeps the notes around
unchanged.
Insn 20 is deleted in
#2  0x00cce9df in copyprop_hardreg_forward_1 (bb=, vd=0x3bd2be0) at ../../gcc/regcprop.cc:829
#3  0x00ccfe1c in copyprop_hardreg_forward_bb_without_debug_insn
(bb=) at ../../gcc/regcprop.cc:1235
#4  0x00d5b371 in prepare_shrink_wrap (entry_block=) at ../../gcc/shrink-wrap.cc:451
#5  0x00d5bb70 in try_shrink_wrapping (entry_edge=0x7fffd900,
prologue_seq=0x7fffe9f25240) at ../../gcc/shrink-wrap.cc:674
#6  0x008b4320 in thread_prologue_and_epilogue_insns () at
../../gcc/function.cc:6056
and regcprop.cc documents it relies on up to date REG_DEAD/REG_UNUSED notes;
after all
the removal happens in
  /* Detect obviously dead sets (via REG_UNUSED notes) and remove them.  */
  if (set
  && !RTX_FRAME_RELATED_P (insn)
  && NONJUMP_INSN_P (insn)
  && !may_trap_p (set)
  && find_reg_note (insn, REG_UNUSED, SET_DEST (set))
  && !side_effects_p (SET_SRC (set))
  && !side_effects_p (SET_DEST (set)))
{
  bool last = insn == BB_END (bb);
  delete_insn (insn);
  if (last)
break;
  continue;
}
and regcprop.cc calls df_note_add_problem (); before calling df_analyze (). 
Except
in the pro_and_epilogue case it is done elsewhere and it just calls into the
regcprop.cc functions.

[Bug rtl-optimization/112760] [14 Regression] wrong code with -O2 -fno-dce -fno-guess-branch-probability -m8bit-idiv -mavx --param=max-cse-insns=0 and __builtin_add_overflow_p() since r14-5355

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 56753
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56753&action=edit
gcc14-pr112760.patch

Untested fix.

[Bug testsuite/112728] gcc.dg/scantest-lto.c FAILs

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

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #3 from Jorn Wolfgang Rennecke  ---
> (In reply to Rainer Orth from comment #0)
>> The gcc.dg/scantest-lto.c FAILs on quite a number of targets:
> ... 
>> * On Darwin, the __TEXT,__eh_frame contains .ascii because the assembler
>>   lacks support for cfi directives.
>
> I suppose we could handle the darwin case by:
>
> - Not doing the common scan-assembler* tests for darwin

I guess it would be better to use the recently introduce cfi
effective-target keyword to catch targets that would show ascii in
there.

> - doing a scan-assembler-times test that expects exactly how many .ascii are
> emitted for cfi.

While that's an option, I suspect that's going too far actually.

[Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #12 from rguenther at suse dot de  ---
On Fri, 1 Dec 2023, rdapp at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
> 
> --- Comment #11 from Robin Dapp  ---
> When I define a vec_extract...bi pattern we don't enter the if (vec_extract) 
> in
> expmed because e.g.
> 
> bitsize = {1, 0}
> bitnum = {3, 4}
> 
> and GET_MODE_BITSIZE (innermode) = {1, 0} with innermode = BImode.
> 
> This fails multiple_p (bitnum, GET_MODE_BITSIZE (innermode), &pos).
> 
> It is a multiple of course, but still dependent on the actual vector length.
> (So we would also need to extract a [3 4] from the vector).
> 
> That would be the same as an extract_last with a CONST_M1 mask.  Maybe that's
> an option?  So if we have an extract_last and no loop len or mask fall back to
> an extract_last with a full mask?  That would delegate the length calculation
> to the backend.

Hm, yeah, but is that an issue?  I guess all vec_extract can end up
at a variable position with VLA?

[Bug libstdc++/112796] header implicitly includes

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Jonathan Wakely  ---
This is not a bug in GCC, the C++ standard allows any header to include any
other. The bug is in your code, and we can't generally diagnose it.

It's simply not possible to implement  without at least some of the
concepts defined in , because the algos are specified in terms of
those concepts.

Similarly, nearly every header includes the  header.

While it would be nice if we didn't expose all of  for any program
that doesn't include it explicitly, that's just not practical, sorry.

[Bug libstdc++/112796] header implicitly includes

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> This is not a bug in GCC, the C++ standard allows any header to include any
> other.


See [res.on.headers] in the C++ standard:
"A C++ header may include other C++ headers. A C++ header shall provide the
declarations and definitions that appear in its synopsis. A C++ header shown in
its synopsis as including other C++ headers shall provide the declarations and
definitions that appear in the synopses of those other headers."

N.B. this is different from C, which does not allow e.g.  to include
.

[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
The problem is that the toplevel configure (which is autoconf 2.69 as pretty
much everything in gcc) uses the older AC_PROG_CC, which only checks for
-std=gnu99 -std=c99 -c99 -AC99 -D_STDC_C99= -qlanglvl=extc99, not for
-std=gnu11.
And sets
CC = @CC@
in toplevel Makefile.in to
CC = gcc -std=gnu99
in toplevel objdir Makefile.  That gets then passed to in-tree gettext (if
present, I really don't think you need it on powerpc64-linux-gnu, perhaps
download_prerequisities should be smarter and check if gettext is really
needed) configure (where it just means
CC is set there to gcc -std=gnu99 -std=gnu11 in gettext/Makefile), but worse is
passed as CC="gcc -std=gnu99" in environment down when doing make all in the
gettext subdir.
I think that is something very similar to how CXX="g++ -std=c++11" is being
passed down
to in-tree isl build and breaks with recent isl which wants to use C++17 or
what.
Strangely, in my x86_64-linux toplevel Makefile I only have
CC = gcc
CXX = g++ -std=c++11
Dunno why it hasn't added -std=gnu99 there, maybe because that gcc already
defaults to gnu17?  Anyway, even when CC = gcc, I think that is passed down to
make of the in-tree compilations.
So, I guess if we don't want to switch to autoconf 2.70 or later (which I think
is a lot of work), one possibility if we know gettext relies on C11 and newest
ISL relies on C++17 (does it really?) would be to add explicit probing in
configure for -std=gnu11 or -std=c11 and if that works, pass it down in the
gettext build case; and similarly for isl.  Maybe better not in CC/CXX but in
CFLAGS/CXXFLAGS?
The propagation of flags is done in $(HOST_EXPORTS) and for stage2+
$(POSTSTAGE1_HOST_EXPORTS).

Looking around in Makefile.def, I see e.g. for gmp/mpfr we use
extra_make_flags='AM_CFLAGS="-DNO_ASM"';
and for isl
extra_make_flags='V=1';
Dunno if it would work to add for the gettext case
extra_make_flags='CFLAGS="$(CFLAGS) @C11_CFLAGS@"';
with configure check for C11_FLAGS or something similar.

[Bug analyzer/103533] Enable "taint" state machine with -fanalyzer without requiring -fanalyzer-checker=taint

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

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

--- Comment #10 from GCC Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:83b210d55b28461e7604068c5df95a24b21e7081

commit r14-6056-g83b210d55b28461e7604068c5df95a24b21e7081
Author: David Malcolm 
Date:   Fri Dec 1 08:47:41 2023 -0500

docs: remove stray reference to -fanalyzer-checker=taint [PR103533]

I missed this one in r14-5464-gcfaaa8b11b8429.

gcc/ChangeLog:
PR analyzer/103533
* doc/extend.texi: Remove stray reference to
-fanalyzer-checker=taint.

Signed-off-by: David Malcolm 

[Bug c++/112795] [C++>=14] ICE pragma GCC unroll (n) cxx_eval_constant_expression

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |11.5
 Ever confirmed|0   |1
   Last reconfirmed||2023-12-01

--- Comment #2 from Marek Polacek  ---
Started with r8-5544-g170a8bd604a4c9:

commit 170a8bd604a4c960b8a378d50f7cc6c66cbdaf5c
Author: Eric Botcazou 
Date:   Fri Dec 22 10:22:15 2017 +

extend.texi (Loop-Specific Pragmas): Document pragma GCC unroll.

[Bug libstdc++/112802] : _ToClosure::operator() has no constraints

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

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

--- Comment #1 from Jonathan Wakely  ---
Patrick has a pending patch to improve those adaptors.

[Bug libstdc++/112808] Consider enabling _GLIBCXX_ASSERTIONS checks by default for debug builds

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Yes I've been considering making them opt out for a while (maybe even in
optimized builds).


The libstdc++ config can use #ifndef __OPTIMIZE__ to detect when building
without optimization.

[Bug analyzer/112811] New: ICE in -fanalyzer in has_null_terminator

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

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

Bug ID: 112811
   Summary: ICE in -fanalyzer in has_null_terminator
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
Blocks: 106358
  Target Milestone: ---

-fanalyzer with trunk ICEs on:

struct foo_laptop_debug {
  struct dentry *root;
  unsigned long size;
};
struct foo_laptop {
  void *placeholder;
  struct foo_laptop_debug debug;
  char sdiag[64];
};

extern struct dentry *debugfs_create_dir(void);

void foo_debugfs_init(struct foo_laptop *foo) {
  struct dentry *root;
  root = debugfs_create_dir();
  foo->debug.root = root;
  foo->debug.size = __builtin_strlen(foo->sdiag);
}

during IPA pass: analyzer
t.c: In function ‘foo_debugfs_init’:
t.c:17:21: internal compiler error: in has_null_terminator, at
analyzer/region-model.cc:3523
   17 |   foo->debug.size = __builtin_strlen(foo->sdiag);
  | ^~~~
0x1495415
ana::fragment::has_null_terminator(generic_wide_int
>, generic_wide_int >*) const
../../src/gcc/analyzer/region-model.cc:3523
0x1495322
ana::fragment::has_null_terminator(generic_wide_int
>, generic_wide_int >*) const
../../src/gcc/analyzer/region-model.cc:3602
0x1484e6c ana::region_model::scan_for_null_terminator(ana::region const*,
tree_node*, ana::svalue const**, ana::region_model_context*) const
../../src/gcc/analyzer/region-model.cc:3833
0x1485695
ana::region_model::check_for_null_terminated_string_arg(ana::call_details
const&, unsigned int, bool, ana::svalue const**) const
../../src/gcc/analyzer/region-model.cc:4054
0x146703b ana::kf_strlen::impl_call_pre(ana::call_details const&) const
../../src/gcc/analyzer/kf.cc:1392
0x1481c4c ana::region_model::on_call_pre(gcall const*,
ana::region_model_context*)
../../src/gcc/analyzer/region-model.cc:1651
0x1486b9a ana::region_model::on_stmt_pre(gimple const*, bool*,
ana::region_model_context*)
../../src/gcc/analyzer/region-model.cc:1300
0x144ceb5 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*, ana::uncertainty_t*, bool*, \
ana::path_context*)
../../src/gcc/analyzer/engine.cc:1507
0x144f680 ana::exploded_graph::process_node(ana::exploded_node*)
../../src/gcc/analyzer/engine.cc:4123
0x145035a ana::exploded_graph::process_worklist()
../../src/gcc/analyzer/engine.cc:3512
0x1452330 ana::impl_run_checkers(ana::logger*)
../../src/gcc/analyzer/engine.cc:6206
0x14532c6 ana::run_checkers()
../../src/gcc/analyzer/engine.cc:6297
0x14445ec execute
../../src/gcc/analyzer/analyzer-pass.cc:87
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.

Trunk (for gcc 14): https://godbolt.org/z/Pc5heGh7e
Doesn't affect gcc 13

(reduced from ICE on linux kernel: 'samsung_debugfs_init' at
drivers/platform/x86/samsung-laptop.c:1292:38)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358
[Bug 106358] [meta-bug] tracker bug for building the Linux kernel with
-fanalyzer

[Bug c++/112795] [C++>=14] ICE pragma GCC unroll (n) cxx_eval_constant_expression

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
The bug is in calling
  expr = maybe_constant_value (expr);
That is something that shouldn't be done in code possibly parsed in templates,
unless !processing_template_decl.
A quick fix would be to use
  expr = fold_non_dependent_expr (expr);
and I guess I'll just submit a patch with that.
That is e.g. what we do in OpenMP collapse clause parsing where we really want
a constant already during parsing because how we parse the following code
depends on that.
If that is not the case in #pragma GCC unroll, the normal C++ way would be to
only
check if the result is INTEGER_CST etc. if it is not value dependent expr,
otherwise
pass down a tree and during instantiation instantiate that tree.
That way
template 
void
foo ()
{
#pragma GCC unroll(N)
  for (int i = 0; i != N; ++i)
;
}
would be possible.

[Bug middle-end/112697] [14 Regression] 30-40% exec time regression of 433.milc on zen2 since r14-4972-g8aa47713701b1f

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

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

--- Comment #8 from Alexander Monakov  ---
Thanks, I can reproduce it. It is pretty tricky though. For instance, just
swapping the mov and the compare is enough to make it fast:

--- d.out.ltrans0.ltrans.slow.s 2023-12-01 18:32:54.255841611 +0300
+++ d.out.ltrans0.ltrans.fast.s 2023-12-01 18:32:20.318668991 +0300
@@ -743,8 +743,8 @@ add_force_to_mom:
.p2align 4,,10
.p2align 3
 .L58:
-   cmpb$1, -680(%r11,%r12)
movapd  %xmm5, %xmm7
+   cmpb$1, -680(%r11,%r12)
jne .L54
xorpd   %xmm6, %xmm7
 .L54:

[Bug c++/112795] [C++>=14] ICE pragma GCC unroll (n) cxx_eval_constant_expression

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

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 56754
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56754&action=edit
gcc14-pr112795.patch

Untested full fix.  If we backport at all, I think we could just change the
maybe_const_value to fold_non_dependent_expr.

[Bug middle-end/112697] [14 Regression] 30-40% exec time regression of 433.milc on zen2 since r14-4972-g8aa47713701b1f

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

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

--- Comment #9 from Alexander Monakov  ---
... as does inserting a nop before the compare ¯\_(ツ)_/¯


--- d.out.ltrans0.ltrans.slow.s 2023-12-01 18:32:54.255841611 +0300
+++ d.out.ltrans0.ltrans.s  2023-12-01 18:53:04.909438690 +0300
@@ -743,6 +743,7 @@ add_force_to_mom:
.p2align 4,,10
.p2align 3
 .L58:
+   nop
cmpb$1, -680(%r11,%r12)
movapd  %xmm5, %xmm7
jne .L54

[Bug target/112445] [14 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1861 unable to find a register to spill: {*umulditi3_1} with -O -march=cascadelake -fwrapv since r14-4968-g89e5d90

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Vladimir Makarov :

https://gcc.gnu.org/g:1390bf52c17a71834a1766c0222e4f8a74efb162

commit r14-6060-g1390bf52c17a71834a1766c0222e4f8a74efb162
Author: Vladimir N. Makarov 
Date:   Fri Dec 1 11:46:37 2023 -0500

[PR112445][LRA]: Fix "unable to find a register to spill" error

PR112445 is a very complicated bug occurring from interaction of
constraint subpass, inheritance, and hard reg live range splitting.
It is hard to debug this PR only from LRA standard logs.  Therefore I
added dumping all func insns at the end of complicated sub-passes
(constraint, inheritance, undoing inheritance, hard reg live range
splitting, and rematerialization).  As such output can be quite big,
it is switched only one level 7 of -fira-verbose value.  The reason
for the bug is a skip of live-range splitting of hard reg (dx) on the
1st live range splitting subpass.  Splitting is done for reload
pseudos around an original insn and its reload insns but the subpass
did not recognize such insn pattern because previous inheritance and
undoing inheritance subpasses extended a bit reload pseudo live range.
Although we undid inheritance in question, the result code was a bit
different from a code before the corresponding inheritance pass.  The
following fixes the bug by restoring exact code before the
inheritance.

gcc/ChangeLog:

PR target/112445
* lra.h (lra): Add one more arg.
* lra-int.h (lra_verbose, lra_dump_insns): New externals.
(lra_dump_insns_if_possible): Ditto.
* lra.cc (lra_dump_insns): Dump all insns.
(lra_dump_insns_if_possible):  Dump all insns for lra_verbose >= 7.
(lra_verbose): New global.
(lra): Add new arg.  Setup lra_verbose from its value.
* lra-assigns.cc (lra_split_hard_reg_for): Dump insns if rtl
was changed.
* lra-remat.cc (lra_remat): Dump insns if rtl was changed.
* lra-constraints.cc (lra_inheritance): Dump insns.
(lra_constraints, lra_undo_inheritance): Dump insns if rtl
was changed.
(remove_inheritance_pseudos): Use restore reg if it is set up.
* ira.cc: (lra): Pass internal_flag_ira_verbose.

gcc/testsuite/ChangeLog:

PR target/112445
* gcc.target/i386/pr112445.c: New test.

[Bug tree-optimization/112807] ICE: SIGSEGV in contains_struct_check (tree.h:3747) with _BitInt() at -O1 and above

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

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

--- Comment #1 from Jakub Jelinek  ---
Ah, the problem is that lower_addsub_overflow was written for lowering of
large/huge _BitInt operations, so for .{ADD,SUB}_OVERFLOW where one of the 2
operands is in the x86_64 case at least 129 bit or the result is a complex type
with 129+ bit element type.
That is the case here, because the first operand is _BitInt(256), but as result
is just 32-bit and VRP tells us the first argument is in [0, 0x] range
which needs 32-bits unsigned and the second argument is in [-2, 1] range, we
don't actually cast the second argument to a large/huge _BitInt type and so it
fails miserably.
Now, we could fix that either by tweaking the
  tree type0 = TREE_TYPE (arg0);
  tree type1 = TREE_TYPE (arg1);
  if (TYPE_PRECISION (type0) < prec3)
{
  type0 = build_bitint_type (prec3, TYPE_UNSIGNED (type0));
  if (TREE_CODE (arg0) == INTEGER_CST)
arg0 = fold_convert (type0, arg0);
}
  if (TYPE_PRECISION (type1) < prec3)
{  
  type1 = build_bitint_type (prec3, TYPE_UNSIGNED (type1));
  if (TREE_CODE (arg1) == INTEGER_CST)
arg1 = fold_convert (type1, arg1);
}
such that if bitint_precision_kind (prec3) < bitint_prec_large we actually use
smallest possible bitint_prec_large, or during the preparation phase check if
.{ADD,SUB}_OVERFLOW with small/medium return and both operands with
range_for_prec absolute values also small/medium we actually turn it into a
small/medium .{ADD,SUB}_OVERFLOW and expand just the casts.

[Bug c++/112795] [C++>=14] ICE pragma GCC unroll (n) cxx_eval_constant_expression

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

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

--- Comment #5 from Eric Botcazou  ---
Thanks for looking into this, Jakub.  IIRC I didn't write this C++ support, it
was already there in Mike's original implementation.

[Bug c/112812] New: Regression: ASAN + stack-protector breaks alignment of stack variables

[tonyb at cybernetics dot com via Gcc-bugs]

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

Bug ID: 112812
   Summary: Regression: ASAN + stack-protector breaks alignment of
stack variables
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tonyb at cybernetics dot com
  Target Milestone: ---

Created attachment 56755
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56755&action=edit
Test case

The combination of -fsanitize=address and -fstack-protector-strong causes gcc
13 to misalign stack variables.  Attached is a test program that requests
64-byte alignment of a stack variable.  With -fsanitize=address and
-fstack-protector-strong, the address is aligned on a 32-byte boundary but not
a 64-byte boundary.  With other combinations of options the alignment is
correct.  Running on x86_64.

Compile options:
gcc -m64 -Wall -O2 -U_FORTIFY_SOURCE -fstack-protector-strong
-fsanitize=address -fno-omit-frame-pointer

Test fails with gcc version 13.2.1 20231201
Configured with: ../gcc/configure --host=x86_64-pc-linux-gnu
--enable-languages=c

I believe gcc 12 did not have this bug.  I noticed the problem when UBSan
complained about a misaligned pointer which led back to a stack variable after
upgrading from gcc 12.3 to gcc 13.2.

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

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Alexandre Oliva :

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

commit r14-6062-gb8edb812ff4934c609fdfafe2e1c7f932bc18305
Author: Alexandre Oliva 
Date:   Fri Dec 1 14:31:22 2023 -0300

hardcfr: make builtin_return tests more portable [PR112334]

Rework __builtin_return tests to explicitly call __builtin_apply and
use its return value rather than anything else.  Also require
untyped_assembly.  Avoid the noise out of exceptions escaping the
builtin-applied function, but add a test to cover their effects as
well.


for  gcc/testsuite/ChangeLog

PR target/112334
* c-c++-common/torture/harden-cfr-bret.c: Rework for stricter
untyped_return requirements.  Require untyped_assembly.
* c-c++-common/torture/harden-cfr-bret-except.c: New.
* c-c++-common/torture/harden-cfr-bret-always.c: Require
untyped_assembly.
* c-c++-common/torture/harden-cfr-bret-never.c: Likewise.
* c-c++-common/torture/harden-cfr-bret-noopt.c: Likewise.
* c-c++-common/torture/harden-cfr-bret-noret.c: Likewise.
* c-c++-common/torture/harden-cfr-bret-no-xthrow.c: Likewise.
* c-c++-common/torture/harden-cfr-bret-nothrow.c: Likewise.
* c-c++-common/torture/harden-cfr-bret-retcl.c: Likewise.

[Bug target/110027] Misaligned vector store on detect_stack_use_after_return

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||tonyb at cybernetics dot com

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

[Bug target/112812] Regression: ASAN + stack-protector breaks alignment of stack variables

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug middle-end/112510] [11/12/13/14 Regression]: ASAN code injection breaks alignment of stack variables

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug target/110027] Misaligned vector store on detect_stack_use_after_return

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||sadko4u at gmail dot com

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

[Bug fortran/112764] Associating entity does not have target attribute if selector has pointer attribute in associate block

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

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

--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to martin from comment #10)
> Thanks for the speedy fix! I just thought about a variation, which should
> now with the fix work as well (was not yet able to compile current dev
> branch, so cannot check myself):
> 
> 
> program assoc_ptr_in

This compiles now and prints:

 123

[Bug tree-optimization/112807] ICE: SIGSEGV in contains_struct_check (tree.h:3747) with _BitInt() at -O1 and above

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2023-12-01
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from Jakub Jelinek  ---
Created attachment 56756
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56756&action=edit
gcc14-pr112807.patch

Untested implementation of the first option.  The other could be done
incrementally later on if it proves to be a win (but this one doesn't seem that
bad either).

[Bug fortran/111880] [11/12/13/14] False positive warning of obsolescent COMMON block with Fortran submodule

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

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

--- Comment #9 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:17cbec6e8ea8817b6240837bb1f1bf74f1b9bdcd

commit r12-10022-g17cbec6e8ea8817b6240837bb1f1bf74f1b9bdcd
Author: Harald Anlauf 
Date:   Thu Nov 23 22:48:38 2023 +0100

Fortran: avoid obsolescence warning for COMMON with submodule [PR111880]

gcc/fortran/ChangeLog:

PR fortran/111880
* resolve.cc (resolve_common_vars): Do not call gfc_add_in_common
for symbols that are USE associated or used in a submodule.

gcc/testsuite/ChangeLog:

PR fortran/111880
* gfortran.dg/pr111880.f90: New test.

(cherry picked from commit c9d029ba2ceb435e31492c1f3f0fd3edf0e386be)

[Bug fortran/111880] [11/12/13/14] False positive warning of obsolescent COMMON block with Fortran submodule

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

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

--- Comment #10 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:246760b37f1239b3b97c20fb4a914f21154389a3

commit r11-9-g246760b37f1239b3b97c20fb4a914f21154389a3
Author: Harald Anlauf 
Date:   Thu Nov 23 22:48:38 2023 +0100

Fortran: avoid obsolescence warning for COMMON with submodule [PR111880]

gcc/fortran/ChangeLog:

PR fortran/111880
* resolve.c (resolve_common_vars): Do not call gfc_add_in_common
for symbols that are USE associated or used in a submodule.

gcc/testsuite/ChangeLog:

PR fortran/111880
* gfortran.dg/pr111880.f90: New test.

(cherry picked from commit c9d029ba2ceb435e31492c1f3f0fd3edf0e386be)

[Bug fortran/111880] [11/12/13/14] False positive warning of obsolescent COMMON block with Fortran submodule

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #11 from anlauf at gcc dot gnu.org ---
Fixed on all open branches.  Closing.

[Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #2 from Andrew Macleod  ---
(In reply to Kewen Lin from comment #1)

> 
> ranger makes use of type precision directly instead of something like
> types_compatible_p. I wonder if we can introduce a target hook (or hookpod)
> to make ranger unrestrict this check a bit, the justification is that for
> float type its precision information is encoded in its underlying
> real_format, if two float types underlying modes are the same, the precision
> are actually the same. 
> 
> btw, the operand_check_ps seems able to call range_compatible_p?

It could, but just a precision check seemed enough at the time.
The patch also went thru many iterations and it was only the final version that
operand_check_p() ended up with types as the parameter rather than ranges.

You bring up a good point tho. I just switched those routines to call
range_compatible_p() and checked it in.  Now it is all centralized in the one
routine going forward. 

It does seem wrong that the float precision don't match, and weird that its
hard to fix :-)   It should now be possible to have range_compatible_p check
the underlying mode for floats rather than the precision...  If there's a good
argument for it, and you want to give that a shot...

[Bug target/112813] New: [14 Regression] RISCV ICE: vsetvl pass: in merge at config/riscv/riscv-vsetvl.cc:1968 on rv32gcv_zvl256b

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 112813
   Summary: [14 Regression] RISCV ICE: vsetvl pass: in merge at
config/riscv/riscv-vsetvl.cc:1968 on rv32gcv_zvl256b
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Created attachment 56757
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56757&action=edit
-freport-bug output

> /scratch/tc-testing/tc-nov-30-trunk/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -march=rv32gcv_zvl256b -mabi=ilp32d -O3 red.c -S -freport-bug
during RTL pass: vsetvl
red.c: In function 'k':
red.c:21:1: internal compiler error: in merge, at
config/riscv/riscv-vsetvl.cc:1968
   21 | }
  | ^
0xac3d86 demand_system::merge(vsetvl_info&, vsetvl_info const&)
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:1968
0xac3d86 pre_vsetvl::earliest_fuse_vsetvl_info()
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:2992
0x1733d79 pass_vsetvl::lazy_vsetvl()
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:3472
0x17340df pass_vsetvl::execute(function*)
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:3519
0x17340df pass_vsetvl::execute(function*)
../../../gcc/gcc/config/riscv/riscv-vsetvl.cc:3502
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /scratch/tmp/ccoSwl1N.out file, please attach
this to your bugreport.

creduced testcase:
int a, c, d, f, j;
int b[7];
long e;
char *g;
int *h;
long long *i;
void k() {
  int l[][1] = {{}, {1}, {1}};
  int *m = &d, *n = &l[0][0];
  for (; e;) {
f = 3;
for (; f >= 0; f--) {
  *m &= b[f] >= 0;
  j = a >= 2 ? 0 : 1 >> a;
  *i |= j;
}
for (; c;)
  *g = 0;
  }
  h = n;
}

I've attached the -freport-bug output.

Compiler explorer: https://godbolt.org/z/G49a3P8Ef

[Bug tree-optimization/112814] New: `Plus , PHI>` is not optimized to just PLUS

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

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

Bug ID: 112814
   Summary: `Plus , PHI>` is not optimized to just
PLUS
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
int f(int a, int b, int c)
{
int d, e;
if (c) d = a, e = b;
else   d = b, e = a;
return d+e;
}
```
This should just be optimized to `return a+b` but it is currently not.

[Bug tree-optimization/112814] `Plus , PHI>` is not optimized to just PLUS

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Similarly:
```
int f(int a, int b, int c)
{
int d, e;
return (c ? a : b) + (c ? b : a);
}
```


Note the above could be done using a match pattern. catching it before
gimplification.

[Bug tree-optimization/112814] `Plus , PHI>` is not optimized to just PLUS

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug fortran/112772] Some issues with OPTIONAL, ALLOCATABLE dummy arguments

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

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Created attachment 56758
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56758&action=edit
Patch for testcase 2

This patch makes the initialization code seen in testcase 2
dependent on the presence of the optional argument.

Needs testing.

[Bug c++/112815] New: ICE: in vague_linkage_p, at cp/decl2.cc:2329 with -flto -fno-weak

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 112815
   Summary: ICE: in vague_linkage_p, at cp/decl2.cc:2329 with
-flto -fno-weak
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 56759
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56759&action=edit
reduced testcase

This crashes at the same place as PR107990, but with a different backtrace. It
has common -fno-weak flag.

The original testcase didn't output the warning: 'T::T()::U::U()' used but
never defined

Compiler output:
$ x86_64-pc-linux-gnu-gcc -flto -fno-weak testcase.C
testcase.C:7:7: warning: 'T::T()::U::U()' used but never defined
7 |   U ();
  |   ^
during IPA pass: *free_lang_data
testcase.C:5:12: internal compiler error: in vague_linkage_p, at
cp/decl2.cc:2329
5 | struct U
  |^
0x74d356 vague_linkage_p(tree_node*)
/repo/gcc-trunk/gcc/cp/decl2.cc:2329
0x11394bf no_linkage_check(tree_node*, bool)
/repo/gcc-trunk/gcc/cp/tree.cc:3022
0xfd1cf3 mangle_decl(tree_node*)
/repo/gcc-trunk/gcc/cp/mangle.cc:4146
0x1ad0a8d decl_assembler_name(tree_node*)
/repo/gcc-trunk/gcc/tree.cc:719
0x1af7747 assign_assembler_name_if_needed(tree_node*)
/repo/gcc-trunk/gcc/tree.cc:834
0x2916760 free_lang_data_in_cgraph
/repo/gcc-trunk/gcc/ipa-free-lang-data.cc:1064
0x2916760 free_lang_data
/repo/gcc-trunk/gcc/ipa-free-lang-data.cc:1109
0x2916760 execute
/repo/gcc-trunk/gcc/ipa-free-lang-data.cc:1176
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.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-6051-20231201105652-gb1fe98dee21-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-6051-20231201105652-gb1fe98dee21-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231201 (experimental) (GCC)

[Bug middle-end/112816] New: internal compiler error: in extract_insn, at recog.cc:2804, unrecognizable_insn for __builtin_signbit

[a.elovikov at gmail dot com via Gcc-bugs]

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

Bug ID: 112816
   Summary: internal compiler error: in extract_insn, at
recog.cc:2804, unrecognizable_insn for
__builtin_signbit
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a.elovikov at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/3vzejjWcq

constexpr int N = 4;

template 
struct S {
T x[N];
T& operator[](int idx) { return x[idx]; }
};
auto foo(S x) {
  S res;
  for (int i = 0; i < 4; ++i)
res[i] = __builtin_signbit(x[i]) ? -1 : 0;
  return res;
}

Copy-pasting "x86-64 gcc (trunk)" output from the godbolt link above (-O3
-std=c++17 options used):
: In function 'auto foo(S)':
:13:1: error: unrecognizable insn:
   13 | }
  | ^
(insn 20 19 21 2 (set (reg:V4SI 99 [ vect__2.11 ])
(lshiftrt:V4SI (subreg:V4SI (subreg:V4SF (reg/v:TI 105 [ x ]) 0) 0)
(const_int 31 [0x1f]))) "":11:31 discrim 1 -1
 (nil))
during RTL pass: vregs
:13:1: internal compiler error: in extract_insn, at recog.cc:2804
0x26c14fe internal_error(char const*, ...)
???:0
0xb125b9 fancy_abort(char const*, int, char const*)
???:0
0x925e6a _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
???:0
0x925e8c _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
???: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

Also reproducible with (the version I discovered it with)

$ g++ --version
g++ (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Copyright (C) 2021 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.

[Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b

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

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

--- Comment #13 from Robin Dapp  ---
Mostly an issue because our expander is definitely not prepared to handle that
:)

It looks like aarch64's is, though, and ours can/should be changed then.
aarch64 doesn't need to implement a qi/bi extract from a mask because the
bit_field_ref fallback code works for sve masks.

There is (at least) three things that prevent us from creating a vec_extract
here.  First, my old friend MODE_BITSIZE vs MODE_PRECISION, second we expect a
mask -> BI extract here (while we do mask -> QI extraction on the other path)
but I haven't yet defined a vec_extract...bi either.
Once those two are our of the way I still hit QI vs BI inconsistencies but I
think they can be sorted out.  Then we emit a VLA vec_extract.

I hope to have a patch ready by Monday.

[Bug target/112816] [11/12/13/14 Regression] internal compiler error: in extract_insn, at recog.cc:2804, unrecognizable_insn for __builtin_signbit

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|internal compiler error: in |[11/12/13/14 Regression]
   |extract_insn, at|internal compiler error: in
   |recog.cc:2804,  |extract_insn, at
   |unrecognizable_insn for |recog.cc:2804,
   |__builtin_signbit   |unrecognizable_insn for
   ||__builtin_signbit
   Target Milestone|--- |11.5

[Bug target/112816] [11/12/13/14 Regression] internal compiler error: in extract_insn, at recog.cc:2804, unrecognizable_insn for __builtin_signbit

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 56760
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56760&action=edit
C testcase

[Bug target/112816] [11/12/13/14 Regression] ICE unrecognizable_insn with __builtin_signbit and returning struct with int[4]

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-12-01
Summary|[11/12/13/14 Regression]|[11/12/13/14 Regression]
   |internal compiler error: in |ICE unrecognizable_insn
   |extract_insn, at|with __builtin_signbit and
   |recog.cc:2804,  |returning struct with
   |unrecognizable_insn for |int[4]
   |__builtin_signbit   |
 Ever confirmed|0   |1

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

[Bug fortran/112772] Some issues with OPTIONAL, ALLOCATABLE dummy arguments

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:7317275497e10c4a0fb3fbaa6ca87f3463ac124d

commit r14-6066-g7317275497e10c4a0fb3fbaa6ca87f3463ac124d
Author: Harald Anlauf 
Date:   Thu Nov 30 21:53:21 2023 +0100

Fortran: copy-out for possibly missing OPTIONAL CLASS arguments [PR112772]

gcc/fortran/ChangeLog:

PR fortran/112772
* trans-expr.cc (gfc_conv_class_to_class): Make copy-out
conditional
on the presence of an OPTIONAL CLASS argument passed to an OPTIONAL
CLASS dummy.

gcc/testsuite/ChangeLog:

PR fortran/112772
* gfortran.dg/missing_optional_dummy_7.f90: New test.

[Bug target/112817] New: RISC-V: RVV: provide a preprocessor macro for VLS codegen

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

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

Bug ID: 112817
   Summary: RISC-V: RVV: provide a preprocessor macro for VLS
codegen
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vineetg at gcc dot gnu.org
CC: ewlu at rivosinc dot com, juzhe.zhong at rivai dot ai,
rdapp at gcc dot gnu.org
  Target Milestone: ---

LLVM toggle for setting up fixed vector length using -mrvv-vector-bits=zvl
(which in turn derives VL from -march=...-vl256) also generates a preprocessor
define __riscv_v_fixed_vlen.

gcc doesn't, which is a bit of pain for downstream projects such as xsimd.

Granted the C-API document [1] doesn't specify this, generation by llvm and
more importantly usage in downstream projects seems good enough of a
requirement to have it in gcc as well.

[1] https://github.com/riscv-non-isa/riscv-c-api-doc/blob/master/riscv-c-api.md