[Bug preprocessor/103902] GCC requires a space between string-literal and identifier in a literal-operator-id where the identifier is not in basic character set

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

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

Lewis Hyatt  changed:

   What|Removed |Added

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

--- Comment #7 from Lewis Hyatt  ---
Fixed for GCC 14.

[Bug preprocessor/103902] GCC requires a space between string-literal and identifier in a literal-operator-id where the identifier is not in basic character set

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Lewis Hyatt :

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

commit r14-2629-g1d3e4f4e2d19c3394dc018118a78c1f4b59cb5c2
Author: Lewis Hyatt 
Date:   Tue Jul 18 17:16:08 2023 -0400

libcpp: Handle extended characters in user-defined literal suffix
[PR103902]

The PR complains that we do not handle UTF-8 in the suffix for a
user-defined
literal, such as:

bool operator ""_Ï (unsigned long long);

In fact we don't handle any extended identifier characters there, whether
UTF-8, UCNs, or the $ sign. We do handle it fine if the optional space
after
the "" tokens is included, since then the identifier is lexed in the
"normal" way as its own token. But when it is lexed as part of the string
token, this is handled in lex_string() with a one-off loop that is not
aware
of extended characters.

This patch fixes it by adding a new function scan_cur_identifier() that can
be used to lex an identifier while in the middle of lexing another token.

BTW, the other place that has been mis-lexing identifiers is
lex_identifier_intern(), which is used to implement #pragma push_macro
and #pragma pop_macro. This does not support extended characters either.
I will add that in a subsequent patch, because it can't directly reuse the
new function, but rather needs to lex from a string instead of a
cpp_buffer.

With scan_cur_identifier(), we do also correctly warn about bidi and
normalization issues in the extended identifiers comprising the suffix.

libcpp/ChangeLog:

PR preprocessor/103902
* lex.cc (identifier_diagnostics_on_lex): New function refactoring
some common code.
(lex_identifier_intern): Use the new function.
(lex_identifier): Don't run identifier diagnostics here, rather let
the call site do it when needed.
(_cpp_lex_direct): Adjust the call sites of lex_identifier ()
acccordingly.
(struct scan_id_result): New struct.
(scan_cur_identifier): New function.
(create_literal2): New function.
(lit_accum::create_literal2): New function.
(is_macro): Folded into new function...
(maybe_ignore_udl_macro_suffix): ...here.
(is_macro_not_literal_suffix): Folded likewise.
(lex_raw_string): Handle UTF-8 in UDL suffix via
scan_cur_identifier ().
(lex_string): Likewise.

gcc/testsuite/ChangeLog:

PR preprocessor/103902
* g++.dg/cpp0x/udlit-extended-id-1.C: New test.
* g++.dg/cpp0x/udlit-extended-id-2.C: New test.
* g++.dg/cpp0x/udlit-extended-id-3.C: New test.
* g++.dg/cpp0x/udlit-extended-id-4.C: New test.

[Bug target/106460] internal compiler error: output_operand: invalid expression as operand on -O1

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

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

Jiu Fu Guo  changed:

   What|Removed |Added

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

--- Comment #3 from Jiu Fu Guo  ---
Fixed in trunk.

[Bug target/110625] [AArch64] Vect: SLP fails to vectorize a loop as the reduction_latency calculated by new costs is too large

[hliu at amperecomputing dot com via Gcc-bugs]

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

--- Comment #6 from Hao Liu  ---
Thanks for the confirmation about the reduction latency.  I'll create a simple
patch to fix this.

> Discounting the loads, we do have 15 general operations.

That's true, and there are indeed 8 general operations for scalar loop.  As the
count_ops() is accurate, it seems maybe the Cost of Vector Body is too large
(Vector inside of loop cost: 51):

*k_48 4 times vec_perm costs 12 in body
*k_48 1 times unaligned_load (misalign -1) costs 4 in body
_5->m1 1 times vec_perm costs 3 in body
_5->m4 1 times unaligned_load (misalign -1) costs 4 in body
(int) _24 2 times vec_promote_demote costs 4 in body
(double) _25 4 times vec_promote_demote costs 8 in body
_2 * _26 4 times vector_stmt costs 8 in body

If it is small enough, even the vect-body cost is increased according to the
issue-info, SLP is still profitable.  I'm not quite familiar with this part and
it may affect all aarch64 targets, so I think it's hard to fix by me.  It would
be great if you will look at how to fix this.

[Bug c++/102724] ICE in genericize_spaceship, at cp/method.c:1089

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-07-19

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

[Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-July/62
   ||4847.html

--- Comment #9 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624847.html

[Bug target/109504] [12/13/14 Regression] Compilation fails with pragma GCC target sse4.1 and immintrin.h

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

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

commit r14-2628-g9a19fa8b616f83474c35cc5b34a3865073ced829
Author: liuhongt 
Date:   Tue Apr 18 14:53:04 2023 +0800

Support type _Float16/__bf16 independent of SSE2.

Enable _Float16 and __bf16 all the time but issue errors when the
types are used in conversion, unary operation, binary operation,
parameter passing or value return when TARGET_SSE2 is not available.

Also undef macros which are used by libgcc/libstdc++ to check the
backend support of the _Float16/__bf16 types when TARGET_SSE2 is not
available.

gcc/ChangeLog:

PR target/109504
* config/i386/i386-builtins.cc
(ix86_register_float16_builtin_type): Remove TARGET_SSE2.
(ix86_register_bf16_builtin_type): Ditto.
* config/i386/i386-c.cc (ix86_target_macros): When TARGET_SSE2
isn't available, undef the macros which are used to check the
backend support of the _Float16/__bf16 types when building
libstdc++ and libgcc.
* config/i386/i386.cc (construct_container): Issue errors for
HFmode/BFmode when TARGET_SSE2 is not available.
(function_value_32): Ditto.
(ix86_scalar_mode_supported_p): Remove TARGET_SSE2 for
HFmode/BFmode.
(ix86_libgcc_floating_mode_supported_p): Ditto.
(ix86_emit_support_tinfos): Adjust codes.
(ix86_invalid_conversion): Return diagnostic message string
when there's conversion from/to BF/HFmode w/o TARGET_SSE2.
(ix86_invalid_unary_op): New function.
(ix86_invalid_binary_op): Ditto.
(TARGET_INVALID_UNARY_OP): Define.
(TARGET_INVALID_BINARY_OP): Define.
* config/i386/immintrin.h [__SSE2__]: Remove for fp16/bf16
related instrinsics header files.
* config/i386/i386.h (VALID_SSE2_TYPE_MODE): New macro.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr109504.c: New test.
* gcc.target/i386/sse2-bfloat16-1.c: Adjust error info.
* gcc.target/i386/sse2-float16-1.c: Ditto.
* gcc.target/i386/sse2-float16-4.c: New test.
* gcc.target/i386/sse2-float16-5.c: New test.
* g++.target/i386/float16-1.C: Adjust error info.

libgcc/ChangeLog:

* config/i386/t-softfp: Add -msse2 to libbid HFtype related
files.

[Bug c/110728] should __attribute__((cleanup())) callback get invoked for indirect edges of asm goto

[rjmccall at gmail dot com via Gcc-bugs]

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

--- Comment #5 from John McCall  ---
> If this gets changed in GCC, I'd be happy to modify clang to match that 
> updated behavior.

Policy-wise, I don't think clang would accept a patch making this UB
(effectively what not calling the destructor/cleanup means) instead of
ill-formed unless a standards body forced us to.  Not calling the
destructor/cleanup seems like clearly undesirable behavior, and if we can
define that away in the compiler with relative ease, we should.

[Bug c/44677] Warn for variables incremented but not used (+=, ++)

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

Vincent Lefèvre  changed:

   What|Removed |Added

 CC||vincent-gcc at vinc17 dot net

--- Comment #17 from Vincent Lefèvre  ---
(In reply to Martin Sebor from comment #10)
> $ cat pr95217.c && clang -S -Wall -Wextra --analyze pr95217.c
[...]
> pr95217.c:8:3: warning: Value stored to 'p' is never read
>   p += 1;  // missing warning
>   ^~
> pr95217.c:13:3: warning: Value stored to 'p' is never read
>   p = p + 1;   // missing warning
>   ^   ~
> 2 warnings generated.

Clang (15 and above) with -Wunused-but-set-variable now detects the issue on
the "p++" and "p += 1" forms (ditto with other combined assignment operators),
but not on "p = p + 1".

Such forms (p++, etc.) are common, so that detecting an unused variable is very
useful.

Like Paul did for Emacs (comment 13), I've just fixed two issues in GNU MPFR
(one cosmetic about a useless loop variable and one important in the
testsuite), found with Clang 16. The references:
https://gitlab.inria.fr/mpfr/mpfr/-/commit/4c110cf4773b3c07de2a33acbee591cedb083c80
https://gitlab.inria.fr/mpfr/mpfr/-/commit/b34d867fa41934d12d0d4dbaaa0242d6d3eb32c7

For the second MPFR issue, there was an "err++" for each error found by the
function in the testsuite, but err was not tested at the end, so that potential
errors were never reported.

[Bug c/95057] missing -Wunused-but-set-variable warning on multiple assignments, not all of them used

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #6 from Vincent Lefèvre  ---
Well, for the ++, --, +=, -=, *=, etc. operators, that's PR44677 (though it is
unclear on what it should cover).

[Bug c/95057] missing -Wunused-but-set-variable warning on multiple assignments, not all of them used

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #5 from Vincent Lefèvre  ---
FYI, Clang 16 does not warn either on the testcases provided in comment 0 (bug
report).

But contrary to GCC (tested with master r14-1713-g6631fe419c6 - Debian
gcc-snapshot package 20230613-1), Clang 15 and 16 both warn on f and g below:

int h (void);

void f (void)
{
  int i = h ();
  i++;
}

void g (void)
{
  for (int i = 0 ;; i++)
if (h ())
  break;
}

zira:~> clang-15 -c -Wunused-but-set-variable warn-inc.c
warn-inc.c:5:7: warning: variable 'i' set but not used
[-Wunused-but-set-variable]
  int i = h ();
  ^
warn-inc.c:11:12: warning: variable 'i' set but not used
[-Wunused-but-set-variable]
  for (int i = 0 ;; i++)
   ^
2 warnings generated.

Thanks to this detection, a test with Clang 16 found two issues in GNU MPFR
(one cosmetic about a useless loop variable and one important in the
testsuite). So it is useful to consider such particular cases.

[Bug c++/110114] [13/14 Regression] ICE on calling overloaded function in case of incomplete argument type and C++ designated initializers

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

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

--- Comment #4 from Marek Polacek  ---
This should work; I'll test it tomorrow.

--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -986,6 +986,11 @@ build_aggr_conv (tree type, tree ctor, int flags,
tsubst_flags_t complain)
   tree empty_ctor = NULL_TREE;
   hash_set pset;

+  /* We've called complete_type on TYPE before calling this function, but
+ perhaps it wasn't successful.  */
+  if (!COMPLETE_TYPE_P (type))
+return nullptr;
+
   /* We already called reshape_init in implicit_conversion, but it might not
  have done anything in the case of parenthesized aggr init.  */

[Bug c++/110114] [13/14 Regression] ICE on calling overloaded function in case of incomplete argument type and C++ designated initializers

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c/110728] should __attribute__((cleanup())) callback get invoked for indirect edges of asm goto

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=37722

--- Comment #4 from Andrew Pinski  ---
Oh and computed goto has a similar issue too (PR 37722 which is for C++
deconstructors but cleanup is the same idea there).

[Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Sergei Trofimovich from comment #7)
> Silly question: I would expect -O0 not to perform any simplifications like
> that.  Does `gcc` have a knob to disable `match.pd` templates? Or some of
> them are crucial for correctness?

Some are crucial for correctness usually dealing with c++. you could always use
dbg_cnt to try to narrow down which one is failing.


See 
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/dbgcnt.def;h=9e2f1d857b49c6c331cc7d1c419eafa0f2403e96;hb=HEAD

For on how to use dbg_cnt

match is the counter here.

Also for generic folding -fdump-tree-original-folding will have the debug info
on what match pattern was applied during "fold" (of generic).

[Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

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

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

--- Comment #7 from Sergei Trofimovich  ---
Silly question: I would expect -O0 not to perform any simplifications like
that.  Does `gcc` have a knob to disable `match.pd` templates? Or some of them
are crucial for correctness?

[Bug c/110728] should __attribute__((cleanup())) callback get invoked for indirect edges of asm goto

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

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

--- Comment #3 from Andrew Pinski  ---
That is even doing:
```
int g();
int h()
{
l0:;
int x __attribute__((cleanup(test4cleanup)));
if (g()) goto l0;
}
```
Produces the same result which is why I said this is the same as PR 91951
really.

[Bug c/110728] should __attribute__((cleanup())) callback get invoked for indirect edges of asm goto

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

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

--- Comment #2 from Andrew Pinski  ---
Techincally x does not go out of scope until the } so I don't see how this
would act any other way.

[Bug c/110728] should __attribute__((cleanup())) callback get invoked for indirect edges of asm goto

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

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

--- Comment #1 from Andrew Pinski  ---
I suspect PR 91951 is the same really.

[Bug c/110728] New: should __attribute__((cleanup())) callback get invoked for indirect edges of asm goto

[ndesaulniers at google dot com via Gcc-bugs]

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

Bug ID: 110728
   Summary: should __attribute__((cleanup())) callback get invoked
for indirect edges of asm goto
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ndesaulniers at google dot com
  Target Milestone: ---

Consider the following test case:

```c
void test4cleanup(int*);
// No errors expected.
void test4(void) {
l0:;
int x __attribute__((cleanup(test4cleanup)));
asm goto("# %l0"l0);
}

```

gcc trunk today generates effectively the following control flow:
```
test4:
.LFB0:
subq$24, %rsp
.L2:
#APP
# .L2
#NO_APP
leaq12(%rsp), %rdi
calltest4cleanup
addq$24, %rsp
ret
```
so if the inline asm blob jumps to `l0`, then the cleanup function is not run.

That seemed surprising, at least when we discussed it on this thread.
https://reviews.llvm.org/D155342#4511887

A fellow Linux kernel dev (who introduced the usage of
__attribute__((cleanup())) (and asm goto, coincidentally) to the kernel) agreed
(on IRC).

For now in clang, we produce a diagnostic since the behavior seems surprising. 
If this gets changed in GCC, I'd be happy to modify clang to match that updated
behavior.

[Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

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

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

--- Comment #6 from Andrew Pinski  ---
Created attachment 55576
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55576=edit
Full testcase

[Bug fortran/110720] [13 Regression] Internal compiler error (segmentation fault) in gfc_expression_rank

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

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #2)
> (In reply to anlauf from comment #1)
> > Looks like a dup of pr109948, which is fixed on 14-trunk.
> > 
> > @Paul: do you think your patch (commit r14-1487-g3c2eba4) is
> > backportable to 13-branch?
> 
> I know that it is :-)
> 
> I'll propose a backport to the list unless you want to OK it here?

I don't remember any regressions from the fix on mainline, so OK from me.
Let's fix this issue in time before 13.2 comes out...

:-)

[Bug fortran/110720] [13 Regression] Internal compiler error (segmentation fault) in gfc_expression_rank

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

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

--- Comment #2 from Paul Thomas  ---
(In reply to anlauf from comment #1)
> Looks like a dup of pr109948, which is fixed on 14-trunk.
> 
> @Paul: do you think your patch (commit r14-1487-g3c2eba4) is
> backportable to 13-branch?

I know that it is :-)

I'll propose a backport to the list unless you want to OK it here?

Cheers

Paul

[Bug testsuite/110419] [14 regression] new test case gfortran.dg/value_9.f90 in r14-2050-gd130ae8499e0c6 fails

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

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||dje at gcc dot gnu.org
   Last reconfirmed||2023-07-18
 Ever confirmed|0   |1

--- Comment #16 from David Edelsohn  ---
As I wrote in issue 110360, the bug appears to be the memory layout and padding
assumed by GFortran that does not take into account endianness.

I have changed val() to print both c and x, and not halt.

  subroutine val (x, c)
character(kind=1), intent(in) :: x  ! control: pass by reference
character(kind=1), value  :: c
print *, "by value(kind=1): ", x
print *, "by value(kind=1): ", c
!if (c /= x)   stop 1
c = "*"
if (c /= "*") stop 2
  end


The output is:

 by value(kind=1): B
 by value(kind=1): B
 by value(kind=1): A
 by value(kind=1): A
 by value(kind=1): A
 by value(kind=1):<- c
 by value(kind=1): A
 by value(kind=1):<- c
 by value(kind=1): A
 by value(kind=1):<- c
 by value(kind=1): 1
 by value(kind=1):<- c
 by value(kind=1): 1
 by value(kind=1):<- c


The assembly language for the first few calls is

# call val  ("B","B")
lwz 31,LC..5(2)  LOAD ADDRESS of x
mr 3,31  COPY address to first parameter
li 6,1
li 5,1
lbzu 4,148(3)LOAD BYTE of c as second parameter
slwi 4,4,24  SHIFT c 24 bits
bl .val.4
# call val  ("A",char(65))
mr 30,31 COPY ADDRESS of x
li 6,1
li 5,1
lbzu 4,152(30)   LOAD BYTE of c as second parameter
slwi 4,4,24  SHIFT c 24 bits
mr 3,30  COPY address of first parameter
bl .val.4
# call val  ("A",char(a))
li 6,1
li 5,1
li 4,65  <- c NOT SHIFTED
mr 3,30  <- x
bl .val.4
# call val  ("A",mychar(65))
li 6,1
li 5,1
li 4,65  <- c NOT SHIFTED
mr 3,30  <- x
bl .val.4
# call val  ("A",mychar(a))
li 6,1
li 5,1
li 4,65  <- c NOT SHIFTED
mr 3,30  <- x
bl .val.4

GFortran is not taking account of endianness for the layout of values in memory
compared to constants loaded into registers.  This isn't an ABI issue of the
target, this is a memory layout and register layout issue of GFortran.

On a big endian system, a character / byte is loaded at the LSB, but GFortran
seems to be comparing it to a memory image with the character / byte stored at
the MSB, which would be correct for little endian.  In some cases, GFortran is
shifting the value and in other cases it is not.

GFortran does not seem to have a consistent view of the memory layout for
characters / bytes loaded into a larger object.

[Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

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

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

--- Comment #5 from Andrew Pinski  ---
Created attachment 55575
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55575=edit
Patch which should fix this

So I didn't realize I need the check for "INTEGRAL_TYPE_P (TREE_TYPE (@0))
  && TYPE_PRECISION (TREE_TYPE (@0)) == 1" On these.

[Bug target/110724] Unnecessary alignment on branch to unconditional branch targets

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

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

--- Comment #5 from Andrew Pinski  ---
Plus if this is just the return case how important is that because maybe we
should be inlining this kind of function.  Plus this is a memcpy, why not just
use the expansion of __builtin_memcpy here (which is tuned for each target
better).

[Bug c++/110106] [11/12/13/14 Regression] ICE on noexcept(noexcept(...)) with optional

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug target/110724] Unnecessary alignment on branch to unconditional branch targets

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |target

--- Comment #4 from Andrew Pinski  ---
I noticed clang/LLVM does not do any alignment here but I doubt that is correct
thing to do.

Anyways I don't there is any bug here in the middle-end because the alignment
is what the backend requests. Now the question is the alignment needed or not,
that is for some x86 person to do benchmarking really. And if this needs more
than the simple heurstics than what is currently supported in the middle-end
well that is still up to the Intel/AMD person to benchmark.

[Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

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

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

--- Comment #4 from Andrew Pinski  ---
/* a | (a == b)  -->  a | (b^1) (boolean version of the above). */
(simplify
 (bit_ior:c @0 (nop_convert? (eq:c @0 @1)))
 (bit_ior @0 (bit_xor @1 { build_one_cst (type); })))


So I guess the issue is eq on generic has an integer type rather than boolean
type ...

[Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-07-18
 Status|UNCONFIRMED |NEW
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
It worked at r14-2547-g71a907abdb4c03d4a3419190d .

Mine, looks like r14-2556-g0407ae8a7732d9 caused it ...

[Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |14.0

[Bug target/110722] FP is Saved/Restored around inline assembly

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

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

--- Comment #1 from Andrew Pinski  ---
I think this will be fixed with -momit-leaf-frame-pointer patch at :
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624752.html

[Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

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

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

--- Comment #2 from Andrew Pinski  ---
Whoops wrong bug report.

[Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

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

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

--- Comment #1 from Andrew Pinski  ---
I think this will be fixed with -momit-leaf-frame-pointer patch at :
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624752.html

[Bug target/110727] New: gcc.target/aarch64/sve/aarch64-sve.exp has two new failures since commit 061f74c0673

[thiago.bauermann at linaro dot org via Gcc-bugs]

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

Bug ID: 110727
   Summary: gcc.target/aarch64/sve/aarch64-sve.exp has two new
failures since commit 061f74c0673
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thiago.bauermann at linaro dot org
  Target Milestone: ---

Created attachment 55574
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55574=edit
Tarball containing testsuite log files for first bad and last good commits.

Our CI detected that commit 061f74c06735 "Fix profile update in
scale_profile_for_vect_loop" introduced these testsuite failures on
aarch64-linux:

Running gcc:gcc.target/aarch64/sve/aarch64-sve.exp ...
FAIL: gcc.target/aarch64/sve/live_1.c scan-assembler-times
\\twhilelo\\tp[0-7].b,  2
FAIL: gcc.target/aarch64/sve/live_1.c scan-assembler-times
\\twhilelo\\tp[0-7].h,  4

I confirmed that they are still present in trunk as of commit c11a3aedec26
"tree-ssa-loop-ch improvements, part 3" from today.

Tested on Ubuntu 22.04 with:

$ ~/src/gcc/configure --disable-bootstrap --disable-multilib && make -j 60
$ make -C gcc check-c RUNTESTFLAGS=gcc.target/aarch64/sve/aarch64-sve.exp

I'll attach gcc.sum and gcc.log from commit c11a3aedec26 as well as gcc.sum and
gcc.log from its parent, which was the last commit where the test passed.

[Bug middle-end/110726] New: [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

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

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

Bug ID: 110726
   Summary: [14 Regression] wrong code on llvm-16 around 'a |= a
== 0'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

This week's gcc r14-2600-g3a407070b610a8 fails llvm-16 test suite as:

  Failed Tests (1):
LLVM-Unit ::
Support/./SupportTests/BlockFrequencyTest.SaturatingRightShift

It looks like the reproducer is trivial and happens even on -O0:

// $ cat bug.cc
int main(void) {
  unsigned long long freq = 0x10080ULL;

  freq >>= 2;
  freq |= freq == 0;

  if (freq != 0x4020ULL)
  __builtin_trap();
}

$ gcc-14 bug.cc -o a && ./a
Illegal instruction (core dumped)

$ $ gcc bug.cc -o a && ./a


$ gcc -v
Using built-in specs.
COLLECT_GCC=/<>/gcc-14.0.0/bin/gcc
COLLECT_LTO_WRAPPER=/<>/gcc-14.0.0/libexec/gcc/x86_64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../source/configure --prefix=/<>/gcc-14.0.0
--with-gmp-include=/<>/gmp-6.2.1-dev/include
--with-gmp-lib=/<>/gmp-6.2.1/lib
--with-mpfr-include=/<>/mpfr-4.2.0-dev/include
--with-mpfr-lib=/<>/mpfr-4.2.0/lib --with-mpc=/<>/libmpc-1.3.1
--with-native-system-header-dir=/<>/glibc-2.37-8-dev/include
--with-build-sysroot=/ --program-prefix= --enable-lto --disable-libstdcxx-pch
--without-included-gettext --with-system-zlib --enable-checking=release
--enable-static --enable-languages=c,c++ --disable-multilib --enable-plugin
--disable-libcc1 --with-isl=/<>/isl-0.20 --disable-bootstrap
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=x86_64-unknown-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0  (experimental) (GCC)

[Bug middle-end/110724] Unnecessary alignment on branch to unconditional branch targets

[javier.martinez.bugzilla at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Javier Martinez  
---
The generic tuning of 16:11:8 looks reasonable to me, I do not argue against
it.



From Anger Fog’s Optimizing subroutines in assembly language:

> Most microprocessors fetch code in aligned 16-byte or 32-byte blocks.
> If an important subroutine entry or jump label happens to be near the
> end of a 16-byte block then the microprocessor will only get a few 
> useful bytes of code when fetching that block of code. It may have
> to fetch the next 16 bytes too before it can decode the first instructions
> after the label. This can be avoided by aligning important subroutine
> entries and loop entries by 16. Aligning by 8 will assure that at least 8
> bytes of code can be loaded with the first instruction fetch, which may
> be sufficient if the instructions are small.



This looks like the reason behind the alignment. That section of the book
goes on to explain the inconvenience (execution of nops) of alignment on labels
reachable by other means than branching - which I presume lead to the :m and
:m2 tuning values, the distinction between -falign-labels and -falign-jumps,
and the reason padding is removed when my label is reachable by fall-through
with [[unlikely]].



All this is fine. 

My thesis is that this alignment strategy is always unnecessary in one specific
circumstance - when the branch target is itself an unconditional branch of size
1, as in:



.L1:

  ret 



Because the ret instruction will never cross a block boundary, and the
instructions following the ret must not execute, so there is no front-end stall
to avoid.

[Bug fortran/110725] [13/14 Regression,openmp] internal compiler error: in expand_expr_real_1, at expr.cc:10897

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[13/14 Regression] internal |[13/14 Regression,openmp]
   |compiler error: in  |internal compiler error: in
   |expand_expr_real_1, at  |expand_expr_real_1, at
   |expr.cc:10897   |expr.cc:10897
 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
Reduced testcase.  The '!$omp end teams' line in subroutine initial appears to
be out-of-place.


  module swim_mod

  INTEGER, PARAMETER :: N1=7702, N2=7702

  DOUBLE PRECISION, ALLOCATABLE, DIMENSION(:,:) :: U, V

  INTEGER :: M, N, MP1, NP1

!$omp declare target(U, V)
!$omp declare target(M,N,MP1,NP1)

  CONTAINS

  SUBROUTINE ALLOC
 IMPLICIT NONE
!$omp target update to(M,N,MP1,NP1)
!$omp&
 ALLOCATE(U(NP1,MP1), V(NP1,MP1))
  END SUBROUTINE

  SUBROUTINE INITAL
  INTEGER I
!$omp target
!$omp teams
!$omp distribute parallel do simd
  DO 75 I=1,M
 U(I+1,N+1) = U(I+1,1)
 V(I,1) = V(I,N+1)
   75 CONTINUE
!$omp end teams
  U(1,N+1) = U(M+1,1)
  V(M+1,1) = V(1,N+1)
!$omp end target
  END SUBROUTINE

  end module swim_mod

[Bug fortran/110360] ABI issue with character,value dummy argument

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

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

--- Comment #26 from anlauf at gcc dot gnu.org ---
(In reply to David Edelsohn from comment #25)
> The problem on big endian systems is that GFortran is passing the character
> with the wrong padding.
[...]
> GFortran is not taking account of endianness for the layout of values in
> memory compared to constants loaded into registers.  This isn't an ABI issue
> of the target, this is a memory layout and register layout issue of GFortran.

Frankly speaking, this is a place where I have zero knowledge.

> Let me know if you need more information or tests.

There is pr110419 which tracks the testsuite regression on BE systems.

Mikael added some info there.  Maybe you can have a look, too.

[Bug fortran/95947] PACK intrinsic returns blank strings when an allocatable character array with allocatable length is used

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-14 so far, and on 13-branch.
Might be backported further after waiting some time.

Thanks for the report!

[Bug fortran/110658] MINVAL/MAXVAL and deferred-length character arrays

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Harald Anlauf
:

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

commit r13-7584-gccf94ab2abb6969c04d51c7879f07edfbb97ae55
Author: Harald Anlauf 
Date:   Sun Jul 16 22:17:27 2023 +0200

Fortran: intrinsics and deferred-length character arguments
[PR95947,PR110658]

gcc/fortran/ChangeLog:

PR fortran/95947
PR fortran/110658
* trans-expr.cc (gfc_conv_procedure_call): For intrinsic procedures
whose result characteristics depends on the first argument and
which
can be of type character, the character length will not be
deferred.

gcc/testsuite/ChangeLog:

PR fortran/95947
PR fortran/110658
* gfortran.dg/deferred_character_37.f90: New test.

(cherry picked from commit 95ddd2659849a904509067ec3a2770135149a722)

[Bug fortran/95947] PACK intrinsic returns blank strings when an allocatable character array with allocatable length is used

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Harald Anlauf
:

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

commit r13-7584-gccf94ab2abb6969c04d51c7879f07edfbb97ae55
Author: Harald Anlauf 
Date:   Sun Jul 16 22:17:27 2023 +0200

Fortran: intrinsics and deferred-length character arguments
[PR95947,PR110658]

gcc/fortran/ChangeLog:

PR fortran/95947
PR fortran/110658
* trans-expr.cc (gfc_conv_procedure_call): For intrinsic procedures
whose result characteristics depends on the first argument and
which
can be of type character, the character length will not be
deferred.

gcc/testsuite/ChangeLog:

PR fortran/95947
PR fortran/110658
* gfortran.dg/deferred_character_37.f90: New test.

(cherry picked from commit 95ddd2659849a904509067ec3a2770135149a722)

[Bug c++/110197] [13/14 Regression] Empty constexpr object constructor erronously claims out of range access

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

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

--- Comment #2 from Marek Polacek  ---
// PR c++/110197

namespace std {
constexpr bool __is_constant_evaluated() {
  return __builtin_is_constant_evaluated();
}
template  using enable_if_t = _Tp;
template  struct __array_traits {
  typedef _Tp _Type[_Nm];
};
template  struct array {
  typename __array_traits<_Tp, _Nm>::_Type _M_elems;
};
template  array(_Tp) -> array, 1>;
struct char_traits {
  static constexpr unsigned length() {
__is_constant_evaluated();
return 0;
  }
};
struct basic_string_view {
  using traits_type = char_traits;
  constexpr basic_string_view(const char *)
  : _M_len{traits_type::length()}, _M_str{} {}
  long _M_len;
  char _M_str;
};
} // namespace std
struct Currency {
  constexpr Currency(std::basic_string_view) {}
};
void get_c() { constexpr std::array c{Currency{""}}; }

[Bug fortran/110725] [13/14 Regression] internal compiler error: in expand_expr_real_1, at expr.cc:10897

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Summary|internal compiler error: in |[13/14 Regression] internal
   |expand_expr_real_1, at  |compiler error: in
   |expr.cc:10897   |expand_expr_real_1, at
   ||expr.cc:10897
   Target Milestone|--- |13.2
   Keywords||ice-on-valid-code, openmp
   Last reconfirmed||2023-07-18
   Priority|P3  |P4

--- Comment #1 from anlauf at gcc dot gnu.org ---
The code is accepted by Nvidia.

No ICE at -O0, but ICE at -Og, -O1, and higher.

ICE confirmed also on x86_64, so likely not target-specific.

[Bug middle-end/110724] Unnecessary alignment on branch to unconditional branch targets

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2023-07-18
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
The generic tuning is:
  "16:11:8",/* Loop alignment.  */
  "16:11:8",/* Jump alignment.  */
  "0:0:8",  /* Label alignment.  */

The the operands are described as:
https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Optimize-Options.html#index-falign-functions
```
-falign-functions=n:m:n2
...
Examples: -falign-functions=32 aligns functions to the next 32-byte boundary,
-falign-functions=24 aligns to the next 32-byte boundary only if this can be
done by skipping 23 bytes or less, -falign-functions=32:7 aligns to the next
32-byte boundary only if this can be done by skipping 6 bytes or less.

The second pair of n2:m2 values allows you to specify a secondary alignment:
-falign-functions=64:7:32:3 aligns to the next 64-byte boundary if this can be
done by skipping 6 bytes or less, otherwise aligns to the next 32-byte boundary
if this can be done by skipping 2 bytes or less. If m2 is not specified, it
defaults to n2.
```

So align jumps to 16 byte if 11 or less bytes can be used or 8 byte alignment
Which is exactly what this does:
.p2align 4,,7  # <-- unnecessary alignment
.p2align 3

[Bug middle-end/110724] Unnecessary alignment on branch to unconditional branch targets

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

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

--- Comment #1 from Andrew Pinski  ---
I think this is by design.

Adding -fno-align-jumps makes the alignment go away.

[Bug c++/110338] Implement C++26 language features

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

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

Bug 110340 Summary: [C++26] P2621R2 - Remove undefined behavior from lexing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110340

   What|Removed |Added

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

[Bug c++/110340] [C++26] P2621R2 - Remove undefined behavior from lexing

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

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

--- Comment #3 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r14-2626-gfca089e8a47314a40ad93527ba9f9d0d374b3afb
Author: Marek Polacek 
Date:   Tue Jul 18 13:26:39 2023 -0400

c++: Add tests for P2621, no UB in lexer [PR110340]

C++26 P2621 removes UB in the lexer and either makes the construct valid
or ill-formed.  We're already handling this correctly so this patch only
adds tests.

PR c++/110340

gcc/testsuite/ChangeLog:

* g++.dg/cpp/string-4.C: New test.
* g++.dg/cpp/ucn-2.C: New test.

[Bug c++/110340] [C++26] P2621R2 - Remove undefined behavior from lexing

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Done.

[Bug fortran/110725] New: internal compiler error: in expand_expr_real_1, at expr.cc:10897

[tonycurtis32 at gmail dot com via Gcc-bugs]

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

Bug ID: 110725
   Summary: internal compiler error: in expand_expr_real_1, at
expr.cc:10897
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tonycurtis32 at gmail dot com
  Target Milestone: ---

Created attachment 55573
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55573=edit
preprocessed source

arch = a64fx (arm 8.2 + sve)

==

Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/lustre/software/gcc/13.1.0/libexec/gcc/aarch64-unknown-linux-gnu/13.1.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: ../gcc-13.1.0/configure --with-mpfr-lib=/lib64
--with-gmp-lib=/lib64 --with-gmp-include=/usr/include
--with-mpfr-include=/usr/include --with-mpc-lib=/lib64
--with-mpc-include=/usr/include --prefix=/lustre/software/gcc/13.1.0
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.0 (GCC)

==

command-line = gfortran -ggdb -fopenmp -mcmodel=large -mcpu=a64fx -O3 -o swim
swim.F
(-O0 compiles ok, gcc 12.2 works fine too with optimization)

==

swim.F:107:72:

  107 |   DO 50 I=1,MP1
  |   
1
Warning: Fortran 2018 deleted feature: Shared DO termination label 50 at (1)
swim.F:129:72:

  129 |   DO 60 I=1,M
  |   
1
Warning: Fortran 2018 deleted feature: Shared DO termination label 60 at (1)
swim.F:173:72:

  173 |   DO 86 I=1,MP1
  |   
1
Warning: Fortran 2018 deleted feature: Shared DO termination label 86 at (1)
swim.F:206:72:

  206 |   DO 100 I=1,M
  |   
1
Warning: Fortran 2018 deleted feature: Shared DO termination label 100 at (1)
swim.F:278:72:

  278 |   DO 200 I=1,M
  |   
1
Warning: Fortran 2018 deleted feature: Shared DO termination label 200 at (1)
swim.F:340:72:

  340 |   DO 400 I=1,MP1
  |   
1
Warning: Fortran 2018 deleted feature: Shared DO termination label 400 at (1)
swim.F:376:72:

  376 |   DO 300 I=1,M
  |   
1
Warning: Fortran 2018 deleted feature: Shared DO termination label 300 at (1)
during RTL pass: expand
swim.F:404:72:

  404 | !$omp target
  |   
^
internal compiler error: in expand_expr_real_1, at expr.cc:10897
0x9d1067 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-13.1.0/gcc/expr.cc:10897
0x9cce9b expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../gcc-13.1.0/gcc/expr.cc:9000
0x9cce9b expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
../../gcc-13.1.0/gcc/expr.h:310
0x9cce9b expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-13.1.0/gcc/expr.cc:11234
0x9ce88f expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../gcc-13.1.0/gcc/expr.cc:9000
0x9ce88f expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-13.1.0/gcc/expr.cc:11463
0x9cff3b expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../gcc-13.1.0/gcc/expr.cc:9000
0x9cff3b expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-13.1.0/gcc/expr.cc:10805
0x9cce9b expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../gcc-13.1.0/gcc/expr.cc:9000
0x9cce9b expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
../../gcc-13.1.0/gcc/expr.h:310
0x9cce9b expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-13.1.0/gcc/expr.cc:11234
0x9cff3b expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../gcc-13.1.0/gcc/expr.cc:9000
0x9cff3b expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-13.1.0/gcc/expr.cc:10805
0x9da10f expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../gcc-13.1.0/gcc/expr.cc:9000
0x9da10f store_expr(tree_node*, rtx_def*, int, bool, bool)
../../gcc-13.1.0/gcc/expr.cc:6330
0x9db73b expand_assignment(tree_node*, tree_node*, bool)

[Bug rtl-optimization/110701] [14 Regression] Wrong code at -O1/2/3/s on x86_64-linux-gnu

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |roger at 
nextmovesoftware dot com
 Status|NEW |ASSIGNED

--- Comment #6 from Roger Sayle  ---
I have a fix (to combine.cc's record_dead_and_set_regs_1).  Bootstrapping and
regression testing.

[Bug rtl-optimization/110724] New: Unnecessary alignment on branch to unconditional branch targets

[javier.martinez.bugzilla at gmail dot com via Gcc-bugs]

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

Bug ID: 110724
   Summary: Unnecessary alignment on branch to unconditional
branch targets
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: javier.martinez.bugzilla at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/f7qMxxfMj

void duff(int * __restrict to, const int * __restrict from, const int count)
{
int n = (count+7) / 8;
switch(count%8)
{
   case 0: do { *to++ = *from++;
   case 7:  *to++ = *from++;
   case 6:  *to++ = *from++;
   case 5:  *to++ = *from++;
   case 4:  *to++ = *from++;
   case 3:  *to++ = *from++;
   case 2:  *to++ = *from++;
   [[likely]] case 1:  *to++ = *from++;
} while (--n>0);
}
}

Trunk with O3:
jle .L1
[...]
lea rax, [rax+4]
jmp .L5# <-- no fall-through to ret
.p2align 4,,7  # <-- unnecessary alignment
.p2align 3
.L1:
ret


I believe this 16-byte alignment is done to put the branch target at the
beginning of a front-end instruction fetch block. That however seems
unnecessary when the branch target is itself an unconditional branch, as the
instructions to follow will not retire.

In this example the degrade is code size / instruction caching only, as there
is no possible fall-through to .L1 that would cause nop's to be consumed.
Changing the C++ attribute to [[unlikely]] introduces fall-through, and GCC
seems to remove the padding, which is great.

[Bug fortran/110723] ICE with allocatable character lhs and parenthesized array with vector subscript

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

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #0)
> Not sure if this is the right place.

Actually, the following still fails:

  n =  (m([2])//"")   ! ICE

:-(

Generally stripping parentheses generates a failure in
gfortran.dg/reassoc_2.f90, which is bad...

[Bug fortran/110723] New: ICE with allocatable character lhs and parenthesized array with vector subscript

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

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

Bug ID: 110723
   Summary: ICE with allocatable character lhs and parenthesized
array with vector subscript
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gcc dot gnu.org
  Target Milestone: ---

Found while analyzing pr95947:

program p
  implicit none
  character(len=1)  :: m(3) = ['a','b','c']
  character(len=:), allocatable :: n(:)
  n =   m([2])
  n =   m([2,3])
  n =  (m([2]))   ! ICE
  n =  (m([2,3])) ! ICE
end

We end up with EXPR_OP in the assignment for the parenthesized variants,
leading to bad gimple.

Tentative fix:

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index ef3e6d08f78..63d39c2516e 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -11954,6 +11954,12 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr *
expr2, bool init_flag,

   rss = NULL;

+  /* Strip left-over parentheses around rhs variables (not expressions).  */
+  while (expr2->expr_type == EXPR_OP
+&& expr2->value.op.op == INTRINSIC_PARENTHESES
+&& expr2->value.op.op1->expr_type == EXPR_VARIABLE)
+expr2 = expr2->value.op.op1;
+
   if (expr2->expr_type != EXPR_VARIABLE
   && expr2->expr_type != EXPR_CONSTANT
   && (expr2->ts.type == BT_CLASS || gfc_may_be_finalized (expr2->ts)))

Not sure if this is the right place.

[Bug c/110721] Segmentation fault with '-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink'

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

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

--- Comment #2 from Andrew Pinski  ---
It seems to work on the trunk ...

[Bug target/110649] [14 Regression] 25% sphinx3 spec2006 regression on Ice Lake and zen since g:r14-2369-g3a61ca1b925653 (2023-07-06)

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

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

Jan Hubicka  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=110586

--- Comment #15 from Jan Hubicka  ---
It seems that both this PR nad PR110586 boils down to worse IRA and scheduling
due to corrected profile.  I wonder if the artifically increased frequency of
former bodies of vectorized loops does not suggest that IRA may take into
account that spilling in code with long latency instructions is worse than
spiling elsehwere.

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

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #55567|0   |1
is obsolete||

--- Comment #85 from Jakub Jelinek  ---
Created attachment 55572
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55572=edit
gcc14-bitint-wip.patch

At least the x86-64 _BitInt psABI says that the padding bits are undefined and
the various other psABI proposals do that as well.
Though, when looking at RTL expansion, we were doing REDUCE_BIT_FIELD after
operations, meaning that that we effectively relied on those bits at least for
small/middle _BitInt to be sign or zero extended.
This change tries to force sign/zero extensions when reading _BitInt from
memory, parameters etc.

[Bug rtl-optimization/110701] [14 Regression] Wrong code at -O1/2/3/s on x86_64-linux-gnu

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #5 from Roger Sayle  ---
nonzero_bits ((reg:DI 92),SImode) is returning 340, so combine (or more
specifically simplify_and_const_int_1) believes that the AND (ZERO_EXTEND)
isn't unnecessary.  So it's the same nonzero_bits information that allows us to
turn the  XOR into IOR (in insn 16) that's incorrectly telling us the AND 340
(or AND 343, or ZERO_EXTEND) is unnecessary (in insn 17).

[Bug fortran/110720] [13 Regression] Internal compiler error (segmentation fault) in gfc_expression_rank

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
Summary|Internal compiler error |[13 Regression] Internal
   |(segmentation fault) in |compiler error
   |gfc_expression_rank |(segmentation fault) in
   ||gfc_expression_rank
   Last reconfirmed||2023-07-18
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=109948

--- Comment #1 from anlauf at gcc dot gnu.org ---
Looks like a dup of pr109948, which is fixed on 14-trunk.

@Paul: do you think your patch (commit r14-1487-g3c2eba4) is
backportable to 13-branch?

[Bug target/110722] New: FP is Saved/Restored around inline assembly

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

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

Bug ID: 110722
   Summary: FP is Saved/Restored around inline assembly
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: palmer at gcc dot gnu.org
  Target Milestone: ---

I'm not sure if this is some ABI-related requirement that I've managed to
forget about, but it looks like we're saving/restoring FP around inline
assembly.

long fp_asm(long arg0)
{
asm volatile ("addi a0, a0, 1" : "+r"(arg0));
return arg0;
}

produces

fp_asm(long):
addisp,sp,-16
sd  s0,8(sp)
addis0,sp,16
addi a0, a0, 1
ld  s0,8(sp)
addisp,sp,16
jr  ra

We've got a ton of inline assembly in Linux these days and defconfig has
`-fno-omit-frame-pointer`, so this probably manifests as a performance issue
for someone somewhere -- though Clement just ran into it because he was
curious, so I don't have anything concrete.

[Bug gcov-profile/110561] gcov counts closing bracket in a function as executable, lowering coverage statistics

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Carlos Galvez  ---
@Andrew Pinski ping in case you missed my last message. If this were a
duplicate but, wouldn't it also happen in GCC 7.5.0?

[Bug libgcc/109712] [13 Regression] Segmentation fault in linear_search_fdes

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

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

Florian Weimer  changed:

   What|Removed |Added

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

--- Comment #37 from Florian Weimer  ---
Backported to 13, the only impacted release.

[Bug c/110721] Segmentation fault with '-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink'

[19373742 at buaa dot edu.cn via Gcc-bugs]

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

--- Comment #1 from CTC <19373742 at buaa dot edu.cn> ---
Created attachment 55571
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55571=edit
The compiler output

[Bug c/110721] New: Segmentation fault with '-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink'

[19373742 at buaa dot edu.cn via Gcc-bugs]

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

Bug ID: 110721
   Summary: Segmentation fault with '-O3 -fno-dce -fno-ipa-cp
-fno-tree-dce -fno-tree-sink'
   Product: gcc
   Version: 11.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 19373742 at buaa dot edu.cn
  Target Milestone: ---

Created attachment 55570
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55570=edit
The preprocessed file

***
OS and Platform:
CentOS Linux release 7.9.2009 (Core), x86_64 GNU/Linux
***
gcc version:
gcc -v
Using built-in specs.
COLLECT_GCC=/home/new-gcc/gcc-11-0713/bin/gcc
COLLECT_LTO_WRAPPER=/home/new-gcc/gcc-11-0713/libexec/gcc/x86_64-pc-linux-gnu/11.4.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/home/new-gcc/gcc-11-0713/
--disable-multilib --enable-languae=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.4.1 20230713 (GCC)
***
Command Lines:
# /home/new-gcc/gcc-11-0713/bin/gcc -I /home/csmith/include/csmith-2.3.0/ -O3
-fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink ecn.c -o ecn.o
#/home/new-gcc/gcc-11-0713/bin/gcc -I /home/csmith/include/csmith-2.3.0/ ecn.c
-o ecn2.o
# ./ecn.o
Segmentation fault
# ./ecn2.o
checksum = AF78526F

[Bug libgcc/109712] [13 Regression] Segmentation fault in linear_search_fdes

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

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

--- Comment #36 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Florian Weimer 
:

https://gcc.gnu.org/g:7302f8a2fa2f95252b32de2dc826591e75230662

commit r13-7582-g7302f8a2fa2f95252b32de2dc826591e75230662
Author: Florian Weimer 
Date:   Tue Jun 6 11:01:07 2023 +0200

libgcc: Fix eh_frame fast path in find_fde_tail

The eh_frame value is only used by linear_search_fdes, not the binary
search directly in find_fde_tail, so the bug is not immediately
apparent with most programs.

Fixes commit e724b0480bfa5ec04f39be8c7290330b495c59de ("libgcc:
Special-case BFD ld unwind table encodings in find_fde_tail").

libgcc/

PR libgcc/109712
* unwind-dw2-fde-dip.c (find_fde_tail): Correct fast path for
parsing eh_frame.

(cherry picked from commit 49310a993308492348119f4033e4db0bda4fe46a)

[Bug libgcc/110179] unwind-dw2-fde-dip.c:406: assignment makes integer from pointer without a cast

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Florian Weimer 
:

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

commit r13-7583-g6f9dfb4d759146eebf7f88ad519010ea2191bf3a
Author: Florian Weimer 
Date:   Tue Jul 11 06:19:39 2023 +0200

libgcc: Fix -Wint-conversion warning in find_fde_tail

Fixes commit r14-1614-g49310a99330849 ("libgcc: Fix eh_frame fast path
in find_fde_tail").

libgcc/

PR libgcc/110179
* unwind-dw2-fde-dip.c (find_fde_tail): Add cast to avoid
implicit conversion of pointer value to integer.

(cherry picked from commit 104b09005229ef48a79a33511ea192bb3ec3c415)

[Bug fortran/110720] New: Internal compiler error (segmentation fault) in gfc_expression_rank

[adrien.morison at gmail dot com via Gcc-bugs]

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

Bug ID: 110720
   Summary: Internal compiler error (segmentation fault) in
gfc_expression_rank
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adrien.morison at gmail dot com
  Target Milestone: ---

Created attachment 55569
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55569=edit
Minimal test case triggering the problem, foo_mod.f90 in the above command

This is with a development snapshot on commit
bef95ba085b0ae9bf3eb79a8eed685236d773116

Compiling the attached code lead to an internal compiler error. The attached
code is a self-contained example that triggers the problem, and is a stripped
down version of the actual code (which does a bunch of computations instead of
setting things to 0).

Command:
gfortran -v -save-temps -freport-bug -c foo_mod.f90

Output:
Using built-in specs.
COLLECT_GCC=gfortran
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,objc,obj-c++ --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.1 20230714 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-freport-bug' '-c' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/13.1.1/f951 foo_mod.f90 -quiet -dumpbase
foo_mod.f90 -dumpbase-ext .f90 -mtune=generic -march=x86-64 -version
-freport-bug -fintrinsic-modules-path
/usr/lib/gcc/x86_64-pc-linux-gnu/13.1.1/finclude
-fpre-include=/usr/include/finclude/math-vector-fortran.h -o foo_mod.s
GNU Fortran (GCC) version 13.1.1 20230714 (x86_64-pc-linux-gnu)
compiled by GNU C version 13.1.1 20230714, GMP version 6.2.1, MPFR
version 4.2.0-p9, MPC version 1.3.1, isl version isl-0.26-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
f951: internal compiler error: Segmentation fault
0x1a10354 internal_error(char const*, ...)
???:0
0x77d345 gfc_expression_rank(gfc_expr*)
???:0
0x7392cc gfc_match_expr(gfc_expr**)
???:0
0x7792e0 gfc_match_actual_arglist(int, gfc_actual_arglist**, bool)
???:0
0x784cd3 gfc_match_rvalue(gfc_expr**)
???:0
0x7392cc gfc_match_expr(gfc_expr**)
???:0
0x739778 gfc_match(char const*, ...)
???:0
0x739f29 gfc_match_assignment()
???:0
0x793ac4 gfc_parse_file()
???:0
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug rtl-optimization/110717] Double-word sign-extension missed-optimization

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

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

--- Comment #2 from Jakub Jelinek  ---
Improved testcase which shows similar behavior also with bitfields:

#ifdef __SIZEOF_INT128__
#define type __int128
#define N 59
#else
#define type long long
#define N 27
#endif

struct S { type a : sizeof (type) * __CHAR_BIT__ - N; };

unsigned type
foo (unsigned type x)
{
  x <<= N;
  return ((type) x) >> N;
}

unsigned type
bar (struct S *p)
{
  return p->a;
}

[Bug target/110649] [14 Regression] 25% sphinx3 spec2006 regression on Ice Lake and zen between g:acaa441a98bebc52 (2023-07-06 11:36) and g:55900189ab517906 (2023-07-07 00:23)

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

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

--- Comment #14 from Jan Hubicka  ---
Chasing profile update bugs out of the hottest two functions did not solve the
regression. Moreover the weekly testers confirm it was not noise on zens
either.

Before the change we get:

  34.58%  sphinx_livepret  [.] mgau_eval  ◆
  26.61%  sphinx_livepret  [.] vector_gautbl_eval_logs3   ▒
   8.94%  sphinx_livepret  [.] subvq_mgau_shortlist   ▒
   7.36%  sphinx_livepret  [.] logs3_add  ▒
   5.66%  sphinx_livepret  [.] approx_cont_mgau_frame_eval▒
   4.68%  sphinx_livepret  [.] mdef_sseq2sen_active   ▒
   3.38%  sphinx_livepret  [.] dict2pid_comsenscr ▒
   1.66%  sphinx_livepret  [.] hmm_vit_eval_3st   ▒
   0.90%  sphinx_livepret  [.] lextree_hmm_eval   ▒
   0.73%  sphinx_livepret  [.] lextree_hmm_propagate  ▒
   0.71%  sphinx_livepret  [.] lextree_enter  ▒
   0.68%  sphinx_livepret  [.] fe_fft ▒
   0.49%  sphinx_livepret  [.] dict2pid_comsseq2sen_active▒
   0.35%  sphinx_livepret  [.] lextree_ssid_active▒
   0.20%  sphinx_livepret  [.] vithist_rescore▒

So difference seems to be mgau_eval.
Both version of mgau_eval has almost same code layout. Main difference is
registr allocation.  In old version we do more spill around call:

 0.01 │   and  $0xffe0,%rsp  ▒
  0.14 │   mov  %rcx,%rbx ▒
  0.00 │   sub  $0xa0,%rsp▒
  0.04 │   mov  0x10(%rdi),%rax   ▒
  0.13 │   mov  0x8(%rdi),%r15d   ▒
  0.01 │   vmovaps  %xmm3,0x80(%rsp)  ▒
  0.22 │   vmovaps  %xmm2,0x90(%rsp)  ▒
  0.03 │   mov  %rdi,0x70(%rsp)   ▒
  0.05 │   lea  (%rax,%rdx,8),%r14▒
  0.01 │   call log_to_logs3_factor   ▒
  1.00 │   test %r13,%r13 ▒
  0.00 │   vxorps   %xmm4,%xmm4,%xmm4 ▒
  0.02 │   vmovsd   %xmm0,0x78(%rsp)  ▒
  0.00 │   je   433   ▒
  0.01 │   movslq   0x0(%r13),%rax▒
  0.02 │   mov  $0xc800,%edi  ▒
  0.01 │   vmovaps  0x90(%rsp),%xmm2  ▒
  0.23 │   vmovaps  0x80(%rsp),%xmm3  ▒
  0.09 │   test %eax,%eax ▒
  0.00 │   js   3f9   ▒

new verison is missing the spill of xmm2/3

  0.02 │   and  $0xffe0,%rsp  ▒
  0.03 │   mov  %rcx,%rbx ▒
  0.01 │   add  $0xff80,%rsp  ▒
  0.03 │   mov  0x10(%rdi),%rax   ▒
  0.16 │   mov  0x8(%rdi),%r15d   ▒
  0.06 │   mov  %rdi,0x50(%rsp)   ▒
  0.12 │   lea  (%rax,%rdx,8),%r14▒
  0.01 │   call log_to_logs3_factor   ▒
  0.75 │   test %r12,%r12 ▒
  0.00 │   vxorps   %xmm3,%xmm3,%xmm3 ▒
  0.01 │   vmovsd   %xmm0,0x58(%rsp)  ▒
  0.01 │   je   3f2   ▒
  0.01 │   movslq   (%r12),%rcx   ▒
  0.00 │   mov  $0xc800,%edi  ▒
   │   test %ecx,%ecx ▒
  0.14 │   js   3b8   ▒

Which looks better. log_to_logs3_factor just returns constant:

Percent│ vmovsd invlogB,%xmm0  
   │ ret   

I wonder why we no longer need to spill. log_to_logs3_factor is from other
translation unit and this is non-LTO build. Maybe there are undefined
variables.

New version does:
  0.29 │   vmovhps  %xmm4,0x70(%rsp)  ▒
  0.11 │   vmovaps  0x70(%rsp),%xmm7  ▒
and this looks odd.

[Bug libstdc++/110719] New: Should chrono formatters always use std::time_put for locale's representation?

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

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

Bug ID: 110719
   Summary: Should chrono formatters always use std::time_put for
locale's representation?
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

auto t = std::chrono::system_clock::now();
  auto loc = std::locale::classic();
  std::cout << std::format(loc, "{:%EX %OS}\n", t);

This prints something like:

14:30:46.809059031 46

The %EX output is produced by calling std::format again with a format string
based on the locale's D_FMT, which for the C locale is something like:
%H:%M:%S. And using std::format("{:%H:%M:%S}", t) prints fractional seconds for
the %S part.

The %OS output is produced by calling std::time_put::put with the %OS format
string and a struct tm with tm_sec set to the integer number of seconds. This
doesn't print the fractional part.

If chrono::parse("%EX", t) uses std::time_get then this presents a problem for
round-tripping, as the formatted output will have fractional seconds, but the
parsed input will not consume that fractional part.

Should we consistently use std::time_put for all locale-specific output?
Alternatively, we could use time_point_cast and duration_cast to round to
seconds. None of the locale-specific formats print fractional seconds.

It would be useful to profile std::format with and without std::time_get, to
see if reusing std::format performs better. If it doesn't, using std::time_put
might be simpler.

[Bug fortran/110718] New: [OpenMP] Wrong value for 'lastprivate' for zero-trip loops

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

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

Bug ID: 110718
   Summary: [OpenMP] Wrong value for 'lastprivate' for zero-trip
loops
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: openmp, wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

In Fortran, a loop
  do i = m1, m2, m3
has a zero-trip loop if  '(m2 - m1 + m3)/m3' <= 0 (the LHS is how the loop
count is calculated).

The second step for the loop initialization is:
"(2) The DO variable becomes defined with the value of the initial parameter
m1."

(For both, see e.g. F2023, "11.1.7.4.1 Loop initiation".)

Hence, the expected value of 'i' after a zero-trip loop is m1.

However, with OpenMP, this fails with zero-trip loops - having some odd value.
(The equivalent C program works.)

Example: The following program prints "-2" (instead of 3 [= n])
and, hence, fails then with "STOP 2".

implicit none
integer :: i, n, m

n = 3
m = 10
i = 99
!$omp parallel do lastprivate(i)
do i = n,m,-2
  stop 1 ! should not run
end do
print *, i
if (i /= 3) stop 2
end

[Bug target/110709] how to handle the initialization of global struct data for position independent executable application.

[wangwen at microsoft dot com via Gcc-bugs]

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

--- Comment #8 from wangwen at microsoft dot com ---
I posted it in the wrong place, please just delete it.
thank you.

[Bug rtl-optimization/110717] Double-word sign-extension missed-optimization

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||uros at gcc dot gnu.org
 Target||x86_64-linux
   Keywords||missed-optimization

--- Comment #1 from Jakub Jelinek  ---
Haven't tried other targets.

[Bug rtl-optimization/110717] New: Double-word sign-extension missed-optimization

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

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

Bug ID: 110717
   Summary: Double-word sign-extension missed-optimization
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

While working on _BitInt, I've noticed that we don't emit very good code at
least on x86_64 -m64/-m32 -O2 for:
#ifdef __SIZEOF_INT128__
unsigned __int128
foo (unsigned __int128 x)
{
  x <<= 59;
  return ((__int128) x) >> 59;
}
#else
unsigned long long
foo (unsigned long long x)
{
  x <<= 27;
  return ((long long) x) >> 27;
}
#endif

The sign-extension from 69 resp. 37 bits could be limited solely to the upper
word,
but we uselessly shift the lower word with it as well:
movq%rdi, %rax
movq%rsi, %rdx
shldq   $59, %rdi, %rdx
salq$59, %rax
shrdq   $59, %rdx, %rax
sarq$59, %rdx
ret
for -m64 and
movl4(%esp), %eax
movl8(%esp), %edx
shldl   $27, %eax, %edx
sall$27, %eax
shrdl   $27, %edx, %eax
sarl$27, %edx
ret
for -m32.
LLVM emits even more horrible code for -m64, but
movl4(%esp), %eax
movl8(%esp), %edx
shll$27, %edx
sarl$27, %edx
retl
for -m32, which looks to me like what we want.

[Bug rtl-optimization/71923] return instruction emitted twice with branch target inbetween

[javier.martinez.bugzilla at gmail dot com via Gcc-bugs]

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

Javier Martinez  changed:

   What|Removed |Added

 CC||javier.martinez.bugzilla@gm
   ||ail.com

--- Comment #2 from Javier Martinez  
---
Also reproducible with:

extern void s1(void);
extern void s2(void);

void foo(int i) {
switch (i) {
case 1:  return s1(); 
case 2:  return s1();
case 3:  return s2();
}
}


On Trunk and with -O2 or higher:

foo(int):
  cmp edi, 2
  jg .L2
  test edi, edi
  jle .L7
  jmp s1 #tailcall
.LVL1:
  .p2align 4,,10
  .p2align 3
.L2:
  cmp edi, 3
  jne .L8
  jmp s2 #tailcall
.LVL2:
  .p2align 4,,10
  .p2align 3
.L7:
  ret# <--- ret
  .p2align 4,,10
  .p2align 3
.L8:
  ret# <--- ret

[Bug libgcc/109712] [13 Regression] Segmentation fault in linear_search_fdes

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

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

--- Comment #35 from Florian Weimer  ---
Backport posted, along with the warning fix:

[PATCH releases/gcc-13 1/2] libgcc: Fix eh_frame fast path in find_fde_tail


[PATCH releases/gcc-13 2/2] libgcc: Fix -Wint-conversion warning in
find_fde_tail

[Bug bootstrap/110716] failed to build cross gcc 10.5 with host gcc 4.6.3

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

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

--- Comment #5 from Xi Ruoyao  ---
Should we change invoke.texi?

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index e099cd0b568..dd4f74fbd78 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -231,7 +231,7 @@ Necessary to bootstrap GCC.  GCC 4.8.3 or newer has
sufficient
 support for used C++11 features, with earlier GCC versions you
 might run into implementation bugs.

-Versions of GCC prior to 11 also allow bootstrapping with an ISO C++98
+Versions of GCC prior to 10.5 also allow bootstrapping with an ISO C++98
 compiler, versions of GCC prior to 4.8 also allow bootstrapping with a
 ISO C89 compiler, and versions of GCC prior to 3.4 also allow
 bootstrapping with a traditional (K) C compiler.

[Bug middle-end/110702] [12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2)

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #2 from Mikael Pettersson  ---
Masked at -Os/O2/O3. The regression at -O1 started with

374cee99d01fceb89d0929da8b38051e6c9768f0 is the first new commit
commit 374cee99d01fceb89d0929da8b38051e6c9768f0
Author: Richard Biener 
Date:   Tue May 17 09:45:02 2022 +0200

tree-optimization/105618 - restore load sinking

[Bug target/110709] how to handle the initialization of global struct data for position independent executable application.

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

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

--- Comment #7 from Xi Ruoyao  ---
(In reply to wangwen from comment #6)
> would anyone guide me any place to ask such question?

You are building the .o files with -fpie, but have you linked the executable
with -pie?  Note that -fpie and -pie are two different options, -fpie is for
the compiler but -pie is for the linker.  W/o -pie the linker will just produce
a non-position-independent executable which can be only loaded at a fixed
address, even if you've built all .o files with -fpie.

With -pie the linker will emit some relative relocation entries in a section of
the outputted PIE.  And when you load the executable, either the loader or the
executable itself must "resolve" the relocation, i. e. read each relocation
entry and use the info recorded in the entry to fix up the addresses of global
objects.

Andrew has already explained this.  If you still don't understand, it indicates
you lack the knowledge about how PIE works in general.  Then Google will find
some nice articles explaining PIE in detail.  Any project-specific support
channel won't be proper for asking such a question about a general concept.

[Bug libgcc/109712] [13 Regression] Segmentation fault in linear_search_fdes

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

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

--- Comment #34 from Richard Biener  ---
You have until Thursday for the backport which is when we want to do 13.2 RC1

[Bug c++/109241] [12/13/14 Regression] ICE Segmentation fault for statement expression with a local type inside inside a generic lambda inside a generic lambda since r13-6722-gb323f52ccf966800

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #12 from Richard Biener  ---
Closing again.

[Bug target/110170] Sub-optimal conditional jumps in conditional-swap with floating point

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|14.0|---
 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #18 from Richard Biener  ---
Huh, right.  Somehow I thought minss/maxss is SSE 4.1.  I do have a patch
series that fixes this, the PR88540 is missing for this but it has some fallout
still.

[Bug rtl-optimization/105715] [13 Regression] missed RTL if-conversion with COND_EXPR change

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[13/14 Regression] missed   |[13 Regression] missed RTL
   |RTL if-conversion with  |if-conversion with
   |COND_EXPR change|COND_EXPR change
  Known to fail||13.1.0
  Known to work||14.0

--- Comment #7 from Richard Biener  ---
Fixed on trunk.

[Bug rtl-optimization/105715] [13/14 Regression] missed RTL if-conversion with COND_EXPR change

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r14-2620-gcbe5f6859a73b2acf203bd7d13f9fb245d63cbd4
Author: Richard Biener 
Date:   Tue Jul 18 10:02:52 2023 +0200

middle-end/105715 - missed RTL if-conversion with COND_EXPR expansion

When the COND_EXPR condition operand was split out to a separate stmt
it became subject to CSE with other condition evaluations.  This
unfortunately leads to TER no longer applying and in turn RTL
expansion of COND_EXPRs no longer seeing the condition and thus
failing to try conditional move expansion.  This can be seen with
gcc.target/i386/pr45685.c when built with -march=cascadelake which
then FAILs to produce the expected number of cmovs.

It can also be seen when we create more COND_EXPRs early like for
instruction selection of MIN/MAX operations that map to IEEE
a > b ? a : b expression semantics.

PR middle-end/105715
* gimple-isel.cc (gimple_expand_vec_exprs): Merge into...
(pass_gimple_isel::execute): ... this.  Duplicate
comparison defs of COND_EXPRs.

[Bug target/110709] how to handle the initialization of global struct data for position independent executable application.

[wangwen at microsoft dot com via Gcc-bugs]

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

--- Comment #6 from wangwen at microsoft dot com ---
would anyone guide me any place to ask such question?

[Bug c++/110535] Internal error when performing a surrogate call with unsatisfied constraints

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ppalka at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
   Target Milestone|--- |13.2

--- Comment #3 from Patrick Palka  ---
Fixed on trunk so far.

[Bug bootstrap/110716] failed to build cross gcc 10.5 with host gcc 4.6.3

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Won't fix.
Build gcc 10.4.0 and then build gcc 10.5.0 and then build the cross compiler.

[Bug c++/110535] Internal error when performing a surrogate call with unsatisfied constraints

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r14-2618-g1e0f37df1b12cd91a6dbb523f5c722f9a961edaa
Author: Patrick Palka 
Date:   Tue Jul 18 09:21:40 2023 -0400

c++: constrained surrogate call functions [PR110535]

We weren't checking constraints on pointer/reference-to-function conversion
functions during overload resolution, which caused us to ICE on the first
testcase and reject the second testcase.

PR c++/110535

gcc/cp/ChangeLog:

* call.cc (add_conv_candidate): Check constraints.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-surrogate1.C: New test.
* g++.dg/cpp2a/concepts-surrogate2.C: New test.

[Bug bootstrap/110716] failed to build cross gcc 10.5 with host gcc 4.6.3

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #3 from Xi Ruoyao  ---
(In reply to Andrew Pinski from comment #2)
> Some c++11ism slipped into the last gcc 10 release it seems. Since gcc 10.5
> is the last release of the gcc 10 series, there is not much to be done there.
> 
> Now I can't remember if gcc 11 requires c++11 compiler or not.

It does, since r11-462.

[Bug c++/110714] constexpr lifetime error: base class this pointer

[pkeir at outlook dot com via Gcc-bugs]

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

--- Comment #3 from Paul Keir  ---
Actually, there's no need here to delete through the base pointer; so this is
perhaps simpler:

struct Base
{
  constexpr Base* get_this() { return this; }
  int x;
};

struct Derived : public Base {};

constexpr bool test()
{
  Derived* pf = new Derived;

  delete static_cast(pf->get_this());

  return true;
}

constexpr bool b = test();

[Bug bootstrap/110716] failed to build cross gcc 10.5 with host gcc 4.6.3

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

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

--- Comment #2 from Andrew Pinski  ---
Some c++11ism slipped into the last gcc 10 release it seems. Since gcc 10.5 is
the last release of the gcc 10 series, there is not much to be done there.

Now I can't remember if gcc 11 requires c++11 compiler or not.

[Bug bootstrap/110716] failed to build cross gcc 10.5 with host gcc 4.6.3

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

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

--- Comment #1 from Xi Ruoyao  ---
GCC 10 branch has been closed so this is unlikely to be fixed.

[Bug bootstrap/110716] New: failed to build cross gcc 10.5 with host gcc 4.6.3

[anmin_deng at yahoo dot com.tw via Gcc-bugs]

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

Bug ID: 110716
   Summary: failed to build cross gcc 10.5 with host gcc 4.6.3
   Product: gcc
   Version: 10.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anmin_deng at yahoo dot com.tw
  Target Milestone: ---

I tried to build a cross gcc-10.5 for ARM target on a linux host/build with
gcc-4.6.3.

Previously in May, I successfully built cross gcc-10.4 for ARM target on the
same linux host/build, but now in July the very same procedure and options
failed for building gcc-10.5.

(possibly gcc-10.5 source added with some C++ features not supported by
gcc-4.6.3?)

The building error messages==>
In file included from ../../gcc-10.5.0/gcc/opts-common.c:29:0:
../../gcc-10.5.0/gcc/opts-jobserver.h:33:22: error: ISO C++ forbids
initialization of member 'error_msg' [-fpermissive]
../../gcc-10.5.0/gcc/opts-jobserver.h:33:22: error: making 'error_msg' static
[-fpermissive]
../../gcc-10.5.0/gcc/opts-jobserver.h:33:22: error: invalid in-class
initialization of static data member of non-integral type 'std::string {aka
std::basic_string}'
../../gcc-10.5.0/gcc/opts-jobserver.h:35:30: error: ISO C++ forbids
initialization of member 'skipped_makeflags' [-fpermissive]
../../gcc-10.5.0/gcc/opts-jobserver.h:35:30: error: making 'skipped_makeflags'
s
static [-fpermissive]
...
...
<==


My configure options are ==>
../gcc-10.4.0/configure LDFLAGS=--static --prefix=/home/tool_chain
--target=arm-none-eabi --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--with-sysroot=/home/tool_chain --with-gnu-as --with-gnu-ld --disable-threads
--with-stabs --disable-nls --disable-host-shared --disable-shared
--with-tls=gnu2 --with-newlib --without-headers --disable-biendian
--enable-version-specific-runtime-libs --enable-languages=c,c++
--disable-libssp --disable-libquadmath --disable-libgomp --disable-libvtv
--disable-lto --disable-add-ons --enable-target-optspace
--with-multilib-list=aprofile,rmprofile --disable-tm-clone-registry
--disable-newlib-iconv --disable-newlib-mb --disable-newlib-wide-orient
--enable-newlib-long-time_t --disable-profile --disable-nss-crypt --disable-nss
--with-host-libstdcxx=-Wl,-Bstatic,-lstdc++,-lm
--with-mpc=/home/tool_chain/prerequisites-20230504
--with-mpfr=/home/tool_chain/prerequisites-20230504
--with-gmp=/home/tool_chain/prerequisites-20230504
--with-isl=/home/tool_chain/prerequisites-20230504
<==

[Bug c++/110714] constexpr lifetime error: base class this pointer

[pkeir at outlook dot com via Gcc-bugs]

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

--- Comment #2 from Paul Keir  ---
I know. `delete pf` also works. The issue seems to be with the use of the this
pointer within the member function. This is just the MRE - I've come across
this issue twice now in our code base.

[Bug c++/110715] New: Static thread_local unique_ptrs must be defined in the same order as they were declared when using -ftest-coverage else get error 'function starts on a higher line number than it

[obi.phil+gcc at googlemail dot com via Gcc-bugs]

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

Bug ID: 110715
   Summary: Static thread_local unique_ptrs must be defined in the
same order as they were declared when using
-ftest-coverage else get error 'function starts on a
higher line number than it ends'
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: obi.phil+gcc at googlemail dot com
  Target Milestone: ---

Created attachment 55568
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55568=edit
Output from g++ -v --save-temps

Consider the following minimum reproducible example:

---
#include 

template
class Base
{
 public:
  Base()
  {
count = std::make_unique(0);
another = std::make_unique(0);
  }

  virtual ~Base() { }

  static thread_local std::unique_ptr count;
  static thread_local std::unique_ptr another;
};

#ifdef BREAK
template  thread_local std::unique_ptr Base::another(nullptr);
#endif
template  thread_local std::unique_ptr Base::count(nullptr);
#ifndef BREAK
template  thread_local std::unique_ptr Base::another(nullptr);
#endif

class Foo : public Base
{
 public:
  Foo() { }
  virtual ~Foo() { }
};

int main()
{
  Foo a;
  return 0;
}
---

When compiled with my usual compiler options (with either -DBREAK or without
it) it compiles fine on OEL9 x86_64 (kernel 5.14.0-162.6.1.el9_1.x86_64).
However when compiled with -ftest-coverage (and -DBREAK) I get the error:

---
TemplateTest.cpp: In function ‘void __tls_init()’:
TemplateTest.cpp:22:54: error: function starts on a higher line number than it
ends [-Werror=coverage-invalid-line-number]
   22 | template  thread_local std::unique_ptr
Base::count(nullptr);
  |  ^~~
TemplateTest.cpp: In function ‘std::unique_ptr&
_ZTWN4BaseI3FooE5countE()’:
TemplateTest.cpp:22:54: error: function starts on a higher line number than it
ends [-Werror=coverage-invalid-line-number]
---

The newer GCC versions appear to require the static thread_local member
variables to be defined in the same order they are declared. However I've also
seen other instances when trying to create the MRE whereby using the arguments
in a different order to the 'declared' order causes the same error. I have so
far been unable to recreate these issues in an MRE however.

I have validated that this occurs with GCC 13.1.1, 12.2.1, and 12.1.1. It does
not occur when using GCC 11.3.1 or 8.3.1.

The full compilation arguments I've used are:
c++ -v --save-temps -DBREAK -Werror -Wall -Wextra -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations -fprofile-arcs -ftest-coverage -o a.out
TemplateTest.cpp
And I have uploaded the .ii output file it created as an attachment, but please
let me know if you want more information. Here is the output from the command
above:

---
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/opt/rh/gcc-toolset-13/root/usr/libexec/gcc/x86_64-redhat-linux/13/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,lto --prefix=/opt/rh/gcc-toolset-13/root/usr
--mandir=/opt/rh/gcc-toolset-13/root/usr/share/man
--infodir=/opt/rh/gcc-toolset-13/root/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-libstdcxx-backtrace
--with-libstdcxx-zoneinfo=/opt/rh/gcc-toolset-13/root/usr/share/zoneinfo
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--without-isl --enable-offload-targets=nvptx-none --without-cuda-driver
--enable-offload-defaulted --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_64=x86-64-v2 --with-arch_32=x86-64
--build=x86_64-redhat-linux --with-build-config=bootstrap-lto
--enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.1 20230614 (Red Hat 13.1.1-4) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-D' 'BREAK' '-Werror' '-Wall' '-Wextra'
'-fno-strict-aliasing' '-fwrapv' '-fno-aggressive-loop-optimizations'
'-fprofile-arcs' '-ftest-coverage' '-o' 'a.out' '-shared-libgcc'
'-mtune=generic' '-march=x86-64-v2' '-dumpdir' 'a-'
 

[Bug c++/110714] constexpr lifetime error: base class this pointer

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-07-18

--- Comment #1 from Andrew Pinski  ---
Note this works on the trunk:
```
struct Base
{
  constexpr virtual ~Base() {}
//  constexpr Base* get_this() { return this; }
  int x;
};

struct Derived : public Base {};

constexpr bool test()
{
  Derived* pf = new Derived;
  Base* t = pf;
  delete t;
  return true;
}

constexpr bool b = test();
```

[Bug c/89180] [meta-bug] bogus/missing -Wunused warnings

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Bug 101090 Summary: incorrect -Wunused-value warning on remquo with constant 
values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101090

   What|Removed |Added

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

[Bug c/106264] [10/11/12/13 Regression] spurious -Wunused-value on a folded frexp, modf, and remquo calls with unused result since r9-1295-g781ff3d80e88d7d0

[roger at nextmovesoftware dot com via Gcc-bugs]

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

--- Comment #9 from Roger Sayle  ---
*** Bug 101090 has been marked as a duplicate of this bug. ***

[Bug c/101090] incorrect -Wunused-value warning on remquo with constant values

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 CC||roger at nextmovesoftware dot 
com
 Status|NEW |RESOLVED

--- Comment #4 from Roger Sayle  ---
Many thanks to Vincent for spotting/confirming that his bug report is a
duplicate of PR 106264, which was fixed in GCC 13.

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