[Bug analyzer/114791] analyzer: file-leak not detected

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

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

--- Comment #4 from Andrew Pinski  ---
Interesting, with -O0, there is a warning but that can be turned into a false
positive if you enable the "missing:" section.

[Bug analyzer/114791] analyzer: file-leak not detected

[urs at akk dot org via Gcc-bugs]

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

--- Comment #3 from Urs Janßen  ---
Comment on attachment 57998
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57998
minimal test case

>#include 
>#include 
>#include 
>#include 
>
>int main(void);
>
>int main(void) {
>FILE *fp = (FILE *) 0;
>int i = 0;
>static const char *list[] = { "/tmp/", "/tmp/a", "/tmp/b", NULL };
>struct stat st;
>
>while (list[i] != NULL) {
>if ((fp = fopen(list[i], "r")) != NULL) {

should be 
if ((fp = fopen(list[i++], "r")) != NULL) {

>if (fstat(fileno(fp), ) != -1) {
>if ((st.st_mode & (S_IFREG | S_IFLNK)) && st.st_size > 0L)
>break;
>}
>/* missing:
>fclose(fp);
>fp = NULL;
>here */
>}
>}
>
>if (fp)
>fclose(fp);
>}

[Bug analyzer/114791] analyzer: file-leak not detected

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
   Last reconfirmed||2024-04-21
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

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

[Bug analyzer/114791] analyzer: file-leak not detected

[urs at akk dot org via Gcc-bugs]

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

--- Comment #1 from Urs Janßen  ---
Created attachment 57999
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57999=edit
preprocessed example

[Bug analyzer/114791] New: analyzer: file-leak not detected

[urs at akk dot org via Gcc-bugs]

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

Bug ID: 114791
   Summary: analyzer: file-leak not detected
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: urs at akk dot org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

Created attachment 57998
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57998=edit
minimal test case

False negative -Wanalyzer-file-leak

gcc build from git @ ef2392236ec629351496d7f299d6a0956080e4d9

gcc-14 -D_DEFAULT_SOURCE -Wall -Wextra -fanalyzer -O2 -v -save-temps
-freport-bug -g -std=c11 -o fleak file-leak.c

doesn't give a warning but it should (value of fp may be overwritten before
released).

[Bug rtl-optimization/114768] Volatile reads can be optimized away

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

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

--- Comment #10 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

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

commit r13-8636-gab3b83afc149edda11fa3c7cbb3815606731003b
Author: Jakub Jelinek 
Date:   Fri Apr 19 08:47:53 2024 +0200

rtlanal: Fix set_noop_p for volatile loads or stores [PR114768]

On the following testcase, combine propagates the mem/v load into mem store
with the same address and then removes it, because noop_move_p says it is a
no-op move.  If it was the other way around, i.e. mem/v store and mem load,
or both would be mem/v, it would be kept.
The problem is that rtx_equal_p never checks any kind of flags on the rtxes
(and I think it would be quite dangerous to change it at this point), and
set_noop_p checks side_effects_p on just one of the operands, not both.
In the MEM <- MEM set, it only checks it on the destination, in
store to ZERO_EXTRACT only checks it on the source.

The following patch adds the missing side_effects_p checks.

2024-04-19  Jakub Jelinek  

PR rtl-optimization/114768
* rtlanal.cc (set_noop_p): Don't return true for MEM <- MEM
sets if src has side-effects or for stores into ZERO_EXTRACT
if ZERO_EXTRACT operand has side-effects.

* gcc.dg/pr114768.c: New test.

(cherry picked from commit 9f295847a9c32081bdd0fe908ffba58e830a24fb)

[Bug middle-end/114753] from_chars aborts with -m32 -ftrapv when passed -9223372036854775808

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

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

--- Comment #10 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:10f689596ad1633f4f5de1852c8f82a993fe948e

commit r13-8635-g10f689596ad1633f4f5de1852c8f82a993fe948e
Author: Jakub Jelinek 
Date:   Thu Apr 18 09:45:14 2024 +0200

internal-fn: Temporarily disable flag_trapv during .{ADD,SUB,MUL}_OVERFLOW
etc. expansion [PR114753]

__builtin_{add,sub,mul}_overflow{,_p} builtins are well defined
for all inputs even for -ftrapv, and the -fsanitize=signed-integer-overflow
ifns shouldn't abort in libgcc but emit the desired ubsan diagnostics
or abort depending on -fsanitize* setting regardless of -ftrapv.
The expansion of these internal functions uses expand_expr* in various
places (e.g. MULT_EXPR at least in 2 spots), so temporarily disabling
flag_trapv in all those spots would be hard.
The following patch disables it around the bodies of 3 functions
which can do the expand_expr calls.
If it was in the C++ FE, I'd use some RAII sentinel, but I don't think
we have one in the middle-end.

2024-04-18  Jakub Jelinek  

PR middle-end/114753
* internal-fn.cc (expand_mul_overflow): Save flag_trapv and
temporarily clear it for the duration of the function, then
restore previous value.
(expand_vector_ubsan_overflow): Likewise.
(expand_arith_overflow): Likewise.

* gcc.dg/pr114753.c: New test.

(cherry picked from commit 6c152c9db3b5b9d43e12846fb7a44977c0b65fc2)

[Bug middle-end/110027] [11/12/13 regression] Stack objects with extended alignments (vectors etc) misaligned on detect_stack_use_after_return

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

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

--- Comment #24 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

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

commit r13-8630-ga16d90ec302e588dab5d7d31ccdd7b3fd5c6214e
Author: Jakub Jelinek 
Date:   Thu Apr 11 11:12:11 2024 +0200

asan, v3: Fix up handling of > 32 byte aligned variables with
-fsanitize=address -fstack-protector* [PR110027]

On Tue, Mar 26, 2024 at 02:08:02PM +0800, liuhongt wrote:
> > > So, try to add some other variable with larger size and smaller
alignment
> > > to the frame (and make sure it isn't optimized away).
> > >
> > > alignb above is the alignment of the first partition's var, if
> > > align_frame_offset really needs to depend on the var alignment, it
probably
> > > should be the maximum alignment of all the vars with alignment
> > > alignb * BITS_PER_UNIT <=3D MAX_SUPPORTED_STACK_ALIGNMENT
> > >
>
> In asan_emit_stack_protection, when it allocated fake stack, it assume
> bottom of stack is also aligned to alignb. And the place violated this
> is the first var partition. which is 32 bytes offsets,  it should be
> BIGGEST_ALIGNMENT / BITS_PER_UNIT.
> So I think we need to use MAX (BIGGEST_ALIGNMENT /
> BITS_PER_UNIT, ASAN_RED_ZONE_SIZE) for the first var partition.

Your first patch aligned offsets[0] to maximum of alignb and
ASAN_RED_ZONE_SIZE.  But as I wrote in the reply to that mail, alignb there
is the alignment of just a single variable which is the first one to appear
in the sorted list and is placed in the highest spot in the stack frame.
That is not necessarily the largest alignment, the sorting ensures that it
is a variable with the largest size in the frame (and only if several of
them have equal size, largest alignment from the same sized ones).  Your
second patch used maximum of BIGGEST_ALIGNMENT / BITS_PER_UNIT and
ASAN_RED_ZONE_SIZE.  That doesn't change anything at all when using
-mno-avx512f - offsets[0] is still just 32-byte aligned in that case
relative to top of frame, just changes the -mavx512f case to be 64-byte
aligned offsets[0] (aka offsets[0] is then either 0 or -64 instead of
either
0 or -32).  That will not help if any variable in the frame needs 128-byte,
256-byte, 512-byte ...  4096-byte alignment.  If you want to fix the bug in
the spot you've touched, you'd need to walk all the
stack_vars[stack_vars_sorted[si2]] for si2 [si + 1, n - 1] and for those
where the loop would do anything (i.e.
stack_vars[i2].representative == i2
&& TREE_CODE (decl2) == SSA_NAME
   ? SA.partition_to_pseudo[var_to_partition (SA.map, decl2)] == NULL_RTX
   : DECL_RTL (decl2) == pc_rtx
and the pred applies (but that means also walking the earlier ones!
because with -fstack-protector* the vars can be processed in several calls)
and
alignb2 * BITS_PER_UNIT <= MAX_SUPPORTED_STACK_ALIGNMENT
and compute maximum of those alignments.
That maximum is already computed,
data->asan_alignb = MAX (data->asan_alignb, alignb);
computes that, but you get the final result only after you do all the
expand_stack_vars calls.  You'd need to compute it before.

Though, that change would be still in the wrong place.
The thing is, it would be a waste of the precious stack space when it isn't
needed at all (e.g.  when asan will not at compile time do the use after
return checking, or if it won't do it at runtime, or even if it will do at
runtime it will waste the space on the stack).

The following patch fixes it solely for the __asan_stack_malloc_N
allocations, doesn't enlarge unnecessarily further the actual stack frame.
Because asan is only supported on FRAME_GROWS_DOWNWARD architectures
(mips, rs6000 and xtensa are conditional FRAME_GROWS_DOWNWARD arches, which
for -fsanitize=address or -fstack-protector* use FRAME_GROWS_DOWNWARD 1,
otherwise 0, others supporting asan always just use 1), the assumption for
the dynamic stack realignment is that the top of the stack frame (aka
offset
0) is aligned to alignb passed to the function (which is the maximum of
alignb
of all the vars in the frame).  As checked by the assertion in the patch,
offsets[0] is 0 most of the time and so that assumption is correct, the
only
case when it is not 0 is if -fstack-protector* is on together with
-fsanitize=address and cfgexpand.cc (create_stack_guard) created a stack
guard.  That is the only variable which is allocated in the stack frame
right away, for all others with -fsanitize=address defer_stack_allocation
(or -fstack-protector*) returns true and so they aren't allocated
immediately but handled during the frame layout phases.  So, the original
frame_offset of 0 is changed because of the stack guard to
-pointer_size_in_bytes and later 

[Bug c++/114580] Bogus warning on if constexpr

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

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

commit r13-8629-gae3b6dea0445f9650cf1a684527efac06497f1b4
Author: Jakub Jelinek 
Date:   Tue Apr 9 09:31:42 2024 +0200

c++: Fix up maybe_warn_for_constant_evaluated calls [PR114580]

When looking at maybe_warn_for_constant_evaluated for the trivial
infinite loops patch, I've noticed that it can emit weird diagnostics
for if constexpr in templates, first warn that std::is_constant_evaluted()
always evaluates to false (because the function template is not constexpr)
and then during instantiation warn that std::is_constant_evaluted()
always evaluates to true (because it is used in if constexpr condition).
Now, only the latter is actually true, even when the if constexpr
is in a non-constexpr function, it will still always evaluate to true.

So, the following patch fixes it to call maybe_warn_for_constant_evaluated
always with IF_STMT_CONSTEXPR_P (if_stmt) as the second argument rather
than
true if it is if constexpr with non-dependent condition etc.

2024-04-09  Jakub Jelinek  

PR c++/114580
* semantics.cc (finish_if_stmt_cond): Call
maybe_warn_for_constant_evaluated with IF_STMT_CONSTEXPR_P
(if_stmt)
as the second argument, rather than true/false depending on if
it is if constexpr with non-dependent constant expression with
bool type.

* g++.dg/cpp2a/is-constant-evaluated15.C: New test.

(cherry picked from commit cfed80b9e4f562c99679739548df9369117dd791)

[Bug tree-optimization/114566] [11/12/13 Regression] Misaligned vmovaps when compiling with stack-protector-strong for znver4

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

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

--- Comment #18 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:38af0d59043da4cc07cd62c17da599e43668e3be

commit r13-8628-g38af0d59043da4cc07cd62c17da599e43668e3be
Author: Jakub Jelinek 
Date:   Fri Apr 5 14:56:14 2024 +0200

vect: Don't clear base_misaligned in update_epilogue_loop_vinfo [PR114566]

The following testcase is miscompiled, because in the vectorized
epilogue the vectorizer assumes it can use aligned loads/stores
(if the base decl gets alignment increased), but it actually doesn't
increase that.
This is because r10-4203-g97c1460367 added the hunk following
patch removes.  The explanation feels reasonable, but actually it
is not true as the testcase proves.
The thing is, we vectorize the main loop with 64-byte vectors
and the corresponding data refs have base_alignment 16 (the
a array has DECL_ALIGN 128) and offset_alignment 32.  Now, because
of the offset_alignment 32 rather than 64, we need to use unaligned
loads/stores in the main loop (and ditto in the first load/store
in vectorized epilogue).  But the second load/store in the vectorized
epilogue uses only 32-byte vectors and because it is a multiple
of offset_alignment, it checks if we could increase alignment of the
a VAR_DECL, the function returns true, sets base_misaligned = true
and says the access is then aligned.
But when update_epilogue_loop_vinfo clears base_misaligned with the
assumption that the var had to have the alignment increased already,
the update of DECL_ALIGN doesn't happen anymore.

Now, I'd think this base_alignment = false was needed before
r10-4030-gd2db7f7901 change was committed where it incorrectly
overwrote DECL_ALIGN even if it was already larger, rather than
just always increasing it.  But with that change in, it doesn't
make sense to me anymore.

Note, the testcase is latent on the trunk, but reproduces on the 13
branch.

2024-04-05  Jakub Jelinek  

PR tree-optimization/114566
* tree-vect-loop.cc (update_epilogue_loop_vinfo): Don't clear
base_misaligned.

* gcc.target/i386/avx512f-pr114566.c: New test.

(cherry picked from commit a844095e17c1a5aada1364c6f6eaade87ead463c)

[Bug c++/114691] [11/12/13 Regression] Bogus ignoring loop annotation warning

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

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

commit r13-8632-ged7be7ba6f125cfda7ad07263213cbe02b7e7ced
Author: Jakub Jelinek 
Date:   Fri Apr 12 20:53:10 2024 +0200

c++: Fix bogus warnings about ignored annotations [PR114691]

The middle-end warns about the ANNOTATE_EXPR added for while/for loops
if they declare a var inside of the loop condition.
This is because the assumption is that ANNOTATE_EXPR argument is used
immediately in a COND_EXPR (later GIMPLE_COND), but simplify_loop_decl_cond
wraps the ANNOTATE_EXPR inside of a TRUTH_NOT_EXPR, so it no longer
holds.

The following patch fixes that by adding the TRUTH_NOT_EXPR inside of the
ANNOTATE_EXPR argument if any.

2024-04-12  Jakub Jelinek  

PR c++/114691
* semantics.cc (simplify_loop_decl_cond): Use cp_build_unary_op
with
TRUTH_NOT_EXPR on ANNOTATE_EXPR argument (if any) rather than
ANNOTATE_EXPR itself.

* g++.dg/ext/pr114691.C: New test.

(cherry picked from commit 91146346f57cc54dfeb2669347edd0eb3d13af7f)

[Bug c/114780] Using C23 nullptr as sentinel gives missing sentinel warning

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

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

commit r13-8637-ge802786436851b1f5efca21a14d4f41c83c83f4f
Author: Jakub Jelinek 
Date:   Sat Apr 20 00:12:36 2024 +0200

c-family: Allow arguments with NULLPTR_TYPE as sentinels [PR114780]

While in C++ the ellipsis argument conversions include
"An argument that has type cv std::nullptr_t is converted to type void*"
in C23 a nullptr_t argument is not promoted in any way, but va_arg
description says:
"the type of the next argument is nullptr_t and type is a pointer type that
has the same
representation and alignment requirements as a pointer to a character
type."
So, while in C++ check_function_sentinel will never see NULLPTR_TYPE, for
C23 it can see that and currently we incorrectly warn about those.

The only question is whether we should warn on any argument with
nullptr_t type or just about nullptr (nullptr_t argument with integer_zerop
value).  Through undefined behavior guess one could pass non-NULL pointer
that way, say by union { void *p; nullptr_t q; } u; u.p = 
and pass u.q to ..., but valid code should always pass something that will
read as (char *) 0 when read using va_arg (ap, char *), so I think it is
better not to warn rather than warn in those cases.

Note, clang seems to pass (void *)0 rather than expression of nullptr_t
type to ellipsis in C23 mode as if it did the C++ ellipsis argument
conversions, in that case guess not warning about that would be even safer,
but what GCC does I think follows the spec more closely, even when in a
valid program one shouldn't be able to observe the difference.

2024-04-20  Jakub Jelinek  

PR c/114780
* c-common.cc (check_function_sentinel): Allow as sentinel any
argument of NULLPTR_TYPE.

* gcc.dg/format/sentinel-2.c: New test.

(cherry picked from commit 2afdecccbaf5c5b1c7a235509b37092540906c02)

[Bug c++/114572] [OpenMP] "internal compiler error: in assign_temp" with assignment operator and lastprivate clause

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:910fa4d9df8f72d16279324cca2bf1f2649aa68b

commit r13-8627-g910fa4d9df8f72d16279324cca2bf1f2649aa68b
Author: Jakub Jelinek 
Date:   Fri Apr 5 09:31:28 2024 +0200

c++: Fix ICE with weird copy assignment operator [PR114572]

While ctors/dtors don't return anything (undeclared void or this pointer
on arm) and copy assignment operators normally return a reference to *this,
it isn't invalid to return uselessly some class object which might need
destructing, but the OpenMP clause handling code wasn't expecting that.

The following patch fixes that.

2024-04-05  Jakub Jelinek  

PR c++/114572
* cp-gimplify.cc (cxx_omp_clause_apply_fn): Call build_cplus_new
on build_call_a result if it has class type.

* testsuite/libgomp.c++/pr114572.C: New test.

(cherry picked from commit 592536eb3c0a97a55b1019ff0216ef77e6ca847e)

[Bug sanitizer/114687] [13 Regression] ICE: in edge_before_returns_twice_call, at gimple-iterator.cc:981

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

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:7a1a52934a2ab9ac9205a3a4d5b82a672fefba7e

commit r13-8631-g7a1a52934a2ab9ac9205a3a4d5b82a672fefba7e
Author: Jakub Jelinek 
Date:   Fri Apr 12 10:59:54 2024 +0200

Limit special asan/ubsan/bitint returns_twice handling to calls in bbs with
abnormal pred [PR114687]

The tree-cfg.cc verifier only diagnoses returns_twice calls preceded
by non-label/debug stmts if it is in a bb with abnormal predecessor.
The following testcase shows that if a user lies in the attributes
(a function which never returns can't be pure, and can't return
twice when it doesn't ever return at all), when we figure it out,
we can remove the abnormal edges to the "returns_twice" call and perhaps
whole .ABNORMAL_DISPATCHER etc.
edge_before_returns_twice_call then ICEs because it can't find such
an edge.

The following patch limits the special handling to calls in bbs where
the verifier requires that.

2024-04-12  Jakub Jelinek  

PR sanitizer/114687
* gimple-iterator.cc (gsi_safe_insert_before): Only use
edge_before_returns_twice_call if bb_has_abnormal_pred.
(gsi_safe_insert_seq_before): Likewise.

* gcc.dg/asan/pr114687.c: New test.

(cherry picked from commit c9e94ae448ba309dba74de3ee1974a3ed9248889)

[Bug sanitizer/114743] ICE in build_check_stmt at asan.cc:2707 while compiling gcc.dg/ubsan/pr112709-2.c with -fsanitize=address

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

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

--- Comment #4 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

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

commit r13-8634-gcd8e2137462d9ae1723fa193b6062ec65d164457
Author: Jakub Jelinek 
Date:   Wed Apr 17 10:24:18 2024 +0200

asan: Don't instrument .ABNORMAL_DISPATCHER [PR114743]

.ABNORMAL_DISPATCHER is currently the only internal function with
ECF_NORETURN, and asan likes to instrument ECF_NORETURN calls by adding
some builtin call before them, which breaks the .ABNORMAL_DISPATCHER
discovery added in gsi_safe_*.

The following patch fixes asan not to instrument .ABNORMAL_DISPATCHER
calls, like it doesn't instrument a couple of specific builtin calls
as well.

2024-04-17  Jakub Jelinek  

PR sanitizer/114743
* asan.cc (maybe_instrument_call): Don't instrument calls to
.ABNORMAL_DISPATCHER.

* gcc.dg/asan/pr112709-2.c (freddy): New function from
gcc.dg/ubsan/pr112709-2.c version of the test.

(cherry picked from commit 299d14a54672a4d12c1abbe4031a732bb56cddaa)

[Bug c++/114634] [11/12/13 Regression] Crash Issue Encountered in GCC Compilation of Template Code with Aligned Attribute since r9-1745

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

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:2c85e8def0efd4b0d9d312a1f0cbbee332b4e0d1

commit r13-8633-g2c85e8def0efd4b0d9d312a1f0cbbee332b4e0d1
Author: Jakub Jelinek 
Date:   Mon Apr 15 10:25:22 2024 +0200

attribs: Don't crash on NULL TREE_TYPE in diag_attr_exclusions [PR114634]

The enumerator still doesn't have TREE_TYPE set but diag_attr_exclusions
assumes that all decls must have types.
I think it is better in something as unimportant as diag_attr_exclusions
to be more robust, if there is no type, it can just diagnose exclusions
on the DECL_ATTRIBUTES, like for types it only diagnoses it on
TYPE_ATTRIBUTES.

2024-04-15  Jakub Jelinek  

PR c++/114634
* attribs.cc (diag_attr_exclusions): Set attrs[1] to NULL_TREE for
decls with NULL TREE_TYPE.

* g++.dg/ext/attrib68.C: New test.

(cherry picked from commit 7ec54f5fdfec298812a749699874db4d6a7246bb)

[Bug c++/114537] bit_cast does not work NSDMI of bitfields

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

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

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

commit r13-8626-ga297f9bbb9611414fe48f6d61a8829bf5808bd2c
Author: Jakub Jelinek 
Date:   Thu Apr 4 10:47:52 2024 +0200

fold-const: Handle NON_LVALUE_EXPR in native_encode_initializer [PR114537]

The following testcase is incorrectly rejected.  The problem is that
for bit-fields native_encode_initializer expects the corresponding
CONSTRUCTOR elt value must be INTEGER_CST, but that isn't the case
here, it is wrapped into NON_LVALUE_EXPR by maybe_wrap_with_location.
We could STRIP_ANY_LOCATION_WRAPPER as well, but as all we are looking for
is INTEGER_CST inside, just looking through NON_LVALUE_EXPR seems easier.

2024-04-04  Jakub Jelinek  

PR c++/114537
* fold-const.cc (native_encode_initializer): Look through
NON_LVALUE_EXPR if val is INTEGER_CST.

* g++.dg/cpp2a/bit-cast16.C: New test.

(cherry picked from commit 1baec8deb014b8a7da58879a407a4c00cdeb5a09)

[Bug middle-end/114552] [13 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r13-990

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

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

--- Comment #9 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

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

commit r13-8624-gba6fd407891fd83648ad803c85b607dc09e23be4
Author: Jakub Jelinek 
Date:   Wed Apr 3 09:59:45 2024 +0200

expr: Fix up emit_push_insn [PR114552]

r13-990 added optimizations in multiple spots to optimize during
expansion storing of constant initializers into targets.
In the load_register_parameters and expand_expr_real_1 cases,
it checks it has a tree as the source and so knows we are reading
that whole decl's value, so the code is fine as is, but in the
emit_push_insn case it checks for a MEM from which something
is pushed and checks for SYMBOL_REF as the MEM's address, but
still assumes the whole object is copied, which as the following
testcase shows might not always be the case.  In the testcase,
k is 6 bytes, then 2 bytes of padding, then another 4 bytes,
while the emit_push_insn wants to store just the 6 bytes.

The following patch simply verifies it is the whole initializer
that is being stored, I think that is best thing to do so late
in GCC 14 cycle as well for backporting.

For GCC 15, perhaps the code could stop requiring it must be at offset
zero,
nor that the size is equal, but could use
get_symbol_constant_value/fold_ctor_reference gimple-fold APIs to actually
extract just part of the initializer if we e.g. push just some subset
(of course, still verify that it is a subset).  For sizes which are power
of two bytes and we have some integer modes, we could use as type for
fold_ctor_reference corresponding integral types, otherwise dunno, punt
or use some structure (e.g. try to find one in the initializer?), whatever.
But even in the other spots it could perhaps handle loading of
COMPONENT_REFs or MEM_REFs from the .rodata vars.

2024-04-03  Jakub Jelinek  

PR middle-end/114552
* expr.cc (emit_push_insn): Only use store_constructor for
immediate_const_ctor_p if int_expr_size matches size.

* gcc.c-torture/execute/pr114552.c: New test.

(cherry picked from commit 03039744f368a24a452e4ea8d946e9c2cedaf1aa)

[Bug libquadmath/114533] libquadmath: printf: fix misaligned access on args

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

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

--- Comment #13 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

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

commit r13-8625-gcc39bd532d4de1ba0b2785246fb6fdd63ec2e92c
Author: Jakub Jelinek 
Date:   Wed Apr 3 10:02:35 2024 +0200

libquadmath: Don't assume the storage for __float128 arguments is aligned
[PR114533]

With the
register_printf_type/register_printf_modifier/register_printf_specifier
APIs the C library is just told the size of the argument and is provided
with
a callback to fetch the argument from va_list using va_arg into C library
provided
memory.  The C library isn't told what alignment requirement it has, but we
were
using direct load of a __float128 value from that memory which assumes
__alignof (__float128) alignment.

The following patch fixes that by using memcpy instead.

I haven't been able to reproduce an actual crash, tried
 #include 
 #include 
 #include 

int main ()
{
  __float128 r;
  int prec = 20;
  int width = 46;
  char buf[128];

  r = 2.0q;
  r = sqrtq (r);
  int n = quadmath_snprintf (buf, sizeof buf, "%+-#*.20Qe", width, r);
  if ((size_t) n < sizeof buf)
printf ("%s\n", buf);
/* Prints: +1.41421356237309504880e+00 */
  quadmath_snprintf (buf, sizeof buf, "%Qa", r);
  if ((size_t) n < sizeof buf)
printf ("%s\n", buf);
/* Prints: 0x1.6a09e667f3bcc908b2fb1366ea96p+0 */
  n = quadmath_snprintf (NULL, 0, "%+-#46.*Qe", prec, r);
  if (n > -1)
{
  char *str = malloc (n + 1);
  if (str)
{
  quadmath_snprintf (str, n + 1, "%+-#46.*Qe", prec, r);
  printf ("%s\n", str);
  /* Prints: +1.41421356237309504880e+00 */
}
  free (str);
}
  printf ("%+-#*.20Qe\n", width, r);
  printf ("%Qa\n", r);
  printf ("%+-#46.*Qe\n", prec, r);
  printf ("%d %Qe %d %Qe %d %Qe\n", 1, r, 2, r, 3, r);
  return 0;
}
In any case, I think memcpy for loading from it is right.

2024-04-03  Simon Chopin  
Jakub Jelinek  

PR libquadmath/114533
* printf/printf_fp.c (__quadmath_printf_fp): Use memcpy to copy
__float128 out of args.
* printf/printf_fphex.c (__quadmath_printf_fphex): Likewise.

Signed-off-by: Simon Chopin 
(cherry picked from commit 8455d6f6cd43b7b143ab9ee19437452fceba9cc9)

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

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

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

--- Comment #39 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:

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

commit r13-8623-gcb277dea557aaa25fdced201f7c45c753c709dfa
Author: Jakub Jelinek 
Date:   Tue Apr 2 13:40:27 2024 +0200

Fix up postboot dependencies [PR106472]

On Wed, Mar 13, 2024 at 10:13:37AM +0100, Jakub Jelinek wrote:
> While the first Makefile.tpl hunk looks obviously ok, the others look
> completely wrong to me.
> There is nothing special about libgo vs. libbacktrace/libatomic
> compared to any other target library which is not bootstrapped vs. any
> of its dependencies which are in the bootstrapped set.
> So, Makefile.tpl shouldn't hardcode such dependencies.

Here is my version of the fix.
The dependencies in the toplevel Makefile simply didn't take into account
that some target modules could be in a bootstrapped build built in some
configurations as bootstrap modules (typically as dependencies of other
target bootstrap modules), while in other configurations just as
dependencies of non-bootstrap target modules and so not built during the
bootstrap, but after it.
Makefile.tpl arranges for those postboot target module -> target module
dependencies to be emitted only inside of an @unless gcc-bootstrap block,
while for @if gcc-bootstrap it just emits
configure-target-whatever: stage_last
dependencies which ensure those postbootstrap target modules are only built
after everything that is bootstrapped has been.

Now, the libbacktrace/libatomic target modules have bootstrap=true
target_modules = { module= libbacktrace; bootstrap=true; };
target_modules = { module= libatomic; bootstrap=true; lib_path=.libs; };
because those modules are dependencies of libphobos target module, so
when d is included among bootstrapped languages, those are all bootstrapped
and everything works correctly.
While if d is not included, libphobos target module is disabled,
libbacktrace/libatomic target modules aren't bootstrapped, nothing during
bootstrap needs them, but post bootstrap libgo target module depends on
the libatomic and libbacktrace target modules, libgfortran target module
depends on the libbacktrace target module and libgm2 target module depends
on the libatomic target module, but those dependencies were emitted only
@unless gcc-bootstrap.  There is a similar theoretical problem for zlib
target module if GCJ would be ressurected, libphobos as bootstrap target
module depends on the zlib target module, but if d is not configured,
fastjar also depends on it.

The following patch arranges for the @if gcc-bootstrap case to emit also
target module -> target module dependencies, but conditionally on the
on dependency not being bootstrapped.

In the generated Makefile.in you can see what the Makefile.tpl change
produces and that it just adds extra dependencies which weren't there
before in the @if gcc-bootstrap case.

I've bootstrapped without this patch with
../configure --enable-languages=c,c++,go; make
on x86_64-linux (note, make -j2 or higher usually worked) which failed
as described in the PR, then with this patch with the same command which
built fine and the Makefile difference between the two builds being
diff -up obj40{a,b}/Makefile
--- obj40a/Makefile 2024-03-31 00:35:22.243791499 +0100
+++ obj40b/Makefile 2024-03-31 22:40:38.143299144 +0200
@@ -29376,6 +29376,14 @@ configure-bison: stage_last
 configure-flex: stage_last
 configure-m4: stage_last

+configure-target-fastjar: maybe-configure-target-zlib
+all-target-fastjar: maybe-all-target-zlib
+all-target-libgo: maybe-all-target-libbacktrace
+all-target-libgo: maybe-all-target-libatomic
+all-target-libgm2: maybe-all-target-libatomic
+configure-target-libgfortran: maybe-all-target-libbacktrace
+configure-target-libgo: maybe-all-target-libbacktrace
+

 # Dependencies for target modules on other target modules are
 # described by lang_env_dependencies; the defaults apply to anything

which I believe are exactly the extra dependencies we want.
Plus I've done normal x86_64-linux and i686-linux bootstraps/regtests
which in my case include
--enable-languages=default,ada,obj-c++,lto,go,d,rust,m2
for x86_64 and the same except ada for i686; those with my usual make -j32.
The Makefile difference in those builds vs. unpatched case
is just an extra empty line.

2024-04-02  Jakub Jelinek  

PR bootstrap/106472
* Makefile.tpl (make-postboot-target-dep): New lambda.
Use it to add --enable-bootstrap dependencies of target modules
on other target modules if the latter aren't bootstrapped.
* Makefile.in: Regenerate.

[Bug ipa/114790] ICE when building intel-compute-runtime (error: direct call to ... speculative call sequence has no speculative flag)

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

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

--- Comment #4 from Sam James  ---
I'm going to kick off a reduction but don't count on me either, as I hate doing
LTO ones.

[Bug lto/114790] ICE when building intel-compute-runtime (error: direct call to ... speculative call sequence has no speculative flag)

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

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

--- Comment #3 from Sam James  ---
Created attachment 57997
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57997=edit
tracing_copy_imp.cpp.ii.xz

[Bug lto/114790] ICE when building intel-compute-runtime (error: direct call to ... speculative call sequence has no speculative flag)

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

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

--- Comment #2 from Sam James  ---
Created attachment 57996
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57996=edit
tracing_device_imp.cpp.ii.xz

[Bug lto/114790] ICE when building intel-compute-runtime (error: direct call to ... speculative call sequence has no speculative flag)

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

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

--- Comment #1 from Sam James  ---
Created attachment 57995
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57995=edit
tracing_imp.cpp.ii.xz

[Bug lto/114790] New: ICE when building intel-compute-runtime (error: direct call to ... speculative call sequence has no speculative flag)

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

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

Bug ID: 114790
   Summary: ICE when building intel-compute-runtime (error: direct
call to ... speculative call sequence has no
speculative flag)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57994
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57994=edit
ze.exports

Initially reported downstream in Gentoo at https://bugs.gentoo.org/930199.

```
$ g++-14 -fPIC -O2 -flto=auto -shared -Wl,--version-script=ze.exports -o
libze_intel_gpu.so.1.3.29138 tracing_imp.cpp.ii tracing_copy_imp.cpp.ii
tracing_device_imp.cpp.ii
/var/tmp/portage/dev-libs/intel-compute-runtime-24.13.29138.7/work/compute-runtime-24.13.29138.7/level_zero/experimental/source/tracing/tracing_copy_imp.cpp:
In function ‘zeCommandListAppendMemoryCopyTracing’:
/var/tmp/portage/dev-libs/intel-compute-runtime-24.13.29138.7/work/compute-runtime-24.13.29138.7/level_zero/experimental/source/tracing/tracing_copy_imp.cpp:41:35:
error: direct call to releaseActivetracersList/1531 in speculative call
sequence has no speculative flag
   41 | return
L0::apiTracerWrapperImp(driverDdiTable.coreDdiTable.CommandList.pfnAppendMemoryCopy,
  |   ^
_ZN2L019apiTracerWrapperImpIPF12_ze_result_tP25_ze_command_list_handle_tPvPKvmP18_ze_event_handle_tjPS8_EP44_ze_command_list_append_memory_copy_params_tPFvSD_S1_S4_PS4_ESt6vectorINS_25APITracerCallbackStateImpISG_EESaISJ_EESL_JRS3_RS4_RS6_RmRS8_RjRS9_EEES1_T_T0_T1_T2_T3_DpOT4_.isra.0/10477
(apiTracerWrapperImp.isra)
  Type: function definition analyzed
  Visibility: artificial
  References: _ZN2L019APITracerContextImp24releaseActivetracersListEv/1531
(addr) (speculative) _ZTHN2L017tracingInProgressE/5374 (addr)
_ZN2L017tracingInProgressE/1237 (write) _ZN2L025globalAPITracerContextImpE/1490
(addr)
  Referring:
  Read from file: /tmp/cciN484G.ltrans0.o
  Function apiTracerWrapperImp.isra/10477 is inline copy in
zeCommandListAppendMemoryCopyTracing/3756
  Availability: local
  Unit id: 3
  Function flags: count:143044205 (estimated locally) body local
  Called by: zeCommandListAppendMemoryCopyTracing/3756 (inlined) (143044205
(estimated locally),0.50 per call)
  Calls: _ZN2L019APITracerContextImp24releaseActivetracersListEv/1531
(114435364 (estimated locally),0.40 per call)
_ZNSt6vectorIPvSaIS0_EE6resizeEm.constprop.0/11584 (inlined) (143044205
(estimated locally),0.50 per call) (can throw external)
_ZNSt6vectorIN2L025APITracerCallbackStateImpIPFvP44_ze_command_list_append_memory_copy_params_t12_ze_result_tPvPS5_EEESaIS9_EE2atEm/10833
(inlined) (1157357666 (estimated locally),4.05 per call) (can throw external)
_ZNSt6vectorIN2L025APITracerCallbackStateImpIPFvP44_ze_command_list_append_memory_copy_params_t12_ze_result_tPvPS5_EEESaIS9_EE2atEm/4315
(inlined) (618839143 (estimated locally),2.16 per call) (can throw external)
_ZNSt6vectorIPvSaIS0_EEixEm.isra.0/11478 (inlined) (618839143 (estimated
locally),2.16 per call)
_ZNSt6vectorIN2L025APITracerCallbackStateImpIPFvP44_ze_command_list_append_memory_copy_params_t12_ze_result_tPvPS5_EEESaIS9_EE2atEm/11133
(inlined) (618839143 (estimated locally),2.16 per call) (can throw external)
_ZNSt6vectorIN2L025APITracerCallbackStateImpIPFvP44_ze_command_list_append_memory_copy_params_t12_ze_result_tPvPS5_EEESaIS9_EE2atEm/10733
(inlined) (1157357666 (estimated locally),4.05 per call) (can throw external)
_ZNSt6vectorIN2L025APITracerCallbackStateImpIPFvP44_ze_command_list_append_memory_copy_params_t12_ze_result_tPvPS5_EEESaIS9_EE2atEm/11033
(inlined) (618839143 (estimated locally),2.16 per call) (can throw external)
_ZNSt6vectorIPvSaIS0_EEixEm.isra.0/11462 (inlined) (618839143 (estimated
locally),2.16 per call)
_ZNSt6vectorIN2L025APITracerCallbackStateImpIPFvP44_ze_command_list_append_memory_copy_params_t12_ze_result_tPvPS5_EEESaIS9_EE2atEm/10933
(inlined) (618839143 (estimated locally),2.16 per call) (can throw external)
_ZTHN2L017tracingInProgressE/5374 (76485736 (estimated locally),0.27 per call)
(can throw external) _ZNSt12_Vector_baseIPvSaIS0_EED2Ev.isra.0/11539 (inlined)
(143044205 (estimated locally),0.50 per call)
_ZNSt12_Vector_baseIPvSaIS0_EED2Ev.isra.0/10508 (0 (precise),0.00 per call)
   Indirect call(618839143 (estimated locally),2.16 per call) (can throw
external) num speculative call targets: 0
   Indirect call(143044205 (estimated locally),0.50 per call) (can throw
external) num speculative call targets: 0
   Indirect call(618839143 (estimated locally),2.16 per call) (can throw
external) num speculative call targets: 0
   Indirect call(speculative) (28608841 (estimated locally),0.10 per call) (can
throw external) num speculative call targets: 1
during IPA pass: inline

[Bug tree-optimization/114787] [13/14 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #5)
> The first difference (in GCC 13) with/without -fdump-tree-all-all comes from
> cunroll:


I should note that -fdump-tree-cunroll-all still produces the correct code
generation for GCC 13 which makes this bug even odder.

[Bug tree-optimization/114787] [13/14 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)

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

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

--- Comment #5 from Andrew Pinski  ---
The first difference (in GCC 13) with/without -fdump-tree-all-all comes from
cunroll:



Broken:
```
Loop 3 iterates 2 times.
Loop 3 iterates at most 1 times.
Loop 3 likely iterates at most 1 times.
Analyzing # of iterations of loop 3
  exit condition [2, + , 4294967295] != 0
  bounds on difference of bases: -2 ... -2
  result:
# of iterations 2, bounded by 2
Removed pointless exit: if (ivtmp_43 != 0)
```

Working:
```
Loop 3 iterates 2 times.
Loop 3 iterates at most 2 times.
Loop 3 likely iterates at most 2 times.
```

[Bug tree-optimization/114787] [13/14 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
  Known to work||12.1.0
   Target Milestone|14.0|13.3
  Known to fail||13.1.0
Summary|[14 Regression] wrong code  |[13/14 Regression] wrong
   |at -O1 on x86_64-linux-gnu  |code at -O1 on
   |(the generated code hangs)  |x86_64-linux-gnu (the
   ||generated code hangs)

--- Comment #4 from Andrew Pinski  ---
So with GCC 13, with `-fdump-tree-all-all`, we get the same wrong code as on
the trunk.

This is why I was I misunderstood thinking it was a target issue as I was
comparing the dumps between GCC 13 and the trunk with -all enabled but it was
broken in GCC 13 too.

Anyways I tested GCC 12.3.0 and it looks to be working there.

It would be useful to get another bisect done this time with `-O1
-fdump-tree-all-all` .

[Bug tree-optimization/114787] [14 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |tree-optimization

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> The first difference besides prediction/counts on the BB is in the register
> allocator.
> 
> The code for aarch64 looks ok too.

So I was wrong (and now even more confused than before). In that sometimes even
GCC 13.2.0 code generation is broken. But I don't understand what the
conditions are which cause it (adding -fdump-tree-optimized-all or something
like that seems to cause different code generation).

[Bug target/114787] [14 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-linux-gnu
  Component|tree-optimization   |target

--- Comment #2 from Andrew Pinski  ---
The first difference besides prediction/counts on the BB is in the register
allocator.

The code for aarch64 looks ok too.

[Bug c/114789] New: False positive -Wmaybe-uninitialized at -O2

[jb999 at gmx dot de via Gcc-bugs]

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

Bug ID: 114789
   Summary: False positive -Wmaybe-uninitialized at -O2
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jb999 at gmx dot de
  Target Milestone: ---

This test case produces a false positive -Wmaybe-uninitialized warning with
PARTS set to 2 or higher, but not with PARTS set to 1 or at -O instead of -O2:

#include 

#define PARTS 2

void foo(void **);

void grab (char *line)
{
  void *item[1];

  unsigned int part = 1;

  do
  {
while (*line && *line == ' ') line++;
if (part == 1) item[0] = line;
while (*line && *line != ' ') line++;
  }
  while (++part <= PARTS);

  if (*line) *line++ = 0;

  if (strlen(item[0])) foo(item);
}

Output:

Using built-in specs.
COLLECT_GCC=/tmp/gcc14/usr/bin/gcc
Target: i686-pc-linux-gnu
Configured with: /tmp/gcc/configure --prefix=/tmp/gcc14/usr
--sysconfdir=/tmp/gcc14/etc --sharedstatedir=/tmp/gcc14/var/state
--localstatedir=/tmp/gcc14/var/state --enable-shared --disable-static
--disable-nls --enable-languages=c,c++ --with-system-zlib --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.1 20240416 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-Wuninitialized' '-c'
'-mtune=generic' '-march=pentiumpro'
 /tmp/gcc14/usr/libexec/gcc/i686-pc-linux-gnu/14.0.1/cc1 -E -quiet -v
testcase.c -mtune=generic -march=pentiumpro -Wuninitialized -O2
-fpch-preprocess -o testcase.i
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/tmp/gcc14/usr/lib/gcc/i686-pc-linux-gnu/14.0.1/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /tmp/gcc14/usr/lib/gcc/i686-pc-linux-gnu/14.0.1/include
 /tmp/gcc14/usr/include
 /tmp/gcc14/usr/lib/gcc/i686-pc-linux-gnu/14.0.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-Wuninitialized' '-c'
'-mtune=generic' '-march=pentiumpro'
 /tmp/gcc14/usr/libexec/gcc/i686-pc-linux-gnu/14.0.1/cc1 -fpreprocessed
testcase.i -quiet -dumpbase testcase.c -dumpbase-ext .c -mtune=generic
-march=pentiumpro -O2 -Wuninitialized -version -o testcase.s
GNU C17 (GCC) version 14.0.1 20240416 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 14.0.1 20240416 (experimental), GMP version
6.0.0, MPFR version 3.1.3-p4, MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 2da1b27980967f452f520dd3eb2f4c0a
testcase.c: In function 'grab':
testcase.c:23:18: warning: 'item' may be used uninitialized
[-Wmaybe-uninitialized]
   23 |   if (strlen(item[0])) foo(item);
  |  ^~~
testcase.c:9:9: note: 'item' declared here
9 |   void *item[1];
  | ^~~~
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-Wuninitialized' '-c'
'-mtune=generic' '-march=pentiumpro'
 as -v --32 -o testcase.o testcase.s
GNU assembler version 2.29.1 (i686-pc-linux-gnu) using BFD version (GNU
Binutils) 2.29.1
COMPILER_PATH=/tmp/gcc14/usr/libexec/gcc/i686-pc-linux-gnu/14.0.1/:/tmp/gcc14/usr/libexec/gcc/i686-pc-linux-gnu/14.0.1/:/tmp/gcc14/usr/libexec/gcc/i686-pc-linux-gnu/:/tmp/gcc14/usr/lib/gcc/i686-pc-linux-gnu/14.0.1/:/tmp/gcc14/usr/lib/gcc/i686-pc-linux-gnu/
LIBRARY_PATH=/tmp/gcc14/usr/lib/gcc/i686-pc-linux-gnu/14.0.1/:/tmp/gcc14/usr/lib/gcc/i686-pc-linux-gnu/14.0.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-Wuninitialized' '-c'
'-mtune=generic' '-march=pentiumpro'

[Bug rtl-optimization/114788] New: ICE on valid code at -O{2,3} on x86_64-linux-gnu (during RTL pass: sched2): in move_exprs_to_boundary, at sel-sched.cc:5236

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

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

Bug ID: 114788
   Summary: ICE on valid code at -O{2,3} on x86_64-linux-gnu
(during RTL pass: sched2): in move_exprs_to_boundary,
at sel-sched.cc:5236
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It is a regression from 12.*, and affects 13.* and later. 

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

[679] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.1 20240420 (experimental) (GCC)
[680] %
[680] % gcctk -O3 -fno-guess-branch-probability -fselective-scheduling2
-fno-tree-sink -fschedule-insns -c small.c
during RTL pass: sched2
small.c: In function ‘main’:
small.c:32:1: internal compiler error: in move_exprs_to_boundary, at
sel-sched.cc:5236
   32 | }
  | ^
0x8424f2 move_exprs_to_boundary
../../gcc-trunk/gcc/sel-sched.cc:5236
0x8424f2 schedule_expr_on_boundary
../../gcc-trunk/gcc/sel-sched.cc:5444
0x1125588 fill_insns
../../gcc-trunk/gcc/sel-sched.cc:5586
0x1125588 schedule_on_fences
../../gcc-trunk/gcc/sel-sched.cc:7361
0x1125588 sel_sched_region_2
../../gcc-trunk/gcc/sel-sched.cc:7499
0x1126c78 sel_sched_region_1
../../gcc-trunk/gcc/sel-sched.cc:7541
0x1128a19 sel_sched_region(int)
../../gcc-trunk/gcc/sel-sched.cc:7642
0x1128a19 sel_sched_region(int)
../../gcc-trunk/gcc/sel-sched.cc:7627
0x1129a21 run_selective_scheduling()
../../gcc-trunk/gcc/sel-sched.cc:7728
0x1106c0d rest_of_handle_sched2
../../gcc-trunk/gcc/sched-rgn.cc:3741
0x1106c0d execute
../../gcc-trunk/gcc/sched-rgn.cc:3888
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.
[681] % cat small.c
extern void r();
int b, d, g, l;
char c, e, f;
volatile char h;
int main() {
  int k, i, m, q;
  for (; b && i; i++) {
int n = k;
  L1:
k = 0 || d;
while (n < e)
  ;
  }
  b = f;
 L2:
  if (h)
r();
  if (l) {
int a, j = f / g, o = (j / c && f) % d, p = (f % q * ~h && c && j) / k;
if (h) {
  a = d;
  p = m;
  k = k / l / (2 * f % 3);
  m = o & c / ((m && a) ^ (p && 2 / g) | f);
  if (m)
goto L1;
}
m = p;
goto L2;
  }
  return 0;
}

[Bug ada/114710] temporary object finalized too late

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

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Temporary object finalized  |temporary object finalized
   |too late, causing deadlock  |too late
   Last reconfirmed||2024-04-20
 Status|UNCONFIRMED |NEW

--- Comment #1 from Eric Botcazou  ---
Yes, this works as expected in simpler cases, but not here.

[Bug rtl-optimization/114766] ^ constraint modifier unexpectedly affects register class selection.

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

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

--- Comment #2 from Tamar Christina  ---
(In reply to Vladimir Makarov from comment #1)
> (In reply to Tamar Christina from comment #0)
> > The documentation for ^ states:
>
> If it works for you, we could try to use the patch (although it needs some
> investigation how other targets uses the hint).  In any case, the
> documentation should be modified or made more clear depending on applying or
> not applying the patch.

Yeah, using the patch gives us the behavior we expected, we added a workaround
for now so we can investigate what other targets do in GCC 15.

But while looking at this we also got some unexpected behavior with using ?

For instance we have the pattern:

;; Equal width integer to fp conversion.
(define_insn "2"
  [(set (match_operand:GPF 0 "register_operand")
(FLOATUORS:GPF (match_operand: 1 "register_operand")))]
  "TARGET_FLOAT"
  {@ [ cons: =0 , 1  ; attrs: type , arch  ]
 [ w, w  ; neon_int_to_fp_ , simd  ]
cvtf\t%0, %1
 [ w, ?r ; f_cvti2f, fp]
cvtf\t%0, %1
  })

for modeling floating point conversions. We had expected ? to make the
alternative more expensive, but still possible.  However again during IRA the
entire register class is blocked:

r103: preferred FP_REGS, alternative NO_REGS, allocno FP_REGS

I would have expected that the additional penalty should never make an
alternative impossible.
We thought maybe the move costs were an issue, but we tried with various big
and small numbers but it looks like the move costs have little to no effect. 
Since the original value in this case was in r:

  Choosing alt 0 in insn 7:  (0) =rk  (1) %rk  (2) I {*adddi3_aarch64}

I would have expected the cost for FP_REGS not to be 0, as there's a register
file move involved:

  r103 costs: W8_W11_REGS:2000 W12_W15_REGS:2000 TAILCALL_ADDR_REGS:2000
STUB_REGS:2000 GENERAL_REGS:2000 FP_LO8_REGS:0 FP_LO_REGS:0 FP_REGS:0
POINTER_AND_FP_REGS:7000 MEM:9000

In this particular pattern the ? isn't needed so we're removing it, but the
behavior is still unexpected.

[Bug ada/114708] [12/13/14 regression] internal error on access to an incomplete formal in generic package

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

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

Eric Botcazou  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org

--- Comment #2 from Eric Botcazou  ---
I'll have a look.

[Bug ada/114708] [12/13/14 regression] internal error on access to an incomplete formal in generic package

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug ada/114708] [12/13/14 regression] internal error on access to an incomplete formal in generic package

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

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
Summary|Creating access to an   |[12/13/14 regression]
   |incomplete formal in a  |internal error on access to
   |generic package sometimes   |an incomplete formal in
   |causes GNAT to crash|generic package
   Last reconfirmed||2024-04-20
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
Confirmed as a regression in GCC 12 and later.

[Bug ada/114640] ICE on elsif part of if-statement containing if-expression

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Botcazou  ---
I'll test the above fixlet.

[Bug ada/114640] ICE on elsif part of if-statement containing if-expression

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

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

--- Comment #3 from Eric Botcazou  ---
This appears to be sufficient:

diff --git a/gcc/ada/exp_util.adb b/gcc/ada/exp_util.adb
index 04d114694ab..71cfdd718e0 100644
--- a/gcc/ada/exp_util.adb
+++ b/gcc/ada/exp_util.adb
@@ -6549,6 +6549,7 @@ package body Exp_Util is
 | N_Aggregate
 | N_Delta_Aggregate
 | N_Extension_Aggregate
+| N_Elsif_Part
   and then Nkind (Parent (Par)) not in N_Function_Call
  | N_Procedure_Call_Statement
  | N_Entry_Call_Statement

[Bug ada/114640] ICE on elsif part of if-statement containing if-expression

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

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

Eric Botcazou  changed:

   What|Removed |Added

Summary|ICE on 'elsif' with complex |ICE on elsif part of
   |function call   |if-statement containing
   ||if-expression
 Ever confirmed|0   |1
 CC||ebotcazou at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-04-20

--- Comment #2 from Eric Botcazou  ---
Indeed, way too many chained/nested ifs here. :-)

[Bug analyzer/104042] Four memcpy/memset analyzer failures on darwin

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

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

--- Comment #8 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Iain D Sandoe
:

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

commit r12-10361-gc2cb625eb141cacd0bee6c6ce5888d673ac38ca4
Author: Francois-Xavier Coudert 
Date:   Sat Aug 19 23:22:06 2023 +0200

Testsuite: fix analyzer tests on Darwin

On macOS, system headers redefine by default some macros (memcpy,
memmove, etc) to checked versions, which defeats the analyzer. We
want to turn this off.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042

gcc/testsuite/ChangeLog:

PR analyzer/104042
* gcc.dg/analyzer/analyzer.exp: Pass -D_FORTIFY_SOURCE=0 on Darwin.

(cherry picked from commit ce33bbfcbc7dd3afc6c96fb48a19ed00f0c598ce)

[Bug ada/114636] actual does not match formal in instantiation with formal package

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Botcazou  ---
I'll test the above fixlet.

[Bug ada/114636] actual does not match formal in instantiation with formal package

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

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

--- Comment #2 from Eric Botcazou  ---
This appears to be sufficient:

diff --git a/gcc/ada/sem_ch12.adb b/gcc/ada/sem_ch12.adb
index e7b759c4e88..c06377ab4c9 100644
--- a/gcc/ada/sem_ch12.adb
+++ b/gcc/ada/sem_ch12.adb
@@ -6696,8 +6696,12 @@ package body Sem_Ch12 is
  then
 --  If the formal is a tagged type the corresponding class-wide
 --  type has been generated as well, and it must be skipped.
+--  Likewise, for a formal discrete type, the base type has been
+--  generated as well (see Analyze_Formal_Discrete_Type).

-if Is_Type (E2) and then Is_Tagged_Type (E2) then
+if Is_Type (E2)
+  and then (Is_Tagged_Type (E2) or else Is_Enumeration_Type (E2))
+then
Next_Entity (E2);
 end if;

[Bug ada/114636] actual does not match formal in instantiation with formal package

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

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

Eric Botcazou  changed:

   What|Removed |Added

Summary|Actual does not match   |actual does not match
   |formal in generic   |formal in instantiation
   |instantiation   |with formal package
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-04-20
 CC||ebotcazou at gcc dot gnu.org

--- Comment #1 from Eric Botcazou  ---
This comes from the formal discrete types and has probably never worked.

[Bug tree-optimization/114787] [14 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||law at gcc dot gnu.org

[Bug modula2/112893] gm2 fails to detect procedure address actual parameter is incompatible with cardinal formal parameter

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

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

[Bug modula2/112893] gm2 fails to detect procedure address actual parameter is incompatible with cardinal formal parameter

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

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

--- Comment #9 from GCC Commits  ---
The master branch has been updated by Gaius Mulley :

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

commit r14-10053-gf9a48fe7032d9894e88d0d121ba6f75b08ea5dcb
Author: Gaius Mulley 
Date:   Sat Apr 20 14:35:18 2024 +0100

PR modula2/112893 full type checking between proctype and procedure not
implemented

This patch implements full type checking between proctype and procedures.
The change implements an associated proc type built for each
procedure.  M2Check.mod will request GetProcedureProcType if it encounters
a procedure.  Before this patch a procedure was associated with the type
ADDRESS in the type checking module M2Check.  The
gm2/pim/pass/proccard.mod have been corrected now this assumption has
been removed.

gcc/m2/ChangeLog:

PR modula2/112893
* gm2-compiler/M2Check.mod (GetProcedureProcType): Import.
(getType): Return value using GetProcedureProcType if sym is a
procedure.
* gm2-compiler/M2Range.mod (FoldTypeExpr): Remove quad if
expression is type compatible.
* gm2-compiler/SymbolTable.def (GetProcedureProcType): New
procedure function.
* gm2-compiler/SymbolTable.mod (Procedure): Add ProcedureType.
(MakeProcedure): Initialize ProcedureType.
(PutParam): Call AddProcedureProcTypeParam.
(PutVarParam): Call AddProcedureProcTypeParam.
(AddProcedureProcTypeParam): New procedure.
(GetProcedureProcType): New procedure function.

gcc/testsuite/ChangeLog:

PR modula2/112893
* gm2/pim/pass/another.mod: Correct bug exposed by type checker.
Swap ProcA and ProcB assignments.
* gm2/pim/pass/proccard.mod: Use VAL to convert procedure into a
cardinal.
* gm2/iso/const/fail/castproctype.mod: New test.
* gm2/pim/fail/badproctype.mod: New test.

Signed-off-by: Gaius Mulley 

[Bug c++/114764] noexcept on a friend complains about incomplete type

[dangelog at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Giuseppe D'Angelo  ---
I get it :)

If you wanted an actual use-case (rather than a synthetic testcase), we
stumbled upon this bug from implementing a friend operator==:


```
class S {

  bool comparesEqual(S, S) noexcept; // pass by value, object is
small/trivially copyable
  friend inline bool operator==(S a, S b) noexcept(noexcept(comparesEqual(S,
S))) {
 returns comparesEqual(a, b);
  }
};
```

which is the result of some macro expansions through which we support C++20's
comparisons in C++17 in Qt. The problem is the pass by value -- changing it to
pass by const-ref fixes it, but generates different linting about not passing a
small TC object by value...

[Bug tree-optimization/114787] [14 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Version|unknown |14.0
   Last reconfirmed||2024-04-20
 CC||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Target Milestone|--- |14.0
 Status|UNCONFIRMED |NEW
Summary|wrong code at -O1 on|[14 Regression] wrong code
   |x86_64-linux-gnu (the   |at -O1 on x86_64-linux-gnu
   |generated code hangs)   |(the generated code hangs)
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r14-7138-g05e8ef2a05b477589cae25af3311bad0f68a90fe

[Bug tree-optimization/114787] New: wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)

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

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

Bug ID: 114787
   Summary: wrong code at -O1 on x86_64-linux-gnu (the generated
code hangs)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

It appears to be a recent regression and does not reproduce with 13.2 and
earlier. 

Compiler Explorer: https://godbolt.org/z/6sbh8Wr1e


[663] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.1 20240420 (experimental) (GCC) 
[664] % 
[664] % gcctk -O0 small.c; ./a.out
[665] % 
[665] % gcctk -O1 small.c
[666] % timeout -s 9 10 ./a.out
Killed
[667] % 
[667] % cat small.c
int a, b, c, d, e = -1, f, g, h, j, k, n, o, p;
int main() {
  int i, l = 2, m;
  for (b = 0; b < 1; b++)
l = 0;
  for (; a >= 0; a--)
for (m = 3; m; m--) {
  k = g;
  i = 0;
  for (; i < 1; i++)
for (; f < 1; f++)
  h = g;
  n = 2 & ((e ^ d) | 1) * j;
  o = ~(e & n);
q:
  if (c <= e)
return 0;
  e = o;
}
  p = l;
  l = 0;
  if (p)
goto q;
  return 0;
}

[Bug tree-optimization/101139] Unable to remove double byteswap in fast path

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

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

--- Comment #5 from Andrew Pinski  ---
Created attachment 57993
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57993=edit
Patch but it does not work for the code in this testcase

I have to look into why it is not working for the testcase in comment #0
(factor_out_conditional_operation is not even called) but it does work for:
```
short f(int a, short b, short c)
{
  if (a)
return __builtin_bswap16(b);
  return __builtin_bswap16(c);
}
```

[Bug c/114361] ICE with c23 related to completion of incomplete structure types

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #9 from uecker at gcc dot gnu.org ---
Fixed.

[Bug target/114786] New: ICE in recog.cc: unrecognizable insn while compiling bcd-3.c for power pc

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

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

Bug ID: 114786
   Summary: ICE in recog.cc: unrecognizable insn while compiling
bcd-3.c for power pc
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pheeck at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: ppc64le-linux-gnu

While compiling the GCC testsuite testcase gcc.target/powerpc/bcd-3.c with a
cross-compiler for power pc

ppc64le-linux-gnu-gcc
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/powerpc/bcd-3.c
-ffinite-math-only

the following ICE happens

/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/powerpc/bcd-3.c:
In function ‘do_sub_ge’:
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/powerpc/bcd-3.c:104:1:
error: unrecognizable insn:
  104 | }
  | ^
(insn 22 21 23 2 (set (reg:SI 117 [ _1 ])
(ge:SI (reg:CCFP 106 6)
(const_int 0 [0])))
"/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/powerpc/bcd-3.c":100:7
-1
 (nil))
during RTL pass: vregs
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/powerpc/bcd-3.c:104:1:
internal compiler error: in extract_insn, at recog.cc:2812
0x656597 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/rtl-error.cc:108
0x6565b3 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
   
/home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/rtl-error.cc:116
0x655a16 extract_insn(rtx_insn*)
   
/home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/recog.cc:2812
0x92d390 instantiate_virtual_regs_in_insn
   
/home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/function.cc:1612
0x92d390 instantiate_virtual_regs
   
/home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/function.cc:1995
0x92d390 execute
   
/home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/function.cc:2042
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.


ppc64le-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/home/worker/cross/bin/ppc64le-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/worker/cross/libexec/gcc/ppc64le-linux-gnu/14.0.1/lto-wrapper
Target: ppc64le-linux-gnu
Configured with:
/home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/configure
--enable-languages=c,c++,fortran --disable-bootstrap --disable-libsanitizer
--disable-multilib --enable-checking=release --prefix=/home/worker/cross
--target=ppc64le-linux-gnu --with-as=/usr/bin/powerpc64le-suse-linux-as
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240419 (experimental)
c23db3ebb65ba357155be85ef56d037403eaee36 (GCC)