[Bug libbacktrace/97082] new test 'mtest' fails for Mach-O/Darwin.

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

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

--- Comment #3 from Iain Sandoe  ---
(In reply to Ian Lance Taylor from comment #2)
> Does btest pass?  It's hard to see why mtest would fail if btest passes.

current results [darwin16, darwin19] are:

PASS: allocfail.sh
PASS: test_elf_32
PASS: test_elf_64
PASS: test_macho
PASS: test_xcoff_32
PASS: test_xcoff_64
PASS: test_pecoff
PASS: test_unknown
PASS: unittest
PASS: unittest_alloc
FAIL: btest
FAIL: btest_alloc
PASS: stest
PASS: stest_alloc
PASS: edtest
PASS: edtest_alloc
PASS: ttest
PASS: ttest_alloc
FAIL: dwarf5
FAIL: dwarf5_alloc
FAIL: mtest

the reason for btest* and mtest fails is unknown at present.

Most likely the fails for dwarf5 would relate to whether dsymutil is yet
'dwarf5 aware' .. I believe the debug default for the system toolchain(s) is
dwarf4.

Using the most recent command line tools (XC12 beta5) on darwin19, dsymutil
actually aborts with the dwarf5 input.

[Bug middle-end/64928] [8/9/10/11 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs

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

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

--- Comment #31 from Richard Biener  ---
(In reply to lucier from comment #30)
> I'm coming back to this project.
> 
> I naively thought "Well, I don't need arc profiling, I'll just set
> -ftest-coverage without -fprofile-arcs" but it appears that I can't do that,
> the gcda files are generated by -fprofile-arcs.
> 
> It seems to me that test coverage could be implemented simply by
> instrumenting each basic block in an algorithm that's linear in the number
> of basic blocks.  Is it possible to do this?
> 
> Brad

I don't think the instrumentation itself is the problem - it's already
doing better than one counter per block.  It's simply that the large
source runs into multiple non-linearities in core pieces of the compiler
that cannot be turned off ...

[Bug tree-optimization/97236] [10/11 Regression] g:e93428a8b056aed83a7678 triggers vlc miscompile

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |10.3
 CC||doko at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Target||x86_64-*-*

[Bug tree-optimization/97236] New: [10/11 Regression] g:e93428a8b056aed83a7678 triggers vlc miscompile

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

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

Bug ID: 97236
   Summary: [10/11 Regression] g:e93428a8b056aed83a7678 triggers
vlc miscompile
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971027

No testcase or confirmation yet.

[Bug tree-optimization/97228] [11 regression] New ICEs on arm since r11-3426 g:10843f8303509fcba880c6c05c08e4b4ccd24f36

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |11.0
   Last reconfirmed||2020-09-29

--- Comment #2 from Richard Biener  ---
I will have a look, hopefully I can reproduce ...

[Bug ipa/97235] [11 Regression] ICE in duplicate, at ipa-prop.c:4251

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
   Priority|P3  |P1
   Keywords|ice-on-invalid-code |ice-on-valid-code
Summary|ICE in duplicate, at|[11 Regression] ICE in
   |ipa-prop.c:4251 |duplicate, at
   ||ipa-prop.c:4251
 CC||hubicka at gcc dot gnu.org

[Bug preprocessor/96952] __builtin_thread_pointer support cannot be probed

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-09-29
 Ever confirmed|0   |1
 CC||ebotcazou at gcc dot gnu.org

--- Comment #4 from Eric Botcazou  ---
What about detecting the support at configure time and defining a macro during
the compilation?  Everyone has been doing this for more that 3 decades...

[Bug tree-optimization/96979] [9/10/11 Regression] Switch with case values derived from constexpr function takes unreasonable time to compile

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Martin Liska :

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

commit r11-3519-ge46858e445d35ca4a7df1996186fe884879b
Author: Martin Liska 
Date:   Thu Sep 24 13:34:13 2020 +0200

switch conversion: make a rapid speed up

gcc/ChangeLog:

PR tree-optimization/96979
* tree-switch-conversion.c (jump_table_cluster::can_be_handled):
Make a fast bail out.
(bit_test_cluster::can_be_handled): Likewise here.
* tree-switch-conversion.h (get_range): Use wi::to_wide instead
of a folding.

gcc/testsuite/ChangeLog:

PR tree-optimization/96979
* g++.dg/tree-ssa/pr96979.C: New test.

[Bug ipa/96394] [10/11 Regression] ICE in add_new_edges_to_heap, at ipa-inline.c:1746 (-O3 PGO)

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

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|hubicka at gcc dot gnu.org |jamborm at gcc dot 
gnu.org

--- Comment #16 from Martin Liška  ---
I believe Martin's patch is correct, I'll add a single file test-case for the
PR.

[Bug ipa/96394] [10/11 Regression] ICE in add_new_edges_to_heap, at ipa-inline.c:1746 (-O3 PGO)

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

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

--- Comment #17 from Martin Liška  ---
Created attachment 49283
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49283&action=edit
Single file test-case

[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor

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

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |11.0
 Status|NEW |ASSIGNED

--- Comment #4 from Martin Liška  ---
> 
> So according to your analysis would you classify this issue as a bug? Or is
> it an NBC change that was introduced?

Hard to say as C++ language introduces quite some boilerplate code that is not
explicitly written by a code author.
We identify these blocks in JSON format as exceptional, let me try to ignore
these when outputting '#'.

> 
> /Filip

[Bug tree-optimization/97228] [11 regression] New ICEs on arm since r11-3426 g:10843f8303509fcba880c6c05c08e4b4ccd24f36

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
So for

FAIL: gcc.dg/tree-ssa/ifc-cd.c (internal compiler error)

I see before ISEL changes like

@@ -180,16 +180,12 @@
   vect_b1_24.24_112 = vect_a1_16.12_97 + { 1, 1, 1, 1 };
   vect_b1_25.25_114 = vect_a1_16.12_97 + { 2, 2, 2, 2 };
   _118 = vect_a2_18.15_100 > { 0, 0, 0, 0 };
-  vect_patt_35.26_119 = VEC_COND_EXPR <_118, { 1, 1, 1, 1 }, { 0, 0, 0, 0 }>;
   _122 = vect__8.23_110 == { 0, 0, 0, 0 };
-  vect_patt_26.27_123 = VEC_COND_EXPR <_122, vect_patt_35.26_119, { 0, 0, 0, 0
}>;
-  _125 = vect_patt_26.27_123 != { 0, 0, 0, 0 };
+  _125 = VEC_COND_EXPR <_122, _118, { 0, 0, 0, 0 }>;
   vect_patt_44.28_126 = VEC_COND_EXPR <_125, vect_b1_25.25_114,
vect_b1_24.24_112>;
   vect_patt_37.31_138 = VEC_COND_EXPR <_125, vect_b1_24.24_112,
vect_a1_16.12_97>;
-  vect_patt_36.32_143 = VEC_COND_EXPR <_122, { 1, 1, 1, 1 }, { 0, 0, 0, 0 }>;
   _146 = vect_a3_20.18_103 < { 0, 0, 0, 0 };
-  vect_patt_72.33_147 = VEC_COND_EXPR <_146, vect_patt_36.32_143, { 0, 0, 0, 0
}>;
-  _149 = vect_patt_72.33_147 != { 0, 0, 0, 0 };
+  _149 = VEC_COND_EXPR <_146, _122, { 0, 0, 0, 0 }>;
   vect_patt_12.34_150 = VEC_COND_EXPR <_149, vect_patt_37.31_138,
vect_patt_44.28_126>;
   vect__ifc__73.35_154 = VEC_COND_EXPR <_122, vect_patt_12.34_150, { 0, 0, 0,
0 }>;
   MEM  [(int *)vectp_y.19_105] = vect__ifc__73.35_154;

where the difference is that we end up with a used vector comparison
that is not supported by the target (see also the other PR which Richard
has kindly taken).

Now, folding produces

   _118 = vect_a2_18.15_100 > { 0, 0, 0, 0 };
   _122 = vect__8.23_110 == { 0, 0, 0, 0 };
   _125 = VEC_COND_EXPR <_122, _118, { 0, 0, 0, 0 }>;

that's still not fully simplified, if written as bitwise ops it could be
as simple as

   _125 = _122 & _118;

but then this will probably make the issue worse ;)

I think this is a duplicate of that other bug.

[Bug ipa/97235] [11 Regression] ICE in duplicate, at ipa-prop.c:4251 since r11-3478-gada353b87909fd6c

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

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

--- Comment #1 from Martin Liška  ---
Confirmed, started with r11-3478-gada353b87909fd6c.

[Bug ipa/97235] [11 Regression] ICE in duplicate, at ipa-prop.c:4251 since r11-3478-gada353b87909fd6c

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
  Known to fail||11.0
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
Summary|[11 Regression] ICE in  |[11 Regression] ICE in
   |duplicate, at   |duplicate, at
   |ipa-prop.c:4251 |ipa-prop.c:4251 since
   ||r11-3478-gada353b87909fd6c
   Last reconfirmed||2020-09-29

[Bug c++/97237] New: [10/11 Regression] static_assert does not accept fpermissive code

[lutztonineubert at gmail dot com via Gcc-bugs]

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

Bug ID: 97237
   Summary: [10/11 Regression] static_assert does not accept
fpermissive code
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lutztonineubert at gmail dot com
  Target Milestone: ---

The following valid code:

  constexpr bool test() {
  auto i = 1 << 132;
  return true;
  }

  static_assert(test());

Build with GCC -fpermissive does compile in GCC 9 but not in 10/11:

> non-constant condition for static assertion

See: https://gcc.godbolt.org/z/r85zvP

But this code is valid in all versions:

  constexpr bool test() {
  auto i = 1 << 132;
  return true;
  }

  constexpr auto t = test();

  static_assert(t);

[Bug c++/97237] [10/11 Regression] static_assert does not accept fpermissive code

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to fail||10.2.0, 11.0
   Last reconfirmed||2020-09-29
 Status|UNCONFIRMED |NEW
 CC||jakub at gcc dot gnu.org
  Known to work||9.3.0
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Started to be rejected with r276622 "PR c++/91369 - Implement P0784R7:
constexpr new"

I'm not sure how much we care about accepting this.

[Bug c++/97237] [10/11 Regression] static_assert does not accept fpermissive code

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

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

--- Comment #2 from Jakub Jelinek  ---
It surprises me -fpermissive ever accepted such bogosities.
Also using -fpermissive with C++11 and later code is very weird, -fpermissive
is about letting some very old unmaintained code compile, but using that
together with C++11 features doesn't make sense.

[Bug c++/97237] [10/11 Regression] static_assert does not accept fpermissive code

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Toni Neubert from comment #0)
> The following valid code:

N.B. that's not valid at all. That's why you need to use -fpermissive to
compile it.


> But this code is valid in all versions:

No, it's invalid in all versions. It's only accepted with -fpermissive because
that means "please accept my broken code".

[Bug tree-optimization/97238] New: [11 Regression] ICE: SIGSEGV in gimple_assign_rhs_code (gimple.h:2797) with -O

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 97238
   Summary: [11 Regression] ICE: SIGSEGV in gimple_assign_rhs_code
(gimple.h:2797) with -O
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 49284
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49284&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c -wrapper valgrind,-q
==31466== Invalid read of size 2
==31466==at 0x750E2C: gimple_assign_rhs_code (gimple.h:2797)
==31466==by 0x750E2C: ovce_extract_ops(tree_node*, gassign**, bool*,
tree_node**, tree_node**, tree_node**, gassign**) [clone .part.0] [clone
.isra.0] [clone .cold] (tree-ssa-reassoc.c:3914)
==31466==by 0x119A493: ovce_extract_ops (tree-ssa-reassoc.c:3893)
==31466==by 0x119A493: optimize_vec_cond_expr (tree-ssa-reassoc.c:3970)
==31466==by 0x119A493: reassociate_bb(basic_block_def*)
(tree-ssa-reassoc.c:6465)
==31466==by 0x1199DE8: reassociate_bb(basic_block_def*)
(tree-ssa-reassoc.c:6606)
==31466==by 0x119C25E: do_reassoc (tree-ssa-reassoc.c:6718)
==31466==by 0x119C25E: execute_reassoc (tree-ssa-reassoc.c:6805)
==31466==by 0x119C25E: (anonymous
namespace)::pass_reassoc::execute(function*) (tree-ssa-reassoc.c:6844)
==31466==by 0xEFBDF7: execute_one_pass(opt_pass*) (passes.c:2509)
==31466==by 0xEFC76F: execute_pass_list_1(opt_pass*) (passes.c:2597)
==31466==by 0xEFC781: execute_pass_list_1(opt_pass*) (passes.c:2598)
==31466==by 0xEFC7A8: execute_pass_list(function*, opt_pass*)
(passes.c:2608)
==31466==by 0xB88B8B: cgraph_node::expand() (cgraphunit.c:2309)
==31466==by 0xB8A0EF: expand_all_functions (cgraphunit.c:2480)
==31466==by 0xB8A0EF: symbol_table::compile() [clone .part.0]
(cgraphunit.c:2843)
==31466==by 0xB8C522: compile (cgraphunit.c:2756)
==31466==by 0xB8C522: symbol_table::finalize_compilation_unit()
(cgraphunit.c:3021)
==31466==by 0xFF2AC9: compile_file() (toplev.c:484)
==31466==  Address 0x2 is not stack'd, malloc'd or (recently) free'd
==31466== 
during GIMPLE pass: reassoc
testcase.c: In function 'foo':
testcase.c:6:1: internal compiler error: Segmentation fault
6 | foo (void)
  | ^~~
0x4fd9cfa __libc_start_main
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
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-r11-3519-20200929092607-ge46858e4eee-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.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-r11-3519-20200929092607-ge46858e4eee-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200929 (experimental) (GCC)

[Bug tree-optimization/97239] New: [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 97239
   Summary: [11 Regression] ICE in gimple_expand_vec_cond_expr, at
gimple-isel.cc:201
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

gcc-11.0.0-alpha20200927 snapshot (g:e24817aa7a1c6d12039b486ab5ea9b5ee0a46cd4)
ICEs when compiling the following testcase w/ -O1:

int __attribute__ ((simd))
br (int cr)
{
  return -!!cr == !cr ? cr : 0;
}

% x86_64-pc-linux-gnu-gcc-11.0.0 -O1 -c gfa49kep.c
during GIMPLE pass: isel
gfa49kep.c: In function 'br.simdclone.7':
gfa49kep.c:2:1: internal compiler error: in gimple_expand_vec_cond_expr, at
gimple-isel.cc:201
2 | br (int cr)
  | ^~
0x70479d gimple_expand_vec_cond_expr
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200927/work/gcc-11-20200927/gcc/gimple-isel.cc:201
0xfecf68 gimple_expand_vec_exprs
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200927/work/gcc-11-20200927/gcc/gimple-isel.cc:247
0xfecf68 execute
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200927/work/gcc-11-20200927/gcc/gimple-isel.cc:300

[Bug analyzer/97240] New: Analyzer runs out of memory building C++ source

[andris.pavenis at iki dot fi via Gcc-bugs]

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

Bug ID: 97240
   Summary: Analyzer runs out of memory building C++ source
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: andris.pavenis at iki dot fi
  Target Milestone: ---

Created attachment 49285
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49285&action=edit
Preprocessed source

Compiling source with -fanalyzer incommand line causes gcc-10.2.0 run out of
memory.

g++ -c -v -std=c++17 -fanalyzer FastMathTest.ii 
Using built-in specs.
COLLECT_GCC=g++
Kohde: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Säiemalli: posix
Supported LTO compression algorithms: zlib zstd
gcc-versio 10.2.0 (GCC) 
COLLECT_GCC_OPTIONS='-c' '-v' '-std=c++17' '-fanalyzer' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/cc1plus -fpreprocessed FastMathTest.ii
-quiet -dumpbase FastMathTest.ii -mtune=generic -march=x86-64 -auxbase
FastMathTest -std=c++17 -version -fanalyzer -o /tmp/ccZO5KJm.s
GNU C++17 (GCC) versio 10.2.0 (x86_64-pc-linux-gnu)
käännetty GNU C:n versiolla 10.2.0, GMP version 6.2.0, MPFR version
4.1.0, MPC version 1.1.0, isl version isl-0.21-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++17 (GCC) versio 10.2.0 (x86_64-pc-linux-gnu)
käännetty GNU C:n versiolla 10.2.0, GMP version 6.2.0, MPFR version
4.1.0, MPC version 1.1.0, isl version isl-0.21-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2affcd71b0797e2421aae734ab600c81


Killed compile when memory use exceeded 70 GB.

[Bug fortran/97224] [8/9/10/11 Regression] SPECCPU 2006 Gamess fails to build after g:e5a76af3a2f3324efc60b4b2778ffb29d5c377bc

[drikosev at gmail dot com via Gcc-bugs]

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

Ev Drikos  changed:

   What|Removed |Added

 CC||drikosev at gmail dot com

--- Comment #7 from Ev Drikos  ---
Created attachment 49286
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49286&action=edit
regression example

Hello,

Indeed, the solution in PR/95614 has regressions,
because the attached program ie is rejected but it
was accepted by gcc-8.4

One could also exclude GSYM_SUBROUTINE & GSYM_FUNCTION
in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95614#c3
to have the attached program pr95614_aim2.f90 compile
smoothly. 

Hope this isn't out of topic,
Ev. Drikos

[Bug tree-optimization/97238] [11 Regression] ICE: SIGSEGV in gimple_assign_rhs_code (gimple.h:2797) with -O since r11-2577

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
   Last reconfirmed||2020-09-29
Summary|[11 Regression] ICE:|[11 Regression] ICE:
   |SIGSEGV in  |SIGSEGV in
   |gimple_assign_rhs_code  |gimple_assign_rhs_code
   |(gimple.h:2797) with -O |(gimple.h:2797) with -O
   ||since r11-2577
 Status|UNCONFIRMED |NEW
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r11-2577-g229752afe3156a3990dacaedb94c76846cebf132

[Bug tree-optimization/97239] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-09-29
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |11.0

--- Comment #1 from Richard Biener  ---
Confirmed.  Yet another VEC_COND_EXPR producing masks from masks.  This time:

201   gcc_assert (known_eq (GET_MODE_SIZE (mode), GET_MODE_SIZE
(cmp_op_mode))
202   && known_eq (GET_MODE_NUNITS (mode),
203GET_MODE_NUNITS (cmp_op_mode)));
(gdb) p mode
$1 = E_HImode
(gdb) p cmp_op_mode
$2 = E_V16SImode

(gdb) p debug_gimple_stmt (stmt)
mask__29.155_75 = VEC_COND_EXPR ;

  vector(16)  mask__2.147;
  vector(16)  mask__5.150;
  vector(16)  mask__29.155;

  mask__2.147_61 = simd.38_17(D) != { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0 };
  mask__5.150_67 = simd.38_17(D) == { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0 };
  mask__29.155_75 = VEC_COND_EXPR ;

so this is simd != 0 ? true : simd == 0 which is just 'true'?

That said, it's probably an uphill battle to try to combat all such
cases with more foldings ...

Rather we need to synthesize mask from mask VEC_COND via bit ops?

  mask__29.155_75 = mask__2.147_61 | (~mask__2.147_61 & mask__5.150_67);

in this case.

[Bug tree-optimization/97238] [11 Regression] ICE: SIGSEGV in gimple_assign_rhs_code (gimple.h:2797) with -O since r11-2577

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
3912  gassign *assign = dyn_cast (SSA_NAME_DEF_STMT (cond));
3913  if (stmt == NULL
3914  || TREE_CODE_CLASS (gimple_assign_rhs_code (assign)) !=
tcc_comparison)
3915return ERROR_MARK;

typo, should be assign == NULL.

[Bug tree-optimization/97238] [11 Regression] ICE: SIGSEGV in gimple_assign_rhs_code (gimple.h:2797) with -O since r11-2577

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

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

--- Comment #3 from Jakub Jelinek  ---
Yeah, just came to the same conclusion ;)

[Bug tree-optimization/97241] New: [11 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6503

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 97241
   Summary: [11 Regression] ICE in vectorizable_reduction, at
tree-vect-loop.c:6503
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-11.0.0-alpha20200927 snapshot (g:e24817aa7a1c6d12039b486ab5ea9b5ee0a46cd4)
ICEs when compiling the following testcase w/ -O3 --param
max-loop-header-insns=2:

short int *ev;
int l4;

short int
a7 (void)
{
  short int uo = ev[0], ie = uo;

  for (int kp = 0; kp < l4; kp += 4)
{
  uo += ev[kp + 1];
  ie += ev[kp];
}

  return uo + ie;
}

% gcc-11.0.0 -O3 --param max-loop-header-insns=2 -c u56c7vpf.c
during GIMPLE pass: vect
u56c7vpf.c: In function 'a7':
u56c7vpf.c:5:1: internal compiler error: in vectorizable_reduction, at
tree-vect-loop.c:6503
5 | a7 (void)
  | ^~
0x70b14d vectorizable_reduction(_loop_vec_info*, _stmt_vec_info*, _slp_tree*,
_slp_instance*, vec*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200927/work/gcc-11-20200927/gcc/tree-vect-loop.c:6503
0x1012baf vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*, _slp_tree*,
_slp_instance*, vec*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200927/work/gcc-11-20200927/gcc/tree-vect-stmts.c:10718
0x1046a5b vect_slp_analyze_node_operations_1
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200927/work/gcc-11-20200927/gcc/tree-vect-slp.c:2814
0x1046a5b vect_slp_analyze_node_operations
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200927/work/gcc-11-20200927/gcc/tree-vect-slp.c:2948
0x1046946 vect_slp_analyze_node_operations
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200927/work/gcc-11-20200927/gcc/tree-vect-slp.c:2940
0x1046946 vect_slp_analyze_node_operations
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200927/work/gcc-11-20200927/gcc/tree-vect-slp.c:2940
0x1046946 vect_slp_analyze_node_operations
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200927/work/gcc-11-20200927/gcc/tree-vect-slp.c:2940
0x1048b06 vect_slp_analyze_operations(vec_info*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200927/work/gcc-11-20200927/gcc/tree-vect-slp.c:3129
0x102bf43 vect_analyze_loop_2
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200927/work/gcc-11-20200927/gcc/tree-vect-loop.c:2338
0x102bf43 vect_analyze_loop(loop*, vec_info_shared*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200927/work/gcc-11-20200927/gcc/tree-vect-loop.c:2799
0x104f761 try_vectorize_loop_1
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200927/work/gcc-11-20200927/gcc/tree-vectorizer.c:999
0x10501c1 vectorize_loops()
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200927/work/gcc-11-20200927/gcc/tree-vectorizer.c:1234

[Bug fortran/97242] New: Pointer assignment: Noncontiguous target to contiguous pointer wrongly accepted.

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

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

Bug ID: 97242
   Summary: Pointer assignment: Noncontiguous target to contiguous
pointer wrongly accepted.
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

The lines:
  P => B(i)%A(:,::3,::4)   ! <<<
  P => C(::2,::2,::2)  ! <<<

are wrongly accepted – although the compiler can know that it is invalid →
gfc_is_not_contiguous() should detect this.


--
implicit none
type t
  integer, allocatable :: A(:,:,:)
end type t

type(t), target :: B(5)
integer, pointer, contiguous :: P(:,:,:)
integer, target :: C(5,5,5)
integer :: i

i = 1

! OK: contiguous
P => B(i)%A
P => B(i)%A(:,:,:)
P => C
P => C(:,:,:)
call foo (B(i)%A)
call foo (B(i)%A(:,:,:))
call foo (C)
call foo (C(:,:,:))

! Invalid - not contiguous
! "If the pointer object has the CONTIGUOUS attribute, the pointer target shall
be contiguous."
! → known to be noncontigous (not always checkable, however)
P => B(i)%A(:,::3,::4)   ! <<<
P => C(::2,::2,::2)  ! <<<

! This following is stricter:
! C1541  The actual argument corresponding to a dummy pointer with the
!CONTIGUOUS attribute shall be simply contiguous (9.5.4).
call foo (B(i)%A(:,::3,::4))  ! { dg-error "must be simply contiguous" }
call foo (C(::2,::2,::2)) ! { dg-error "must be simply contiguous" }

contains
  subroutine foo(Q)
integer, pointer, intent(in), contiguous :: Q(:,:,:)
  end subroutine foo
end

[Bug middle-end/64928] [8/9/10/11 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs

[lucier at math dot purdue.edu via Gcc-bugs]

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

--- Comment #32 from lucier at math dot purdue.edu ---
I don't know precisely what you're saying, but it compiles fine without the
instrumentation.

[Bug target/96789] x264: sub4x4_dct() improves when vectorization is disabled

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #35 from rsandifo at gcc dot gnu.org  
---
(In reply to rguent...@suse.de from comment #24)
> On September 27, 2020 4:56:43 AM GMT+02:00, crazylht at gmail dot com
>  wrote:
> >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96789
> >
> >--- Comment #22 from Hongtao.liu  ---
> >>One of my workmates found that if we disable vectorization for
> >SPEC2017 >525.x264_r function sub4x4_dct in source file
> >x264_src/common/dct.c with ?>explicit function attribute
> >__attribute__((optimize("no-tree-vectorize"))), it >can speed up by 4%.
> >
> >For CLX, if we disable slp vectorization in sub4x4_dct by 
> >__attribute__((optimize("no-tree-slp-vectorize"))), it can also speed
> >up by 4%.
> >
> >> Thanks Richi! Should we take care of this case? or neglect this kind
> >of
> >> extension as "no instruction"? I was intent to handle it in target
> >specific
> >> code, but it isn't recorded into cost vector while it seems too heavy
> >to do
> >> the bb_info slp_instances revisits in finish_cost.
> >
> >For i386 backend unsigned char --> unsigned short is no "no
> >instruction", but
> >in this case
> >---
> >1033  _134 = MEM[(pixel *)pix1_295 + 2B];  
> >
> >1034  _135 = (short unsigned int) _134;
> >---
> >
> >It could be combined and optimized to 
> >---
> >movzbl  19(%rcx), %r8d
> >---
> >
> >So, if "unsigned char" variable is loaded from memory, then the
> >convertion
> >would also be "no instruction", i'm not sure if backend cost model
> >could handle
> >such situation.
> 
> I think all attempts to address this from the side of the scalar cost is
> going to be difficult and fragile..
Agreed FWIW.  Even in rtl, the kinds of conversion we're talking
about could be removed, such as by proving that the upper bits are
already correct, by combining the extension with other instructions
so that it becomes “free” again, or by ree.  Proving that the upper
bits are already correct isn't uncommon: gimple has to make a choice
between signed and unsigned types even if both choices would be
correct, whereas rtl is sign-agnostic for storage.

So it's not obvious to me that trying model things at this level is
going to be right more often than it's wrong.

[Bug tree-optimization/97241] [11 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6503

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2020-09-29

--- Comment #1 from Richard Biener  ---
Mine.  Hacks pay back :/  Wonder what caused it.

[Bug tree-optimization/97238] [11 Regression] ICE: SIGSEGV in gimple_assign_rhs_code (gimple.h:2797) with -O since r11-2577

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/97238] [11 Regression] ICE: SIGSEGV in gimple_assign_rhs_code (gimple.h:2797) with -O since r11-2577

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

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

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

https://gcc.gnu.org/g:29aef377d814bd342dd5a306f99e0d614623ce0e

commit r11-3524-g29aef377d814bd342dd5a306f99e0d614623ce0e
Author: Richard Biener 
Date:   Tue Sep 29 14:38:06 2020 +0200

tree-optimization/97238 - fix typo causing ICE

This fixes a typo causing a NULL dereference.

2020-09-29  Richard Biener  

PR tree-optimization/97238
* tree-ssa-reassoc.c (ovce_extract_ops): Fix typo.

* gcc.dg/pr97238.c: New testcase.

[Bug target/97231] Missing FSF copyright notes for some x86 intrinsic headers

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r11-3525-gd68f4d2ecb8ed6781e4e535d2abc498b1674d68a
Author: Hongyu Wang 
Date:   Mon Sep 28 22:22:28 2020 +

Add missing FSF copyright notes for x86 intrinsic headers.

gcc/ChangeLog:

PR target/97231
* config/i386/amxbf16intrin.h: Add FSF copyright notes.
* config/i386/amxint8intrin.h: Ditto.
* config/i386/amxtileintrin.h: Ditto.
* config/i386/avx512vp2intersectintrin.h: Ditto.
* config/i386/avx512vp2intersectvlintrin.h: Ditto.
* config/i386/pconfigintrin.h: Ditto.
* config/i386/tsxldtrkintrin.h: Ditto.
* config/i386/wbnoinvdintrin.h: Ditto.

[Bug target/97231] Missing FSF copyright notes for some x86 intrinsic headers

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

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

H.J. Lu  changed:

   What|Removed |Added

Version|11.0|8.4.1

--- Comment #4 from H.J. Lu  ---
Fixed for GCC 11 so far.

[Bug tree-optimization/97236] [10/11 Regression] g:e93428a8b056aed83a7678 triggers vlc miscompile

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

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

--- Comment #1 from Martin Liška  ---
Created attachment 49287
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49287&action=edit
Reduced test-case

Reduced test-case that started to fail on master with r11-205-gbc484e250990393e
with -O3.

[Bug tree-optimization/97236] [10/11 Regression] g:e93428a8b056aed83a7678 triggers vlc miscompile

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

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

--- Comment #2 from Martin Liška  ---
Created attachment 49288
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49288&action=edit
Another test-case

Another test-case that started to fail with r10-1361-g9f962469cabc7fdc.

[Bug middle-end/64928] [8/9/10/11 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #33 from rguenther at suse dot de  ---
On Tue, 29 Sep 2020, lucier at math dot purdue.edu wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928
> 
> --- Comment #32 from lucier at math dot purdue.edu ---
> I don't know precisely what you're saying, but it compiles fine without the
> instrumentation.

Yes - the instrumentation does complicate the IL but the instrumentation
should be already better than linear in the blocks.

[Bug tree-optimization/97236] [10/11 Regression] g:e93428a8b056aed83a7678 triggers vlc miscompile

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-09-29
 Status|UNCONFIRMED |NEW

[Bug tree-optimization/97236] [10/11 Regression] g:e93428a8b056aed83a7678 triggers vlc miscompile

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
typedef unsigned char __uint8_t;
typedef __uint8_t uint8_t;
typedef struct plane_t {
  uint8_t *p_pixels;
  int i_lines;
  int i_pitch;
} plane_t;

typedef struct {
  plane_t p[5];
} picture_t;

#define N 4

void __attribute__((noipa))
picture_Clone(picture_t *picture, picture_t *res)
{
  for (int i = 0; i < N; i++) {
res->p[i].p_pixels = picture->p[i].p_pixels;
res->p[i].i_lines = picture->p[i].i_lines;
res->p[i].i_pitch = picture->p[i].i_pitch;
  }
}

int
main()
{
  picture_t aaa, bbb;
  uint8_t pixels[10] = {1, 1, 1, 1, 1, 1, 1, 1};

  for (unsigned i = 0; i < N; i++)
aaa.p[i].p_pixels = pixels;

  picture_Clone (&aaa, &bbb);

  uint8_t c;
  for (unsigned i = 0; i < N; i++)
c += bbb.p[i].p_pixels[0];

  if (c != N)
__builtin_abort ();
  return 0;
}

ends up with a NULL pointer in bb.p[1].p_pixels

[Bug ipa/97243] New: [11 Regression] ICE in compute_parm_map at gcc/ipa-modref.c:1368 since r11-3478-gada353b87909fd6c

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

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

Bug ID: 97243
   Summary: [11 Regression] ICE in compute_parm_map at
gcc/ipa-modref.c:1368 since r11-3478-gada353b87909fd6c
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

The following fails:

$ cat fp.c
float fma_test1(float a, float b, float c) {
  float x = a * b + c;
  return x;
}
float fma_test2(float a, float b, float c) {
  float x = a * b + c;
  return x;
}

$ gcc fp.c -c -fipa-modref -fipa-icf
during IPA pass: modref
fp.c:8:1: internal compiler error: Segmentation fault
8 | }
  | ^
0xda1cef crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:329
0x7788652f ???
   
/usr/src/debug/glibc-2.31-6.3.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xb97b0c compute_parm_map
/home/marxin/Programming/gcc/gcc/ipa-modref.c:1368
0xb9a0e1 compute_parm_map
/home/marxin/Programming/gcc/gcc/ipa-modref.c:1338
0xb9a0e1 modref_propagate_in_scc
/home/marxin/Programming/gcc/gcc/ipa-modref.c:1603
0xb9a0e1 execute
/home/marxin/Programming/gcc/gcc/ipa-modref.c:1680
0xb9a0e1 execute
/home/marxin/Programming/gcc/gcc/ipa-modref.c:1659
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug ipa/97243] [11 Regression] ICE in compute_parm_map at gcc/ipa-modref.c:1368 since r11-3478-gada353b87909fd6c

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-09-29
   Target Milestone|--- |11.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug ipa/97244] [11 Regression] ICE in ipa_edge_args_sum_t::duplicate at gcc/ipa-prop.c:4251 since r11-3478-gada353b87909fd6c

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-09-29
   Target Milestone|--- |11.0

[Bug ipa/97244] New: [11 Regression] ICE in ipa_edge_args_sum_t::duplicate at gcc/ipa-prop.c:4251 since r11-3478-gada353b87909fd6c

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

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

Bug ID: 97244
   Summary: [11 Regression] ICE in ipa_edge_args_sum_t::duplicate
at gcc/ipa-prop.c:4251 since
r11-3478-gada353b87909fd6c
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

The following fails:

$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/ipa/remref-2a.c -O3
-fno-early-inlining -fno-ipa-modref
during IPA pass: inline
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/ipa/remref-2a.c: In function
‘main’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/ipa/remref-2a.c:81:7:
internal compiler error: in duplicate, at ipa-prop.c:4251
   81 |   hip1_1 (hooray_1);
  |   ^
0x69433a ipa_edge_args_sum_t::duplicate(cgraph_edge*, cgraph_edge*,
ipa_edge_args*, ipa_edge_args*)
/home/marxin/Programming/gcc/gcc/ipa-prop.c:4251
0x96cc0b symbol_table::call_edge_duplication_hooks(cgraph_edge*, cgraph_edge*)
/home/marxin/Programming/gcc/gcc/cgraph.c:451
0x9804fb cgraph_edge::clone(cgraph_node*, gcall*, unsigned int, profile_count,
profile_count, bool)
/home/marxin/Programming/gcc/gcc/cgraphclones.c:149
0xe25067 copy_bb
/home/marxin/Programming/gcc/gcc/tree-inline.c:2266
0xe2602f copy_cfg_body
/home/marxin/Programming/gcc/gcc/tree-inline.c:3042
0xe2602f copy_body
/home/marxin/Programming/gcc/gcc/tree-inline.c:3290
0xe292c8 expand_call_inline
/home/marxin/Programming/gcc/gcc/tree-inline.c:5076
0xe2ae89 gimple_expand_calls_inline
/home/marxin/Programming/gcc/gcc/tree-inline.c:5266
0xe2ae89 optimize_inline_calls(tree_node*)
/home/marxin/Programming/gcc/gcc/tree-inline.c:5439
0xb954e3 inline_transform(cgraph_node*)
/home/marxin/Programming/gcc/gcc/ipa-inline-transform.c:741
0xcc98cd execute_one_ipa_transform_pass
/home/marxin/Programming/gcc/gcc/passes.c:2240
0xcc98cd execute_all_ipa_transforms(bool)
/home/marxin/Programming/gcc/gcc/passes.c:2279
0x97bca3 cgraph_node::expand()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2302
0x97d24f expand_all_functions
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2480
0x97d24f symbol_table::compile()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2843
0x97f642 symbol_table::compile()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2756
0x97f642 symbol_table::finalize_compilation_unit()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:3021
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/97241] [11 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6503 since r11-564-g79f0451c67e8ed56

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
Summary|[11 Regression] ICE in  |[11 Regression] ICE in
   |vectorizable_reduction, at  |vectorizable_reduction, at
   |tree-vect-loop.c:6503   |tree-vect-loop.c:6503 since
   ||r11-564-g79f0451c67e8ed56

--- Comment #2 from Martin Liška  ---
Started with r11-564-g79f0451c67e8ed56.

[Bug analyzer/95188] analyzer-unsafe-call-within-signal-handler shows wrong statement for signal registration event

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

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

--- Comment #4 from Mark Wielaard  ---
Note that I can replicate it with the instructions in the description and gcc
git: gcc (GCC) 11.0.0 20200916 (experimental)

$ /opt/local/install/gcc/bin/gcc -g -O2 -fanalyzer -c bzip2.c 2>&1 | head -25
bzip2.c: In function ‘showFileNames.part.0’:
bzip2.c:677:4: warning: call to ‘fprintf’ from within signal handler [CWE-479]
[-Wanalyzer-unsafe-call-within-signal-handler]
  677 |fprintf (
  |^
  678 |   stderr,
  |   ~~~
  679 |   "\tInput file = %s, output file = %s\n",
  |   
  680 |   inName, outName
  |   ~~~
  681 |);
  |~
  ‘main’: events 1-2
|
| 1776 | IntNative main ( IntNative argc, Char *argv[] )
|  |   ^~~~
|  |   |
|  |   (1) entry to ‘main’
| 1777 | {
| 1778 |Int32  i, j;
|  |~   
|  ||
|  |(2) registering ‘mySIGSEGVorSIGBUScatcher’ as signal handler
|
  event 3


It doesn't point at smallMode anymore, but the Int32 type isn't the right place
either.

For reference this is the main method starting at line 1776:

IntNative main ( IntNative argc, Char *argv[] )
{
   Int32  i, j;
   Char   *tmp;
   Cell   *argList;
   Cell   *aa;
   Bool   decode;

   /*-- Be really really really paranoid :-) --*/
   if (sizeof(Int32) != 4 || sizeof(UInt32) != 4  ||
   sizeof(Int16) != 2 || sizeof(UInt16) != 2  ||
   sizeof(Char)  != 1 || sizeof(UChar)  != 1)
  configError();

   /*-- Initialise --*/
   outputHandleJustInCase  = NULL;
   smallMode   = False;
   keepInputFiles  = False;
   forceOverwrite  = False;
   noisy   = True;
   verbosity   = 0;
   blockSize100k   = 9;
   testFailsExist  = False;
   unzFailsExist   = False;
   numFileNames= 0;
   numFilesProcessed   = 0;
   workFactor  = 30;
   deleteOutputOnInterrupt = False;
   exitValue   = 0;
   i = j = 0; /* avoid bogus warning from egcs-1.1.X */

   /*-- Set up signal handlers for mem access errors --*/
   signal (SIGSEGV, mySIGSEGVorSIGBUScatcher);

[Bug tree-optimization/97236] [10/11 Regression] g:e93428a8b056aed83a7678 triggers vlc miscompile

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
So what goes wrong is the single-element interleaving code-gen for the pointer
copy.  We have

t.c:18:21: note:   Detected single element interleaving
picture_7(D)->p[i_18].p_pixels step 16

but for the store:

t.c:18:21: missed:   not consecutive access res_8(D)->p[i_18].p_pixels = _1;
t.c:18:21: note:   using strided accesses

...

t.c:18:21: note:   ==> examining statement: _1 =
picture_7(D)->p[i_18].p_pixels;
t.c:18:21: note:   vect_model_load_cost: aligned.
t.c:18:21: note:   vect_model_load_cost: inside_cost = 24, prologue_cost = 0 .

and in group get-load-store type we handle it as (V1DI)

  if (!STMT_VINFO_STRIDED_P (first_stmt_info)
  && (can_overrun_p || !would_overrun_p)
  && compare_step_with_zero (vinfo, stmt_info) > 0)
{
  /* First cope with the degenerate case of a single-element
 vector.  */
  if (known_eq (TYPE_VECTOR_SUBPARTS (vectype), 1U))
*memory_access_type = VMAT_CONTIGUOUS;

looks like this needs to be conditional on gap == 0?  Adding that fixes
the testcase.  This was added by g:6737facbb3c53a1f0158b05e4116c161ed9bc319
Richard?  It looks like the !STMT_VINFO_STRIDED_P check might have supposed
to prevent this?  In vectorizable_load we're also doing

  if (memory_access_type == VMAT_GATHER_SCATTER
  || (!slp && memory_access_type == VMAT_CONTIGUOUS))
grouped_load = false;

but vect_transform_grouped_load doesn't like this case, possibly because
there's nothing to "permute" (eliding that alone doesn't fix the code-gen
issue).

[Bug middle-end/97054] [10/11 Regression] Runtime segfault with attached test code since r10-3559

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #4 from H.J. Lu  ---
Fixed for GCC 10.3 by

commit 6959f60cb276ad530917c2d039d9edc19fefa216
Author: Richard Sandiford 
Date:   Fri Sep 18 16:55:45 2020 +0100

ira: Fix elimination for global hard FPs [PR97054]

If the hard frame pointer is being used as a global register,
we should skip the usual handling for eliminations.  As the
comment says, the register cannot in that case be eliminated
(or eliminated to) and is already marked live where appropriate.

Doing this removes the duplicate error for gcc.target/i386/pr82673.c.
The “cannot be used in 'asm' here” message is meant to be for asm
statements rather than register asms, and the function that the
error is reported against doesn't use asm.

gcc/
2020-09-18  Richard Sandiford  

PR middle-end/97054
* ira.c (ira_setup_eliminable_regset): Skip the special elimination
handling of the hard frame pointer if the hard frame pointer is
fixed.

gcc/testsuite/
2020-09-18  H.J. Lu  
Richard Sandiford  

PR middle-end/97054
* g++.target/i386/pr97054.C: New test.
* gcc.target/i386/pr82673.c: Remove redundant extra message.

(cherry picked from commit 3c7c5f1d4a4b8328fb4c07483cdbfe4ea7762155)

[Bug tree-optimization/97241] [11 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6503 since r11-564-g79f0451c67e8ed56

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/97241] [11 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6503 since r11-564-g79f0451c67e8ed56

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

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

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

https://gcc.gnu.org/g:39a27bb01aa223ce89946f0a4de6b60c4c0b03d2

commit r11-3527-g39a27bb01aa223ce89946f0a4de6b60c4c0b03d2
Author: Richard Biener 
Date:   Tue Sep 29 15:02:47 2020 +0200

tree-optimization/97241 - fix ICE in reduction vectorization

The following moves an ad-hoc attempt at discovering the SLP node
for a stmt to the place where we can find it in lock-step when
we find the stmt itself.

2020-09-29  Richard Biener  

PR tree-optimization/97241
* tree-vect-loop.c (vectorizable_reduction): Move finding
the SLP node for the reduction stmt to a better place.

* gcc.dg/vect/pr97241.c: New testcase.

[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses

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

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

Bug 94433 Summary: enhancement: 12 * constify some parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94433

   What|Removed |Added

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

[Bug analyzer/94433] enhancement: 12 * constify some parameters

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #6 from David Malcolm  ---
Thanks.  I took another look through the output, and nothing struck me as
serious, so I'm going to close this one out.

[Bug preprocessor/96952] __builtin_thread_pointer support cannot be probed

[bugdal at aerifal dot cx via Gcc-bugs]

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

--- Comment #5 from Rich Felker  ---
The whole point of __has_builtin is to let you avoid the configure-time checks
on compilers that support __has_builtin. If __has_builtin doesn't actually
work, it's pointless that it even exists and indeed everyone should just
pretend it doesn't exist and keep using configure-time checks for everything.

[Bug sanitizer/97229] pointer-compare sanitizer is very slow due to __asan::IsAddressNearGlobal

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-09-29
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Martin Liška  ---
Thank you Millian for the report. I'm the author of the pointer-compare
run-time implementation and I can help.

Can you please paste 'perf report' of your real application. I bet you have
quite some globals and we stupidly iterate over them here:
https://github.com/gcc-mirror/gcc/blob/master/libsanitizer/asan/asan_globals.cpp#L108-L127

[Bug preprocessor/96952] __builtin_thread_pointer support cannot be probed

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

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

--- Comment #6 from Eric Botcazou  ---
> The whole point of __has_builtin is to let you avoid the configure-time
> checks on compilers that support __has_builtin. If __has_builtin doesn't
> actually work, it's pointless that it even exists and indeed everyone should
> just pretend it doesn't exist and keep using configure-time checks for
> everything.

That would certainly restore the portability that __has_builtin has broken.

[Bug middle-end/95673] missing -Wstring-compare for an impossible strncmp test

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

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

Franz Sirl  changed:

   What|Removed |Added

 CC||sirl at gcc dot gnu.org

--- Comment #5 from Franz Sirl  ---
Wstring-compare seems to depend a lot on the optimizations. In the following
testcase warnings are also inconsistent and fragile (slight changes make the
warning disappear):

int c, d, e;
void f(void) {
  const char *file = (c & 7) ? "file1234.txt" : "x";
  const char *file2 = (c & 7) ? "y" : "file12.txt";
  if (c == 2)
if (d
|| __builtin_strcmp(file, "file123.txt")
|| __builtin_strcmp(file2, "file123.txt")
   )
  e = 2;
}

With "gcc -c -O2 -Wstring-compare testcase.c" current trunk shows:

testcase.c: In function 'f':
testcase.c:8:12: warning: '__builtin_strcmp' of a string of length 11 and an
array of size 11 evaluates to nonzero [-Wstring-compare]
8 | || __builtin_strcmp(file2, "file123.txt")
  |^~

There is no warning for line 7 ('file').
Maybe the warning could also be a bit more verbose when the information is
available, like for example:

warning: '__builtin_strcmp' of a string ('file2' with content "y" ||
"file12.txt") and an array ("file123.txt") of size 11 always evaluates to
nonzero [-Wstring-compare]

[Bug preprocessor/96952] __builtin_thread_pointer support cannot be probed

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

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Eric Botcazou from comment #4)
> What about detecting the support at configure time and defining a macro
> during the compilation?  Everyone has been doing this for more that 3
> decades...

Sorry, but it doesn't work. How do you suggest libstdc++ should use
configure-time checks to find out what features are present in the compiler
including the libstdc++ headers later? I don't know what that compiler is at
configure time.

For example, installed libstdc++ headers might get included by the GCC release
that they belong to, or by unknown releases of Clang or ICC with different
feature sets and levels of standard conformance. Checking anything at configure
time is useless for code in headers.

[Bug fortran/97245] New: ASSOCIATE intrinsic does not recognize a ponter variable the second time it is used

[aluaces at udc dot es via Gcc-bugs]

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

Bug ID: 97245
   Summary: ASSOCIATE intrinsic does not recognize a ponter
variable the second time it is used
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aluaces at udc dot es
  Target Milestone: ---

Created attachment 49289
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49289&action=edit
Minimal working example

In the attached example, the second call to associate() makes the compiler
error with "Error: ‘pointer’ argument of ‘associated’ intrinsic at (1) must be
a POINTER", although it is correct and the first use passes:

MODULE formulaciones
  IMPLICIT NONE

  ABSTRACT INTERFACE
 SUBROUTINE proc_void()
   IMPLICIT NONE
 END SUBROUTINE proc_void
  end INTERFACE

  PROCEDURE(proc_void), POINTER:: pADJSensib

CONTAINS
  subroutine calculo()
implicit none
LOGICAL step

IF(associated(pADJSensib)) THEN
   CALL pADJSensib
ENDIF

IF(associated(pADJSensib)) THEN
   CALL pADJSensib
END IF
  end subroutine calculo

END MODULE formulaciones

[Bug c++/97195] construct_at on a union member is not a constant expression

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c/97206] [11 Regression] internal compiler error: in composite_type, at c/c-typeck.c:447 since r11-3303-g6450f07388f9fe57

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

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

--- Comment #6 from Martin Sebor  ---
Testing this fix:

diff --git a/gcc/attribs.c b/gcc/attribs.c
index abc75368e6c..262e4b8f7b9 100644
--- a/gcc/attribs.c
+++ b/gcc/attribs.c
@@ -2278,7 +2278,7 @@ attr_access::array_as_string (tree type) const
   else  if (minsize)
index_type = build_index_type (size_int (minsize - 1));

-  artype = build_array_type (eltype, index_type);
+  artype = build_nonshared_array_type (eltype, index_type);

   if (static_p || vla_p)
{

[Bug analyzer/95188] analyzer-unsafe-call-within-signal-handler shows wrong statement for signal registration event

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

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

--- Comment #5 from David Malcolm  ---
Thanks Mark.  What architecture are you on?

When I do those steps, there's a long wait and then in terminates with no
analyzer output.

If I add -Wanalyzer-too-complex I see lots of warnings about "terminating
analysis for this program point".

What do you see if you add -Wanalyzer-too-complex?

If you do, my guess as to what's happening is that there's a "random" factor in
how the worklist is being explored, and that on my machine it's hitting the
complexity limits before finding the issue, and on your machine it's finding
the issue first.  Perhaps it relates to pointer addresses; PR 96608 notes some
places where hash values could vary between runs, and that could be enough to
throw out the worklist traversal order.

[Bug target/96700] undefined reference to `failure_on_line_796'

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

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

Jim Wilson  changed:

   What|Removed |Added

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

--- Comment #3 from Jim Wilson  ---
I took another look at this.

I can get this to fail with an x86_64 gcc, but that is the system compiler
which is gcc-7.  A little testing shows that the testcase works for x86_64
gcc-8 and later and fails for gcc-7.  However, since this is a testcase for
gcc-11, there is no expectation that it should work with older gcc versions. 
We sometimes need to modify testcases to work when gcc changes.

I also tried this with rv32-elf compilers, gcc-11, gcc-10, gcc-9, and I
couldn't get the testcase to fail for any of them, with or without -flto.

So I can't reproduce the original poster's problem, which gets me back to my
original claim that I don't think that this is a gcc bug.

Actually, on second thought, I realized that I'm using the original testcase
from the gcc source tree gcc.dg/tree-ssa/buitlin-sprintf.c not the attachment. 
Looking at the attachment, I see that some numbers have been modified.  So that
is why it fails.  It is a bogus testcase.  Looking further, I see that you are
using an old version of the testcase before it was changed in 2018.  See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86274
which both changed an optimization and changed the testcase to match the new
optimization.  The fix was put on mainlnie (gcc-9) and backported to gcc-8, so
the testcase should fail for any gcc-8 or later.

This is invalid.  You can't take a testcase from gcc-X and expect it to work
with gcc-Y.

[Bug c++/97222] GCC discards attributes aligned and may_alias for typedefs passed as template arguments

[mte.zych at gmail dot com via Gcc-bugs]

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

Mateusz Zych  changed:

   What|Removed |Added

   See Also||https://bugs.llvm.org/show_
   ||bug.cgi?id=47674

--- Comment #4 from Mateusz Zych  ---
I just wanted to mention, that I raised issue in the Clang Bugzilla,
since Clang is matching GCC behavior (also discards attributes):

 - https://bugs.llvm.org/show_bug.cgi?id=47674

Thanks, Mateusz

[Bug c++/97246] New: [10.1 regression] mismatched argument pack lengths

[wjwray at gmail dot com via Gcc-bugs]

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

Bug ID: 97246
   Summary: [10.1 regression] mismatched argument pack lengths
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wjwray at gmail dot com
  Target Milestone: ---

A deduced  argument pack T... v now gives a
"mismatched argument pack lengths" error for T... and v...

i.e. static_assert( sizeof...(T) == sizeof...(v) ); // Fail !!

Here's a sample, working on 9.3, rejected since 10.1
https://godbolt.org/z/oM9ve5

  template 
  T arg_T(decltype(Is)..., T, ...);

  template 
  inline constexpr auto get =
   [](decltype(Is)..., T... v, ...) {
 static_assert( sizeof...(T) == sizeof...(v) );
 if constexpr ( sizeof...(T) == 1 )
   return (v,...);
 else {
   using V = decltype(arg_T<__integer_pack(I)...>(v...));
   return get.template operator()(v...);
 }
   };

   static_assert( get<0>('\0', short{1}, 2, long{3}) == 0 );

(Will try to simplify & post a reduced sample in a later comment).

Note: the 'mismatched length' error shows when both T and v are used together
e.g. with forwarding references  : (T&&... v) : ((T&&)v...)

[Bug target/97231] Missing FSF copyright notes for some x86 intrinsic headers

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-10 branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:93212f3e15c5e13cb1eed430e880f35edc108b13

commit r10-8826-g93212f3e15c5e13cb1eed430e880f35edc108b13
Author: Hongyu Wang 
Date:   Mon Sep 28 22:22:28 2020 +

Add missing FSF copyright notes for x86 intrinsic headers.

gcc/ChangeLog:

PR target/97231
* config/i386/avx512vp2intersectintrin.h: Add FSF copyright notes.
* config/i386/avx512vp2intersectvlintrin.h: Ditto.
* config/i386/pconfigintrin.h: Ditto.
* config/i386/wbnoinvdintrin.h: Ditto.

(cherry picked from commit d68f4d2ecb8ed6781e4e535d2abc498b1674d68a)

[Bug analyzer/95188] analyzer-unsafe-call-within-signal-handler shows wrong statement for signal registration event

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

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

--- Comment #6 from Mark Wielaard  ---
Created attachment 49291
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49291&action=edit
Output for gcc -Wanalyzer-too-complex -g -O2 -fanalyzer -c bzip2.c

(In reply to David Malcolm from comment #5)
> Thanks Mark.  What architecture are you on?

RHEL7 x86_64.

> When I do those steps, there's a long wait and then in terminates with no
> analyzer output.
> 
> If I add -Wanalyzer-too-complex I see lots of warnings about "terminating
> analysis for this program point".
> 
> What do you see if you add -Wanalyzer-too-complex?

Lots and lots of output saying "warning: terminating analysis for this program
point". log attached.

[Bug target/97231] Missing FSF copyright notes for some x86 intrinsic headers

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-9 branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:97bbda2c7e29e39719278055bcc7b07a5e89eba3

commit r9-8957-g97bbda2c7e29e39719278055bcc7b07a5e89eba3
Author: Hongyu Wang 
Date:   Mon Sep 28 22:22:28 2020 +

Add missing FSF copyright notes for x86 intrinsic headers.

gcc/ChangeLog:

PR target/97231
* config/i386/pconfigintrin.h: Add FSF copyright notes.
* config/i386/wbnoinvdintrin.h: Ditto.

(cherry picked from commit d68f4d2ecb8ed6781e4e535d2abc498b1674d68a)

[Bug target/97231] Missing FSF copyright notes for some x86 intrinsic headers

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-8 branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:528348fca9a9a29ba40a32df8f1a0dc95b101aa7

commit r8-10554-g528348fca9a9a29ba40a32df8f1a0dc95b101aa7
Author: Hongyu Wang 
Date:   Mon Sep 28 22:22:28 2020 +

Add missing FSF copyright notes for x86 intrinsic headers.

gcc/ChangeLog:

PR target/97231
* config/i386/pconfigintrin.h: Add FSF copyright notes.
* config/i386/wbnoinvdintrin.h: Ditto.

(cherry picked from commit d68f4d2ecb8ed6781e4e535d2abc498b1674d68a)

[Bug target/97231] Missing FSF copyright notes for some x86 intrinsic headers

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #8 from H.J. Lu  ---
Fixed for GCC 8.5, 9.4 and 10.3.

[Bug target/97247] New: Typo in

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

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

Bug ID: 97247
   Summary: Typo in 
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: i386,x86-64

 has

#if !defined _IMMINTRIN_H_INCLUDED
# error "Never use  directly; include  instead."
    It should be .
#endif

[Bug target/97247] Typo in

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

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

H.J. Lu  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2020-Septemb
   ||er/555109.html
   Target Milestone|--- |10.3
   Last reconfirmed||2020-09-29
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from H.J. Lu  ---
A patch has been submitted:

https://gcc.gnu.org/pipermail/gcc-patches/2020-September/555109.html

[Bug target/97247] Typos in

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

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

H.J. Lu  changed:

   What|Removed |Added

Summary|Typo in |Typos in 

--- Comment #2 from H.J. Lu  ---
The updated patch with the _ENQCMDNTRIN_H_INCLUDED fix is at:

https://gcc.gnu.org/pipermail/gcc-patches/2020-September/555109.html

[Bug target/97247] Typos in

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

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

H.J. Lu  changed:

   What|Removed |Added

URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma
   |il/gcc-patches/2020-Septemb |il/gcc-patches/2020-Septemb
   |er/555109.html  |er/555111.html

--- Comment #3 from H.J. Lu  ---
It is:

https://gcc.gnu.org/pipermail/gcc-patches/2020-September/555111.html

[Bug target/97247] Typos in

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r11-3531-gdec881f85abbddc6e37630b6e61ce621cea6acd7
Author: H.J. Lu 
Date:   Tue Sep 29 11:40:46 2020 -0700

x86: Replace  with 

Fix 2 typos in config/i386/enqcmdintrin.h by replacing 
with :

[hjl@gnu-cfl-2 x86-gcc]$ echo "#include " | gcc -S -o
/dev/null -x c -
In file included from :1:
/usr/lib/gcc/x86_64-redhat-linux/10/include/enqcmdintrin.h:25:3: error:
#error "Never use  directly; include  instead."
   25 | # error "Never use  directly; include 
instead."
  |   ^
[hjl@gnu-cfl-2 x86-gcc]$

and _ENQCMDINTRIN_H_INCLUDED with _ENQCMDINTRIN_H_INCLUDED.

gcc/

PR target/97247
* config/i386/enqcmdintrin.h: Replace  with
.  Replace _ENQCMDNTRIN_H_INCLUDED with
_ENQCMDINTRIN_H_INCLUDED.

[Bug preprocessor/96952] __builtin_thread_pointer support cannot be probed

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

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

--- Comment #8 from Eric Botcazou  ---
> Sorry, but it doesn't work. How do you suggest libstdc++ should use
> configure-time checks to find out what features are present in the compiler
> including the libstdc++ headers later? I don't know what that compiler is at
> configure time.

I'm surprising by that: are you saying that none of the  _GLIBCXX_* values
tested in the libstdc++ headers come from the libstdc++ configure machinery?

[Bug target/97247] Typos in

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-10 branch has been updated by H.J. Lu :

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

commit r10-8827-gffe2a432ac553b45b954fa24c8cbb9cc373bfbc6
Author: H.J. Lu 
Date:   Tue Sep 29 11:40:46 2020 -0700

x86: Replace  with 

Fix 2 typos in config/i386/enqcmdintrin.h by replacing 
with :

[hjl@gnu-cfl-2 x86-gcc]$ echo "#include " | gcc -S -o
/dev/null -x c -
In file included from :1:
/usr/lib/gcc/x86_64-redhat-linux/10/include/enqcmdintrin.h:25:3: error:
#error "Never use  directly; include  instead."
   25 | # error "Never use  directly; include 
instead."
  |   ^
[hjl@gnu-cfl-2 x86-gcc]$

and _ENQCMDINTRIN_H_INCLUDED with _ENQCMDINTRIN_H_INCLUDED.

gcc/

PR target/97247
* config/i386/enqcmdintrin.h: Replace  with
.  Replace _ENQCMDNTRIN_H_INCLUDED with
_ENQCMDINTRIN_H_INCLUDED.

(cherry picked from commit dec881f85abbddc6e37630b6e61ce621cea6acd7)

[Bug target/97247] Typos in

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #6 from H.J. Lu  ---
Fixed for GCC 11 and GCC 10.3.

[Bug analyzer/95188] analyzer-unsafe-call-within-signal-handler shows wrong statement for signal registration event

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

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

--- Comment #7 from David Malcolm  ---
Thanks.  I see a similar deluge of
  "terminating analysis for this program point"
warnings, but at different locations.

My warnings eventually terminate with:

  bzip2.c:1537:31: warning: analysis bailed out early (4561 'after-snode'
enodes; 15071 enodes) [-Wanalyzer-too-complex]

whereas yours don't - my machine is eventually hitting the overall complexity
limit (as opposed to merely hitting the per-program-point limit).

If I add
  -fparam-analyzer-bb-explosion-factor=50
to try to get past that limit (the default for that param is 5) then I see the
-Wanalyzer-unsafe-call-within-signal-handler warnings you're seeing (it takes
quite a while to run).

As in comment #5, I think what's happening is some "random" aspect of the
analysis affecting the order in which the worklist is processed, which leads to
my machine terminating early and yours running to completion.

So there are at least four issues here:

(a) the reported bug: that -Wanalyzer-unsafe-call-within-signal-handler uses
the wrong source location when reporting the signal registration event in the
diagnostic_path
(b) that -fanalyzer is hitting per-program-point limits
(c) that -fanalyzer can hit the overall enode limit
(d) that the behavior is sufficiently "random" that (c) can happen on one
machine and not on another, and that the log for the (b) events shows the order
of exploration varying between machines.

Mark: please can you add -fdump-analyzer-supergraph to the arguments and attach
the bzip2.c.supergraph.dot file to this bug.  Doing so may help track down (d).

[Bug preprocessor/96952] __builtin_thread_pointer support cannot be probed

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

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

--- Comment #9 from Jonathan Wakely  ---
No, I didn't say none of them come from configure. What I meant by "checking
anything at configure time" is anything related to the properties of the
compiler that ends up including the header. Not *anything* at all.

Most of the _GLIBCXX macros relate to properties of the OS, which doesn't
change when you include the headers with a different C++ compiler.

But see
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/bits/c%2B%2Bconfig;h=860bf6dbcb3de8500555c95148f4fc6ad44cf0dd;hb=HEAD#l665
which uses __has_builtin. How would you do that in configure? The compiler that
ends up consuming the libstdc++ headers might not even have existed when
configure was run.

[Bug c/97206] [11 Regression] internal compiler error: in composite_type, at c/c-typeck.c:447 since r11-3303-g6450f07388f9fe57

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

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code, patch

--- Comment #7 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/555125.html

[Bug bootstrap/97183] zstd build failure for gcc 10 on Ubuntu 16.04

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jim Wilson :

https://gcc.gnu.org/g:6649df18f98d5baf89b56a09b816b5eeb5f67bcb

commit r11-3536-g6649df18f98d5baf89b56a09b816b5eeb5f67bcb
Author: Jim Wilson 
Date:   Mon Sep 28 17:13:40 2020 -0700

Fix GCC 10+ build failure with zstd version 1.2.0 or older.

Extends the configure check for zstd.h to also verify the zstd version,
since gcc requires features that only exist in 1.3.0 and newer.  Without
this patch we get a build error for lto-compress.c when using an old zstd
version.

gcc/
PR bootstrap/97183
* configure.ac (gcc_cv_header_zstd_h): Check ZSTD_VERISON_NUMBER.
* configure: Regenerated.

[Bug analyzer/95188] analyzer-unsafe-call-within-signal-handler shows wrong statement for signal registration event

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

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

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

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

commit r11-3537-gd60d63a00bb50ba6896939705c589578177b404d
Author: David Malcolm 
Date:   Tue Sep 29 15:55:33 2020 -0400

analyzer: fix signal-handler registration location [PR95188]

PR analyzer/95188 reports that diagnostics from
-Wanalyzer-unsafe-call-within-signal-handler use the wrong
source location when reporting the signal-handler registration
event in the diagnostic_path.  The diagnostics erroneously use the
location of the first stmt in the basic block containing the call
to "signal", rather than that of the call itself.

Fixed thusly.

gcc/analyzer/ChangeLog:
PR analyzer/95188
* engine.cc (stmt_requires_new_enode_p): Split enodes before
"signal" calls.

gcc/testsuite/ChangeLog:
PR analyzer/95188
* gcc.dg/analyzer/signal-registration-loc.c: New test.

[Bug analyzer/95188] analyzer-unsafe-call-within-signal-handler shows wrong statement for signal registration event

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

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

--- Comment #9 from David Malcolm  ---
The above patch fixes (a) from comment #7 above, but (b), (c) and (d) still
need fixing, so keeping this open for now.

[Bug c++/94695] Implement -Wrange-loop-analysis

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:969baf03acd8124345617cea125b148568c7370a

commit r11-3539-g969baf03acd8124345617cea125b148568c7370a
Author: Marek Polacek 
Date:   Thu Sep 24 14:30:50 2020 -0400

c++: Implement -Wrange-loop-construct [PR94695]

This new warning can be used to prevent expensive copies inside range-based
for-loops, for instance:

  struct S { char arr[128]; };
  void fn () {
S arr[5];
for (const auto x : arr) {  }
  }

where auto deduces to S and then we copy the big S in every iteration.
Using "const auto &x" would not incur such a copy.  With this patch the
compiler will warn:

q.C:4:19: warning: loop variable 'x' creates a copy from type 'const S'
[-Wrange-loop-construct]
4 |   for (const auto x : arr) {  }
  |   ^
q.C:4:19: note: use reference type 'const S&' to prevent copying
4 |   for (const auto x : arr) {  }
  |   ^
  |   &

As per Clang, this warning is suppressed for trivially copyable types
whose size does not exceed 64B.  The tricky part of the patch was how
to figure out if using a reference would have prevented a copy.  To
that point, I'm using the new function called ref_conv_binds_directly_p.

This warning is enabled by -Wall.  Further warnings of similar nature
should follow soon.

gcc/c-family/ChangeLog:

PR c++/94695
* c.opt (Wrange-loop-construct): New option.

gcc/cp/ChangeLog:

PR c++/94695
* call.c (ref_conv_binds_directly_p): New function.
* cp-tree.h (ref_conv_binds_directly_p): Declare.
* parser.c (warn_for_range_copy): New function.
(cp_convert_range_for): Call it.

gcc/ChangeLog:

PR c++/94695
* doc/invoke.texi: Document -Wrange-loop-construct.

gcc/testsuite/ChangeLog:

PR c++/94695
* g++.dg/warn/Wrange-loop-construct.C: New test.

[Bug c++/94695] Implement -Wrange-loop-analysis

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

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

--- Comment #2 from Marek Polacek  ---
First part of the warning is now implemented.

[Bug tree-optimization/97188] [11 Regression] ICE in c_tree_printer at c/c-objc-common.c:314 since r11-3303-g6450f07388f9fe57

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:873f8c1e6df94a9dcbfbe69f06538e3e45ba151d

commit r11-3540-g873f8c1e6df94a9dcbfbe69f06538e3e45ba151d
Author: Martin Sebor 
Date:   Tue Sep 29 17:10:54 2020 -0600

Correct and improve -Wnonnull for calls to functions with VLA arguments (PR
middle-end/97188).

Resolves:
PR middle-end/97188 - ICE passing a null VLA to a function expecting at
least one element

gcc/ChangeLog:

PR middle-end/97188
* calls.c (maybe_warn_rdwr_sizes): Simplify warning messages.
Correct handling of VLA argumments.

gcc/testsuite/ChangeLog:

PR middle-end/97188
* gcc.dg/Wstringop-overflow-23.c: Adjust text of expected warnings.
* gcc.dg/Wnonnull-4.c: New test.

[Bug tree-optimization/97188] [11 Regression] ICE passing a null VLA to a function expecting at least one element

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

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
Summary|[11 Regression] ICE in  |[11 Regression] ICE passing
   |c_tree_printer at   |a null VLA to a function
   |c/c-objc-common.c:314 since |expecting at least one
   |r11-3303-g6450f07388f9fe57  |element

--- Comment #3 from Martin Sebor  ---
Fixed in r11-3540.

[Bug ipa/97244] [11 Regression] ICE in ipa_edge_args_sum_t::duplicate at gcc/ipa-prop.c:4251 since r11-3478-gada353b87909fd6c

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

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #1 from Iain Sandoe  ---
a stage #1 debug build using a recent GCC-11 with 
 make CFLAGS="-Og -g" CXXFLAGS="-Og -g"
 also fails in the same way on x86_64-linux and darwin:

I think between r11-3505r11-3531.

during IPA pass: inline
../../src/gcc/cgraph.c: In member function ‘bool
cgraph_node::can_remove_if_no_direct_calls_p(bool)’:
../../src/gcc/cgraph.c:2935:43: internal compiler error: in duplicate, at
ipa-prop.c:4251
 2935 |   return !call_for_symbol_and_aliases (nonremovable_p, NULL, true);
  |   ^~~~
0x7814c2 ipa_edge_args_sum_t::duplicate(cgraph_edge*, cgraph_edge*,
ipa_edge_args*, ipa_edge_args*)
../../src/gcc/ipa-prop.c:4251
0xe02ddb symbol_table::call_edge_duplication_hooks(cgraph_edge*, cgraph_edge*)
../../src/gcc/cgraph.c:451
0xe1657b cgraph_edge::clone(cgraph_node*, gcall*, unsigned int, profile_count,
profile_count, bool)
../../src/gcc/cgraphclones.c:149
0x12edcb7 copy_bb
../../src/gcc/tree-inline.c:2266
0x12eecc3 copy_cfg_body
../../src/gcc/tree-inline.c:3042
0x12eecc3 copy_body
../../src/gcc/tree-inline.c:3290
0x12f1fa8 expand_call_inline
../../src/gcc/tree-inline.c:5076
0x12f3b31 gimple_expand_calls_inline
../../src/gcc/tree-inline.c:5266
0x12f3b31 optimize_inline_calls(tree_node*)
../../src/gcc/tree-inline.c:5439
0x103cb8b inline_transform(cgraph_node*)
../../src/gcc/ipa-inline-transform.c:741
0x117d0cd execute_one_ipa_transform_pass
../../src/gcc/passes.c:2240
0x117d0cd execute_all_ipa_transforms(bool)
../../src/gcc/passes.c:2279
0xe11d13 cgraph_node::expand()
../../src/gcc/cgraphunit.c:2302
0xe132af expand_all_functions
../../src/gcc/cgraphunit.c:2480
0xe132af symbol_table::compile()
../../src/gcc/cgraphunit.c:2843
0xe156e2 symbol_table::compile()
../../src/gcc/cgraphunit.c:2756
0xe156e2 symbol_table::finalize_compilation_unit()
../../src/gcc/cgraphunit.c:3021
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[1]: *** [Makefile:1123: cgraph.o] Error 1
make: *** [Makefile:4726: all-gcc] Error 2

[Bug target/96968] aarch64 : ICE in vregs or expand pass, lowering __builtin_aarch64_get_{fpcr,fpsr,fpcr64,fpsr64}

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

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

--- Comment #9 from Iain Sandoe  ---
(In reply to Andrea Corallo from comment #8)
> "iains at gcc dot gnu.org via Gcc-bugs"  writes:
> [...]
> > unfortunately, I've not been able to test since you applied this - currently
> > bootstrap is broken on aarch64-darwin for reasons outside our control (new
> > security provisions stopping the gcc/build/gen* programs from running).  If 
> > it
> > could stay open for a few more days, while we try to find a fix for that - 
> > (or
> > close it and we can reopen if needed).
> 
> Sure no rush, thanks for testing it!

I managed to do a manual build on arm64-darwin, and the ICE is gone.  Not sure
if the flags are supported by the hardware but that's a different issue.  Fine
to close this from my pov.

We get this for the simple test-case (mach-o/darwin format object):
.arch armv8-a
.text
.align  2
.globl _main
_main:
LFB0:
.cfi_startproc
sub sp, sp, #16
.cfi_def_cfa_offset 16
mrs x0, fpcr
str w0, [sp, 12]
mov w0, 0
add sp, sp, 16
.cfi_def_cfa_offset 0
ret
.cfi_endproc
LFE0:
.ident  "GCC: (GNU) 11.0.0 20200929 (experimental)"
.subsections_via_symbols

[Bug target/97248] New: [mips] unrecognizable insn when left shifting uint64 vector by scalar with MSA

[evan--- via Gcc-bugs]

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

Bug ID: 97248
   Summary: [mips] unrecognizable insn when left shifting uint64
vector by scalar with MSA
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: e...@coeus-group.com
  Target Milestone: ---

On mips64el with -mmsa, attempting to left shift a vector of unsigned 64-bit
integers by a scalar results in an ICE.  The same code works without -mmsa.

Test case:

  typedef struct {
long unsigned int c __attribute__((__vector_size__(16)));
  } d;
  int i() {
int e;
d f, g;
f.c = g.c << e;
  }

`mips64el-linux-gnuabi64-gcc-10 -mmsa -c -o foo.o foo.c`:

  foo.c: In function ‘i’:
  foo.c:8:1: error: unrecognizable insn:
  8 | }
| ^
  (insn 9 8 10 2 (set (reg:DI 198)
  (subreg:DI (mem/c:SI (reg/f:DI 189 virtual-stack-vars) [1 e+0 S4
A32]) 0)) "foo.c":7:13 -1
  (nil))
  during RTL pass: vregs
  foo.c:8:1: internal compiler error: in extract_insn, at recog.c:2294
  Please submit a full bug report,
  with preprocessed source if appropriate.
  See  for instructions.

[Bug c++/97246] [10/11 regression] mismatched argument pack lengths

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[10.1 regression]   |[10/11 regression]
   |mismatched argument pack|mismatched argument pack
   |lengths |lengths
   Keywords||rejects-valid
  Known to fail||10.1.0
  Known to work||9.3.0
   Target Milestone|--- |10.3

[Bug rtl-optimization/97249] New: Missing vec_select and subreg optimization

[crazylht at gmail dot com via Gcc-bugs]

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

Bug ID: 97249
   Summary: Missing vec_select and subreg optimization
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
CC: hjl.tools at gmail dot com, wwwhhhyyy333 at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Cat test.c
---
void
foo (unsigned char* p1, unsigned char* p2, short* __restrict p3)
{
for (int i = 0 ; i != 8; i++)
 p3[i] = p1[i] + p2[i];
 return;
}
---

gcc11 -Ofast -mavx2 test.c  got

---
foo:
.LFB0:
.cfi_startproc
vmovq   (%rdi), %xmm0
vmovq   (%rsi), %xmm1
vpmovzxbw   %xmm0, %xmm0
vpmovzxbw   %xmm1, %xmm1
vpaddw  %xmm1, %xmm0, %xmm0
vmovdqu %xmm0, (%rdx)
ret
.cfi_endproc
---

memory operand doesn't propagate into *vpmovzxbw* because rtl didn't simplify
---
(insn 9 8 10 2 (set (reg:V8HI 92 [ vect__33.6 ])
(zero_extend:V8HI (vec_select:V8QI (subreg:V16QI (reg:V8QI 91 [
vect__40.5 ]) 0)
(parallel [
(const_int 0 [0])
(const_int 1 [0x1])
(const_int 2 [0x2])
(const_int 3 [0x3])
(const_int 4 [0x4])
(const_int 5 [0x5])
(const_int 6 [0x6])
(const_int 7 [0x7])
] "test.c":5:16 4638 {sse4_1_zero_extendv8qiv8hi2}
 (expr_list:REG_DEAD (reg:V8QI 91 [ vect__40.5 ])
(nil)))
--- 

to 

---
(insn 9 8 10 2 (set (reg:V8HI 92 [ vect__33.6 ])
(zero_extend:V8HI (reg:V8QI 91 [ vect__40.5 ] "test.c":5:16 4638
{sse4_1_zero_extendv8qiv8hi2}
 (expr_list:REG_DEAD (reg:V8QI 91 [ vect__40.5 ])
(nil)))
---

Similar for other vector modes.

[Bug c++/97246] [10/11 regression] mismatched argument pack lengths since r10-7865-gaedd04caa945260e

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-09-30
 Ever confirmed|0   |1
Summary|[10/11 regression]  |[10/11 regression]
   |mismatched argument pack|mismatched argument pack
   |lengths |lengths since
   ||r10-7865-gaedd04caa945260e
 Status|UNCONFIRMED |NEW
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
  Known to fail||11.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r10-7865-gaedd04caa945260e.

[Bug rtl-optimization/97249] Missing vec_select and subreg optimization

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Hongtao.liu  ---
for i386 backend, maybe we can adjust pattern of

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 934b60a288f..2bfa9635fab 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -17658,12 +17658,7 @@ (define_expand "v32qiv32hi2"
 (define_insn "sse4_1_v8qiv8hi2"
   [(set (match_operand:V8HI 0 "register_operand" "=Yr,*x,v")
(any_extend:V8HI
- (vec_select:V8QI
-   (match_operand:V16QI 1 "register_operand" "Yr,*x,v")
-   (parallel [(const_int 0) (const_int 1)
-  (const_int 2) (const_int 3)
-  (const_int 4) (const_int 5)
-  (const_int 6) (const_int 7)]]
+ (subreg:V8QI(match_operand:V16QI 1 "register_operand" "Yr,*x,v")
0)))]
   "TARGET_SSE4_1 &&  && "
   "%vpmovbw\t{%1, %0|%0, %1}"
   [(set_attr "isa" "noavx,noavx,avx")

[Bug rtl-optimization/97249] Missing vec_select and subreg optimization

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #1)
> for i386 backend, maybe we can adjust pattern of
> 
> diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
> index 934b60a288f..2bfa9635fab 100644
> --- a/gcc/config/i386/sse.md
> +++ b/gcc/config/i386/sse.md
> @@ -17658,12 +17658,7 @@ (define_expand "v32qiv32hi2"
>  (define_insn "sse4_1_v8qiv8hi2"
>[(set (match_operand:V8HI 0 "register_operand" "=Yr,*x,v")
> (any_extend:V8HI
> - (vec_select:V8QI
> -   (match_operand:V16QI 1 "register_operand" "Yr,*x,v")
> -   (parallel [(const_int 0) (const_int 1)
> -  (const_int 2) (const_int 3)
> -  (const_int 4) (const_int 5)
> -  (const_int 6) (const_int 7)]]
> + (subreg:V8HI(match_operand:V16QI 1 "register_operand" "Yr,*x,v")
> 0)))]
>"TARGET_SSE4_1 &&  && "
>"%vpmovbw\t{%1, %0|%0, %1}"
>[(set_attr "isa" "noavx,noavx,avx")

Correct typo 
 @@ -17658,12 +17658,7 @@ (define_expand "v32qiv32hi2"
  (define_insn "sse4_1_v8qiv8hi2"
[(set (match_operand:V8HI 0 "register_operand" "=Yr,*x,v")
 (any_extend:V8HI
 - (vec_select:V8QI
 -   (match_operand:V16QI 1 "register_operand" "Yr,*x,v")
 -   (parallel [(const_int 0) (const_int 1)
 -  (const_int 2) (const_int 3)
 -  (const_int 4) (const_int 5)
 -  (const_int 6) (const_int 7)]]
 + (subreg:V8HI (match_operand:V16QI 1 "register_operand" "Yr,*x,v")
> 0)))]

[Bug rtl-optimization/97249] Missing vec_select and subreg optimization

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-09-30
 CC||segher at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #3 from Richard Biener  ---
Guess you want to figure what built the (vec_select:V8QI (V16QI)) and if
it was appropriately simplified (and simplify_rtx would handle this case).
In any case the vec_select is the same as (subreg:V8QI (V16QI)).