[Bug c/106133] New: ICE: SIGSEGV in diagnostic_output_format_init_json_file() with -fdiagnostics-format=json-file -E

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 106133
   Summary: ICE: SIGSEGV in
diagnostic_output_format_init_json_file() with
-fdiagnostics-format=json-file -E
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Compiler output:
$ echo -n > empty.c
$ x86_64-pc-linux-gnu-gcc -fdiagnostics-format=json-file -E empty.c -wrapper
valgrind,-q
==20305== Invalid read of size 1
==20305==at 0x4846FA2: strlen (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==20305==by 0x2634511: xstrdup (xstrdup.c:33)
==20305==by 0x25A92C8:
diagnostic_output_format_init_json_file(diagnostic_context*, char const*)
(diagnostic-format-json.cc:375)
==20305==by 0x258BF28: common_handle_option(gcc_options*, gcc_options*,
cl_decoded_option const*, unsigned int, int, unsigned int, cl_option_handlers
const*, diagnostic_context*, void (*)()) (opts.cc:2853)
==20305==by 0x2590F38: handle_option(gcc_options*, gcc_options*,
cl_decoded_option const*, unsigned int, int, unsigned int, cl_option_handlers
const*, bool, diagnostic_context*) (opts-common.cc:1246)
==20305==by 0x259106E: read_cmdline_option(gcc_options*, gcc_options*,
cl_decoded_option*, unsigned int, unsigned int, cl_option_handlers const*,
diagnostic_context*) (opts-common.cc:1574)
==20305==by 0x129BC64: read_cmdline_options (opts-global.cc:239)
==20305==by 0x129BC64: decode_options(gcc_options*, gcc_options*,
cl_decoded_option*, unsigned int, unsigned int, diagnostic_context*, void
(*)()) (opts-global.cc:321)
==20305==by 0xD114AD: toplev::main(int, char**) (toplev.cc:2265)
==20305==by 0xD13A6A: main (main.cc:39)
==20305==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==20305== 
0x13a859f crash_signal
/repo/gcc-trunk/gcc/toplev.cc:322
0x2634511 xstrdup
/repo/gcc-trunk/libiberty/xstrdup.c:33
0x25a92c8 diagnostic_output_format_init_json_file(diagnostic_context*, char
const*)
/repo/gcc-trunk/gcc/diagnostic-format-json.cc:375
0x258bf28 common_handle_option(gcc_options*, gcc_options*, cl_decoded_option
const*, unsigned int, int, unsigned int, cl_option_handlers const*,
diagnostic_context*, void (*)())
/repo/gcc-trunk/gcc/opts.cc:2853
0x2590f38 handle_option
/repo/gcc-trunk/gcc/opts-common.cc:1246
0x259106e read_cmdline_option(gcc_options*, gcc_options*, cl_decoded_option*,
unsigned int, unsigned int, cl_option_handlers const*, diagnostic_context*)
/repo/gcc-trunk/gcc/opts-common.cc:1574
0x129bc64 read_cmdline_options
/repo/gcc-trunk/gcc/opts-global.cc:239
0x129bc64 decode_options(gcc_options*, gcc_options*, cl_decoded_option*,
unsigned int, unsigned int, diagnostic_context*, void (*)())
/repo/gcc-trunk/gcc/opts-global.cc:321
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.

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

[Bug sanitizer/106132] New: ICE: in report_conflicting_sanitizer_options, at opts.cc:1011 with -fsanitize=thread,address,kernel-hwaddress

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 106132
   Summary: ICE: in report_conflicting_sanitizer_options, at
opts.cc:1011 with
-fsanitize=thread,address,kernel-hwaddress
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
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: ---
  Host: x86_64-pc-linux-gnu

Compiler output:
$ echo -n > empty.c
$ x86_64-pc-linux-gnu-gcc -fsanitize=thread,address,kernel-hwaddress empty.c 
cc1: internal compiler error: in report_conflicting_sanitizer_options, at
opts.cc:1011
0x25889e0 report_conflicting_sanitizer_options
/repo/gcc-trunk/gcc/opts.cc:1011
0x2589e1a finish_options(gcc_options*, gcc_options*, unsigned int)
/repo/gcc-trunk/gcc/opts.cc:1216
0x129bcf4 decode_options(gcc_options*, gcc_options*, cl_decoded_option*,
unsigned int, unsigned int, diagnostic_context*, void (*)())
/repo/gcc-trunk/gcc/opts-global.cc:326
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.


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

[Bug c++/106131] -fstrict-aliasing breaks normal program that does not use any pointer or reference

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

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

--- Comment #2 from Andrew Pinski  ---
Here is a slightly reduced (still has std::vector in it):

#include 

template
struct Pair1
{
  constexpr Pair1(const Pair1&) = default;
  constexpr Pair1(Pair1&&) = default;
  constexpr Pair1(const A& __a, const B& __b)
  : first(__a), second(__b) { }
   Pair1&
  operator=(  const Pair1 &   __p)
  {
first = __p.first;
second = __p.second;
return *this;
  }
  A first;
  B second;
};
typedef Pair1 Pair;

std::vector f = {{0, -11}, {0, -8}, {1, 2}};

int foo(Pair x, Pair y) {
return std::max(x.second, y.second);
}

int main() {
int t = 0;
for (int J = 0; J < 1; J++) {
f[J] = f[0];
if(J == 0)
f[J] = f[2];
t = foo(f[J], f[1]);
}
if (t != 2)
  __builtin_abort();
}

[Bug c++/106131] -fstrict-aliasing breaks normal program that does not use any pointer or reference

[18307130172 at fudan dot edu.cn via Gcc-bugs]

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

--- Comment #1 from 18307130172 at fudan dot edu.cn ---
Created attachment 53221
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53221=edit
output of g++ -v -O2 main.cpp

[Bug c++/106131] New: -fstrict-aliasing breaks normal program that does not use any pointer or reference

[18307130172 at fudan dot edu.cn via Gcc-bugs]

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

Bug ID: 106131
   Summary: -fstrict-aliasing breaks normal program that does not
use any pointer or reference
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 18307130172 at fudan dot edu.cn
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

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

My program does not use any pointer or reference but is affected by
-fstrict-aliasing. Here is a minimal example to manifest this issue:

#include 
#include 

using Pair = std::pair;

std::vector f = {{0, -11}, {0, -8}, {1, 2}};

int foo(Pair x, Pair y) {
return std::max(x.second, y.second);
}

int main() {
for (int J = 0; J < 1; J++) {
f[J] = f[0];
if(J == 0)
f[J] = f[2];
std::cout << foo(f[J], f[1]) << std::endl;
}
}

Save it to main.cpp and compile it with:

g++ -O2 main.cpp

The expected output should be "2", but the optimized build output "-8". If
compiled with "-O2 -fno-strict-aliasing", the output is correct.

[Bug tree-optimization/105903] Missed optimization for __synth3way

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|NEW |ASSIGNED
 Depends on||96923

--- Comment #3 from Andrew Pinski  ---
(In reply to luoxhu from comment #2)
> diff --git a/gcc/match.pd b/gcc/match.pd
> index 4a570894b2e..f6b5415a351 100644
> --- a/gcc/match.pd
> +++ b/gcc/match.pd
> @@ -5718,6 +5718,22 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>   (bit_xor (convert (rshift @0 {shifter;})) @1)
>   (bit_not (bit_xor (convert (rshift @0 {shifter;})) @1)))
> 
> +/* X >= Y ? X > Y : 0 into X > Y. */
> +(simplify
> +  (cond (ge @0 @1) (gt @0 @1) integer_zerop)
> +   (if (INTEGRAL_TYPE_P (type)
> +   && POINTER_TYPE_P (TREE_TYPE (@0))
> +   && POINTER_TYPE_P (TREE_TYPE (@1)))
> +(gt @0 @1)))
> +
> +/* X < Y ? 0 : X > Y into X > Y.  */
> +(simplify
> +  (cond (lt @0 @1) integer_zerop (gt @0 @1))
> +   (if (INTEGRAL_TYPE_P (type)
> +   && POINTER_TYPE_P (TREE_TYPE (@0))
> +   && POINTER_TYPE_P (TREE_TYPE (@1)))
> +(gt @0 @1)))
> +

Hmm, could be simplified to just:
+#if GIMPLE
+/* a ? b : c -> (a & b) | (!a & c) for truth (boolean) values
+   Only if either b or c are integer constants. */
+(simplify
+ (cond @0 truth_valued_p@1 truth_valued_p@2)
+ (if (TREE_CODE (@1) == INTEGER_CST
+  || TREE_CODE (@2) == INTEGER_CST)
+  (with {
+   tree booltrue = constant_boolean_node (true, type);
+ }
+   (bit_ior (bit_and (convert @0) @1) (bit_and (bit_xor (convert @0) {
booltrue; }) @2)
+#endif

Which is PR 96923 so mine.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96923
[Bug 96923] Failure to optimize a select-related bool pattern to or+not

[Bug tree-optimization/105903] Missed optimization for __synth3way

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

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

--- Comment #2 from luoxhu at gcc dot gnu.org ---
diff --git a/gcc/match.pd b/gcc/match.pd
index 4a570894b2e..f6b5415a351 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -5718,6 +5718,22 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  (bit_xor (convert (rshift @0 {shifter;})) @1)
  (bit_not (bit_xor (convert (rshift @0 {shifter;})) @1)))

+/* X >= Y ? X > Y : 0 into X > Y. */
+(simplify
+  (cond (ge @0 @1) (gt @0 @1) integer_zerop)
+   (if (INTEGRAL_TYPE_P (type)
+   && POINTER_TYPE_P (TREE_TYPE (@0))
+   && POINTER_TYPE_P (TREE_TYPE (@1)))
+(gt @0 @1)))
+
+/* X < Y ? 0 : X > Y into X > Y.  */
+(simplify
+  (cond (lt @0 @1) integer_zerop (gt @0 @1))
+   (if (INTEGRAL_TYPE_P (type)
+   && POINTER_TYPE_P (TREE_TYPE (@0))
+   && POINTER_TYPE_P (TREE_TYPE (@1)))
+(gt @0 @1)))
+

The two patterns could fold PHI in phiopt4 for the two greater3way and generate
expected results.

[Bug middle-end/106130] internal compiler error: Illegal instruction

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2022-06-29
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
> This failure only reproduces on certain machine types even when using the 
> same OS image and same GCC.

How did you compile/configure GMP, MPFR, MPC? I suspect you did compiled
GMP/MPFR/MPC on one machine and those packages default basically to
-mcpu=native and then used it on others.

[Bug c/106130] New: internal compiler error: Illegal instruction

[kalen.brunham at intel dot com via Gcc-bugs]

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

Bug ID: 106130
   Summary: internal compiler error: Illegal instruction
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kalen.brunham at intel dot com
  Target Milestone: ---

Created attachment 53219
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53219=edit
Test case

Compiling test.c with:

/usr/intel/pkgs/gcc/11.1.0/bin/gcc -v -fvisibility=hidden
-fno-var-tracking-assignments -DHAVE_MODULE_DATE -DSIMICS_5_API -gdwarf-2 -Wall
-Wwrite-strings -std=gnu99 -fPIC -Wformat-security -O2 -D_FORTIFY_SOURCE=2 
-fcommon -c test.c -o test.o


Fails with:

Reading specs from
/nfs/site/itools/em64t_SLES12SP5/pkgs/gcc/11.1.0/.bin/../lib/gcc/x86_64-pc-linux-gnu/11.1.0/specs
COLLECT_GCC=/usr/intel/pkgs/gcc/11.1.0/.bin/gcc
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/usr/intel/pkgs/gcc/11.1.0
--enable-languages=c,c++,objc,fortran --enable-gold=yes --with-system-zlib
--disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-fvisibility=hidden' '-fno-var-tracking-assignments'
'-D' 'HAVE_MODULE_DATE' '-D' 'SIMICS_5_API' '-gdwarf-2' '-Wall'
'-Wwrite-strings' '-std=gnu99' '-fPIC' '-Wformat-security' '-O2' '-D'
'_FORTIFY_SOURCE=2' '-fcommon' '-c' '-o' 'test.o' '-mtune=generic'
'-march=x86-64'

/nfs/site/itools/em64t_SLES12SP5/pkgs/gcc/11.1.0/.bin/../libexec/gcc/x86_64-pc-linux-gnu/11.1.0/cc1
-quiet -v -iprefix
/nfs/site/itools/em64t_SLES12SP5/pkgs/gcc/11.1.0/.bin/../lib/gcc/x86_64-pc-linux-gnu/11.1.0/
-D HAVE_MODULE_DATE -D SIMICS_5_API -D _FORTIFY_SOURCE=2 test.c -quiet
-dumpbase test.c -dumpbase-ext .c -mtune=generic -march=x86-64 -gdwarf-2 -O2
-Wall -Wwrite-strings -Wformat-security -std=gnu99 -version -fvisibility=hidden
-fno-var-tracking-assignments -fPIC -fcommon -o /tmp/ccKi1d1X.s
GNU C99 (GCC) version 11.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 10.1.0, GMP version 6.1.2, MPFR version
4.0.2, MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/nfs/site/itools/em64t_SLES12SP5/pkgs/gcc/11.1.0/.bin/../lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/include"
ignoring duplicate directory
"/nfs/site/itools/em64t_SLES12SP5/pkgs/gcc/11.1.0/.bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/11.1.0/include"
ignoring duplicate directory
"/nfs/site/itools/em64t_SLES12SP5/pkgs/gcc/11.1.0/.bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/11.1.0/include-fixed"
ignoring nonexistent directory
"/nfs/site/itools/em64t_SLES12SP5/pkgs/gcc/11.1.0/.bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/nfs/site/itools/em64t_SLES12SP5/pkgs/gcc/11.1.0/.bin/../lib/gcc/x86_64-pc-linux-gnu/11.1.0/include

/nfs/site/itools/em64t_SLES12SP5/pkgs/gcc/11.1.0/.bin/../lib/gcc/x86_64-pc-linux-gnu/11.1.0/include-fixed
 /usr/local/include
 /nfs/site/itools/em64t_SLES12SP5/pkgs/gcc/11.1.0/.bin/../lib/gcc/../../include
 /usr/include
End of search list.
GNU C99 (GCC) version 11.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 10.1.0, GMP version 6.1.2, MPFR version
4.0.2, MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 8358ad49fce44be475210251587261da
test.c: In function ‘bigtime_as_sec’:
test.c:89:9: internal compiler error: Illegal instruction
   89 | return int128_to_double(t.val) / 1e12;
  | ^~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Sweeping across GCC versions I see:
11.2.0 : fail
11.1.0 : fail
10.3.0 : Pass
10.1.0 : Pass
9.2.0 : Pass
9.1.0 : Pass
8.3.0 : Fail
8.2.0 : Pass
7.2.0 : Pass
6.5.0 : Pass

This failure only reproduces on certain machine types even when using the same
OS image and same GCC.

[Bug other/106120] [13 regression] g++.dg/warn/Wstringop-overflow-4.C fails since r13-1268-g8c99e307b20c50

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #3 from Hans-Peter Nilsson  ---
(In reply to seurer from comment #2)
> I am not sure.  This only happens for 32 bit runs on power.  64 bit ones
> work fine.

You mean something like -m32 with powerpc64-linux-gnu?

I'll dump my observations for cris-elf (a "32-bit target") hoping it'll help:
At r13-1268-g8c99e307b20c50:

Running TOPLEVEL/gcc/testsuite/g++.dg/dg.exp ...
...
FAIL: g++.dg/warn/Wstringop-overflow-4.C  -std=gnu++98 (test for excess errors)
...

At r13-1333-g74956337e827, (long) after r13-1271-g80ace9185dc534
al...@redhat.com "XFAIL a test in g++.dg/warn/Wstringop-overflow-4.C":

Running TOPLEVEL/gcc/testsuite/g++.dg/dg.exp ...
FAIL: g++.dg/warn/Wstringop-overflow-4.C  -std=gnu++98 (test for excess errors)
XPASS: g++.dg/warn/Wstringop-overflow-4.C  -std=gnu++14  (test for bogus
messages, line 198)
XPASS: g++.dg/warn/Wstringop-overflow-4.C  -std=gnu++17  (test for bogus
messages, line 198)
XPASS: g++.dg/warn/Wstringop-overflow-4.C  -std=gnu++20  (test for bogus
messages, line 198)

g++.log at that latter commit:
FAIL: g++.dg/warn/Wstringop-overflow-4.C  -std=gnu++98 (test for excess errors)
Excess errors:
TOPLEVEL/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:144:3: warning:
'void* __builtin_memcpy(void*, const void*, long unsigned int)' writing 3 bytes
into a region of size 0 [-Wstringop-overflow=]

[Bug c/106117] Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---
we're using -fexcess-precision=16 to force operation-by-operation translation
when  AVX512-FP16 is not available.

https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576493.html

[Bug lto/106129] New: [12/13 Regression] LTO option merging broken

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

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

Bug ID: 106129
   Summary: [12/13 Regression] LTO option merging broken
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

The LTO merging of options from different input files was broken by:

commit 227a2ecf663d69972b851f51f1934d18927b62cd
Author: Martin Liska 
Date:   Fri Mar 12 11:53:47 2021 +0100

lto-wrapper: Use vec data type.

Previously, find_and_merge_options would merge options it read into those in
*opts. After this commit, options in *opts on entry to find_and_merge_options
are ignored; the only merging that takes place is between multiple sets of
options in the same input file that are read in the same call to this function
(not sure how that case can occur at all). The effects include, for example,
that if some objects are built with PIC enabled and others with it disabled,
and the last LTO object processed has PIC enabled, the choice of PIC for the
last object will result in the whole program being built as PIC, when the
merging logic is intended to ensure that a mixture of PIC and non-PIC objects
results in the whole program being built as non-PIC.

I'm testing a patch for this bug.

[Bug c++/106128] Bogus Warning on static_cast double to bool with -Wfloat-equal

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
>its internals

What do you mean internals?

When you do a static cast anything to a bool, it is always converted to "!= 0".
This is not an internal part of GCC but part of the language. 

GCC is not warning about the constant version because it know exactly that 0.0
!= 0.0 will be true at compile time as it is considered an constant expression
as required by the C++ standard.

clang does not have -Wfloat-equal so there is nothing to compare against here.

Also note comparing against 0.0 will have -0.0 be equal too. Which might not be
what you wnated either.

[Bug c++/106128] Bogus Warning on static_cast double to bool with -Wfloat-equal

[mckelvey at maskull dot com via Gcc-bugs]

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

--- Comment #1 from James McKelvey  ---
I guess I should say recent Windows 10 with Cygwin.

[Bug c++/106128] New: Bogus Warning on static_cast double to bool with -Wfloat-equal

[mckelvey at maskull dot com via Gcc-bugs]

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

Bug ID: 106128
   Summary: Bogus Warning on static_cast double to bool with
-Wfloat-equal
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mckelvey at maskull dot com
  Target Milestone: ---

static_cast should not warn on its internals.


int main()
{
double xx(0.0);

// Warning
bool y = static_cast(xx);

// No warning
bool z = static_cast(0.0);

return 0;
}

g++ -Wfloat-equal -c test.cc

test.cc: In function ‘int main()’:
test.cc:6:36: warning: comparing floating-point with ‘==’ or ‘!=’ is unsafe
[-Wfloat-equal]
6 | bool y = static_cast(xx);
  |^~

$ /usr/local/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-cygwin/13.0.0/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with: ./configure --enable-languages=c,c++ --enable-threads=posix
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220626 (experimental) (GCC)

$ uname
CYGWIN_NT-10.0-19044


Fails on gcc-11-20220624, gcc-12-20220625, gcc-13-20220626

[Bug tree-optimization/106126] tree check fail in useless_type_conversion_p, at gimple-expr.cc:87

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from David Binderman  ---
Seems good. Current range appears to be [607118dfa47a1865, f1fcd6e3ad911945].

[Bug c/106117] Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #2 from joseph at codesourcery dot com  ---
"none" was something I mentioned as a possible future argument when 
originally posting -fexcess-precision 
.  I 
still think it's the appropriate name for that case.

(Doing +-*/ operations on float and then immediately converting back to 
_Float16 has exactly the same semantics as direct _Float16 arithmetic; 
float has sufficient precision that no double rounding issues arise; that 
doesn't apply to fma, however.  The effect of excess precision is that 
e.g. in "a + b + c", the value of a + b with the range and precision of 
float is what gets added to c; there's no intermediate truncation of a + b 
to _Float16.  But (_Float16)(a + b) + c would have such a truncation, 
because casts and conversion as if by assignment remove excess range and 
precision.)

[Bug libstdc++/106127] experimental::filesystem::path("//") should be a root-directory not a root-name

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

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

--- Comment #1 from Jonathan Wakely  ---
This patch:

--- a/libstdc++-v3/src/filesystem/path.cc
+++ b/libstdc++-v3/src/filesystem/path.cc
@@ -377,7 +377,7 @@ path::_M_split_cmpts()
  if (len == 2)
{
  // entire path is just "//"
- _M_type = _Type::_Root_name;
+ _M_type = _Type::_Root_dir;
  return;
}

fixes the absolute.cc test on Windows and causes only one new FAIL (on all
targets):

/home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/experimental/filesystem/path/decompose/root_directory.cc:52:
void test02(): Assertion 'rootdir.string()[0] != '/'' failed.
FAIL: experimental/filesystem/path/decompose/root_directory.cc execution test

The test seems questionable anyway:

void
test02()
{
  for (const path p : __gnu_test::test_paths)
  {
path rootdir = p.root_directory();
// If root-directory is composed of 'slash name',
// 'slash' is excluded from the returned string.
if (!rootdir.empty() && rootdir.string() != "/")
  VERIFY( rootdir.string()[0] != '/' );
  }
}

This fails with the change because "//" behaves the same as "/" and so still
has a leading slash.

[Bug tree-optimization/106126] tree check fail in useless_type_conversion_p, at gimple-expr.cc:87

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
(In reply to David Binderman from comment #3)
> I am trying a git bisect. Trying git f1fcd6e3ad911945.

Goes wrong with that. Trying 607118dfa47a1865.

[Bug libstdc++/106127] New: experimental::filesystem::path("//") should be a root-directory not a root-name

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

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

Bug ID: 106127
   Summary: experimental::filesystem::path("//") should be a
root-directory not a root-name
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

Our Filesystem TS implementation treats // the same as //x which is probably
wrong.

It causes experimental/filesystem/operations/absolute.cc to FAIL on Windows,
because absolute(path("//"), "z:\\tmp") returns "//\\tmp" which is a root-name.
(On the other hand, the specification for experimental::filesystem::absolute is
known to be broken for Windows, and was completely changed for C++17).

[Bug fortran/106121] ICE in gfc_simplify_extends_type_of, at fortran/simplify.cc:3109

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #4)
> Shorter is definitely better.  One thing that my patch
> allowed was shortening the tortured if-statement that
> is spread across a dozen of so lines.  In any event,
> if you're patch survives regression testing, ok to
> commit.

It did regtest fine.  I nevertheless submitted here

https://gcc.gnu.org/pipermail/fortran/2022-June/057966.html

and will wait for 24h for comments.

[Bug tree-optimization/106126] tree check fail in useless_type_conversion_p, at gimple-expr.cc:87

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
I am trying a git bisect. Trying git f1fcd6e3ad911945.

[Bug fortran/106121] ICE in gfc_simplify_extends_type_of, at fortran/simplify.cc:3109

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #4 from Steve Kargl  ---
On Tue, Jun 28, 2022 at 07:43:39PM +, anlauf at gcc dot gnu.org wrote:
> (In reply to kargl from comment #2)
> > Infamous NULL pointer dereference.
> 
> Yes.
> 
> Shorter fix:
> 
> diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
> index e8e3ec63669..b5112da441a 100644
> --- a/gcc/fortran/simplify.cc
> +++ b/gcc/fortran/simplify.cc
> @@ -3096,6 +3096,10 @@ gfc_simplify_extends_type_of (gfc_expr *a, gfc_expr
> *mold)
>if (UNLIMITED_POLY (a) || UNLIMITED_POLY (mold))
>  return NULL;
> 
> +  if ((a->ts.type == BT_CLASS && !gfc_expr_attr (a).class_ok)
> +  || (mold->ts.type == BT_CLASS && !gfc_expr_attr (mold).class_ok))
> +return NULL;
> +
>/* Return .false. if the dynamic type can never be an extension.  */
>if ((a->ts.type == BT_CLASS && mold->ts.type == BT_CLASS
> && !gfc_type_is_extension_of
> 

Shorter is definitely better.  One thing that my patch
allowed was shortening the tortured if-statement that
is spread across a dozen of so lines.  In any event,
if you're patch survives regression testing, ok to
commit.

[Bug fortran/103942] [9 Regression] invalid memory reference with allocatable string and class(*)

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
Fixed for gcc-10.4.

[Bug fortran/106121] ICE in gfc_simplify_extends_type_of, at fortran/simplify.cc:3109

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #2)
> Infamous NULL pointer dereference.

Yes.

Shorter fix:

diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index e8e3ec63669..b5112da441a 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -3096,6 +3096,10 @@ gfc_simplify_extends_type_of (gfc_expr *a, gfc_expr
*mold)
   if (UNLIMITED_POLY (a) || UNLIMITED_POLY (mold))
 return NULL;

+  if ((a->ts.type == BT_CLASS && !gfc_expr_attr (a).class_ok)
+  || (mold->ts.type == BT_CLASS && !gfc_expr_attr (mold).class_ok))
+return NULL;
+
   /* Return .false. if the dynamic type can never be an extension.  */
   if ((a->ts.type == BT_CLASS && mold->ts.type == BT_CLASS
&& !gfc_type_is_extension_of

I think we need a good (better) set of macros to concisely handle problems
like the above to improve error recovery.

[Bug fortran/106121] ICE in gfc_simplify_extends_type_of, at fortran/simplify.cc:3109

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2022-06-28
 CC||kargl at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Priority|P3  |P4

--- Comment #2 from kargl at gcc dot gnu.org ---
Infamous NULL pointer dereference.

diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index c8f2ef9fbf4..1a33f26932a 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -3084,6 +3084,8 @@ is_last_ref_vtab (gfc_expr *e)
 gfc_expr *
 gfc_simplify_extends_type_of (gfc_expr *a, gfc_expr *mold)
 {
+  gfc_component *ac, *mc;
+
   /* Avoid simplification of resolved symbols.  */
   if (is_last_ref_vtab (a) || is_last_ref_vtab (mold))
 return NULL;
@@ -3096,31 +3098,28 @@ gfc_simplify_extends_type_of (gfc_expr *a, gfc_expr
*mold)
   if (UNLIMITED_POLY (a) || UNLIMITED_POLY (mold))
 return NULL;

+  ac = a->ts.u.derived->components;
+  if (a->ts.type == BT_CLASS && !ac)
+return NULL;
+
+  mc = mold->ts.u.derived->components;
+  if (mold->ts.type == BT_CLASS && !mc)
+return NULL;
+
   /* Return .false. if the dynamic type can never be an extension.  */
   if ((a->ts.type == BT_CLASS && mold->ts.type == BT_CLASS
-   && !gfc_type_is_extension_of
-   (mold->ts.u.derived->components->ts.u.derived,
-a->ts.u.derived->components->ts.u.derived)
-   && !gfc_type_is_extension_of
-   (a->ts.u.derived->components->ts.u.derived,
-mold->ts.u.derived->components->ts.u.derived))
+   && !gfc_type_is_extension_of (mc->ts.u.derived, ac->ts.u.derived)
+   && !gfc_type_is_extension_of (ac->ts.u.derived, mc->ts.u.derived))
   || (a->ts.type == BT_DERIVED && mold->ts.type == BT_CLASS
- && !gfc_type_is_extension_of
-   (mold->ts.u.derived->components->ts.u.derived,
-a->ts.u.derived))
+ && !gfc_type_is_extension_of (mc->ts.u.derived, a->ts.u.derived))
   || (a->ts.type == BT_CLASS && mold->ts.type == BT_DERIVED
- && !gfc_type_is_extension_of
-   (mold->ts.u.derived,
-a->ts.u.derived->components->ts.u.derived)
- && !gfc_type_is_extension_of
-   (a->ts.u.derived->components->ts.u.derived,
-mold->ts.u.derived)))
+ && !gfc_type_is_extension_of (mold->ts.u.derived, ac->ts.u.derived)
+ && !gfc_type_is_extension_of (ac->ts.u.derived, mold->ts.u.derived)))
 return gfc_get_logical_expr (gfc_default_logical_kind, >where, false);

   /* Return .true. if the dynamic type is guaranteed to be an extension.  */
   if (a->ts.type == BT_CLASS && mold->ts.type == BT_DERIVED
-  && gfc_type_is_extension_of (mold->ts.u.derived,
-  a->ts.u.derived->components->ts.u.derived))
+  && gfc_type_is_extension_of (mold->ts.u.derived, ac->ts.u.derived))
 return gfc_get_logical_expr (gfc_default_logical_kind, >where, true);

   return NULL;

[Bug ipa/106124] [11/12/13 Regression] ICE in dwarf2out_abstract_function, at dwarf2out.cc:23254

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Started with r10-5053-gb3f44388f3bb9b42, but it ICEd with a different reason
the revision before it:

/home/marxin/Programming/gcc/libgomp/testsuite/libgomp.c++/udr-20.C:16:134:
internal compiler error: in cp_check_omp_declare_reduction, at
cp/semantics.c:5482
   #pragma omp declare reduction (x : T : omp_out += omp_in + [](){ return T
(0); }()) initializer (omp_priv = [](){ return T (0); }())

[Bug other/106120] [13 regression] g++.dg/warn/Wstringop-overflow-4.C fails since r13-1268-g8c99e307b20c50

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

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

--- Comment #2 from seurer at gcc dot gnu.org ---
I am not sure.  This only happens for 32 bit runs on power.  64 bit ones work
fine.

[Bug tree-optimization/106126] tree check fail in useless_type_conversion_p, at gimple-expr.cc:87

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
Reduced C code seems to be

char *var_1;
void pool_conda_matchspec() {
  for (; var_1 && *var_1 &&
 *var_1 != '<' && *var_1 != '>' &&
 *var_1 != '!' && *var_1 != '~';)
if (*var_1 >= 'A' && *var_1 <= 'Z')
  *var_1 += 'A';
}

[Bug tree-optimization/106126] tree check fail in useless_type_conversion_p, at gimple-expr.cc:87

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
Problem first seems to occur sometime between git hash 713f2fd923442b1b
and 98b6e62cf5e7d477, a couple of days later.

cvise reduction running in other window.

[Bug c/106126] New: tree check fail in useless_type_conversion_p, at gimple-expr.cc:87

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 106126
   Summary: tree check fail in useless_type_conversion_p, at
gimple-expr.cc:87
   Product: gcc
   Version: 12.0
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 53218
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53218=edit
C source code

For the attached C code, with recent gcc trunk and compiler flag -O2, I get

$ ../results/bin/gcc -c -O2 bug822.c
during GIMPLE pass: iftoswitch
/home/dcb36/rpmbuild/BUILD/libsolv-0.7.20/src/conda.c: In function
‘pool_conda_matchspec’:
/home/dcb36/rpmbuild/BUILD/libsolv-0.7.20/src/conda.c:679:1: internal compiler
error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in
useless_type_conversion_p, at gimple-expr.cc:87
  679 | }
  | ^
0x10fcfba tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../trunk.git/gcc/tree.cc:8866
0x9ffd8c tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../trunk.git/gcc/tree.h:3639
0x9ffd8c useless_type_conversion_p(tree_node*, tree_node*)
../../trunk.git/gcc/gimple-expr.cc:87

I will have my usual go at identifying a git hash range and reducing the code.

[Bug c++/95291] ICE in resolve_args at gcc/cp/call.c:4482

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mameluc at gmail dot com

--- Comment #12 from Marek Polacek  ---
*** Bug 106125 has been marked as a duplicate of this bug. ***

[Bug c++/106125] [c++2a] Segmentation fault in constexpr initialization of static variable

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Dup.

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

[Bug c++/106125] [c++2a] Segmentation fault in constexpr initialization of static variable

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
I think this was fixed in GCC 11.

[Bug other/106120] [13 regression] g++.dg/warn/Wstringop-overflow-4.C fails since r13-1268-g8c99e307b20c50

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

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

--- Comment #1 from Aldy Hernandez  ---
I wonder if this is the same problem we see on x86-64 on line 198.

[Bug c++/106125] [c++2a] Segmentation fault in constexpr initialization of static variable

[mameluc at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Marcos Campos  ---
Command line: 
g++-10 -save-temps -std=c++2a test_segfault.cpp

[Bug c++/106125] New: [c++2a] Segmentation fault in constexpr initialization of static variable

[mameluc at gmail dot com via Gcc-bugs]

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

Bug ID: 106125
   Summary: [c++2a] Segmentation fault in constexpr initialization
of static variable
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mameluc at gmail dot com
  Target Milestone: ---

Created attachment 53217
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53217=edit
Preprocessed file (compressed)

The following code triggers a segfault. Tested with g++ 10.3.0, -O0 to -O3

/* starts here */
template
struct DataStructure
{
};

template
struct StringLiteral 
{
constexpr StringLiteral (const char ()[N]) 
{
std::copy_n(str, N, value); 
}

constexpr auto operator<=>(const StringLiteral&) const = default;
constexpr bool operator==(const StringLiteral&) const  = default;
static constexpr auto len = N; 
char value[N];
};



template 
struct Item
{
constexpr static auto item_name = Name;
T data;
};



template 
struct Test
{
static constexpr auto eq = false;
};

template 
struct Test
{
static constexpr auto eq = (Target == First::item_name) || Test::eq;
};



template
struct DataStructure
{
constexpr DataStructure()
: first()
, rest()
{
// this line!
static_assert(!Test::eq, "repeated id in data
structure");
}

T first;
DataStructure rest;
};

DataStructure<
Item<"Ident::ZUM", int>, 
Item<"Ident::FOO", float>,
Item<"Ident::BAR", float>
> data;

/* ends here */

g++-10 -save-temps -std=c++2a test_segfault.cpp
test_segfault.cpp: In constructor ‘constexpr DataStructure::DataStructure()’:
test_segfault.cpp:58:50: internal compiler error: Segmentation fault
   58 | static_assert(!Test::eq, "repeated id in
data structure");
  |  ^
0x7f3d44ebe08f ???
   
/build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7f3d44e9f082 __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make: *** [Makefile:2: all] Error 1

//
Compiler info:

Using built-in specs.
COLLECT_GCC=g++-10
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
10.3.0-1ubuntu1~20.04' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-10-S4I5Pr/gcc-10-10.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-S4I5Pr/gcc-10-10.3.0/debian/tmp-gcn/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.3.0 (Ubuntu 10.3.0-1ubuntu1~20.04)

[Bug c++/106124] New: [11/12/13 Regression] ICE in dwarf2out_abstract_function, at dwarf2out.cc:23254

[gscfq--- via Gcc-bugs]

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

Bug ID: 106124
   Summary: [11/12/13 Regression] ICE in
dwarf2out_abstract_function, at dwarf2out.cc:23254
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20200621 and 20200628,
with files libgomp/testsuite/libgomp.c++/udr-20.C and udr-21.C :


$ gcc-13-20220626 -c udr-20.C -g -O2 -fopenmp -fkeep-inline-functions
during IPA pass: inline
In static member function 'static constexpr int A::omp declare reduction
x~i(T&)_FUN()':
cc1plus: internal compiler error: in dwarf2out_abstract_function, at
dwarf2out.cc:23254
0xa07c13 dwarf2out_abstract_function
../../gcc/dwarf2out.cc:23254
0xe32e4d tree_function_versioning(tree_node*, tree_node*, vec*, ipa_param_adjustments*, bool, bitmap_head*,
basic_block_def*)
../../gcc/tree-inline.cc:6219
0xb8cd98 save_inline_function_body
../../gcc/ipa-inline-transform.cc:658
0xb8cd98 inline_transform(cgraph_node*)
../../gcc/ipa-inline-transform.cc:750
0xcddad3 execute_one_ipa_transform_pass
../../gcc/passes.cc:2330
0xcddad3 execute_all_ipa_transforms(bool)
../../gcc/passes.cc:2393
0x99c927 cgraph_node::expand()
../../gcc/cgraphunit.cc:1827
0x99de92 expand_all_functions
../../gcc/cgraphunit.cc:1998
0x99de92 symbol_table::compile()
../../gcc/cgraphunit.cc:2348
0x9a060f symbol_table::compile()
../../gcc/cgraphunit.cc:2532
0x9a060f symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.cc:2529

[Bug c++/106123] New: ICE in walk_tree_1, at tree.cc:11243

[gscfq--- via Gcc-bugs]

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

Bug ID: 106123
   Summary: ICE in walk_tree_1, at tree.cc:11243
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r12 and option -ftrivial-auto-var-init=zero,
with file g++.dg/gomp/member-1.C :


$ gcc-13-20220626 -c member-1.C -fopenmp -ftrivial-auto-var-init=zero
during GIMPLE pass: omplower
member-1.C: In member function 'void S::foo()':
member-1.C:99:13: internal compiler error: Segmentation fault
   99 | #pragma omp taskloop firstprivate (a, t) lastprivate (t)
  | ^~~
0xdb5c7f crash_signal
../../gcc/toplev.cc:322
0x104c224 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.cc:11243
0x104c86a walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.cc:11468
0xc74445 unshare_and_remap
../../gcc/omp-low.cc:329
0xc78f87 lower_omp_regimplify_operands_p
../../gcc/omp-low.cc:14307
0x104c212 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.cc:11237
0xb0ceb8 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.cc:202
0xc74fa4 lower_omp_regimplify_operands
../../gcc/omp-low.cc:14331
0xc7fac1 lower_omp_1
../../gcc/omp-low.cc:14597
0xc7fac1 lower_omp
../../gcc/omp-low.cc:14609
0xc93593 lower_omp_for
../../gcc/omp-low.cc:11648
0xc80d21 lower_omp_1
../../gcc/omp-low.cc:14415
0xc80d21 lower_omp
../../gcc/omp-low.cc:14609
0xc80e8e lower_omp_1
../../gcc/omp-low.cc:14399
0xc80e8e lower_omp
../../gcc/omp-low.cc:14609
0xc80e8e lower_omp_1
../../gcc/omp-low.cc:14399
0xc80e8e lower_omp
../../gcc/omp-low.cc:14609
0xc8fc83 lower_omp_taskreg
../../gcc/omp-low.cc:12564
0xc809f1 lower_omp_1
../../gcc/omp-low.cc:14408
0xc809f1 lower_omp
../../gcc/omp-low.cc:14609

[Bug c/106122] New: [12/13 Regression] ICE in fixup_args_size_notes, at expr.cc:4493

[gscfq--- via Gcc-bugs]

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

Bug ID: 106122
   Summary: [12/13 Regression] ICE in fixup_args_size_notes, at
expr.cc:4493
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20211219 and 20220109,
with -Oz and file gcc.target/i386/pr104446.c :


$ gcc-12-20211219 -c pr104446.c -m32 -Oz
$
$ gcc-13-20220626 -c pr104446.c -m32 -Oz
during RTL pass: peephole2
pr104446.c: In function 'baz':
pr104446.c:15:1: internal compiler error: in fixup_args_size_notes, at
expr.cc:4493
   15 | }
  | ^
0x8d72ec fixup_args_size_notes(rtx_insn*, rtx_insn*, poly_int<1u, long>)
../../gcc/expr.cc:4493
0xb98f36 peep2_attempt
../../gcc/recog.cc:4014
0xb98f36 peephole2_optimize
../../gcc/recog.cc:4183
0xb98f36 rest_of_handle_peephole2
../../gcc/recog.cc:4331
0xb98f36 execute
../../gcc/recog.cc:4365

[Bug fortran/106121] ICE in gfc_simplify_extends_type_of, at fortran/simplify.cc:3109

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #1 from G. Steinmetz  ---

$ cat z3.f90
program p
   type t
  integer :: a
   end type
   type(t) :: x
   class(t) :: y
   print *, extends_type_of(x, y)
end


$ cat z4.f90
program p
   type t
  integer :: a
   end type
   type(t) :: x
   class(t) :: y
   stop extends_type_of(x, y)
end


$ gfortran-13-20220626 -c z3.f90
z3.f90:6:16:

6 |class(t) :: y
  |1
Error: CLASS variable 'y' at (1) must be dummy, allocatable or pointer


$ gfortran-13-20220626 -c z4.f90
f951: internal compiler error: gfc_compare_derived_types: invalid derived type
0x73a249 gfc_report_diagnostic
../../gcc/fortran/error.cc:883
0x73bdc7 gfc_internal_error(char const*, ...)
../../gcc/fortran/error.cc:1503
0x748458 gfc_compare_derived_types(gfc_symbol*, gfc_symbol*)
../../gcc/fortran/interface.cc:619
0x7e032e gfc_type_is_extension_of(gfc_symbol*, gfc_symbol*)
../../gcc/fortran/symbol.cc:5116
0x7cfd01 gfc_simplify_extends_type_of(gfc_expr*, gfc_expr*)
../../gcc/fortran/simplify.cc:3109
0x750296 do_simplify
../../gcc/fortran/intrinsic.cc:4670
0x75b25a gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.cc:5056
0x7b0068 resolve_unknown_f
../../gcc/fortran/resolve.cc:2990
0x7b0068 resolve_function
../../gcc/fortran/resolve.cc:3347
0x7b0068 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.cc:7187
0x740184 gfc_reduce_init_expr(gfc_expr*)
../../gcc/fortran/expr.cc:3163
0x76d538 gfc_match_stopcode
../../gcc/fortran/match.cc:3157
0x794051 match_word
../../gcc/fortran/parse.cc:67
0x7999ad decode_statement
../../gcc/fortran/parse.cc:561
0x799fca next_free
../../gcc/fortran/parse.cc:1397
0x799fca next_statement
../../gcc/fortran/parse.cc:1629
0x79b55b parse_spec
../../gcc/fortran/parse.cc:4168
0x79e6fc parse_progunit
../../gcc/fortran/parse.cc:6210
0x79fdc1 gfc_parse_file()
../../gcc/fortran/parse.cc:6755
0x7ee53f gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:229

[Bug fortran/106121] New: ICE in gfc_simplify_extends_type_of, at fortran/simplify.cc:3109

[gscfq--- via Gcc-bugs]

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

Bug ID: 106121
   Summary: ICE in gfc_simplify_extends_type_of, at
fortran/simplify.cc:3109
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :
(missing attribute allocatable or pointer)


$ cat z1.f90
program p
   type t
   end type
   type(t) :: x
   class(t) :: y
   print *, extends_type_of(x, y)
end


$ cat z2.f90
program p
   type t
   end type
   type(t) :: x
   class(t) :: y
   stop extends_type_of(x, y)
end


$ gfortran-13-20220626 -c z1.f90
z1.f90:5:16:

5 |class(t) :: y
  |1
Error: CLASS variable 'y' at (1) must be dummy, allocatable or pointer
(null):0: confused by earlier errors, bailing out


$ gfortran-13-20220626 -c z2.f90
f951: internal compiler error: Segmentation fault
0xcd816f crash_signal
../../gcc/toplev.cc:322
0x78d799 gfc_simplify_extends_type_of(gfc_expr*, gfc_expr*)
../../gcc/fortran/simplify.cc:3109
0x70e0b6 do_simplify
../../gcc/fortran/intrinsic.cc:4670
0x718fca gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.cc:5056
0x76db08 resolve_unknown_f
../../gcc/fortran/resolve.cc:2990
0x76db08 resolve_function
../../gcc/fortran/resolve.cc:3347
0x76db08 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.cc:7187
0x6fdfa4 gfc_reduce_init_expr(gfc_expr*)
../../gcc/fortran/expr.cc:3163
0x72b268 gfc_match_stopcode
../../gcc/fortran/match.cc:3157
0x751af1 match_word
../../gcc/fortran/parse.cc:67
0x75744d decode_statement
../../gcc/fortran/parse.cc:561
0x757a6a next_free
../../gcc/fortran/parse.cc:1397
0x757a6a next_statement
../../gcc/fortran/parse.cc:1629
0x758ffb parse_spec
../../gcc/fortran/parse.cc:4168
0x75c19c parse_progunit
../../gcc/fortran/parse.cc:6210
0x75d861 gfc_parse_file()
../../gcc/fortran/parse.cc:6755
0x7ab3ef gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:229

[Bug target/106101] [12/13 Regression] ICE in reg_bitfield_target_p

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

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

--- Comment #6 from Segher Boessenkool  ---
It looks like quite a few more backends use strict_low_part on random RTL,
which
is completely meaningless :-(

[Bug c++/65328] GCC perf issue when compiling templates - 120x slower than Clang

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Patrick Palka  ---
Should be fixed for GCC 13

[Bug ipa/106116] Missed optimization: in no_reorder-attributed functions, tail calls to the subsequent function could just be function-to-function fallthrough

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

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

--- Comment #3 from Andrew Pinski  ---
What I am saying is the cost for doing this optimization is higher than the
gain you would get.

[Bug ipa/106116] Missed optimization: in no_reorder-attributed functions, tail calls to the subsequent function could just be function-to-function fallthrough

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

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

--- Comment #2 from Andrew Pinski  ---
On most recent out of order cores, a unconditional jump is basically free
except for space. So I really doubt you would see a performance improvement in
most code on x86 cores; even on high performance armv8 cores you won't see any
either.

[Bug ipa/106116] Missed optimization: in no_reorder-attributed functions, tail calls to the subsequent function could just be function-to-function fallthrough

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug other/106120] New: [13 regression] g++.dg/warn/Wstringop-overflow-4.C fails since r13-1268-g8c99e307b20c50

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

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

Bug ID: 106120
   Summary: [13 regression] g++.dg/warn/Wstringop-overflow-4.C
fails since r13-1268-g8c99e307b20c50
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:8c99e307b20c502e55c425897fb3884ba8f05882, r13-1268-g8c99e307b20c50
make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}'
dg.exp=g++.dg/warn/Wstringop-overflow-4.C"
FAIL: g++.dg/warn/Wstringop-overflow-4.C  -std=gnu++98 (test for excess errors)
# of expected passes59
# of unexpected failures1


This is for 32 bits on a powerpc64 BE system.


Excess errors:
/home/seurer/gcc/git/gcc-trunk/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:144:3:
warning: 'void* __builtin_memcpy(void*, const void*, unsigned int)' writing 3
bytes into a region of size 0 [-Wstringop-overflow=]


commit 8c99e307b20c502e55c425897fb3884ba8f05882
Author: Aldy Hernandez 
Date:   Sat Jun 25 18:58:02 2022 -0400

Convert DOM to use Ranger rather than EVRP

[Bug middle-end/106030] [13 Regression] ice in emit_move_insn, at expr.cc:4026

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/106032] [10/11 Regression] wrong code at -Os and above on x86_64-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11/12/13 Regression]|[10/11 Regression] wrong
   |wrong code at -Os and above |code at -Os and above on
   |on x86_64-linux-gnu |x86_64-linux-gnu

--- Comment #13 from Jakub Jelinek  ---
Fixed for 12.2+ and 13+ so far.

[Bug rtl-optimization/106032] [10/11/12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:

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

commit r12-8523-g9e72a522dd9f835dd159fe3aff493eee001be0d4
Author: Jakub Jelinek 
Date:   Tue Jun 21 11:40:16 2022 +0200

ifcvt: Don't introduce trapping or faulting reads in noce_try_sign_mask
[PR106032]

noce_try_sign_mask as documented will optimize
  if (c < 0)
x = t;
  else
x = 0;
into x = (c >> bitsm1) & t;
The optimization is done if either t is unconditional
(e.g. for
  x = t;
  if (c >= 0)
x = 0;
) or if it is cheap.  We already check that t doesn't have side-effects,
but if t is conditional, we need to punt also if it may trap or fault,
as we make it unconditional.

I've briefly skimmed other noce_try* optimizations and didn't find one that
would suffer from the same problem.

2022-06-21  Jakub Jelinek  

PR rtl-optimization/106032
* ifcvt.cc (noce_try_sign_mask): Punt if !t_unconditional, and
t may_trap_or_fault_p, even if it is cheap.

* gcc.c-torture/execute/pr106032.c: New test.

(cherry picked from commit a0c30fe3b888f20215f3e040d21b62b603804ca9)

[Bug middle-end/106030] [13 Regression] ice in emit_move_insn, at expr.cc:4026

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

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

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

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

commit r12-8522-gd068623e5b109e635e2ec2acfcf15e7c50c7f15c
Author: Jakub Jelinek 
Date:   Tue Jun 21 11:38:59 2022 +0200

expand: Fix up expand_cond_expr_using_cmove [PR106030]

If expand_cond_expr_using_cmove can't find a cmove optab for a particular
mode, it tries to promote the mode and perform the cmove in the promoted
mode.

The testcase in the patch ICEs on arm because in that case we pass temp
which
has the promoted mode (SImode) as target to expand_operands where the
operands have the non-promoted mode (QImode).
Later on the function uses paradoxical subregs:
  if (GET_MODE (op1) != mode)
op1 = gen_lowpart (mode, op1);

  if (GET_MODE (op2) != mode)
op2 = gen_lowpart (mode, op2);
to change the operand modes.

The following patch fixes it by passing NULL_RTX as target if it has
promoted mode.

2022-06-21  Jakub Jelinek  

PR middle-end/106030
* expr.cc (expand_cond_expr_using_cmove): Pass NULL_RTX instead of
temp to expand_operands if mode has been promoted.

* gcc.c-torture/compile/pr106030.c: New test.

(cherry picked from commit 2df1df945fac85d7b3d084001414a66a2709d8fe)

[Bug c/106119] Bogus use-after-free warning triggered by optimizer

[tom.cosgrove at arm dot com via Gcc-bugs]

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

--- Comment #1 from Tom Cosgrove  ---
Note that the command lines just need -Wall, i.e.

gcc-12 $ gcc -O2 -Wall -o foo -c foo.c

[Bug libgomp/106045] Incorrect testcase in libgomp.c/target-31.c at -O0

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

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

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

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

commit r12-8521-gd67dfc5f80e537460ebf809758a0e673028ebad7
Author: Jakub Jelinek 
Date:   Tue Jun 21 17:51:08 2022 +0200

libgomp: Fix up target-31.c test [PR106045]

The i variable is used inside of the parallel in:
  #pragma omp simd safelen(32) private (v)
  for (i = 0; i < 64; i++)
{
  v = 3 * i;
  ll[i] = u1 + v * u2[0] + u2[1] + x + y[0] + y[1] + v + h[0] +
u3[i];
}
where i is predetermined linear (so while inside of the body
it is safe, private per SIMD lane var) the final value is written to
the shared variable, and in:
  for (i = 0; i < 64; i++)
if (ll[i] != u1 + 3 * i * u2[0] + u2[1] + x + y[0] + y[1] + 3 * i +
13 + 14 + i)
  #pragma omp atomic write
err = 1;
which is a normal loop and so it isn't in any way privatized there.
So we have a data race, fixed by adding private (i) clause to the
parallel.

2022-06-21  Jakub Jelinek  
Paul Iannetta  

PR libgomp/106045
* testsuite/libgomp.c/target-31.c: Add private (i) clause.

(cherry picked from commit 85d613da341b76308edea48359a5dbc7061937c4)

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

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

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

--- Comment #4 from Lewis Hyatt  ---
(In reply to Lewis Hyatt from comment #3)
> I can look into that.

Patch waiting for review here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596660.html

[Bug c/106117] Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

[rjmccall at gmail dot com via Gcc-bugs]

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

John McCall  changed:

   What|Removed |Added

 CC||rjmccall at gmail dot com

--- Comment #1 from John McCall  ---
To clarify one point: Clang plans to use excess precision arithmetic as the
default for _Float16 when AVX512-FP16 isn't available, following the C
standard's rules, i.e. `-fexcess-precision=standard`.  We'd like to offer users
a way to disable this and force operation-by-operation translation, but as far
as we can tell, there isn't a way to request this in GCC today.  It feels like
`-fexcess-precision=none` (or some similar spelling) would be the most
appropriate way to do this, since of course this conflicts with other values of
`-fexcess-precision`.

Since GCC originated `-fexcess-precision`, we're trying to being neighborly and
ask whether you have a problem with this extension.

[Bug fortran/103506] [10/11/12/13 Regression] ICE in gfc_free_namespace, at fortran/symbol.c:4039 since r10-2798-ge68a35ae4a65d2b3

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

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

--- Comment #4 from kargl at gcc dot gnu.org ---
A patch to address this issue was submitted 7 months ago.

[Bug fortran/104313] [10/11/12/13 Regression] ICE verify_gimple failed with -ff2c since r10-2279-ge0af8f52b10385d8

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #6 from Steve Kargl  ---
On Tue, Jun 28, 2022 at 10:47:54AM +, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104313
> 
> Jakub Jelinek  changed:
> 
>What|Removed |Added
> 
>Target Milestone|10.4|10.5
> 
> --- Comment #5 from Jakub Jelinek  ---
> GCC 10.4 is being released, retargeting bugs to GCC 10.5.
> 

The patch in comment 2 fixes the issue.  It was submitted
13 hours after the initial report.

[Bug target/106101] [12/13 Regression] ICE in reg_bitfield_target_p

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

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

--- Comment #5 from Segher Boessenkool  ---
Thanks for tracking this down!

Interesting it survived so long.  We could use some RTL checking on this :-)

[Bug fortran/103414] [10/11/12/13 Regression] [PDT] ICE in gfc_free_actual_arglist, at fortran/expr.c:547 since r10-2083-g8dc63166e0b85954

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

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

--- Comment #8 from kargl at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #7)
> GCC 10.4 is being released, retargeting bugs to GCC 10.5.

That's a shame. The patches in comments in 2 and 4 where
submitted over 8 months ago.

[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954

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

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

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #4)
> GCC 10.4 is being released, retargeting bugs to GCC 10.5.

That's a shame.  The patch in comment 1 and the correction
noted in comment 2 where submitted 8 months ago.

[Bug tree-optimization/106114] [13 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

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

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

Aldy Hernandez  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||law at gcc dot gnu.org

--- Comment #5 from Aldy Hernandez  ---
I think this is fold_using_range getting confused with DOM changing the IL from
under it.

fold_using_range::relation_fold_and_or() is (incorrectly) folding the final
conditional as always true:

   [local count: 79134772]:
  a.0_1 = a;
  b = a.0_1;
  a.1_15 = a.0_1;
  _16 = a.0_1 < -117;
  _17 = a.0_1 >= -83;
  _18 = _16 | _17;
  if (_18 != 0)

But the IL on entry to DOM is actually:

   [local count: 79134772]:
  a.0_1 = a;
  b = a.0_1;
  a.1_15 = a;
  _16 = a.1_15 < -117;
  _17 = a.1_15 >= -83;
  _18 = _16 | _17;
  if (_18 != 0)

DOM replaced a.1_15=a with a.1_15=a.0_1:

Optimizing statement a.1_15 = a;
LKUP STMT a.1_15 = a with .MEM_7
FIND: a.0_1
  Replaced redundant expr 'a' with 'a.0_1'


...and then cproped the a.1_15 into the uses:

Optimizing statement _16 = a.1_15 < -117;
  Replaced 'a.1_15' with variable 'a.0_1'
Optimizing statement _17 = a.1_15 >= -83;
  Replaced 'a.1_15' with variable 'a.0_1'

By the time we get to the conditional, the ranger thinks it can fold the
conditional:

Optimizing statement if (_18 != 0)
  Relation adjustment: _16  and _17  combine to produce [irange] _Bool [1, 1]
  Replaced '_18' with constant '1'

Since the IL on entry to DOM is different than what evrp would see, I added an
evrp instance before DOM and ran it with -O2 -fno-tree-dominator-opts, but evrp
does not fold the conditional.  So this is something particular to what we're
doing in DOM.

In this hacked up evrp instance I see ssa1_dep2 and ssa2_dep2 are both NULL
when we query "_18 = _16 | _17", so we never fold the conditional:

  // Both names will need to have 2 direct dependencies.
  tree ssa1_dep2 = src.gori ()->depend2 (ssa1);
  tree ssa2_dep2 = src.gori ()->depend2 (ssa2);
  if (!ssa1_dep2 || !ssa2_dep2)
return;

  (gdb) p ssa1_dep2
  $35 = 
  (gdb) p ssa2_dep2
  $36 = 

OTOH, in DOM we have:

(gdb) p debug(ssa1_dep2)
a.0_1
$33 = void
(gdb) p debug(ssa2_dep2)
a.0_1
$34 = void
(gdb) 

So the dependencies in DOM's use of ranger in flight are different than what
evrp would see.

Andrew, would the changed IL cause the folding problem above?

[Bug lto/106118] lto-plugin/lto-plugin.c: -pthread not passed to AM_LDFLAGS

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-06-28
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Thanks for the fix, please send the patch to gcc-patches mailing list.

[Bug ipa/101279] Function attributes often block inlining

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #6 from rguenther at suse dot de  ---
> Am 28.06.2022 um 14:53 schrieb david at westcontrol dot com 
> :
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101279
> 
> --- Comment #5 from David Brown  ---
> (In reply to Richard Biener from comment #4)
>> (In reply to frankhb1989 from comment #3)
>>> There is a more specific instance here: can_inline_edge_by_limits_p in
>>> ipa-inline.cc treats flags and "optimize" attributes differently.
>> 
>> A bit up there's a blacklist we maintain where inlining is not OK because it
>> results in semantic differences.
>> 
>> Generally we it's hard to second-guess the users intention when looking
>> at an inline edge with different optimization settings of caller and callee.
>> For C++ comdats there might be even multiple variants with different
>> optimization level (but we only keep one, special-casing this a bit).
> 
> I appreciate the "err on the side of caution" attitude.  Perhaps there could 
> be
> an extra "I know what I'm doing" attribute that lets you override the
> blacklisting in a particular case.  This would only really make sense in cases
> where the attribute can be attached to the expressions and statements within
> the function (I think "-fwrapv" would be in this category).  In cases where
> this is not possible, an error or warning message would be in order as the
> compiler can't do what the programmer is asking.

Can you provide a specific example that you would allow this way?


> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug c++/106072] Bogus -Wnonnull warning breaks rust bootstrap

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

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

--- Comment #2 from Rainer Orth  ---
Created attachment 53215
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53215=edit
Original preprocessed testcase.

[Bug c++/106111] -Wc++20-compat doesn't warn about using `requires` as an identifier

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/106111] -Wc++20-compat doesn't warn about using `requires` as an identifier

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

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

--- Comment #4 from Marek Polacek  ---
And for consteval the problem is likely that enum rid has:

 273   RID_FIRST_CXX20 = RID_CONSTINIT,
 274   RID_LAST_CXX20 = RID_CONSTINIT,

Oops.

[Bug c/106119] New: Bogus use-after-free warning triggered by optimizer

[tom.cosgrove at arm dot com via Gcc-bugs]

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

Bug ID: 106119
   Summary: Bogus use-after-free warning triggered by optimizer
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom.cosgrove at arm dot com
  Target Milestone: ---

There are a number of bug reports related to -Wuse-after-free - it's not clear
to me if our particular issue has already been captured, so please do close as
duplicate if it has (it seems that the optimiser is moving code around, so
could potentially be a duplicate of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104215).

Assuming not a duplicate, this should probably be linked to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104075.


Our self-test code checks to see if two consecutive calloc() calls return the
same value, by storing the pointer value in a uintptr_t integer and comparing
against this value later. When we compile with optimisation (we don't see the
problem with -O0) and with an if-statement later in the code, we get a spurious
use-after-free warning.

We don't get this warning at -O0, or if we remove the if-statement.

We have also confirmed that if we reorder the assignment to the uintptr_t and
the call to free() we consistently DO get the use-after-free warning (as
expected) regardless of optimisation level.


gcc-12 $ uname -a
Linux e120653 5.17.15-1-MANJARO #1 SMP PREEMPT Wed Jun 15 07:09:31 UTC 2022
x86_64 GNU/Linux

gcc-12 $ gcc --version
gcc (GCC) 12.1.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

gcc-12 $ cat foo.c
#include 
#include 
#include 

void calloc_self_test( __attribute__ ((unused)) int verbose )
{
void *buffer1 = calloc( 1, 1 );
uintptr_t old_buffer1 = (uintptr_t) buffer1;
free( buffer1 );
buffer1 = calloc( 1, 1 );
int same = ( old_buffer1 == (uintptr_t) buffer1 );
if( verbose )
printf( "  CALLOC(1 again): passed (%s address)\n",
same ? "same" : "different" );
free( buffer1 );
}

No warning at -O0:

gcc-12 $ gcc -O0 -Wall -Wextra -Wformat=2 -Wno-format-nonliteral -o foo -c
foo.c
gcc-12 $

But unexpected warning at -O2:

gcc-12 $ gcc -O2 -Wall -Wextra -Wformat=2 -Wno-format-nonliteral -o foo -c
foo.c
foo.c: In function ‘calloc_self_test’:
foo.c:8:15: warning: pointer ‘buffer1’ may be used after ‘free’
[-Wuse-after-free]
8 | uintptr_t old_buffer1 = (uintptr_t) buffer1;
  |   ^~~
foo.c:9:5: note: call to ‘free’ here
9 | free( buffer1 );
  | ^~~

Removing the if-statement quashes the warning:

gcc-12 $ perl -ni -e 'print unless /if.*verbose/' foo.c
gcc-12 $ cat foo.c
#include 
#include 
#include 

void calloc_self_test( __attribute__ ((unused)) int verbose )
{
void *buffer1 = calloc( 1, 1 );
uintptr_t old_buffer1 = (uintptr_t) buffer1;
free( buffer1 );
buffer1 = calloc( 1, 1 );
int same = ( old_buffer1 == (uintptr_t) buffer1 );
printf( "  CALLOC(1 again): passed (%s address)\n",
same ? "same" : "different" );
free( buffer1 );
}

gcc-12 $ gcc -O0 -Wall -Wextra -Wformat=2 -Wno-format-nonliteral -o foo -c
foo.c
gcc-12 $ gcc -O2 -Wall -Wextra -Wformat=2 -Wno-format-nonliteral -o foo -c
foo.c
gcc-12 $


Checking that we always get the error when we swap the assignment and free()
statements:

gcc-12 $ cat bar.c
#include 
#include 
#include 

void calloc_self_test( __attribute__ ((unused)) int verbose )
{
void *buffer1 = calloc( 1, 1 );
free( buffer1 );
uintptr_t old_buffer1 = (uintptr_t) buffer1;
buffer1 = calloc( 1, 1 );
int same = ( old_buffer1 == (uintptr_t) buffer1 );
if( verbose )
printf( "  CALLOC(1 again): passed (%s address)\n",
same ? "same" : "different" );
free( buffer1 );
}

gcc-12 $ gcc -O0 -Wall -Wextra -Wformat=2 -Wno-format-nonliteral -o bar -c
bar.c
bar.c: In function ‘calloc_self_test’:
bar.c:9:15: warning: pointer ‘buffer1’ used after ‘free’ [-Wuse-after-free]
9 | uintptr_t old_buffer1 = (uintptr_t) buffer1;
  |   ^~~
bar.c:8:5: note: call to ‘free’ here
8 | free( buffer1 );
  | ^~~

gcc-12 $ gcc -O2 -Wall -Wextra -Wformat=2 -Wno-format-nonliteral -o bar -c
bar.c
bar.c: In function ‘calloc_self_test’:
bar.c:9:15: warning: pointer ‘buffer1’ used after ‘free’ [-Wuse-after-free]
9 | uintptr_t old_buffer1 = (uintptr_t) buffer1;
  |   ^~~
bar.c:8:5: note: call to ‘free’ here
8 | free( buffer1 );

and we still get the warning (as we would hope) without the if-statement:

gcc-12 $ perl -ni -e 'print unless /if.*verbose/' bar.c
gcc-12 $ cat bar.c
#include 
#include 
#include 

void 

[Bug target/106091] [11/12/13 Regression] during RTL pass: swaps ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 69 with -fnon-call-exceptions

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

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

Kewen Lin  changed:

   What|Removed |Added

 CC||linkw at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2022-06-28

--- Comment #2 from Kewen Lin  ---
Confirmed, thanks for reporting.

It needs explicit option -mcpu=power8 if the default cpu type is some else.

It looks pass swaps doesn't copy REG_NOTES when replacing insns.

[Bug target/106113] wrong codegen for _mm_[u]comineq_{ss,sd} and need to return PF result.

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

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

--- Comment #2 from Jakub Jelinek  ---
Note, for -ffast-math we certainly should keep generating what we have been as
NaN as operand is not valid in that case.

[Bug ipa/101279] Function attributes often block inlining

[david at westcontrol dot com via Gcc-bugs]

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

--- Comment #7 from David Brown  ---
(In reply to rguent...@suse.de from comment #6)
> > Am 28.06.2022 um 14:53 schrieb david at westcontrol dot com 
> > :
> > 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101279
> > 
> > --- Comment #5 from David Brown  ---
> > (In reply to Richard Biener from comment #4)
> >> (In reply to frankhb1989 from comment #3)
> >>> There is a more specific instance here: can_inline_edge_by_limits_p in
> >>> ipa-inline.cc treats flags and "optimize" attributes differently.
> >> 
> >> A bit up there's a blacklist we maintain where inlining is not OK because 
> >> it
> >> results in semantic differences.
> >> 
> >> Generally we it's hard to second-guess the users intention when looking
> >> at an inline edge with different optimization settings of caller and 
> >> callee.
> >> For C++ comdats there might be even multiple variants with different
> >> optimization level (but we only keep one, special-casing this a bit).
> > 
> > I appreciate the "err on the side of caution" attitude.  Perhaps there 
> > could be
> > an extra "I know what I'm doing" attribute that lets you override the
> > blacklisting in a particular case.  This would only really make sense in 
> > cases
> > where the attribute can be attached to the expressions and statements within
> > the function (I think "-fwrapv" would be in this category).  In cases where
> > this is not possible, an error or warning message would be in order as the
> > compiler can't do what the programmer is asking.
> 
> Can you provide a specific example that you would allow this way?
> 
> 

I'd go back to my original example :


  __attribute__((optimize("-fwrapv")))
  static inline int wrapped_add(int a, int b) {
  return a + b;
  }

  int foo(int x, int y, int z) {
  return wrapped_add(wrapped_add(x, y), z);
  }

If you want to disable inlining of "wrapped_add" due to the change in the
semantics of integer arithmetic, that's fair enough.  But if I /really/ want
inlining, and write something like :

  __attribute__((optimize("-fwrapv"), always_inline))
  static inline int wrapped_add(int a, int b) {
  return a + b;
  }

then I want the code treated as :

  return (__wrapping_int) a + (__wrapping_int) b;

or

  return __wrapping_add_int(a, b);

If the way gcc marks and handles "-fwrapv" arithmetic does not support
something like that, which would allow inline mixing with other code, then that
would result in a compiler warning or error message.


It might be best to have a new attribute name here rather than using
"always_inline" - I have not thought through the consequences.

It might also be that if the compiler can be changed to support inlining of a
given optimisation attribute, then the attribute in question can be whitelisted
for inlining for everyone.  I suppose what I am saying is that if the compiler
can't be sure that inlining is safe, then it could be cautious by default while
letting the programmer override that caution explicitly.

[Bug lto/106118] New: lto-plugin/lto-plugin.c: -pthread not passed to AM_LDFLAGS

[pexu--- via Gcc-bugs]

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

Bug ID: 106118
   Summary: lto-plugin/lto-plugin.c: -pthread not passed to
AM_LDFLAGS
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: p...@gcc-bugzilla.mail.kapsi.fi
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 53216
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53216=edit
move -pthread from LDFLAGS to AM_LDFLAGS (prior autoreconf)

Hi.

"lto-plugin: make claim_file_handler thread-safe" [1] uses LDFLAGS="-pthread"
at configure.ac.  Unfortunately, LDFLAGS is not passed from configure to the
Makefile recipe that links liblto_plugin.la.

Perhaps just move -pthread to AM_LDFLAGS at Makefile.in?  AC_CHECK_HEADER does
not use LDFLAGS anyway.  It is implicitly used by other checks but I wonder if
that just makes things more misleading (a missing pthread library, that is).

Also, it seems that pretty much every library has a different way of checking
and setting -pthread, -lpthread et. al.

[1]
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=2669cae081c852bc8bde1647d671aa66930cc556

[Bug c++/106072] Bogus -Wnonnull warning breaks rust bootstrap

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

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

--- Comment #1 from Rainer Orth  ---
While creduce produced a 198-byte file from the original 3.5 MB source which
still
shows the warning/error, it is correct in that case.

I'm attaching the original preprocessed source instead.  It shows the error
with

cc1plus -fpreprocessed -quiet -mcpu=v9 -O2 -Wall -Wno-narrowing
-Wno-error=format-diag -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -Wno-unused-parameter -std=c++11

on SPARC.

[Bug tree-optimization/106114] [13 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
Another test (-O2):

int printf(const char *, ...);
int a, b = 1041281974;
unsigned short c;
int main()
{
  int d, e = b;
  b = ~-~a;
  a = c = -~b;
  if (c < 65529) {
printf("%d\n", d);
e = 0;
  }
  if (b)
d = a;
  if (((e > 1041281974) && d) || e < 1041281974)
printf("%d\n", c);
  return 0;
}

[Bug c/106117] New: Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

[Zahira.Ammarguellat at intel dot com via Gcc-bugs]

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

Bug ID: 106117
   Summary: Use of option -fexcess-precision for
operation-by-operation emulation for _Float16
arithmetics.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Zahira.Ammarguellat at intel dot com
  Target Milestone: ---

We are adding in Clang the support of '_Float16' on X86 targets with SSE2
enabled. 
When the target supports AVX512-FP16, Clang performs '_Float16' arithmetic
using native support. Otherwise, '_Float16' arithmetic is performed by
promoting to 'float', then performing the operation, and finally truncating to
'_Float16'. 

This operation-by-operation emulation is the default in Clang, and is in line
with the C standard's rules for excess precision arithmetic. We would like to
adopt the option '-fexcess-precision' to request this operation-by-operation
emulation by setting '-fexcess-precision=none'. 
First are there any objections in using this option to request
operation-by-operation emulation for '_Float16' arithmetic? 
Second is 'none' the right value to use?
Thanks.

[Bug tree-optimization/106115] wrong code at -O2 and -O3 on x86_64-linux-gnu

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Also started with r13-1268-g8c99e307b20c502e so I think it's a dup of PR
106114.

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

[Bug target/106096] [13 regression] ICE building stage 2 libgcc on loongarch64-linux-gnu because stage 2 gcc is miscompiled

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

Xi Ruoyao  changed:

   What|Removed |Added

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

--- Comment #13 from Xi Ruoyao  ---
Fixed for trunk and gcc-12.

[Bug ipa/106116] Missed optimization: in no_reorder-attributed functions, tail calls to the subsequent function could just be function-to-function fallthrough

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
  Component|c   |ipa
   Keywords||missed-optimization

--- Comment #1 from Richard Biener  ---
This might be doable with multiple entries (thunk-like), but it's not as simple
as falling through with no_reorder (that might be an assembler optimization)

[Bug c++/106111] -Wc++20-compat doesn't warn about using `requires` as an identifier

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2022-06-28
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #3 from Marek Polacek  ---
Confirmed, same problem with e.g.

int concept;

The problem is that cp_lexer_get_preprocessor_token has

  906   if (warn_cxx20_compat
  907   && C_RID_CODE (token->u.value) >= RID_FIRST_CXX20
  908   && C_RID_CODE (token->u.value) <= RID_LAST_CXX20)

but requires/concept aren't in the C++20 keywords, they are marked as
D_CXX_CONCEPTS_FLAGS instead.

[Bug target/106096] [13 regression] ICE building stage 2 libgcc on loongarch64-linux-gnu because stage 2 gcc is miscompiled

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Xi Ruoyao :

https://gcc.gnu.org/g:020b7d98589bbc928b5a66b1ed56b42af8791355

commit r13-1319-g020b7d98589bbc928b5a66b1ed56b42af8791355
Author: Xi Ruoyao 
Date:   Tue Jun 28 16:00:14 2022 +0800

loongarch: exclude LARCH_PROLOGUE_TEMP from SIBCALL_REGS [PR 106096]

The epilogue may clobber LARCH_PROLOGUE_TEMP ($r13/$t1), so it cannot be
used for sibcalls.

gcc/ChangeLog:

PR target/106096
* config/loongarch/loongarch.h (REG_CLASS_CONTENTS): Exclude
$r13 from SIBCALL_REGS.
* config/loongarch/loongarch.cc (loongarch_regno_to_class):
Change $r13 to JIRL_REGS.

gcc/testsuite/ChangeLog:

PR target/106096
* g++.target/loongarch/loongarch.exp: New test support file.
* g++.target/loongarch/pr106096.C: New test.

[Bug rtl-optimization/106032] [10/11/12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|10.4|10.5

--- Comment #11 from Jakub Jelinek  ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug c++/105996] [10/11/12/13 Regression] reinterpret_cast in constexpr failure creating a pair with a function pointer of class parent

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|10.4|10.5

--- Comment #4 from Jakub Jelinek  ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug tree-optimization/106114] [13 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Version|unknown |13.0
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |13.0

[Bug rtl-optimization/105988] [10/11/12/13 Regression] ICE in linemap_ordinary_map_lookup, at libcpp/line-map.cc:1064 since r6-4873-gebedc9a3414d8422

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|10.4|10.5

--- Comment #3 from Jakub Jelinek  ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug c/106116] New: Missed optimization: in no_reorder-attributed functions, tail calls to the subsequent function could just be function-to-function fallthrough

[pskocik at gmail dot com via Gcc-bugs]

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

Bug ID: 106116
   Summary: Missed optimization: in no_reorder-attributed
functions, tail calls to the subsequent function could
just be function-to-function fallthrough
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pskocik at gmail dot com
  Target Milestone: ---

Example:

__attribute((noinline,no_reorder))
int fnWithExplicitArg(int ExplicitArg);

__attribute((noinline,no_reorder))
int fnWithDefaultArg(void){ return fnWithExplicitArg(42); }

int fnWithExplicitArg(int ExplicitArg){
int useArg(int);
return 12+useArg(ExplicitArg);
}

Generated fnWithDefaultArg:

fnWithDefaultArg:
mov edi, 42
jmp fnWithExplicitArg
fnWithExplicitArg:
//...

Desired fnWithDefaultArg


fnWithDefaultArg:
mov edi, 42
//fallthru
fnWithExplicitArg:
//...

https://gcc.godbolt.org/z/Ph3onxoh9

[Bug target/106113] wrong codegen for _mm_[u]comineq_{ss,sd} and need to return PF result.

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Has the definition of these intrinsics changed over time?
Because e.g. clang up to 3.8.1 also matches gcc behavior of testing LTGT for
the *neq* and UNEQ for *eq* intrinsics.
Note, changing all UNEQ to EQ and LTGT to NE in the COMI section of
i386-builtin.def doesn't do the trick.

[Bug c++/105809] [10/11/12/13 Regression] __PRETTY_FUNCTION__ in constexpr in function vs NSDMI

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|10.4|10.5

--- Comment #5 from Jakub Jelinek  ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug tree-optimization/106114] [13 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

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

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

--- Comment #3 from Marek Polacek  ---
*** Bug 106115 has been marked as a duplicate of this bug. ***

[Bug c++/105737] [10/11 only] Incorrect evaluation order in new expression

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|10.4|10.5

--- Comment #4 from Jakub Jelinek  ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug ipa/101279] Function attributes often block inlining

[david at westcontrol dot com via Gcc-bugs]

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

--- Comment #5 from David Brown  ---
(In reply to Richard Biener from comment #4)
> (In reply to frankhb1989 from comment #3)
> > There is a more specific instance here: can_inline_edge_by_limits_p in
> > ipa-inline.cc treats flags and "optimize" attributes differently.
> 
> A bit up there's a blacklist we maintain where inlining is not OK because it
> results in semantic differences.
> 
> Generally we it's hard to second-guess the users intention when looking
> at an inline edge with different optimization settings of caller and callee.
> For C++ comdats there might be even multiple variants with different
> optimization level (but we only keep one, special-casing this a bit).

I appreciate the "err on the side of caution" attitude.  Perhaps there could be
an extra "I know what I'm doing" attribute that lets you override the
blacklisting in a particular case.  This would only really make sense in cases
where the attribute can be attached to the expressions and statements within
the function (I think "-fwrapv" would be in this category).  In cases where
this is not possible, an error or warning message would be in order as the
compiler can't do what the programmer is asking.

[Bug debug/105653] [10/11/12/13 Regression] '-fcompare-debug' failure w/ -O2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|10.4|10.5

--- Comment #1 from Jakub Jelinek  ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug middle-end/105604] [10/11 Regression] ICE: in tree_to_shwi with vla in struct and sprintf

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|10.4|10.5

--- Comment #8 from Jakub Jelinek  ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug debug/105415] [10/11/12 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2 since r7-4900-g59ec925b1199f9

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|10.4|10.5

--- Comment #10 from Jakub Jelinek  ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug ipa/101279] Function attributes often block inlining

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

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

--- Comment #4 from Richard Biener  ---
(In reply to frankhb1989 from comment #3)
> There is a more specific instance here: can_inline_edge_by_limits_p in
> ipa-inline.cc treats flags and "optimize" attributes differently.

A bit up there's a blacklist we maintain where inlining is not OK because it
results in semantic differences.

Generally we it's hard to second-guess the users intention when looking
at an inline edge with different optimization settings of caller and callee.
For C++ comdats there might be even multiple variants with different
optimization level (but we only keep one, special-casing this a bit).

[Bug middle-end/105263] [10 Regression] ICE: gimple check: expected gimple_assign(error_mark), have gimple_nop() in gimple_assign_rhs1, at gimple.h:2655 with _Decimal64 -ffast-math since r7-950-g8a85c

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|10.4|10.5

--- Comment #7 from Jakub Jelinek  ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug ipa/101279] Function attributes often block inlining

[frankhb1989 at gmail dot com via Gcc-bugs]

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

frankhb1989 at gmail dot com changed:

   What|Removed |Added

 CC||frankhb1989 at gmail dot com

--- Comment #3 from frankhb1989 at gmail dot com ---
There is a more specific instance here: can_inline_edge_by_limits_p in
ipa-inline.cc treats flags and "optimize" attributes differently.

While it is reasonable to reject inlining for semantic mismatch from different
global flags, "opts_for_fn (caller->decl) != opts_for_fn (callee->decl)" looks
quite unnatural. In practice it means missing of valid opportunity of inlining,
unless the programmer knows what should go under the hood and decides to
propagate "always_inline" plus the "optimize" attributes manually in the
declarations of *all* callees (including lambda-expressions in C++),
*recursively*. Adding "__attribute__((flatten))" can be a workaround sometimes,
but it does not always generated desired code, and often too slow.

This is somewhat worse than the case of "-fwrapv" whose semantic is easier to
reason in the generated code.

[Bug tree-optimization/106112] [10/11/12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu since r10-2711-g3ed01d5408045d80

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
   [local count: 1073741824]:
  e.0_1 = e;
  _2 = e.0_1 | 4294967292;
  e = _2;
  d.1_3 = d;
  _4 = (long unsigned int) d.1_3;
-  # RANGE [2147483647, 6442450942] NONZERO 8589934591
+  # RANGE ~[2147483647, 18446744071562067967]
  _10 = _4 + 4294967295;
  _7 = _10 - _2;
  _8 = 18446744073709551615 % _7;
  _9 = (int) _8;
  c = _9;
  _11 = 18446744073709551614 - _2;
-  _13 = d.1_3 + -1;
-  # RANGE ~[2147483647, 18446744071562067967]
-  _14 = (long unsigned int) _13;
-  _15 = _11 % _14;
+  _15 = _11 % _10;

is the key change, replacing (unsigned long)(intvar + -1) with (unsigned
long)intvar + 4294967295

It looks like

  /* For constants simply extend it.  */
  if (TREE_CODE (op) == INTEGER_CST)
return wide_int_to_tree (wide_type, wi::to_wide (op));

doesn't sign-extend the -1 from int to unsigned log.  Using wi::to_widest
does and fixes the testcase.

[Bug c++/105228] [10/11/12/13 Regression] ICE tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in decl_anon_ns_mem_p, at cp/tree.cc:3826 since r7-755-g23cb72663051cd

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|10.4|10.5

--- Comment #4 from Jakub Jelinek  ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug libstdc++/103501] associative containers left invalid after allocator-extended move construction

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|10.5|10.4

[Bug tree-optimization/106114] [13 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||amacleod at redhat dot com,
   ||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Summary|wrong code at -O1, -O2 and  |[13 Regression] wrong code
   |-O3 on x86_64-linux-gnu |at -O1, -O2 and -O3 on
   ||x86_64-linux-gnu since
   ||r13-1268-g8c99e307b20c502e
   Last reconfirmed||2022-06-28

--- Comment #2 from Martin Liška  ---
Started with r13-1268-g8c99e307b20c502e.