[Bug libquadmath/112963] [14 Regression] Incorrect linking of libquadmath since r14-4863

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

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

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

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

commit r14-6451-gfdce86c9f07eb4f95ba438491c2b151e94be7ef2
Author: Jakub Jelinek 
Date:   Tue Dec 12 08:57:02 2023 +0100

libquadmath: Restore linking against -lm on most targets [PR112963]

The r14-4825 change added AC_CHECK_LIBM to libquadmath configure.ac and
replaced unconditional linking with -lm with linking with $(LIBM)
determined by that.
Unfortunately that broke bare metal targets because AC_CHECK_LIBM attempts
to link against -lm and this was after (unconditional) GCC_NO_EXECUTABLES.
Then r14-4863 partially reverted that change (no longer AC_CHECK_LIBM),
but didn't revert the Makefile.am change of -lm to $(LIBM), which had
the effect that libquadmath is not linked against -lm on any arch.
That is a serious problem though e.g. on Linux, because libquadmath calls
a few libm entrypoints and e.g. on powerpc64le the underlinking can cause
crashes in IFUNC resolvers of libm.
Instead of adding further reversion of the r14-4825 commit and use -lm
unconditionally again, this patch adds an AC_CHECK_LIBM like substitutions
with the *-ncr-sysv4.3* target handling removed (I think we don't support
such targets, especially not in libquadmath) and with the default case
replaced by simple using -lm.  That is something in between using -lm
unconditionally and what AC_CHECK_LIBM does if it would work on bare metal
- we know from GCC 13 and earlier that we can link -lm on all targets
libquadmath is built for, and just white list a couple of targets which
we know don't have separate -lm and don't want to link against that
(like Darwin, Cygwin, ...).

2023-12-12  Jakub Jelinek  

PR libquadmath/112963
* configure.ac (LIBM): Readd AC_CHECK_LIBM-like check without doing
AC_CHECK_LIB in it.
* configure: Regenerated.
* Makefile.in: Regenerated.

[Bug libquadmath/112963] [14 Regression] Incorrect linking of libquadmath since r14-4863

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/112847] [14 Regression] nvptx: 'FAIL: g++.dg/cpp2a/concepts-explicit-inst1.C -std=c++20 scan-assembler _Z1gI1XEvT_', 'scan-assembler _Z1gI1YEvT_'

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

--- Comment #2 from Thomas Schwinge  ---
This one (but not PR112846 "nvptx: 'FAIL: g++.dg/abi/anon6.C -std=c++20
scan-assembler
_Z5dummyIXtl8wrapper1IdEtlNS1_Ut_Edi9RightNametlNS2_Ut_Edi9RightNameLd405ec000EEvv'",
which I'd filed at the same time) has been fixed by commit
r14-6432-g074c6f15f7a28c620c756f18c2a310961de00539 "testsuite: update
mangling", I presume.  (The new 'g++.dg/cpp2a/concepts-explicit-inst1a.C' also
is all-PASS.)

[Bug analyzer/112704] FAIL: gcc.dg/analyzer/data-model-20.c (test for warnings, line 17)

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

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #2 from Thomas Schwinge  ---
Should be resolved via commit
r14-6434-g6008b80b25d71827fb26ce49f49aae02b645bb12 "analyzer: fix uninitialized
bitmap [PR112955]".

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

[Bug analyzer/112955] Valgrind error in ana::feasibility_state::maybe_update_for_edge

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #4 from Thomas Schwinge  ---
*** Bug 112704 has been marked as a duplicate of this bug. ***

[Bug middle-end/100942] ccmp is not used if the value is used later

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-Decembe
   ||r/640289.html
   Keywords||patch

--- Comment #3 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640289.html

[Bug ada/112979] New: [13/14 regression] Gnat Bug Detected with Invalid Prefix

[suratiamol at gmail dot com via Gcc-bugs]

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

Bug ID: 112979
   Summary: [13/14 regression] Gnat Bug Detected with Invalid
Prefix
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: suratiamol at gmail dot com
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 56861
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56861&action=edit
Reproducer: to be gnatchopped

On running the code at [1], the gnat 13.2 compiler raises an error
about invalid prefix, which looks okay.

But the gnat trunk compiler causes a "Gnat Bug Detected", as seen
at [2].

Part of the message:

   14.0.0 20231212 (experimental) (x86_64-linux-gnu) \
   Assert_Failure failed precondition from einfo-entities.ads:2256|

A search on bugzilla for 'einfo-entities.ads' turned up empty.

The sources are also attached as a single .ada file. 

[1] https://godbolt.org/z/4ojeq1xx8
[2] https://godbolt.org/z/naWsq7GsG

Thank you.

[Bug target/112929] [14] RISC-V vector: Variable clobbered at runtime

[pan2.li at intel dot com via Gcc-bugs]

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

--- Comment #19 from Li Pan  ---
(In reply to Robin Dapp from comment #7)
> Here
> 
> 0x105c6   vse8.v  v8,(a5)
> 
> is where we overwrite m.  The vl is 128 but the preceding vsetvl gets a4 =
> 46912504507016 as AVL which seems already borken.

I can reproduce this up to a point.

0x10282   vsetvli zero,a4,e8,m8,ta,ma

(gdb) p $a4
$2 = 110736

Looks like 110736 is not the correct vl here, will continue to investigate.

[Bug target/112962] [14 Regression] ICE: SIGSEGV in operator() (recog.h:431) with -fexceptions -mssse3 and __builtin_ia32_pabsd128()

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #1 from Uroš Bizjak  ---
Created attachment 56862
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56862&action=edit
Proposed patch

Patch in testing.

[Bug target/112929] [14] RISC-V vector: Variable clobbered at runtime

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

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

Kito Cheng  changed:

   What|Removed |Added

 CC||kito at gcc dot gnu.org

--- Comment #20 from Kito Cheng  ---
```
.L15:
li  a3,9
lui a4,%hi(s)
sw  a3,%lo(j)(t2)
sh  a5,%lo(s)(a4) <--a4 is hold the address of s
beq t0,zero,.L42
sw  t5,8(t4)
vsetvli zero,a4,e8,m8,ta,ma  <<--- a4 as avl
```

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

[naveen at kernel dot org via Gcc-bugs]

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

Bug ID: 112980
   Summary: 64-bit powerpc ELFv2 does not allow nops to be
generated before function global entry point
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: naveen at kernel dot org
  Target Milestone: ---

Bug 99888 addressed issue with -fpatchable-function-entry not generating nops
at function local entry point with ppc64le ELFv2. However, the change also
meant that there is now no way to request for nops to be generated _before_ the
function global entry point.

This is problematic if we only want to have two nops generated for storing a
64-bit value. With the current implementation of -fpatchable-function-entry, we
are forced to emit at least 6 nops due to ABI restrictions on the number of
instructions between GEP and LEP. This is required to support Linux kernel
features such as DYNAMIC_FTRACE_WITH_CALL_OPS [1]. Furthermore, it may be
desirable to generate nops before the function entry point so as to minimize
icache usage with functions entered through the global entry point.

Please consider adding an option to allow nops to be generated before the
global entry point.

[1] https://lore.kernel.org/all/20230123134603.1064407-2-mark.rutl...@arm.com/

[Bug target/112962] [14 Regression] ICE: SIGSEGV in operator() (recog.h:431) with -fexceptions -mssse3 and __builtin_ia32_pabsd128()

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

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

--- Comment #2 from Jakub Jelinek  ---
Started with r14-1145-g1ede03e2d0437ea9c2f7453fcbe263505b4e0def

[Bug target/112962] [14 Regression] ICE: SIGSEGV in operator() (recog.h:431) with -fexceptions -mssse3 and __builtin_ia32_pabsd128()

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I was thinking whether it wouldn't be better to expand x86 const or pure
builtins when lhs is ignored to nothing in the expanders.

[Bug target/112962] [14 Regression] ICE: SIGSEGV in operator() (recog.h:431) with -fexceptions -mssse3 and __builtin_ia32_pabsd128()

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #3)
> I was thinking whether it wouldn't be better to expand x86 const or pure
> builtins when lhs is ignored to nothing in the expanders.

Yes, this could be a better solution.

[Bug target/112962] [14 Regression] ICE: SIGSEGV in operator() (recog.h:431) with -fexceptions -mssse3 and __builtin_ia32_pabsd128()

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

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

--- Comment #5 from Jakub Jelinek  ---
With -O1 or higher there is some DCE which will remove them (unless disabled),
but the above ICE is with -O0...

[Bug target/112918] [m68k] [LRA] ICE: maximum number of generated reload insns per insn achieved (90)

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

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

--- Comment #11 from Richard Biener  ---
The original testcase fails with the same pattern btw., alternating between
register classes / alternatives.

[Bug target/112962] [14 Regression] ICE: SIGSEGV in operator() (recog.h:431) with -fexceptions -mssse3 and __builtin_ia32_pabsd128()

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #3)
> I was thinking whether it wouldn't be better to expand x86 const or pure
> builtins when lhs is ignored to nothing in the expanders.

Something like this?

--cut here--
diff --git a/gcc/config/i386/i386-expand.cc b/gcc/config/i386/i386-expand.cc
index a53d69d5400..0f3d6108d77 100644
--- a/gcc/config/i386/i386-expand.cc
+++ b/gcc/config/i386/i386-expand.cc
@@ -13032,6 +13032,9 @@ ix86_expand_builtin (tree exp, rtx target, rtx
subtarget,
   unsigned int fcode = DECL_MD_FUNCTION_CODE (fndecl);
   HOST_WIDE_INT bisa, bisa2;

+  if (ignore && (TREE_READONLY (fndecl) || DECL_PURE_P (fndecl)))
+return const0_rtx;
+
   /* For CPU builtins that can be folded, fold first and expand the fold.  */
   switch (fcode)
 {
@@ -14401,9 +14404,6 @@ rdseed_step:
   return target;

 case IX86_BUILTIN_READ_FLAGS:
-  if (ignore)
-   return const0_rtx;
-
   emit_insn (gen_pushfl ());

   if (optimize
--cut here--

[Bug target/112962] [14 Regression] ICE: SIGSEGV in operator() (recog.h:431) with -fexceptions -mssse3 and __builtin_ia32_pabsd128()

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

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

--- Comment #7 from Jakub Jelinek  ---
On the other side, maybe we want some of the diagnostics that is only done at
expansion time (argument xyz must be such and such immediate).  Though, at -O2
it isn't diagnosed anyway because it is DCEd.
Anyway, with just -O0 -mssse3 this works fine because of expr.cc:
11097 /* If we are going to ignore this result, we need only do something
11098if there is a side-effect somewhere in the expression.  If there
11099is, short-circuit the most common cases here.  Note that we must
11100not call expand_expr with anything but const0_rtx in case this
11101is an initial expansion of a size that contains a
PLACEHOLDER_EXPR.  */
11102   
11103 if (ignore)
11104   {
11105 if (! TREE_SIDE_EFFECTS (exp))
11106   return const0_rtx;
but with -fexceptions (and probably because we incorrectly don't mark the
builtins nothrow?) this doesn't happen.
I was thinking about something like
--- gcc/i386-expand.cc.jj   2023-12-07 08:31:59.855850982 +0100
+++ gcc/i386-expand.cc  2023-12-12 11:02:54.524733315 +0100
@@ -11842,6 +11842,12 @@ ix86_expand_args_builtin (const struct b
   xops[i] = op;
 }

+  if (icode == CODE_FOR_nothing)
+{
+  gcc_assert (target == const0_rtx);
+  return const0_rtx;
+}
+
   switch (nargs)
 {
 case 1:
but of course, your choice...

[Bug sanitizer/112981] New: [13/14 Regression] Big compile time and run time regression in libasan with g:f732bf6a603721f61102a08ad2d023c7c2670870

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

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

Bug ID: 112981
   Summary: [13/14 Regression] Big compile time and run time
regression in libasan with
g:f732bf6a603721f61102a08ad2d023c7c2670870
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-*

Starting with the sync with upstream in
g:f732bf6a603721f61102a08ad2d023c7c2670870

f732bf6a603721f61102a08ad2d023c7c2670870 is the first bad commit
commit f732bf6a603721f61102a08ad2d023c7c2670870
Author: Martin Liska 
Date:   Tue May 3 12:56:26 2022 +0200

libsanitizer: merge from upstream
(0a1bcab9f3bf75c4c5d3e53bafb3eeb80320af46).

there's a massive compile time and performance overhead (6x slower) when using
-fsanitize=address.

The following testcase (due to the dependencies provided as cmake project)
illustrates this:

-- main.cpp:

#include 
#include 

TEST_CASE("Test") {
  for (int i= 0; i<100; i++) {
REQUIRE(1 + 2 == 3);
  }
}

-- CMakeList.txt

cmake_minimum_required(VERSION 3.5)
project(slow_asan)

add_compile_options(-fsanitize=address)
add_link_options(-fsanitize=address)

Include(FetchContent)
FetchContent_Declare(
Catch2
SYSTEM
GIT_REPOSITORY https://github.com/catchorg/Catch2.git
GIT_TAG v3.3.0
)

FetchContent_MakeAvailable(Catch2)

add_executable(tests main.cpp)
target_link_libraries(tests PRIVATE Catch2::Catch2WithMain)

--- command

cmake -DCMAKE_C_COMPILER=${install_dir}/bin/gcc
-DCMAKE_CXX_COMPILER=${install_dir}/bin/g++ -DCMAKE_BUILD_TYPE=Release . &&
make VERBOSE=1 -j && timeout 10.0s ./tests

will take significantly longer than in GCC 12 (compiles at -O3).

I have not yet tracked down if the compile hog is a GCC issue or not.

[Bug target/112962] [14 Regression] ICE: SIGSEGV in operator() (recog.h:431) with -fexceptions -mssse3 and __builtin_ia32_pabsd128()

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

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

--- Comment #8 from Jakub Jelinek  ---
Of course, yet another option is:
--- gcc/config/i386/i386.cc 2023-12-12 08:54:39.821148670 +0100
+++ gcc/config/i386/i386.cc 2023-12-12 11:07:03.795286363 +0100
@@ -19377,7 +19377,10 @@ ix86_gimple_fold_builtin (gimple_stmt_it
 do_shift:
   gcc_assert (n_args >= 2);
   if (!gimple_call_lhs (stmt))
-   break;
+   {
+ gsi_replace (gsi, gimple_build_nop (), false);
+ return true;
+   }
   arg0 = gimple_call_arg (stmt, 0);
   arg1 = gimple_call_arg (stmt, 1);
   elems = TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg0));
@@ -19523,7 +19526,10 @@ ix86_gimple_fold_builtin (gimple_stmt_it
 case IX86_BUILTIN_PABSD256_MASK:
   gcc_assert (n_args >= 1);
   if (!gimple_call_lhs (stmt))
-   break;
+   {
+ gsi_replace (gsi, gimple_build_nop (), false);
+ return true;
+   }
   arg0 = gimple_call_arg (stmt, 0);
   elems = TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg0));
   /* For masked ABS, only optimize if the mask is all ones.  */
(and I wonder why all the gsi_replace calls in that function are with false,
IMHO they should use true).

[Bug target/112962] [14 Regression] ICE: SIGSEGV in operator() (recog.h:431) with -fexceptions -mssse3 and __builtin_ia32_pabsd128()

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #8)
> Of course, yet another option is:

This goes out of my (limited) area of expertise, so if my proposed (trivial)
patch is papering over some other issue, I'll happily leave the solution to
you.

[Bug sanitizer/112981] [13/14 Regression] Big compile time and run time regression in libasan with g:f732bf6a603721f61102a08ad2d023c7c2670870

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Can you provide the preprocessed source before and after the commit? There
should be no compile time change due to that commit except link time.

[Bug sanitizer/112981] [13/14 Regression] Big compile time and run time regression in libasan with g:f732bf6a603721f61102a08ad2d023c7c2670870

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
My bet this is a dup of bug 110835

[Bug target/112962] [14 Regression] ICE: SIGSEGV in operator() (recog.h:431) with -fexceptions -mssse3 and __builtin_ia32_pabsd128()

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Assignee|ubizjak at gmail dot com   |unassigned at gcc dot 
gnu.org
 Status|ASSIGNED|NEW

--- Comment #10 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #7)

> but with -fexceptions (and probably because we incorrectly don't mark the
> builtins nothrow?) this doesn't happen.

Maybe we should finally fix the above nothrow issue?

[Bug c++/93259] Unsized temporary array initialization problem

[m.cencora at gmail dot com via Gcc-bugs]

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

--- Comment #7 from m.cencora at gmail dot com ---
This seems to be fixed in gcc 12.3 and gcc 13+

Can we close this?

[Bug tree-optimization/112982] New: Missing optimization: fold max(b, a + 1) to b when a < b

[xxs_chy at outlook dot com via Gcc-bugs]

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

Bug ID: 112982
   Summary: Missing optimization: fold max(b, a + 1) to b when a <
b
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xxs_chy at outlook dot com
  Target Milestone: ---

Godbolt example: https://godbolt.org/z/nn8hT16Ka

long src(long a, long b) {
if(a < b){
return max(b, a + 1);
}else{
return 0;
}
}

can be folded to:

long tgt(long a, long b) {
if(a < b){
return b;
}else{
return 0;
}
}

Similarly, such pattern can be generalized to `a > b`, `min(b, a + 1)`.
Both GCC and LLVM missed such optimization opportunity.

[Bug middle-end/111683] [11/12/13/14 Regression] Incorrect answer when using SSE2 intrinsics with -O3

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Keywords|needs-bisection |

--- Comment #4 from Jakub Jelinek  ---
Started with r7-3163-g973625a04b3d9351f2485e37f7d3382af2aed87e
Slightly reduced:
#include 

void convn_script(const double in9[10], const double in10[7], double out5[16])
{
  int iB = 0;
  int iC = 0;
  __builtin_memset(&out5[0], 0, 16U * sizeof(double));
  for (int i = 0; i < 7; i++) {
int b_i;
int vectorUB;
if (i + 10 <= 15)
  b_i = 9;
else
  b_i = 15 - i;
vectorUB = (((b_i + 1) / 2) << 1) - 2;
for (int r = 0; r <= vectorUB; r += 2) {
  __m128d b_r;
  b_i = iC + r;
  b_r = _mm_loadu_pd(&out5[b_i]);
  _mm_storeu_pd(&out5[b_i],
_mm_add_pd(b_r, _mm_mul_pd(_mm_set1_pd(in10[iB]),
   _mm_loadu_pd(&in9[r];
}
iC = iB + 1;
iB++;
  }
}

int main() {
  double in9[10] = {0.8147, 0.9058, 0.1270, 0.9134, 0.6324, 0.0975, 0.2785,
0.5469, 0.9575, 0.9649};
  double in10[7] = {0.1576, 0.9706, 0.9572, 0.4854, 0.8003, 0.1419, 0.4218};
  double out5[16];
  convn_script(in9, in10, out5);
  for(int i = 0; i < 16; i++)
__builtin_printf ("%d %f\n", i, out5[i]);
}

[Bug driver/112983] New: gcc.cc: do_spec_1, ICE if missing '}' for %x{...}

[pexu--- via Gcc-bugs]

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

Bug ID: 112983
   Summary: gcc.cc: do_spec_1, ICE if missing '}' for %x{...}
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: p...@gcc-bugzilla.mail.kapsi.fi
  Target Milestone: ---

Hi.

# cat bracegracemisery.specs
*self_spec: %x{
# gcc --specs=bracegracemisery.specs -E - < /dev/null > /dev/null
Segmentation fault (core dumped)

Happens because when looking for the terminating '}' character the loop
condition does not check if the input buffer runs out.

gcc.cc:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/gcc.cc;h=701f5cdfb59c8f60c9c9bee310ef9de03d1ece27;hb=refs/heads/master#l6683
6683: while (*p++ != '}')
6684:   ;

Due to memory layout reproducing this might be difficult (or impossible) or
yield other diagnosted errors (should the out of bounds read contain the
terminating character prior an invalid memory location is accessed).

[Bug ipa/92606] [11/12/13 Regression][avr] invalid merge of symbols in progmem and data sections

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

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

--- Comment #28 from Georg-Johann Lay  ---
(In reply to Richard Biener from comment #25)
> I wonder if it would be possible to set the appropriate address-space when
> parsing the "progmem" attribute in the target?

No, that's not possible. You cannot adjust all uses to also refer to the
different address-space.  And qualifiers and attributes behave quite
differently.

> For ICF (or more generally IPA) there's comp_type_attributes which
> we already check and which dispatches to target code.  We're also
> rejecting differing DECL_ATTRIBUTES:

This would make sense to also use for variables, or better still call a target
hook to reject specific combinations.  Attrs like "used", "unused" etc. should
still be ok, but the back-end knows best, IMO.

And different address-spaces might also work, e.g. when one decl is progmem
(AS0) and the other is __flash (AS1).  So the current fix misses some
opportunities (just to mention it, not that I think it would matter much).

> so I wonder what happens here?  Does AVR not actually add the progmem
> attribute?

It always adds the progmem attribute (but may bail out, e.g. when not "const").

[Bug target/112962] [14 Regression] ICE: SIGSEGV in operator() (recog.h:431) with -fexceptions -mssse3 and __builtin_ia32_pabsd128()

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

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

--- Comment #11 from Jakub Jelinek  ---
Sure.  But we need to find out first what builtins might actually throw.
Perhaps with -fnon-call-exceptions those which read/store (vector loads/stores,
masked loads/stores, scatters/gathers?) memory can?  Unsure if we handle it
though...

[Bug modula2/112984] New: Compiling program with -Wpedantic shows warning in libraries

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

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

Bug ID: 112984
   Summary: Compiling program with -Wpedantic shows warning in
libraries
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

Forwarded from the gm2 mailing list:

Consider the hello world program below:

MODULE test_hello;

  FROM STextIO IMPORT WriteString, WriteLn;

BEGIN
  WriteLn;
  WriteString("Hello, World!");
  WriteLn;
  WriteLn;
END test_hello.


if compiled with -Wpedantic

gm2 -fiso -fsoft-check-all -Wpedantic  test_hello.mod
/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/14.0.0/m2/m2iso/SYSTEM.mod:31:1:
error: In implementation module ‘SYSTEM’: symbol (memcpy) has already been
imported
   31 | CONST
  | ^
/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/14.0.0/m2/m2iso/M2RTS.mod:35:1:
error: In implementation module ‘M2RTS’: symbol (ADDRESS) has already been
imported
   35 | FROM ASCII IMPORT nl, nul ;
  | ^~~~
/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/14.0.0/m2/m2iso/TextIO.mod:31:1:
error: In implementation module ‘TextIO’: symbol (IOChan) has already been
imported
   31 | FROM SYSTEM IMPORT ADR ;
  | ^~~~
/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/14.0.0/m2/m2iso/IOChan.mod:32:1:
error: In implementation module ‘IOChan’: symbol (IOConsts) has already been
imported
   32 | FROM EXCEPTIONS IMPORT ExceptionSource, RAISE, AllocateSource,
  | ^~~~
/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/14.0.0/m2/m2iso/IOLink.mod:31:1:
error: In implementation module ‘IOLink’: symbol (SYSTEM) has already been
imported
   31 | FROM Storage IMPORT ALLOCATE, DEALLOCATE ;
  | ^~~~
/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/14.0.0/m2/m2iso/IOLink.mod:31:1:
error: symbol (IOChan) has already been imported
/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/14.0.0/m2/m2iso/RTfio.mod:30:1:
error: In implementation module ‘RTfio’: symbol (DeviceTablePtr) has already
been imported
   30 | FROM RTio IMPORT GetFile ;
  | ^~~~
/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/14.0.0/m2/m2iso/RTgen.mod:35:1:
error: In implementation module ‘RTgen’: symbol (DeviceTablePtr) has already
been imported
   35 | IMPORT ChanConsts ;
  | ^~
/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/14.0.0/m2/m2iso/RTgen.mod:46:1:
error: symbol (doWBytes) has already been imported
   46 | FROM ChanConsts IMPORT FlagSet, readFlag, writeFlag, rawFlag,
  | ^~~~
/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/14.0.0/m2/m2iso/RTgen.mod:46:1:
error: symbol (GenDevIF) has already been imported
/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/14.0.0/m2/m2iso/TextUtil.mod:9:1:
error: In implementation module ‘TextUtil’: symbol (IOChan) has already been
imported
9 | PROCEDURE SkipSpaces (cid: IOChan.ChanId) ;
  | ^
/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/14.0.0/m2/m2pim/Indexing.mod:33:1:
error: In implementation module ‘Indexing’: symbol (ADDRESS) has already been
imported
   33 | CONST

shows many warnings in the libraries (and it looks as if an error should be a
warning possibly).

[Bug sanitizer/112981] [13/14 Regression] Big compile time and run time regression in libasan with g:f732bf6a603721f61102a08ad2d023c7c2670870

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.3

[Bug modula2/112984] Compiling program with -Wpedantic shows warning in libraries

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #1 from Gaius Mulley  ---
Confirmed in gcc-14 will fix.

[Bug target/112891] [11/12/13/14 Regression] Missing vzeroupper insert

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

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

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

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

commit r13-8149-gd3e140ac549a2117e82dac51f2e739b20f9c7941
Author: liuhongt 
Date:   Thu Dec 7 09:17:27 2023 +0800

Don't assume it's AVX_U128_CLEAN after call_insn whose
abi.mode_clobber(V4DImode) deosn't contains all SSE_REGS.

If the function desn't clobber any sse registers or only clobber
128-bit part, then vzeroupper isn't issued before the function exit.
the status not CLEAN but ANY after the function.

Also for sibling_call, it's safe to issue an vzeroupper. Also there
could be missing vzeroupper since there's no mode_exit for
sibling_call_p.

gcc/ChangeLog:

PR target/112891
* config/i386/i386.cc (ix86_avx_u128_mode_after): Return
AVX_U128_ANY if callee_abi doesn't clobber all_sse_regs to
align with ix86_avx_u128_mode_needed.
(ix86_avx_u128_mode_needed): Return AVX_U128_ClEAN for
sibling_call.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr112891.c: New test.
* gcc.target/i386/pr112891-2.c: New test.

[Bug target/112891] [11/12/13/14 Regression] Missing vzeroupper insert

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

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

--- Comment #7 from GCC Commits  ---
The releases/gcc-12 branch has been updated by hongtao Liu
:

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

commit r12-10037-g2dc102c030093ab2abb69f6d991c6a43bf6f0201
Author: liuhongt 
Date:   Thu Dec 7 09:17:27 2023 +0800

Don't assume it's AVX_U128_CLEAN after call_insn whose
abi.mode_clobber(V4DImode) deosn't contains all SSE_REGS.

If the function desn't clobber any sse registers or only clobber
128-bit part, then vzeroupper isn't issued before the function exit.
the status not CLEAN but ANY after the function.

Also for sibling_call, it's safe to issue an vzeroupper. Also there
could be missing vzeroupper since there's no mode_exit for
sibling_call_p.

gcc/ChangeLog:

PR target/112891
* config/i386/i386.cc (ix86_avx_u128_mode_after): Return
AVX_U128_ANY if callee_abi doesn't clobber all_sse_regs to
align with ix86_avx_u128_mode_needed.
(ix86_avx_u128_mode_needed): Return AVX_U128_ClEAN for
sibling_call.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr112891.c: New test.
* gcc.target/i386/pr112891-2.c: New test.

(cherry picked from commit fc189a08f5b7ad5889bd4c6b320c1dd99dd5d642)

[Bug target/112891] [11/12/13/14 Regression] Missing vzeroupper insert

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

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

--- Comment #8 from GCC Commits  ---
The releases/gcc-11 branch has been updated by hongtao Liu
:

https://gcc.gnu.org/g:172b7ad97c46594d44aeb73dce03daff5f575cfb

commit r11-11135-g172b7ad97c46594d44aeb73dce03daff5f575cfb
Author: liuhongt 
Date:   Thu Dec 7 09:17:27 2023 +0800

Don't assume it's AVX_U128_CLEAN after call_insn whose
abi.mode_clobber(V4DImode) deosn't contains all SSE_REGS.

If the function desn't clobber any sse registers or only clobber
128-bit part, then vzeroupper isn't issued before the function exit.
the status not CLEAN but ANY after the function.

Also for sibling_call, it's safe to issue an vzeroupper. Also there
could be missing vzeroupper since there's no mode_exit for
sibling_call_p.

gcc/ChangeLog:

PR target/112891
* config/i386/i386.c (ix86_avx_u128_mode_after): Return
AVX_U128_ANY if callee_abi doesn't clobber all_sse_regs to
align with ix86_avx_u128_mode_needed.
(ix86_avx_u128_mode_needed): Return AVX_U128_ClEAN for
sibling_call.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr112891.c: New test.
* gcc.target/i386/pr112891-2.c: New test.

(cherry picked from commit fc189a08f5b7ad5889bd4c6b320c1dd99dd5d642)

[Bug target/112891] [11/12/13/14 Regression] Missing vzeroupper insert

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

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

Hongtao Liu  changed:

   What|Removed |Added

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

--- Comment #9 from Hongtao Liu  ---
Fixed everywhere.

[Bug target/112962] [14 Regression] ICE: SIGSEGV in operator() (recog.h:431) with -fexceptions -mssse3 and __builtin_ia32_pabsd128()

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

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

--- Comment #12 from Hongtao Liu  ---
(In reply to Jakub Jelinek from comment #8)
> Of course, yet another option is:
> --- gcc/config/i386/i386.cc   2023-12-12 08:54:39.821148670 +0100
> +++ gcc/config/i386/i386.cc   2023-12-12 11:07:03.795286363 +0100
> @@ -19377,7 +19377,10 @@ ix86_gimple_fold_builtin (gimple_stmt_it
>  do_shift:
>gcc_assert (n_args >= 2);
>if (!gimple_call_lhs (stmt))
> - break;
> + {
> +   gsi_replace (gsi, gimple_build_nop (), false);
> +   return true;
> + }
>arg0 = gimple_call_arg (stmt, 0);
>arg1 = gimple_call_arg (stmt, 1);
>elems = TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg0));
> @@ -19523,7 +19526,10 @@ ix86_gimple_fold_builtin (gimple_stmt_it
>  case IX86_BUILTIN_PABSD256_MASK:
>gcc_assert (n_args >= 1);
>if (!gimple_call_lhs (stmt))
> - break;
> + {
> +   gsi_replace (gsi, gimple_build_nop (), false);
> +   return true;
> + }
>arg0 = gimple_call_arg (stmt, 0);
>elems = TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg0));
>/* For masked ABS, only optimize if the mask is all ones.  */
> (and I wonder why all the gsi_replace calls in that function are with false,
> IMHO they should use true).

I prefer this solution, that's what we did for blendvps case.
I don't know either, just follow what we did before (with false) when folding
builtins.

[Bug target/112962] [14 Regression] ICE: SIGSEGV in operator() (recog.h:431) with -fexceptions -mssse3 and __builtin_ia32_pabsd128()

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

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

--- Comment #13 from Hongtao Liu  ---

> I prefer this solution, that's what we did for blendvps case.
> I don't know either, just follow what we did before (with false) when
> folding builtins.
I mean when I was working on
r14-1145-g1ede03e2d0437ea9c2f7453fcbe263505b4e0def, I'm just follow the existed
code.

[Bug middle-end/107723] lround/ceil/floor with -fno-fp-int-builtin-inexact

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Xi Ruoyao :

https://gcc.gnu.org/g:99182ea09f10beca8445396cbab491899536f5c3

commit r14-6455-g99182ea09f10beca8445396cbab491899536f5c3
Author: Xi Ruoyao 
Date:   Fri Nov 24 11:08:19 2023 +0800

Only allow (int)trunc(x) to (int)x simplification with
-ffp-int-builtin-inexact [PR107723]

With -fno-fp-int-builtin-inexact, trunc is not allowed to raise
FE_INEXACT and it should produce an integral result (if the input is not
NaN or Inf).  Thus FE_INEXACT should not be raised.

But (int)x may raise FE_INEXACT when x is a non-integer, non-NaN, and
non-Inf value.  C23 recommends to do so in a footnote.

Thus we should not simplify (int)trunc(x) to (int)x if
-fno-fp-int-builtin-inexact is in-effect.

gcc/ChangeLog:

PR middle-end/107723
* convert.cc (convert_to_integer_1) [case BUILT_IN_TRUNC]: Break
early if !flag_fp_int_builtin_inexact and flag_trapping_math.

gcc/testsuite/ChangeLog:

PR middle-end/107723
* gcc.dg/torture/builtin-fp-int-inexact-trunc.c: New test.

[Bug modula2/112946] Assignment of string to enumeration or set crashes

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #1 from Gaius Mulley  ---
Confirmed - many thanks for  the bug report and test code!

[Bug target/112962] [14 Regression] ICE: SIGSEGV in operator() (recog.h:431) with -fexceptions -mssse3 and __builtin_ia32_pabsd128()

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #14 from Jakub Jelinek  ---
Created attachment 56863
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56863&action=edit
gcc14-pr112962-1.patch

Patch I'm going to test.

[Bug target/112962] [14 Regression] ICE: SIGSEGV in operator() (recog.h:431) with -fexceptions -mssse3 and __builtin_ia32_pabsd128()

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

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

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

And another one for nothrow/leaf.  I'm too lazy to figure out the exact details
for -fnon-call-exceptions, will defer that to somebody who cares about those
and has time to figure out all the details.
I think e.g. aarch64 doesn't set nothrow on builtins with -fnon-call-exceptions
if they might raise floating point exceptions or read/write memory.

[Bug preprocessor/112956] Valgrind errors on pr88974.c

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

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

--- Comment #1 from Jakub Jelinek  ---
The above patch breaks a lot of tests though.
+FAIL: c-c++-common/cpp/eof-1.c  -Wc++-compat  (test for excess errors)
+FAIL: c-c++-common/cpp/eof-1.c  -Wc++-compat  unterminated macro (test for
errors, line 7)
+FAIL: c-c++-common/cpp/eof-2.c  -Wc++-compat   dg-regexp 8 not found:
"[^\\n]*eof-2.h:4:21: error: unterminated argument list invoking macro "f"\\n"
+FAIL: c-c++-common/cpp/eof-2.c  -Wc++-compat  (test for excess errors)
+FAIL: c-c++-common/cpp/eof-3.c  -Wc++-compat   dg-regexp 6 not found:
"[^\\n]*eof-2.h:4:21: error: unterminated argument list invoking macro "f"\\n"
+FAIL: c-c++-common/cpp/eof-3.c  -Wc++-compat  (test for excess errors)
+FAIL: c-c++-common/cpp/fmax-include-depth.c  -Wc++-compat   (test for errors,
line 4)
+FAIL: c-c++-common/cpp/fmax-include-depth.c  -Wc++-compat  (test for excess
errors)
+FAIL: c-c++-common/cpp/pr88974.c  -Wc++-compat   at line 5 (test for errors,
line 4)
+FAIL: c-c++-common/cpp/pr88974.c  -Wc++-compat   at line 6 (test for errors,
line 4)
+FAIL: c-c++-common/cpp/pr88974.c  -Wc++-compat  (test for excess errors)
+FAIL: gcc.dg/cpp/assert2.c (test for excess errors)
+FAIL: gcc.dg/cpp/assert2.c assert w/o predicate (test for errors, line 5)
+FAIL: gcc.dg/cpp/assert2.c test w/o predicate (test for errors, line 10)
+FAIL: gcc.dg/cpp/c23-elifdef-2.c  (test for errors, line 50)
+FAIL: gcc.dg/cpp/c23-elifdef-2.c  (test for errors, line 54)
+FAIL: gcc.dg/cpp/c23-elifdef-2.c (test for excess errors)
+FAIL: gcc.dg/cpp/directiv.c  (test for errors, line 34)
+FAIL: gcc.dg/cpp/directiv.c (test for excess errors)
+FAIL: gcc.dg/cpp/expr-overflow-1.c  (test for warnings, line 10)
+FAIL: gcc.dg/cpp/expr-overflow-1.c  (test for warnings, line 16)
+FAIL: gcc.dg/cpp/expr-overflow-1.c  (test for warnings, line 22)
+FAIL: gcc.dg/cpp/expr-overflow-1.c  (test for warnings, line 31)
+FAIL: gcc.dg/cpp/expr-overflow-1.c (test for excess errors)
+FAIL: gcc.dg/cpp/gnu11-elifdef-2.c  (test for errors, line 50)
+FAIL: gcc.dg/cpp/gnu11-elifdef-2.c  (test for errors, line 54)
+FAIL: gcc.dg/cpp/gnu11-elifdef-2.c (test for excess errors)
+FAIL: gcc.dg/cpp/gnu11-elifdef-3.c  (test for warnings, line 28)
+FAIL: gcc.dg/cpp/gnu11-elifdef-3.c  (test for warnings, line 37)
...

[Bug middle-end/112985] New: LOGICAL_OP_NON_SHORT_CIRCUIT unconditionally execute comparison even if it's very expensive

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

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

Bug ID: 112985
   Summary: LOGICAL_OP_NON_SHORT_CIRCUIT unconditionally execute
comparison even if it's very expensive
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xry111 at gcc dot gnu.org
  Target Milestone: ---

/* { dg-do compile } */
/* { dg-options "-O2 -ffast-math -fdump-tree-gimple" } */

int
short_circuit (float *a)
{
  float t1x = a[0];
  float t2x = a[1];
  float t1y = a[2];
  float t2y = a[3];
  float t1z = a[4];
  float t2z = a[5];

  if (t1x > t2y  || t2x < t1y  || t1x > t2z || t2x < t1z || t1y > t2z || t2y <
t1z)
return 0;

  return 1;
}

on LoongArch it produces something like:

  _1 = t1x > t2y;
  _2 = t2x < t1y;
  _3 = _1 | _2; 
  if (_3 != 0) goto ; else goto ;
  :
  _4 = t1x > t2z;
  _5 = t2x < t1z;
  _6 = _4 | _5; 
  if (_6 != 0) goto ; else goto ;
  :
  _7 = t1y > t2z;
  _8 = t2y < t1z;
  _9 = _7 | _8; 
  if (_9 != 0) goto ; else goto ;
  :
  D.2209 = 0;

but it's better to produce 6 if (per
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640313.html it will
produce a 1.8% improvement in SPECCPU 2017 fprate).

One obvious issue is LoongArch cost model for FP comparison is incorrect
(PR112936) but even if I set the cost of floating-point comparison to 5000 the
gimple still produces 3 if with non-shorted comparisons.

[Bug target/86131] powerpc: gcc uses costly multiply instead of shift left

[christophe.leroy at csgroup dot eu via Gcc-bugs]

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

--- Comment #3 from Christophe Leroy  ---
(In reply to Andrew Pinski from comment #2)
> The cost has been 2 since the day -mcpu=860 was added back in 1996
> (r0-10828).

Right, which means that a single left shift performs better than a multiply by
a power of two.

[Bug target/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1

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

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

--- Comment #2 from Robin Dapp  ---
It doesn't look like the same issue to me.  The other bug is related to TImode
handling in combination with mask registers.  I will also have a look at this
one.

[Bug preprocessor/112956] Valgrind errors on pr88974.c

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

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

--- Comment #2 from Jakub Jelinek  ---
--- libcpp/lex.cc.jj2023-12-11 12:39:23.353442196 +0100
+++ libcpp/lex.cc   2023-12-12 13:15:07.154019695 +0100
@@ -3809,7 +3809,7 @@ _cpp_get_fresh_line (cpp_reader *pfile)
 cpp_token *
 _cpp_lex_direct (cpp_reader *pfile)
 {
-  cppchar_t c;
+  cppchar_t c = 0;
   cpp_buffer *buffer;
   const unsigned char *comment_start;
   bool fallthrough_comment = false;
@@ -3833,6 +3833,7 @@ _cpp_lex_direct (cpp_reader *pfile)
  pfile->state.in_deferred_pragma = false;
  if (!pfile->state.pragma_allow_expansion)
pfile->state.prevent_expansion--;
+ result->src_loc = pfile->line_table->highest_line;
  return result;
}
   if (!_cpp_get_fresh_line (pfile))
@@ -3849,6 +3850,8 @@ _cpp_lex_direct (cpp_reader *pfile)
  /* Now pop the buffer that _cpp_get_fresh_line did not.  */
  _cpp_pop_buffer (pfile);
}
+ else if (c == 0)
+   result->src_loc = pfile->line_table->highest_line;
  return result;
}
   if (buffer != pfile->buffer)
seems to work though (at least in quick cpp.exp testing).

[Bug c/112986] New: s390x gcc O2, O3: Incorrect logic operation in < comparison with the same values

[22s302h0659 at sonline20 dot sen.go.kr via Gcc-bugs]

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

Bug ID: 112986
   Summary: s390x gcc O2, O3: Incorrect logic operation in <
comparison with the same values
   Product: gcc
   Version: 11.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 22s302h0659 at sonline20 dot sen.go.kr
  Target Milestone: ---

# Environment

- Compiler: s390x-linux-gnu-gcc (64bit)
- Version: gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
- Platform: Windows 11_5.15.90.1-microsoft-standard-WSL2
- Build Optimization Options: O0, O1, O2, O3

I installed the s390x-linux-gnu toolchain using the 'apt' package manager in
Ubuntu and utilized s390x-linux-gnu-gcc (version 11.4.0) from it.

# build script & excution script

```c
s390x-linux-gnu-gcc -o bug0 bug.c -O0 -fsanitize=undefined 
s390x-linux-gnu-gcc -o bug1 bug.c -O1 -fsanitize=undefined 
s390x-linux-gnu-gcc -o bug2 bug.c -O2 -fsanitize=undefined 
s390x-linux-gnu-gcc -o bug3 bug.c -O3 -fsanitize=undefined 
```

```c
qemu-s390x-static -L /usr/s390x-linux-gnu/ ./bug0
qemu-s390x-static -L /usr/s390x-linux-gnu/ ./bug1
qemu-s390x-static -L /usr/s390x-linux-gnu/ ./bug2
qemu-s390x-static -L /usr/s390x-linux-gnu/ ./bug3
```

This is the build script and the execution script.

# Source Code

```c
#include 

unsigned int g_2 = 1;
signed short g_70 = 1;

int main (int argc, char* argv[])
{
printf("bug = %d\n", ((signed long long)g_2 < g_70));
return 0;
}
```

In the s390x architecture, the '<' comparison operation for the same values
returns an incorrect logical value.

# output

```c
Expected output
O0: 0
O1: 0
O2: 0
O3: 0

Actual output
O0: 0
O1: 0
O2: 1
O3: 1
```

[Bug tree-optimization/112961] [13/14 Regression] middle-end Missed vectorization: failed to vectorize simple reduction max since GCC-13

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

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

--- Comment #4 from Richard Biener  ---
So in this case VN doesn't "fix" it because

Value numbering stmt = _29 = MAX_EXPR <_16, prephitmp_18>;
Setting value number of _29 to _29 (changed)
Making available beyond BB3 _29 for value _29
Value numbering stmt = prephitmp_23 = _29;
Setting value number of prephitmp_23 to _29 (changed)
...
Keeping eliminated stmt live as copy because of out-of-region uses

as the loop header is using this on the backedge and we are explicitly
excluding the latch block from processing to avoid CSE of PHIs(?).
I think including the latch block should be fine, but PR90402 is what
I added this special case for (the testcase still passes after reverting).

[Bug middle-end/112985] LOGICAL_OP_NON_SHORT_CIRCUIT unconditionally execute comparison even if it's very expensive

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #1 from chenglulu  ---
(In reply to Xi Ruoyao from comment #0)
> /* { dg-do compile } */
> /* { dg-options "-O2 -ffast-math -fdump-tree-gimple" } */
> 
> int
> short_circuit (float *a)
> {
>   float t1x = a[0];
>   float t2x = a[1];
>   float t1y = a[2];
>   float t2y = a[3];
>   float t1z = a[4];
>   float t2z = a[5];
> 
>   if (t1x > t2y  || t2x < t1y  || t1x > t2z || t2x < t1z || t1y > t2z || t2y
> < t1z)
> return 0;
> 
>   return 1;
> }
> 
> on LoongArch it produces something like:
> 
>   _1 = t1x > t2y;
>   _2 = t2x < t1y;
>   _3 = _1 | _2; 
>   if (_3 != 0) goto ; else goto ;
>   :
>   _4 = t1x > t2z;
>   _5 = t2x < t1z;
>   _6 = _4 | _5; 
>   if (_6 != 0) goto ; else goto ;
>   :
>   _7 = t1y > t2z;
>   _8 = t2y < t1z;
>   _9 = _7 | _8; 
>   if (_9 != 0) goto ; else goto ;
>   :
>   D.2209 = 0;
> 
> but it's better to produce 6 if (per
> https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640313.html it will
> produce a 1.8% improvement in SPECCPU 2017 fprate).
> 
> One obvious issue is LoongArch cost model for FP comparison is incorrect
> (PR112936) but even if I set the cost of floating-point comparison to 5000
> the gimple still produces 3 if with non-shorted comparisons.

I agree that the code should generate logic similar to a fixed point:

  slt $r17,$r15,$r14
  slt $r13,$r16,$r12
  or  $r13,$r13,$r17
  bstrpick.w  $r13,$r13,7,0 
  bnez$r13,.L3

[Bug middle-end/112985] LOGICAL_OP_NON_SHORT_CIRCUIT unconditionally execute comparison even if it's very expensive

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #2 from Richard Biener  ---
LOGICAL_OP_NON_SHORT_CIRCUIT is applied very early and is only based on branch
cost (not "compare cost").  It is IMHO premature optimization but it's been
that way forever.  It has similarly be adopted by the later run ifcombine pass
(originally one idea was to get rid of the early short-circuiting in
fold-const.cc but preserving actual behavior).  Note ifcombine also doesn't
care about cost but RTL expansion should when deciding whether to expand
t1x > t2y | t2x < t1y as branch or not.

My suggestion is to look at RTL expansion

[Bug target/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1

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

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

--- Comment #3 from Robin Dapp  ---
In match.pd we do something like this:


;; Function e (e, funcdef_no=0, decl_uid=2751, cgraph_uid=1, symbol_order=4)


Pass statistics of "forwprop": 

Matching expression match.pd:2771, gimple-match-2.cc:35
Matching expression match.pd:2774, gimple-match-1.cc:66
Matching expression match.pd:2781, gimple-match-2.cc:96
Aborting expression simplification due to deep recursion
Aborting expression simplification due to deep recursion
Applying pattern match.pd:6784, gimple-match-5.cc:1742
Applying pattern match.pd:6784, gimple-match-5.cc:1742
Applying pattern match.pd:6784, gimple-match-5.cc:1742
Applying pattern match.pd:6784, gimple-match-5.cc:1742
Applying pattern match.pd:6784, gimple-match-5.cc:1742
Applying pattern match.pd:6784, gimple-match-5.cc:1742
Applying pattern match.pd:6784, gimple-match-5.cc:1742
Applying pattern match.pd:6784, gimple-match-5.cc:1742
Applying pattern match.pd:6784, gimple-match-5.cc:1742
Applying pattern match.pd:6784, gimple-match-5.cc:1742
Applying pattern match.pd:6784, gimple-match-5.cc:1742
gimple_simplified to _53 = { 0, ... } & { 8, 7, 6, ... };
_63 = { 0, ... } & { -9, -8, -7, ... };
_52 = { 0, ... } & { 8, 7, 6, ... };
_74 = { 0, ... } & { -9, -8, -7, ... };
_38 = { 0, ... } & { 8, 7, 6, ... };
_40 = { 0, ... } & { -9, -8, -7, ... };
_55 = { 0, ... } & { 8, 7, 6, ... };
_57 = { 0, ... } & { -9, -8, -7, ... };
_65 = { 0, ... } & { 8, 7, 6, ... };
_72 = { 0, ... } & { -9, -8, -7, ... };
_32 = { 0, ... } & { 8, 7, 6, ... };
mask__6.19_61 = _32 == { 0, ... };

That doesn't look particularly backend related but we're trying to simplify a
mask so you never know...

[Bug middle-end/112985] LOGICAL_OP_NON_SHORT_CIRCUIT unconditionally execute comparison even if it's very expensive

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

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

--- Comment #3 from Richard Biener  ---
Btw, ideally you'd vectorize these compares ;)  (there's a missed-optimization
bug for this I think)

[Bug target/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1

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

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

--- Comment #4 from JuzheZhong  ---
Maybe try to remove this ?

 /* (X & Y) == X becomes (X & ~Y) == 0.  */
 (simplify
  (cmp:c (bit_and:c @0 @1) @0)
  (cmp (bit_and @0 (bit_not! @1)) { build_zero_cst (TREE_TYPE (@0)); }))
 (simplify
  (cmp:c (convert@3 (bit_and (convert@2 @0) INTEGER_CST@1)) (convert @0))
  (if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
   && INTEGRAL_TYPE_P (TREE_TYPE (@2))
   && INTEGRAL_TYPE_P (TREE_TYPE (@3))
   && TYPE_PRECISION (TREE_TYPE (@2)) == TYPE_PRECISION (TREE_TYPE (@0))
   && TYPE_PRECISION (TREE_TYPE (@3)) > TYPE_PRECISION (TREE_TYPE (@2))
   && !wi::neg_p (wi::to_wide (@1)))
   (cmp (bit_and @0 (convert (bit_not @1)))
{ build_zero_cst (TREE_TYPE (@0)); })))

[Bug target/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1

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

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

--- Comment #5 from Robin Dapp  ---
Yes that's what I just tried.  No infinite loop anymore then.  But that's not a
new simplification and looks reasonable so there must be something special for
our backend.

[Bug analyzer/112704] FAIL: gcc.dg/analyzer/data-model-20.c (test for warnings, line 17)

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

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

--- Comment #3 from David Malcolm  ---
Aha!  Thanks.

[Bug tree-optimization/112961] [13/14 Regression] middle-end Missed vectorization: failed to vectorize simple reduction max since GCC-13

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:878cb5acf0c499702ffd315e273f55e8bd0970b8

commit r14-6457-g878cb5acf0c499702ffd315e273f55e8bd0970b8
Author: Richard Biener 
Date:   Tue Dec 12 14:01:47 2023 +0100

tree-optimization/112961 - include latch in if-conversion CSE

The following makes sure to also process the (empty) latch when
performing CSE on the if-converted loop body.  That's important
to get all uses of copies propagated out on the backedge as well.
To avoid CSE on the PHI nodes itself which is prohibitive
(see PR90402) this temporarily adds a fake entry edge to the loop.

PR tree-optimization/112961
* tree-if-conv.cc (tree_if_conversion): Instead of excluding
the latch block from VN, add a fake entry edge.

* g++.dg/vect/pr112961.cc: New testcase.

[Bug tree-optimization/112961] [13 Regression] middle-end Missed vectorization: failed to vectorize simple reduction max since GCC-13

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||14.0
   Priority|P3  |P2
Summary|[13/14 Regression]  |[13 Regression] middle-end
   |middle-end Missed   |Missed vectorization:
   |vectorization: failed to|failed to vectorize simple
   |vectorize simple reduction  |reduction max since GCC-13
   |max since GCC-13|

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

[Bug ipa/92606] [11/12/13 Regression][avr] invalid merge of symbols in progmem and data sections

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

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

--- Comment #29 from GCC Commits  ---
The master branch has been updated by Richard Biener :

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

commit r14-6458-geee13a3730bd1d7aa7b40687b1ee49c17d95159f
Author: Richard Biener 
Date:   Mon Dec 11 10:08:24 2023 +0100

ipa/92606 - properly handle no_icf attribute for variables

The following adds no_icf handling for variables where the attribute
was rejected.  It also fixes the check for no_icf by checking both
the source and the targets decl.

PR ipa/92606
gcc/c-family/
* c-attribs.cc (handle_noicf_attribute): Also allow the
attribute on global variables.

gcc/
* ipa-icf.cc (sem_item_optimizer::merge_classes): Check
both source and alias for the no_icf attribute.
* doc/extend.texi (no_icf): Document variable attribute.

[Bug tree-optimization/112736] [14 Regression] vectorizer is introducing out of bounds memory access

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Richard Biener :

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

commit r14-6459-g6d0b0806eb638447c3184c59d996c2f178553d45
Author: Richard Biener 
Date:   Mon Dec 11 14:39:48 2023 +0100

tree-optimization/112736 - avoid overread with non-grouped SLP load

The following aovids over/under-read of storage when vectorizing
a non-grouped load with SLP.  Instead of forcing peeling for gaps
use a smaller load for the last vector which might access excess
elements.  This builds upon the existing optimization avoiding
peeling for gaps, generalizing it to all gap widths leaving a
power-of-two remaining number of elements (but it doesn't replace
or improve that particular case at this point).

I wonder if the poly relational compares I set up are good enough
to guarantee /* remain should now be > 0 and < nunits.  */.

There is existing test coverage that runs into /* DR will be unused.  */
always when the gap is wider than nunits.  Compared to the
existing gap == nunits/2 case this only adjusts the load that will
cause the overrun at the end, not every load.  Apart from the
poly relational compares it should reliably cover these cases but
I'll leave it for stage1 to remove.

PR tree-optimization/112736
* tree-vect-stmts.cc (vectorizable_load): Extend optimization
to avoid peeling for gaps to handle single-element non-groups
we now allow with SLP.

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

[Bug tree-optimization/112736] [14 Regression] vectorizer is introducing out of bounds memory access

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug ipa/92606] [11/12/13 Regression][avr] invalid merge of symbols in progmem and data sections

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #30 from Richard Biener  ---
So as a workaround it should be possible to attach no_icf to PROGMEM vars,
either in the Arduino.h header or during backend processing of the progmem
attribute.

This support could be backported if requested.

[Bug ipa/92606] [11/12/13 Regression][avr] invalid merge of symbols in progmem and data sections

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

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

--- Comment #31 from Jan Hubicka  ---
This is Maritn's code, but I agree that equals_wpa should reject pairs with
"dangerous" attributes on them (ideally we should hash them). 
I think we could add test for same attributes to equals_wpa and eventually
white list attributes we consider mergeable?
There are attributes that serves no meaning once we enter backend, so it may be
also good option to strip them, so they are not confusing passes like ICF.

[Bug c++/112968] Valgrind error on libstdc++-v3/testsuite/18_support/comparisons/object/93479.cc

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I believe the bug is in
https://gcc.gnu.org/legacy-ml/gcc-patches/2018-04/msg00709.html
aka r8-7885-ga56e2f69fede451499cfcbb58bab7687e4b1643a
When tinst_level::to_list is called, if it allocates new TREE_LIST, all is
fine, but
otherwise it goes through:
  tree ret = tree_list_freelist ().alloc ();
  TREE_PURPOSE (ret) = tldcl;
  TREE_VALUE (ret) = targs;
where alloc does
T *obj = head;
head = next (head);
reinit (obj);
return obj;
and
template <>
inline void
freelist::reinit (tree obj ATTRIBUTE_UNUSED)
{
  tree_base *b ATTRIBUTE_UNUSED = &obj->base;

#ifdef ENABLE_GC_CHECKING
  gcc_checking_assert (TREE_CODE (obj) == TREE_LIST);
  VALGRIND_DISCARD (VALGRIND_MAKE_MEM_UNDEFINED (obj, sizeof (tree_list)));
  memset (obj, 0, sizeof (tree_list));
#endif

  /* Let valgrind know the entire object is available, but
 uninitialized.  */
  VALGRIND_DISCARD (VALGRIND_MAKE_MEM_UNDEFINED (obj, sizeof (tree_list)));

#ifdef ENABLE_GC_CHECKING
  TREE_SET_CODE (obj, TREE_LIST);
#else
  VALGRIND_DISCARD (VALGRIND_MAKE_MEM_DEFINED (b, sizeof (*b)));
#endif
}

Now, tree_list is:
struct GTY(()) tree_list {
  struct tree_common common;
  tree purpose;
  tree value;
};
struct GTY(()) tree_common {
  struct tree_typed typed;
  tree chain;
};
struct GTY(()) tree_typed {
  struct tree_base base;
  tree type;
};
and the 2 stores to TREE_PURPOSE/TREE_VALUE afterwards initialize those 2, so I
believe
this leaves from valgrind annotation POV TREE_TYPE and TREE_CHAIN of the
TREE_LIST allocated from the freelist uninitialized (even when it actually is
in reality initialized from the initial build_tree_list call before it got put
into the cache).

I must say it is unclear what should be TREE_CHAIN value after
tinst_level::to_list
and what should be TREE_TYPE.  Right now it is sometimes well defined NULL and
NULL (if we allocated it freshly), sometimes NULL and NULL with valgrind think
it is uninitialized (if ENABLE_GC_CHECKING where reinit clears the whole object
and sets TREE_CODE again) and sometimes garbage with valgrind thinking it is
undefined (otherwise).
After pending_template_freelist ().alloc (); we already clear pt->next = NULL;
and
similarly after tinst_level_freelist ().alloc (); we clear new_level->next =
NULL;
so I think it is just the tree_list case.

So, wonder about
--- gcc/cp/pt.cc.jj 2023-12-11 23:52:03.592513063 +0100
+++ gcc/cp/pt.cc2023-12-12 16:40:09.259903877 +0100
@@ -9525,7 +9525,7 @@ template <>
 inline void
 freelist::reinit (tree obj ATTRIBUTE_UNUSED)
 {
-  tree_base *b ATTRIBUTE_UNUSED = &obj->base;
+  tree_common *c ATTRIBUTE_UNUSED = &obj->common;

 #ifdef ENABLE_GC_CHECKING
   gcc_checking_assert (TREE_CODE (obj) == TREE_LIST);
@@ -9540,8 +9540,9 @@ freelist::reinit (tree obj AT
 #ifdef ENABLE_GC_CHECKING
   TREE_SET_CODE (obj, TREE_LIST);
 #else
-  VALGRIND_DISCARD (VALGRIND_MAKE_MEM_DEFINED (b, sizeof (*b)));
+  TREE_CHAIN (obj) = NULL_TREE;
 #endif
+  VALGRIND_DISCARD (VALGRIND_MAKE_MEM_DEFINED (c, sizeof (*c)));
 }

 /* Point to the first object in the TREE_LIST freelist.  */
where this (IMHO) ought to ensure that both TREE_TYPE and TREE_CHAIN is
accessible and NULL after tinst_level::to_list regardless of whether it was
freshly allocated or not
and regardless of ENABLE_GC_CHECKING or not.

[Bug modula2/112984] Compiling program with -Wpedantic shows warning in libraries

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

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

--- Comment #2 from Gaius Mulley  ---
Created attachment 56865
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56865&action=edit
Proposed fix

Here is a proposed fix - all libraries can be compiled with -Wpedantic (apart
from two which have necessary infinite loops).  Perhaps the -Wpedantic needs to
be turned off via an attribute in these two modules (one of which is the
procedure SYSTEM.Listen which waits for activity in a set of fds).

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

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

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

--- Comment #22 from Tamar Christina  ---
Bisected the remaining regression to:

dd86a5a69cbda40cf76388a65d3317c91cb2b501 is the first bad commit
commit dd86a5a69cbda40cf76388a65d3317c91cb2b501
Author: Richard Biener 
Date:   Thu Jun 22 11:40:46 2023 +0200

tree-optimization/96208 - SLP of non-grouped loads

The following extends SLP discovery to handle non-grouped loads
in loop vectorization in the case the same load appears in all
lanes.

It looks like our cost model doesn't handle this change correctly,
so we over-vectorize MorphologyApply.constprop.0.  The resulting
code is significantly slower due to all the lane shufflings to
prepare the vector.

Reducing a testcase...

[Bug c++/93259] Unsized temporary array initialization problem

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #8 from Patrick Palka  ---
Fixed for GCC 12.3+ then, thanks for the heads up.

[Bug tree-optimization/112822] [14 regression] ICE: invalid RHS for gimple memory store after r14-5831-gaae723d360ca26

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

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

--- Comment #9 from Martin Jambor  ---
Thank you, I have proposed the patch on the mailing list:

https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640356.html

If it is approved, I'd also like you to add the testcase to the testsuite as a
target specific test.

[Bug target/112987] New: [14 Regression][aarch64] ICE in aarch64_do_track_speculation, at config/aarch64/aarch64-speculation.cc:214 since r14-5886-g426fddcbdad674

[mjires at suse dot cz via Gcc-bugs]

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

Bug ID: 112987
   Summary: [14 Regression][aarch64] ICE in
aarch64_do_track_speculation, at
config/aarch64/aarch64-speculation.cc:214 since
r14-5886-g426fddcbdad674
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjires at suse dot cz
CC: nszabolcs at gmail dot com
  Target Milestone: ---
Target: aarch64

Compiling testcase gcc.target/aarch64/eh_return-2.c results in ICE since
r14-5886-g426fddcbdad674.

$ cat eh_return-2.c
/* { dg-do compile } */
/* { dg-final { scan-assembler "add\tsp, sp, x5" } } */
/* { dg-final { scan-assembler "br\tx6" } } */

void
foo (unsigned long off, void *handler)
{
  __builtin_eh_return (off, handler);
}


$ aarch64-linux-gnu-gcc eh_return-2.c -mtrack-speculation
during RTL pass: speculation
eh_return-2.c: In function ‘foo’:
eh_return-2.c:9:1: internal compiler error: in aarch64_do_track_speculation, at
config/aarch64/aarch64-speculation.cc:214
9 | }
  | ^
0x8f6f6f aarch64_do_track_speculation()
   
/home/mjires/git/GCC/master/gcc/config/aarch64/aarch64-speculation.cc:214
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.


$ aarch64-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/mjires/built/master-aarch64-linux-gnu/libexec/gcc/aarch64-linux-gnu/14.0.0/lto-wrapper
Target: aarch64-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--target=aarch64-linux-gnu --disable-bootstrap --enable-languages=c,c++
--disable-multilib --prefix=/home/mjires/built/master-aarch64-linux-gnu/
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231207 (experimental) (GCC)

[Bug tree-optimization/112982] Missing optimization: fold max(b, a + 1) to b when a < b

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug middle-end/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1

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

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

--- Comment #6 from Andrew Pinski  ---
Looks like `{ 0, ... } & { -9, -8, -7, ... }` is not simplifying down to just
`{ 0, ...}`

[Bug middle-end/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1

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

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

--- Comment #7 from Andrew Pinski  ---
Can you modify:
```
/* x & 0 -> 0  */
(simplify
 (bit_and @0 integer_zerop@1)
 @1)
```
to
```
/* x & 0 -> 0  */
(simplify
 (bit_and:c @0 integer_zerop@1)
 @1)
```

That in theory should not matter but I don't think we simplify normally VLA
constants ...

[Bug tree-optimization/112940] ICE: verify_ssa failed: definition in block 4 does not dominate use in block 8 at -O with _BitInt()

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug target/112987] [14 Regression][aarch64] ICE in aarch64_do_track_speculation, at config/aarch64/aarch64-speculation.cc:214 since r14-5886-g426fddcbdad674

[mjires at suse dot cz via Gcc-bugs]

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

--- Comment #1 from Michal Jireš  ---
Sorry for initially reporting with outdated GCC. Identical ICE is still present
with:

$ aarch64-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/mjires/built/master/libexec/gcc/aarch64-linux-gnu/14.0.0/lto-wrapper
Target: aarch64-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --target=aarch64-linux-gnu
--disable-bootstrap --enable-languages=c,c++ --disable-multilib
--disable-libsanitizer --enable-checking
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231212 (experimental) (GCC)

[Bug target/112988] New: [14] RISC-V vector: Variadic function call causes runtime failure

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 112988
   Summary: [14] RISC-V vector: Variadic function call causes
runtime failure
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Testcase:
int a = 0;
int p, q, r, x = 230;
short d;
int e[256];
static struct f w;
int *c = &r;

short y(short z) {
  return z * d;
}

#pragma pack(1)
struct f {
  int g;
  short h;
  int j;
  char k;
  char l;
  long m;
  long n;
  int o;
} s = {1}, v, t, *u = &v, *b = &s;

void add_em_up(int count, ...) {
  __builtin_va_list ap;
  __builtin_va_start(ap, count);
  __builtin_va_end(ap);
}

int main() {
  int i = 0;
  for (; i < 256; i++)
e[i] = i;

  p = 0;
  for (; p <= 0; p++) {
*c = 4;
*u = t;
x |= y(6 >= q);
  }

  *b = w;

  add_em_up(1, 1);

  if (a != 0)
return 1;
  if (q != 0)
return 2;
  if (p != 1)
return 3;
  if (r != 4)
return 4;
  if (x != 0xE6)
return 5;
  if (d != 0)
return 6;

  return 0;
}

Commands:
rv64gcv
> /scratch/tc-testing/tc-dec-11-trunk/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -march=rv64gcv -mabi=lp64d -O3 red.c -o rv64gcv.out
> QEMU_CPU=rv64,vlen=128,v=true,vext_spec=v1.0 
> /scratch/tc-testing/tc-dec-8-trunk/build-rv64gcv/bin/qemu-riscv64 rv64gcv.out
> echo $?
3

rv64gc
> /scratch/tc-testing/tc-dec-11-trunk/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
>  -march=rv64gc -mabi=lp64d -O3 red.c -o rv64gc.out
> QEMU_CPU=rv64,vlen=128,v=true,vext_spec=v1.0 
> /scratch/tc-testing/tc-dec-8-trunk/build-rv64gcv/bin/qemu-riscv64 rv64gc.out
> echo $?
0

Godbolt:
https://godbolt.org/z/Pq7Yns56G

Testcase seems very similar to pr112929, filing this bug to give people an
additional testcase to look at :)

[Bug middle-end/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1

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

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

--- Comment #8 from Robin Dapp  ---
Yes, can confirm that this helps.

[Bug middle-end/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1

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

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

--- Comment #9 from Andrew Pinski  ---
The real fix will be to const_binop .
Right now const_binop only handles a few cases for VLA's VECTOR_CST and it
seems like it really only handles +, -, and sometimes * and sometimes left shit
.

[Bug middle-end/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug middle-end/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1

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

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #9)
> The real fix will be to const_binop .
> Right now const_binop only handles a few cases for VLA's VECTOR_CST and it
> seems like it really only handles +, -, and sometimes * and sometimes left
> shit .

I should say for stepped VLA VECTOR_CST .
In this case have one fully dup 0 and'ed with a stepped VECTOR_CST and that is
not handled.

Maybe a few special cases are needed here for &, |, ^ might be enough.

BIT_AND_EXPR: handle both 0 and -1
BIT_IOR_EXPR: handle both 0 and -1
BIT_XOR_EXPR: handle 0

[Bug c++/101631] gcc allows for the changing of an union active member to be changed via a reference

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||m.cencora at gmail dot com

--- Comment #8 from Patrick Palka  ---
*** Bug 98637 has been marked as a duplicate of this bug. ***

[Bug c++/98637] Changing active union member via assignment expression should require trivial default constructor in constexpr context

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #2 from Patrick Palka  ---
This is fixed on trunk by r14-4771-g1d260ab0e39ea6, so I guess we can mark this
a dup of PR101631.

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

[Bug target/112986] s390x gcc O2, O3: Incorrect logic operation in < comparison with the same values

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
How was gcc configured (gcc -v should print that)?  Mainly, what -march= and
-mtune= does it default to and is it PIE by default or not?
I certainly don't see anything in the -O1 vs. -O2 assembly difference that
would result in a different result.

[Bug target/112987] [14 Regression][aarch64] ICE in aarch64_do_track_speculation, at config/aarch64/aarch64-speculation.cc:214 since r14-5886-g426fddcbdad674

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 CC||pinskia at gcc dot gnu.org

[Bug tree-optimization/112982] Missing optimization: fold max(b, a + 1) to b when a < b

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Confirmed. Very much related to PR 110199 .

[Bug preprocessor/112978] Five minute long error message when OpenMP pragma is erroneously placed in macro

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

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

Xi Ruoyao  changed:

   What|Removed |Added

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

--- Comment #3 from Xi Ruoyao  ---
There is nothing we can do here.

Note that GCC security policy is clear that if you need to compile some random
code completely not trust-able, use a sandbox.

And for "excessive amount of diagnostics" you may use -fmax-errors= as a
workaround.

[Bug modula2/112984] Compiling program with -Wpedantic shows warning in libraries

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

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

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

https://gcc.gnu.org/g:01cca857aa3e86a750f5df77ca6c36c0739f10f0

commit r14-6465-g01cca857aa3e86a750f5df77ca6c36c0739f10f0
Author: Gaius Mulley 
Date:   Tue Dec 12 19:29:06 2023 +

PR modula2/112984 Compiling program with -Wpedantic shows warning in
libraries

This patch tidies up the library modules so that -Wpedantic does not
generate any warnings (apart from two procedures with legitimate infinite
loops).

gcc/m2/ChangeLog:

PR modula2/112984
* gm2-libs-coroutines/SYSTEM.mod: Remove redundant import of
memcpy.
* gm2-libs-iso/ClientSocket.mod: Remove redundant import of
IOConsts.
* gm2-libs-iso/IOChan.mod: Remove redundant import of IOConsts.
* gm2-libs-iso/IOLink.mod: Remove redundant import of IOChan and
SYSTEM.
* gm2-libs-iso/IOResult.mod: Remove redundant import of IOChan.
* gm2-libs-iso/LongIO.mod: Remove redundant import of writeString.
* gm2-libs-iso/LongWholeIO.mod: Remove redundant import of IOChan.
* gm2-libs-iso/M2RTS.mod: Remove redundant import of ADDRESS.
* gm2-libs-iso/MemStream.mod: Remove redundant import of ADDRESS.
* gm2-libs-iso/RTdata.mod: Remove redundant import of
DeviceTablePtr.
* gm2-libs-iso/RTfio.mod: Remove redundant import of
DeviceTablePtr.
* gm2-libs-iso/RTgen.mod: Remove redundant import of
DeviceTablePtr.
* gm2-libs-iso/RealIO.mod: Remove redundant import of writeString.
* gm2-libs-iso/RndFile.mod: Remove redundant import of SYSTEM.
* gm2-libs-iso/SYSTEM.mod: Remove redundant import of memcpy.
* gm2-libs-iso/ShortWholeIO.mod: Remove redundant import of
IOConsts.
* gm2-libs-iso/TextIO.mod: Remove redundant import of IOChan.
* gm2-libs-iso/TextUtil.mod: Remove redundant import of IOChan.
* gm2-libs-iso/WholeIO.mod: Remove redundant import of IOChan.
* gm2-libs-log/BitByteOps.mod: Remove redundant import of BYTE.
* gm2-libs-log/FileSystem.mod: Remove redundant import of BYTE and
ADDRESS.
* gm2-libs-log/InOut.mod: Remove redundant import of String.
* gm2-libs-log/RealConversions.mod: Remove redundant import of
StringToLongreal.
* gm2-libs/FIO.mod: Remove redundant import of SIZE.
* gm2-libs/FormatStrings.mod: Remove redundant import of String
and ConCatChar.
* gm2-libs/IO.mod: Remove redundant import of SIZE.
* gm2-libs/Indexing.mod: Remove redundant import of ADDRESS.
* gm2-libs/M2Dependent.mod: Remove redundant import of SIZE.
* gm2-libs/M2RTS.mod: Remove redundant import of ADDRESS.
* gm2-libs/OptLib.mod: Remove redundant import of DynamicStrings.
* gm2-libs/SYSTEM.mod: Remove redundant import of memcpy.
* gm2-libs/StringConvert.mod: Remove redundant import of String.

libgm2/ChangeLog:

* libm2iso/Makefile.am (libm2iso_la_M2FLAGS): Added line breaks.
* libm2iso/Makefile.in: Regenerate.
* libm2log/Makefile.am (libm2log_la_M2FLAGS): Added line breaks.
* libm2log/Makefile.in: Regenerate.
* libm2pim/Makefile.am (libm2pim_la_M2FLAGS): Added line breaks.
* libm2pim/Makefile.in: Regenerate.

gcc/testsuite/ChangeLog:

PR modula2/112984
* gm2/switches/pedantic/pass/hello.mod: New test.
* gm2/switches/pedantic/pass/switches-pedantic-pass.exp: New test.

Signed-off-by: Gaius Mulley 

[Bug modula2/112984] Compiling program with -Wpedantic shows warning in libraries

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

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

[Bug target/112989] New: GC ICE with C++, `#include ` and `-fsanitize=address`

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

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

Bug ID: 112989
   Summary: GC ICE with C++, `#include ` and
`-fsanitize=address`
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: GC, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-linux-gnu

Just a simple:
```
#pragma GCC aarch64 "arm_sve.h"
```

Causes an ICE:
```
ubuntu@ubuntu:~/src/upstream-gcc-aarch64\#
/bajas/pinskia/src/upstream-gcc-aarch64/gcc/objdir/stage1-gcc/cc1plus t.cc
-quiet -march=armv8.6-a+sve  -fsanitize=address
t.cc:1:32: internal compiler error: Segmentation fault
1 | #pragma GCC aarch64 "arm_sve.h"
  |^
0x1d150ff crash_signal
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/toplev.cc:316
0x12fb314 c_tree_chain_next(tree_node*)
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/c-family/c-common.h:1347
0x12eeda3 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:108
0x240ca7f gt_ggc_mx_registered_function(void*)
./gt-aarch64-sve-builtins.h:29
0x240cb23 gt_ggc_mx(aarch64_sve::registered_function*&)
./gt-aarch64-sve-builtins.h:47
0x240ea3f void
gt_ggc_mx(vec*)
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/vec.h:1449
0x240caef gt_ggc_mx_vec_registered_function__va_gc_(void*)
./gt-aarch64-sve-builtins.h:39
0x17a1237 ggc_mark_root_tab
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/ggc-common.cc:75
0x17a13a7 ggc_mark_roots()
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/ggc-common.cc:104
0x146d183 ggc_collect(ggc_collect)
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/ggc-page.cc:2227
0xfd0567 c_parse_final_cleanups()
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/cp/decl2.cc:5064
0x140a413 c_common_parse_file()
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/c-family/c-opts.cc:1319
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

```

I have not debugged this but I can't reproduce with a cross though, only a
native build (but stage1)

[Bug tree-optimization/112822] [14 regression] ICE: invalid RHS for gimple memory store after r14-5831-gaae723d360ca26

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

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

--- Comment #10 from GCC Commits  ---
The master branch has been updated by Martin Jambor :

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

commit r14-6466-gcd7d0b4cf789264cd75ab7df5df232dc58061ed7
Author: Martin Jambor 
Date:   Tue Dec 12 21:19:21 2023 +0100

SRA: Force gimple operand in an additional corner case (PR 112822)

PR 112822 revealed a corner case in load_assign_lhs_subreplacements
where it creates invalid gimple: an assignment where on the LHS there
is a complex variable which however is not a gimple register because
it has partial defs and on the right hand side there is a
VIEW_CONVERT_EXPR.  This patch invokes force_gimple_operand_gsi on
such statements (like it already does when both sides of a generated
assignment have partial definitions.

gcc/ChangeLog:

2023-12-12  Martin Jambor  

PR tree-optimization/112822
* tree-sra.cc (load_assign_lhs_subreplacements): Invoke
force_gimple_operand_gsi also when LHS has partial stores and RHS
is a
VIEW_CONVERT_EXPR.

[Bug target/112990] New: [14 Regression][s390x] ICE in related_vector_mode, at stor-layout.cc:539 since r14-3381-g27de9aa152141e

[mjires at suse dot cz via Gcc-bugs]

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

Bug ID: 112990
   Summary: [14 Regression][s390x] ICE in related_vector_mode, at
stor-layout.cc:539 since r14-3381-g27de9aa152141e
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjires at suse dot cz
CC: rguenther at suse dot de
  Target Milestone: ---
Target: s390x

Compiling reduced testcase gcc.target/s390/vector/reverse-elements-6.c with
s390x cross compiler results in ICE since r14-3381-g27de9aa152141e.


$ cat reverse-elements-6.c
typedef long __attribute__((vector_size(16))) V2DI;
V2DI v2di_x;
void v2di() {
  V2DI y, z;
  for (int i = 0; i < 2; ++i)
z[i] = y[1];
  v2di_x = z;
}


$ s390x-linux-gnu-gcc reverse-elements-6.c -O1
during RTL pass: expand
reverse-elements-6.c: In function ‘v2di’:
reverse-elements-6.c:7:10: internal compiler error: in related_vector_mode, at
stor-layout.cc:539
7 |   v2di_x = z;
  |   ~~~^~~
0x15dd230 related_vector_mode(machine_mode, scalar_mode, poly_int<1u, unsigned
long>)
/home/mjires/git/GCC/master/gcc/stor-layout.cc:539
0x1428a35 qimode_for_vec_perm(machine_mode)
/home/mjires/git/GCC/master/gcc/optabs-query.cc:358
0x141db61 expand_vec_perm_const(machine_mode, rtx_def*, rtx_def*,
int_vector_builder > const&, machine_mode, rtx_def*)
/home/mjires/git/GCC/master/gcc/optabs.cc:6445
0x106f66f expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/home/mjires/git/GCC/master/gcc/expr.cc:10844
0x1070df4 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/mjires/git/GCC/master/gcc/expr.cc:11216
0x1068fa1 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/home/mjires/git/GCC/master/gcc/expr.cc:9407
0x105debf store_expr(tree_node*, rtx_def*, int, bool, bool)
/home/mjires/git/GCC/master/gcc/expr.cc:6709
0x105c5ff expand_assignment(tree_node*, tree_node*, bool)
/home/mjires/git/GCC/master/gcc/expr.cc:6430
0xec1ec7 expand_gimple_stmt_1
/home/mjires/git/GCC/master/gcc/cfgexpand.cc:3960
0xec22b5 expand_gimple_stmt
/home/mjires/git/GCC/master/gcc/cfgexpand.cc:4058
0xeca6e0 expand_gimple_basic_block
/home/mjires/git/GCC/master/gcc/cfgexpand.cc:6114
0xecca96 execute
/home/mjires/git/GCC/master/gcc/cfgexpand.cc:6849
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.


$ s390x-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=s390x-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/mjires/built/master/libexec/gcc/s390x-linux-gnu/14.0.0/lto-wrapper
Target: s390x-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --target=s390x-linux-gnu --disable-bootstrap
--enable-languages=c,c++ --disable-multilib --disable-libsanitizer
--enable-checking : (reconfigured) /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --target=s390x-linux-gnu --disable-bootstrap
--enable-languages=c,c++ --disable-multilib --disable-libsanitizer
--enable-checking
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231212 (experimental) (GCC)

[Bug analyzer/112655] analyzer/infinite-loop.cc:75: Possible performance problem ?

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #1 from David Malcolm  ---
Thanks!  Am working on a fix.

[Bug target/112989] GC ICE with C++, `#include ` and `-fsanitize=address`

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed (but I can't reproduce it with a cross, either).

[Bug target/112989] GC ICE with C++, `#include ` and `-fsanitize=address`

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

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

--- Comment #2 from Andrew Pinski  ---
#1  0x012eeda4 in gt_ggc_mx_lang_tree_node (x_p=0xf6bd4900) at
./gt-cp-tree.h:108
108xlimit = ((union lang_tree_node *) c_tree_chain_next
(&(*xlimit).generic));
(gdb) up
#2  0x0240ca80 in gt_ggc_mx_registered_function (x_p=0xf6b854f0) at
./gt-aarch64-sve-builtins.h:29
29gt_ggc_m_9tree_node ((*x).decl);
(gdb) p x
$8 = (aarch64_sve::registered_function * const) 0xf6b854f0
(gdb) p *x
$9 = {instance = {base_name = 0x3c08b80 "svmla", base = 0x3c21cb8
, shape = 0x3c165a0
, mode_suffix_id =
aarch64_sve::MODE_single, type_suffix_ids = {aarch64_sve::TYPE_SUFFIX_za64,
aarch64_sve::TYPE_SUFFIX_s16},
group_suffix_id = aarch64_sve::GROUP_vg4x1, pred = aarch64_sve::PRED_none},
decl = 0xf6bd4900, required_extensions = 5497558138885, overloaded_p =
false}
(gdb) p x->decl
$10 = (tree) 0xf6bd4900
(gdb) p debug_tree(x->decl)
 

[Bug target/112990] [14 Regression][s390x] ICE in related_vector_mode, at stor-layout.cc:539 since r14-3381-g27de9aa152141e

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug target/112989] GC ICE with C++, `#include ` and `-fsanitize=address`

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

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

--- Comment #3 from Andrew Pinski  ---
```
Breakpoint 1, ggc_free (p=0xf6bd4900) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/ggc-page.cc:1612
1612  if (in_gc)
(gdb) bt
#0  ggc_free (p=0xf6bd4900) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/ggc-page.cc:1612
#1  0x00f59a48 in duplicate_decls (newdecl=0xf6bd4900,
olddecl=0xf6bd3d00, hiding=false, was_hidden=false) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/cp/decl.cc:3312
#2  0x010f57a0 in pushdecl (decl=0xf6bd4900, hiding=false) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/cp/name-lookup.cc:3920
#3  0x00f62300 in cxx_simulate_builtin_function_decl
(decl=0xf6bd4900) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/cp/decl.cc:5239
#4  0x01a0c5c8 in simulate_builtin_function_decl (location=255050,
name=0x48b5200 "svmla_za64_vg4x1", type=0xf6b1cb70, function_code=31409,
library_name=0x0, attrs=0xf6bced80) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/langhooks.cc:774
#5  0x023ff6b0 in aarch64_sve::function_builder::add_function
(this=0xf490, instance=..., name=0x48b5200 "svmla_za64_vg4x1",
fntype=0xf6b1cb70, attrs=0xf6bced80, required_extensions=5497558138885,
overloaded_p=false, placeholder_p=false)
at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/config/aarch64/aarch64-sve-builtins.cc:1490
#6  0x023ff8e8 in aarch64_sve::function_builder::add_unique_function
(this=0xf490, instance=..., return_type=0xf5b30f18,
argument_types=..., required_extensions=5497558138885,
force_direct_overloads=false)
at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/config/aarch64/aarch64-sve-builtins.cc:1542
#7  0x02411fe8 in aarch64_sve::build_one (b=..., signature=0x3c16590
"_,su32,t1,v1", group=..., mode_suffix_id=aarch64_sve::MODE_single, ti=0, gi=0,
pi=0, force_direct_overloads=false) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/config/aarch64/aarch64-sve-builtins-shapes.cc:331
#8  0x02412508 in aarch64_sve::build_all (b=..., signature=0x3c16590
"_,su32,t1,v1", group=..., mode_suffix_id=aarch64_sve::MODE_single,
force_direct_overloads=false) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/config/aarch64/aarch64-sve-builtins-shapes.cc:470
#9  0x02415418 in aarch64_sve::binary_za_slice_opt_single_def::build
(this=0x3c165a0 , b=...,
group=...) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/config/aarch64/aarch64-sve-builtins-shapes.cc:1896
#10 0x023fffec in
aarch64_sve::function_builder::register_function_group (this=0xf490,
group=...) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/config/aarch64/aarch64-sve-builtins.cc:1637
#11 0x0240b0bc in aarch64_sve::handle_arm_sve_h () at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/config/aarch64/aarch64-sve-builtins.cc:4588
#12 0x01460b1c in aarch64_pragma_aarch64 () at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/config/aarch64/aarch64-c.cc:347
#13 0x01412ebc in c_invoke_pragma_handler (id=14) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/c-family/c-pragma.cc:1741
#14 0x01199f8c in cp_parser_pragma (parser=0xf5e54e18,
context=pragma_external, if_p=0x0) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/cp/parser.cc:50751
#15 0x01137730 in cp_parser_toplevel_declaration
(parser=0xf5e54e18) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/cp/parser.cc:15392
#16 0x0111f240 in cp_parser_translation_unit (parser=0xf5e54e18) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/cp/parser.cc:5273
#17 0x0119a354 in c_parse_file () at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/cp/parser.cc:50845
#18 0x0140a314 in c_common_parse_file () at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/c-family/c-opts.cc:1301
#19 0x01d156a4 in compile_file () at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/toplev.cc:446
#20 0x01d1989c in do_compile () at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/toplev.cc:2150
#21 0x01d19dd4 in toplev::main (this=0xf8d0, argc=5,
argv=0xfa18) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/toplev.cc:2306
#22 0x0358944c in main (argc=5, argv=0xfa18) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/main.cc:39
```

[Bug tree-optimization/110199] [12/13/14 Regression] Missing VRP transformation with MIN_EXPR and known relation

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #3 from Andrew Macleod  ---
(In reply to Andrew Pinski from comment #2)
> I Kinda see how to implement this by creating
> operator_min::fold_range/operator_max::fold_range but I am still new on
> using these interfaces so I am not 100% sure how to use them.

Actually, on ranger, we'd be able to make the range choice of the range of a_2
or b_3, but it can't rewrite the IL...  and since the range of both is varying,
fold_range would still return varying.  Unless we indicate there are relations.
 fodl_range itself only takes what it is given, so we have to query the
relations first. 

In theory all that is missing is to teach simplification about relation
queries. For instance, in simplify_using_ranges::fold_cond_with_ops, we are
invoking the range-op handler without any relations.. we query the ranges, but
not the relation. If we add something like this (and make sure both operands
are symbolic)

diff --git a/gcc/vr-values.cc b/gcc/vr-values.cc
index ecb294131b0..ad2c2d6c090 100644
--- a/gcc/vr-values.cc
+++ b/gcc/vr-values.cc
@@ -315,10 +315,17 @@ simplify_using_ranges::fold_cond_with_ops (enum tree_code
code,
   || !query->range_of_expr (r1, op1, s))
 return NULL_TREE;

+  relation_kind rel = VREL_VARYING;
+  if (gimple_range_ssa_p (op0) && gimple_range_ssa_p (op1))
+rel = query->query_relation (s, op0, op1);
+  // Create a trio with the relation set between op0 and op2 for folding.
+  // TRIOS are lhs-op0, lhs-op1, op0-op1 relations.
+  relation_trio trio (VREL_VARYING, VREL_VARYING, rel);
+
   tree type = TREE_TYPE (op0);
   int_range<1> res;
   range_op_handler handler (code);
-  if (handler && handler.fold_range (res, type, r0, r1))
+  if (handler && handler.fold_range (res, type, r0, r1, trio))
 {
   if (res == range_true (type))
return boolean_true_node;

This should do what you want I think...   fold_range should use the relation
passed in to determine that the condition is always true or false.

I have not fully tested this patch, fwiw.

[Bug analyzer/112965] Valgrind error on gcc.dg/analyzer/fd-dup-1.c

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

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

--- Comment #2 from David Malcolm  ---
In c-parser.cc's consider_macro:
1843pretty_printer pp;
1844pp_string (&pp, (const char *) tok.val.str.text);
1845pp_newline (&pp);
1846cpp_push_buffer (parse_in,
1847 (const unsigned char *) pp_formatted_text (&pp),
1848 strlen (pp_formatted_text (&pp)),
1849 0);

(gdb) p pp_formatted_text (&pp)
$10 = 0x5782360 "3\n"

(gdb) p (size_t)strlen(pp_formatted_text (&pp))
$11 = 2

So we have an aligned buffer, but it's only 2 bytes long aka 3 bytes in size
i.e.:
  ['3', '\n', '\0']

Looking at lex.cc's search_line_sse42:

424   uintptr_t si = (uintptr_t)s;
425   uintptr_t index;
426 
427   /* Check for unaligned input.  */
428   if (si & 15)
429 {
430   v16qi sv;
431 
432   if (__builtin_expect (end - s < 16, 0)
433   && __builtin_expect ((si & 0xfff) > 0xff0, 0))
434 {
435   /* There are less than 16 bytes left in the buffer, and less
436  than 16 bytes left on the page.  Reading 16 bytes at this
437  point might generate a spurious page fault.  Defer to the
438  SSE2 implementation, which already handles alignment.  */
439   return search_line_sse2 (s, end);
440 }

we skip the block starting at line 429, since it's aligned:

(gdb) p ((uintptr_t)s) & 15
$14 = 0

but the length is so short that we presumably don't want to read 16 bytes at a
time:

(gdb) p end - s
$15 = 2

Not sure if this is a false positive, or a bug in search_line_sse42 when
dealing with very short aligned buffers.

[Bug target/112989] GC ICE with C++, `#include ` and `-fsanitize=address`

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

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

--- Comment #4 from Andrew Pinski  ---
```
simulate_builtin_function_decl (location=255050, name=0x48b5200
"svmla_za64_vg4x1", type=0xf6b1cb70, function_code=31409, library_name=0x0,
attrs=0xf6bced80) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/langhooks.cc:781
781   if (TREE_CODE (new_decl) == FUNCTION_DECL
(gdb)
782   && fndecl_built_in_p (new_decl, function_code, BUILT_IN_MD))
(gdb)
781   if (TREE_CODE (new_decl) == FUNCTION_DECL
(gdb)
785   return decl;
(gdb) p debug_tree(new_decl)
 >
SI
size 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality
attributes >
value >>
chain 
value >>
value >>>
arg-types 
chain 
chain 
chain >
nothrow public external built-in DI t.cc:1:21
align:32 warn_if_not_align:0 built-in: BUILT_IN_MD:31385 context

attributes >
chain >>>
full-name "void svmla_za64_vg4x1(unsigned int, svint16_t, svint16_t)" chain
>
$2 = void
(gdb) p function_code
$3 = 31409
```


There seems like there are 2 builtins for svmla_za64_vg4x1 

[Bug analyzer/112965] Valgrind error on gcc.dg/analyzer/fd-dup-1.c

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

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

--- Comment #3 from David Malcolm  ---
A workaround might be to pad pp's buffer with trailing zero bytes up to a
multiple of 16.