[Bug tree-optimization/51049] A regression caused by "Improve handling of conditional-branches on targets with high branch costs"

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

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

--- Comment #2 from Andrew Pinski  ---
So at -O1 we get what we expect:
```
  _1 = *i_4(D);
  _7 = j_5(D) != 2;
  _8 = _1 != 0;
  _9 = _7 & _8;
  if (_9 != 0)
goto ; [43.56%]
  else
goto ; [56.44%]

   [local count: 467721933]:
  _6 = (int) _1;

   [local count: 1073741824]:
  # _2 = PHI <_6(3), j_5(D)(2)>
```
But at -O2 we get:
```
  if (_1 != 0)
goto ; [66.00%]
  else
goto ; [34.00%]

   [local count: 708669599]:
  if (j_5(D) != 2)
goto ; [66.00%]
  else
goto ; [34.00%]

   [local count: 467721933]:
  _6 = (int) _1;

   [local count: 1073741824]:
  # _2 = PHI <_6(4), j_5(D)(3), j_5(D)(2)>
```

Because VRP comes along and replaces j_5(D) with 2 along the edge `3->5` and
ifcombine does not do handle that as the phi entries are different (but maybe
can be proved as the same).

[Bug tree-optimization/110875] [14 Regression] Dead Code Elimination Regression since r14-2501-g285c9d042e9

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Confirmed. Though I have no idea how to fix this really.
The first major change to the IR happens in thread2 where we decide to do a
jump thread with the change that we didn't do before.

In GCC 13 we had:
```
   [local count: 282631250]:
  # a.8_39 = PHI <_12(23), 0(3)>
  # f_lsm.17_20 = PHI 
  # f_lsm_flag.18_22 = PHI 
  # b_lsm.19_45 = PHI <0(23), b_lsm.19_53(3)>
  # b_lsm_flag.20_47 = PHI <1(23), 0(3)>
  # a_lsm.21_49 = PHI <_12(23), _55(D)(3)>
  _1 = a.8_39 != 0;
  _2 = (int) _1;
  if (_2 != a.8_39)
goto ; [41.79%]
```

On the trunk we get:
```
   [local count: 339987332]:
  # a.8_38 = PHI <_10(24), 0(3)>
  # f_lsm.17_18 = PHI 
  # f_lsm_flag.18_20 = PHI 
  # b_lsm.19_44 = PHI <0(24), b_lsm.19_52(3)>
  # b_lsm_flag.20_46 = PHI <1(24), 0(3)>
  # a_lsm.21_48 = PHI <_10(24), _54(D)(3)>
  _13 = (unsigned int) a.8_38;
  if (_13 > 1)
goto ; [34.74%]
  else
goto ; [65.26%]
```
We duplicate bb4 for bb3 as we can figure that _13>1 will be false. This was
not done for the IR in GCC 13.

I am super confused about VRP's ranges:
We have the following that ranges that get exported and their relationships:
Global Exported: a.8_105 = [irange] int [-2, 0]
  _10 = a.8_105 + -1;
Global Exported: _10 = [irange] int [-INF, -6][-3, -1][1, 2147483645]
  _103 = (unsigned int) _10;
Global Exported: _103 = [irange] unsigned int [1, 2147483645][2147483648,
4294967290][4294967294, +INF]
Simplified relational if (_103 > 1)
 into if (_103 != 1)


Shouldn't the range of _10 just be [-3,-1] 
If so _103 can't get 0 or 1 ? And then if that gets it right then the call to
foo will go away.

[Bug tree-optimization/110873] [14 Regression] Dead Code Elimination Regression at -O2 since r14-376-g47a76439911

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

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

--- Comment #2 from Andrew Pinski  ---
Note there are other missed optimizations later on too even in GCC 13.

[Bug tree-optimization/110875] [14 Regression] Dead Code Elimination Regression since r14-2501-g285c9d042e9

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |14.0

[Bug tree-optimization/110873] [14 Regression] Dead Code Elimination Regression at -O2 since r14-376-g47a76439911

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
GCC 13 had:
```
 Registering value_relation (h_29 == h_13) (bb10) at h_29 = PHI 
   Loops range found for h_29: [irange] unsigned char [5, 5] NONZERO 0x5 and
calculated range :[irange] unsigned char [0, 5] NONZERO 0x7
Global Exported: h_29 = [irange] unsigned char [5, 5] NONZERO 0x5
Folding PHI node: h_29 = PHI 
Queued PHI for removal.  Folds to: 5
Folding statement: if (h_29 <= 4)
gimple_simplified to if (0 != 0)
gimple_simplified to if (0 != 0)
Folded into: if (0 != 0)
``
While trunk does:
```
redicate evaluates to: DON'T KNOW
Not folded
 Registering value_relation (h_29 == h_13) (bb10) at h_29 = PHI 
Global Exported: h_29 = [irange] unsigned char [0, 5] MASK 0xfe VALUE 0xe7
Folding PHI node: h_29 = PHI 
No folding possible
Folding statement: if (h_29 <= 4)

Visiting conditional with predicate: if (h_29 <= 4)

With known ranges
h_29: [irange] unsigned char [0, 5] MASK 0xfe VALUE 0xe7

Predicate evaluates to: DON'T KNOW
Simplified relational if (h_29 <= 4)
 into if (h_29 != 5)

Folded into: if (h_29 != 5)
```
Which totally misses that h_29 was just 5.

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-August/
   ||626131.html
   Keywords||patch

--- Comment #11 from Andrew Pinski  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626131.html

[Bug gcov-profile/110883] internal compiler error: in ipa_profile_write_edge_summary

[hndxvon at 163 dot com via Gcc-bugs]

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

--- Comment #2 from 海山  ---
(In reply to Andrew Pinski from comment #1)
> autofdo is not well supported and fixes for it only made it into GCC 12 and
> not GCC 10.x.
> 
> Please try GCC 12.x or newer and report back.
> 
> Also since you are using a redhat supplied GCC, you should have reported it
> to them as mentioned in the message that outputs:
> 
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.

thank you.
could you list the modifying files for autofdo, not only ipa-profile.cc?

[Bug testsuite/110858] [14 Regression] gcc.dg/unroll-1.c UNRESOLVED

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Fixed by r14-2922-gb278d3080ef23835438ec625b984 .

[Bug gcov-profile/110883] internal compiler error: in ipa_profile_write_edge_summary

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=71672
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2023-08-03

--- Comment #1 from Andrew Pinski  ---
autofdo is not well supported and fixes for it only made it into GCC 12 and not
GCC 10.x.

Please try GCC 12.x or newer and report back.

Also since you are using a redhat supplied GCC, you should have reported it to
them as mentioned in the message that outputs:

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug other/110883] New: internal compiler error: in ipa_profile_write_edge_summary

[hndxvon at 163 dot com via Gcc-bugs]

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

Bug ID: 110883
   Summary: internal compiler error: in
ipa_profile_write_edge_summary
   Product: gcc
   Version: og10 (devel/omp/gcc-10)
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hndxvon at 163 dot com
  Target Milestone: ---

Hi,
gcc-10.2.1 compiles mysql with autofdo and lto optimization, then it reports
"internal compiler error: in ipa_profile_write_edge_summary, at
ipa-profile.c:355
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
"
cflags  '-fauto-profile=myfbdata.gcov -flto', but I try to compile
incrementally times, it maybe success.

$gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --disable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --without-isl --enable-gnu-indirect-function
--enable-cet --with-tune=generic --with-arch_32=x86-64
--build=x86_64-redhat-linux
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.1 20200825 (Redhat 10.2.1-3 2.17) (GCC)

moreover, gcc-9.2.1 build successful one time.

[Bug sanitizer/110876] AddressSanitizer: false positive bad-free

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

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

--- Comment #3 from Andrew Pinski  ---
I looked into the code and I think this is a boost issue, it is specifically
catching the abort signal and recovering and then exit is called and messes up.

[Bug sanitizer/110876] AddressSanitizer: false positive bad-free

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

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

--- Comment #2 from Andrew Pinski  ---
clang trunk has the same failure.
clang 11.0.0 has the same failure.
clang 10.0.0 references https://github.com/google/sanitizers/issues/189 .

I am thinking this is boost issue because both clang and GCC producing the
error.

[Bug analyzer/110882] ICE with -fanalyzer on zero-sized array

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #2 from David Malcolm  ---
Reduced from downstream bug:
https://bugzilla.redhat.com/show_bug.cgi?id=2228600

[Bug analyzer/110882] ICE with -fanalyzer on zero-sized array

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

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

--- Comment #1 from David Malcolm  ---
It's failing this assertion:

#1  0x016e2295 in ana::binding_key::make (mgr=0x7fff91d8,
r=0x3275340) at ../../src/gcc/analyzer/store.cc:132
132   gcc_assert (bit_size > 0);
(gdb) list
127 {
128   bit_size_t bit_size;
129   if (r->get_bit_size (_size))
130 {
131   /* Must be non-empty.  */
132   gcc_assert (bit_size > 0);
133   return mgr->get_concrete_binding (offset.get_bit_offset (),
134 bit_size);
135 }
136   else

[Bug analyzer/110882] New: ICE with -fanalyzer on zero-sized array

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

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

Bug ID: 110882
   Summary: ICE with -fanalyzer on zero-sized array
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

ICE seen with -fanalyzer on this code:

-

struct csv_row {
  char *columns[0];
};

void
parse_csv_line(int n_columns,
   const char *columns[])
{
  for (int n = 0; n < n_columns; n++) {
  columns[n] = ((void *)0);
  }
}

void parse_csv_data(int n_columns,
struct csv_row *entry)
{
  parse_csv_line(n_columns, (const char **)entry->columns);
}

-

ICE happens on gcc 13 onwards; specifically, affects:
- trunk: https://godbolt.org/z/To7c1r8ME
- gcc 13.2: https://godbolt.org/z/a5zr5Ga4b

gcc 12.3 is not affected

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

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

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

--- Comment #10 from Andrew Pinski  ---
I am not happy with the patch I came up with but it does reduce the amount of
iterating and 100% makes sure it is bound so it will work.

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

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

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

--- Comment #9 from Andrew Pinski  ---
(gdb) p debug_tree(expr1)
 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type
0x778215e8 precision:32 min  max

pointer_to_this >
visited
def_stmt g_227.1_3 = (int) g_227_8;
version:3>
$3 = void
(gdb) up -1
#0  gimple_bitwise_inverted_equal_p (expr1=0x779db048,
expr2=0x779db3a8, valueize=0x11ba180 ) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-match-head.cc:278
278   if (expr1 == expr2)
(gdb) p debug_tree(expr1)
 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x77821690 precision:32 min  max 
pointer_to_this >
visited
def_stmt g_161.3_5 = (unsigned int) g_161.2_4;
version:5>
$4 = void



Value numbering stmt = g_161.2_4 = g_161;
Setting value number of g_161.2_4 to g_227.1_3 (changed)
g_227.1_3 is available for g_227.1_3
Value numbering stmt = g_161.3_5 = (unsigned int) g_161.2_4;
g_227.1_3 is available for g_227.1_3
Applying pattern match.pd:4207, gimple-match-4.cc:4064
Applying pattern match.pd:4299, gimple-match-4.cc:4122
Match-and-simplified (unsigned int) g_161.2_4 to g_227_8
RHS (unsigned int) g_161.2_4 simplified to g_227_8
Setting value number of g_161.3_5 to g_227_15 (changed)
Making available beyond BB6 g_161.3_5 for value g_227_15
Value numbering stmt = _6 = g_161.3_5 & t_17(D);



So when we go and handle gimple_nop_convert here and we loop between the two.
So we just need to limit gimple_bitwise_inverted_equal_p to only one look
through I think ...

[Bug analyzer/107646] RFE: can we reimplement gcc-python-plugin's cpychecker as a -fanalyzer plugin?

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

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

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

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

commit r14-2933-gfafe2d18f791c6b97b49af7c84b1b5703681c3af
Author: Eric Feng 
Date:   Wed Aug 2 16:54:55 2023 -0400

analyzer: stash values for CPython plugin [PR107646]

This patch adds a hook to the end of ana::on_finish_translation_unit
which calls relevant stashing-related callbacks registered during plugin
initialization. This feature is used to stash named types and global
variables for a CPython analyzer plugin [PR107646].

gcc/analyzer/ChangeLog:
PR analyzer/107646
* analyzer-language.cc (run_callbacks): New function.
(on_finish_translation_unit): New function.
* analyzer-language.h (GCC_ANALYZER_LANGUAGE_H): New include.
(class translation_unit): New vfuncs.

gcc/c/ChangeLog:
PR analyzer/107646
* c-parser.cc: New functions on stashing values for the
analyzer.

gcc/testsuite/ChangeLog:
PR analyzer/107646
* gcc.dg/plugin/plugin.exp: Add new plugin and test.
* gcc.dg/plugin/analyzer_cpython_plugin.c: New plugin.
* gcc.dg/plugin/cpython-plugin-test-1.c: New test.

Signed-off-by: Eric Feng 

[Bug target/109977] [14 Regression] ICE: output_operand: incompatible floating point / vector register operand for '%d' at -Og

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||slyfox at gcc dot gnu.org

--- Comment #3 from Andrew Pinski  ---
*** Bug 110880 has been marked as a duplicate of this bug. ***

[Bug target/110880] [14 Regression] aarch64 ICE on highway-1.0.5: internal compiler error: output_operand: incompatible floating point / vector register operand for '%s'

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Yes it is a dup of bug 109977:
(insn:TI 14 11 21 (set (mem/c:V2SF (plus:DI (reg/f:DI 31 sp)
(const_int 24 [0x18])) [1 __trans_tmp_1.raw_+0 S8 A64])
(vec_duplicate:V2SF (reg:SF 2 x2 [orig:94 _7 ] [94])))
"/app/example.cpp":18:29 1391 {aarch64_simd_stpv2sf}
 (nil))

Here we have V2SF and in that one we had V2DF but the problem is the same. The
use of the `vw` iterator in this pattern.

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

[Bug target/110880] [14 Regression] aarch64 ICE on highway-1.0.5: internal compiler error: output_operand: incompatible floating point / vector register operand for '%s'

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

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

--- Comment #2 from Andrew Pinski  ---
Yes it is a dup of bug 109977:
(insn:TI 14 11 21 (set (mem/c:V2SF (plus:DI (reg/f:DI 31 sp)
(const_int 24 [0x18])) [1 __trans_tmp_1.raw_+0 S8 A64])
(vec_duplicate:V2SF (reg:SF 2 x2 [orig:94 _7 ] [94])))
"/app/example.cpp":18:29 1391 {aarch64_simd_stpv2sf}
 (nil))

Here we have V2SF and in that one we had V2DF but the problem is the same. The
use of the `vw` iterator in this pattern.

[Bug c++/110881] New: Feature request: an attribute for enum members that would skip the -Wswitch-enum warning

[valentyn.pavliuchenko at gmail dot com via Gcc-bugs]

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

Bug ID: 110881
   Summary: Feature request: an attribute for enum members that
would skip the -Wswitch-enum warning
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: valentyn.pavliuchenko at gmail dot com
  Target Milestone: ---

Sometimes enum members are added only for static_assert() checks, but not for
actual use. The problem is that it triggers the -Wswitch-enum warning if these
members are not explicitly specified in a switch() statement.

The request is to add an attribute like [[unused]] for such enum members that
would not cause a -Wswitch-enum warning when the member is omitted in a
switch().

Example case that demonstrates the problem:

// build with -Wall
#include 

enum MyEnum
{
eMyEnum_One,
eMyEnum_Two,
eMyEnum_Three,
eMyEnum_Four,

eMyEnum_Count, // not a real enum value, but rather a marker for
static_assert() statements like in the bar() function below
};

void doEven();

void bar(MyEnum inValue)
{
static_assert(eMyEnum_Count == 4, "review the code below"); // would
trigger if new members are added to the enum
if (inValue == eMyEnum_Two || inValue == eMyEnum_Four)
doEven();
}

void foo(MyEnum inValue)
{
switch (inValue) // warning: enumeration value 'eMyEnum_Count' not handled
in switch [-Wswitch]
{
case eMyEnum_One: std::cout << "1\n";
case eMyEnum_Two: std::cout << "2\n";
case eMyEnum_Three: std::cout << "3\n";
case eMyEnum_Four: std::cout << "4\n";
}
}

Possible code after a fix:


enum MyEnum
{
eMyEnum_One,
eMyEnum_Two,
eMyEnum_Three,
eMyEnum_Four,

[[unused]]eMyEnum_Count,
};

[Bug target/110880] [14 Regression] aarch64 ICE on highway-1.0.5: internal compiler error: output_operand: incompatible floating point / vector register operand for '%s'

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

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

--- Comment #1 from Sergei Trofimovich  ---
Compiler details:

$ aarch64-unknown-linux-gnu-g++ -v

Using built-in specs.
COLLECT_GCC=/<>/aarch64-unknown-linux-gnu-stage-final-gcc-14.0.0/bin/aarch64-unknown-linux-gnu-g++
COLLECT_LTO_WRAPPER=/<>/aarch64-unknown-linux-gnu-stage-final-gcc-14.0.0/libexec/gcc/aarch64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: ../source/configure
--prefix=/<>/aarch64-unknown-linux-gnu-stage-final-gcc-14.0.0
--with-gmp-include=/<>/gmp-with-cxx-6.2.1-dev/include
--with-gmp-lib=/<>/gmp-with-cxx-6.2.1/lib
--with-mpfr-include=/<>/mpfr-4.2.0-dev/include
--with-mpfr-lib=/<>/mpfr-4.2.0/lib --with-mpc=/<>/libmpc-1.3.1
--with-native-system-header-dir=/<>/glibc-aarch64-unknown-linux-gnu-2.38-dev/include
--with-build-sysroot=/ --program-prefix=aarch64-unknown-linux-gnu- --enable-lto
--disable-libstdcxx-pch --without-included-gettext --with-system-zlib
--enable-checking=release --enable-static --enable-languages=c,c++
--disable-multilib --enable-plugin --with-isl=/<>/isl-0.20
--with-arch=armv8-a
--with-as=/<>/aarch64-unknown-linux-gnu-binutils-wrapper-2.41/bin/aarch64-unknown-linux-gnu-as
--with-ld=/<>/aarch64-unknown-linux-gnu-binutils-wrapper-2.41/bin/aarch64-unknown-linux-gnu-ld
--with-headers=/<>/glibc-aarch64-unknown-linux-gnu-2.38-dev/include
--enable-__cxa_atexit --enable-long-long --enable-threads=posix --enable-nls
--disable-bootstrap --build=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --target=aarch64-unknown-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0  (experimental) (GCC)

[Bug target/110880] New: [14 Regression] aarch64 ICE on highway-1.0.5: internal compiler error: output_operand: incompatible floating point / vector register operand for '%s'

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

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

Bug ID: 110880
   Summary: [14 Regression] aarch64 ICE on highway-1.0.5: internal
compiler error: output_operand: incompatible floating
point / vector register operand for '%s'
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Don't know if a duplicate of PR109977 or not. FIling just in case. Initially
observed ICE on `highway-1.0.5` against gcc r14-2930-g0460c122162793.

Extracted small example as:

// $ cat math_test.cc.cc
void CopyBytes(bool *from, float *to) { __builtin_memcpy(to, from, 4); }
int TestMath_d;
typedef __Float32x2_t float32x2_t;
struct Vec128 {
  Vec128(float32x2_t raw) : raw_(raw) {}
  float32x2_t raw_;
};
Vec128 NativeSet(float t) {
  float32x2_t __trans_tmp_2{t, t};
  return __trans_tmp_2;
}
Vec128 Set(float t) { return NativeSet(t); }
float BitCast_out;
bool TestMath_in[4];
void TestMath(int fxN(int, Vec128 &)) {
  CopyBytes(TestMath_in, _out);
  Vec128 __trans_tmp_1 = Set(BitCast_out);
  fxN(TestMath_d, __trans_tmp_1);
}

$
aarch64-unknown-linux-gnu-stage-final-gcc-wrapper-14.0.0/bin/aarch64-unknown-linux-gnu-g++
-O2  -c math_test.cc.cc -o bug.o -O1

during RTL pass: final
math_test.cc.cc: In function 'void TestMath(int (*)(int, Vec128&))':
math_test.cc.cc:19:1: internal compiler error: output_operand: incompatible
floating point / vector register operand for '%s'
   19 | }
  | ^
0x1c13274 diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char
const*, __va_list_tag (*) [1], diagnostic_t)
???:0
0x1c137e7 internal_error(char const*, ...)
???:0
0xb8b410 output_operand_lossage(char const*, ...)
???:0
0xb8b5d1 output_operand(rtx_def*, int)
???:0
0xb8c23d output_asm_insn(char const*, rtx_def**) [clone .part.0]
???:0
0xb8d564 final_scan_insn_1(rtx_insn*, _IO_FILE*, int, int, int*) [clone
.isra.0]
???:0
0xb8d99b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
???:0
0xb8dc37 final_1(rtx_insn*, _IO_FILE*, int, int)
???:0
0xb8e496 (anonymous namespace)::pass_final::execute(function*)
???:0

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

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

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

--- Comment #8 from Andrew Pinski  ---
Oh the difference between -O1 and -O2 is due to in fre:
  /* At -O[1g] use the cheap non-iterating mode.  */
  bool iterate_p = may_iterate && (optimize > 1);

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to David Binderman from comment #6)
> (In reply to Andrew Pinski from comment #4)
> > There is a stack overflow while executing the FRE pass.
> 
> I can confirm over 100,000 stack frames.
> 
> Which -f flag causes the FRE pass to be executed ?
> I assume it is in -O2, but not in -O1.

Fre is enabled at -O1 but the IR changes before fre. I have not looked into
what changes to the IR on why there is a difference between -O1 and -O2 yet.

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from David Binderman  ---
(In reply to Andrew Pinski from comment #4)
> There is a stack overflow while executing the FRE pass.

I can confirm over 100,000 stack frames.

Which -f flag causes the FRE pass to be executed ?
I assume it is in -O2, but not in -O1.

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from David Binderman  ---
Created attachment 55679
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55679=edit
C source code

Another test case.

[Bug c/110878] -Wstringop-overflow incorrectly warns about arguments to functions with static array parameter declarations

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Taylor R Campbell from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > This is basically a dup of bug 108154 I think.
> 
> That one appears to be different: it trips -Wstringop-overread, not
> -Wstringop-overflow.

The infrastructure for both are the same for this static array parameters
though. So 

[Bug c/110878] -Wstringop-overflow incorrectly warns about arguments to functions with static array parameter declarations

[campbell+gcc-bugzilla at mumble dot net via Gcc-bugs]

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

--- Comment #3 from Taylor R Campbell  
---
(In reply to Andrew Pinski from comment #1)
> There is another bug report dealing with this. But IIRC this is an expected
> warning as foo is being passed an array which is size 16 but then passed to
> bar as size 128 which would be undefined.

There is nothing undefined here.

The caller's requirement as noted in the comment (which is not formally
expressible in C, as far as I know, but is obviously extremely
widespread practice) is that for foo(p, n) or bar(p, n), p must point
to the first element of an array of at least n elements.

foo additionally imposes the requirement that p have at least 16
elements.  bar additionally imposes the requirement that p have at
least 128 elements.

When the caller meets foo's contract, foo meets bar's contract.  So
there is nothing undefined.

>From C11, Sec. 6.7.6.3 `Function declarators (including prototypes)',
paragraph 7, p. 133:

> A declaration of a parameter as ``array of type'' shall be adjusted
> to ``qualified pointer to type'', where the type qualifiers (if any)
> are those specified within the [ and ] of the array type derivation.
> If the keyword static also appears within the [ and ] of the array
> type derivation, then for each call to the function, the value of the
> corresponding actual argument shall provide access to the first
> element of an array with at least as many elements as specified by
> the size expression.

Here, as required, the value of the corresponding actual argument does
provide access to the first element of an array with at least as many
elements as specified by the size expression.

In other words, this states a requirement about run-time values, which
the code meets, not about compile-time parameter declarations, which is
what GCC appears to object to.

(In reply to Andrew Pinski from comment #2)
> This is basically a dup of bug 108154 I think.

That one appears to be different: it trips -Wstringop-overread, not
-Wstringop-overflow.

[Bug rtl-optimization/110867] [14 Regression] ICE in combine after 7cdd0860949c6c3232e6cff1d7ca37bb5234074c

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Stefan Schulze Frielinghaus
:

https://gcc.gnu.org/g:41ef5a34161356817807be3a2e51fbdbe575ae85

commit r14-2932-g41ef5a34161356817807be3a2e51fbdbe575ae85
Author: Stefan Schulze Frielinghaus 
Date:   Wed Aug 2 21:43:22 2023 +0200

rtl-optimization/110867 Fix narrow comparison of memory and constant

In certain cases a constant may not fit into the mode used to perform a
comparison.  This may be the case for sign-extended constants which are
used during an unsigned comparison as e.g. in

(set (reg:CC 100 cc)
(compare:CC (mem:SI (reg/v/f:SI 115 [ a ]) [1 *a_4(D)+0 S4 A64])
(const_int -2147483648 [0x8000])))

Fixed by ensuring that the constant fits into comparison mode.

Furthermore, on some targets as e.g. sparc the constant used in a
comparison is chopped off before combine which leads to failing test
cases (see PR 110869).  Fixed by not requiring that the source mode has
to be DImode, and excluding sparc from the last two test cases entirely
since there the constant cannot be further reduced.

gcc/ChangeLog:

PR rtl-optimization/110867
* combine.cc (simplify_compare_const): Try the optimization only
in case the constant fits into the comparison mode.

gcc/testsuite/ChangeLog:

PR rtl-optimization/110869
* gcc.dg/cmp-mem-const-1.c: Relax mode for constant.
* gcc.dg/cmp-mem-const-2.c: Relax mode for constant.
* gcc.dg/cmp-mem-const-3.c: Relax mode for constant.
* gcc.dg/cmp-mem-const-4.c: Relax mode for constant.
* gcc.dg/cmp-mem-const-5.c: Exclude sparc since here the
constant is already reduced.
* gcc.dg/cmp-mem-const-6.c: Exclude sparc since here the
constant is already reduced.

[Bug middle-end/110869] [14 regression] ICE in decompose, at rtl.h:2297

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Stefan Schulze Frielinghaus
:

https://gcc.gnu.org/g:41ef5a34161356817807be3a2e51fbdbe575ae85

commit r14-2932-g41ef5a34161356817807be3a2e51fbdbe575ae85
Author: Stefan Schulze Frielinghaus 
Date:   Wed Aug 2 21:43:22 2023 +0200

rtl-optimization/110867 Fix narrow comparison of memory and constant

In certain cases a constant may not fit into the mode used to perform a
comparison.  This may be the case for sign-extended constants which are
used during an unsigned comparison as e.g. in

(set (reg:CC 100 cc)
(compare:CC (mem:SI (reg/v/f:SI 115 [ a ]) [1 *a_4(D)+0 S4 A64])
(const_int -2147483648 [0x8000])))

Fixed by ensuring that the constant fits into comparison mode.

Furthermore, on some targets as e.g. sparc the constant used in a
comparison is chopped off before combine which leads to failing test
cases (see PR 110869).  Fixed by not requiring that the source mode has
to be DImode, and excluding sparc from the last two test cases entirely
since there the constant cannot be further reduced.

gcc/ChangeLog:

PR rtl-optimization/110867
* combine.cc (simplify_compare_const): Try the optimization only
in case the constant fits into the comparison mode.

gcc/testsuite/ChangeLog:

PR rtl-optimization/110869
* gcc.dg/cmp-mem-const-1.c: Relax mode for constant.
* gcc.dg/cmp-mem-const-2.c: Relax mode for constant.
* gcc.dg/cmp-mem-const-3.c: Relax mode for constant.
* gcc.dg/cmp-mem-const-4.c: Relax mode for constant.
* gcc.dg/cmp-mem-const-5.c: Exclude sparc since here the
constant is already reduced.
* gcc.dg/cmp-mem-const-6.c: Exclude sparc since here the
constant is already reduced.

[Bug c/110878] -Wstringop-overflow incorrectly warns about arguments to functions with static array parameter declarations

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||108154

--- Comment #2 from Andrew Pinski  ---
This is basically a dup of bug 108154 I think.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108154
[Bug 108154] Inappropriate -Wstringop-overread in the C99 [static n] func param
decl

[Bug c/110878] -Wstringop-overflow incorrectly warns about arguments to functions with static array parameter declarations

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

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

--- Comment #1 from Andrew Pinski  ---
There is another bug report dealing with this. But IIRC this is an expected
warning as foo is being passed an array which is size 16 but then passed to bar
as size 128 which would be undefined.

[Bug c++/110879] New: Unnecessary reread from memory in a loop

[palevichva at gmail dot com via Gcc-bugs]

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

Bug ID: 110879
   Summary: Unnecessary reread from memory in a loop
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: palevichva at gmail dot com
  Target Milestone: ---

Created attachment 55678
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55678=edit
preprocessed file by g++ from revision dd2eb972a

I've found a strange regression in optimization. Trunk version of g++ produces
less optimal assembly. It rereads same memory location in every iteration of a
loop. More specifically, it rereads fields _M_finish and _M_end_of_storage of a
vector from memory every push_back call, although it is not necessary.
Released version 13.2 doesn't do that, and just uses values from registers.

I'm compiling following code:

#include 

std::vector f(std::size_t n) {
std::vector res;
res.reserve(n);
for (std::size_t i = 0; i < n; ++i) {
res.push_back(i*i);
}
return res;
}

The main body of a loop looks like this:
~/.local/gcc/bin/g++ -S -fverbose-asm -O3 -std=c++20 pb.cpp

>.L41:
># /home/scaiper/.local/gcc/include/c++/14.0.0/bits/stl_construct.h:97: { 
>return ::new((void*)__location) _Tp(std::forward<_Args>(__args)...); }
>movl%r15d, (%rbx)   # _3, *prephitmp_51
># /home/scaiper/.local/gcc/include/c++/14.0.0/bits/vector.tcc:119:  
>++this->_M_impl._M_finish;
>addq$4, %rbx#, tmp135
>movq%rbx, 8(%rbp)   # tmp135, 
> res_8(D)->D.35756._M_impl.D.35067._M_finish
>.L8:
># pb.cpp:6: for (std::size_t i = 0; i < n; ++i) {
>addq$1, %r13#, i
># pb.cpp:6: for (std::size_t i = 0; i < n; ++i) {
>cmpq%r13, %r12  # i, n
>je  .L1 #,
># /home/scaiper/.local/gcc/include/c++/14.0.0/bits/vector.tcc:114:  if 
>(this->_M_impl._M_finish != this->_M_impl._M_end_of_storage)
>movq8(%rbp), %rbx   # res_8(D)->D.35756._M_impl.D.35067._M_finish, 
> prephitmp_51
># /home/scaiper/.local/gcc/include/c++/14.0.0/bits/vector.tcc:114:  if 
>(this->_M_impl._M_finish != this->_M_impl._M_end_of_storage)
>movq16(%rbp), %rax  # 
> res_8(D)->D.35756._M_impl.D.35067._M_end_of_storage, pretmp_52
>.L16:
># pb.cpp:7: res.push_back(i*i);
>movl%r13d, %r15d# i, _3
>imull   %r13d, %r15d# i, _3
># /home/scaiper/.local/gcc/include/c++/14.0.0/bits/vector.tcc:114:  if 
>(this->_M_impl._M_finish != this->_M_impl._M_end_of_storage)
>cmpq%rax, %rbx  # pretmp_52, prephitmp_51
>jne .L41#,

Same loop as produced by 13.2:
~/.local/gcc-13.2/bin/g++ -v -S -fverbose-asm -O3 -std=c++20 pb.cpp

>.L43:
># /home/scaiper/.local/gcc-13.2/include/c++/13.2.0/bits/stl_construct.h:97:
> { return ::new((void*)__location) _Tp(std::forward<_Args>(__args)...); }
>movl%r12d, (%rcx)   # _3, *prephitmp_4
># /home/scaiper/.local/gcc-13.2/include/c++/13.2.0/bits/vector.tcc:119:
> ++this->_M_impl._M_finish;
>addq$4, %rcx#, prephitmp_4
>movq%rcx, 8(%rbp)   # prephitmp_4, 
> res_8(D)->D.35699._M_impl.D.35010._M_finish
>.L8:
># pb.cpp:6: for (std::size_t i = 0; i < n; ++i) {
>addq$1, %rbx#, i
># pb.cpp:6: for (std::size_t i = 0; i < n; ++i) {
>cmpq%rbx, %r13  # i, n
>je  .L1 #,
>.L18:
># pb.cpp:7: res.push_back(i*i);
>movl%ebx, %r12d # i, _3
>imull   %ebx, %r12d # i, _3
># /home/scaiper/.local/gcc-13.2/include/c++/13.2.0/bits/vector.tcc:114:
> if (this->_M_impl._M_finish != this->_M_impl._M_end_of_storage)
>cmpq%r8, %rcx   # prephitmp_74, prephitmp_4
>jne .L43#,

Notice this extra commands in the first snippet:
movq8(%rbp), %rbx
movq16(%rbp), %rax

I've bisected this problem to the commit dd2eb972a (libstdc++: Use RAII in
std::vector::_M_realloc_insert)
(https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=dd2eb972a5b063e10c83878d5c9336a818fa8291).
It doesn't look like commit is the problem. Code looks pretty equivalent. But
for some reason compiler produces different result.

I'm using version built from aforementioned commit dd2eb972a:
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c++ --disable-multilib
--prefix=/home/scaiper/.local/gcc
gcc version 14.0.0 20230623 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-S' '-fverbose-asm' '-O3' '-std=c++20'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'

Comparing with 13.2:
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c++ --disable-multilib
--prefix=/home/scaiper/.local/gcc-13.2
gcc version 13.2.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-S' '-fverbose-asm' '-O3' '-std=c++20'
'-shared-libgcc' '-mtune=generic' 

[Bug c/110878] New: -Wstringop-overread incorrectly warns about arguments to functions with static array parameter declarations

[campbell+gcc-bugzilla at mumble dot net via Gcc-bugs]

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

Bug ID: 110878
   Summary: -Wstringop-overread incorrectly warns about arguments
to functions with static array parameter declarations
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: campbell+gcc-bugzilla at mumble dot net
  Target Milestone: ---

Isolated from code passing a pointer into an array and the length of the array
as separate arguments, where each function has the minimum length of the array
encoded in its parameter declaration, and uses runtime conditionals to
guarantee the minimum is met:

// bar(p, n) may access p[0], p[1], ..., p[n-1], and requires n >= 128
void bar(unsigned char[static 128], unsigned);

// foo(p, n) may access p[0], p[1], ..., p[n-1], and requires n >= 16
void
foo(unsigned char p[static 16], unsigned n)
{

if (n % 128)
n -= n % 128;
if (n)
bar(p, n);
}

: In function 'foo':
:12:17: error: 'bar' accessing 128 bytes in a region of size 16
[-Werror=stringop-overflow=]
   12 | bar(p, n);
  | ^
:12:17: note: referencing argument 1 of type 'unsigned char[128]'
:2:6: note: in a call to function 'bar'
2 | void bar(unsigned char[static 128], unsigned n);
  |  ^~~
cc1: all warnings being treated as errors
Compiler returned: 1

Reproduced in GCC 10.5, 11.4, and 12.3.  Not reproduced in any earlier versions
of GCC.

Using `if (n >= 128)' doesn't change anything, presumably because GCC doesn't
know the connection between p and n.

[Bug fortran/110877] New: Incorrect copy of allocatable component in polymorphic assignment from array dummy argument

[townsend at astro dot wisc.edu via Gcc-bugs]

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

Bug ID: 110877
   Summary: Incorrect copy of allocatable component in polymorphic
assignment from array dummy argument
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

I've run into a problem that's demonstrated by the following code:

--
module avs_m

   type :: foo_t
   end type foo_t

   type, extends(foo_t) :: bar_t
  real, allocatable :: a
   end type bar_t

end module avs_m

program assign_vs_source

   use avs_m

   implicit none

   class(foo_t), allocatable :: foo(:)

   allocate(bar_t::foo(1))
   select type(foo)
   class is (bar_t)
  allocate(foo(1)%a)
   end select

   call check_assign(foo)

contains

   subroutine check_assign(f)

  class(foo_t), intent(in)  :: f(:)
  class(foo_t), allocatable :: g(:)

  g = f

  select type(g)
  class is (bar_t)
 print *,'is allocated?', allocated(g(1)%a)
  end select

  deallocate(g)
  allocate(g, SOURCE=f)

  select type(g)
  class is (bar_t)
 print *,'is allocated?', allocated(g(1)%a)
  end select

   end subroutine check_assign

end program assign_vs_source
--

Expected output is 

 is allocated? T
 is allocated? T

but instead I get (gfortran 13.1.0, MacOS 13.4 x86_64):

 is allocated? F
 is allocated? T

It seems that the polymorphic assignment g=f is not correctly allocating the %a
component -- but the sourced allocation is. The problem seems to go away if (1)
I use scalars for foo, f and g, or (2) if I move the code from the check_assign
subroutine to the main program.

cheers,

Rich

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

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

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

--- Comment #4 from Andrew Pinski  ---
Reduced testcase:
```
struct S1 {
  unsigned f0;
};
static int g_161;
void func_109(unsigned g_227, unsigned t) {
  struct S1 l_178;
  int l_160 = 0x1FAE99D5L;
  int *l_230[] = {_160};
  if (l_160) {
for (l_178.f0 = -7; l_178.f0;) {
  ++g_227;
  break;
}
(g_161) = g_227;
  }
  (g_161) &= t;
}
```
There is a stack overflow while executing the FRE pass.

[Bug fortran/88286] [OOP] gfortran reports conflicting intent(in) with an intent(in) declared class variable

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #2)
> Appears fixed in 12-branch and later.  Adding known-to work.
> 
> Can we close this one?

I think the answer is "yes".  It comes down to "too many bugs and too few
contributors".  If someone can identify the commit that fixed this bug, then by
all means it can be back-ported.  It's unclear to me if it is worth the effort
to find the commit.

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

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

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

--- Comment #3 from Andrew Pinski  ---
I think this might be the common attribute on an local variable decl that is
causing the issue 

[Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls

[fxue at os dot amperecomputing.com via Gcc-bugs]

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

Feng Xue  changed:

   What|Removed |Added

 CC||fxue at os dot 
amperecomputing.com

--- Comment #9 from Feng Xue  ---
On some occasions, we may not use the new ld, the kernel-building relies on its
own runtime linker which is used for kernel modules. So I created a patch
(https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626084.html), and this
provides user another option that could be done at the compiler side.

[Bug middle-end/110874] [14 Regression] ice with -O2 with recent gcc

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
Version|unknown |14.0
   Target Milestone|--- |14.0
  Component|c   |middle-end
   Keywords||ice-on-valid-code
Summary|ice with -O2 with recent|[14 Regression] ice with
   |gcc |-O2 with recent gcc
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
   Last reconfirmed||2023-08-02

--- Comment #2 from Andrew Pinski  ---
Let me look into it ...

[Bug c/110874] ice with -O2 with recent gcc

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
Stack backtrace seems to be:

#0  0x00a0b511 in operand_compare::verify_hash_value (flags=0, 
this=, arg0=, arg1=, 
ret=) at ../../trunk.year/gcc/fold-const.cc:4074
#1  operand_compare::operand_equal_p (
this=0x2efbbd8 , arg0=0x7fffe9c9fc60, 
arg1=0x7fffe9cc8e10, flags=0) at ../../trunk.year/gcc/fold-const.cc:3090
#2  0x00a04162 in operand_equal_p (arg0=0x7fffe9c9fc60, 
arg1=0x7fffe9cc8e10, flags=16) at ../../trunk.year/gcc/fold-const.cc:4105
#3  0x01dde083 in gimple_bitwise_inverted_equal_p (
expr1=0x7fffe9c9fc60, expr2=expr2@entry=0x7fffe9cc8e10, 
valueize=valueize@entry=0x106ee10 )
at ../../trunk.year/gcc/gimple-match-head.cc:284

Looking for the word "invert" in the range of git hashes gives:

$ grep invert /tmp/0
Slightly improve bitwise_inverted_equal_p comparisons
This slighly improves bitwise_inverted_equal_p
* gimple-match-head.cc (gimple_bitwise_inverted_equal_p): Valueize
Move `~X & X` and `~X | X` over to use bitwise_inverted_equal_p
bitwise_inverted_equal_p. It also allows us to remove 2 other patterns
use bitwise_inverted_equal_p, removing :c as
bitwise_inverted_equal_p
$ 

This is commit:

commit ee20be8325f7f257ba91a0201cfb3bd6bfbceba9
Author: Andrew Pinski 
Date:   Sat Jul 29 16:29:09 2023 -0700

Slightly improve bitwise_inverted_equal_p comparisons

I can't be sure yet, but that commit is a likely candidate.
Perhaps Andrew would be willing to offer their opinion ?

[Bug c++/101027] Short-circuit behavior not respected with co_await in while head

[sichert at in dot tum.de via Gcc-bugs]

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

Moritz Sichert  changed:

   What|Removed |Added

 CC||sichert at in dot tum.de

--- Comment #2 from Moritz Sichert  ---
Created attachment 55677
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55677=edit
Coroutine that segfaults because it does not short-circuit

I have encountered the same problem where co_await in a logical operation does
not short-circuit correctly. See the attached example.

The code segfaults because in the condition "foo && co_await foo->foo(123)" it
starts executing the coroutine even if foo is nullptr. For some reason the
error only occurs if the condition is nested in a logical-|| expression.

[Bug sanitizer/110876] AddressSanitizer: false positive bad-free

[dvirtz at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Dvir Yitzchaki  ---
Created attachment 55676
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55676=edit
preprocessed code

[Bug sanitizer/110876] New: AddressSanitizer: false positive bad-free

[dvirtz at gmail dot com via Gcc-bugs]

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

Bug ID: 110876
   Summary: AddressSanitizer: false positive bad-free
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dvirtz at gmail dot com
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: ---

Using ASAN together with boost::test, where the test calls `std::abort`
produces the false diagonstic

=
==1==ERROR: AddressSanitizer: attempting free on address which was not
malloc()-ed: 0x62502900 in thread T0
#0 0x7f535efcb098 in operator delete[](void*)
(/opt/compiler-explorer/gcc-13.1.0/lib64/libasan.so.8+0xdc098) (BuildId:
c9b24be17e4cbd04bdb4891782c4425e47a9259a)
#1 0x4ef5d8 in void boost::checked_array_delete(char*)
/opt/compiler-explorer/libs/boost_1_82_0/boost/core/checked_delete.hpp:43
#2 0x4c74d9 in boost::scoped_array::~scoped_array()
/opt/compiler-explorer/libs/boost_1_82_0/boost/smart_ptr/scoped_array.hpp:70
#3 0x49b22d in boost::execution_monitor::~execution_monitor()
/opt/compiler-explorer/libs/boost_1_82_0/boost/test/execution_monitor.hpp:317
#4 0x4a9cd1 in
boost::unit_test::unit_test_monitor_t::~unit_test_monitor_t()
/opt/compiler-explorer/libs/boost_1_82_0/boost/test/unit_test_monitor.hpp:52
#5 0x7f535e96a8a6  (/lib/x86_64-linux-gnu/libc.so.6+0x468a6) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#6 0x7f535e96aa5f in exit (/lib/x86_64-linux-gnu/libc.so.6+0x46a5f)
(BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
#7 0x7f535e948089 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24089) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#8 0x407e3d in _start (/app/output.s+0x407e3d) (BuildId:
672eb81700f7ac2665b4ac944a33b70100145f2e)

0x62502900 is located 2048 bytes after 8192-byte region
[0x62500100,0x62502100)
freed by thread T0 here:
#0 0x7f535efcb098 in operator delete[](void*)
(/opt/compiler-explorer/gcc-13.1.0/lib64/libasan.so.8+0xdc098) (BuildId:
c9b24be17e4cbd04bdb4891782c4425e47a9259a)
#1 0x4ef5d8 in void boost::checked_array_delete(char*)
/opt/compiler-explorer/libs/boost_1_82_0/boost/core/checked_delete.hpp:43
#2 0x4c74d9 in boost::scoped_array::~scoped_array()
/opt/compiler-explorer/libs/boost_1_82_0/boost/smart_ptr/scoped_array.hpp:70
#3 0x49b22d in boost::execution_monitor::~execution_monitor()
/opt/compiler-explorer/libs/boost_1_82_0/boost/test/execution_monitor.hpp:317
#4 0x49b5f1 in boost::unit_test::framework::state::~state()
/opt/compiler-explorer/libs/boost_1_82_0/boost/test/impl/framework.ipp:499
#5 0x7f535e96a8a6  (/lib/x86_64-linux-gnu/libc.so.6+0x468a6) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)

previously allocated by thread T0 here:
#0 0x7f535efca688 in operator new[](unsigned long)
(/opt/compiler-explorer/gcc-13.1.0/lib64/libasan.so.8+0xdb688) (BuildId:
c9b24be17e4cbd04bdb4891782c4425e47a9259a)
#1 0x423222 in boost::execution_monitor::catch_signals(boost::function const&)
/opt/compiler-explorer/libs/boost_1_82_0/boost/test/impl/execution_monitor.ipp:891
#2 0x423794 in boost::execution_monitor::execute(boost::function
const&)
/opt/compiler-explorer/libs/boost_1_82_0/boost/test/impl/execution_monitor.ipp:1301
#3 0x4254ab in boost::execution_monitor::vexecute(boost::function
const&)
/opt/compiler-explorer/libs/boost_1_82_0/boost/test/impl/execution_monitor.ipp:1397
#4 0x41ae5f in
boost::unit_test::framework::init(boost::unit_test::test_suite* (*)(int,
char**), int, char**)
/opt/compiler-explorer/libs/boost_1_82_0/boost/test/impl/framework.ipp:1209
#5 0x43eb06 in
boost::unit_test::unit_test_main(boost::unit_test::test_suite* (*)(int,
char**), int, char**)
/opt/compiler-explorer/libs/boost_1_82_0/boost/test/impl/unit_test_main.ipp:208
#6 0x43f6a6 in main
/opt/compiler-explorer/libs/boost_1_82_0/boost/test/impl/unit_test_main.ipp:306
#7 0x7f535e948082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)

SUMMARY: AddressSanitizer: bad-free
(/opt/compiler-explorer/gcc-13.1.0/lib64/libasan.so.8+0xdc098) (BuildId:
c9b24be17e4cbd04bdb4891782c4425e47a9259a) in operator delete[](void*)
==1==ABORTING


The same code runs without sanitizer errors when compiled with gcc 12.3

See https://godbolt.org/z/G4rbo8cGd

[Bug c++/96780] debuginfo for std::move and std::forward isn't useful

[moncef.mechri at gmail dot com via Gcc-bugs]

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

Moncef Mechri  changed:

   What|Removed |Added

 CC||moncef.mechri at gmail dot com

--- Comment #18 from Moncef Mechri  ---
Currently, -ffold-simple-inlines is disabled when optimizations are disabled.

Since it is pretty much standard practice to disable optimizations in debug
builds (yes, I am aware that -Og exists), perhaps it would be a good idea to
make -ffold-simple-inlines opt-out instead of opt-in even for non-optimized
builds?

[Bug middle-end/110869] [14 regression] ICE in decompose, at rtl.h:2297

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

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

--- Comment #7 from Stefan Schulze Frielinghaus  
---
I've send a patch for review:

https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626075.html

and thanks for testing :)

[Bug rtl-optimization/110867] [14 Regression] ICE in combine after 7cdd0860949c6c3232e6cff1d7ca37bb5234074c

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

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

--- Comment #4 from Stefan Schulze Frielinghaus  
---
Thanks for testing so quickly :)

I've send a patch for review:

https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626075.html

[Bug tree-optimization/110875] New: [14 Regression] Dead Code Elimination Regression since r14-2501-g285c9d042e9

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

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

Bug ID: 110875
   Summary: [14 Regression] Dead Code Elimination Regression since
r14-2501-g285c9d042e9
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: theodort at inf dot ethz.ch
  Target Milestone: ---

https://godbolt.org/z/rjxT5PfzY

Given the following code:

void foo(void);
static int a, b;
static int *c = , *d;
static unsigned e;
static short f;
static unsigned g(unsigned char h, char i) { return h + i; }
int main() {
d = 
int *j = d;
e = -27;
for (; e > 18; e = g(e, 6)) {
a = 0;
for (; a != -3; a--) {
if (0 != a ^ *j)
for (; b; b++) f = -f;
else if (*c) {
foo();
break;
}
if (!(((e) >= 235) && ((e) <= 4294967269))) {
__builtin_unreachable();
}
b = 0;
}
}
}

gcc-trunk -O2 does not eliminate the call to foo:

main:
subq$8, %rsp
movl$-27, e(%rip)
.p2align 4,,10
.p2align 3
.L5:
xorl%eax, %eax
.L3:
subl$1, %eax
cmpl$-3, %eax
je  .L2
cmpl$1, %eax
jne .L3
movl$1, a(%rip)
movl$0, b(%rip)
callfoo
.L6:
movzbl  e(%rip), %eax
addl$6, %eax
movl%eax, e(%rip)
cmpl$18, %eax
jg  .L5
xorl%eax, %eax
addq$8, %rsp
ret
.p2align 4,,10
.p2align 3
.L2:
movl$-3, a(%rip)
movl$0, b(%rip)
jmp .L6

gcc-13.2.0 -O2 eliminates the call to foo:

main:
movl$-27, e(%rip)
movl$-27, %esi
.p2align 4,,10
.p2align 3
.L9:
movzwl  f(%rip), %r11d
xorl%ecx, %ecx
xorl%r10d, %r10d
xorl%edx, %edx
movl$0, a(%rip)
movlb(%rip), %eax
leal-235(%rsi), %r8d
jmp .L7
.p2align 4,,10
.p2align 3
.L2:
cmpl$-262, %r8d
ja  .L28
subl$1, %edx
xorl%eax, %eax
movl$1, %ecx
cmpl$-3, %edx
je  .L32
movl%edx, %r9d
.L7:
xorl%esi, %esi
testl   %edx, %edx
movl%ecx, %edi
setne   %sil
cmpl%edx, %esi
je  .L2
testl   %eax, %eax
je  .L2
testb   $1, %al
je  .L3
negl%r11d
addl$1, %eax
je  .L30
.p2align 4,,10
.p2align 3
.L3:
addl$2, %eax
jne .L3
.L30:
movl$1, %edi
movl$1, %r10d
jmp .L2
.p2align 4,,10
.p2align 3
.L32:
movl$-3, a(%rip)
movl$0, b(%rip)
testb   %r10b, %r10b
je  .L8
movw%r11w, f(%rip)
.L8:
movzbl  e(%rip), %esi
addl$6, %esi
movl%esi, e(%rip)
cmpl$18, %esi
jg  .L9
xorl%eax, %eax
ret
.section.text.unlikely
.type   main.cold, @function
main.cold:
.L28:
testb   %cl, %cl
je  .L5
movl%r9d, a(%rip)
.L5:
testb   %dil, %dil
je  .L6
movl%eax, b(%rip)
.L6:
movw%r11w, f(%rip)
.section.text.startup

Bisects to  r14-2501-g285c9d042e9

[Bug c/110874] New: ice with -O2 with recent gcc

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 110874
   Summary: ice with -O2 with recent gcc
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 55675
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55675=edit
C source code

The attached C code, when compiled by recent gcc trunk and -O2, does this:

foundBugs $ ~/gcc/results/bin/gcc -c -w -O2 bug945.c
buildData/keep/in.18686.c: In function ‘func_56’:
buildData/keep/in.18686.c:1184:17: note: the ABI for passing parameters with
32-byte alignment has changed in GCC 4.6
gcc: internal compiler error: Segmentation fault signal terminated program cc1
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
foundBugs $ 

-O1 is fine:

foundBugs $ ~/gcc/results/bin/gcc -c -w -O1 bug945.c
buildData/keep/in.18686.c: In function ‘func_56’:
buildData/keep/in.18686.c:1184:17: note: the ABI for passing parameters with
32-byte alignment has changed in GCC 4.6
foundBugs $ 

Yesterday's compiler (g:01b0c36ba0c3bbe6) seems fine, but today's
(g:0460c1221627938b),
some 36 commits later, does not.

I have a reduction running.

It seems a side issue that -w was given to the compiler, but it still prints
out notes about things that happened a long time ago (gcc 4.6).

[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw

[tomas.kalibera at gmail dot com via Gcc-bugs]

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

--- Comment #16 from Tomas Kalibera  ---
(In reply to Julian Waters from comment #15)
> It seems like the patch also doesn't fix the strftime case too, strangely
> enough. gcc with that patch applied still causes a compilation failure in
> the Windows JDK when encountering strftime with the %T specifier

Given that this bug hasn't attracted enough attention to get fixed, perhaps you
could try reporting this as a wish for improvement of the ms_strftime format
(msformat-c.c, ms_time_char_table): probably it should support %T.

I don't easily see why the patch doesn't help with %T in strftime. In MinGW-W64
10, strftime doesn't seem to have a format attribute at all, so the patch
couldn't help. But in MinGW-W64 11, the gnu_strftime format attribute is
present.

[Bug tree-optimization/110873] [14 Regression] Dead Code Elimination Regression at -O2 since r14-376-g47a76439911

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |14.0

[Bug tree-optimization/110873] New: [14 Regression] Dead Code Elimination Regression at -O2 since r14-376-g47a76439911

[scherrer.sv at gmail dot com via Gcc-bugs]

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

Bug ID: 110873
   Summary: [14 Regression] Dead Code Elimination Regression at
-O2 since r14-376-g47a76439911
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: scherrer.sv at gmail dot com
  Target Milestone: ---

static int b;
static short c;
static char d;
static int *e = 
void foo(void);  
void bar110_(void);
static char(a)(char f, char g) { return f + g; }
int main() {
*e = 3;
unsigned char h;
c = 0;
i:
if (!b)
foo();
h = -25;
for (; h >= 7; h = a(h, 6))
for (; d; d--)
;
if (!(h >= 5))
bar110_();
if (c)
goto i;
}
---
gcc-68c3aa7510b (trunk) -O2 cannot eliminate the call to foo but
gcc-releases/gcc-13.1.0 -O2 can
---
gcc-68c3aa7510b2f45f44379ecd77e97c88780a84ed -O2 case.c -S -o case.s
- OUTPUT -
main:
.LFB1:
.cfi_startproc
movl$3, b(%rip)
xorl%esi, %esi
movw%si, c(%rip)
.L11:
cmpb$0, d(%rip)
je  .L13
movb$0, d(%rip)
.L13:
cmpw$0, c(%rip)
je  .L15
movlb(%rip), %eax
testl   %eax, %eax
jne .L11
subq$8, %rsp
.cfi_def_cfa_offset 16
.L6:
callfoo
.L2:
cmpb$0, d(%rip)
je  .L4
movb$0, d(%rip)
.L4:
cmpw$0, c(%rip)
je  .L5
movlb(%rip), %ecx
testl   %ecx, %ecx
jne .L2
jmp .L6
.L15:
.cfi_def_cfa_offset 8
xorl%eax, %eax
ret
.L5:
.cfi_def_cfa_offset 16
xorl%eax, %eax
popq%rdx
.cfi_def_cfa_offset 8
ret
-- END OUTPUT -

---
gcc-2b98cc24d6af0432a74f6dad1c722ce21c1f7458 -O2 case.c -S -o case.s
- OUTPUT -
main:
.LFB1:
.cfi_startproc
movl$3, b(%rip)
xorl%eax, %eax
cmpb$0, d(%rip)
movw%ax, c(%rip)
je  .L3
movb$0, d(%rip)
.L3:
xorl%eax, %eax
ret
-- END OUTPUT -

---
Bisects to r14-376-g47a76439911

[Bug fortran/88420] Fortran OpenACC "Clause SEQ conflicts with INDEPENDENT"

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

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

Thomas Schwinge  changed:

   What|Removed |Added

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

[Bug middle-end/110857] aarch64-linux-gnu profiledbootstrap broken

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

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

Franz Sirl  changed:

   What|Removed |Added

 CC||sirl at gcc dot gnu.org

--- Comment #2 from Franz Sirl  ---
x86_64-linux profiledbootstrap shows a similar symptom (trunk@r14-2929):

during GIMPLE pass: ivcanon
../../gcc/cfgrtl.cc: In function 'bool can_fallthru(basic_block, basic_block)':
../../gcc/cfgrtl.cc:638:1: internal compiler error: in operator>, at
profile-count.h:995
  638 | can_fallthru (basic_block src, basic_block target)
  | ^~~~
0xa8fb07 profile_count::operator>(profile_count const&) const
../../gcc/profile-count.h:995
0xa93642 update_loop_exit_probability_scale_dom_bbs(loop*, edge_def*,
profile_count)
../../gcc/cfgloopmanip.cc:614
0xa9449f scale_loop_profile(loop*, profile_probability, long)
../../gcc/cfgloopmanip.cc:749
0x10dc9ee try_unroll_loop_completely
../../gcc/tree-ssa-loop-ivcanon.cc:927
0x10dc9ee canonicalize_loop_induction_variables
../../gcc/tree-ssa-loop-ivcanon.cc:1274
0x10dd9c4 canonicalize_induction_variables()
../../gcc/tree-ssa-loop-ivcanon.cc:1317

I'll see if I can find time do the requested debugging later.

[Bug target/110796] builtin_iseqsig fails some tests in armv8l-linux-gnueabihf

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

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #12 from Richard Earnshaw  ---
Working on a patch.

[Bug middle-end/110869] [14 regression] ICE in decompose, at rtl.h:2297

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #6 from Eric Botcazou  ---
> I guess that's best for Eric (Cc'ed) to say.

No objections by me.

[Bug rtl-optimization/110587] [14 regression] 96% pr28071.c compile time regression since r14-2337-g37a231cc7594d1

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

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

--- Comment #21 from Richard Biener  ---
(In reply to Uroš Bizjak from comment #20)
> Can we revert the Comment #13 kludge now?

When we revert it we get

 integrated RA  :   0.42 ( 17%)   0.00 (  0%)   0.43 ( 17%)
   19M ( 16%)
 LRA non-specific   :   0.39 ( 16%)   0.00 (  0%)   0.39 ( 15%)
 6304k (  5%)
 LRA virtuals elimination   :   0.03 (  1%)   0.00 (  0%)   0.02 (  1%)
 3729k (  3%)
 LRA reload inheritance :   0.17 (  7%)   0.01 ( 10%)   0.18 (  7%)
 5109k (  4%)
 LRA create live ranges :   0.27 ( 11%)   0.00 (  0%)   0.28 ( 11%)
  984k (  1%)
 LRA hard reg assignment:   0.72 ( 30%)   0.01 ( 10%)   0.74 ( 29%)
0  (  0%)
 TOTAL  :   2.43  0.10  2.54   
  123M

so the regression is back and also code size increases significantly.

[Bug tree-optimization/106293] [13/14 Regression] 456.hmmer at -Ofast -march=native regressed by 19% on zen2 and zen3 in July 2022

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

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

--- Comment #25 from Richard Biener  ---
(In reply to Jan Hubicka from comment #24)
> g:2e93b92c1ec5fbbbe10765c6e059c3c90d564245 fixes the profile update after
> cancelled distribution. However it does not help hmmer since we actually
> vectorize that loop iterating 0 times.  We need to figure out proper
> iteration count for that and convince loop distribution and vectorizer to do
> nothing on it.

or use a smaller VF?  I doubt the scalar loop iterates zero times?

[Bug middle-end/110869] [14 regression] ICE in decompose, at rtl.h:2297

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

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #5 from Rainer Orth  ---
(In reply to Stefan Schulze Frielinghaus from comment #4)

> This would solve test cases cmp-mem-const-{1,2,3,4}.c.  For
> cmp-mem-const-{5,6} we have that the pre-optimization already chopped the
> 64-bit constant into a 32-bit constant and thus leaves us with nothing to do
> here.  I'm not entirely sure how we handled such cases in the past.  Though,
> one solution would be to simply exclude sparc from this test:
> 
> /* { dg-do compile { target { lp64 } && ! target { sparc*-*-* } } } */
> 
> Would that be ok?

I guess that's best for Eric (Cc'ed) to say.

[Bug rtl-optimization/110587] [14 regression] 96% pr28071.c compile time regression since r14-2337-g37a231cc7594d1

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #20 from Uroš Bizjak  ---
Can we revert the Comment #13 kludge now?

[Bug middle-end/110869] [14 regression] ICE in decompose, at rtl.h:2297

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

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

--- Comment #4 from Stefan Schulze Frielinghaus  
---
For sparc we already see some sort of pre-optimization which "breaks" the new
test cases.  For example, for test cmp-mem-const-1.c we have prior combine:

(insn 14 13 41 2 (set (reg:SI 117)
(ior:SI (reg:SI 118)
(const_int 1023 [0x3ff]))) "cmp-mem-const-1.c":10:13 307 {iorsi3}
 (expr_list:REG_DEAD (reg:SI 118)
(expr_list:REG_EQUAL (const_int 1073741823 [0x3fff])
(nil

(insn 41 14 42 2 (set (reg:CC 100 %icc)
(compare:CC (reg:SI 117)
(reg:SI 116 [ *x_2(D) ]))) "cmp-mem-const-1.c":10:13 1
{*cmpsi_insn}
 (expr_list:REG_DEAD (reg:SI 117)
(expr_list:REG_DEAD (reg:SI 116 [ *x_2(D) ])
(nil

where the 64-bit constant 0x3fff already got chopped into a 32-bit
constant 0x3fff.  Thus in combine we only see

narrow comparison from mode SI to QI: (MEM leu 0x3fff) to (MEM leu 0x3f)

whereas I have been pretty strict in the new tests and demanded to see a 64-bit
constant:

scan-rtl-dump "narrow comparison from mode DI to QI" "combine"

Thus one solution would be to not consider the source mode by using

scan-rtl-dump "narrow comparison from mode .I to QI" "combine"

This would solve test cases cmp-mem-const-{1,2,3,4}.c.  For cmp-mem-const-{5,6}
we have that the pre-optimization already chopped the 64-bit constant into a
32-bit constant and thus leaves us with nothing to do here.  I'm not entirely
sure how we handled such cases in the past.  Though, one solution would be to
simply exclude sparc from this test:

/* { dg-do compile { target { lp64 } && ! target { sparc*-*-* } } } */

Would that be ok?

[Bug tree-optimization/106293] [13/14 Regression] 456.hmmer at -Ofast -march=native regressed by 19% on zen2 and zen3 in July 2022

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

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

--- Comment #24 from Jan Hubicka  ---
g:2e93b92c1ec5fbbbe10765c6e059c3c90d564245 fixes the profile update after
cancelled distribution. However it does not help hmmer since we actually
vectorize that loop iterating 0 times.  We need to figure out proper iteration
count for that and convince loop distribution and vectorizer to do nothing on
it.

[Bug tree-optimization/92335] [11/12/13 Regression] sinking of loads happen too early which causes vectorization not to be done

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||14.0
Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
   |sinking of loads happen too |sinking of loads happen too
   |early which causes  |early which causes
   |vectorization not to be |vectorization not to be
   |done|done

--- Comment #9 from Richard Biener  ---
Fixed for GCC 14, very unlikely to be backported.

[Bug tree-optimization/92335] [11/12/13/14 Regression] sinking of loads happen too early which causes vectorization not to be done

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

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

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

https://gcc.gnu.org/g:399c8dd44ff44f4b496223c7cc980651c4d6f6a0

commit r14-2927-g399c8dd44ff44f4b496223c7cc980651c4d6f6a0
Author: Richard Biener 
Date:   Thu Jul 27 15:34:12 2023 +0200

tree-optimization/92335 - Improve sinking heuristics for vectorization

The following delays sinking of loads within the same innermost
loop when it was unconditional before.  That's a not uncommon
issue preventing vectorization when masked loads are not available.

PR tree-optimization/92335
* tree-ssa-sink.cc (select_best_block): Before loop
optimizations avoid sinking unconditional loads/stores
in innermost loops to conditional executed places.

* gcc.dg/tree-ssa/ssa-sink-10.c: Disable vectorizing.
* gcc.dg/tree-ssa/predcom-9.c: Clone from ssa-sink-10.c,
expect predictive commoning to happen instead of sinking.
* gcc.dg/vect/pr65947-3.c: Ajdust.

[Bug c++/110137] implement clang -fassume-sane-operator-new

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #5 from rguenther at suse dot de  ---
On Wed, 2 Aug 2023, redi at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
> 
> --- Comment #4 from Jonathan Wakely  ---
> Why would that depend on this new option? It's a requirement of the standard,
> it has to be true always.

And GCC already assumes this.  Note we don't make an exception for
pointers passed to deallocation - we're using the info mainly
for memory access disambiguation and rely on the deallocation call
itself to be a barrier for code motion here.

[Bug rtl-optimization/110587] [14 regression] 96% pr28071.c compile time regression since r14-2337-g37a231cc7594d1

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #19 from Richard Biener  ---
The tester shows the issue is fixed now (we're faster than before the
regression).  At -O0 compile-time is still dominated by RA
(r14-2920-g07b7cd70399d22, release checking):

 integrated RA  :   0.29 ( 32%)
 LRA non-specific   :   0.15 ( 16%)
 TOTAL  :   0.91

Samples: 3K of event 'cycles:u', Event count (approx.): 5038659855  
Overhead   Samples  Command  Shared Object   Symbol 
   6.15%   233  cc1  cc1 [.] process_alt_operands
   4.29%   163  cc1  cc1 [.] process_bb_node_lives
   3.72%   142  cc1  cc1 [.] record_reg_classes
   3.01%   114  cc1  cc1 [.] mark_ref_dead
   2.87%   109  cc1  cc1 [.] constrain_operands
   2.71%   114  cc1  cc1 [.]
df_ref_create_structure
   2.47%94  cc1  cc1 [.] ira_setup_alts

[Bug middle-end/110869] [14 regression] ICE in decompose, at rtl.h:2297

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
>> --- Comment #1 from Andrew Pinski  ---
>> Can you test the patch in bug 110867 comment #1 to see if fixes the issue 
>> here
>> too?
>
> Sure: sparc-sun-solaris2.11 bootstrap in progress...

Bootstrap is restored with this patch, however all the new tests FAIL:

FAIL: gcc.dg/cmp-mem-const-1.c scan-rtl-dump combine "narrow comparison from
mode DI to QI"
FAIL: gcc.dg/cmp-mem-const-2.c scan-rtl-dump combine "narrow comparison from
mode DI to QI"
FAIL: gcc.dg/cmp-mem-const-3.c scan-rtl-dump combine "narrow comparison from
mode DI to HI"
FAIL: gcc.dg/cmp-mem-const-4.c scan-rtl-dump combine "narrow comparison from
mode DI to HI"
FAIL: gcc.dg/cmp-mem-const-5.c scan-rtl-dump combine "narrow comparison from
mode DI to SI"
FAIL: gcc.dg/cmp-mem-const-6.c scan-rtl-dump combine "narrow comparison from
mode DI to SI"

[Bug testsuite/110858] [14 Regression] gcc.dg/unroll-1.c UNRESOLVED

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
 Target||x86_64-*-*
   Target Milestone|--- |14.0

[Bug rtl-optimization/110587] [14 regression] 96% pr28071.c compile time regression since r14-2337-g37a231cc7594d1

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

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

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

https://gcc.gnu.org/g:07b7cd70399d22c113ad8bb1eff5cc2d12973d33

commit r14-2920-g07b7cd70399d22c113ad8bb1eff5cc2d12973d33
Author: Richard Biener 
Date:   Tue Jul 25 15:32:11 2023 +0200

rtl-optimization/110587 - remove quadratic regno_in_use_p

The following removes the code checking whether a noop copy
is between something involved in the return sequence composed
of a SET and USE.  Instead of checking for this special-case
the following makes us only ever remove noop copies between
pseudos - which is the case that is necessary for IRA/LRA
interfacing to function according to the comment.  That makes
looking for the return reg special case unnecessary, reducing
the compile-time in LRA non-specific to zero for the testcase.

PR rtl-optimization/110587
* lra-spills.cc (return_regno_p): Remove.
(regno_in_use_p): Likewise.
(lra_final_code_change): Do not remove noop moves
between hard registers.

[Bug c++/110137] implement clang -fassume-sane-operator-new

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

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

--- Comment #4 from Jonathan Wakely  ---
Why would that depend on this new option? It's a requirement of the standard,
it has to be true always.

[Bug target/81904] FMA and addsub instructions

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

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

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

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

commit r14-2919-gf0b7a61d83534fc8f7aa593b1f0f0357a371a800
Author: liuhongt 
Date:   Mon Jul 31 16:03:45 2023 +0800

Support vec_fmaddsub/vec_fmsubadd for vector HFmode.

AVX512FP16 supports vfmaddsubXXXph and vfmsubaddXXXph.
Also remove scalar mode from fmaddsub/fmsubadd pattern since there's
no scalar instruction for that.

gcc/ChangeLog:

PR target/81904
* config/i386/sse.md (vec_fmaddsub4): Extend to vector
HFmode, use mode iterator VFH instead.
(vec_fmsubadd4): Ditto.
(fma_fmaddsub_):
Remove scalar mode from iterator, use VFH_AVX512VL instead.
(fma_fmsubadd_):
Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr81904.c: New test.