[Bug testsuite/109549] [14 Regression] Conditional move regressions after r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a

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

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

--- Comment #13 from Stefan Schulze Frielinghaus  ---
I will take it and I've already prepared a patch.  Currently, I'm still testing
the patch.  I hope I get enough compute resources in order to make it into GCC
14.

Anyhow, you can assign the issue to me (I think I don't have permissions to do
it myself).

[Bug middle-end/111151] [12/13/14 Regression] Wrong code at -O0 on x86_64-pc-linux-gnu

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

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

--- Comment #13 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #11)
> Perhaps
> --- fold-const.cc.jj8 2024-03-11 22:37:29.0 +0100
> +++ fold-const.cc 2024-03-22 19:31:44.189686120 +0100
> @@ -7104,6 +7104,27 @@ extract_muldiv_1 (tree t, tree c, enum t
>if (TYPE_UNSIGNED (ctype) != TYPE_UNSIGNED (type))
>   break;
>  
> +  /* Punt for multiplication altogether.
> +  MAX (1U + INT_MAX, 1U) * 2U is not equivalent to
> +  MAX ((1U + INT_MAX) * 2U, 1U * 2U), the former is
> +  0U, the latter is 2U.
> +  MAX (INT_MIN / 2, 0) * -2 is not equivalent to
> +  MIN (INT_MIN / 2 * -2, 0 * -2), the former is
> +  well defined 0, the latter invokes UB.
> +  MAX (INT_MIN / 2, 5) * 5 is not equivalent to
> +  MAX (INT_MIN / 2 * 5, 5 * 5), the former is
> +  well defined 25, the latter invokes UB.  */
> +  if (code == MULT_EXPR)
> + break;
> +  /* For division/modulo, punt on c being -1 for MAX, as
> +  MAX (INT_MIN, 0) / -1 is not equivalent to
> +  MIN (INT_MIN / -1, 0 / -1), the former is well defined
> +  0, the latter invokes UB (or for -fwrapv is INT_MIN).
> +  MIN (INT_MIN, 0) / -1 already invokes UB, so the
> +  transformation won't make it worse.  */
> +  else if (tcode == MAX_EXPR && integer_minus_onep (c))
> + break;
> +
>/* MIN (a, b) / 5 -> MIN (a / 5, b / 5)  */
>sub_strict_overflow_p = false;
>if ((t1 = extract_muldiv (op0, c, code, wide_type,
> ?

I think that looks reasonable.

[Bug tree-optimization/114435] PCOM messes up vectorization some times

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
We've moved pcom after loop vectorization because of this.  But yes,
moving pcom further down is a possibility although we lack DCE after SLP
(prefetching and IVOPTs might be also confused because of that, so it
seems like a separate problem).

So yes, moving pcom after SLP and before loop prefetching sounds reasonable
to me.

[Bug target/114416] calling convention incompatibility with vendor compiler for V9

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

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

--- Comment #5 from Eric Botcazou  ---
Created attachment 57806
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57806&action=edit
Tentative fix

[Bug tree-optimization/114440] Fail to recognize a chain of lane-reduced operations for loop reduction vect

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

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||53947
   Last reconfirmed||2024-03-25
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
It looks like this should be possible, but of course this performs more "weird"
re-association which might be a problem with floating-point (though I don't
know of any lane-reducing ops implemented for FP).

Representing the "scalar" side in the vectorizer IL is tricky though, this
is why the current handling is separated and not integrated with the rest
(so it doesn't compose as you noticed).

Note we lack SLP recognition for dot_prod and sad also because we do not
specify which lanes are combined, so the optabs are a black-box and only
useful when the resulting lanes are reduced.


Referenced Bugs:

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

[Bug driver/114447] -fstack-protector-explicit ignored

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org
  Component|middle-end  |driver

--- Comment #2 from Richard Biener  ---
It's probably a specs issue instead (all the options should probably be aliases
to a new one with a ENUM specifier).

Note I guess that it's Ubuntu patching GCCs specs here (CCing maintainer).

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #26 from Uroš Bizjak  ---
Do we also need to adjust TSAN? There is a bugreport that KCSAN does work
correctly with the named address spaces.

[Bug middle-end/114449] bswap64 not optimized

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

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

--- Comment #5 from Richard Biener  ---
Note we do unroll the loop with -O3 but only late after which we do not re-do
bswap recognition (which happens before loop optimization).  At -O2 we
don't unroll because that increases code-size too much.

Recognition of "final value computation" is done in the sccp pass which
could be amended for this (final_value_replacement_loop,
tree-scalar-evolution.cc).

[Bug testsuite/109549] [14 Regression] Conditional move regressions after r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a

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

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

--- Comment #14 from Sam James  ---
Hi Stefan, you should be able to change your email on bugzilla to
@gcc.gnu.org and gain permissions.

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

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

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

--- Comment #27 from Jakub Jelinek  ---
I think it should.
E.g. for
int __seg_fs a;

void
foo (int __seg_fs *p)
{
  a = *p;
}
the instrumentation is
  _5 = __builtin_return_address (0);
  __builtin___tsan_func_entry (_5);
  __builtin___tsan_read4 (p_3(D));
  _1 = *p_3(D);
  __builtin___tsan_write4 (&a);
  a = _1;
  __builtin___tsan_func_exit (); [tail call]
but neither __tsan_read4 nor __tsan_write4 will know that the address they are
passed are not from the generic address space.

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

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

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

--- Comment #28 from Jakub Jelinek  ---
Created attachment 57807
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57807&action=edit
gcc14-pr111736-tsan.patch

Untested patch for tsan.

[Bug libstdc++/77776] C++17 std::hypot implementation is poor

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

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

--- Comment #24 from Matthias Kretz (Vir)  ---
(In reply to g.peterhoff from comment #23)
> * How do you create the benchmarks?

https://github.com/mattkretz/simd-benchmarks
Look at hypot3.cpp :)

[Bug rtl-optimization/114452] New: Functions invoked through compile-time table of function pointers not inlined

[chfast at gmail dot com via Gcc-bugs]

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

Bug ID: 114452
   Summary: Functions invoked through compile-time table of
function pointers not inlined
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chfast at gmail dot com
  Target Milestone: ---

In the following example there is a compile-time table of pointers to simple
functions. When the table is used in a simple unrolled loop with constant trip
count the functions invoked by pointers are not inlined.

using F = int (*)(int) noexcept;

void test(int z[2]) noexcept {
static constexpr F fs[]{
[](int x) noexcept { return x; },
[](int x) noexcept { return x; },
};

for (int i = 0; i < 2; ++i) {
z[i] = fs[i](z[i]);
}
}

Generated assembly:

test(int*)::{lambda(int)#1}::_FUN(int):
mov eax, edi
ret
test(int*)::{lambda(int)#2}::_FUN(int):
mov eax, edi
ret
test(int*):
mov rdx, rdi
mov edi, DWORD PTR [rdi]
calltest(int*)::{lambda(int)#1}::_FUN(int)
mov edi, DWORD PTR [rdx+4]
mov DWORD PTR [rdx], eax
calltest(int*)::{lambda(int)#2}::_FUN(int)
mov DWORD PTR [rdx+4], eax
ret


https://godbolt.org/z/fGqPKh81j

[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #29 from Uroš Bizjak  ---
Do we also need to adjust TSAN? There is a bugreport that KCSAN does work
correctly with the named address spaces.(In reply to Jakub Jelinek from comment
#28)
> Created attachment 57807 [details]
> gcc14-pr111736-tsan.patch
> 
> Untested patch for tsan.

Yes, this patch fixes the failure for linux kernel.

[Bug rtl-optimization/114452] Functions invoked through compile-time table of function pointers not inlined

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Xi Ruoyao  ---
Dup.

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

[Bug ipa/111573] lambda functions often not inlined and optimized out

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||chfast at gmail dot com

--- Comment #3 from Xi Ruoyao  ---
*** Bug 114452 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/114452] Functions invoked through compile-time table of function pointers not inlined

[chfast at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Paweł Bylica  ---
I don't think this is related to lambdas. The following is also not optimized:


using F = int (*)(int) noexcept;

inline int impl(int x) noexcept { return x; }

void test(int z[2]) noexcept {
static constexpr F fs[]{
impl,
impl,
};

for (int i = 0; i < 2; ++i) {
z[i] = fs[i](z[i]);
}
}

https://godbolt.org/z/9hPbzo4Px

[Bug rtl-optimization/114452] Functions invoked through compile-time table of function pointers not inlined

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

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

--- Comment #3 from Xi Ruoyao  ---
(In reply to Paweł Bylica from comment #2)
> I don't think this is related to lambdas. The following is also not
> optimized:
> 
> 
> using F = int (*)(int) noexcept;
> 
> inline int impl(int x) noexcept { return x; }
> 
> void test(int z[2]) noexcept {
> static constexpr F fs[]{
> impl,
> impl,
> };
> 
> for (int i = 0; i < 2; ++i) {
> z[i] = fs[i](z[i]);
> }
> }
> 
> https://godbolt.org/z/9hPbzo4Px

The analysis of PR111573 says:

"So we fail to inline since ipa-prop fails to track the constant function
address.  I think this is really common in typical lambda function usage"

"fails to track the constant function address" applies for normal functions
too.

[Bug go/114453] New: 32-bit go.test/test/fixedbugs/issue16016.go FAILs

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

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

Bug ID: 114453
   Summary: 32-bit go.test/test/fixedbugs/issue16016.go FAILs
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: i386-pc-solaris2.11, sparc-sun-solaris2.11,
i686-pc-linux-gnu

The 32-bit go.test/test/fixedbugs/issue16016.go FAILs on most (all?) targets:

FAIL: go.test/test/fixedbugs/issue16016.go execution,  -O2 -g 

On Solaris, the error is like

runtime: out of memory: cannot allocate 4194304-byte block (3779067904 in use)
fatal error: out of memory

while on Linux/i686 I get

unable to allocate additional stack space: errno 1
SIGABRT: abort
PC=0xf7ed3d99 m=6 sigcode=4294967290

[Bug c++/93595] [c++20] function call, substitution failure of template parameter with a lambda default in template context

[andrea.agostini.sax at gmail dot com via Gcc-bugs]

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

Andrea Agostini  changed:

   What|Removed |Added

 CC||andrea.agostini.sax at gmail 
dot c
   ||om

--- Comment #9 from Andrea Agostini  ---
While trying to work around this, I massaged the code enough for the compiler
to produce a more interesting message: see https://godbolt.org/z/Gsbv8fG7M

Adding a return statement to the lambda makes the compiler confess that it
thinks the lambda should return int, rather than void. Maybe this can help
pinpoint the bug?

[Bug middle-end/111151] [12/13/14 Regression] Wrong code at -O0 on x86_64-pc-linux-gnu

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

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

--- Comment #14 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #12)
> The following testcase at least reproduces the unsigned multiplication
> issue, but doesn't reproduce the signed multiplication nor division by -1.
> int
> main ()
> {
>   unsigned a = (1U + __INT_MAX__) / 2U;
>   unsigned b = 1U;
>   unsigned c = (a * 2U > b * 2U ? a * 2U : b * 2U) * 2U;
>   if (c != 0U)
> __builtin_abort ();
>   int d = (-__INT_MAX__ - 1) / 2;
>   int e = 10;
>   int f = (d * 2 > e * 2 ? d * 2 : e * 2) * 6;
>   if (f != 120)
> __builtin_abort ();
>   int g = (-__INT_MAX__ - 1) / 2;
>   int h = 0;
>   int i = (g * 2 > h * 2 ? g * 2 : h * 2) / -1;
>   if (i != 0)
> __builtin_abort ();
> }

Ah, the reason it doesn't fail for the f and i cases is that for the signed
type cases, we actually don't create a MIN_EXPR or MAX_EXPR but COND_EXPR which
just compares the vars and performs multiplication only in the COND_EXPR
second/third arguments.
So it is kind of hard trying to make it trigger for the problematic cases where
the recursive calls would extract something.

Will see in full bootstrap/regtest with logging how often does the patch
trigger.

[Bug testsuite/109549] [14 Regression] Conditional move regressions after r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a

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

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

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

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

--- Comment #15 from Stefan Schulze Frielinghaus  
---
Hi Sam, thanks for the pointer. Taking it now.

[Bug go/114454] New: go.test/test/fixedbugs/issue27836.go FAILs with LANG=C

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

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

Bug ID: 114454
   Summary: go.test/test/fixedbugs/issue27836.go FAILs with LANG=C
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---

When running the Go testsuite with LANG=C (or any non-UTF-8 locale, I suppose),
go.test/test/fixedbugs/issue27836.go FAILs:

FAIL: go.test/test/fixedbugs/issue27836.dir/Äfoo.go  -O -I. (test for excess
errors)

Excess errors:
go1: fatal error: cannot open
/vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue27836.dir/Ã<84>foo.go:
No such file or directory
compilation terminated.

FAIL: go.test/test/fixedbugs/issue27836.dir/Ämain.go  -O -I. (test for excess
errors)

Excess errors:
go1: fatal error: cannot open
/vol/gcc/src/hg/master/local/gcc/testsuite/go.test/test/fixedbugs/issue27836.dir/Ã<84>main.go:
No such file or directory
compilation terminated.

It seems the test assumes an UTF-8 locale, but takes no precautions to
guarantee
that.

[Bug c++/114455] New: [C++26] P2748R5 - Disallow binding a returned reference to a temporary

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

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

Bug ID: 114455
   Summary: [C++26] P2748R5 - Disallow binding a returned
reference to a temporary
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c++/114456] New: [C++26] P0609R3 - Attributes for structured bindings

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

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

Bug ID: 114456
   Summary: [C++26] P0609R3 - Attributes for structured bindings
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c++/114457] New: [C++26] P2795R5 - Erroneous behavior for uninitialized reads

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

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

Bug ID: 114457
   Summary: [C++26] P2795R5 - Erroneous behavior for uninitialized
reads
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c++/114458] New: [C++26] P2573R2 - = delete("reason");

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

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

Bug ID: 114458
   Summary: [C++26] P2573R2 - = delete("reason");
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c++/114459] New: [C++26] P2893R3 - Variadic friends

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

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

Bug ID: 114459
   Summary: [C++26]  P2893R3 - Variadic friends
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

See .

[Bug c++/114460] New: [C++26] P3106R1 - Clarifying rules for brace elision in aggregate initialization

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

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

Bug ID: 114460
   Summary: [C++26] P3106R1 - Clarifying rules for brace elision
in aggregate initialization
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

See .

DR for C++98 and up.

[Bug c++/114461] New: [C++26] P3034R1 - Disallow module declarations to be macros

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

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

Bug ID: 114461
   Summary: [C++26] P3034R1 - Disallow module declarations to be
macros
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

See .

DR for C++20 and up.

[Bug c++/114462] New: [C++26] P2809R3 - Trivial infinite loops are not undefined behavior

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

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

Bug ID: 114462
   Summary: [C++26] P2809R3 - Trivial infinite loops are not
undefined behavior
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

See .

DR.

[Bug go/114463] New: go.test/test/fixedbugs/issue4458.go FAILs

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

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

Bug ID: 114463
   Summary: go.test/test/fixedbugs/issue4458.go FAILs
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: i?86-pc-solaris2.11, sparcv9-sun-solaris2.11

The go.test/test/fixedbugs/issue4458.go FAILs on Solaris in a weird way:

FAIL: issue4458.go   -O   (test for errors, line 19)
FAIL: issue4458.go   -O  (test for excess errors)

The issue happens both for a 32-bit-default x86 compiler, generating either 32
or
64-bit-code:

Excess errors:
issue4458.go:19: error: method 'foo' is ambiguous

A 64-bit-default x86 compiler is fine,though.

OTOH on sparc, a 32-bit default compiler is fine while a 64-bit-default
compiler shows the same issue.

[Bug c++/114462] [C++26] P2809R3 - Trivial infinite loops are not undefined behavior

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

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

--- Comment #1 from Richard Biener  ---
Apart from marking via -ffinite-loops GCC considers loops without an exit as
not required to make "forward progress".  That's more than just a constant
controlling expression but should allow optimizing most relevant cases.

[Bug c++/114462] [C++26] P2809R3 - Trivial infinite loops are not undefined behavior

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I know, but I think this will need changes in the C++ FE.
I was asking recently Jason what the "when interpreted as a
constant-expression"
in the paper actually means, whether such expression should be evaluated as
manifestly constant evaluation or not.
If yes, it seems like an incompatible change in a DR, because say
#include 
void
foo ()
{
  while (std::is_constant_evaluated ())
;
}
changing behavior from previous doing nothing to an infinite loop.
If it is not manifestly constant evaluation, still, the FE would need to (at
least for the cases listed in the paper) try to silently constant evaluate the
condition (with
mce_false such that std::is_constant_evaluated () is folded to false in there;
but perhaps only during cp_fold_function?) and if that evaluates to non-zero
replace the condition with true, such that the middle-end would then really
consider it as infinite loop regardless of -ffinite-loops.
Because if one has
constexpr bool
bar ()
{
  return true;
}
void
baz ()
{
  while (bar ())
;
}
we want middle-end to see while (true) ; rather than while (bar ()) ; because
the latter would be under -ffinite-loops decision.

[Bug c++/114462] [C++26] P2809R3 - Trivial infinite loops are not undefined behavior

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

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

--- Comment #3 from Jakub Jelinek  ---
And another case to watch for is:
void
qux ()
{
  while (const bool b = bar ())
;
}

[Bug ada/114424] gnat: Ada.Calendar.Clock crashes on 32bit architectures with 64bit time_t

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

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

--- Comment #9 from Matthias Klose  ---
not sure if that's the right forum here, however:

 - in both Debian and Ubuntu, we're currently doing
   the time_t 64bit transition, for gnat that is
   moving from packages built with gnat-12 (32bit time_t)
   to packages built with gnat-13 (64bit time_t),
   on at least armhf (arm-linux-gnueabihf).

 - packages succeeding to build are adasockets,
   libxmlada, libgmpada, gprbuild.

 - next packages failing to build are: ahven, adacgi with that error
   gprbuild: raised CONSTRAINT_ERROR : a-calend.adb:371 overflow check failed

 - libflorist fails with
   posix-c.ads:876:07: error: size for "suseconds_t" too small, minimum allowed
is 64
posix-c.ads:876:07: error: size for "suseconds_t" too small, minimum allowed is
64
posix-c.ads:876:07: error: size for "suseconds_t" too small, minimum allowed is
64
posix-c.ads:876:07: error: size for "suseconds_t" too small, minimum allowed is
64

   compilation of posix_signals.ads failed
   compilation of posix-timers.adb failed
   compilation of posix_process_primitives.ads failed
   compilation of posix-timers-extensions.adb failed

  which is https://sourceware.org/bugzilla/show_bug.cgi?id=31510

 - unrelated, the libtemplates-parser build is timing out

for complete build logs see (enabling "good")
https://ubuntu-archive-team.ubuntu.com/transitions/html/gnat-13.html

[Bug target/114441] Relocation issues when compiling with -O1,-O2,and -Os

[njuwy at smail dot nju.edu.cn via Gcc-bugs]

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

--- Comment #5 from Yang Wang  ---
(In reply to Xi Ruoyao from comment #4)
> (In reply to Yang Wang from comment #3)
> > (In reply to Andrew Pinski from comment #1)
> > > This is not a GCC bug, 
> > > 
> > > You need to use -mcmodel=large if you have huge statically allocated 
> > > arrays.
> > > 
> > > The default -mcmodel=medium does not support more than 2GB size arrays
> > > 
> > > See
> > >  https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/x86-Options.html#index-
> > > mcmodel_003dlarge-3
> > 
> > Thanks for your reply! Indeed, the compilation was successful when either
> > the -mcmodel=medium or -mcmodel=large was enabled. However, I'm still
> > curious why it can be compiled successfully at the -O3 optimization level
> > when the default -mcmodel=small is enabled? As far as I know, the -O3
> > optimization level is the highest.
> 
> Because the entire `c` function is optimized to empty.  Note that `c` always
> invokes undefined behavior:
> 
> t.cc: In function 'void c()':
> t.cc:10:30: warning: iteration 1 invokes undefined behavior
> [-Waggressive-loop-optimizations]
>10 | a[d][e][f][g][i] = 2;
>   | ~^~~
> t.cc:9:32: note: within this loop
> 9 |   for (size_t i = 0; i < 16; ++i)
>   |  ~~^~~~
> 
> So the compiler is allowed to optimize it into nothing.
> 
> A test case without undefined behavior:
> 
> #include 
> int a[1][1][1][1][1];
> short b[6268435456];
> void c() {
>   a[0][0][0][0][0] = 114514;
> }
> int main() {}
> 
> fails at -O3 too.
> 
> Also note that -O levels are for optimizing the *valid* programs, not for
> debugging the compiler.  It's wrong to report bugs solely because of
> "different behaviors with different -O levels" (without analysing the
> validity of the test case).

Thanks for your reply!I'll pay more attention.

[Bug middle-end/114464] New: [14 regression] ICE when building tdscpp-20240212

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

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

Bug ID: 114464
   Summary: [14 regression] ICE when building tdscpp-20240212
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57808
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57808&action=edit
bcp.cpp.ii.xz

```
$ g++ -c bcp.cpp.ii -O2 -std=gnu++23
/var/tmp/portage/dev-db/tdscpp-20240212/work/tdscpp-20240212/src/bcp.cpp: In
function ‘void tds::bcp_row_data(uint8_t*&, const col_info&, const value&,
std::u16string_view)’:
/var/tmp/portage/dev-db/tdscpp-20240212/work/tdscpp-20240212/src/bcp.cpp:578:10:
error: incompatible types in ‘PHI’ argument 0
  578 | void bcp_row_data(uint8_t*& ptr, const col_info& col, const value&
vv, u16string_view col_name) {
  |  ^~~~
vector(16) unsigned char

vector(16) 

vect_vec_recur_.4107_221 = PHI 
/var/tmp/portage/dev-db/tdscpp-20240212/work/tdscpp-20240212/src/bcp.cpp:578:10:
error: type mismatch in ‘vec_perm_expr’
vector(16) unsigned char
vector(16) unsigned char
vector(16) 
vector(16) ssizetype
_2739 = VEC_PERM_EXPR ;
during GIMPLE pass: vect
/var/tmp/portage/dev-db/tdscpp-20240212/work/tdscpp-20240212/src/bcp.cpp:578:10:
internal compiler error: verify_gimple failed
0x558d86f1abae verify_gimple_in_cfg(function*, bool, bool)
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/tree-cfg.cc:5663
0x558d886683f4 execute_function_todo
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/passes.cc:2088
0x558d886683f4 do_per_function
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/passes.cc:1687
0x558d886683f4 execute_todo
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/passes.cc:2142
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.
```

[Bug libstdc++/114316] assert failure with _GLIBCXX_DEBUG and empty range of singular iterators passed to std:: algorithm

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|14.0|13.3

[Bug tree-optimization/114464] [14 regression] ICE when building tdscpp-20240212

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code,
   ||needs-reduction
   Target Milestone|--- |14.0
 CC||rguenth at gcc dot gnu.org
  Component|middle-end  |tree-optimization

--- Comment #1 from Richard Biener  ---
x86-64?

[Bug tree-optimization/114464] [14 regression] ICE when building tdscpp-20240212

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

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

--- Comment #2 from Sam James  ---
Ah, yes, sorry. Reducing too.

[Bug tree-optimization/114465] New: "x % const1 % const2" should be optimized if const1 % const2 == 0

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

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

Bug ID: 114465
   Summary: "x % const1 % const2" should be optimized if const1 %
const2 == 0
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xry111 at gcc dot gnu.org
  Target Milestone: ---

int test(int x) { return x % 114514 % 1847; }

This should be optimized as-is

int test(int x) { return x % 1847; }

[Bug target/110027] [11/12/13/14 regression] Misaligned vector store on detect_stack_use_after_return

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.5
   Priority|P3  |P2

[Bug tree-optimization/114465] "x % const1 % const2" should be optimized if const1 % const2 == 0

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

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

Xi Ruoyao  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization

[Bug ada/114398] [13/14 regression] Storage_Error with 'Access of primitive function returning limited type

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.3
   Priority|P3  |P4

[Bug c++/57176] copy elision with function arguments passed by value

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2024-03-25

--- Comment #5 from Jonathan Wakely  ---
(In reply to Marc Glisse from comment #2)
> (In reply to comment #1)
> > Unless I'm misunderstanding your suggestion I think that a compiler is not
> > allowed to apply copy-elision here, because that case was explicitly 
> > excluded
> > from 12.8 p31 by
> > 
> > http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1148
> 
> Really? Apart from the fact that no compiler implements it so it probably
> didn't look like a huge sacrifice at the time, it is in my opinion moving in
> the wrong direction (less elision, when we actually need a lot more).

There have been a lot of changes in the area of copy elision in recent
standards (see links below) but the "other than a function parameter" wording
still remains. So I don't think we can make this optimization without a change
to the standard.

What we are allowed (and even required) to do is treat return values as rvalues
more often, and so perform moves instead of copies. Even if we can't elide that
move entirely, it's better than a copy.

Is it worth keeping this open if we're not allowed to make this change?


Guaranteed copy elision:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0135r1.html
Implicitly move from rvalue references in return statements / More implicit
moves:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1825r0.html
Simpler implicit move:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2266r3.html

[Bug c++/59926] Remove temporary move constructor before move assignment

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=57176
 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Jonathan Wakely  ---
(In reply to Patrick Arnoux from comment #2)
> Derived f(Derived d) { return (d) ; }
> Derived g(Derived& d) { Derived e = d ; return (e) ; }
> Derived h(Derived d) { Derived e = d ; return (e) ; }
> 
> 
> Derived r ;
> Derived u ;
> u = f(r) ; // (A) Move Ctor to TmpObj, then Move Assign to u.
> u = g(r) ; // (B) Move Assign to u (No move ctor)
> u = h(r) ; // (C) Move Assign to u
> Derived v = h(r) ; // (D) straight up 'rvo'
> 
> I would have expected case A to behave like B and C and I would ask

I don't think the standard allows that.

The initial copy of 'r' has to happen in the caller's scope, not inside the
function. And so it can't be constructed in the return slot, because the caller
doesn't know that the body of 'f' returns its parameter, rather than returning
some other object.

If the functions are defined inline and your objects don't have silly side
effects like printing messages to standard output for every member function (or
other side effects with observable behaviour that can't be optimized away),
then the compiler _will_ optimize it to more efficient code.


> if case D could eliminate rvo and do a Move Ctor instead, would that
> simplify the code generation.

That's not possible, for the same reason as above. The call to h(r) has to make
a copy in the caller's frame, and that obviously can't be a move because 'r'
can't be modified by calling h(r). Then in the body of h you make another copy,
which can't be changed to a move because the compiler isn't allowed to do that
to arbitrary copies (except in a return statement). If you want it to be a
move, write it as a move:

Derived h(Derived d) { Derived e = std::move(d) ; return (e) ; }

Of course that 'h' function is still unnecessarily inefficient, using 'f' with
RVO does what you want:

Derived w = f(r) ;

0x7ffd118b2cbf Derived copy
0x7ffd118b2cb7 Derived move
0x7ffd118b2cbf Derived dtor

This copies 'r' to initialize the argument 'd' and then moves that directly
into 'w'.

The standard doesn't permit us to do anything different here, so I'm closing
this.

[Bug middle-end/111151] [12/13/14 Regression] Wrong code at -O0 on x86_64-pc-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2

[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2

[Bug c++/58055] [meta-bug] RVO / NRVO improvements

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

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

Bug 57176 Summary: copy elision with function arguments passed by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57176

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

[Bug c++/57176] copy elision with function arguments passed by value

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

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

Marc Glisse  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Marc Glisse  ---
(In reply to Jonathan Wakely from comment #5)
> Is it worth keeping this open if we're not allowed to make this change?

Probably not since wg21 explicitly added text to forbid this optimization. It
belongs in some non-existent wg21 feature request list...

[Bug driver/114447] -fstack-protector-explicit ignored

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

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

Matthias Klose  changed:

   What|Removed |Added

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

--- Comment #3 from Matthias Klose  ---
committed for the distro packages. it will take a while until these reach the
archives. closing the issue here, not an upstream issue.

[Bug target/112470] [11/12/13/14 regression] [AARCH64] stack-protector vulnerability fixing solution impact code size and performance

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2

--- Comment #15 from Richard Biener  ---
P2 since it's a minor missed-optimization and possibly an unwanted optimization
even.  "importance" is priority of the reporter, so I'm leaving that critical.

[Bug c++/114303] [11/12/13/14 Regression] ICE with constexpr if and accessing captures across nested generic lambdas

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2

--- Comment #4 from Richard Biener  ---
P2, we releases with this bug.

[Bug c++/114377] [13/14 Regression] GCC crashes on an example of CTAD for alias templates

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2
Version|unknown |13.2.1

--- Comment #2 from Richard Biener  ---
P2, we released with this bug.

[Bug target/114466] New: mips: ICE during RTL pass: zero_call_used_regs

[rene at exactcode dot de via Gcc-bugs]

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

Bug ID: 114466
   Summary: mips: ICE during RTL pass: zero_call_used_regs
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rene at exactcode dot de
  Target Milestone: ---

Compiling the latest openssh-9.7p1 (and openssh-9.6p1) for mips-linux or
mips64n32 linux causes and internal compiler error: Segmentation fault:

uring RTL pass: zero_call_used_regs
misc.c: In function 'bandwidth_limit':
misc.c:1807:1: internal compiler error: Segmentation fault
 1807 | }
  | ^
0x128fff5 internal_error(char const*, ...)
???:0
0x863ad0 emit_move_insn(rtx_def*, rtx_def*)
???:0
0xac9967 default_zero_call_used_regs(HARD_REG_SET)
???: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.

at least 14-20240324 and 13-20240224 are affected. I would expect at leaste
13.2 as well.

[Bug fortran/114467] New: f951: internal compiler error: Segmentation fault

[thomas.kalscheuer at geo dot uu.se via Gcc-bugs]

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

Bug ID: 114467
   Summary: f951: internal compiler error: Segmentation fault
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.kalscheuer at geo dot uu.se
  Target Milestone: ---

I use a system with dual Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz cpus, CentOS
Linux 7 and gfortran v. 13.2.0

According to gcc -v, gcc was configured with the options "Configured with:
../gcc-13.2.0/configure --enable-languages=c,c++,fortran"

By compiling a fortran code with 
gfortran -O2 -march=native -mtune=native -malign-data=cacheline
-finline-functions -std=f2018 -ffree-form -ffree-line-length-none -pedantic
-Wsurprising -Wopenmp-simd -Wvector-operation-performance -ftree-vectorize
-ftree-vectorizer-verbose=2 -fopt-info -fopenmp -I/usr/include
-I/usr/include/hdf5/serial/ -freport-bug -save-temps -x f95-cpp-input -DRMT -c
code.f90 -o code.o
I get the following error message:
f951: internal compiler error: Segmentation fault
0xd29d7f crash_signal
../../gcc-13.2.0/gcc/toplev.cc:314
0x7c2a65 gfc_expression_rank(gfc_expr*)
../../gcc-13.2.0/gcc/fortran/resolve.cc:5643
0x7c2c14 gfc_op_rank_conformable(gfc_expr*, gfc_expr*)
../../gcc-13.2.0/gcc/fortran/resolve.cc:5676
0x709e9c eval_intrinsic
../../gcc-13.2.0/gcc/fortran/arith.cc:1674
0x781cfc match_level_4
../../gcc-13.2.0/gcc/fortran/matchexp.cc:636
0x781cfc match_and_operand
../../gcc-13.2.0/gcc/fortran/matchexp.cc:693
0x781d66 match_or_operand
../../gcc-13.2.0/gcc/fortran/matchexp.cc:722
0x781e76 match_equiv_operand
../../gcc-13.2.0/gcc/fortran/matchexp.cc:765
0x781f88 match_level_5
../../gcc-13.2.0/gcc/fortran/matchexp.cc:811
0x7810e4 gfc_match_expr(gfc_expr**)
../../gcc-13.2.0/gcc/fortran/matchexp.cc:870
0x78132b match_primary
../../gcc-13.2.0/gcc/fortran/matchexp.cc:165
0x78132b match_level_1
../../gcc-13.2.0/gcc/fortran/matchexp.cc:211
0x78132b match_mult_operand
../../gcc-13.2.0/gcc/fortran/matchexp.cc:267
0x7815c8 match_add_operand
../../gcc-13.2.0/gcc/fortran/matchexp.cc:356
0x78189c match_level_2
../../gcc-13.2.0/gcc/fortran/matchexp.cc:480
0x781a56 match_level_3
../../gcc-13.2.0/gcc/fortran/matchexp.cc:551
0x781b90 match_level_4
../../gcc-13.2.0/gcc/fortran/matchexp.cc:599
0x781b90 match_and_operand
../../gcc-13.2.0/gcc/fortran/matchexp.cc:693
0x781d66 match_or_operand
../../gcc-13.2.0/gcc/fortran/matchexp.cc:722
0x781e76 match_equiv_operand
../../gcc-13.2.0/gcc/fortran/matchexp.cc:765
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
make: *** [code.o] Error 1

Compilation with
gfortran -g -std=f2018 -ffree-form -ffree-line-length-none -pedantic -Wall
-I/usr/include -I/usr/include/hdf5/serial/ -freport-bug -save-temps -x
f95-cpp-input -DRMT -c code.f90 -o code.o
leads to the same error message.

Note, that inclusion of the -save-temps option has not led to any *.* file
being generated by the compiler.

[Bug target/114466] mips: ICE during RTL pass: zero_call_used_regs

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Sam James  ---
Dupe.

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

[Bug target/110934] m68k: ICE with -fzero-call-used-regs=all compiling openssh 9.3p2

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

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

Sam James  changed:

   What|Removed |Added

 CC||rene at exactcode dot de

--- Comment #16 from Sam James  ---
*** Bug 114466 has been marked as a duplicate of this bug. ***

[Bug target/114466] mips: ICE during RTL pass: zero_call_used_regs

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

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

--- Comment #2 from Sam James  ---
Also:
>Please submit a full bug report, with preprocessed source (by using 
>-freport-bug).

But no need here.

[Bug target/114466] mips: ICE during RTL pass: zero_call_used_regs

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #3 from Sam James  ---
Oh, no, it isn't. Yeah, preprocessed source please.

[Bug target/112980] 64-bit powerpc ELFv2 does not allow nops to be generated before function global entry point

[naveen at kernel dot org via Gcc-bugs]

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

--- Comment #7 from Naveen N Rao  ---
I have been looking at an alternative approach to see if we can move the entire
function patching sequence out of line. However, the approach I am considering
is very specific to the linux kernel, and I don't see it applying for userspace
in a generic way. As such, I think there is value in addressing the current
limitation with -fpatchable-function-entry one way or another.

[Bug c/114468] New: unixbench compilation performance results vary with different gcc compilers

[jiangchuanganghw at outlook dot com via Gcc-bugs]

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

Bug ID: 114468
   Summary: unixbench compilation performance results vary with
different gcc compilers
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jiangchuanganghw at outlook dot com
  Target Milestone: ---

We used Unixbench to compare gcc 10.3.0 with gcc8.5 on an intel Sapphire Rapids
CPU and found that the performance of the dhry2reg test project compiled with
gcc 10.3.0 deteriorated by about 10%. We found that this commit affected
performance, and after rolling back the changes in that patch, performance was
restored.
https://github.com/gcc-mirror/gcc/commit/3133bed5d0327e8a9cd0a601b7ecdb9de4fc825d

We expect to find the cause of this result.Looking forward to your help.

[Bug pch/114381] (Sporadic) crash generating x86_64-pc-cygwin/bits/extc++.h.gch/O2g.gch

[roland.mainz at nrubsig dot org via Gcc-bugs]

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

--- Comment #2 from Roland Mainz  ---
Same issue happens on Cygwin 3.6.x

[Bug lto/114337] LTO symbol table doesn't include builtin functions

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #5 from Alexander Monakov  ---
Gold handles such rescanning correctly. BFD ld regressed in 2.27, this
bugreport contains references to previous discussions about rescanning:
https://sourceware.org/bugzilla/show_bug.cgi?id=23935

(in the above bug there's a patch for ld.bfd that seemingly went nowhere)

[Bug tree-optimization/114469] New: gcc.dg/torture/bitint-64.c failure with -O2 -flto -std=c23 -fwrapv

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

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

Bug ID: 114469
   Summary: gcc.dg/torture/bitint-64.c failure with -O2 -flto
-std=c23 -fwrapv
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

This test fails with
make check-gcc GCC_TEST_RUN_EXPENSIVE=1
RUNTESTFLAGS="dg-torture.exp=bitint-64.c"
FAIL: gcc.dg/torture/bitint-64.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
The question is if _Atomic _BitInt(5) should be in memory always sign extended,
or as the ABI says the upper bits are unspecified.
If the former, then I'd say the problem is on the
/* Strip inner integral conversions that do not change precision or size, or
   zero-extend while keeping the same size (for bool-to-char).  */
(simplify
  (view_convert (convert@0 @1))
  (if ((INTEGRAL_TYPE_P (TREE_TYPE (@0)) || POINTER_TYPE_P (TREE_TYPE (@0)))
   && (INTEGRAL_TYPE_P (TREE_TYPE (@1)) || POINTER_TYPE_P (TREE_TYPE (@1)))
   && TYPE_SIZE (TREE_TYPE (@0)) == TYPE_SIZE (TREE_TYPE (@1))
   && (TYPE_PRECISION (TREE_TYPE (@0)) == TYPE_PRECISION (TREE_TYPE (@1))
   || (TYPE_PRECISION (TREE_TYPE (@0)) > TYPE_PRECISION (TREE_TYPE
(@1))
   && TYPE_UNSIGNED (TREE_TYPE (@1)
   (view_convert @1)))
match.pd simplification which transforms
  _5 = (unsigned _BitInt(5)) _4;
  _7 = (unsigned _BitInt(5)) e.0_1;
  _8 = _5 + _7;
  _9 = (_BitInt(5)) _8;
  _10 = VIEW_CONVERT_EXPR(_9);
to just
  _5 = (unsigned _BitInt(5)) _4;
  _7 = (unsigned _BitInt(5)) e.0_1;
  _8 = _5 + _7;
  _10 = VIEW_CONVERT_EXPR(_8);
so it is no longer sign extended in the unsigned char.
If the upper bits are undefined as the psABI on x86 says, then perhaps the
VIEW_CONVERT_EXPR emitted by c-common.cc (resolve_overloaded_builtin) is the
culprit:
  _13 = __atomic_load_1 (&b, 5);
  _14 = VIEW_CONVERT_EXPR<_BitInt(5)>(_13);
and we should change that
/* Cast function result from I{1,2,4,8,16} to the required type. 
*/
result = build1 (VIEW_CONVERT_EXPR, TREE_TYPE (new_return),
result);
to something like if (INTEGRAL_TYPE_P (TREE_TYPE (new_return))IINTEGRAL_TYPE_P
(TREE_TYPE (new_return))NTEGRAL_TYPE_P (TREE_TYPE (new_return)))
if (INTEGRAL_TYPE_P (TREE_TYPE (new_return)))
  result = fold_convert (TREE_TYPE (new_return), result);
else
  result = build1 (VIEW_CONVERT_EXPR, TREE_TYPE (new_return),
result);
Joseph, thoughts on this?

[Bug target/114466] mips: ICE during RTL pass: zero_call_used_regs

[rene at exactcode dot de via Gcc-bugs]

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

--- Comment #4 from René Rebe  ---
Created attachment 57809
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57809&action=edit
preprocessed source from -freport-bug

preprocessed source from -freport-bug

[Bug target/114468] unixbench compilation performance results vary with different gcc compilers

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

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

--- Comment #1 from Andrew Pinski  ---
Gcc 10 is no longer supported. Can you test a newer gcc? Register allocation is
always improving between versions so this might be already fixed.

[Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265

[bouanto at zoho dot com via Gcc-bugs]

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

--- Comment #9 from Antoni  ---
Created attachment 57810
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57810&action=edit
Patch to fix the issue

I was unable to create a reproducer in C for the tests.
It seems the problem was actually in libgccjit because it was not setting
BLOCK_SUPERCONTEXT.

I'm not sure how best to test it, though.
The only idea I have would be to attempt to create a libgccjit test that adds
-fanalyzer to its arguments.
Do you have a better idea?

[Bug c++/114439] [14 Regression] icu4c-73.2 build failure: invalid initializer for array member with initialization of array of struct containing arrays since r14-9622

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug target/114415] [13/14 Regression] wrong code with -Oz -fno-dce -fno-forward-propagate -flive-range-shrinkage -fweb since r13-1826

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|wrong code with -Oz |[13/14 Regression] wrong
   |-fno-dce|code with -Oz -fno-dce
   |-fno-forward-propagate  |-fno-forward-propagate
   |-flive-range-shrinkage  |-flive-range-shrinkage
   |-fweb   |-fweb since r13-1826
   Target Milestone|--- |13.3
   Last reconfirmed||2024-03-25
 Status|UNCONFIRMED |NEW
   Keywords|needs-bisection |
 Ever confirmed|0   |1
 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Started with r13-1826-g16aafa3194d4851a07cc204f56a5f0618f77e5d7

[Bug target/114468] unixbench compilation performance results vary with different gcc compilers

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2024-03-25

[Bug target/114466] mips: ICE during RTL pass: zero_call_used_regs

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #5 from Xi Ruoyao  ---
-fzero-call-used-regs=all is just completely broken on mips as at now.  Please
don't use it for mips.

[Bug sanitizer/71962] error: ‘((& x) != 0u)’ is not a constant expression

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

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

Barry Revzin  changed:

   What|Removed |Added

 CC||barry.revzin at gmail dot com

--- Comment #12 from Barry Revzin  ---
Similar failure:

struct A {
void f();
};

int main() {
constexpr auto pmf = &A::f;
static_assert(pmf != nullptr); // error with UBSAN only
}

This surfaces from attempting to implement function_ref
(https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p0792r14.html) which
has a constructor that takes the callable as a non-type template parameter and
static_asserts that it's not a null pointer.

Which apparently doesn't work with UBSAN.

[Bug analyzer/113314] [14 Regression] -Wanalyzer-infinite-loop false positive seen on haproxy's fd.c

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

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

--- Comment #2 from David Malcolm  ---
(In reply to David Malcolm from comment #1)

[...]

> 70redo_next:
> 71  next = fdtab[fd].update.next;
> 72  if (next > -2)
> 73goto done;
> 74  if (next == -2)
> 75goto redo_next;
> 
> does look like an infinite loop when next == 2.

Presumably I meant -2 here.

[Bug fortran/114470] New: [OOP] Defined, type-bound assignment(=) of component not called within class, allocatable parent

[Linxwiler_Benjamin at bah dot com via Gcc-bugs]

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

Bug ID: 114470
   Summary: [OOP] Defined, type-bound assignment(=) of component
not called within class, allocatable parent
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Linxwiler_Benjamin at bah dot com
  Target Milestone: ---

The following code prints
   42
   42
with gfortran and
   42
7
with ifort (2021.11.1 20231117) and ifx (2024.0.2 20231213).

Per my reading of the relevant portions of the standard (given below), the
latter is the correct behavior.

module myMod
   implicit none
   type component
  integer :: i = 42
  contains
  generic   :: assignment(=) => copy
  procedure :: copy
   end type
   type container
  type(component) :: foo
   end type
   contains
   subroutine copy(lhs,rhs)
  class(component), intent(out) :: lhs
  class(component), intent(in)  :: rhs
  lhs%i = 7
   end subroutine
end module

program main
   use myMod
   implicit none
   type(container)   :: right
!   type(container),  allocatable :: left
   class(container), allocatable :: left
   print *, right%foo%i
   left = right
   print *, left%foo%i
end program

If "left" in the program is made "type, allocatable" instead of "class,
allocatable", then the program prints
   42
7
as expected.

The relevant portions of the Fortran 2008 standard are found in "7.2.1.3
Interpretation of intrinsic assignments" and are as follows:
 - Per paragraph 3 (excerpt):
   "If the variable is or becomes an unallocated allocatable variable, it is 
   then allocated with
  - if the variable is polymorphic, the same dynamic type as expr..."
 - Per paragraph 13 (excerpt):
   "An intrinsic assignment where the variable is of derived type is performed 
   as if each component of the variable were assigned from the corresponding 
   component of expr using... defined assignment for each nonpointer 
   nonallocatable conponent of a type that has a type-bound defined assignment 
   consistent with the component..."
Paragraph 3 pertains to assignment of "left" while paragraph 13 explains the
assignment of component "foo".

This issue is related to the following bugs, with the following similarities
and differences:
 - For PR46897 [solved], both issues involve a defined, type-bound assignment
on 
   a component that is not being called. The difference is with the container 
   holding the object; it is "class, allocatable" in this new issue.
 - For PR57696 [unsolved], both issues involved a defined, type-bound
assignment
   on a component that is not being called. The difference is that the
component 
   is "type, allocatable" while the container holding it is "type" in the 
   previous issue, and in the new issue, the component is "type" while the 
   container holding it is "class, allocatable".
 - For PR57697 [solved], both issues are the same except that in the former the 
   container holding the component is "type, allocatable" while in the latter
it 
   is "class, allocatable".

[Bug target/114466] mips: ICE during RTL pass: zero_call_used_regs

[rene at exactcode dot de via Gcc-bugs]

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

--- Comment #6 from René Rebe  ---
ok - good to know. I guess someone should tell the openssh developers and maybe
gcc should error out with a warning. Actually if gcc would error out it would
signal openssl's configure not to automatically try to use it, ...

[Bug target/114415] [13/14 Regression] wrong code with -Oz -fno-dce -fno-forward-propagate -flive-range-shrinkage -fweb since r13-1826

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||sayle at gcc dot gnu.org,
   ||uros at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Seems it is lr_shrinkage pass where things go wrong.
In bar0, all the 3 calls the function makes have 2 64-byte arguments (plus
64-byte return passed by hidden reference).  -Oz apparently uses
-mno-accumulate-outgoing-args, allocates some stack and then have (at least
initially) before each of the 3 calls two spots which decrement %rsp by 64 and
after each call one spot which increments %rsp by 128.
csa merges the first %rsp -= 64 with the previous much larger %rsp decrement
and in some cases the %rsp += 128 with following %rsp -= 64.
The function sets %r12 to be the REG_ARGS_SIZE 64 %rsp level and %rbx to be the
REG_ARGS_SIZE 128 %rsp level, i.e. %rbx = %r12 - 64.
In asmcons pass, we still have before the call to bar1 %rsp -= 64; rep_movsi
(fills in the second argument); %rsp -= 64; rep_movsi (fills in the first
argument).
But then lr_shrinkage pass moves both the stack decrements after all the
rep_movsi calls, so we then have:
(insn 60 71 66 2 (parallel [
(set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int -64 [0xffc0])))
(clobber (reg:CC 17 flags))
]) "pr114415.c":27:8 272 {*adddi_1}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_ARGS_SIZE (const_int 64 [0x40])
(nil
(insn 66 60 72 2 (parallel [
(set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 129)
(const_int -64 [0xffc0])))
(clobber (reg:CC 17 flags))
]) "pr114415.c":27:8 272 {*adddi_1}
 (expr_list:REG_DEAD (reg/f:DI 129)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_ARGS_SIZE (const_int 128 [0x80])
(nil)
and just set of %rdi and call to bar1.

Now, as x86-64 has red zone, this in theory could still work fine (dunno if
backend is supposed to have some barriers which prevent moving the rep movsl
insns across it, unfortunately the fact that it uses some %rsp based address is
not visible directly in the insn due to CSE), but then comes peephole2
;; With -Oz, transform mov $imm,reg to the shorter push $imm; pop reg.
and converts the (set (reg:DI %rcx) (const_int 16)) insns to push/pop pair,
which when
the stack pointer is higher than it should have been causes clobbering of the
value.

[Bug target/114415] [13/14 Regression] wrong code with -Oz -fno-dce -fno-forward-propagate -flive-range-shrinkage -fweb since r13-1826

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

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

--- Comment #3 from Jakub Jelinek  ---
BTW, with additional -mno-red-zone there is still movement of these insns,
though they   
leaq128(%rbx), %rsp   ! level 0
movq%r13, %rsi
movl%r10d, %edx
rep stosl
andq$0, -424(%rbp)
movq%r12, %rdi
leaq-112(%rbp), %rax
movq$1, -432(%rbp)
pushq   $16
popq%rcx
rep movsl ! fill in second argument - at %rsp - 64
pushq   $16   ! again overwrite last 8 bytes of the
second argument
movq%rbx, %rdi
leaq-240(%rbp), %rsi
popq%rcx
movq%r12, %rsp! level 64
movq%rbx, %rsp! level 128
rep movsl ! fill in first argument
xchgq   %rax, %rdi
callbar1

Ah, and it is sched2 pass which moves the movq %r12, %rsp and movq %rbx, %rsp
instructions before the second rep movsl.

[Bug tree-optimization/114471] New: [14 regression] ICE when building liblc3-1.0.4

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

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

Bug ID: 114471
   Summary: [14 regression] ICE when building liblc3-1.0.4
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57811
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57811&action=edit
spec.c.i

Initially reported downstream in Gentoo by tdr.

```
$ gcc-14 /tmp/foo.c -c -O2 -fno-vect-cost-model -march=x86-64-v4
/tmp/foo.c: In function ‘quantize’:
/tmp/foo.c:4:6: error: type mismatch in binary expression
4 | void quantize(int i, short x1) {
  |  ^~~~
vector(2) 

vector(2) 

vector(2) 

mask_patt_47.14_40 = mask__2.11_44 & mask_patt_48.13_41;
during GIMPLE pass: slp
/tmp/foo.c:4:6: internal compiler error: verify_gimple failed
0x55ab954d6b85 verify_gimple_in_cfg(function*, bool, bool)
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/tree-cfg.cc:5663
0x55ab96a54818 execute_function_todo
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/passes.cc:2088
0x55ab96a54818 do_per_function
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/passes.cc:1687
0x55ab96a54818 execute_todo
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/passes.cc:2142
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.
```

[Bug c++/114460] [C++26] P3106R1 - Clarifying rules for brace elision in aggregate initialization

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2024-03-25
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Marek Polacek  ---
Confirmed.  I'm interested.

[Bug c++/114455] [C++26] P2748R5 - Disallow binding a returned reference to a temporary

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2024-03-25

--- Comment #1 from Marek Polacek  ---
Confirmed.  I'm interested.

[Bug tree-optimization/114471] [14 regression] ICE when building liblc3-1.0.4 with -fno-vect-cost-model -march=x86-64-v4

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

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

--- Comment #1 from Sam James  ---
The original failed with:
```
../liblc3-1.0.4/src/spec.c: In function ‘quantize’:
../liblc3-1.0.4/src/spec.c:210:21: error: type mismatch in binary expression
  210 | LC3_HOT static void quantize(enum lc3_dt dt, enum lc3_srate sr,
  | ^~~~
vector(2) 

vector(2) 

vector(2) 

mask_patt_142.112_162 = mask__23.109_158 & mask_patt_141.111_161;
during GIMPLE pass: vect
../liblc3-1.0.4/src/spec.c:210:21: internal compiler error: verify_gimple
failed
0x559439cc2712 verify_gimple_in_cfg(function*, bool, bool)
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240324/gcc-14-20240324/gcc/tree-cfg.cc:5663
0x559439ad9a28 execute_function_todo
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240324/gcc-14-20240324/gcc/passes.cc:2088
0x559439ad9c8b do_per_function
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240324/gcc-14-20240324/gcc/passes.cc:1687
0x559439ad9c8b execute_todo
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240324/gcc-14-20240324/gcc/passes.cc:2142
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.
ninja: build stopped: subcommand failed.
```

i.e. vect, not slp.

[Bug tree-optimization/114471] [14 regression] ICE when building liblc3-1.0.4 with -fno-vect-cost-model -march=x86-64-v4

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

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

--- Comment #2 from Sam James  ---
Created attachment 57812
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57812&action=edit
spec.i.orig.xz

[Bug c++/114456] [C++26] P0609R3 - Attributes for structured bindings

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

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

--- Comment #1 from Jakub Jelinek  ---
I'll probably take this for stage1.

[Bug c++/114458] [C++26] P2573R2 - = delete("reason");

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

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

--- Comment #1 from Jakub Jelinek  ---
Considering taking this for stage1 as well.

[Bug c++/114456] [C++26] P0609R3 - Attributes for structured bindings

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-03-25

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

[Bug c++/114457] [C++26] P2795R5 - Erroneous behavior for uninitialized reads

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-03-25

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

[Bug c++/114462] [C++26] P2809R3 - Trivial infinite loops are not undefined behavior

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

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

--- Comment #4 from Jakub Jelinek  ---
Ah, if there is a declaration in the condition, then it is not a valid trivial
empty iteration statement.

Anyway, I'd say cp_fold should for WHILE_STMT, DO_STMT and FOR_STMT if the body
is
a STATEMENT_LIST with no statements at all or an empty statement (do we have
predicate for NOP_EXPR to void_type_node of integer_zero_node?) and in case of
FOR_STMT empty increment expression argument try to evaluate the condition as
mce_false constant expression and if it evaluates to constant non-zero, replace
the condition with boolean_true_node.

[Bug c++/114462] [C++26] P2809R3 - Trivial infinite loops are not undefined behavior

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

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

--- Comment #5 from Jakub Jelinek  ---
constexpr bool foo () { return true; }
volatile int v;

void
bar (int x)
{
  switch (x)
{
case 0:
  while (foo ()) ;
  break;
case 1:
  while (foo ()) {}
  break;
case 2:
  do ; while (foo ());
  break;
case 3:
  do {} while (foo ());
  break;
case 4:
  do {} while (foo ());
  break;
case 5:
  for (v = 42; foo (); ) ;
  break;
case 6:
  for (v = 42; foo (); ) {}
  break;
case 7:
  for (int w = 42; foo (); ) ;
  break;
case 8:
  for (int w = 42; foo (); ) {}
  break;
default:
  break;
}
}

[Bug tree-optimization/114471] [14 regression] ICE when building liblc3-1.0.4 with -fno-vect-cost-model -march=x86-64-v4

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

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

--- Comment #3 from Sam James  ---
float quantize_x_1, quantize_x_0;
short *quantize_xq;
short quantize_x0;
void quantize() {
  short x1 = quantize_xq[0] =
  quantize_x0 + ((quantize_x0 > 0) & (quantize_x_0 < 0));
  quantize_xq[1] = 1 + ((x1 > 0) & (quantize_x_1 < 0));
}

[Bug c++/114457] [C++26] P2795R5 - Erroneous behavior for uninitialized reads

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
This might require both gimple and rtl changes.
Well

[Bug c++/114462] [C++26] P2809R3 - Trivial infinite loops are not undefined behavior

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-03-25
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #6 from Andrew Pinski  ---
.

[Bug c++/114458] [C++26] P2573R2 - = delete("reason");

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-03-25
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

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

[Bug c++/114459] [C++26] P2893R3 - Variadic friends

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-03-25
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

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

[Bug c++/114461] [C++26] P3034R1 - Disallow module declarations to be macros

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

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

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

[Bug c++/114461] [C++26] P3034R1 - Disallow module declarations to be macros

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-03-25
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug tree-optimization/114465] "x % const1 % const2" should be optimized if const1 % const2 == 0

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

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

--- Comment #1 from Joseph S. Myers  ---
Note that transforming x % 1 % -1 to x % -1 wouldn't strictly be valid (because
of undefined behavior from INT_MIN % -1), though hopefully cases with constant
1 or -1 get optimized to 0 anyway and the undefined behavior is only a problem
with a -1 that's not a constant.

[Bug tree-optimization/114469] gcc.dg/torture/bitint-64.c failure with -O2 -flto -std=c23 -fwrapv

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

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

--- Comment #1 from Joseph S. Myers  ---
I'd expect _Atomic _BitInt(5) to follow the same ABI (regarding upper bits
being defined or not) as plain _BitInt(5), and any simplification needs to deal
with that.

(In principle for atomics with _BitInt with padding bits there are the same
concerns as for any types with padding bits - any compare-and-exchange loop
needs to succeed eventually when the underlying memory isn't being modified,
rather than failing in comparison of padding bits that might not have been
consistently loaded / preserved. My guess is this is unlikely to be a concern
in practice for _BitInt the way it is e.g. for x86 long double where the
padding bits only exist in memory and not in registers.)

[Bug target/88309] ICE: Floating point exception (in is_miss_rate_acceptable), target assigning alignent of 4 bits(!) to vector

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

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

--- Comment #2 from Andrew Pinski  ---
Note I scanned the sources of the rs6000 backend and I don't see where `user
align:4` would be happening. I might try to debug this later this week.