[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #28 from cqwrteur  ---
(In reply to Ofer Shinaar from comment #27)
> (In reply to cqwrteur from comment #23)
> > (In reply to Jonathan Wakely from comment #22)
> > > *** Bug 101060 has been marked as a duplicate of this bug. ***
> > 
> > I can confirm Yujie Yang's patch works. Just add -nostdinc++ to configure
> > and configure.ac in gcc root repository (not in gcc subdirectory nor
> > libstdc++-v3 subdirectory)
> > 
> > Yes. So it is very easy to fix.
> 
> and what if I do want to use libstdc++ ? the first soultion allows me that

no. it does not affect how libstdc++ builds. It is a bug in the build process
that the GCC will prefer finding headers in the C++ cross compiler. It should
not use C++ standard library headers in your cross compiler.

Add -nostdinc++ is adding a toggle at the build process that fixes all sorts of
issues that relate to the build of libstdc++.

It won't affect you for using it after the build.

There are some other problems of Canadian compilation here, like copying wrong
DLLs when you build with multilibs. Those are separate issues.

[Bug rtl-optimization/102850] New: [10/11/12 Regression] ICE in begin_move_insn, at sched-ebb.c:196

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 102850
   Summary: [10/11/12 Regression] ICE in begin_move_insn, at
sched-ebb.c:196
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-pc-linux-gnu, aarch64-linux-gnu

Probably a duplicate of PR91161.

gcc-12.0.0-alpha20211017 snapshot (g:5d4d64faa71a6389bfb76bfb3334b63360cf62c0)
ICEs when compiling the following testcase w/ -O2 -fsched2-use-superblocks:

volatile int x;
int y;

int
baz (void);

void
bar (void)
{
  for (;;)
++y;
}

void
foo (int a)
{
  int z;

  if (a && baz ())
{
  z = x;
  bar ();
}
}

% x86_64-pc-linux-gnu-gcc-12.0.0 -O2 -fsched2-use-superblocks -c sakxrhiw.c
during RTL pass: sched2
sakxrhiw.c: In function 'foo':
sakxrhiw.c:24:1: internal compiler error: in begin_move_insn, at
sched-ebb.c:196
   24 | }
  | ^
0x82e8f3 begin_move_insn
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211017/work/gcc-12-20211017/gcc/sched-ebb.c:196
0x82e8f3 begin_move_insn
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211017/work/gcc-12-20211017/gcc/sched-ebb.c:144
0x1bc30f2 commit_schedule
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211017/work/gcc-12-20211017/gcc/haifa-sched.c:6245
0x1bc30f2 schedule_block(basic_block_def**, void*)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211017/work/gcc-12-20211017/gcc/haifa-sched.c:7083
0x1ca13be schedule_ebb(rtx_insn*, rtx_insn*, bool)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211017/work/gcc-12-20211017/gcc/sched-ebb.c:536
0x1ca19c9 schedule_ebbs()
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211017/work/gcc-12-20211017/gcc/sched-ebb.c:655
0xe414bc rest_of_handle_sched2
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211017/work/gcc-12-20211017/gcc/sched-rgn.c:3740
0xe414bc execute
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211017/work/gcc-12-20211017/gcc/sched-rgn.c:3878

[Bug tree-optimization/102744] [12 regression] -O2 vectorization causes Wzero-length-array-bounds-2.c to fail on arc-elf

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

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

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

https://gcc.gnu.org/g:3c8d8c0be95e99dc0cba7f6fad2429243582119f

commit r12-4523-g3c8d8c0be95e99dc0cba7f6fad2429243582119f
Author: liuhongt 
Date:   Thu Oct 14 09:31:03 2021 +0800

Adjust testcase for O2 vectorization.

As discussed in [1], this patch add xfail/target selector to those
testcases, also make a copy of them so that they can be tested w/o
vectorization.

Newly added xfail/target selectors are used to check the vectorization
capability of continuous byte/double bytes storage, these scenarios
are exactly the part of the testcases that regressed after O2
vectorization.

[1] https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581456.html.

2021-10-19  Hongtao Liu  
Kewen Lin  

gcc/ChangeLog

* doc/sourcebuild.texi (Effective-Target Keywords): Document
vect_slp_v2qi_store, vect_slp_v4qi_store, vect_slp_v8qi_store,
vect_slp_v16qi_store, vect_slp_v2hi_store,
vect_slp_v4hi_store, vect_slp_v2si_store, vect_slp_v4si_store.

gcc/testsuite/ChangeLog

PR middle-end/102722
PR middle-end/102697
PR middle-end/102462
PR middle-end/102706
PR middle-end/102744
* c-c++-common/Wstringop-overflow-2.c: Adjust testcase with new
xfail/target selector.
* gcc.dg/Warray-bounds-51.c: Ditto.
* gcc.dg/Warray-parameter-3.c: Ditto.
* gcc.dg/Wstringop-overflow-14.c: Ditto.
* gcc.dg/Wstringop-overflow-21.c: Ditto.
* gcc.dg/Wstringop-overflow-68.c: Ditto.
* gcc.dg/Wstringop-overflow-76.c: Ditto.
* gcc.dg/Warray-bounds-48.c: Ditto.
* gcc.dg/Wzero-length-array-bounds-2.c: Ditto.
* lib/target-supports.exp (check_vect_slp_aligned_store_usage):
New function.
(check_effective_target_vect_slp_v2qi_store): Ditto.
(check_effective_target_vect_slp_v4qi_store): Ditto.
(check_effective_target_vect_slp_v8qi_store): Ditto.
(check_effective_target_vect_slp_v16qi_store): Ditto.
(check_effective_target_vect_slp_v2hi_store): Ditto.
(check_effective_target_vect_slp_v4hi_store): Ditto.
(check_effective_target_vect_slp_v2si_store): Ditto.
(check_effective_target_vect_slp_v4si_store): Ditto.
* c-c++-common/Wstringop-overflow-2-novec.c: New test.
* gcc.dg/Warray-bounds-51-novec.c: New test.
* gcc.dg/Warray-bounds-48-novec.c: New test.
* gcc.dg/Warray-parameter-3-novec.c: New test.
* gcc.dg/Wstringop-overflow-14-novec.c: New test.
* gcc.dg/Wstringop-overflow-21-novec.c: New test.
* gcc.dg/Wstringop-overflow-76-novec.c: New test.
* gcc.dg/Wzero-length-array-bounds-2-novec.c: New test.

[Bug tree-optimization/102706] [12 regression] -O2 vectorization causes regression in Warray-bounds-48.c on many targets

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

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

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

https://gcc.gnu.org/g:3c8d8c0be95e99dc0cba7f6fad2429243582119f

commit r12-4523-g3c8d8c0be95e99dc0cba7f6fad2429243582119f
Author: liuhongt 
Date:   Thu Oct 14 09:31:03 2021 +0800

Adjust testcase for O2 vectorization.

As discussed in [1], this patch add xfail/target selector to those
testcases, also make a copy of them so that they can be tested w/o
vectorization.

Newly added xfail/target selectors are used to check the vectorization
capability of continuous byte/double bytes storage, these scenarios
are exactly the part of the testcases that regressed after O2
vectorization.

[1] https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581456.html.

2021-10-19  Hongtao Liu  
Kewen Lin  

gcc/ChangeLog

* doc/sourcebuild.texi (Effective-Target Keywords): Document
vect_slp_v2qi_store, vect_slp_v4qi_store, vect_slp_v8qi_store,
vect_slp_v16qi_store, vect_slp_v2hi_store,
vect_slp_v4hi_store, vect_slp_v2si_store, vect_slp_v4si_store.

gcc/testsuite/ChangeLog

PR middle-end/102722
PR middle-end/102697
PR middle-end/102462
PR middle-end/102706
PR middle-end/102744
* c-c++-common/Wstringop-overflow-2.c: Adjust testcase with new
xfail/target selector.
* gcc.dg/Warray-bounds-51.c: Ditto.
* gcc.dg/Warray-parameter-3.c: Ditto.
* gcc.dg/Wstringop-overflow-14.c: Ditto.
* gcc.dg/Wstringop-overflow-21.c: Ditto.
* gcc.dg/Wstringop-overflow-68.c: Ditto.
* gcc.dg/Wstringop-overflow-76.c: Ditto.
* gcc.dg/Warray-bounds-48.c: Ditto.
* gcc.dg/Wzero-length-array-bounds-2.c: Ditto.
* lib/target-supports.exp (check_vect_slp_aligned_store_usage):
New function.
(check_effective_target_vect_slp_v2qi_store): Ditto.
(check_effective_target_vect_slp_v4qi_store): Ditto.
(check_effective_target_vect_slp_v8qi_store): Ditto.
(check_effective_target_vect_slp_v16qi_store): Ditto.
(check_effective_target_vect_slp_v2hi_store): Ditto.
(check_effective_target_vect_slp_v4hi_store): Ditto.
(check_effective_target_vect_slp_v2si_store): Ditto.
(check_effective_target_vect_slp_v4si_store): Ditto.
* c-c++-common/Wstringop-overflow-2-novec.c: New test.
* gcc.dg/Warray-bounds-51-novec.c: New test.
* gcc.dg/Warray-bounds-48-novec.c: New test.
* gcc.dg/Warray-parameter-3-novec.c: New test.
* gcc.dg/Wstringop-overflow-14-novec.c: New test.
* gcc.dg/Wstringop-overflow-21-novec.c: New test.
* gcc.dg/Wstringop-overflow-76-novec.c: New test.
* gcc.dg/Wzero-length-array-bounds-2-novec.c: New test.

[Bug tree-optimization/102462] vectorization breaks diagnostic for array out of bound detect.

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

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

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

https://gcc.gnu.org/g:3c8d8c0be95e99dc0cba7f6fad2429243582119f

commit r12-4523-g3c8d8c0be95e99dc0cba7f6fad2429243582119f
Author: liuhongt 
Date:   Thu Oct 14 09:31:03 2021 +0800

Adjust testcase for O2 vectorization.

As discussed in [1], this patch add xfail/target selector to those
testcases, also make a copy of them so that they can be tested w/o
vectorization.

Newly added xfail/target selectors are used to check the vectorization
capability of continuous byte/double bytes storage, these scenarios
are exactly the part of the testcases that regressed after O2
vectorization.

[1] https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581456.html.

2021-10-19  Hongtao Liu  
Kewen Lin  

gcc/ChangeLog

* doc/sourcebuild.texi (Effective-Target Keywords): Document
vect_slp_v2qi_store, vect_slp_v4qi_store, vect_slp_v8qi_store,
vect_slp_v16qi_store, vect_slp_v2hi_store,
vect_slp_v4hi_store, vect_slp_v2si_store, vect_slp_v4si_store.

gcc/testsuite/ChangeLog

PR middle-end/102722
PR middle-end/102697
PR middle-end/102462
PR middle-end/102706
PR middle-end/102744
* c-c++-common/Wstringop-overflow-2.c: Adjust testcase with new
xfail/target selector.
* gcc.dg/Warray-bounds-51.c: Ditto.
* gcc.dg/Warray-parameter-3.c: Ditto.
* gcc.dg/Wstringop-overflow-14.c: Ditto.
* gcc.dg/Wstringop-overflow-21.c: Ditto.
* gcc.dg/Wstringop-overflow-68.c: Ditto.
* gcc.dg/Wstringop-overflow-76.c: Ditto.
* gcc.dg/Warray-bounds-48.c: Ditto.
* gcc.dg/Wzero-length-array-bounds-2.c: Ditto.
* lib/target-supports.exp (check_vect_slp_aligned_store_usage):
New function.
(check_effective_target_vect_slp_v2qi_store): Ditto.
(check_effective_target_vect_slp_v4qi_store): Ditto.
(check_effective_target_vect_slp_v8qi_store): Ditto.
(check_effective_target_vect_slp_v16qi_store): Ditto.
(check_effective_target_vect_slp_v2hi_store): Ditto.
(check_effective_target_vect_slp_v4hi_store): Ditto.
(check_effective_target_vect_slp_v2si_store): Ditto.
(check_effective_target_vect_slp_v4si_store): Ditto.
* c-c++-common/Wstringop-overflow-2-novec.c: New test.
* gcc.dg/Warray-bounds-51-novec.c: New test.
* gcc.dg/Warray-bounds-48-novec.c: New test.
* gcc.dg/Warray-parameter-3-novec.c: New test.
* gcc.dg/Wstringop-overflow-14-novec.c: New test.
* gcc.dg/Wstringop-overflow-21-novec.c: New test.
* gcc.dg/Wstringop-overflow-76-novec.c: New test.
* gcc.dg/Wzero-length-array-bounds-2-novec.c: New test.

[Bug middle-end/102697] [12 Regression] overflow warning missing after -O2 vectorization

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

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

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

https://gcc.gnu.org/g:3c8d8c0be95e99dc0cba7f6fad2429243582119f

commit r12-4523-g3c8d8c0be95e99dc0cba7f6fad2429243582119f
Author: liuhongt 
Date:   Thu Oct 14 09:31:03 2021 +0800

Adjust testcase for O2 vectorization.

As discussed in [1], this patch add xfail/target selector to those
testcases, also make a copy of them so that they can be tested w/o
vectorization.

Newly added xfail/target selectors are used to check the vectorization
capability of continuous byte/double bytes storage, these scenarios
are exactly the part of the testcases that regressed after O2
vectorization.

[1] https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581456.html.

2021-10-19  Hongtao Liu  
Kewen Lin  

gcc/ChangeLog

* doc/sourcebuild.texi (Effective-Target Keywords): Document
vect_slp_v2qi_store, vect_slp_v4qi_store, vect_slp_v8qi_store,
vect_slp_v16qi_store, vect_slp_v2hi_store,
vect_slp_v4hi_store, vect_slp_v2si_store, vect_slp_v4si_store.

gcc/testsuite/ChangeLog

PR middle-end/102722
PR middle-end/102697
PR middle-end/102462
PR middle-end/102706
PR middle-end/102744
* c-c++-common/Wstringop-overflow-2.c: Adjust testcase with new
xfail/target selector.
* gcc.dg/Warray-bounds-51.c: Ditto.
* gcc.dg/Warray-parameter-3.c: Ditto.
* gcc.dg/Wstringop-overflow-14.c: Ditto.
* gcc.dg/Wstringop-overflow-21.c: Ditto.
* gcc.dg/Wstringop-overflow-68.c: Ditto.
* gcc.dg/Wstringop-overflow-76.c: Ditto.
* gcc.dg/Warray-bounds-48.c: Ditto.
* gcc.dg/Wzero-length-array-bounds-2.c: Ditto.
* lib/target-supports.exp (check_vect_slp_aligned_store_usage):
New function.
(check_effective_target_vect_slp_v2qi_store): Ditto.
(check_effective_target_vect_slp_v4qi_store): Ditto.
(check_effective_target_vect_slp_v8qi_store): Ditto.
(check_effective_target_vect_slp_v16qi_store): Ditto.
(check_effective_target_vect_slp_v2hi_store): Ditto.
(check_effective_target_vect_slp_v4hi_store): Ditto.
(check_effective_target_vect_slp_v2si_store): Ditto.
(check_effective_target_vect_slp_v4si_store): Ditto.
* c-c++-common/Wstringop-overflow-2-novec.c: New test.
* gcc.dg/Warray-bounds-51-novec.c: New test.
* gcc.dg/Warray-bounds-48-novec.c: New test.
* gcc.dg/Warray-parameter-3-novec.c: New test.
* gcc.dg/Wstringop-overflow-14-novec.c: New test.
* gcc.dg/Wstringop-overflow-21-novec.c: New test.
* gcc.dg/Wstringop-overflow-76-novec.c: New test.
* gcc.dg/Wzero-length-array-bounds-2-novec.c: New test.

[Bug middle-end/102722] [Disgnostic]Xpass for gcc.dg/Wstringop-overflow-68.c after O2 vectorization.

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

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

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

https://gcc.gnu.org/g:3c8d8c0be95e99dc0cba7f6fad2429243582119f

commit r12-4523-g3c8d8c0be95e99dc0cba7f6fad2429243582119f
Author: liuhongt 
Date:   Thu Oct 14 09:31:03 2021 +0800

Adjust testcase for O2 vectorization.

As discussed in [1], this patch add xfail/target selector to those
testcases, also make a copy of them so that they can be tested w/o
vectorization.

Newly added xfail/target selectors are used to check the vectorization
capability of continuous byte/double bytes storage, these scenarios
are exactly the part of the testcases that regressed after O2
vectorization.

[1] https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581456.html.

2021-10-19  Hongtao Liu  
Kewen Lin  

gcc/ChangeLog

* doc/sourcebuild.texi (Effective-Target Keywords): Document
vect_slp_v2qi_store, vect_slp_v4qi_store, vect_slp_v8qi_store,
vect_slp_v16qi_store, vect_slp_v2hi_store,
vect_slp_v4hi_store, vect_slp_v2si_store, vect_slp_v4si_store.

gcc/testsuite/ChangeLog

PR middle-end/102722
PR middle-end/102697
PR middle-end/102462
PR middle-end/102706
PR middle-end/102744
* c-c++-common/Wstringop-overflow-2.c: Adjust testcase with new
xfail/target selector.
* gcc.dg/Warray-bounds-51.c: Ditto.
* gcc.dg/Warray-parameter-3.c: Ditto.
* gcc.dg/Wstringop-overflow-14.c: Ditto.
* gcc.dg/Wstringop-overflow-21.c: Ditto.
* gcc.dg/Wstringop-overflow-68.c: Ditto.
* gcc.dg/Wstringop-overflow-76.c: Ditto.
* gcc.dg/Warray-bounds-48.c: Ditto.
* gcc.dg/Wzero-length-array-bounds-2.c: Ditto.
* lib/target-supports.exp (check_vect_slp_aligned_store_usage):
New function.
(check_effective_target_vect_slp_v2qi_store): Ditto.
(check_effective_target_vect_slp_v4qi_store): Ditto.
(check_effective_target_vect_slp_v8qi_store): Ditto.
(check_effective_target_vect_slp_v16qi_store): Ditto.
(check_effective_target_vect_slp_v2hi_store): Ditto.
(check_effective_target_vect_slp_v4hi_store): Ditto.
(check_effective_target_vect_slp_v2si_store): Ditto.
(check_effective_target_vect_slp_v4si_store): Ditto.
* c-c++-common/Wstringop-overflow-2-novec.c: New test.
* gcc.dg/Warray-bounds-51-novec.c: New test.
* gcc.dg/Warray-bounds-48-novec.c: New test.
* gcc.dg/Warray-parameter-3-novec.c: New test.
* gcc.dg/Wstringop-overflow-14-novec.c: New test.
* gcc.dg/Wstringop-overflow-21-novec.c: New test.
* gcc.dg/Wstringop-overflow-76-novec.c: New test.
* gcc.dg/Wzero-length-array-bounds-2-novec.c: New test.

[Bug target/102834] gcc.target/i386/avx512f-pr96891-3.c FAILs

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
(In reply to Rainer Orth from comment #1)
> Created attachment 51632 [details]
> 32-bit avx512f-pr96891-3.s

It relies on the existence of the pattern one_cmpldi2_doubleword, so that the
avx512bw_cmpv64qi3 and one_cmpldi2_doubleword will be combined to
avx512bw_cmpv64qi3 w/ adjustment of imm operand, but on 32-bit Solaris/x86 
one_cmpldi2_doubleword  is not existed.

(define_expand "one_cmpl2"
  [(set (match_operand:SWIM1248s 0 "nonimmediate_operand")
(not:SWIM1248s (match_operand:SWIM1248s 1 "nonimmediate_operand")))]

(define_mode_iterator SWIM1248s
[(QI "TARGET_QIMODE_MATH")
 (HI "TARGET_HIMODE_MATH")
 SI (DI "TARGET_64BIT || (TARGET_STV && TARGET_SSE2)")])

mstv
Target Mask(STV) Save
Disable Scalar to Vector optimization pass transforming 64-bit integer
computations into a vector ones.

Guess stv is disabled on on 32-bit Solaris/x86, if that, the fail should be
expected and xfail should be added for 32-bit Solaris/x86

[Bug c++/102846] Misleading suggestion to include cassert

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Jonathan Wakely  ---
The "did you forget to include" diagnostics don't look at the context, they
just do simple string matching of undeclared identifiers against a hardcoded
list of standard names, and suggest a header.

[Bug c/102849] New: missing warning for unsigned bitfield tests for negativity

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

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

Bug ID: 102849
   Summary: missing warning for unsigned bitfield tests for
negativity
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC warns for less than comparisons of unsigned integers to zero but it fails
to do the same for unsigned bit-fields (likely because they promote to int;
comparisons of unsigned bit-fields larger than int are diagnosed by
-Wtype-limits).  Diagnosing both kinds of expressions would be helpful.

$ cat x.c && gcc  -S -Wall -Wextra x.c
struct A
{
  unsigned i, j: 3;
};

void f (struct A *p)
{
  p->i = -1;  // missing warning
  p->j = -1;  // missing warning in C, -Woverflow in C++
}

void g (struct A *p)
{
  if (p->i < 0)   // -Wtype-limits in both C and C++, folded to false
__builtin_abort ();
}

void h (struct A *p)
{
  if (p->j < 0)   // missing warning in both C and C++, folded to false
__builtin_abort ();
}

x.c: In function ‘g’:
x.c:14:12: warning: comparison of unsigned expression in ‘< 0’ is always false
[-Wtype-limits]
   14 |   if (p->i < 0)   // -Wtype-limits in both C and C++, folded to
false
  |^

[Bug c/102848] New: missing warning for bitfield overflow in C

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

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

Bug ID: 102848
   Summary: missing warning for bitfield overflow in C
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

G++ warns when assigning to a bit-field a value that cannot be represented in
the object but GCC does not.

$ cat x.c && /build/gcc-master/gcc/xgcc -B /build/gcc-master/gcc  -S -Wall
-Wextra x.c
struct A
{
  unsigned i, j: 3;
};

void f (struct A *p)
{
  p->i = -1;  // missing warning
  p->j = -1;  // missing warning in C, -Woverflow in C++
}

void g (struct A *p)
{
  if (p->i < 0)   // -Wtype-limits in both C and C++, folded to false
__builtin_abort ();
}

void h (struct A *p)
{
  if (p->j < 0)   // missing warning in both C and C++, folded to false
__builtin_abort ();
}

x.c: In function ‘g’:
x.c:14:12: warning: comparison of unsigned expression in ‘< 0’ is always false
[-Wtype-limits]
   14 |   if (p->i < 0)
  |^

[Bug target/102847] [12 regression] r12-4504 breaks powerpc64 build on power 7

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
  Component|bootstrap   |target
   Keywords||build, ice-on-valid-code

[Bug target/102767] [12 Regression] ICE in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.c:5216

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

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

[Bug target/102372] [12 regression] ICE in gfortran.dg/ISO_Fortran_binding_1.f90 after r12-3482

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
This is a dup of bug 102767 which has much more information in it about what is
going wrong..

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

[Bug bootstrap/102847] [12 regression] r12-4504 breaks powerpc64 build on power 7

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
I highly doubt r12-4504 broke bootstrap on Linux.

Also I suspect it is related to PR 102767.

[Bug bootstrap/102847] New: [12 regression] r12-4504 breaks powerpc64 build on power 7

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

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

Bug ID: 102847
   Summary: [12 regression] r12-4504 breaks powerpc64 build on
power 7
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:e3ef92e79f9f1c4275a9e19652439089a310627d, r12-4504


libtool: compile:  /home/seurer/gcc/git/build/gcc-test/./gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/./gcc/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/sys-include
-DHAVE_CONFIG_H -I. -I/home/seurer/gcc/git/gcc-test/libgfortran
-iquote/home/seurer/gcc/git/gcc-test/libgfortran/io
-I/home/seurer/gcc/git/gcc-test/libgfortran/../gcc
-I/home/seurer/gcc/git/gcc-test/libgfortran/../gcc/config
-I/home/seurer/gcc/git/gcc-test/libgfortran/../libquadmath -I../.././gcc
-I/home/seurer/gcc/git/gcc-test/libgfortran/../libgcc -I../libgcc
-I/home/seurer/gcc/git/gcc-test/libgfortran/../libbacktrace -I../libbacktrace
-I../libbacktrace -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules
-ffunction-sections -fdata-sections -ffast-math -ftree-vectorize -funroll-loops
--param max-unroll-times=4 -g -O2 -MT matmul_i1.lo -MD -MP -MF
.deps/matmul_i1.Tpo -c
/home/seurer/gcc/git/gcc-test/libgfortran/generated/matmul_i1.c  -fPIC -DPIC -o
.libs/matmul_i1.o
during GIMPLE pass: vect
/home/seurer/gcc/git/gcc-test/libgfortran/generated/matmul_i1.c: In function
'matmul_i1':
/home/seurer/gcc/git/gcc-test/libgfortran/generated/matmul_i1.c:2450:1:
internal compiler error: in rs6000_builtin_vectorization_cost, at
config/rs6000/rs6000.c:5176
 2450 | matmul_i1 (gfc_array_i1 * const restrict retarray,
  | ^
0x110b9f47 rs6000_builtin_vectorization_cost
/home/seurer/gcc/git/gcc-trunk/gcc/config/rs6000/rs6000.c:5176
0x10f13547 builtin_vectorization_cost
/home/seurer/gcc/git/gcc-trunk/gcc/tree-vectorizer.h:1520
0x10f13547 record_stmt_cost(vec*, int,
vect_cost_for_stmt, _stmt_vec_info*, tree_node*, int, vect_cost_model_location)
/home/seurer/gcc/git/gcc-trunk/gcc/tree-vect-stmts.c:109
0x10f13f87 record_stmt_cost
/home/seurer/gcc/git/gcc-trunk/gcc/tree-vectorizer.h:1928
0x10f13f87 vect_get_load_cost(vec_info*, _stmt_vec_info*, int,
dr_alignment_support, int, bool, unsigned int*, unsigned int*,
vec*, vec*, bool)
/home/seurer/gcc/git/gcc-trunk/gcc/tree-vect-stmts.c:1240
0x10f3000b vect_model_load_cost
/home/seurer/gcc/git/gcc-trunk/gcc/tree-vect-stmts.c:1195
0x10f3000b vectorizable_load
/home/seurer/gcc/git/gcc-trunk/gcc/tree-vect-stmts.c:8783
0x10f3f55b vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*, _slp_tree*,
_slp_instance*, vec*)
/home/seurer/gcc/git/gcc-trunk/gcc/tree-vect-stmts.c:10963
0x10f5f247 vect_analyze_loop_operations
/home/seurer/gcc/git/gcc-trunk/gcc/tree-vect-loop.c:1779
0x10f61067 vect_analyze_loop_2
/home/seurer/gcc/git/gcc-trunk/gcc/tree-vect-loop.c:2518
0x10f62e17 vect_analyze_loop(loop*, vec_info_shared*)
/home/seurer/gcc/git/gcc-trunk/gcc/tree-vect-loop.c:3029
0x10fa6cbf try_vectorize_loop_1
/home/seurer/gcc/git/gcc-trunk/gcc/tree-vectorizer.c:1010
0x10fa7b9f vectorize_loops()
/home/seurer/gcc/git/gcc-trunk/gcc/tree-vectorizer.c:1249
0x10deb787 execute
/home/seurer/gcc/git/gcc-trunk/gcc/tree-ssa-loop.c:413



commit e3ef92e79f9f1c4275a9e19652439089a310627d (HEAD)
Author: Clment Chigot 
Date:   Thu Oct 14 09:03:13 2021 +0200

aix: ensure reference to __tls_get_addr is in text section.

[Bug c++/102846] New: Misleading suggestion to include cassert

[federico.kircheis at gmail dot com via Gcc-bugs]

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

Bug ID: 102846
   Summary: Misleading suggestion to include cassert
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: federico.kircheis at gmail dot com
  Target Milestone: ---

Consider following snippet (https://godbolt.org/z/9e19bP1Gh)



#include 

template 
auto verify(F f, C1* p1){
f(p1);
return p1;
}

void bar(void* ptr){
// no error here, as cassert is included
assert(true); 

// error here, gcc thinks that cassert is missing
auto v = verify(assert, ptr); 

}


GCC does not compile the program successfully (this is unfortunately correct),
but the diagnostic is misleading:


: In function 'void bar(void*)':
:15:21: error: 'assert' was not declared in this scope
   15 | auto v = verify(assert, ptr);
  | ^~
:2:1: note: 'assert' is defined in header ''; did you forget
to '#include '?
1 | #include 
  +++ |+#include 
2 | 


As assert is a macro and not a function, it cannot be generally used as an
argument of another function.
Thus the error is not the not-missing include.

[Bug d/102837] [12 regression] Many 32-bit gdc tests FAIL

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> It is one of the following:
> g:8088a33df5f62fd6416fb8cb158b791e639aa707

Most likely this one.

[Bug d/102837] [12 regression] Many 32-bit gdc tests FAIL

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

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

--- Comment #1 from Andrew Pinski  ---
It is one of the following:
g:8088a33df5f62fd6416fb8cb158b791e639aa707
g:053234120de7f87b050df78f0d9819ca4214
g:efa5449a094d3887e124d400ff0410af2c745b2d

[Bug fortran/102843] [12 regression] gfortran.dg/deferred_type_param_6.f90 fails after r12-4457

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-10-19
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-October
   ||/581826.html
   Keywords||patch

--- Comment #1 from Andrew Pinski  ---
Fortran front-end issue, see thread
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581826.html .

[Bug fortran/102843] [12 regression] gfortran.dg/deferred_type_param_6.f90 fails after r12-4457

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
   Keywords||wrong-code
  Component|other   |fortran

[Bug rtl-optimization/102842] [10/11/12 Regression] ICE in cselib_record_set at 02 or greater

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[10 Regression] ICE in  |[10/11/12 Regression] ICE
   |cselib_record_set at 02 or  |in cselib_record_set at 02
   |greater |or greater
   Target Milestone|--- |10.4

[Bug fortran/102845] New: Memory leak with nested OpenMP parallelism

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

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

Bug ID: 102845
   Summary: Memory leak with nested OpenMP parallelism
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gcc dot gnu.org
  Target Milestone: ---

The following code seems to cause a memory leak when using nested OpenMP
parallelism when compiled and run with gfortran-12.

module nestedMod

  type :: n
 integer, allocatable, dimension(:) :: i
  end type n

contains

  subroutine nested()
implicit none
type(n), save :: a
!$omp threadprivate(a)

!$omp parallel
if (.not.allocated(a%i)) allocate(a%i(1))
!$omp end parallel
return
  end subroutine nested

end module nestedMod

program nestedLeak
  use :: OMP_Lib, only :  OMP_Set_Nested
  use :: nestedMod
  implicit none
  integer :: i,  unit, valueRSS
  character(len=80)  :: line
  call OMP_Set_Nested(.true.)
  !$omp parallel
  do i=1,1000
 call nested()
 !$omp single
 open(NEWUNIT=unit, FILE='/proc/self/status', ACTION='read')
 do
read (unit, '(a)', END=120) line
if (line(1:6) == 'VmRSS:') then
   read (line(7:), *) valueRSS
   exit
endif
 enddo
120  continue
 close(unit)
 write (0,*) i,valueRSS
 !$omp end single
  end do
  !$omp end parallel

end program


This calls a subroutine from within an OpenMP parallel region. That subroutine
then allocates within its own, nested parallel region. 

The output is (middle parts removed for brevity):

   1  197900
   2  376964
   3  385280
.
.
.
 998 1463436
 999 1466208
1000 1475456


If I set OMP_Set_Nested(.false.) instead then the output is instead:

   1  308304
   2  337852
   3  306816
.
.
.
 998  376840
 999  352196
1000  376848

Running this through valgrind (with the number of iterations reduced to 2 so it
doesn't take too long to run) the output is:

==25999== Memcheck, a memory error detector
==25999== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==25999== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info
==25999== Command: ./a.out
==25999== 
   1  291692
   2  298840
==25999== 
==25999== HEAP SUMMARY:
==25999== in use at exit: 19,850,144 bytes in 516 blocks
==25999==   total heap usage: 979 allocs, 463 frees, 20,201,536 bytes allocated
==25999== 
==25999== 4,800 bytes in 15 blocks are possibly lost in loss record 6 of 10
==25999==at 0x4810218: calloc (vg_replace_malloc.c:1117)
==25999==by 0x3810C11952: _dl_allocate_tls (in /lib64/ld-2.12.so)
==25999==by 0x55845EE: allocate_stack (allocatestack.c:570)
==25999==by 0x55845EE: pthread_create@@GLIBC_2.2.5 (pthread_create.c:453)
==25999==by 0x4EFA4D3: gomp_team_start (team.c:841)
==25999==by 0x4EF251C: GOMP_parallel (parallel.c:169)
==25999==by 0x4017C8: MAIN__ (nested_leak.F90:29)
==25999==by 0x4017FF: main (nested_leak.F90:23)
==25999== 
==25999== 120,000 bytes in 3 blocks are possibly lost in loss record 8 of 10
==25999==at 0x480B7AB: malloc (vg_replace_malloc.c:380)
==25999==by 0x40188E: __nestedmod_MOD_nested._omp_fn.0 (nested_leak.F90:15)
==25999==by 0x4EF9E09: gomp_thread_start (team.c:108)
==25999==by 0x5583C39: start_thread (pthread_create.c:301)
==25999==by 0x586A61C: clone (clone.S:115)
==25999== 
==25999== 19,080,000 bytes in 477 blocks are definitely lost in loss record 10
of 10
==25999==at 0x480B7AB: malloc (vg_replace_malloc.c:380)
==25999==by 0x40188E: __nestedmod_MOD_nested._omp_fn.0 (nested_leak.F90:15)
==25999==by 0x4EF9E09: gomp_thread_start (team.c:108)
==25999==by 0x5583C39: start_thread (pthread_create.c:301)
==25999==by 0x586A61C: clone (clone.S:115)
==25999== 
==25999== LEAK SUMMARY:
==25999==definitely lost: 19,080,000 bytes in 477 blocks
==25999==indirectly lost: 0 bytes in 0 blocks
==25999==  possibly lost: 124,800 bytes in 18 blocks
==25999==still reachable: 645,344 bytes in 21 blocks
==25999== suppressed: 0 bytes in 0 blocks
==25999== Reachable blocks (those to which a pointer was found) are not shown.
==25999== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==25999== 
==25999== For lists of detected and suppressed errors, rerun with: -s
==25999== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 4 from 4)

where valgrind claims the allocations in nested() are definitely lost.

I'm aware that valgrind can report "possibly lost" and "still reachable" blocks
of memory when OpenMP is used (e.g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36298) but this seems like an
actual memory leak as far as I can tell.

[Bug rtl-optimization/102842] [10 Regression] ICE in cselib_record_set at 02 or greater

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
  Component|other   |rtl-optimization
 Ever confirmed|1   |0
   Keywords||ice-on-valid-code

[Bug tree-optimization/102844] [9/10/11/12 Regression] vrp inserting assert causes miscompiling when doing update_ssa

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[9/10/11/12 Regression] |[9/10/11/12 Regression] vrp
   |gcc-9.x miscompiles |inserting assert causes
   |unsigned char expression in |miscompiling when doing
   |switch  |update_ssa

--- Comment #4 from Andrew Pinski  ---
  update_ssa (TODO_update_ssa_no_phi);
Hmm, but there needs to be a phi node here 

Someone who understands VRP's insertation of the asserts and update_ssa better
than me should look into this issue.

Note this is definitely latent on the trunk but can be reproduced on the GCC 9
branch.

[Bug tree-optimization/102844] [9/10/11/12 Regression] gcc-9.x miscompiles unsigned char expression in switch

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

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

--- Comment #3 from Andrew Pinski  ---
> 1a438d160e1dc845882c2ecba99513a09a931623

It was definitely latent before this patch.

[Bug tree-optimization/102844] [9/10/11/12 Regression] gcc-9.x miscompiles unsigned char expression in switch

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

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

--- Comment #2 from Andrew Pinski  ---
Before:
   [local count: 25265782]:
:
  nd.7_11 = _46;
  _12 = _46 + -128;
  _13 = (unsigned char) _12;
  dic = _13;
  goto ; [100.00%]

   [local count: 25265782]:
:
  dic = 0;

   [local count: 114848370]:
  # nd_52 = PHI 
  return nd_52;

   [local count: 25270028]:
  _46 = (signed char) nd_6;
  if (_46 < 0)
goto ; [33.33%]
  else
goto ; [66.67%]


Hmmm:

   [local count: 25270028]:
  nd_36 = ASSERT_EXPR ;
  _46 = (signed char) nd_36;
  if (_46 < 0)
goto ; [33.33%]
  else
goto ; [66.67%]


   [local count: 8423438]:
  _17 = ASSERT_EXPR <_46, _46 < 0>;
  nd_39 = ASSERT_EXPR ;

   [local count: 25265782]:
:
  nd.7_11 = _34(D);
  _12 = _33(D) + -128;
  _13 = (unsigned char) _12;
  dic = _13;
  goto ; [100.00%]

   [local count: 16846590]:
  nd_45 = ASSERT_EXPR  127>;


Hmm, no phi node at bb 13 for _46 

[Bug rtl-optimization/102840] [12 Regression] gcc.target/i386/pr22076.c by r12-4475

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

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

H.J. Lu  changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com

--- Comment #4 from H.J. Lu  ---
Avoid MMX register isn't a bad thing.  I think we should adjust test
to check that MMX register isn't used.

[Bug tree-optimization/102844] [9/10/11/12 Regression] gcc-9.x miscompiles unsigned char expression in switch

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Target Milestone|--- |9.5
   Last reconfirmed||2021-10-19
Summary|gcc-9.x miscompiles |[9/10/11/12 Regression]
   |unsigned char expression in |gcc-9.x miscompiles
   |switch  |unsigned char expression in
   ||switch
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
So the problem first shows up in .vrp2.
  nd.7_11 = _34(D);
  _12 = _33(D) + -128;
  _13 = (unsigned char) _12;

Before:
   [local count: 25265782]:
:
  nd.7_11 = _46;
  _12 = _46 + -128;
  _13 = (unsigned char) _12;
  dic = _13;

This happens during the insertation of the assert statements.
I don't think there has been any known issues like this before.

[Bug c/102844] New: gcc-9.x miscompiles unsigned char expression in switch

[breiten at lexmark dot com via Gcc-bugs]

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

Bug ID: 102844
   Summary: gcc-9.x miscompiles unsigned char expression in switch
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: breiten at lexmark dot com
  Target Milestone: ---

The code included below demonstrates a code-generation bug we found in gcc-9.3
(built with poky's dunfell branch) It is present in all of the 9.x releases,
but none of the 10.x releases.

Anticipating your first question, I found that this problem is NOT present
in gcc-10.2, so I went earlier in that branch and was able to see that it
was corrected by 744fd446c321f78f9a1ce4ef5f83df8dcfa44a9 (gcc-10 branch,
but before gcc-10.1 release) Nothing in the commit messages suggests a
bug fix.

I've also been able to pinpoint the commit where the problem first appears
in the gcc-9 branch: 1a438d160e1dc845882c2ecba99513a09a931623.  Here, the
commit message describes this commit to be a bug fix.

My dilemma is that I'm stuck in the 9 branch for a while.  Reverting a bug
fix doesn't feel right. But while picking up the commit from gcc-10 does
appear to work, it a bit more than a simple bug-fix, and I'd like to hear
some opinions regarding its appropriateness.

Maybe there it still a bug out there, and the commit from gcc-10 just makes
this particular code compile properly.

In the C source below, line 58 miscompiles into an unconditional store of
0x80.  Notice that I have two switch statements on the same variable and
with the same cases.  If I remove or alter the other one, the bad code and
the warning goes away.  It also is only present when "nd - 0x80" is stored
to a uchar variable.  If its stored to an int or printf'd the code is correct.
Also, adding "U" suffix to 0x80 corrects the expression.  And I get the warning
regardless of what number I subtract from nd, suggesting that it is incorrectly
considered a signed char, and subtracting anything would underflow.

I see the problem with -Os or -O2, and -fno-strict-overflow is needed.  In
cleaning up the command line, I found that linux adds -Wno-maybe-uninitialized.
Removing that leads to this message:

attach3.c:60:22: warning: '({anonymous})' may be used uninitialized in this
function [-Wmaybe-uninitialized]
   58 | *ic = nd - 0x80; /* compiles into an unconditional store of
0x80 */
  |   ~~~^~

Here's my gcc configuration:
Target: arm-poky-linux-gnueabi
Configured with: ../../../../../../work-shared/gcc-9.3.0-r0/gcc-9.3.0/configure
--build=x86_64-linux --host=x86_64-linux --target=arm-poky-linux-gnueabi
--prefix=/host-native/usr --exec_prefix=/host-native/usr
--bindir=/host-native/usr/bin/arm-poky-linux-gnueabi
--sbindir=/host-native/usr/bin/arm-poky-linux-gnueabi
--libexecdir=/host-native/usr/libexec/arm-poky-linux-gnueabi
--datadir=/host-native/usr/share --sysconfdir=/host-native/etc
--sharedstatedir=/host-native/com --localstatedir=/host-native/var
--libdir=/host-native/usr/lib/arm-poky-linux-gnueabi
--includedir=/host-native/usr/include --oldincludedir=/host-native/usr/include
--infodir=/host-native/usr/share/info --mandir=/host-native/usr/share/man
--disable-silent-rules --disable-dependency-tracking
--with-libtool-sysroot=/host-native --enable-clocale=generic --with-gnu-ld
--enable-shared --enable-languages=c,c++ --enable-threads=posix
--disable-multilib --enable-default-pie --enable-c99 --enable-long-long
--enable-symvers=gnu --enable-libstdcxx-pch
--program-prefix=arm-poky-linux-gnueabi- --without-local-prefix
--disable-install-libiberty --enable-lto --disable-libssp --enable-libitm
--disable-bootstrap --disable-libmudflap --with-system-zlib
--with-linker-hash-style=sysv --enable-linker-build-id --with-ppl=no
--with-cloog=no --enable-checking=release --enable-cheaders=c_global
--without-isl --with-gxx-include-dir=/not/exist/usr/include/c++/9.3.0
--with-sysroot=/not/exist --with-build-sysroot=/host
--enable-poison-system-directories --with-system-zlib --disable-static
--disable-nls --with-glibc-version=2.28 --enable-initfini-array
Thread model: posix
gcc version 9.3.0 (GCC)


<< code to demonstrate problem >>
typedef struct
{
  void (*request)(int request, void *arg);
} po_t;

po_t *po;
unsigned char *ambp(void);
unsigned char da;
unsigned char dic;

unsigned char gnda(unsigned char current_address, int sequence);
void rnsm(void);
int state = 0;
static unsigned char *attach_mb_ptr;
static unsigned char ta;
static unsigned char lda;

static unsigned char snod(unsigned char cd, unsigned char *tl, unsigned char
*ic)
{
   unsigned char nd;
   while ((nd = gnda(cd,0)) != 0x21)
   {
  int Req;
  po->request(57, );
  if (!Req)
 break;
   }
   if (nd != 0x21)
   {
  switch (nd)
  {
 case 0x95:
*tl = 0x01;
break;

 case 0x80:
 

[Bug rtl-optimization/102840] [12 Regression] gcc.target/i386/pr22076.c by r12-4475

[roger at nextmovesoftware dot com via Gcc-bugs]

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

--- Comment #3 from Roger Sayle  ---
With -m64, before:
test:   movq.LC1(%rip), %mm0
paddb   .LC0(%rip), %mm0
movq%xmm0, x(%rip)
ret

And after:
test:   movq.LC2(%rip), %rax
movq%rax, x(%rip)
ret

So we have two movq before, and two movq after, but clearly we've avoided the
computation at run-time.

It's difficult (for me) to judge whether the -m32's use of immediate constants
is now better than -m64's load memory/store memory idiom in the "average case",
but worst case [data cache miss], the former is clearly better [requiring only
fewer memory transactions].

[Bug bootstrap/102828] [12 Regression] ODR violation in gimple-predicate-analysis.h since g:94c12ffac234

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Martin Sebor  ---
Both classes are defined in a header and used in .c/.cc files so they both need
to be public.  One either needs to be renamed or put in some namespace.

The predicate defined in ipa-predicate.h is used by IPA (ipa-fnsummary.c and
ipa-predicate.c), the one in gimple-predicate-analysis.h only by
-Wuninitialized for now (tree-ssa-uninit.c) with the goal of being used by
other middle end warnings in the future. 

It would be easier for me to rename the one in gimple-predicate-analysis.h but
I'm not coming up with a good name.  On the other hand, it seems that the one
in ipa-predicate.h could well be named ipa_predicate.  Wrapping all IPA types
and functions in their own namespace (like ipa) seems even more appealing to me
but it would be a lot of churn, probably too much at this point.

Honza, your thoughts/preference?

[Bug other/102843] New: [12 regression] gfortran.dg/deferred_type_param_6.f90 fails after r12-4457

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

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

Bug ID: 102843
   Summary: [12 regression] gfortran.dg/deferred_type_param_6.f90
fails after r12-4457
   Product: gcc
   Version: 12.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:99b287b8ef51a0be52f7400879a619dc5f993f31, r12-4457
make  -k check-gcc-fortran
RUNTESTFLAGS="dg.exp=gfortran.dg/deferred_type_param_6.f90"
FAIL: gfortran.dg/deferred_type_param_6.f90   -O1  execution test
FAIL: gfortran.dg/deferred_type_param_6.f90   -Os  execution test
# of expected passes10
# of unexpected failures2


spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/deferred_type_param_6.f90
-fdiagnostics-plain-output -fdiagnostics-plain-output -Os -pedantic-errors
-B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libatomic/.libs
-B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-lm -o ./deferred_type_param_6.exe
PASS: gfortran.dg/deferred_type_param_6.f90   -Os  (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libatomic/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../..:.:/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libatomic/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../..:/home/seurer/gcc/git/build/gcc-test/./gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./isl/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-isl/.libs
Execution timeout is: 300
spawn [open ...]
STOP 3
FAIL: gfortran.dg/deferred_type_param_6.f90   -Os  execution test


commit 99b287b8ef51a0be52f7400879a619dc5f993f31 (HEAD, refs/bisect/bad)
Author: Jan Hubicka 
Date:   Sat Oct 16 14:45:06 2021 +0200

Fix wrong code in ldost-strlen-1.c

[Bug c++/31573] -Wall-all to enable all warnings

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #12 from Eric Gallager  ---
I'd like to repeat my suggestion from bug 66293 comment #6: what if
-Weverything always printed at least 1 warning from itself ("Warning: Don't use
-Weverything [-Weverything]") in addition to all the other warnings that it
enables? That way people would be less tempted to try to use it with -Werror.

[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails

[ofer.shinaar at wdc dot com via Gcc-bugs]

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

--- Comment #27 from Ofer Shinaar  ---
(In reply to cqwrteur from comment #23)
> (In reply to Jonathan Wakely from comment #22)
> > *** Bug 101060 has been marked as a duplicate of this bug. ***
> 
> I can confirm Yujie Yang's patch works. Just add -nostdinc++ to configure
> and configure.ac in gcc root repository (not in gcc subdirectory nor
> libstdc++-v3 subdirectory)
> 
> Yes. So it is very easy to fix.

and what if I do want to use libstdc++ ? the first soultion allows me that

[Bug testsuite/102841] libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c FAILs

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

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

Thomas Schwinge  changed:

   What|Removed |Added

  Component|libgomp |testsuite
   Keywords||openacc
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
   Last reconfirmed||2021-10-19
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Thomas Schwinge  ---
Thanks for the report, I'll have a look (next month).

(In reply to Rainer Orth from comment #0)
> The libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c has been
> FAILing
> on Solaris and Darwin since it was installed.

Probably not since it was originally added in commit
d5c23c6ceacf666f218676b648801379044e326a 'OpenACC – support "if" + "if_present"
clauses with "host_data"', but rather in my more recentish commit
11b8286a83289f5b54e813f14ff56d730c3f3185 "[OpenACC privatization] Largely
extend diagnostics and corresponding testsuite coverage [PR90115]".  (Or, if it
indeed has been FAILing before, then it must be a different problem.)

> On Solaris, the excess errors are

> [...]: note: variable 'iftmp.3' declared in block isn't candidate for 
> adjusting OpenACC privatization level: not addressable

> while Darwin shows

> [...]: note: variable 'D.3648' declared in block isn't candidate for 
> adjusting OpenACC privatization level: not addressable

Please do tell if there are further such "[is/isn't] candidate for adjusting
OpenACC privatization level" diagnostic mismatches (excess errors, or FAILs),
in other testcases.  (But indeed per a quick scan of
 posts, it's just
'libgomp.oacc-c-c++-common/host_data-7.c', and it PASSed before my
"diagnostics" commit.)

[Bug c/66918] Disable "inline function declared but never defined" warning

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

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

Eric Gallager  changed:

   What|Removed |Added

 Blocks||44209
 CC||egallager at gcc dot gnu.org

--- Comment #10 from Eric Gallager  ---
This is an instance of bug 44209


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209
[Bug 44209] [meta-bug] Some warnings are not linked to diagnostics options

[Bug c/90690] Undocumented -Werror-implicit-function-declaration

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

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

--- Comment #3 from Eric Gallager  ---
(In reply to sandra from comment #2)
> I think this has been fixed?  In a recent-ish trunk build, I see gcc -Q
> --help-warning prints
> 
>   -Werror-implicit-function-declaration
> -Werror=implicit-function-declaration
> 
> whereas in GCC 9 it just printed
> 
>   -Werror-implicit-function-declaration

Tim, can you confirm?

[Bug target/101893] There is no vgbbd on p7

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Paul Clarke :

https://gcc.gnu.org/g:3cfbe5dc08b574bccc398256946cc03e2a767329

commit r12-4514-g3cfbe5dc08b574bccc398256946cc03e2a767329
Author: Paul A. Clarke 
Date:   Mon Aug 9 13:08:25 2021 -0500

rs6000: Guard some x86 intrinsics implementations

Some compatibility implementations of x86 intrinsics include
Power intrinsics which require POWER8.  Guard them.

emmintrin.h:
- _mm_cmpord_pd: Remove code which was ostensibly for pre-POWER8,
  but which indeed depended on POWER8 (vec_cmpgt(v2du)/vcmpgtud).
  The "POWER8" version works fine on pre-POWER8.
- _mm_mul_epu32: vec_mule(v4su) uses vmuleuw.
pmmintrin.h:
- _mm_movehdup_ps: vec_mergeo(v4su) uses vmrgow.
- _mm_moveldup_ps: vec_mergee(v4su) uses vmrgew.
smmintrin.h:
- _mm_cmpeq_epi64: vec_cmpeq(v2di) uses vcmpequd.
- _mm_mul_epi32: vec_mule(v4si) uses vmuluwm.
- _mm_cmpgt_epi64: vec_cmpgt(v2di) uses vcmpgtsd.
tmmintrin.h:
- _mm_sign_epi8: vec_neg(v4si) uses vsububm.
- _mm_sign_epi16: vec_neg(v4si) uses vsubuhm.
- _mm_sign_epi32: vec_neg(v4si) uses vsubuwm.
  Note that the above three could actually be supported pre-POWER8,
  but current GCC does not support them before POWER8.
- _mm_sign_pi8: depends on _mm_sign_epi8.
- _mm_sign_pi16: depends on _mm_sign_epi16.
- _mm_sign_pi32: depends on _mm_sign_epi32.

sse4_2-pcmpgtq.c:
- _mm_cmpgt_epi64: vec_cmpeq(v2di) uses vcmpequd.

2021-10-19  Paul A. Clarke  

gcc
PR target/101893
PR target/102719
* config/rs6000/emmintrin.h: Guard POWER8 intrinsics.
* config/rs6000/pmmintrin.h: Same.
* config/rs6000/smmintrin.h: Same.
* config/rs6000/tmmintrin.h: Same.

gcc/testsuite
* gcc.target/powerpc/sse4_2-pcmpgtq.c: Tighten dg constraints
to minimally Power8.

[Bug testsuite/102719] [12 regression] several failures after r12-4337

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Paul Clarke :

https://gcc.gnu.org/g:3cfbe5dc08b574bccc398256946cc03e2a767329

commit r12-4514-g3cfbe5dc08b574bccc398256946cc03e2a767329
Author: Paul A. Clarke 
Date:   Mon Aug 9 13:08:25 2021 -0500

rs6000: Guard some x86 intrinsics implementations

Some compatibility implementations of x86 intrinsics include
Power intrinsics which require POWER8.  Guard them.

emmintrin.h:
- _mm_cmpord_pd: Remove code which was ostensibly for pre-POWER8,
  but which indeed depended on POWER8 (vec_cmpgt(v2du)/vcmpgtud).
  The "POWER8" version works fine on pre-POWER8.
- _mm_mul_epu32: vec_mule(v4su) uses vmuleuw.
pmmintrin.h:
- _mm_movehdup_ps: vec_mergeo(v4su) uses vmrgow.
- _mm_moveldup_ps: vec_mergee(v4su) uses vmrgew.
smmintrin.h:
- _mm_cmpeq_epi64: vec_cmpeq(v2di) uses vcmpequd.
- _mm_mul_epi32: vec_mule(v4si) uses vmuluwm.
- _mm_cmpgt_epi64: vec_cmpgt(v2di) uses vcmpgtsd.
tmmintrin.h:
- _mm_sign_epi8: vec_neg(v4si) uses vsububm.
- _mm_sign_epi16: vec_neg(v4si) uses vsubuhm.
- _mm_sign_epi32: vec_neg(v4si) uses vsubuwm.
  Note that the above three could actually be supported pre-POWER8,
  but current GCC does not support them before POWER8.
- _mm_sign_pi8: depends on _mm_sign_epi8.
- _mm_sign_pi16: depends on _mm_sign_epi16.
- _mm_sign_pi32: depends on _mm_sign_epi32.

sse4_2-pcmpgtq.c:
- _mm_cmpgt_epi64: vec_cmpeq(v2di) uses vcmpequd.

2021-10-19  Paul A. Clarke  

gcc
PR target/101893
PR target/102719
* config/rs6000/emmintrin.h: Guard POWER8 intrinsics.
* config/rs6000/pmmintrin.h: Same.
* config/rs6000/smmintrin.h: Same.
* config/rs6000/tmmintrin.h: Same.

gcc/testsuite
* gcc.target/powerpc/sse4_2-pcmpgtq.c: Tighten dg constraints
to minimally Power8.

[Bug rtl-optimization/102840] [12 Regression] gcc.target/i386/pr22076.c by r12-4475

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

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

--- Comment #2 from H.J. Lu  ---
(In reply to Roger Sayle from comment #1)
> I believe this test case is poorly written, and not correctly testing the
> original issue in PR target/22076 which concerned suboptimal moving of
> arguments via memory (fixed by prohibiting reload using mmx registers).
> 
> Prior to my patch, with -m32 -O2 -fomit-frame-pointer -mmmx -mno-sse2, GCC
> generated:
> 
> test:   movq.LC1, %mm0
> paddb   .LC0, %mm0
> movq%mm0, x
> ret
> 
> .x: .zero 8
> .LC0:   .byte   1
> .byte   2
> .byte   3
> .byte   4
> .byte   5
> .byte   6
> .byte   7
> .byte   8
> .LC1:   .byte   11
> .byte   22
> .byte   33
> .byte   44
> .byte   55
> .byte   66
> .byte   77
> .byte   88
> 
> which indeed doesn't use movl, and requires two movq.
> 
> After my patch, we now generate the much more efficient (dare I say optimal):
> test:   movl$807671820, %eax
> movl$1616136252, %edx
> movl%eax, x
> movl%edx, x+4
> ret
> 
> which has evaluated the _mm_add_pi8 at compile-time, and effectively memsets
> x to the correct value in the minimum possible number of cycles.  In fact,
> failing to evaluate this at compile-time is a regression since v4.1
> (according to godbolt)

If your analysis is correct, why does -m64 stay the same?

[Bug target/102783] [powerpc] FPSCR manipulations cannot be relied upon

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #9 from joseph at codesourcery dot com  ---
On Tue, 19 Oct 2021, segher at gcc dot gnu.org via Gcc-bugs wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102783
> 
> --- Comment #8 from Segher Boessenkool  ---
> (In reply to jos...@codesourcery.com from comment #6)
> > Generically (and if the command-line options are such that floating-point 
> > control / status bits are to be respected by optimizations), *any* 
> > function call might access or modify floating-point control and status 
> > bits, subject to e.g. const functions not being able to access them, pure 
> > functions not being able to modify them, functions whose body is known 
> > having properties based on analysis of that body, built-in functions 
> > having semantics based on what the compiler knows about those functions.  
> 
> If FENV_ACCESS is OFF most of those things can be ignored as well.  But
> FENV_ACCESS is much too blunt a hammer for most of our uses.

My recent discussions with Roger Sayle 
, 
and bug 54192 as referenced therein, may be helpful for more details of 
how FENV_ACCESS could be split up.  (At present we have -ftrapping-math, 
on by default, and -frounding-math, off by default.  I suspect that if 
-ftrapping-math really restricted optimizations enough to avoid all 
problematic code reordering / removal in the presence of function calls 
possibly reading and writing exception flags, it would actually inhibit 
optimization more than a full implementation of -frounding-math would: a 
full -frounding-math only means that arithmetic *reads* the rounding mode, 
whereas a full -ftrapping-math means that arithmetic *writes* to the 
exception flags.)

[Bug other/102842] [10 Regression] ICE in cselib_record_set at 02 or greater

[herrtimson at yahoo dot de via Gcc-bugs]

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

--- Comment #3 from tt_1  ---
sure I can provide happily gcc -v of host: 

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/10.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-10.3.0-r2/work/gcc-10.3.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/10.3.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/10.3.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/10.3.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/10.3.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.0/include/g++-v10
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/10.3.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 10.3.0-r2 p3'
--disable-esp --enable-libstdcxx-time --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point
--enable-targets=all --enable-libgomp --disable-libssp --disable-libada
--disable-systemtap --enable-vtable-verify --without-zstd --enable-lto
--without-isl --disable-libsanitizer --enable-default-pie --enable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.3.0 (Gentoo 10.3.0-r2 p3) 

and cross-gcc: 

LANG=C armv7a-unknown-linux-gnueabihf-gcc -v
Using built-in specs.
COLLECT_GCC=armv7a-unknown-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7a-unknown-linux-gnueabihf/10.3.0/lto-wrapper
Target: armv7a-unknown-linux-gnueabihf
Configured with:
/var/tmp/portage/cross-armv7a-unknown-linux-gnueabihf/gcc-10.3.0-r2/work/gcc-10.3.0/configure
--host=x86_64-pc-linux-gnu --target=armv7a-unknown-linux-gnueabihf
--build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/armv7a-unknown-linux-gnueabihf/gcc-bin/10.3.0
--includedir=/usr/lib/gcc/armv7a-unknown-linux-gnueabihf/10.3.0/include
--datadir=/usr/share/gcc-data/armv7a-unknown-linux-gnueabihf/10.3.0
--mandir=/usr/share/gcc-data/armv7a-unknown-linux-gnueabihf/10.3.0/man
--infodir=/usr/share/gcc-data/armv7a-unknown-linux-gnueabihf/10.3.0/info
--with-gxx-include-dir=/usr/lib/gcc/armv7a-unknown-linux-gnueabihf/10.3.0/include/g++-v10
--with-python-dir=/share/gcc-data/armv7a-unknown-linux-gnueabihf/10.3.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 10.3.0-r2 p3'
--disable-esp --enable-libstdcxx-time --enable-poison-system-directories
--with-sysroot=/usr/armv7a-unknown-linux-gnueabihf --disable-bootstrap
--enable-__cxa_atexit --enable-clocale=gnu --disable-multilib
--disable-fixed-point --with-float=hard --with-arch=armv7-a --with-float=hard
--with-fpu=vfpv3-d16 --enable-libgomp --disable-libssp --disable-libada
--disable-systemtap --disable-vtable-verify --disable-libvtv --without-zstd
--enable-lto --without-isl --enable-default-pie --enable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.3.0 (Gentoo 10.3.0-r2 p3) 


I am not sure what you mean by asking for compiler options, but I can give you
the exact command that fails, it should have all details in it: 

/usr/bin/armv7a-unknown-linux-gnueabihf-g++ --sysroot
/usr/armv7a-unknown-linux-gnueabihf -std=gnu++17 -o dec_reconstruct.o -c 
-I/usr/armv7a-unknown-linux-gnueabihf/tmp/portage/www-client/firefox-95.0/work/firefox_build/dist/stl_wrappers
-I/usr/armv7a-unknown-linux-gnueabihf/tmp/portage/www-client/firefox-95.0/work/firefox_build/dist/system_wrappers
-include
/usr/armv7a-unknown-linux-gnueabihf/tmp/portage/www-client/firefox-95.0/work/firefox-95.0/config/gcc_hidden.h
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -DNDEBUG=1
-DTRIMMED=1 -DJPEGXL_MAJOR_VERSION=0 -DJPEGXL_MINOR_VERSION=0
-DJPEGXL_PATCH_VERSION=0 -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL
-DSTATIC_EXPORTABLE_JS_API
-I/usr/armv7a-unknown-linux-gnueabihf/tmp/portage/www-client/firefox-95.0/work/firefox-95.0/media/libjxl
-I/usr/armv7a-unknown-linux-gnueabihf/tmp/portage/www-client/firefox-95.0/work/firefox_build/media/libjxl
-I/usr/armv7a-unknown-linux-gnueabihf/tmp/portage/www-client/firefox-95.0/work/firefox-95.0/media/libjxl/include
-I/usr/armv7a-unknown-linux-gnueabihf/tmp/portage/www-client/firefox-95.0/work/firefox-95.0/third_party/jpeg-xl

[Bug other/102842] [10 Regression] ICE in cselib_record_set at 02 or greater

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-10-19
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |WAITING

--- Comment #2 from Martin Liška  ---
Can you please provide compiler options used for the compilation.
And gcc -v output?

[Bug rtl-optimization/102840] [12 Regression] gcc.target/i386/pr22076.c by r12-4475

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

   Last reconfirmed||2021-10-19
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Roger Sayle  ---
I believe this test case is poorly written, and not correctly testing the
original issue in PR target/22076 which concerned suboptimal moving of
arguments via memory (fixed by prohibiting reload using mmx registers).

Prior to my patch, with -m32 -O2 -fomit-frame-pointer -mmmx -mno-sse2, GCC
generated:

test:   movq.LC1, %mm0
paddb   .LC0, %mm0
movq%mm0, x
ret

.x: .zero 8
.LC0:   .byte   1
.byte   2
.byte   3
.byte   4
.byte   5
.byte   6
.byte   7
.byte   8
.LC1:   .byte   11
.byte   22
.byte   33
.byte   44
.byte   55
.byte   66
.byte   77
.byte   88

which indeed doesn't use movl, and requires two movq.

After my patch, we now generate the much more efficient (dare I say optimal):
test:   movl$807671820, %eax
movl$1616136252, %edx
movl%eax, x
movl%edx, x+4
ret

which has evaluated the _mm_add_pi8 at compile-time, and effectively memsets x
to the correct value in the minimum possible number of cycles.  In fact,
failing to evaluate this at compile-time is a regression since v4.1 (according
to godbolt)

[p.s. I predict other platforms might also notice changes in their testsuites,
as the middle-end now generates more efficient instruction sequences].

[Bug other/102842] [10 Regression] ICE in cselib_record_set at 02 or greater

[herrtimson at yahoo dot de via Gcc-bugs]

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

--- Comment #1 from tt_1  ---
Created attachment 51635
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51635=edit
preprocessed source

[Bug other/102842] New: [10 Regression] ICE in cselib_record_set at 02 or greater

[herrtimson at yahoo dot de via Gcc-bugs]

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

Bug ID: 102842
   Summary: [10 Regression] ICE in cselib_record_set at 02 or
greater
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: herrtimson at yahoo dot de
  Target Milestone: ---

Created attachment 51634
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51634=edit
compressed build log

I'm hitting this when compiling firefox nightly with --enable-jxl, using
gcc-10.3.0 cross-compiler with amd64 host and armv7a target. Affected are -02
and -03, -01 is fine. It is unknown wether the error is cross compile specific,
my rpi2 device doesn't have near enough ram to compile firefox with native gcc
on it. Anyway, here is the error message: 

23:39.63   |  ^~
23:41.47 during RTL pass: postreload
23:41.47
/usr/armv7a-unknown-linux-gnueabihf/tmp/portage/www-client/firefox-95.0/work/firefox-95.0/third_party/jpeg-xl/lib/jxl/dec_reconstruct.cc:
In function 'jxl::Status jxl::FinalizeImageRect(jxl::Image3F*, const
jxl::Rect&, const std::vector*, jxl::Rect> >&,
jxl::PassesDecoderState*, size_t, jxl::ImageBundle*, const jxl::Rect&)':
23:41.47
/usr/armv7a-unknown-linux-gnueabihf/tmp/portage/www-client/firefox-95.0/work/firefox-95.0/third_party/jpeg-xl/lib/jxl/dec_reconstruct.cc:1080:1:
internal compiler error: in cselib_record_set, at cselib.c:2614
23:41.47  1080 | }
23:41.47   | ^
23:41.80 In file included from
/usr/armv7a-unknown-linux-gnueabihf/tmp/portage/www-client/firefox-95.0/work/firefox_build/dist/include/nsTArray.h:3331,
23:41.80  from
/usr/armv7a-unknown-linux-gnueabihf/tmp/portage/www-client/firefox-95.0/work/firefox-95.0/netwerk/cache2/CacheIOThread.h:11,
23:41.80  from
/usr/armv7a-unknown-linux-gnueabihf/tmp/portage/www-client/firefox-95.0/work/firefox-95.0/netwerk/cache2/CacheFileIOManager.h:8,
23


the souce code in question can be accessed via this link:
https://github.com/mozilla/gecko-dev/blob/master/third_party/jpeg-xl/lib/jxl/dec_reconstruct.cc#L1080

[Bug libgomp/102838] [12 regression] Several tests SEGV in gomp_loop_ull_init

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2021-10-19
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #3 from Jakub Jelinek  ---
Created attachment 51633
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51633=edit
gcc12-pr102838.patch

Very lightly tested patch.  This does two things, for orphaned construct when
GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC is defined uses gomp_aligned_alloc rather
than gomp_malloc even for the single workshare allocation, because when we have
the aligned attribute in there, the compiler is right to assume that alignment.
And if the macro isn't defined (i.e. OS doesn't have working posix_memalign,
memalign, aligned_alloc etc.) instead of having aligned attribute in the
structure it just makes sure that the second half starts on a 64-byte boundary.

[Bug tree-optimization/102832] [12 Regression] ICE in vect_create_partial_epilog with -O3 -msve-vector-bits=128

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |12.0

[Bug testsuite/102833] [12 regression] gcc.dg/vect/bb-slp-17.c FAILs

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2021-10-19
 CC||rguenth at gcc dot gnu.org
  Component|tree-optimization   |testsuite
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  I think i386 misses V2SImode vectorization (there's a duplicate bug
somewhere I think).

We need to somehow capture this in a dg-effective-target

[Bug rtl-optimization/102840] [12 Regression] gcc.target/i386/pr22076.c by r12-4475

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 Target||x86_64-*-* i?86-*-*

[Bug libgomp/102841] libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c FAILs

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug libgomp/102841] New: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c FAILs

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

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

Bug ID: 102841
   Summary: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_dat
a-7.c FAILs
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, tschwinge at gcc dot gnu.org
  Target Milestone: ---
Target: i?86-pc-solaris2.11, x86_64-pc-solaris2.11,
i?86-apple-darwin*, x86_64-apple-darwin*

The libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c has been
FAILing
on Solaris and Darwin since it was installed.

FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable  -O2  (test for
excess errors)
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/host_data-7.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable  -O2  (test for
excess errors)

On Solaris, the excess errors are

Excess errors:
/vol/gcc/src/hg/master/local/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c:21:9:
note: variable 'iftmp.3' declared in block isn't candidate for adjusting
OpenACC privatization level: not addressable
/vol/gcc/src/hg/master/local/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c:26:9:
note: variable 'iftmp.6' declared in block isn't candidate for adjusting
OpenACC privatization level: not addressable
/vol/gcc/src/hg/master/local/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c:33:9:
note: variable 'iftmp.9' declared in block isn't candidate for adjusting
OpenACC privatization level: not addressable
/vol/gcc/src/hg/master/local/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c:44:9:
note: variable 'iftmp.12' declared in block isn't candidate for adjusting
OpenACC privatization level: not addressable
/vol/gcc/src/hg/master/local/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c:55:9:
note: variable 'iftmp.15' declared in block isn't candidate for adjusting
OpenACC privatization level: not addressable

while Darwin shows

Excess errors:
/vol/gcc/src/hg/master/darwin/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c:21:9:
note: variable 'D.3648' declared in block isn't candidate for adjusting OpenACC
privatization level: not addressable
/vol/gcc/src/hg/master/darwin/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c:21:9:
note: variable 'D.3649' declared in block isn't candidate for adjusting OpenACC
privatization level: not addressable
/vol/gcc/src/hg/master/darwin/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c:21:9:
note: variable 'D.3650' declared in block isn't candidate for adjusting OpenACC
privatization level: not addressable
/vol/gcc/src/hg/master/darwin/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c:33:9:
note: variable 'D.3662' declared in block isn't candidate for adjusting OpenACC
privatization level: not addressable
/vol/gcc/src/hg/master/darwin/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c:33:9:
note: variable 'D.3663' declared in block isn't candidate for adjusting OpenACC
privatization level: not addressable
/vol/gcc/src/hg/master/darwin/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/host_data-7.c:33:9:
note: variable 'D.3664' declared in block isn't candidate for adjusting OpenACC
privatization level: not addressable
[...]

[Bug tree-optimization/102829] Redundant null check after atomic load from that address

[laurynas.biveinis at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Laurynas Biveinis  ---
FWIW adding "if (this == nullptr) __builtin_unreachable();" between
__atomic_load_n and return fails to workaround this issue

[Bug libgomp/102838] [12 regression] Several tests SEGV in gomp_loop_ull_init

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

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

--- Comment #2 from Jakub Jelinek  ---
Actually no, I'm wrong, there is
gomp_mutex_t lock __attribute__((aligned (64)));
in the middle of the structure, so the start of the structure is 64-byte
aligned.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

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

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

Bug 93183 Summary: SVE does not use neg as conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93183

   What|Removed |Added

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

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

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

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

Bug 93183 Summary: SVE does not use neg as conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93183

   What|Removed |Added

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

[Bug target/93183] SVE does not use neg as conditional

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/102840] New: [12 Regression] gcc.target/i386/pr22076.c by r12-4475

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

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

Bug ID: 102840
   Summary: [12 Regression] gcc.target/i386/pr22076.c by r12-4475
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: roger at nextmovesoftware dot com
  Target Milestone: ---

On Linux/x86-64, r12-4475 caused:

$ make check-gcc RUNTESTFLAGS="--target_board='unix{-m32}' i386.exp=pr22076.c"
...
FAIL: gcc.target/i386/pr22076.c scan-assembler-not movl
FAIL: gcc.target/i386/pr22076.c scan-assembler-times movq 2

[Bug fortran/93963] Select rank mishandling allocatable and pointer arguments with bind(c)

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

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

Tobias Burnus  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
 CC||burnus at gcc dot gnu.org

--- Comment #9 from Tobias Burnus  ---
Close as FIXED (in GCC 12) by the big patch.

I tried the full testcases of the submitted patch (PR93308.f90  PR93963.f90 
PR94327.c  PR94327.f90  PR94331.c  PR94331.f90  PR97046.f90) and also 

Thanks José for report and testcases - and again sorry for no prompt review of
your patches.
(It helps to ping them regularly.)

[Bug libstdc++/95048] [9/10/11/12 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters

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

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

--- Comment #12 from Jonathan Wakely  ---
(In reply to Christian Fersch from comment #9)
> But is it possible to query the value of -fwide-exec-charset? I had quick
> look and couldn't find anything.

It's possible now: __GNUC_WIDE_EXECUTION_CHARSET_NAME

https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html

[Bug fortran/92482] BIND(C) with array-descriptor mishandled for type character

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #10 from Tobias Burnus  ---
Close as FIXED (in GCC 12) now that also the remaining issue is solved :-)

Thanks again for the report!

[Bug libstdc++/102839] filesystem::path::wstring runs in C locale / practically always throws

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

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

--- Comment #4 from Martin Liška  ---
(In reply to Jonathan Wakely from comment #2)
> Martin, did you use -stdlib=libc++ with Clang? Otherwise you're just testing
> libstdc++ again with a different compiler.

I didn't, my bad. Will do it next time.
Thanks.

[Bug libstdc++/102839] filesystem::path::wstring runs in C locale / practically always throws

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

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

--- Comment #3 from Jonathan Wakely  ---
This is the same issue as PR 95048 comment 3 describes.

[Bug fortran/92482] BIND(C) with array-descriptor mishandled for type character

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

https://gcc.gnu.org/g:6920d5a1a2834e9c62d441b8f4c6186b01107d13

commit r12-4505-g6920d5a1a2834e9c62d441b8f4c6186b01107d13
Author: Tobias Burnus 
Date:   Tue Oct 19 15:16:01 2021 +0200

Fortran: Fix "str" to scalar descriptor conversion [PR92482]

PR fortran/92482
gcc/fortran/ChangeLog:

* trans-expr.c (gfc_conv_procedure_call): Use TREE_OPERAND not
build_fold_indirect_ref_loc to undo an ADDR_EXPR.

gcc/testsuite/ChangeLog:

* gfortran.dg/bind-c-char-descr.f90: Remove xfail; extend a bit.

[Bug libstdc++/102839] filesystem::path::wstring runs in C locale / practically always throws

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #2 from Jonathan Wakely  ---
Martin, did you use -stdlib=libc++ with Clang? Otherwise you're just testing
libstdc++ again with a different compiler.

Libc++ does not throw on this testcase for me.

(The test is invalid though, it needs to include  to use
std::setlocale, but that's not the problem)

[Bug target/102835] gcc.target/i386/avx512fp16-trunchf.c FAILs

[wwwhhhyyy333 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Hongyu Wang  ---
(In reply to Rainer Orth from comment #0)

> 
> I wonder what's the best way to handle the difference?  Just add
> -fomit-frame-pointer
> to the testcase or allow for the %ebp vs. %esp difference?

For this test we just want to check mnemonics are properly generated, so I
think we can allow either esp/ebp output for different system.

[Bug libstdc++/102839] filesystem::path::wstring runs in C locale / practically always throws

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-10-19
 CC||marxin at gcc dot gnu.org,
   ||redi at gcc dot gnu.org
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Are you sure it's a valid testcase?
Apparently, clang also throws an exception.

[Bug libgomp/102838] [12 regression] Several tests SEGV in gomp_loop_ull_init

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

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

--- Comment #1 from Jakub Jelinek  ---
Possibly triggered by enabling vectorization at -O2?
long long should for ia32 inside of structures (at least on linux but I think
it is the same for solaris too) have just 32-bit alignment and nothing else in
struct gomp_work_share should result in 64-bit alignment of the structure, so
if the vectorizer (slp?) decides to use aligned 128-bit store, something is
wrong...

[Bug libstdc++/102839] New: filesystem::path::wstring runs in C locale / practically always throws

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 102839
   Summary: filesystem::path::wstring runs in C locale /
practically always throws
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
  Target Milestone: ---

► cat x.cpp
#include 
#include 
#include 
namespace fs = std::filesystem;
int main()
{
const char localeName[] = "ja_JP.UTF-8";
std::setlocale(LC_ALL, localeName);
std::locale::global(std::locale(localeName));
fs::path p(u8"壊した");
std::wcout << p.wstring() << L'\n';
}
 g++ -v x.cpp
Using built-in specs.
Reading specs from /usr/lib64/gcc/x86_64-suse-linux/11/defaults.spec
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d,jit
--enable-offload-targets=nvptx-none,amdgcn-amdhsa, --without-cuda-driver
--enable-host-shared --enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/11 --enable-ssp --disable-libssp
--disable-libvtv --enable-cet=auto --disable-libcc1 --enable-plugin
--with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-libphobos
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-11 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic
--with-build-config=bootstrap-lto-lean --enable-link-mutex
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.1 20210816 [revision 056e324ce46a7924b5cf10f61010cf9dd2ca10e9]
(SUSE Linux) 

► ./a.out 
terminate called after throwing an instance of
'std::filesystem::__cxx11::filesystem_error'
  what():  filesystem error: Cannot convert character sequence: Invalid or
incomplete multibyte or wide character
Aborted (core dumped)

Single-stepping through a -ggdb3 build reveals these code fragments in
libstdc++ which suggest that codecvt<> always operates in C locale:

(x.cpp)
step into
<< p.wstring() <<

leads to

#0  0x77e58f09 in std::codecvt::codecvt
(this=0x7fffdb30, __refs=0) at
../../../../../libstdc++-v3/src/c++98/codecvt.cc:118
116 #ifdef _GLIBCXX_USE_WCHAR_T
117   // codecvt required specialization
118   codecvt::
119   codecvt(size_t __refs)
120   : __codecvt_abstract_base(__refs),
*121   _M_c_locale_codecvt(_S_get_c_locale())
122   { }

std::codecvt::do_max_length (this=0x7fffdb50)
at codecvt_members.cc:220
217   int
218   codecvt::
219   do_max_length() const throw()
220   {
221 #if __GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ > 2)
*222 __c_locale __old = __uselocale(_M_c_locale_codecvt);
223 #endif
224 // XXX Probably wrong for stateful encodings.
225 int __ret = MB_CUR_MAX;
226 #if __GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ > 2)
227 __uselocale(__old);
228 #endif
229 return __ret;
230   }

[Bug libgomp/102838] [12 regression] Several tests SEGV in gomp_loop_ull_init

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug libgomp/102838] New: [12 regression] Several tests SEGV in gomp_loop_ull_init

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

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

Bug ID: 102838
   Summary: [12 regression] Several tests SEGV in
gomp_loop_ull_init
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
Target: i?86-pc-solaris2.11, x86_64-pc-solaris2.11

Between 20211007 (5c1838c01652a403498e27024cb0e5ea66376353) and 20211008
(db3d7270b42fe27fb05664c4fdf524ab7ad13a75),
quite a number of libgomp testcases began to FAIl on 32-bit Solaris/x86 only:

FAIL: libgomp.c++/../libgomp.c-c++-common/for-1.c execution test
FAIL: libgomp.c++/../libgomp.c-c++-common/for-11.c execution test
FAIL: libgomp.c++/../libgomp.c-c++-common/for-12.c execution test
FAIL: libgomp.c++/../libgomp.c-c++-common/for-14.c execution test
FAIL: libgomp.c++/../libgomp.c-c++-common/for-15.c execution test
FAIL: libgomp.c++/../libgomp.c-c++-common/for-2.c execution test
FAIL: libgomp.c++/../libgomp.c-c++-common/for-5.c execution test
FAIL: libgomp.c++/../libgomp.c-c++-common/for-6.c execution test
FAIL: libgomp.c++/../libgomp.c-c++-common/for-7.c execution test
FAIL: libgomp.c++/../libgomp.c-c++-common/for-8.c execution test
FAIL: libgomp.c++/../libgomp.c-c++-common/task-reduction-11.c execution test
FAIL: libgomp.c++/loop-11.C execution test
FAIL: libgomp.c++/loop-8.C execution test

FAIL: libgomp.c/../libgomp.c-c++-common/for-1.c execution test
FAIL: libgomp.c/../libgomp.c-c++-common/for-16.c execution test
FAIL: libgomp.c/../libgomp.c-c++-common/for-2.c execution test
FAIL: libgomp.c/../libgomp.c-c++-common/for-3.c execution test
FAIL: libgomp.c/../libgomp.c-c++-common/for-7.c execution test
FAIL: libgomp.c/../libgomp.c-c++-common/for-8.c execution test
FAIL: libgomp.c/../libgomp.c-c++-common/for-9.c execution test
FAIL: libgomp.c/../libgomp.c-c++-common/lastprivate-conditional-1.c execution
test
FAIL: libgomp.c/../libgomp.c-c++-common/lastprivate-conditional-5.c execution
test
FAIL: libgomp.c/../libgomp.c-c++-common/monotonic-2.c execution test
FAIL: libgomp.c/../libgomp.c-c++-common/nonmonotonic-2.c execution test
FAIL: libgomp.c/../libgomp.c-c++-common/task-reduction-11.c execution test
FAIL: libgomp.c/loop-12.c execution test
FAIL: libgomp.c/loop-6.c execution test

FAIL: libgomp.fortran/pointer2.f90   -O2  execution test

I manually built the C version of for-1.c.  Running it works, but when
I add OMP_NUM_THREADS=8 as happens during a regular make check, the test
SEGVs:

Thread 9 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0xfe5d7fc8 in gomp_loop_ull_init (chunk_size=32, sched=GFS_GUIDED, incr=2,
end=2147486647, start=2147483647, up=true, ws=0x80774b8) at
/vol/gcc/src/hg/master/local/libgomp/loop_ull.c:48
48ws->end_ull = ((up && start > end) || (!up && start < end))

=> 0xfe5d7fc8 : movaps %xmm0,0x10(%esi)

(gdb) p/x $esi
$1 = 0x80774b8

(gdb) where
#0  0xfe5d7fc8 in gomp_loop_ull_init (chunk_size=32, sched=GFS_GUIDED, incr=2,
end=2147486647, start=2147483647, up=true, ws=0x80774b8) at
/vol/gcc/src/hg/master/local/libgomp/loop_ull.c:48
#1  gomp_loop_ull_guided_start (up=true, start=2147483647, end=2147486647,
incr=2, chunk_size=32, istart=0xfeffd910, iend=0xfeffd918) at
/vol/gcc/src/hg/master/local/libgomp/loop_ull.c:157
#2  0x080600bd in f1_f_guided32 ()
#3  0x08061105 in test_f_guided32 ()
#4  0xfeffda80 in ?? ()
#5  0x08062c63 in main ()

Obviously %esi isn't properly aligned, which lets me suspect this is an i386
bug and not libgomp proper.

[Bug gcov-profile/102746] gcov returns 0 un erroneuos incovation

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

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

--- Comment #10 from Martin Liška  ---
(In reply to Илья Шипицин from comment #9)
> ok, so we'll migrate to gcc-12 :)

Yes, but please wait for the release of 12.1 that will happen at the end of
April 2022.

In the meantime, you can port to GCC 11.2 and cherry-pick the patch.

[Bug tree-optimization/102832] [12 Regression] ICE in vect_create_partial_epilog with -O3 -msve-vector-bits=128

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

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

Alex Coplan  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #1 from Alex Coplan  ---
Started with r12-2739-g5a1017dc, FWIW:

commit 5a1017dc305c49c59129d45536630d02dbc01c45
Author: Richard Sandiford 
Date:   Wed Aug 4 16:52:09 2021

vect: Tweak comparisons with existing epilogue loops

[Bug target/102375] [aarch64] Should allow space in target attribute

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Implemented.

[Bug target/102375] [aarch64] Should allow space in target attribute

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

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

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

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

commit r12-4503-g6b34f5c5ec75823d656b6882f12d46248402a2aa
Author: Martin Liska 
Date:   Tue Oct 19 11:11:16 2021 +0200

target: Support whitespaces in target attr/pragma.

PR target/102375

gcc/ChangeLog:

* config/aarch64/aarch64.c (aarch64_process_one_target_attr):
Strip whitespaces.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/pr102375.c: New test.

[Bug d/102837] [12 regression] Many 32-bit gdc tests FAIL

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug d/102837] New: [12 regression] Many 32-bit gdc tests FAIL

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

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

Bug ID: 102837
   Summary: [12 regression] Many 32-bit gdc tests FAIL
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: i?86-pc-solaris2.11, x86_64-pc-solaris2.11

Between 20210930 (ef37ddf477ac4b21ec4d1be9260cfd3b431fd4a9) and 20211001
(701075864ac4d1c6cec936d10f9cfc2aeb8c1699),
a large number of testsuite regressions occured on 32-bit Solaris/x86:

FAIL: gdc.test/runnable/closure.d -shared-libphobos   execution test
FAIL: gdc.test/runnable/eh.d -O2 -fPIC -shared-libphobos   execution test
FAIL: gdc.test/runnable/eh.d -O2 -shared-libphobos   execution test
FAIL: gdc.test/runnable/eh.d -fPIC -shared-libphobos   execution test
FAIL: gdc.test/runnable/eh.d -shared-libphobos   execution test
FAIL: gdc.test/runnable/eh2.d -fPIC -shared-libphobos   execution test
FAIL: gdc.test/runnable/eh2.d -shared-libphobos   execution test
FAIL: gdc.test/runnable/foreach5.d -shared-libphobos   execution test
FAIL: gdc.test/runnable/opover2.d -O2 -finline-functions -shared-libphobos  
execution test
FAIL: gdc.test/runnable/opover2.d -O2 -shared-libphobos   execution test
FAIL: gdc.test/runnable/opover2.d -finline-functions -shared-libphobos  
execution test
FAIL: gdc.test/runnable/opover2.d -shared-libphobos   execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -finline-functions -frelease
-funittest -g -shared-libphobos   execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -finline-functions -frelease
-funittest -shared-libphobos   execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -finline-functions -frelease -g
-shared-libphobos   execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -finline-functions -frelease
-shared-libphobos   execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -finline-functions -funittest -g
-shared-libphobos   execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -finline-functions -funittest
-shared-libphobos   execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -finline-functions -g
-shared-libphobos   execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -finline-functions -shared-libphobos 
 execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -frelease -funittest -g
-shared-libphobos   execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -frelease -funittest
-shared-libphobos   execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -frelease -g -shared-libphobos  
execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -frelease -shared-libphobos  
execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -funittest -g -shared-libphobos  
execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -funittest -shared-libphobos  
execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -g -shared-libphobos   execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -fPIC -shared-libphobos   execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -finline-functions -frelease -funittest -g
-shared-libphobos   execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -finline-functions -frelease -funittest
-shared-libphobos   execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -finline-functions -frelease -g
-shared-libphobos   execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -finline-functions -frelease
-shared-libphobos   execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -finline-functions -funittest -g
-shared-libphobos   execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -finline-functions -funittest
-shared-libphobos   execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -finline-functions -g -shared-libphobos  
execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -finline-functions -shared-libphobos  
execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -frelease -funittest -g -shared-libphobos  
execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -frelease -funittest -shared-libphobos  
execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -frelease -g -shared-libphobos   execution
test
FAIL: gdc.test/runnable/sdtor.d -O2 -frelease -shared-libphobos   execution
test
FAIL: gdc.test/runnable/sdtor.d -O2 -funittest -g -shared-libphobos   execution
test
FAIL: gdc.test/runnable/sdtor.d -O2 -funittest -shared-libphobos   execution
test
FAIL: gdc.test/runnable/sdtor.d -O2 -g -shared-libphobos   execution test
FAIL: gdc.test/runnable/sdtor.d -O2 -shared-libphobos   execution test
FAIL: gdc.test/runnable/sdtor.d -fPIC -finline-functions -frelease -funittest
-g -shared-libphobos   execution test
FAIL: gdc.test/runnable/sdtor.d -fPIC -finline-functions -frelease -funittest
-shared-libphobos   execution test
FAIL: gdc.test/runnable/sdtor.d -fPIC -finline-functions -frelease -g
-shared-libphobos   execution test
FAIL: gdc.test/runnable/sdtor.d -fPIC -finline-functions -frelease

[Bug target/102836] gcc.target/i386/pieces-memset-1.c etc. FAIL

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

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

--- Comment #1 from H.J. Lu  ---
(In reply to Rainer Orth from comment #0)
> It turns out that this happens because 32-bit Solaris/x86 only guarantees
> 4-byte stack alignment following the i386 psABI, so defaults to
> -mstackrealign.
> 
> Adding -mno-stackrealign to one test lets the output match what I get on
> Linux/x86.  I suspect that's the best option?

Yes, I agree.

[Bug target/102836] gcc.target/i386/pieces-memset-1.c etc. FAIL

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug target/102836] New: gcc.target/i386/pieces-memset-1.c etc. FAIL

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

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

Bug ID: 102836
   Summary: gcc.target/i386/pieces-memset-1.c etc. FAIL
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: hjl.tools at gmail dot com
  Target Milestone: ---
Target: i?86-pc-solaris2.11, x86_64-pc-solaris2.11

Some gcc.target/i386/pieces-memset-*.c tests have been FAILing on 32-bit
Solaris/x86
since they were installed:

FAIL: gcc.target/i386/pieces-memset-1.c scan-assembler-not %[re]bp
FAIL: gcc.target/i386/pieces-memset-4.c scan-assembler-not %[re]bp
FAIL: gcc.target/i386/pieces-memset-41.c scan-assembler-not %[re]bp
FAIL: gcc.target/i386/pieces-memset-7.c scan-assembler-not %[re]bp
FAIL: gcc.target/i386/pieces-memset-8.c scan-assembler-not %[re]bp

It turns out that this happens because 32-bit Solaris/x86 only guarantees
4-byte stack alignment following the i386 psABI, so defaults to -mstackrealign.

Adding -mno-stackrealign to one test lets the output match what I get on
Linux/x86.  I suspect that's the best option?

[Bug target/102835] gcc.target/i386/avx512fp16-trunchf.c FAILs

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug target/102835] New: gcc.target/i386/avx512fp16-trunchf.c FAILs

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

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

Bug ID: 102835
   Summary: gcc.target/i386/avx512fp16-trunchf.c FAILs
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: wwwhhhyyy333 at gmail dot com
  Target Milestone: ---
Target: i?86-pc-solaris2.11, x86_64-pc-solaris2.11

The gcc.target/i386/avx512fp16-trunchf.c test has been FAILing on 32-bit
Solaris/x86
since it was installed:

FAIL: gcc.target/i386/avx512fp16-trunchf.c scan-assembler-times vcvttsh2si[
t]+[^{\\n]*(?:%xmm[0-9]|(%esp))+, %eax(?:\\n|[ t]+#) 3
FAIL: gcc.target/i386/avx512fp16-trunchf.c scan-assembler-times vcvttsh2usi[
t]+[^{\\n]*(?:%xmm[0-9]|(%esp))+, %eax(?:\\n|[ t]+#) 2

On Solaris, the assembler output contains

vcvttsh2si  8(%ebp), %eax
vcvttsh2si  8(%ebp), %eax
vcvttsh2si  8(%ebp), %eax

vcvttsh2usi 8(%ebp), %eax
vcvttsh2usi 8(%ebp), %eax

while Linux has

vcvttsh2si  4(%esp), %eax
vcvttsh2si  4(%esp), %eax
vcvttsh2si  4(%esp), %eax

vcvttsh2usi 4(%esp), %eax
vcvttsh2usi 4(%esp), %eax

As it turns out, the difference occurs because Solaris/x86 default to
-fno-omit-frame-pointer.  With -fomit-frame-pointer added, the output matches.

I wonder what's the best way to handle the difference?  Just add
-fomit-frame-pointer
to the testcase or allow for the %ebp vs. %esp difference?

[Bug target/102834] gcc.target/i386/avx512f-pr96891-3.c FAILs

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug target/102834] gcc.target/i386/avx512f-pr96891-3.c FAILs

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

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

--- Comment #1 from Rainer Orth  ---
Created attachment 51632
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51632=edit
32-bit avx512f-pr96891-3.s

[Bug target/102834] New: gcc.target/i386/avx512f-pr96891-3.c FAILs

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

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

Bug ID: 102834
   Summary: gcc.target/i386/avx512f-pr96891-3.c FAILs
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: crazylht at gmail dot com
  Target Milestone: ---
Target: i?86-pc-solaris2.11, x86_64-pc-solaris2.11

The gcc.target/i386/avx512f-pr96891-3.c test has been FAILing on 32-bit
Solaris/x86
since it was installed:

FAIL: gcc.target/i386/avx512f-pr96891-3.c scan-assembler-times (?n)vpcmp[bwdq][
t]*\$7 4

The pattern only occurs 3 times instead of the expected 4.  Attaching the
assembler output for reference.

[Bug tree-optimization/102833] [12 regression] gcc.dg/vect/bb-slp-17.c FAILs

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug tree-optimization/102833] New: [12 regression] gcc.dg/vect/bb-slp-17.c FAILs

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

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

Bug ID: 102833
   Summary: [12 regression] gcc.dg/vect/bb-slp-17.c FAILs
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: i?86-*-*, x86_64-*-*, mips*-mti-elf

Between 20210925 (9a4293ed9bdd029dd44d19b412b1cdf12372801e) and 20210927
(dd11aab6463880c35d942c4a4fd346fdaeeb8e72),
gcc.dg/vect/bb-slp-17.c regressed on 32-bit x86 and mips:

FAIL: gcc.dg/vect/bb-slp-17.c -flto -ffat-lto-objects  scan-tree-dump-times
slp2 "optimized: basic block" 1
FAIL: gcc.dg/vect/bb-slp-17.c scan-tree-dump-times slp2 "optimized: basic
block" 1

[Bug libstdc++/102825] std::move_only_function's implementation breaking existing code

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Fixed now, thanks for the report.

[Bug libstdc++/102825] std::move_only_function's implementation breaking existing code

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:9890b12c72c02828c691f22198c3e0afd8678991

commit r12-4500-g9890b12c72c02828c691f22198c3e0afd8678991
Author: Jonathan Wakely 
Date:   Tue Oct 19 09:16:56 2021 +0100

libstdc++: Fix mem-initializer in std::move_only_function [PR102825]

libstdc++-v3/ChangeLog:

PR libstdc++/102825
* include/bits/mofunc_impl.h (move_only_function): Remove
invalid base initializer.
* testsuite/20_util/move_only_function/cons.cc: Instantiate
constructors to check bodies.

[Bug target/102783] [powerpc] FPSCR manipulations cannot be relied upon

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

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

--- Comment #8 from Segher Boessenkool  ---
(In reply to jos...@codesourcery.com from comment #6)
> Generically (and if the command-line options are such that floating-point 
> control / status bits are to be respected by optimizations), *any* 
> function call might access or modify floating-point control and status 
> bits, subject to e.g. const functions not being able to access them, pure 
> functions not being able to modify them, functions whose body is known 
> having properties based on analysis of that body, built-in functions 
> having semantics based on what the compiler knows about those functions.  

If FENV_ACCESS is OFF most of those things can be ignored as well.  But
FENV_ACCESS is much too blunt a hammer for most of our uses.

> And then a subset of asms may similarly access or modify them (based on 
> inputs / outputs / clobbers, but maybe on some architectures existing 
> practice doesn't provide a register name that inputs / outputs / clobbers 
> can use to refer to floating-point state).

Like PowerPC.  But we *do* model vscr (vector status and control register).
It won't be hard to add fpscr.

> Then you'd need something like Marc Glisse's -ffenv-access patches (August 
> 2020) to represent the other side of things, how floating-point operations 
> also access / modify such bits.

Yeah, we need something for normal computational FP insns to clobber (on
PowerPC load/store insns never change the fpscr / fenv, but I bet that is
different on other archs).

Thanks for the pointer, I'll find Marc's work.

[Bug tree-optimization/102832] New: [12 Regression] ICE in vect_create_partial_epilog with -O3 -msve-vector-bits=128

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

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

Bug ID: 102832
   Summary: [12 Regression] ICE in vect_create_partial_epilog with
-O3 -msve-vector-bits=128
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

The following fails:

$ cat t.c
int a, b;
char c;
signed char d(int e, int f) { return e - f; }
void g() {
  a = 0;
  for (; a >= -17; a = d(a, 1))
c ^= b;
}
$ aarch64-linux-gnu-gcc -c t.c -march=armv8.2-a+sve -O3 -msve-vector-bits=128
during GIMPLE pass: vect
t.c: In function ‘g’:
t.c:4:6: internal compiler error: in vect_create_partial_epilog, at
tree-vect-loop.c:5038
4 | void g() {
  |  ^
0x1156110 vect_create_partial_epilog
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-loop.c:5035
0x1164be3 vect_transform_cycle_phi(_loop_vec_info*, _stmt_vec_info*, gimple**,
_slp_tree*, _slp_instance*)
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-loop.c:7772
0x1150a1c vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-stmts.c:11107
0x1174723 vect_transform_loop(_loop_vec_info*, gimple*)
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-loop.c:9731
0x11b0f44 try_vectorize_loop_1
/home/alecop01/toolchain/src/gcc/gcc/tree-vectorizer.c:
0x11b1662 try_vectorize_loop_1
/home/alecop01/toolchain/src/gcc/gcc/tree-vectorizer.c:1148
0x11b170b try_vectorize_loop
/home/alecop01/toolchain/src/gcc/gcc/tree-vectorizer.c:1168
0x11b19e9 vectorize_loops()
/home/alecop01/toolchain/src/gcc/gcc/tree-vectorizer.c:1249
0x1030ef3 execute
/home/alecop01/toolchain/src/gcc/gcc/tree-ssa-loop.c:413
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/102745] CLASS → TYPE check fails after RESHAPE

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #3 from Tobias Burnus  ---
FIXED (for GCC 11 + 12).

[Bug fortran/92482] BIND(C) with array-descriptor mishandled for type character

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

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #8 from Tobias Burnus  ---
The BIND(C) issue is fixed - but I keep this PR open as there is still an issue
with the non-bind(C) part. Namely:

   testsuite/gfortran.dg/bind-c-char-descr.f90

fails for:

...
  subroutine strg_print_2(this, xfail)
if(associated(strn))then
  if (len (strn) /= 3) stop 31
  if (strn /= "abc") then
if (present (xfail)) then
  print *, 'INVALID STRING - EXPECTED "abc" / PR47225' ! <<< PR is
wrong :-/
else
  stop 32
end if

The call has:

scalar.4 = 97;   // that's  'a' -> expected: "abc".
desc.3.dtype = {.elem_len=1, .rank=0, .type=1}; // not the elem_len=1;
should be len*kind
desc.3.data = (void *) 
desc.3.span = (integer(kind=8)) desc.3.dtype.elem_len;

[Bug fortran/101309] Bind(C): gfortran creates invalid C descriptor for result of TRANSPOSE intrinsic

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

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||burnus at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Tobias Burnus  ---
FIXED (in GCC 12)

Note: TRANSPOSE now yields an descriptor where the dimension are swapped, i.e.
dim[0].sm > dim[1].sm, unless the dummy argument has to be contiguous.

Otherwise, the testsuite passes now.

(For SHAPE and polymorphism with RESHAPE and nested TRANSPOSE, other PRs
exists.)

[Bug fortran/101308] Bind(C): gfortran does not create C descriptors for scalar pointer/allocatable arguments

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #3 from Tobias Burnus  ---
FIXED (in GCC 12)

The committed c-interop / TS29113 testsuite now passes – and the testcase from
comment 0 gives:

{
  integer(kind=4) * p;

  p = 0B;
  {
struct CFI_cdesc_t00 cfi.0;

cfi.0.version = 1;
cfi.0.rank = 0;
cfi.0.type = 1025;
cfi.0.attribute = 0;
cfi.0.base_addr = (void *) p;
cfi.0.elem_len = 4;
ctest ();
p = (integer(kind=4) *) cfi.0.base_addr;
  }
}

[Bug tree-optimization/102827] [12 Regression] ICE: verify_ssa failed (error: definition in block 20 does not dominate use in block 19) since r12-4398-g9b2ad21ab3ebc21a

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/102827] [12 Regression] ICE: verify_ssa failed (error: definition in block 20 does not dominate use in block 19) since r12-4398-g9b2ad21ab3ebc21a

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

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

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

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

commit r12-4498-gd996799a507f9f4c379b55b004233be92fa63380
Author: Richard Biener 
Date:   Tue Oct 19 10:19:12 2021 +0200

tree-optimization/102827 - avoid stmts in preheader

The PR shows that when carefully crafting the runtime alias
condition in the vectorizer we might end up using defs from
the loop preheader but will end up inserting the condition
before the .LOOP_VECTORIZED call.  So the following makes
sure to insert invariants before that when we versioned the
loop, preserving the invariant the vectorizer relies on.

2021-10-19  Richard Biener  

PR tree-optimization/102827
* tree-if-conv.c (predicate_statements): Add pe parameter
and use that edge to insert invariant stmts on.
(combine_blocks): Pass through pe.
(tree_if_conversion): Compute the edge to insert invariant
stmts on and pass it along.

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

[Bug target/102783] [powerpc] FPSCR manipulations cannot be relied upon

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

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

--- Comment #7 from Segher Boessenkool  ---
(In reply to Richard Biener from comment #5)
> Even out-of-line does not help if there are visible CSE/association
> opportunities across such call.

Yeah, good point.

> A workaround is to make the out-of-line
> function __attribute__((returns_twice)) which should insert artificial
> control flow
> preventing such transforms.

Is there anything that guarantees that to work (other than our actual
current implementation)?  It is much more stringent / expensive than we
would want, but if it is the best we can do...

[Bug fortran/92284] Subroutine with bind(c) attribute causing varied problems

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

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

Bug 92189 Summary: Fortran-written bind(C) function with allocatable argument 
does not update C descriptor on exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92189

   What|Removed |Added

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