[Bug tree-optimization/106809] [12/13 regression] large bison grammars compilation got a lot slower, mainly due to -Wuninitialized

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[12 regression] large bison |[12/13 regression] large
   |grammars compilation got a  |bison grammars compilation
   |lot slower, mainly due to   |got a lot slower, mainly
   |-Wuninitialized |due to -Wuninitialized
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Keywords|needs-bisection |
 Status|NEW |ASSIGNED

--- Comment #2 from Richard Biener  ---
Also with GCC 13.  The obvious candidate would be the VN run done now to
identify unreachable code and reduce false positives.  I'll refactor timevars
to better track that.

OK, so callgrind points at dominated_by_p_w_unex, called from
rpo_elim::eliminate_avail.  Looks like we manage to run into a
degenerate case of a value with a very large avail set.  The
most avail queries are from

  if (eliminate && ! iterate)
...
  else
/* If not eliminating, make all not already available defs
   available.  */
FOR_EACH_SSA_TREE_OPERAND (op, gsi_stmt (gsi), i, SSA_OP_DEF)
  if (! avail.eliminate_avail (bb, op))
avail.eliminate_push_avail (bb, op);

[Bug tree-optimization/106809] [12/13 regression] large bison grammars compilation got a lot slower, mainly due to -Wuninitialized

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

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

--- Comment #3 from Richard Biener  ---
OK, we're seeing up to 1420 AVAIL entries for a single value (_11574),
the value corresponding to yyvsp_11649->str.  Looking at the source I
can easily see how this happens.

[Bug c++/106812] New: Throwing a non-copyable exception

[jens.maurer at gmx dot net via Gcc-bugs]

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

Bug ID: 106812
   Summary: Throwing a non-copyable exception
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jens.maurer at gmx dot net
  Target Milestone: ---

gcc accepts the following program:

struct S
{
  S() = default;
  S(const S&) = delete;
  // int x = 0;  // #3
};

int main()
{
  try {
throw S(); // #1
  } catch (S s) {  // #2
return 1;
  }
}

but it is ill-formed at #1 according to [except.throw] p5.

Curiously, if line #3 is added, gcc flags an error at #2 (but not at #1).

[Bug tree-optimization/106809] [12/13 regression] large bison grammars compilation got a lot slower, mainly due to -Wuninitialized

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

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

--- Comment #4 from Martin Liška  ---
I see the change since r12-4726-g9a27acc30a34b785 which goes from 2.2s to 6.3s
(checking enabled).

[Bug middle-end/106804] Poor codegen for selecting and incrementing value behind a reference

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #8 from Alexander Monakov  ---
(In reply to Richard Biener from comment #7)
> In fact I'd say the reverse transformation is more profitable?

In the end it depends on the context. It's a trade-off between a conditional
branch and extra data dependencies feeding into the address of a store. If a
branch is perfectly predictable, it's preferable. Otherwise, if there's no
memory dependency via the store, you don't care about delaying it, making the
branchless version preferable if that reduces pipeline flushes. If there is a
dependency, it comes down to how often the branch mispredicts, I guess.

  
 /\
| People who tinker with compilers |
| need __builtin_branchless_select |
 \/
  
 \
  \
   \
.--.
   |o_o |
   | ~  |
  //   \ \
 (| | )
/'\_   _/`\
\___)=(___/

[Bug c++/106812] Throwing a non-copyable exception

[jens.maurer at gmx dot net via Gcc-bugs]

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

--- Comment #1 from Jens Maurer  ---
Cross-reference: clang bug https://github.com/llvm/llvm-project/issues/57519

[Bug c/100854] TS 18661-3 and backwards-incompatible setting of __FLT_EVAL_METHOD__

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

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

Chung-Ju Wu  changed:

   What|Removed |Added

 CC||andrea.corallo at arm dot com,
   ||kito at gcc dot gnu.org

--- Comment #5 from Chung-Ju Wu  ---
(In reply to Francois-Xavier Coudert from comment #2)
> This affects x86_64-apple-darwin:
> https://gcc.gnu.org/pipermail/gcc/2021-December/237959.html
> 
> The  system header errors out on any value of __FLT_EVAL_METHOD__
> that is not -1, 0, 1, or 2.

I guess this issue has been resolved by newlib implementation. :)

Refer to the discussions on:
https://sourceware.org/pipermail/newlib/2021/018471.html
https://sourceware.org/pipermail/newlib/2022/019522.html

The patches have been committed into newlib code base and it should be workable
now.

[Bug other/106782] dump_printf_loc has incorrect format attribute

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Tamar Christina
:

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

commit r12-8736-ge69134e12551a4289292e3955525f84d99773d31
Author: Tamar Christina 
Date:   Thu Sep 1 22:04:57 2022 +0100

AArch64: Fix bootstrap failure due to dump_printf_loc format attribute uses
[PR106782]

This fixes the bootstrap failure on AArch64 following -Werror=format by
correcting the print format modifiers in the backend.

gcc/ChangeLog:

PR other/106782
* config/aarch64/aarch64.cc
(aarch64_vector_costs::prefer_unrolled_loop): Replace %u with
HOST_WIDE_INT_PRINT_UNSIGNED.

(cherry picked from commit b98c5262d02c13cdbbf3b985859b436adec94d90)

[Bug tree-optimization/106809] [12/13 regression] large bison grammars compilation got a lot slower, mainly due to -Wuninitialized

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

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

--- Comment #5 from Richard Biener  ---
A testcase for this corner case is the following.  At -O0 it is
-Wuninitialized, at -O1 it is FRE:

 tree FRE   :   5.55 ( 70%)   0.00 (  0%)   5.56 ( 67%)
   16k (  0%)

and at -O2 PRE will finally make use of the value numbers, hoisting the
load and optimizing the function to a single conditional.

 tree PRE   :   2.80 ( 27%)   0.02 (  6%)   2.82 ( 26%)
   17k (  0%)
 tree FRE   :   5.56 ( 54%)   0.01 (  3%)   5.57 ( 52%)
   16k (  0%)

The -On behavior would be a regression from GCC 9 where the new VN was
introduced.

int foo (int x, int *val)
{
  switch (x)
{
#define C(n) \
case n + 0: return *val; \
case n + 1: return *val; \
case n + 2: return *val; \
case n + 3: return *val; \
case n + 4: return *val; \
case n + 5: return *val; \
case n + 6: return *val; \
case n + 7: return *val; \
case n + 8: return *val; \
case n + 9: return *val;
#define C1(n) \
C(n+00) C(n+10) C(n+20) C(n+30) C(n+40) \
C(n+50) C(n+60) C(n+70) C(n+80) C(n+90)
#define C10(n) \
C1(n+000) C1(n+100) C1(n+200) C1(n+300) C1(n+400) \
C1(n+500) C1(n+600) C1(n+700) C1(n+800) C1(n+900)
C10(1000)
}
  return 0;
}

[Bug tree-optimization/106809] [12/13 regression] large bison grammars compilation got a lot slower, mainly due to -Wuninitialized

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

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

--- Comment #6 from Richard Biener  ---
(In reply to Martin Liška from comment #4)
> I see the change since r12-4726-g9a27acc30a34b785 which goes from 2.2s to
> 6.3s (checking enabled).

I would have said it's r12-7175-g0f58ba4dd6b25b

[Bug go/106813] New: getSiginfo() libgo/runtime/go-signal.c missing Solaris specific code to get ret.sigpc

[sumbera at volny dot cz via Gcc-bugs]

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

Bug ID: 106813
   Summary: getSiginfo() libgo/runtime/go-signal.c missing Solaris
specific code to get ret.sigpc
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: sumbera at volny dot cz
  Target Milestone: ---

Created attachment 53531
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53531&action=edit
Proposed patch file.

getSiginfo() in libgo/runtime/go-signal.c is missing Solaris specific code to
get ret.sigpc and thus it calls runtime_callers().

It was observed that sometimes call to runtime_callers() ends with segmentation
fault (because sparc64_is_sighandler() gets wrong pc - e.g. 0x8):

7ac13fe1 libgcc_s.so.1`uw_frame_state_for+0x434(7ac14950,
7ac14d40,
6ab59e50, 6ab66a8d, 0, 6ab66a8d)
7ac140a1 libgcc_s.so.1`_Unwind_Backtrace+0x54(6a9ce33c,
7ac154d0, 0,
7ac14d40, 7ac14950, 0)
7ac14c21 libgo.so.14`backtrace_full+0x70(7f5c8000, 1,
6a4c1790,
6a4c1abc, 7ac155b8, 6b09d3b8)
7ac14d01 libgo.so.14`runtime_callers+0x78(6, 7ac156a0,
7f5c8000, 0,
6a4c1abc, 6b0c7d7c)
7ac14dd1 libgo.so.14`runtime.getSiginfo+0x1c(7ac15ef0,
7ac15c10, 0, 0, 0,
61e0)
7ac14ed1 libgo.so.14`runtime.sigtrampgo+0x39c(12, 7ac15ef0,
7ac15c10,
6ad81b88, 36, c0010c6800)
7ac15101 libc.so.1`__sighndlr+0xc(12, 7ac15ef0,
7ac15c10,
6a4c2ebc, 0, 7ed24000)
7ac151b1 libc.so.1`call_user_handler+0x404(d, 7ac15ef0,
ffbffeff, 0, 12, ff)
7ac152a1 libc.so.1`sigacthandler+0xe0(12, 7ac15ef0,
7ac15c10, 0, 0,
7ed24000)
21bff741 libgo.so.14`runtime.kickoff(0, 0, 0, 0, 0, 0)

This can be avoided by setting ret.sigpc via platform specific code as it's
done on other systems. See attached patch file.

[Bug rtl-optimization/106187] armhf: Miscompilation at O2 level (O0 / O1 are working)

[malat at debian dot org via Gcc-bugs]

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

--- Comment #53 from Mathieu Malaterre  ---
For later reference, the gcc-11 symptoms disapear in upstream git after commit:

*
https://github.com/google/highway/commit/4fa872a2a0d9944cb5fe761669ac63096607d3a3

gcc-12 seems to be generating wrong-code for a different unit-test:

% tests/mul_test
"--gtest_filter=HwyMulTestGroup/HwyMulTest.TestAllMulHigh/EMU128"
Running main() from ./googletest/src/gtest_main.cc
Note: Google Test filter = HwyMulTestGroup/HwyMulTest.TestAllMulHigh/EMU128
[==] Running 1 test from 1 test suite.
[--] Global test environment set-up.
[--] 1 test from HwyMulTestGroup/HwyMulTest
[ RUN  ] HwyMulTestGroup/HwyMulTest.TestAllMulHigh/EMU128


i16x8 expect [0+ ->]:
  0x3FFF,0x0FFF,0x03FF,0x00FF,0x003F,0x000F,0x0003,
i16x8 actual [0+ ->]:
  0xBFFF,0x0FFF,0xE400,0x00FF,0xF840,0x000F,0xFE04,
Abort at /home/malat/highway/hwy/tests/mul_test.cc:131: EMU128, i16x8 lane 0
mismatch: expected '0x3FFF', got '0xBFFF'.

zsh: abort  tests/mul_test

[Bug target/105463] [11/12 Regression] MVE: Wrong code, incorrect alignment assumption

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Earnshaw
:

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

commit r12-8737-gde1ba234311b935b1a38d512e57329d4b6e8354d
Author: Richard Earnshaw 
Date:   Wed May 11 13:08:40 2022 +0100

arm: correctly handle misaligned MEMs on MVE [PR105463]

Vector operations in MVE must be aligned to the element size, so if we
are asked for a misaligned move in a wider mode we must recast it to a
form suitable for the known alignment (larger elements have better
address offset ranges, so there is some advantage to using wider
element sizes if possible).  Whilst fixing this, also rework the
predicates used for validating operands - the Neon predicates are
not right for MVE.

gcc/ChangeLog:

PR target/105463
* config/arm/mve.md (*movmisalign_mve_store): Use
mve_memory_operand.
(*movmisalign_mve_load): Likewise.
* config/arm/vec-common.md (movmisalign): Convert to
generator
form...
(@movmisalign): ... thus.  Use generic predicates and then
rework operands if they are not valid.  For MVE rework to a
narrower element size if the alignment is not high enough.

(cherry picked from commit 6a116728e27c4da65d84483c0e75561a7479d4d5)

[Bug libstdc++/106808] std::string_view range concept requirement causes compile error with Boost.Filesystem

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

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to andysem from comment #6)
> So do you think this is a problem in Boost.Filesystem?

I don't know yet, I can't reproduce it with the Boost in Fedora 36, and I
haven't looked further.

> I would say this is a regression in string_view as the code is valid in
> pre-C++23, and I would expect it to stay valid in C++23 onwards.


That range constructor is explicit in the C++23 draft now, but that change
hasn't been backordered to GCC 12 yet, and apparently doesn't change anything
if you still see this in trunk.

> Shouldn't
> the range constructor be simply disabled when fs::path::iterator is not
> defined?

Do you want ODR violations? Because that's how you get ODR violations.

[Bug libstdc++/71579] type_traits miss checks for type completeness in some traits

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

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

--- Comment #23 from Jonathan Wakely  ---
Yes, that's my reading of it. I need to check what other compilers do for
__has_virtual_destructor and check the docs. Maybe libstdc++ should only use it
for class types.

[Bug target/105463] [11 Regression] MVE: Wrong code, incorrect alignment assumption

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Earnshaw
:

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

commit r11-10231-gac1fce509ddd99e825073b3a9eab5911ac3dc454
Author: Richard Earnshaw 
Date:   Wed May 11 13:08:40 2022 +0100

arm: correctly handle misaligned MEMs on MVE [PR105463]

Vector operations in MVE must be aligned to the element size, so if we
are asked for a misaligned move in a wider mode we must recast it to a
form suitable for the known alignment (larger elements have better
address offset ranges, so there is some advantage to using wider
element sizes if possible).  Whilst fixing this, also rework the
predicates used for validating operands - the Neon predicates are
not right for MVE.

gcc/ChangeLog:

PR target/105463
* config/arm/mve.md (*movmisalign_mve_store): Use
mve_memory_operand.
(*movmisalign_mve_load): Likewise.
* config/arm/vec-common.md (movmisalign): Convert to
generator
form...
(@movmisalign): ... thus.  Use generic predicates and then
rework operands if they are not valid.  For MVE rework to a
narrower element size if the alignment is not high enough.

(cherry picked from commit 6a116728e27c4da65d84483c0e75561a7479d4d5)

[Bug target/105463] [11 Regression] MVE: Wrong code, incorrect alignment assumption

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

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Earnshaw  ---
Fixed on all relevant branches

[Bug tree-optimization/106809] [12/13 regression] large bison grammars compilation got a lot slower, mainly due to -Wuninitialized

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

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

--- Comment #7 from Richard Biener  ---
Oh, and the dominated_by_p_w_unex issue is that we do

  if (succe && EDGE_COUNT (succe->dest->preds) == 1)
{
  /* Verify the reached block is only reached through succe.
 If there is only one edge we can spare us the dominator
 check and iterate directly.  */
  if (EDGE_COUNT (succe->dest->preds) > 1)
{
  FOR_EACH_EDGE (e, ei, succe->dest->preds)
if (e != succe
&& ((e->flags & EDGE_EXECUTABLE)
|| (!allow_back && (e->flags & EDGE_DFS_BACK
  {
succe = NULL;
break;
  }

where this is problematic because in the testcase with the switch stmt we have 
1000s of incoming edges into succe->dest.  I'm testing an easy workaround for
the testcase and the original case from bison.  A more general fix requires
some more work.

[Bug tree-optimization/106809] [12/13 regression] large bison grammars compilation got a lot slower, mainly due to -Wuninitialized

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

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

--- Comment #8 from Richard Biener  ---
A real speed improvement to dominated_by_w_unex would record the single known
executable predecessor and successor of each block, for example in rpo_state,
but that's released before PRE eventually calls into it again via
eliminate_with_rpo_vn.  Some less hackish plumbing to manage lifetime is
necessary here.

[Bug other/106814] New: [13 regression] r13-2266-g8bb1df032cc080 breaks some mpfr tests

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

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

Bug ID: 106814
   Summary: [13 regression] r13-2266-g8bb1df032cc080 breaks some
mpfr tests
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:8bb1df032cc080b751e00c0d7d86c31a630105f9, r13-2266-g8bb1df032cc080 

This commit broke some of the mpfr tests on a bootstrap build.

Error in check_misc for +0.
  mpfr_get_decimal128() returned: 0.0
  mpfr_set_decimal128() set x to: -0 approx.
= -0
FAIL tget_set_d128 (exit status: 1)

Error in check_misc for +0.
  mpfr_get_decimal64() returned:
|1010001000110100|
  mpfr_set_decimal64() set x to: -0 approx.
= -0
FAIL tget_set_d64 (exit status: 1)



commit 8bb1df032cc080b751e00c0d7d86c31a630105f9 (HEAD)
Author: Aldy Hernandez 
Date:   Tue Aug 30 08:23:33 2022 +0200

Add support for floating point endpoints to frange.

[Bug rtl-optimization/106187] armhf: Miscompilation at O2 level (O0 / O1 are working)

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

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

--- Comment #54 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Earnshaw
:

https://gcc.gnu.org/g:3835765ae96d294bb71dd8cb05db543d89725f7b

commit r12-8738-g3835765ae96d294bb71dd8cb05db543d89725f7b
Author: Richard Earnshaw 
Date:   Wed Aug 3 10:01:51 2022 +0100

cselib: add function to check if SET is redundant [PR106187]

A SET operation that writes memory may have the same value as an
earlier store but if the alias sets of the new and earlier store do
not conflict then the set is not truly redundant.  This can happen,
for example, if objects of different types share a stack slot.

To fix this we define a new function in cselib that first checks for
equality and if that is successful then finds the earlier store in the
value history and checks the alias sets.

The routine is used in two places elsewhere in the compiler:
cfgcleanup and postreload.

gcc/ChangeLog:

PR rtl-optimization/106187
* alias.h (mems_same_for_tbaa_p): Declare.
* alias.cc (mems_same_for_tbaa_p): New function.
* dse.cc (record_store): Use it instead of open-coding
alias check.
* cselib.h (cselib_redundant_set_p): Declare.
* cselib.cc: Include alias.h
(cselib_redundant_set_p): New function.
* cfgcleanup.cc: (mark_effect): Use cselib_redundant_set_p instead
of rtx_equal_for_cselib_p.
* postreload.cc (reload_cse_simplify): Use cselib_redundant_set_p.
(reload_cse_noop_set_p): Delete.

(cherry picked from commit 64ce76d940501cb04d14a0d36752b4f93473531c)

[Bug rtl-optimization/106187] armhf: Miscompilation at O2 level (O0 / O1 are working)

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

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

--- Comment #55 from Richard Earnshaw  ---
(In reply to Mathieu Malaterre from comment #53)

> 
> gcc-12 seems to be generating wrong-code for a different unit-test:

I've just pushed my patch to the gcc-12 branch, could you try that please?

[Bug tree-optimization/106809] [12/13 regression] large bison grammars compilation got a lot slower, mainly due to -Wuninitialized

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

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

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

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

commit r13-2375-gbe1b42de9c151d46c89f9a8f82d4c5839a19ea94
Author: Richard Biener 
Date:   Fri Sep 2 13:36:13 2022 +0200

tree-optimization/106809 - compile time hog in VN

The dominated_by_p_w_unex function is prone to high compile time.
With GCC 12 we introduced a VN run for uninit diagnostics which now
runs into a degenerate case with bison generated code.  Fortunately
this case is easy to fix with a simple extra check - a more
general fix needs more work.

PR tree-optimization/106809
* tree-ssa-sccvn.cc (dominaged_by_p_w_unex): Check we have
more than one successor before doing extra work.

* gcc.dg/torture/pr106809.c: New testcase.

[Bug tree-optimization/106809] [12 regression] large bison grammars compilation got a lot slower, mainly due to -Wuninitialized

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[12/13 regression] large|[12 regression] large bison
   |bison grammars compilation  |grammars compilation got a
   |got a lot slower, mainly|lot slower, mainly due to
   |due to -Wuninitialized  |-Wuninitialized
  Known to work||13.0

--- Comment #10 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/106787] [13 Regression] ICE in vect_schedule_slp_node, at tree-vect-slp.cc:8648 since r13-2288-g61c4c989034548f4

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

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

--- Comment #3 from CVS Commits  ---
The trunk branch has been updated by Richard Sandiford :

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

commit r13-2377-geab511df13ca6abb24c3c2abb0f420a89c91e310
Author: Richard Sandiford 
Date:   Fri Sep 2 14:00:14 2022 +0100

vect: Ensure SLP nodes don't end up in multiple BB partitions [PR106787]

In the PR we have two REDUC_PLUS SLP instances that share a common
load of stride 4.  Each instance also has a unique contiguous load.

Initially all three loads are out of order, so have a nontrivial
load permutation.  The layout pass puts them in order instead,
For the two contiguous loads it is possible to do this by adjusting the
SLP_LOAD_PERMUTATION to be { 0, 1, 2, 3 }.  But a SLP_LOAD_PERMUTATION
of { 0, 4, 8, 12 } is rejected as unsupported, so the pass creates a
separate VEC_PERM_EXPR instead.

Later the 4-stride load's initial SLP_LOAD_PERMUTATION is rejected too,
so that the load gets replaced by an external node built from scalars.
We then have an external node feeding a VEC_PERM_EXPR.

VEC_PERM_EXPRs created in this way do not have any associated
SLP_TREE_SCALAR_STMTS.  This means that they do not affect the
decision about which nodes should be in which subgraph for costing
purposes.  If the VEC_PERM_EXPR is fed by a vect_external_def,
then the VEC_PERM_EXPR's input doesn't affect that decision either.

The net effect is that a shared VEC_PERM_EXPR fed by an external def
can appear in more than one subgraph.  This triggered an ICE in
vect_schedule_node, which (rightly) expects to be called no more
than once for the same internal def.

There seemed to be many possible fixes, including:

(1) Replace unsupported loads with external defs *before* doing
the layout optimisation.  This would avoid the need for the
VEC_PERM_EXPR altogether.

(2) If the target doesn't support a load in its original layout,
stop the layout optimisation from checking whether the target
supports loads in any new candidate layout.  In other words,
treat all layouts as if they were supported whenever the
original layout is not in fact supported.

I'd rather not do this.  In principle, the layout optimisation
could convert an unsupported layout to a supported one.
Selectively ignoring target support would work against that.

We could try to look specifically for loads that will need
to be decomposed, but that just seems like admitting that
things are happening in the wrong order.

(3) Add SLP_TREE_SCALAR_STMTS to VEC_PERM_EXPRs.

That would be OK for this case, but wouldn't be possible
for external defs that represent existing vectors.

(4) Make vect_schedule_slp share SCC info between subgraphs.

It feels like that's working around the partitioning problem
rather than a real fix though.

(5) Directly ensure that internal def nodes belong to a single
subgraph.

(1) is probably the best long-term fix, but (5) is much simpler.
The subgraph partitioning code already has a hash set to record
which nodes have been visited; we just need to convert that to a
map from nodes to instances instead.

gcc/
PR tree-optimization/106787
* tree-vect-slp.cc (vect_map_to_instance): New function, split out
from...
(vect_bb_partition_graph_r): ...here.  Replace the visited set
with a map from nodes to instances.  Ensure that a node only
appears in one partition.
(vect_bb_partition_graph): Update accordingly.

gcc/testsuite/
* gcc.dg/vect/bb-slp-layout-19.c: New test.

[Bug tree-optimization/106787] [13 Regression] ICE in vect_schedule_slp_node, at tree-vect-slp.cc:8648 since r13-2288-g61c4c989034548f4

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Fixed.

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

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

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

Bug 106787 Summary: [13 Regression] ICE in vect_schedule_slp_node, at 
tree-vect-slp.cc:8648 since r13-2288-g61c4c989034548f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106787

   What|Removed |Added

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

[Bug other/106814] [13 regression] r13-2266-g8bb1df032cc080 breaks some mpfr tests

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

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

--- Comment #1 from Aldy Hernandez  ---
How do I reproduce this?

[Bug other/106814] [13 regression] r13-2266-g8bb1df032cc080 breaks some mpfr tests

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

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

--- Comment #2 from seurer at gcc dot gnu.org ---
Do a bootstrap build then

make checkmpfr

[Bug other/106814] [13 regression] r13-2266-g8bb1df032cc080 breaks some mpfr tests

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

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

--- Comment #3 from seurer at gcc dot gnu.org ---
Sorry, that's make check-mpfr

[Bug other/106814] [13 regression] r13-2266-g8bb1df032cc080 breaks some mpfr tests

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
With in-tree mpfr?

[Bug rtl-optimization/106187] armhf: Miscompilation at O2 level (O0 / O1 are working)

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

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

--- Comment #56 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Earnshaw
:

https://gcc.gnu.org/g:50982aa1145fbdb315162349833412639aa8bc4c

commit r11-10232-g50982aa1145fbdb315162349833412639aa8bc4c
Author: Richard Earnshaw 
Date:   Wed Aug 3 10:01:51 2022 +0100

cselib: add function to check if SET is redundant [PR106187]

A SET operation that writes memory may have the same value as an
earlier store but if the alias sets of the new and earlier store do
not conflict then the set is not truly redundant.  This can happen,
for example, if objects of different types share a stack slot.

To fix this we define a new function in cselib that first checks for
equality and if that is successful then finds the earlier store in the
value history and checks the alias sets.

The routine is used in two places elsewhere in the compiler:
cfgcleanup and postreload.

gcc/ChangeLog:

PR rtl-optimization/106187
* alias.h (mems_same_for_tbaa_p): Declare.
* alias.c (mems_same_for_tbaa_p): New function.
* dse.c (record_store): Use it instead of open-coding
alias check.
* cselib.h (cselib_redundant_set_p): Declare.
* cselib.c: Include alias.h
(cselib_redundant_set_p): New function.
* cfgcleanup.c: (mark_effect): Use cselib_redundant_set_p instead
of rtx_equal_for_cselib_p.
* postreload.c (reload_cse_simplify): Use cselib_redundant_set_p.
(reload_cse_noop_set_p): Delete.

(cherry picked from commit 64ce76d940501cb04d14a0d36752b4f93473531c)

[Bug target/106815] New: [13 Regression] ICE: in riscv_excess_precision, at config/riscv/riscv.cc:5967 with -fexcess-precision=16 on any input

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 106815
   Summary: [13 Regression] ICE: in riscv_excess_precision, at
config/riscv/riscv.cc:5967 with -fexcess-precision=16
on any input
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: riscv64-unknown-linux-gnu

Compiler output (empty testcase.c):
$ echo '' > testcase.c
$ riscv64-unknown-linux-gnu-gcc -fexcess-precision=16 testcase.c
: internal compiler error: in riscv_excess_precision, at
config/riscv/riscv.cc:5967
0x7ada41 riscv_excess_precision
/repo/gcc-trunk/gcc/config/riscv/riscv.cc:5967
0x7ada41 riscv_excess_precision
/repo/gcc-trunk/gcc/config/riscv/riscv.cc:5956
0x94a206 c_ts18661_flt_eval_method
/repo/gcc-trunk/gcc/c-family/c-common.cc:8939
0x98484a c_cpp_builtins(cpp_reader*)
/repo/gcc-trunk/gcc/c-family/c-cppbuiltin.cc:1223
0x99fec7 c_finish_options
/repo/gcc-trunk/gcc/c-family/c-opts.cc:1496
0x9a28b0 c_common_parse_file()
/repo/gcc-trunk/gcc/c-family/c-opts.cc:1249
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ riscv64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-2374-20220902172530-gd72ca12b846-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/13.0.0/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-isa-spec=2.2
--with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu
--with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld
--with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-2374-20220902172530-gd72ca12b846-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220902 (experimental) (GCC)

[Bug other/106814] [13 regression] r13-2266-g8bb1df032cc080 breaks some mpfr tests

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

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

--- Comment #5 from seurer at gcc dot gnu.org ---
I used download_prerequistes before the build.

seurer@rain6p1:~/gcc/git/gcc-test$ ./contrib/download_prerequisites --force
2022-09-02 09:12:04
URL:http://gcc.gnu.org/pub/gcc/infrastructure/gmp-6.2.1.tar.bz2
[2493916/2493916] -> "gmp-6.2.1.tar.bz2" [1]
2022-09-02 09:12:05
URL:http://gcc.gnu.org/pub/gcc/infrastructure/mpfr-4.1.0.tar.bz2
[1747243/1747243] -> "mpfr-4.1.0.tar.bz2" [1]
2022-09-02 09:12:06
URL:http://gcc.gnu.org/pub/gcc/infrastructure/mpc-1.2.1.tar.gz [838731/838731]
-> "mpc-1.2.1.tar.gz" [1]
2022-09-02 09:12:07
URL:http://gcc.gnu.org/pub/gcc/infrastructure/isl-0.24.tar.bz2
[2261594/2261594] -> "isl-0.24.tar.bz2" [1]
gmp-6.2.1.tar.bz2: OK
mpfr-4.1.0.tar.bz2: OK
mpc-1.2.1.tar.gz: OK
isl-0.24.tar.bz2: OK
All prerequisites downloaded successfully.

[Bug libstdc++/106808] std::string_view range concept requirement causes compile error with Boost.Filesystem

[andysem at mail dot ru via Gcc-bugs]

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

--- Comment #8 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to andysem from comment #6)
> > So do you think this is a problem in Boost.Filesystem?
> 
> I don't know yet, I can't reproduce it with the Boost in Fedora 36, and I
> haven't looked further.

I have added a workaround to the current Boost.Filesystem develop and master,
and Boost 1.80 (the latest official release) didn't support std::string_view,
so is not affected either. In order to reproduce you would need the revision I
posted in the original problem description.

> > I would say this is a regression in string_view as the code is valid in
> > pre-C++23, and I would expect it to stay valid in C++23 onwards.
> 
> That range constructor is explicit in the C++23 draft now, but that change
> hasn't been backordered to GCC 12 yet, and apparently doesn't change
> anything if you still see this in trunk.
> 
> > Shouldn't
> > the range constructor be simply disabled when fs::path::iterator is not
> > defined?
> 
> Do you want ODR violations? Because that's how you get ODR violations.

I understand this, but my point is that this is a breaking change, apparently
even with the constructor being marked explicit, and it breaks in a rather
surprising way. Also, apparently MSVC is able to not break somehow as it
doesn't have this issue. So maybe there is a solution that does not introduce
ODR violations and yet still works. I think it would be preferable to fix
std::string_view rather than all its uses like in std/Boost.Filesystem.

[Bug ipa/106816] New: noreturn/pure attributes are not set correctly on multiversioned functions

[gcc.gnu at vvalter dot com via Gcc-bugs]

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

Bug ID: 106816
   Summary: noreturn/pure attributes are not set correctly on
multiversioned functions
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc.gnu at vvalter dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

During the investigation of PR106627, Richard noted (
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600777.html ) that
attributes like noreturn and pure on multiversioned functions are lost when the
function declaration is replaced by the dispatcher declaration in the same way
that the TREE_NOTHROW attribute got lost, which was fixed in PR106627.

Example:

__attribute__((noreturn,target("default")))
void f() {
for (;;) {}
}

__attribute__((noreturn,target("sse4.2,bmi")))
void f() {
for (;;) {}
}

int main()
{
f();
return 1;
}


Gcc should create no code after the call to f(), but the assembly output with
-O3 looks like the following:

call_Z5_Z1fvv@PLT
movl$1, %eax
addq$8, %rsp
.cfi_def_cfa_offset 8
ret

For a non-multiversioned function, no assembly instructions are generated after
the call instruction. Similar problems happen if the function is marked pure.
I reproduced this on 11.2.0 and 12.2, but this most likely affects all gcc
versions.

[Bug libstdc++/106808] std::string_view range concept requirement causes compile error with Boost.Filesystem

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #9 from Jonathan Wakely  ---
Of course there's a solution, but disabling the constructor is not it. The
problem is not that the constructor exists, it's that the constraints on it
have a problem.

[Bug libstdc++/106808] std::string_view range concept requirement causes compile error with Boost.Filesystem

[andysem at mail dot ru via Gcc-bugs]

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

--- Comment #10 from andysem at mail dot ru ---
(In reply to andysem from comment #8)
> (In reply to Jonathan Wakely from comment #7)
> > 
> > Do you want ODR violations? Because that's how you get ODR violations.
> 
> I understand this, but my point is that this is a breaking change,
> apparently even with the constructor being marked explicit...

I take it back, with the constructor marked explicit it doesn't break. Before,
I tested the preprocessed source from gcc 11.2, which didn't have explicit.
Adding the explicit fixes compilation. Sorry for the confusion.

[Bug libstdc++/106808] std::string_view range concept requirement causes compile error with Boost.Filesystem

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

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

--- Comment #11 from Jonathan Wakely  ---
Oh good, I hoped that would be the case. I was already planning to backport
that change to gcc-11 and gcc-12.

[Bug libstdc++/106808] std::string_view range concept requirement causes compile error with Boost.Filesystem

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

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

--- Comment #12 from Jonathan Wakely  ---
In fact, it's already backported to gcc 12.2, as
g:61076545cb3c3cbc79036eff8bc46b0c2083730c

[Bug libstdc++/106808] std::string_view range concept requirement causes compile error with Boost.Filesystem

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

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

--- Comment #13 from Jonathan Wakely  ---
(In reply to andysem from comment #3)
> I don't have the environment to build gcc locally, so I can't readily test
> trunk. But I have been told the same issue reproduces with gcc-12
> 20220319-1ubuntu1 from Ubuntu 22.04:

That version is "ancient" (it's not even the final 12.1 release).

[Bug debug/106746] [13 Regression] '-fcompare-debug' failure (length) with -O2 -fsched2-use-superblocks since r13-2041-g6624ad73064de241

[roger at nextmovesoftware dot com via Gcc-bugs]

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

--- Comment #9 from Roger Sayle  ---
I'm curious why the zero_extend behaves so differently to a sign_extend,
perhaps a  missing simplification or pattern.  Presumably the CONCAT in the
debug_insn is there whether or not a sign_extend or zero_extend is used?

[Bug debug/106746] [13 Regression] '-fcompare-debug' failure (length) with -O2 -fsched2-use-superblocks since r13-2041-g6624ad73064de241

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #10 from H.J. Lu  ---
(In reply to Roger Sayle from comment #9)
> I'm curious why the zero_extend behaves so differently to a sign_extend,
> perhaps a  missing simplification or pattern.  Presumably the CONCAT in the
> debug_insn is there whether or not a sign_extend or zero_extend is used?

I think instruction order changes at random when there are debug insns
with CONCAT and CONCATN.

[Bug ipa/106816] noreturn/pure attributes are not set correctly on multiversioned functions

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

   Last reconfirmed||2022-09-02
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
Like this?

diff --git a/gcc/config/i386/i386-features.cc
b/gcc/config/i386/i386-features.cc
index fd212262f50..4904e4d71b3 100644
--- a/gcc/config/i386/i386-features.cc
+++ b/gcc/config/i386/i386-features.cc
@@ -3269,6 +3269,9 @@ ix86_get_function_versions_dispatcher (void *decl)
   /* Right now, the dispatching is done via ifunc.  */
   dispatch_decl = make_dispatcher_decl (default_node->decl);
   TREE_NOTHROW (dispatch_decl) = TREE_NOTHROW (fn);
+  TREE_THIS_VOLATILE (dispatch_decl) = TREE_THIS_VOLATILE (fn);
+  TREE_READONLY (dispatch_decl) = TREE_READONLY (fn);
+  DECL_PURE_P (dispatch_decl) = DECL_PURE_P (fn);

   dispatcher_node = cgraph_node::get_create (dispatch_decl);
   gcc_assert (dispatcher_node != NULL);

[Bug ipa/106816] noreturn/pure attributes are not set correctly on multiversioned functions

[gcc.gnu at vvalter dot com via Gcc-bugs]

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

--- Comment #2 from Simon Rainer  ---
(In reply to H.J. Lu from comment #1)
> Like this?
> 
> diff --git a/gcc/config/i386/i386-features.cc
> b/gcc/config/i386/i386-features.cc
> index fd212262f50..4904e4d71b3 100644
> --- a/gcc/config/i386/i386-features.cc
> +++ b/gcc/config/i386/i386-features.cc
> @@ -3269,6 +3269,9 @@ ix86_get_function_versions_dispatcher (void *decl)
>/* Right now, the dispatching is done via ifunc.  */
>dispatch_decl = make_dispatcher_decl (default_node->decl);
>TREE_NOTHROW (dispatch_decl) = TREE_NOTHROW (fn);
> +  TREE_THIS_VOLATILE (dispatch_decl) = TREE_THIS_VOLATILE (fn);
> +  TREE_READONLY (dispatch_decl) = TREE_READONLY (fn);
> +  DECL_PURE_P (dispatch_decl) = DECL_PURE_P (fn);
>  
>dispatcher_node = cgraph_node::get_create (dispatch_decl);
>gcc_assert (dispatcher_node != NULL);

I tried something like that, but I didn't see changes in the generated
assembly. I don't know if that is because something else is preventing
optimization or some other member needs to be set correctly.

[Bug ipa/106816] noreturn/pure attributes are not set correctly on multiversioned functions

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #3 from H.J. Lu  ---
(In reply to Simon Rainer from comment #2)
> (In reply to H.J. Lu from comment #1)
> > Like this?
> > 
> > diff --git a/gcc/config/i386/i386-features.cc
> > b/gcc/config/i386/i386-features.cc
> > index fd212262f50..4904e4d71b3 100644
> > --- a/gcc/config/i386/i386-features.cc
> > +++ b/gcc/config/i386/i386-features.cc
> > @@ -3269,6 +3269,9 @@ ix86_get_function_versions_dispatcher (void *decl)
> >/* Right now, the dispatching is done via ifunc.  */
> >dispatch_decl = make_dispatcher_decl (default_node->decl);
> >TREE_NOTHROW (dispatch_decl) = TREE_NOTHROW (fn);
> > +  TREE_THIS_VOLATILE (dispatch_decl) = TREE_THIS_VOLATILE (fn);
> > +  TREE_READONLY (dispatch_decl) = TREE_READONLY (fn);
> > +  DECL_PURE_P (dispatch_decl) = DECL_PURE_P (fn);
> >  
> >dispatcher_node = cgraph_node::get_create (dispatch_decl);
> >gcc_assert (dispatcher_node != NULL);
> 
> I tried something like that, but I didn't see changes in the generated
> assembly. I don't know if that is because something else is preventing
> optimization or some other member needs to be set correctly.

I got

main:
.LFB2:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
call_Z5_Z1fvv
.cfi_endproc

It looks correct.

[Bug fortran/106817] New: clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument

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

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

Bug ID: 106817
   Summary: clobber ordering problem when an actual intent(in)
argument depends on the value of an intent(out)
argument
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikael at gcc dot gnu.org
  Target Milestone: ---

module m
  implicit none
contains
  subroutine copy(in, out)
integer, intent(in) :: in
integer, intent(out) :: out
out = in
  end subroutine copy
end module m

program p
  use m
  implicit none
  integer :: a
  a = 3
  call copy(a+1, a)
  if (a /= 4) stop 1
end program p


The in value (a+1) depends on the value of a, but a is clobbered at the
beginning of the call to copy, so we should make sure that we have evaluated
a+1 before generating the clobber.

[Bug fortran/106817] clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument

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

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

--- Comment #1 from Mikael Morin  ---
PR92178 is vaguely related.
The tests are very similar, but that other PR is about allocatables whereas
this one isn’t, so I think they are different.

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

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

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

--- Comment #31 from Mikael Morin  ---
(In reply to Mikael Morin from comment #30)
> (In reply to anlauf from comment #29)
> > 
> > but if your patch regtests fine then you should proceed.
> 
> Ok, let’s see how good it is.
> Assigning.

It seems to work, but trying to extend clobbering further, I uncovered a bug
latent on master: PR106817.
Maybe not that good an idea to extend clobbering further. :-(

[Bug fortran/99349] ICE in match_data_constant, at fortran/decl.c:426

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r13-2382-gb6aa7d45b502c01f8703c8d2cee2690f9aa8e282
Author: Harald Anlauf 
Date:   Fri Sep 2 21:07:26 2022 +0200

Fortran: avoid NULL pointer dereference on invalid DATA constant [PR99349]

gcc/fortran/ChangeLog:

PR fortran/99349
* decl.cc (match_data_constant): Avoid NULL pointer dereference.

gcc/testsuite/ChangeLog:

PR fortran/99349
* gfortran.dg/pr99349.f90: New test.

Co-authored-by: Steven G. Kargl 

[Bug fortran/99349] ICE in match_data_constant, at fortran/decl.c:426

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
Finally fixed on mainline for gcc-13.  Closing.

Thanks for the report!

[Bug c/106818] New: code is genereated differently with or without 'extern'

[pangbw at gmail dot com via Gcc-bugs]

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

Bug ID: 106818
   Summary: code is genereated differently with or without
'extern'
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pangbw at gmail dot com
  Target Milestone: ---

Just wondering why GCC would generate such different code:

https://godbolt.org/z/ncE5sWYe8

[Bug c/106818] code is genereated differently with or without 'extern'

[pangbw at gmail dot com via Gcc-bugs]

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

--- Comment #1 from baoshan  ---
With 'extern', four 'sb' are ued to store value into "p->i";
while without 'extern', only one 'sw' is used.

[Bug c/106818] code is genereated differently with or without 'extern'

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

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

--- Comment #2 from Andrew Pinski  ---
Most likely known alignment or not.
Riscv targets are sensitive to alignment.

[Bug middle-end/106818] code is genereated differently with or without 'extern'

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

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

--- Comment #3 from Andrew Pinski  ---
Please attach or paste the testcase into the bug report instead of a godbolt
link too.

[Bug ipa/106816] noreturn/pure attributes are not set correctly on multiversioned functions

[gcc.gnu at vvalter dot com via Gcc-bugs]

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

--- Comment #4 from Simon Rainer  ---
That's weird, I still get the following with your patch applied:

main:
.LFB2:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
call_Z5_Z1fvv@PLT
movl$1, %eax
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc

I double checked that and reran a full bootstrap, but maybe I'm doing something
wrong. I would also be surprised if information about volatile, readonly, and
pure are enough to detect that the function is noreturn, wouldn't that need to
be a separate information?

[Bug fortran/106817] clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
I see:

D.4225 = a + 1;
a = {CLOBBER};
copy (&D.4225, &a);

so I do not see any failure.  What am I missing?

[Bug middle-end/106818] code is genereated differently with or without 'extern'

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

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

palmer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||palmer at gcc dot gnu.org

--- Comment #4 from palmer at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #2)
> Most likely known alignment or not.
> Riscv targets are sensitive to alignment.

Not sure I'm allowed to paste the code in for them, but that's what's going on
here: with -mtune=thead-c906 both cases have a single store, the default is for
Rocket which has very slow misaligned accesses.

That said, I think we actually have a bug here: if the extern symbol was really
of unknown alignment then sharing the lui might not work.

[Bug fortran/106817] clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument

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

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

--- Comment #3 from Mikael Morin  ---
(In reply to anlauf from comment #2)
> 
> What am I missing?

The right testcase.
Try this one.

module m
  implicit none
contains
  subroutine copy(out, in)
integer, intent(in) :: in
integer, intent(out) :: out
out = in
  end subroutine copy
end module m

program p
  use m
  implicit none
  integer :: a
  a = 3
  call copy(a, a+1)
  if (a /= 4) stop 1
end program p

[Bug fortran/106817] clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument

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

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

--- Comment #4 from Mikael Morin  ---
(In reply to anlauf from comment #2)
> I see:
> 
> D.4225 = a + 1;
> a = {CLOBBER};
> copy (&D.4225, &a);
> 
> so I do not see any failure.

With the testcase from comment #3, it becomes:

a = {CLOBBER};
D.4223 = a + 1;
copy (&a, &D.4223);

[Bug middle-end/106819] New: [13 Regression] NaN != NaN comparisons return false at -O2 since r13-2338

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Bug ID: 106819
   Summary: [13 Regression] NaN != NaN comparisons return false at
-O2 since r13-2338
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Isolated, and translated to C from the D testsuite, likely can be reduced
further, as I don't think opCmpProper() affects the outcome.

---
static int isNaN(double x)
{
return x != x;
}

static double opCmpProper(int lhs, double rhs)
{
  return lhs < rhs ? -1.0
   : lhs > rhs ? 1.0
   : lhs == rhs ? 0.0
   : __builtin_nan("");
}

int main()
{
if (!isNaN(opCmpProper(41, __builtin_nan(""
  __builtin_abort();
return 0;
}

[Bug fortran/106817] clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument

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

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #4)
> With the testcase from comment #3, it becomes:
> 
> a = {CLOBBER};
> D.4223 = a + 1;
> copy (&a, &D.4223);

Right.  And with -Wall one gets a bogus warning that points to the issue:

pr106817.f90:16:20:

   16 |   call copy (a, a+1)
  |^
Warning: 'a' is used uninitialized [-Wuninitialized]
pr106817.f90:14:14:

   14 |   integer :: a
  |  ^
note: 'a' declared here


Which makes this a 9/10/11/12/13 regression ...  :-(

[Bug c++/103499] C++20 modules error: invalid use of non-static member function

[markmigm at gmail dot com via Gcc-bugs]

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

Mark Millard  changed:

   What|Removed |Added

 CC||markmigm at gmail dot com

--- Comment #1 from Mark Millard  ---
I see this in G++ 12.2.0 on FreeBSD. Reduced to a small example below.
Compiled via:

// g++12 -std=c++20 -fmodules-ts -xc++-system-header type_traits
// g++12 -std=c++20 -fmodules-ts -xc++ -c gpp12_module_iostream_failure.cppm
// g++12 -freport-bug -std=c++20 -fmodules-ts -c
gpp12_module_iostream_failure.cpp

# more gpp12_module_is_nothrow_constructible_v_failure.cppm
export module derived_interface;

export struct base
{
virtual ~base() noexcept = default;
};

export struct derived : base
{
};

# more /tmp/ccrTCTqv.out
// Target: aarch64-portbld-freebsd14.0
// Configured with: /wrkdirs/usr/ports/lang/gcc12/work/gcc-12.2.0/configure
--disable-multilib --disable-bootstrap --disable-nls
--enable-gnu-indirect-function --enable-host-shared --enable-plugin
--libdir=/usr/local/lib/gcc12 --libexecdir=/usr/local/libexec/gcc12
--program-suffix=12 --with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc12/include/c++/
--with-gxx-libcxx-include-dir=/usr/include/c++/v1 --with-ld=/usr/local/bin/ld
--with-pkgversion='FreeBSD Ports Collection' --with-system-zlib --without-zstd
--enable-languages=c,c++,objc,fortran,jit --prefix=/usr/local
--localstatedir=/var --mandir=/usr/local/man
--infodir=/usr/local/share/info/gcc12 --build=aarch64-portbld-freebsd14.0
// Thread model: posix
// Supported LTO compression algorithms: zlib
// gcc version 12.2.0 (FreeBSD Ports Collection) 
// 
// In module /usr/local/lib/gcc12/include/c++/type_traits, imported at
gpp12_module_is_nothrow_constructible_v_failure.cpp:7:
// /usr/local/lib/gcc12/include/c++/type_traits: In substitution of
'template using __is_nothrow_constructible_impl =
std::__bool_constant<__is_nothrow_constructible(_Tp)> [with _Tp =
derived@derived_interface; _Args = {}]':
// /usr/local/lib/gcc12/include/c++/type_traits:1047:12:   required from
'struct std::is_nothrow_constructible'
// /usr/local/lib/gcc12/include/c++/type_traits:3243:46:   required from
'constexpr const bool
std::is_nothrow_constructible_v'
// gpp12_module_is_nothrow_constructible_v_failure.cpp:11:11:   required from
here
// /usr/local/lib/gcc12/include/c++/type_traits:1041:11: error: invalid use of
non-static member function 'virtual constexpr
derived@derived_interface::~derived()'
//  1041 | using __is_nothrow_constructible_impl
//   |   ^~~
// In module derived_interface, imported at
gpp12_module_is_nothrow_constructible_v_failure.cpp:5:
// gpp12_module_is_nothrow_constructible_v_failure.cppm:10:15: note: declared
here
//10 | export struct derived : base
//   |   ^~~
// /usr/local/lib/gcc12/include/c++/type_traits:1041: confused by earlier
errors, bailing out

// /usr/local/libexec/gcc12/gcc/aarch64-portbld-freebsd14.0/12.2.0/cc1plus
-quiet gpp12_module_is_nothrow_constructible_v_failure.cpp -quiet -dumpbase
gpp12_module_is_nothrow_constructible_v_failure.cpp -dumpbase-ext .cpp
-mlittle-endian -mabi=lp64 -std=c++20 -freport-bug -fmodules-ts -o -
-frandom-seed=0 -fdump-noaddr

# 0 "gpp12_module_is_nothrow_constructible_v_failure.cpp"
# 0 ""
# 0 ""
# 1 "gpp12_module_is_nothrow_constructible_v_failure.cpp"




import  derived_interface;

import  "/usr/local/lib/gcc12/include/c++/type_traits";

void test()
{
 if (std::is_nothrow_constructible_v);
}

[Bug d/105659] error: #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

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

commit r13-2385-gd5ad6f8415171798adaff5787400505ce9882144
Author: Iain Buclaw 
Date:   Tue Aug 16 16:18:02 2022 +0200

d: Fix #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not
supported

This moves all D front-end specific target definitions out of the main
target headers, and into its own header that is included by tm_d.h
instead of pulling in the same headers as tm_p.h.

This fixes the build on target configurations that pull in the default D
language target hooks, and subsequently trigger an error because the
definition of PREFERRED_DEBUGGING_TYPE is behind tm.h, the one header
that is avoided from being included in default-d.cc.

PR d/105659

gcc/ChangeLog:

* config.gcc: Set tm_d_file to ${cpu_type}/${cpu_type}-d.h.
* config/aarch64/aarch64-d.cc: Include tm_d.h.
* config/aarch64/aarch64-protos.h (aarch64_d_target_versions): Move
to
config/aarch64/aarch64-d.h.
(aarch64_d_register_target_info): Likewise.
* config/aarch64/aarch64.h (TARGET_D_CPU_VERSIONS): Likewise.
(TARGET_D_REGISTER_CPU_TARGET_INFO): Likewise.
* config/arm/arm-d.cc: Include tm_d.h and arm-protos.h instead of
tm_p.h.
* config/arm/arm-protos.h (arm_d_target_versions): Move to
config/arm/arm-d.h.
(arm_d_register_target_info): Likewise.
* config/arm/arm.h (TARGET_D_CPU_VERSIONS): Likewise.
(TARGET_D_REGISTER_CPU_TARGET_INFO): Likewise.
* config/default-d.cc: Remove memmodel.h include.
* config/freebsd-d.cc: Include tm_d.h instead of tm_p.h.
* config/glibc-d.cc: Likewise.
* config/i386/i386-d.cc: Include tm_d.h.
* config/i386/i386-protos.h (ix86_d_target_versions): Move to
config/i386/i386-d.h.
(ix86_d_register_target_info): Likewise.
(ix86_d_has_stdcall_convention): Likewise.
* config/i386/i386.h (TARGET_D_CPU_VERSIONS): Likewise.
(TARGET_D_REGISTER_CPU_TARGET_INFO): Likewise.
(TARGET_D_HAS_STDCALL_CONVENTION): Likewise.
* config/i386/winnt-d.cc: Include tm_d.h instead of tm_p.h.
* config/mips/mips-d.cc: Include tm_d.h.
* config/mips/mips-protos.h (mips_d_target_versions): Move to
config/mips/mips-d.h.
(mips_d_register_target_info): Likewise.
* config/mips/mips.h (TARGET_D_CPU_VERSIONS): Likewise.
(TARGET_D_REGISTER_CPU_TARGET_INFO): Likewise.
* config/netbsd-d.cc: Include tm_d.h instead of tm.h and
memmodel.h.
* config/openbsd-d.cc: Likewise.
* config/pa/pa-d.cc: Include tm_d.h.
* config/pa/pa-protos.h (pa_d_target_versions): Move to
config/pa/pa-d.h.
(pa_d_register_target_info): Likewise.
* config/pa/pa.h (TARGET_D_CPU_VERSIONS): Likewise.
(TARGET_D_REGISTER_CPU_TARGET_INFO): Likewise.
* config/riscv/riscv-d.cc: Include tm_d.h.
* config/riscv/riscv-protos.h (riscv_d_target_versions): Move to
config/riscv/riscv-d.h.
(riscv_d_register_target_info): Likewise.
* config/riscv/riscv.h (TARGET_D_CPU_VERSIONS): Likewise.
(TARGET_D_REGISTER_CPU_TARGET_INFO): Likewise.
* config/rs6000/rs6000-d.cc: Include tm_d.h.
* config/rs6000/rs6000-protos.h (rs6000_d_target_versions): Move to
config/rs6000/rs6000-d.h.
(rs6000_d_register_target_info): Likewise.
* config/rs6000/rs6000.h (TARGET_D_CPU_VERSIONS) Likewise.:
(TARGET_D_REGISTER_CPU_TARGET_INFO) Likewise.:
* config/s390/s390-d.cc: Include tm_d.h.
* config/s390/s390-protos.h (s390_d_target_versions): Move to
config/s390/s390-d.h.
(s390_d_register_target_info): Likewise.
* config/s390/s390.h (TARGET_D_CPU_VERSIONS): Likewise.
(TARGET_D_REGISTER_CPU_TARGET_INFO): Likewise.
* config/sol2-d.cc: Include tm_d.h instead of tm.h and memmodel.h.
* config/sparc/sparc-d.cc: Include tm_d.h.
* config/sparc/sparc-protos.h (sparc_d_target_versions): Move to
config/sparc/sparc-d.h.
(sparc_d_register_target_info): Likewise.
* config/sparc/sparc.h (TARGET_D_CPU_VERSIONS): Likewise.
(TARGET_D_REGISTER_CPU_TARGET_INFO): Likewise.
* configure: Regenerate.
* configure.ac (tm_d_file): Remove defaults.h.
(tm_d_include_list): Remove options.h and insn-constants.h.
* config/aarch64/aarch64-d.h: New file.
* config/arm/arm-d.h: New file.

[Bug c++/106820] New: internal compiler error: in function_and_variable_visibility [for std::dynamic_pointer_cast use via module]

[markmigm at gmail dot com via Gcc-bugs]

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

Bug ID: 106820
   Summary: internal compiler error: in
function_and_variable_visibility [for
std::dynamic_pointer_cast use via  module]
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markmigm at gmail dot com
  Target Milestone: ---

Failing command sequence (from a FreeBSD context) for a reduced/small test
case:

// g++12 -std=c++20 -fmodules-ts -xc++-system-header memory
// g++12 -std=c++20 -freport-bug -fmodules-ts -c
gpp12_module_dynamic_pointer_cast_failure.cpp

For:

# more /tmp/ccvYB09K.out
// Target: aarch64-portbld-freebsd14.0
// Configured with: /wrkdirs/usr/ports/lang/gcc12/work/gcc-12.2.0/configure
--disable-multilib --disable-bootstrap --disable-nls
--enable-gnu-indirect-function --enable-host-shared --enable-plugin
--libdir=/usr/local/lib/gcc12 --libexecdir=/usr/local/libexec/gcc12
--program-suffix=12 --with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc12/include/c++/
--with-gxx-libcxx-include-dir=/usr/include/c++/v1 --with-ld=/usr/local/bin/ld
--with-pkgversion='FreeBSD Ports Collection' --with-system-zlib --without-zstd
--enable-languages=c,c++,objc,fortran,jit --prefix=/usr/local
--localstatedir=/var --mandir=/usr/local/man
--infodir=/usr/local/share/info/gcc12 --build=aarch64-portbld-freebsd14.0
// Thread model: posix
// Supported LTO compression algorithms: zlib
// gcc version 12.2.0 (FreeBSD Ports Collection) 
// 
// during IPA pass: visibility
// gpp12_module_dynamic_pointer_cast_failure.cpp:21:1: internal compiler error:
in function_and_variable_visibility, at ipa-visibility.cc:716
//21 | }
//   | ^
// Please submit a full bug report, with preprocessed source.
// See  for instructions.

// /usr/local/libexec/gcc12/gcc/aarch64-portbld-freebsd14.0/12.2.0/cc1plus
-quiet gpp12_module_dynamic_pointer_cast_failure.cpp -quiet -dumpbase
gpp12_module_dynamic_pointer_cast_failure.cpp -dumpbase-ext .cpp
-mlittle-endian -mabi=lp64 -std=c++20 -freport-bug -fmodules-ts -o -
-frandom-seed=0 -fdump-noaddr

# 0 "gpp12_module_dynamic_pointer_cast_failure.cpp"
# 0 ""
# 0 ""
# 1 "gpp12_module_dynamic_pointer_cast_failure.cpp"
# 11 "gpp12_module_dynamic_pointer_cast_failure.cpp"
import  "/usr/local/lib/gcc12/include/c++/memory";

struct data
{
 virtual ~data() = default;
};

void test(std::shared_ptr b)
{
 auto dpc = std::dynamic_pointer_cast(b);
}

[Bug middle-end/106818] code is genereated differently with or without 'extern'

[pangbw at gmail dot com via Gcc-bugs]

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

--- Comment #5 from baoshan  ---
Per Andrew's request:

For GCC built for RISC-V,
With the following code:
struct sss_t {
int i;
int j;
} sss;
extern char array[sizeof(struct sss_t )];
void foo()
{
struct sss_t *p = (struct sss_t *)array;
p->i = 10;
}

The following asm is generated:
foo():
lui a5,%hi(array)
li  a4,10
sb  a4,%lo(array)(a5)
sb  zero,%lo(array+1)(a5)
sb  zero,%lo(array+2)(a5)
sb  zero,%lo(array+3)(a5)
ret
sss:
.zero   8

While if remove the 'extern' from the C code, the following asm is generated:

foo():
lui a5,%hi(array)
li  a4,10
sw  a4,%lo(array)(a5)
ret
array:
.zero   8
sss:
.zero   8

[Bug middle-end/106818] code is genereated differently with or without 'extern'

[pangbw at gmail dot com via Gcc-bugs]

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

--- Comment #6 from baoshan  ---
> really of unknown alignment then sharing the lui might not work.
Can you elaborate why shareing the lui might not work?

[Bug c/90885] GCC should warn about 2^16 and 2^32 and 2^64 [-Wxor-used-as-pow]

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

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

--- Comment #27 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r13-2386-gbedfca647a9e9c1adadd8924f3ee0ab4189424e0
Author: David Malcolm 
Date:   Fri Sep 2 18:29:33 2022 -0400

c/c++: new warning: -Wxor-used-as-pow [PR90885]

PR c/90885 notes various places in real-world code where people have
written C/C++ code that uses ^ (exclusive or) where presumbably they
meant exponentiation.

For example
  https://codesearch.isocpp.org/cgi-bin/cgi_ppsearch?q=2%5E32&search=Search
currently finds 11 places using "2^32", and all of them appear to be
places where the user means 2 to the power of 32, rather than 2
exclusive-orred with 32 (which is 34).

This patch adds a new -Wxor-used-as-pow warning to the C and C++
frontends to complain about ^ when the left-hand side is the decimal
constant 2 or the decimal constant 10.

This is the same name as the corresponding clang warning:
  https://clang.llvm.org/docs/DiagnosticsReference.html#wxor-used-as-pow

As per the clang warning, the warning suggests converting the left-hand
side to a hexadecimal constant if you really mean xor, which suppresses
the warning (though this patch implements a fix-it hint for that, whereas
the clang implementation only has a fix-it hint for the initial
suggestion of exponentiation).

I initially tried implementing this without checking for decimals, but
this version had lots of false positives.  Checking for decimals
requires extending the lexer to capture whether or not a CPP_NUMBER
token was decimal.  I added a new DECIMAL_INT flag to cpplib.h for this.
Unfortunately, c_token and cp_tokens both have only an unsigned char for
their flags (as captured by c_lex_with_flags), whereas this would add
the 12th flag to cpp_tokens.  Of the first 8 flags, all but BOL are used
in the C or C++ frontends, but BOL is not, so I moved that to a higher
position, using its old value for the new DECIMAL_INT flag, so that it
is representable within an unsigned char.

Example output:

demo.c:5:13: warning: result of '2^8' is 10; did you mean '1 << 8' (256)?
[-Wxor-used-as-pow]
5 | int t2_8 = 2^8;
  | ^
  |--
  |1<<
demo.c:5:12: note: you can silence this warning by using a hexadecimal
constant (0x2 rather than 2)
5 | int t2_8 = 2^8;
  |^
  |0x2
demo.c:21:15: warning: result of '10^6' is 12; did you mean '1e6'?
[-Wxor-used-as-pow]
   21 | int t10_6 = 10^6;
  |   ^
  | ---
  | 1e
demo.c:21:13: note: you can silence this warning by using a hexadecimal
constant (0xa rather than 10)
   21 | int t10_6 = 10^6;
  | ^~
  | 0xa

gcc/c-family/ChangeLog:
PR c/90885
* c-common.h (check_for_xor_used_as_pow): New decl.
* c-lex.cc (c_lex_with_flags): Add DECIMAL_INT to flags as
appropriate.
* c-warn.cc (check_for_xor_used_as_pow): New.
* c.opt (Wxor-used-as-pow): New.

gcc/c/ChangeLog:
PR c/90885
* c-parser.cc (c_parser_string_literal): Clear ret.m_decimal.
(c_parser_expr_no_commas): Likewise.
(c_parser_conditional_expression): Likewise.
(c_parser_binary_expression): Clear m_decimal when popping the
stack.
(c_parser_unary_expression): Clear ret.m_decimal.
(c_parser_has_attribute_expression): Likewise for result.
(c_parser_predefined_identifier): Likewise for expr.
(c_parser_postfix_expression): Likewise for expr.
Set expr.m_decimal when handling a CPP_NUMBER that was a decimal
token.
* c-tree.h (c_expr::m_decimal): New bitfield.
* c-typeck.cc (parser_build_binary_op): Clear result.m_decimal.
(parser_build_binary_op): Call check_for_xor_used_as_pow.

gcc/cp/ChangeLog:
PR c/90885
* cp-tree.h (class cp_expr): Add bitfield m_decimal.  Clear it in
existing ctors.  Add ctor that allows specifying its value.
(cp_expr::decimal_p): New accessor.
* parser.cc (cp_parser_expression_stack_entry::flags): New field.
(cp_parser_primary_expression): Set m_decimal of cp_expr when
handling numbers.
(cp_parser_binary_expression): Extract flags from token when
populating stack.  Call check_for_xor_used_as_pow.

gcc/ChangeLog:
PR c/90885
* doc/invoke.texi (Warning Options): Add -Wxor-used-as-pow.

gcc/testsuite/ChangeLog:
PR c/90885
* c-c++-common/Wxor-used-as-pow-1.c: New test.
  

[Bug middle-end/106818] code is genereated differently with or without 'extern'

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to baoshan from comment #6)
> > really of unknown alignment then sharing the lui might not work.
> Can you elaborate why shareing the lui might not work?

Linker relaxation not coming in and relaxing it to be use gp offsets instead.
It is one of the worst parts of the riscv toolchain ...

[Bug c++/87403] [Meta-bug] Issues that suggest a new warning

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

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

Bug 90885 Summary: GCC should warn about 2^16 and 2^32 and 2^64 
[-Wxor-used-as-pow]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug c/90885] GCC should warn about 2^16 and 2^32 and 2^64 [-Wxor-used-as-pow]

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

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

David Malcolm  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED

--- Comment #28 from David Malcolm  ---
Implemented for GCC 13 by the above patch; marking as resolved.

[Bug middle-end/106818] code is genereated differently with or without 'extern'

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

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

--- Comment #8 from palmer at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #7)
> (In reply to baoshan from comment #6)
> > > really of unknown alignment then sharing the lui might not work.
> > Can you elaborate why shareing the lui might not work?

Unless I've managed to screw up some bit arithmetic here, it's just overflow
that we're not detecting at link time:

$ cat test.c 
extern char glob[4];

int _start(void) {
int *i = (int *)glob;
return *i;
}
$ cat glob.s 
.section .sdata
.balign 4096
.global empty
empty:
.rep 2046
.byte 0
.endr
.global glob
glob:
.byte 1, 2, 3, 4
$ riscv64-linux-gnu-gcc test.c glob.s -O3 -o test -static -fno-PIE
-mcmodel=medlow -mexplicit-relocs -nostdlib
$ riscv64-linux-gnu-objdump -d test
...
0001010c <_start>:
   1010c:   66c9lui a3,0x12
   1010e:   7ff6c703lbu a4,2047(a3) # 127ff 
   10112:   7fe6c603lbu a2,2046(a3)
   10116:   8006c783lbu a5,-2048(a3)
   1011a:   8016c503lbu a0,-2047(a3)
...

So that's going to load

a3 = 0x127ff 
a2 = 0x127fd
a5 = 0x11800
a6 = 0x11801

Which is wrong.

We can't detect it at link time because both relocations are being processed
correctly, they just don't know about each other (and really can't, because
there's nothing coupling them together).

> Linker relaxation not coming in and relaxing it to be use gp offsets instead.
> It is one of the worst parts of the riscv toolchain ...

Though this time linker relaxation is actually biting us twice:

First, it's masking this problem for small programs: if these accesses are all
within range of GP we end up producing executables that function fine, as the
relaxation calculates the full addresses to use as GP offsets.

Second, the GP relaxations just don't work when we share LUIs for
possibly-misaligned symbols because we delete the LUI if the first low-half is
within GP range.  For example:

$ cat glob.s 
.section .sdata
.global empty
empty:
.rep 4090
.byte 0
.endr
.global glob
glob:
.byte 1, 2, 3, 4
$ riscv64-linux-gnu-gcc test.c glob.s -O3 -o test -static -fno-PIE
-mcmodel=medlow -mexplicit-relocs --save-temps -nostdlib
$ riscv64-linux-gnu-objdump -d test
...
0001010c <_start>:
   1010c:   7fb1c703lbu a4,2043(gp) # 12127 
   10110:   7fa1c603lbu a2,2042(gp) # 12126 
   10114:   1286c783lbu a5,296(a3)
   10118:   1296c503lbu a0,297(a3)
...

We had that problem with the AUIPC->GP relaxation as well, but could fix it
there because the low half points to the high half.  Here I think there's also
nothing we can do in the linker, as there's no way to tell when the result of
the LUI is completely unused -- we could deal with simple cases like this, but
with control flow there's no way to handle all of them.

[Bug target/106815] [13 Regression] ICE: in riscv_excess_precision, at config/riscv/riscv.cc:5967 with -fexcess-precision=16 on any input

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

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

palmer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||palmer at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-09-03

--- Comment #1 from palmer at gcc dot gnu.org ---
Thanks.  I'm pretty sure all we need is

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 675d92c0961..9b6d3e95b1b 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -5962,6 +5962,7 @@ riscv_excess_precision (enum excess_precision_type type)
   return (TARGET_ZFH ? FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16
 : FLT_EVAL_METHOD_PROMOTE_TO_FLOAT);
 case EXCESS_PRECISION_TYPE_IMPLICIT:
+case EXCESS_PRECISION_TYPE_FLOAT16:
   return FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16;
 default:
   gcc_unreachable ();

I'll send it out assuming it passes the tests.

[Bug target/101322] ICE in copy_to_mode_reg, at explow.c:651

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Peter Bergner
:

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

commit r12-8740-g2d4f60f206cf1100b7484d708f6c913762618676
Author: Peter Bergner 
Date:   Wed Aug 31 21:14:36 2022 -0500

rs6000: Don't ICE when we disassemble an MMA variable [PR101322]

When we expand an MMA disassemble built-in with C++ using a pointer that
is cast to a valid MMA type, the type isn't passed down to the expand
machinery and we end up using the base type of the pointer which leads to
an ICE.  This patch enforces we always use the correct MMA type regardless
of the pointer type being used.

2022-08-31  Peter Bergner  

gcc/
PR target/101322
* config/rs6000/rs6000-builtin.cc (rs6000_gimple_fold_mma_builtin):
Enforce the use of a valid MMA pointer type.

gcc/testsuite/
PR target/101322
* g++.target/powerpc/pr101322.C: New test.

(cherry picked from commit 2985049049f12b0aa3366ca244d387820385b9e8)

[Bug c/90885] GCC should warn about 2^16 and 2^32 and 2^64 [-Wxor-used-as-pow]

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

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

--- Comment #29 from Jonathan Wakely  ---
Excellent! Thanks, Dave

[Bug c++/106821] New: Incorrect behavior when using type alias template containing unevaluated lambda expression in a template context

[Dylan.Ferris at amd dot com via Gcc-bugs]

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

Bug ID: 106821
   Summary: Incorrect behavior when using type alias template
containing unevaluated lambda expression in a template
context
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Dylan.Ferris at amd dot com
  Target Milestone: ---

I have prepared three different examples for when this fails:

https://godbolt.org/z/G8Eq5fo5G
https://godbolt.org/z/fajvnfo91
https://godbolt.org/z/e9s9Ws5o7

In the first one, `z.obj.a()` should be valid because `obj` is simply an
instantiation of the `A` template.

In the second one, `z.a()` should be valid because `bar` is inheriting from an
instantiation of the `A` template.

In the third one, `obj.a()` should be valid because `obj` is simply an
instantiation of the `A` template.


All three of these have the following in common:

1. `alias` contains an unevaluated lambda expression, ie. `decltype([]{})`
2. The instantiation of `alias` as the inherited type uses a template parameter


So, this means that the three examples correctly compile if we apply any of the
following workarounds:

1. "inline" the alias by replacing all instances of it with `A`
(Requiring this workaround violates [temp.alias.2])
2. Remove the unevaluated lambda expression from `alias` (such as replacing it
with `int`)
3. Remove the template parameter of `alias`
4. Instantiate `alias` with a fixed type such as `int`.


The bug persists even under a variety of transformations. Such as:

1. Removing the template on `A` and instead making an expression such as:
template
using alias = std::conditional_t;
2. Providing `bar`'s template parameter a default value of `int` and
subsequently using it


I believe this is related to PR 92707, but here the type of the unevaluated
lambda is used as a template parameter in each case, and it holds true in what
seems to be all template contexts.