[Bug tree-optimization/104510] New: ICE: 'verify_gimple' failed: mismatching comparison operand types in verify_gimple_in_seq()

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 104510
   Summary: ICE: 'verify_gimple' failed: mismatching comparison
operand types in verify_gimple_in_seq()
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc testcase.c
testcase.c: In function 'foo':
testcase.c:5:1: error: mismatching comparison operand types
5 | foo (void)
  | ^~~
_Decimal32
_Decimal64
_4 = _2 < d.1_3;
testcase.c:5:1: internal compiler error: 'verify_gimple' failed
0x13e08fd verify_gimple_in_seq(gimple*)
/repo/gcc-trunk/gcc/tree-cfg.cc:5213
0x1092686 gimplify_body(tree_node*, bool)
/repo/gcc-trunk/gcc/gimplify.cc:16302
0x10927dd gimplify_function_tree(tree_node*)
/repo/gcc-trunk/gcc/gimplify.cc:16373
0xeb6837 cgraph_node::analyze()
/repo/gcc-trunk/gcc/cgraphunit.cc:675
0xeb94a7 analyze_functions
/repo/gcc-trunk/gcc/cgraphunit.cc:1240
0xeba14d symbol_table::finalize_compilation_unit()
/repo/gcc-trunk/gcc/cgraphunit.cc:2500
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

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

[Bug c++/99804] cannot convert bit field enum to its own type in a template member function

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||vofogi5810 at goonby dot com

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

[Bug c++/104509] Scoped enum as bit field in a function template

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 99804.

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

[Bug c++/104509] New: Scoped enum as bit field in a function template

[vofogi5810 at goonby dot com via Gcc-bugs]

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

Bug ID: 104509
   Summary: Scoped enum as bit field in a function template
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vofogi5810 at goonby dot com
  Target Milestone: ---

The following fails:

#include 

struct test {
  enum class state { off, on };
  state st: 1; // bit field
  bool is_on() const {
return st == state::on; // this is ok
  }
  template
  bool is() const {
if constexpr (flag) return st == state::on; // error?
else return st == state::off;
  }
};

int main() {
  test t{test::state::on};
  return !t.is();
}

GCC output:

error: no match for ‘operator==’ (operand types are ‘const signed char:1’ and
‘test::state’)

Non-template function works. Current workaround is to apply static_cast.

[Bug middle-end/104504] spurious -Wswitch-unreachable warning with -ftrivial-auto-var-init=zero

[kees at outflux dot net via Gcc-bugs]

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

--- Comment #2 from Kees Cook  ---
As mentioned in a Linux kernel thread, isn't it possible to transform this:


  switch (x) {
  int y;
  default:
  y = x * 2;
  return y;
  }

into this:

  {
  int y;
  switch (x) {
  default:
  y = x * 2;
  return y;
  }
  }

[Bug libstdc++/104508] New: _GLIBCXX_ASSERTIONS gets ignored with clang with -std=c++2b

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 104508
   Summary: _GLIBCXX_ASSERTIONS gets ignored with clang with
-std=c++2b
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

C++20:
https://godbolt.org/z/dr3rEx7zP
C++2b:
https://godbolt.org/z/4KKc9x4x5

[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).

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

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

--- Comment #23 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:4c3792d448964f7bd99e7eac2c29c9eb7c2bfb84

commit r12-7209-g4c3792d448964f7bd99e7eac2c29c9eb7c2bfb84
Author: Iain Sandoe 
Date:   Mon Feb 7 15:36:35 2022 +

LRA, rs6000, Darwin: Amend lo_sum use for forced constants [PR104117].

Two issues resulted in this PR, which manifests when we force a constant
into
memory in LRA (in PIC code on Darwin).  The presence of such forced
constants
is quite dependent on other RTL optimisations, and it is easy for the issue
to
become latent for a specific case.

First, in the Darwin-specific rs6000 backend code, we were not being
careful
enough in rejecting invalid symbolic addresses.  Specifically, when
generating
PIC code, we require a SYMBOL_REF to be wrapped in an
UNSPEC_MACHOPIC_OFFSET.

Second, LRA was attempting to load a register using an invalid lo_sum
address.

Signed-off-by: Iain Sandoe 
Co-authored-by: Vladimir Makarov 

PR target/104117

gcc/ChangeLog:

* config/rs6000/rs6000.cc
(darwin_rs6000_legitimate_lo_sum_const_p):
Check for UNSPEC_MACHOPIC_OFFSET wrappers on symbolic addresses
when
emitting PIC code.
(legitimate_lo_sum_address_p): Likewise.
* lra-constraints.cc (process_address_1): Do not attempt to emit a
reg
load from an invalid lo_sum address.

[Bug c/104506] [12 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:87 on invalid symbol redeclaration

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> Now do we want to add a check inside STRIP_USELESS_TYPE_CONVERSION for
> error_mark_node, I am still deciding.

Oh STRIP_TYPE_NOPS has a check for error_mark_node which was done in 2000 by
r0-29080 . So maybe it just should too.

[Bug c/104506] [12 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:87 on invalid symbol redeclaration

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

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

--- Comment #2 from Andrew Pinski  ---
The NOP_EXPR comes from:

(gdb) up
#1  0x00b99a72 in c_process_expr_stmt (loc=266752, expr=) at
/home/apinski/src/upstream-gcc/gcc/gcc/c/c-typeck.cc:11356
11356 expr = build1 (NOP_EXPR, TREE_TYPE (expr), expr);
(gdb) l
11351
11352 /* If the expression is not of a type to which we cannot assign a
line
11353number, wrap the thing in a no-op NOP_EXPR.  */
11354 if (DECL_P (expr) || CONSTANT_CLASS_P (expr))
11355   {
11356 expr = build1 (NOP_EXPR, TREE_TYPE (expr), expr);
11357 SET_EXPR_LOCATION (expr, loc);
11358   }


But if you had a cast to void, it would come from somewhere else.


The strip is:
  /* Strip away as many useless type conversions as possible
 at the toplevel.  */
  STRIP_USELESS_TYPE_CONVERSION (*expr_p);


Now do we want to add a check inside STRIP_USELESS_TYPE_CONVERSION for
error_mark_node, I am still deciding.

[Bug target/101324] powerpc64le: hashst appears before mflr at -O1 or higher

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #26 from Peter Bergner  ---
Fixed everywhere now.

[Bug c++/104507] [10/11 Regression] internal compiler error: unexpected expression ‘(int)(__ret)’ of kind cast_expr

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||10.1.0, 9.3.0, 9.4.0
Summary|internal compiler error:|[10/11 Regression] internal
   |unexpected expression   |compiler error: unexpected
   |‘(int)(__ret)’ of kind  |expression ‘(int)(__ret)’
   |cast_expr   |of kind cast_expr
  Known to fail||10.2.0, 10.3.0, 11.1.0
   Target Milestone|--- |10.4

[Bug tree-optimization/102586] [12 Regression] ICE in clear_padding_type, at gimple-fold.c:4798 since r12-3433-ga25e0b5e6ac8a77a

[qing.zhao at oracle dot com via Gcc-bugs]

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

--- Comment #27 from Qing Zhao  ---
> On Feb 11, 2022, at 11:47 AM, jakub at gcc dot gnu.org 
>  wrote:
> But if I do:
> struct C { char a; int b; char c; long d; C () : a (42), b (42), c (42), d 
> (42)
> {} };
> void bar (C *);
> void
> foo ()
> {
>  C c;
>  bar ();
> }
> then *.gimple is:
>  c = .DEFERRED_INIT (24, 1, &"c"[0]);
>  __builtin_clear_padding (, 0B, 1);
>  C::C ();
>  bar ();
> ...
> void C::C (struct C * const this)
> {
>  *this = {CLOBBER};
>  {
>this->a = 42;
>this->b = 42;
>this->c = 42;
>this->d = 42;
>  }
> }
> After einline this is:
>  c = .DEFERRED_INIT (24, 1, &"c"[0]);
>  MEM  [(struct C *) + 1B] = {};
>  MEM  [(struct C *) + 9B] = {};
>  c ={v} {CLOBBER};
>  c.a = 42;
>  c.b = 42;
>  c.c = 42;
>  c.d = 42;
>  bar ();
> and that keeps until dse1 which optimizes that out:
>  c ={v} {CLOBBER};
>  c.a = 42;
>  c.b = 42;
>  c.c = 42;
>  c.d = 42;
>  bar ();
> so there is no zero padding initialization at all.

Does this issue only exist with -flifetime-dse=2?
When -flifetime-dse=2, the call to __builtin_clear_padding should be inserted
AFTER the
start point of the constructor of the object, otherwise it’s dead and will be
eliminated by DSE. 
And with -flifetime-dse=2, the padding initialization should be done by C++ FE
instead of middle end.
Is this understanding correct?

[Bug c++/104507] internal compiler error: unexpected expression ‘(int)(__ret)’ of kind cast_expr

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code,
   ||needs-bisection

--- Comment #1 from Andrew Pinski  ---
Looks to be fixed on the trunk.

[Bug c/104506] [12 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:87 on invalid symbol redeclaration

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug c/104506] [12 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:87 on invalid symbol redeclaration

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
   Last reconfirmed||2022-02-11
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Anoth testcase:
double x;
void
foo (void)
{
  x;
}
int x;

Confirmed, most likely started with r12-3278-g823685221de98.

[Bug c++/104507] New: internal compiler error: unexpected expression ‘(int)(__ret)’ of kind cast_expr

[junk at sigpwr dot com via Gcc-bugs]

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

Bug ID: 104507
   Summary: internal compiler error: unexpected expression
‘(int)(__ret)’ of kind cast_expr
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: junk at sigpwr dot com
  Target Milestone: ---

Created attachment 52423
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52423=edit
repro ii file

Observed on multiple builds of GCC 11.2 (originally on a couple
cross-compilers, then reproduced on debian)

GCC details:

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

Command line to reproduce:

gcc -save-temps repro.cc -c -o repro.o
repro.cc: In function ‘int DoFoo()’:
repro.cc:11:89: internal compiler error: unexpected expression ‘(int)(__ret)’
of kind cast_expr
   11 |   const char *n = s_errmsg(__ret);
  |
^
0x7fce4df477ec __libc_start_main
../csu/libc-start.c:332
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Contents of repro.cc (.ii file attached):

#define ERR_MAX -20

#define s_errmsg(r)  \
_k_errmsg[(((int)r) <= 0 && ((int)r) > ERR_MAX) ? -(r) : -ERR_MAX]

extern const char *_k_errmsg[];

template 
inline int DoFoo() {
  int __ret = 0;
  const char *n = s_errmsg(__ret);
  return __ret;
}

[Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11

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

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

--- Comment #15 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:3273e704d04a98bcfccdc93c8d07e88f2b032043

commit r11-9561-g3273e704d04a98bcfccdc93c8d07e88f2b032043
Author: Patrick Palka 
Date:   Fri Feb 11 15:39:06 2022 -0500

libstdc++: Back out some changes from P2325R3 backport [PR103904]

In the P2325R3 backport r11-9555 the relaxation of the constraints on
the partial specialization of __box (which is semantically equivalent to
the primary template, only more space efficient) means some
specializations of __box will now use the partial specialization instead
of the primary template, which constitutes an ABI change unsuitable for
a release branch.  So this patch reverts this constraint change, which
isn't needed for correctness anyway.

Similarly, the change to use __non_propagating_cache for the data member
split_view::_M_current (so that it's always default-initializable) also
constitutes an unsuitable ABI change.  This patch reverts this change
too, and instead further constrains split_view's default constructor to
require that we can default-initialize _M_current.

PR libstdc++/103904

libstdc++-v3/ChangeLog:

* include/std/ranges (__detail::__box): Revert r11-9555 changes
to the constraints on the partial specialization and the
now-unnecessary special member functions.
(__detail::__non_propagating_cache::operator=): Remove
now-unused overload added by r11-9555.
(split_view::_OuterIter::__current): Adjust after reverting the
r11-9555 change to the type of _M_current.
(split_view::_M_current): Revert r11-9555 change to its type.
(split_view::split_view): Constrain the default constructor
further.
* testsuite/std/ranges/adaptors/detail/copyable_box.cc: Disable
now-irrelevant test for the r11-9555 changes to the partial
specialization of __box.

[Bug target/79754] ICE in type_natural_mode with vector for DFP type

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #4 from Uroš Bizjak  ---
Created attachment 52422
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52422=edit
Patch in testing.

[Bug tree-optimization/104499] [12 Regression] ICE: in emit_move_insn, at expr.cc:4010 at -O1

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/101324] powerpc64le: hashst appears before mflr at -O1 or higher

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

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

--- Comment #25 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Peter Bergner
:

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

commit r11-9560-gc56c398c39f6195c3d158f02514c33b7da73ebc2
Author: Martin Liska 
Date:   Fri Dec 3 11:58:25 2021 -0600

rs6000: Fix up flag_shrink_wrap handling in presence of -mrop-protect
[PR101324]

PR101324 shows a problem in disabling shrink-wrapping when using
-mrop-protect
when there is a attribute optimize/pragma.  The fix envolves moving the
handling
of flag_shrink_wrap so it gets re-disbled when we change or add options.

2021-12-03  Martin Liska  

gcc/
PR target/101324
* config/rs6000/rs6000.c (rs6000_option_override_internal): Move
the
disabling of shrink-wrapping when using -mrop-protect from here...
(rs6000_override_options_after_change): ...to here.

2021-12-03  Peter Bergner  

gcc/testsuite/
PR target/101324
* gcc.target/powerpc/pr101324.c: New test.

(cherry picked from commit cff7879a381d3f5ed6556206896e6a6229800167)

[Bug testsuite/103586] New test case gcc.target/powerpc/pr101324.c fails on BE

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Peter Bergner
:

https://gcc.gnu.org/g:4854985f13feac2d61c69c996c47af468f29c6c9

commit r11-9559-g4854985f13feac2d61c69c996c47af468f29c6c9
Author: Peter Bergner 
Date:   Tue Dec 7 14:42:38 2021 -0600

testsuite: Fix check_effective_target_rop_ok [PR103556, PR103586]

The new rop_ok effective target test doesn't correctly compute its
expression
result because a new line starts a new statement.  Solution is to remove
the new line.

2021-12-07  Peter Bergner  

gcc/testsuite/
PR testsuite/103556
PR testsuite/103586
* lib/target-supports.exp (check_effective_target_rop_ok): Remove
'\n'.

(cherry picked from commit 4394fd67264f5de650c2c3509c001c5f7203449d)

[Bug testsuite/103556] [12 regression] rop test cases start failing after r12-5780

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Peter Bergner
:

https://gcc.gnu.org/g:4854985f13feac2d61c69c996c47af468f29c6c9

commit r11-9559-g4854985f13feac2d61c69c996c47af468f29c6c9
Author: Peter Bergner 
Date:   Tue Dec 7 14:42:38 2021 -0600

testsuite: Fix check_effective_target_rop_ok [PR103556, PR103586]

The new rop_ok effective target test doesn't correctly compute its
expression
result because a new line starts a new statement.  Solution is to remove
the new line.

2021-12-07  Peter Bergner  

gcc/testsuite/
PR testsuite/103556
PR testsuite/103586
* lib/target-supports.exp (check_effective_target_rop_ok): Remove
'\n'.

(cherry picked from commit 4394fd67264f5de650c2c3509c001c5f7203449d)

[Bug tree-optimization/104499] [12 Regression] ICE: in emit_move_insn, at expr.cc:4010 at -O1

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:9355a8c35883b5125851bb9b4169a1a1cd8e343f

commit r12-7202-g9355a8c35883b5125851bb9b4169a1a1cd8e343f
Author: Jakub Jelinek 
Date:   Fri Feb 11 20:27:23 2022 +0100

match.pd: Fix up (X & Y) CMP 0 -> X CMP2 ~Y simplifications [PR104499]

The following testcase ICEs on x86_64-linux, because match.pd emits
there a NOP_EXPR cast from int*8 vector type with BLKmode to
unsigned*8 vector type with BLKmode and vec-lowering isn't prepared
to handle such casts.

Fixed by using VIEW_CONVERT_EXPR instead.

2022-02-11  Jakub Jelinek  

PR tree-optimization/104499
* match.pd ((X & Y) CMP 0 -> X CMP2 ~Y): Use view_convert instead
of convert.

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

[Bug sanitizer/104449] [9/10/11/12 Regression] ICE: verify_gimple failed: dead statement in EH table with -fexceptions -fsanitize=address -fstack-check=generic

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c/104506] [12 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:87 on invalid symbol redeclaration

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |trivial
  Known to work|11.2.1  |11.0

[Bug c/104506] [12 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:87 on invalid symbol redeclaration

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug tree-optimization/104501] vector lowering for VEC_COND_EXPR does not consider smaller vectors

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
I think this is direct dup of bug 55001.

[Bug middle-end/104504] spurious -Wswitch-unreachable warning with -ftrivial-auto-var-init=zero

[kees at outflux dot net via Gcc-bugs]

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

Kees Cook  changed:

   What|Removed |Added

 CC||kees at outflux dot net

--- Comment #1 from Kees Cook  ---
Similar issue exists in Clang, though Clang doesn't warn:
https://github.com/llvm/llvm-project/issues/44261

[Bug tree-optimization/102586] [12 Regression] ICE in clear_padding_type, at gimple-fold.c:4798 since r12-3433-ga25e0b5e6ac8a77a

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

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

--- Comment #26 from Jakub Jelinek  ---
Though, I must say I don't understand how that works currently at all.
For say
struct C0 {};
struct C1 {};
struct C2 : C1, virtual C0 {};
struct C3 : virtual C2, C1 {};
struct C6 { char c; };
struct C7 : virtual C6, virtual C3, C1 {};
struct C8 : C7 {};
void bar (C8 *);

void
foo ()
{
  C8 c;
  bar ();
}
I see in gimple dump:
  c = .DEFERRED_INIT (32, 1, &"c"[0]);
  __builtin_clear_padding (, 0B, 1);
  C8::C8 ();
  bar ();
and it does something only because C8::C8 doesn't get the -flifetime-dse=2
CLOBBER at the start.

But if I do:
struct C { char a; int b; char c; long d; C () : a (42), b (42), c (42), d (42)
{} };
void bar (C *);
void
foo ()
{
  C c;
  bar ();
}
then *.gimple is:
  c = .DEFERRED_INIT (24, 1, &"c"[0]);
  __builtin_clear_padding (, 0B, 1);
  C::C ();
  bar ();
...
void C::C (struct C * const this)
{
  *this = {CLOBBER};
  {
this->a = 42;
this->b = 42;
this->c = 42;
this->d = 42;
  }
}
After einline this is:
  c = .DEFERRED_INIT (24, 1, &"c"[0]);
  MEM  [(struct C *) + 1B] = {};
  MEM  [(struct C *) + 9B] = {};
  c ={v} {CLOBBER};
  c.a = 42;
  c.b = 42;
  c.c = 42;
  c.d = 42;
  bar ();
and that keeps until dse1 which optimizes that out:
  c ={v} {CLOBBER};
  c.a = 42;
  c.b = 42;
  c.c = 42;
  c.d = 42;
  bar ();
so there is no zero padding initialization at all.

[Bug libstdc++/102994] std::atomic::wait is not marked const

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

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

--- Comment #14 from Thomas Rodgers  ---
Created attachment 52420
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52420=edit
Make notify_one/notify_all non-const

I submitted this patch to the list.

[Bug analyzer/102692] -Wanalyzer-null-dereference false alarm with (!p || q || !p->next)

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

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

--- Comment #4 from David Malcolm  ---
I've been investigating the false positive from
-Wanalyzer-use-of-uninitialized-value.  It only happens when optimization is
turned on, but happens within the FE, before gimplification.

Specifically, c_parser_condition parses this condition:
  ((A OR-IF B) OR-IF C)
and calls c_fully_fold on the condition.

Within c_fully_fold, fold_truth_andor is called, which bails when optimization
is off, but if any optimization is turned on converts the
  ((A OR-IF B) OR-IF C)
into:
  ((A OR B) OR_IF C)

and at gimplification time the inner OR becomes BIT_IOR_EXPR (in
gimplify_expr), giving this for the inner condition:

  tmp = A | B
  if (tmp)

thus effectively synthesizing a redundant access of B when optimization is
turned on.

[Bug tree-optimization/102586] [12 Regression] ICE in clear_padding_type, at gimple-fold.c:4798 since r12-3433-ga25e0b5e6ac8a77a

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

 CC||qinzhao at gcc dot gnu.org

--- Comment #25 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #24)
> I bet with the default -flifetime-dse=2 we would then have a
>   var = {};
>   var ={v} {CLOBBER}; // Start of ctor clobber
>   var.whatever = ...; // Ctor content
> and the zero initialization would be optimized away then.
> I guess ideal would be to emit such zero initialization in the complete
> object ctors right after the -flifetime-dse=2 beginning clobber and ideally
> one that clearly says to the gimplifier and rest of middle-end that it must
> initialize even padding bits.
> Because right now gimplification of var = {} will often happily lower that to
>   var.a = 0; var.b = 0; var.c = 0;
> even when there are padding bits,

oh right, I recall that this was the reason why adding "var = {}" to initialize
the whole structure didn't work well for initialize all paddings. therefore we
have to explicitly call __builtin_clear_padding for clear all paddings.

[Bug target/97040] incorrect fused multiply add/subtract instruction generated from C code

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #4 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug rtl-optimization/104400] [12 Regression] v850e lra/reload failure after recent change

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #5 from Jeffrey A. Law  ---
And I can confirm newlib builds again.  Unfortunately, the last successful
build was too far in the past and was wiped by Jenkins.  So I can't compare the
testsuite results with that prior successful run :(

[Bug c/104506] New: [12 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:87 on invalid symbol redeclaration

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 104506
   Summary: [12 Regression] ICE: tree check: expected class
'type', have 'exceptional' (error_mark) in
useless_type_conversion_p, at gimple-expr.cc:87 on
invalid symbol redeclaration
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc testcase.c
testcase.c: In function 'foo':
testcase.c:5:7: error: 'x' redeclared as different kind of symbol
5 |   int x;
  |   ^
testcase.c:2:13: note: previous definition of 'x' with type 'double'
2 | foo (double x)
  |  ~~~^
testcase.c:4:3: internal compiler error: tree check: expected class 'type',
have 'exceptional' (error_mark) in useless_type_conversion_p, at
gimple-expr.cc:87
4 |   x;
  |   ^
0x7f8b57 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/repo/gcc-trunk/gcc/tree.cc:8738
0x6e607c tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/repo/gcc-trunk/gcc/tree.h:3568
0x6e607c useless_type_conversion_p(tree_node*, tree_node*)
/repo/gcc-trunk/gcc/gimple-expr.cc:87
0x15d565b tree_ssa_strip_useless_type_conversions(tree_node*)
/repo/gcc-trunk/gcc/tree-ssa.cc:1280
0x107f937 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:14875
0x10841a6 gimplify_stmt(tree_node**, gimple**)
/repo/gcc-trunk/gcc/gimplify.cc:7035
0x1081cf3 gimplify_statement_list
/repo/gcc-trunk/gcc/gimplify.cc:2022
0x1081cf3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:15425
0x10841a6 gimplify_stmt(tree_node**, gimple**)
/repo/gcc-trunk/gcc/gimplify.cc:7035
0x10848fd gimplify_bind_expr
/repo/gcc-trunk/gcc/gimplify.cc:1427
0x1080e62 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:15181
0x10923df gimplify_stmt(tree_node**, gimple**)
/repo/gcc-trunk/gcc/gimplify.cc:7035
0x10923df gimplify_body(tree_node*, bool)
/repo/gcc-trunk/gcc/gimplify.cc:16226
0x109280d gimplify_function_tree(tree_node*)
/repo/gcc-trunk/gcc/gimplify.cc:16380
0xeb6807 cgraph_node::analyze()
/repo/gcc-trunk/gcc/cgraphunit.cc:675
0xeb9477 analyze_functions
/repo/gcc-trunk/gcc/cgraphunit.cc:1240
0xeba11d symbol_table::finalize_compilation_unit()
/repo/gcc-trunk/gcc/cgraphunit.cc:2500
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

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

[Bug tree-optimization/102586] [12 Regression] ICE in clear_padding_type, at gimple-fold.c:4798 since r12-3433-ga25e0b5e6ac8a77a

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

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

--- Comment #24 from Jakub Jelinek  ---
I bet with the default -flifetime-dse=2 we would then have a
  var = {};
  var ={v} {CLOBBER}; // Start of ctor clobber
  var.whatever = ...; // Ctor content
and the zero initialization would be optimized away then.
I guess ideal would be to emit such zero initialization in the complete object
ctors right after the -flifetime-dse=2 beginning clobber and ideally one that
clearly says to the gimplifier and rest of middle-end that it must initialize
even padding bits.
Because right now gimplification of var = {} will often happily lower that to
  var.a = 0; var.b = 0; var.c = 0;
even when there are padding bits, which is ok for most of ctors, but not ok for
D and not ok for C++ zero initialization.
So, I think we need some flag on CONSTRUCTORS requesting the initialize also
padding bits behavior, set it for D ctors and for C++ zero initialization,
properly propagate it through the C++ FE and honor it during gimplification
(and wherever else it is needed).

[Bug target/79754] ICE in type_natural_mode with vector for DFP type

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #3 from Zdenek Sojka  ---
This still ICEs on r12-7199:
$ x86_64-pc-linux-gnu-gcc testcase.c 
testcase.c: In function 'foo':
testcase.c:2:1: internal compiler error: in type_natural_mode, at
config/i386/i386.cc:1978
2 | V foo (V a) { return a * a; }
  | ^
0x81e1e7 type_natural_mode
/repo/gcc-trunk/gcc/config/i386/i386.cc:1978
0x172382a ix86_return_in_memory
/repo/gcc-trunk/gcc/config/i386/i386.cc:4230
0x101084d aggregate_value_p(tree_node const*, tree_node const*)
/repo/gcc-trunk/gcc/function.cc:2119
0x10154ac allocate_struct_function(tree_node*, bool)
/repo/gcc-trunk/gcc/function.cc:4845
0xd26104 store_parm_decls()
/repo/gcc-trunk/gcc/c/c-decl.cc:10160
0xd855c7 c_parser_declaration_or_fndef
/repo/gcc-trunk/gcc/c/c-parser.cc:2505
0xd8d8a3 c_parser_external_declaration
/repo/gcc-trunk/gcc/c/c-parser.cc:1779
0xd8e2eb c_parser_translation_unit
/repo/gcc-trunk/gcc/c/c-parser.cc:1652
0xd8e2eb c_parse_file()
/repo/gcc-trunk/gcc/c/c-parser.cc:23348
0xdef9fd c_common_parse_file()
/repo/gcc-trunk/gcc/c-family/c-opts.cc:1238
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

but works on powerpc64le (at least, doesn't ICE; I didn't check if the code is
correct):
$ powerpc64le-unknown-linux-gnu-gcc testcase.c -c
(no output)

[Bug tree-optimization/102586] [12 Regression] ICE in clear_padding_type, at gimple-fold.c:4798 since r12-3433-ga25e0b5e6ac8a77a

[qing.zhao at oracle dot com via Gcc-bugs]

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

--- Comment #23 from Qing Zhao  ---
> On Feb 11, 2022, at 9:29 AM, jason at gcc dot gnu.org 
>  wrote:
> 
> I wonder why -fauto-var-init uses builtin_clear_padding instead of just
> zero-initializing the whole object before normal initialization, as with
> value-initialization?  With a new object we don't need to get clever.

In the initial several versions of the implementation, I didn’t use
builtin_clear_padding, other that
that, I just zero-initialized the whole object before normal initialization.
However, multiple people
suggested to use builtin_clear_padding instead. Then in the later
implementations, I used
builtin_clear_padding for the padding initialization.

[Bug rtl-optimization/104400] [12 Regression] v850e lra/reload failure after recent change

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Vladimir Makarov :

https://gcc.gnu.org/g:274a4d29421e73c9b40c1641986c6ed904e20184

commit r12-7200-g274a4d29421e73c9b40c1641986c6ed904e20184
Author: Vladimir N. Makarov 
Date:   Fri Feb 11 09:52:14 2022 -0500

[PR104400] LRA: Modify exclude start hard register calculation for insn
alternative

v850 target has an interesting insn alternative constraint 'e!r' where e
denotes even general regs and e is a subset of r.  We cannot just make
union of exclude start hard registers for e and r and should use only
exclude start hard registers of r.  The following patch implements this.

gcc/ChangeLog:

PR rtl-optimization/104400
* lra-constraints.cc (process_alt_operands): Don't make union of
this_alternative_exclude_start_hard_regs when reg class in insn
alternative covers other reg classes in the same alternative.

gcc/testsuite/ChangeLog:

PR rtl-optimization/104400
* gcc.target/v850/pr104400.c: New.
* gcc.target/v850/v850.exp: New.

[Bug target/103008] poor inlined builtin_fmod on x86_64

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #13 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #12)
> Just as data-point on znver2 Uros testcase shows
> 
> rguenther@ryzen:/tmp> gcc-11 t.c -Ofast -lm -march=znver2
> rguenther@ryzen:/tmp> numactl --physcpubind=3 /usr/bin/time ./a.out 
> 19.18user 0.00system 0:19.18elapsed 99%CPU (0avgtext+0avgdata
> 1528maxresident)k
> 0inputs+0outputs (0major+76minor)pagefaults 0swaps
> rguenther@ryzen:/tmp> gcc-11 t.c -Ofast -lm -march=znver2 -fno-builtin-fmod

You should use -fno-builtin-fmodf in the above compile flags.

[Bug target/104502] [12 Regression] ICE: in extract_constrain_insn, at recog.cc:2670: insn does not satisfy its constraints with -O -flive-range-shrinkage -march=barcelona -fstack-protector-all -mavx5

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug tree-optimization/102586] [12 Regression] ICE in clear_padding_type, at gimple-fold.c:4798 since r12-3433-ga25e0b5e6ac8a77a

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

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

--- Comment #22 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #21)
> This patch implements the rejection of pointers to non-trivially-copyable
> types with the exception of  or , because in those cases we know it
> is complete object type and so don't need to worry about it being just a
> subobject.

OK.

I wonder why -fauto-var-init uses builtin_clear_padding instead of just
zero-initializing the whole object before normal initialization, as with
value-initialization?  With a new object we don't need to get clever.

[Bug target/104455] Cannot select -march=armv7-a using GCC 11

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

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

--- Comment #5 from Richard Earnshaw  ---
(In reply to Jeffrey Walton from comment #4)

> 
> So stepping back to 10,000 feet, we now need to specify options and ISA's we
> are not using. That seems like a bug to me. I'm not sure I would consider
> this fixed.
> 
> Where is it going to stop? How many non-used options that I am not aware of
> will I need to specify?
> 
> I think either GCC or Debian needs to fix this. This could be a GCC bug
> because GCC apparently knows there's a fp unit but it chooses to ignore it.
> Instead it wants me to say it again. This could be a Debian bug because they
> need to completely (not partially) configure things.

No, it knows it /needs/ a FP unit, but you haven't told it which one is
available.  The Arm architecture has many variants and not all are necessarily
compatible with a base set, so you have to explicitly state which one is
intended.  Assumptions are a potential source of massive misunderstandings.

Note, in the past the FPU variant was baked into the compiler when it was
configured and this lead to all forms of confusion because if you had a Neon
FPU and then started compiling for a cortex-m device you could still end up
with Neon instructions in your code because there was no explicit option to
turn it off.  We've gone as far as we can by allowing you to simply specify
'+fp' rather than having to know exactly which variant of the VFP architecture
goes with armv7-a.

Also note that clang has the same option logic for CPU selection.

[Bug c/104505] New: ICE: SIGSEGV in c_pretty_printer::postfix_expression() on invalid code

[zsojka at seznam dot cz via Gcc-bugs]

otstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-7199-20220211084605-gcc68ad87014-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220211 (experimental) (GCC)

[Bug middle-end/104504] New: spurious -Wswitch-unreachable warning with -ftrivial-auto-var-init=zero

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

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

Bug ID: 104504
   Summary: spurious -Wswitch-unreachable warning with
-ftrivial-auto-var-init=zero
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

reduced from linux code on which gcc-12 warns now:

int foo(int x) {
switch(x) {
int y;
/* spuriously warns with -ftrivial-auto-var-init=zero */
default:
y = x * 2;
return y;
}
}

$ gcc -Wall -ftrivial-auto-var-init=zero -c a.c
a.c: In function 'foo':
a.c:3:13: warning: statement will never be executed [-Wswitch-unreachable]
3 | int y;
  | ^

i can see why gcc warns, but it would be better not to.

[Bug target/95082] [11] LE implementations of vec_cnttz_lsbb and vec_cntlz_lsbb are wrong

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

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

--- Comment #9 from Segher Boessenkool  ---
It still needs fixing on trunk as well, as discussed.

[Bug target/104502] [12 Regression] ICE: in extract_constrain_insn, at recog.cc:2670: insn does not satisfy its constraints with -O -flive-range-shrinkage -march=barcelona -fstack-protector-all -mavx5

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2022-02-11
   Target Milestone|--- |12.0
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r12-2666-g29f0e955c97da002b5adb4e8c9dfd2ea9709e207

[Bug c++/104503] New: [12 regression][modules] bits/shared_ptr_base.h: error: must ‘#include ’ before using ‘typeid’

[egor.pugin at gmail dot com via Gcc-bugs]

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

Bug ID: 104503
   Summary: [12 regression][modules] bits/shared_ptr_base.h:
error: must ‘#include ’ before using
‘typeid’
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egor.pugin at gmail dot com
  Target Milestone: ---

11.2.1 works fine.

#include  is present in include/c++/12.0.1/bits/shared_ptr_base.h

Repro:

cat << EOF > 1.cpp
export module m;
import ;
EOF
cat << EOF > 2.cpp
import m;
int main(){}
EOF
g++ -std=c++23 -fmodules-ts -x c++-system-header bits/stdc++.h
g++ -std=c++23 -fmodules-ts -c 1.cpp
g++ -std=c++23 -fmodules-ts -c 2.cpp

Error:

In file included from
/home/egor/dev/gcc/build_debug/install/include/c++/12.0.1/bits/shared_ptr.h:53,
 from
/home/egor/dev/gcc/build_debug/install/include/c++/12.0.1/memory:77,
 from
/home/egor/dev/gcc/build_debug/install/include/c++/12.0.1/x86_64-pc-linux-gnu/bits/stdc++.h:82,
of module
/home/egor/dev/gcc/build_debug/install/include/c++/12.0.1/x86_64-pc-linux-gnu/bits/stdc++.h,
imported at 1.cpp:2,
of module m, imported at 2.cpp:1:
/home/egor/dev/gcc/build_debug/install/include/c++/12.0.1/bits/shared_ptr_base.h:
In instantiation of ‘void* std::_Sp_counted_ptr_inplace<_Tp, _Alloc,
_Lp>::_M_get_deleter(const std::type_info&) [with _Tp = std::mutex; _Alloc =
std::allocator; __gnu_cxx::_Lock_policy _Lp = __gnu_cxx::_S_atomic]’:
/home/egor/dev/gcc/build_debug/install/include/c++/12.0.1/bits/shared_ptr_base.h:631:7:
  required from here
/home/egor/dev/gcc/build_debug/install/include/c++/12.0.1/bits/shared_ptr_base.h:641:21:
error: must ‘#include ’ before using ‘typeid’
   62 | #include 
  +++ |+#include 
   63 | #if __cplusplus >= 202002L
..
  641 | __ti == typeid(_Sp_make_shared_tag)
  | ^~~
/home/egor/dev/gcc/build_debug/install/include/c++/12.0.1/bits/shared_ptr_base.h:
In instantiation of ‘void* std::_Sp_counted_ptr_inplace<_Tp, _Alloc,
_Lp>::_M_get_deleter(const std::type_info&) [with _Tp =
std::__future_base::_State_baseV2; _Alloc = std::allocator;
__gnu_cxx::_Lock_policy _Lp = __gnu_cxx::_S_atomic]’:
/home/egor/dev/gcc/build_debug/install/include/c++/12.0.1/bits/shared_ptr_base.h:631:7:
  required from here
/home/egor/dev/gcc/build_debug/install/include/c++/12.0.1/bits/shared_ptr_base.h:641:21:
error: must ‘#include ’ before using ‘typeid’

Build:

Using built-in specs.
COLLECT_GCC=/home/egor/dev/gcc/build_debug/install/bin/g++
COLLECT_LTO_WRAPPER=/home/egor/dev/gcc/build_debug/install/libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--prefix=/home/egor/dev/gcc/build_debug/install --disable-libsanitizer
--disable-gcov --disable-libgomp --disable-libquadmath --disable-libssp
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.1 20220211 (experimental) (GCC)

[Bug testsuite/104423] [libgomp, testsuite] Add means to do accelerator-only testing in libgomp

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

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

--- Comment #4 from Tom de Vries  ---
Created attachment 52416
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52416=edit
[libgomp, testsuite, nvptx] Add GOMP_NVPTX_JIT_ITER (libgomp.c/c.exp only)

[Bug target/104502] New: [12 Regression] ICE: in extract_constrain_insn, at recog.cc:2670: insn does not satisfy its constraints with -O -flive-range-shrinkage -march=barcelona -fstack-protector-all -

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 104502
   Summary: [12 Regression] ICE: in extract_constrain_insn, at
recog.cc:2670: insn does not satisfy its constraints
with -O -flive-range-shrinkage -march=barcelona
-fstack-protector-all -mavx512f
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -flive-range-shrinkage -march=barcelona
-fstack-protector-all -mavx512f testcase.c
testcase.c: In function 'foo':
testcase.c:27:1: error: insn does not satisfy its constraints:
   27 | }
  | ^
(insn 152 19 153 2 (set (reg:V2DF 44 xmm8 [150])
(vec_duplicate:V2DF (reg:DF 52 xmm16 [orig:83 d.0_2 ] [83])))
"testcase.c":18:23 5856 {vec_dupv2df}
 (nil))
during RTL pass: pro_and_epilogue
testcase.c:27:1: internal compiler error: in extract_constrain_insn, at
recog.cc:2670
0x7682a5 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0x76832b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.cc:118
0x757252 extract_constrain_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.cc:2670
0x12e0dcb copyprop_hardreg_forward_1
/repo/gcc-trunk/gcc/regcprop.cc:826
0x12e2001 copyprop_hardreg_forward_bb_without_debug_insn(basic_block_def*)
/repo/gcc-trunk/gcc/regcprop.cc:1220
0x134cba7 prepare_shrink_wrap
/repo/gcc-trunk/gcc/shrink-wrap.cc:451
0x134cba7 try_shrink_wrapping(edge_def**, rtx_insn*)
/repo/gcc-trunk/gcc/shrink-wrap.cc:674
0x101009b thread_prologue_and_epilogue_insns()
/repo/gcc-trunk/gcc/function.cc:6047
0x1010972 rest_of_handle_thread_prologue_and_epilogue
/repo/gcc-trunk/gcc/function.cc:6532
0x1010972 execute
/repo/gcc-trunk/gcc/function.cc:6608
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

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

[Bug middle-end/104449] [9/10/11/12 Regression] ICE: verify_gimple failed: dead statement in EH table with -fexceptions -fsanitize=address -fstack-check=generic

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

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

--- Comment #3 from Jakub Jelinek  ---
C++ testcase that ICEs with such options even at -O2:
void bar (int *);
struct A { A (); ~A (); };

void
foo (int n)
{
  A b;
  {
int a[n];
bar (a);
  }
}

[Bug libstdc++/102425] std::error_code() does not compare equal to std::error_condition()

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

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #8)
> This also prompted https://wg21.link/lwg3598

Which has been voted into the working draft now.

[Bug rtl-optimization/104498] Alias attribute being ignored by scheduler

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

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

--- Comment #8 from rsandifo at gcc dot gnu.org  
---
No, negating the offset seems like the right fix.

[Bug target/100181] hot-cold partitioned code doesn't assemble

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

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

--- Comment #13 from Andrew Stubbs  ---
I've updated the LLVM version documentation at
https://gcc.gnu.org/wiki/Offloading#For_AMD_GCN:

It's LLVM 9 or 13.0.1 now (nothing in between), and will be 13.0.1+ for the
next release (dropping LLVM 9 because we'll want to add newer device support to
GCC soonish).

[Bug target/100181] hot-cold partitioned code doesn't assemble

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #12 from Tobias Burnus  ---
I think with all the fixes which went into LLVM main and are now also in
release LLVM 13.0 (including a late fix, which is only in LLVM 13.0.1) this
issue is FIXED.

Thus, close as FIXED – if new issues shows up again, I think it makes sense to
open a new PR.

[Bug libstdc++/101231] _CachedPosition::_M_get() should not return {} when range adapter does not model forward_range

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:18b7cbb2ac0bf676846d7fe68283f093825357f6

commit r11-9557-g18b7cbb2ac0bf676846d7fe68283f093825357f6
Author: Patrick Palka 
Date:   Fri Jul 16 09:44:42 2021 -0400

libstdc++: invalid default init in _CachedPosition [PR101231]

The primary template for _CachedPosition is a dummy implementation for
non-forward ranges, the iterators for which generally can't be cached.
Because this implementation doesn't actually cache anything, _M_has_value
is defined to be false and so calls to _M_get (which are always guarded
by _M_has_value) are unreachable.

Still, to suppress a "control reaches end of non-void function" warning
I made _M_get return {}, but after P2325 input iterators are no longer
necessarily default constructible so this workaround now breaks valid
programs.

This patch fixes this by instead using __builtin_unreachable to squelch
the warning.

PR libstdc++/103904
PR libstdc++/101231

libstdc++-v3/ChangeLog:

* include/std/ranges (_CachedPosition::_M_get): For non-forward
ranges, just call __builtin_unreachable.
* testsuite/std/ranges/istream_view.cc (test05): New test.

(cherry picked from commit 1af937eb6246ad7f63ebff03590e9eede33aca81)

[Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11

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

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:18b7cbb2ac0bf676846d7fe68283f093825357f6

commit r11-9557-g18b7cbb2ac0bf676846d7fe68283f093825357f6
Author: Patrick Palka 
Date:   Fri Jul 16 09:44:42 2021 -0400

libstdc++: invalid default init in _CachedPosition [PR101231]

The primary template for _CachedPosition is a dummy implementation for
non-forward ranges, the iterators for which generally can't be cached.
Because this implementation doesn't actually cache anything, _M_has_value
is defined to be false and so calls to _M_get (which are always guarded
by _M_has_value) are unreachable.

Still, to suppress a "control reaches end of non-void function" warning
I made _M_get return {}, but after P2325 input iterators are no longer
necessarily default constructible so this workaround now breaks valid
programs.

This patch fixes this by instead using __builtin_unreachable to squelch
the warning.

PR libstdc++/103904
PR libstdc++/101231

libstdc++-v3/ChangeLog:

* include/std/ranges (_CachedPosition::_M_get): For non-forward
ranges, just call __builtin_unreachable.
* testsuite/std/ranges/istream_view.cc (test05): New test.

(cherry picked from commit 1af937eb6246ad7f63ebff03590e9eede33aca81)

[Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Patrick Palka
:

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

commit r11-9556-gfdc75c820f0f6fa458f0325c2c222ad5e7a7d3ad
Author: Patrick Palka 
Date:   Mon Jun 21 09:45:31 2021 -0400

libstdc++: Sync __cpp_lib_ranges macro defined in ranges_cmp.h

r12-1606 bumped the value of __cpp_lib_ranges defined in ,
but this macro is also defined in , so it needs to
be updated there as well.

PR libstdc++/103904

libstdc++-v3/ChangeLog:

* include/bits/ranges_cmp.h (__cpp_lib_ranges): Adjust value.

(cherry picked from commit 12bdd39755a25d237b7776153cbe03e171396fc5)

[Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:92d6121eeccf858cecd29ce4b7e734df7ae9

commit r11-9555-g92d6121eeccf858cecd29ce4b7e734df7ae9
Author: Patrick Palka 
Date:   Fri Feb 11 09:01:51 2022 -0500

libstdc++: Implement P2325 changes to default-constructibility of views

NB: This backport of r12-1606 to the 11 branch deliberately omits parts
of P2325R3 so as to maximize backward compatibility with pre-P2325R3 code.
In particular, we don't remove the default ctors for back_insert_iterator,
front_insert_iterator, ostream_iterator, ref_view and basic_istream_view.

===

This implements the wording changes of P2325R3 "Views should not be
required to be default constructible".  Changes are relatively
straightforward, besides perhaps those to __box (which now stands
for copyable-box instead of semiregular-box) and __non_propagating_cache.

For __box, this patch implements the recommended practice to also avoid
std::optional when the boxed type is nothrow_move/copy_constructible.

For __non_propagating_cache, now that it's used by split_view::_M_current,
we need to add assignment from a value of the underlying type to the
subset of the std::optional API implemented for the cache (needed by
split_view::begin()).  Hence the new __non_propagating_cache::operator=
overload.

In passing, this fixes the undesirable list-init in the constructors of
the partial specialization of __box as reported in PR100475 comment #7.

PR libstdc++/103904

libstdc++-v3/ChangeLog:

* include/bits/iterator_concepts.h (weakly_incrementable): Remove
default_initializable requirement.
* include/bits/ranges_base.h (ranges::view): Likewise.
* include/bits/ranges_util.h (subrange): Constrain the default
ctor.
* include/bits/stl_iterator.h (common_iterator): Constrain the
default ctor.
(counted_iterator): Likewise.
* include/std/ranges (__detail::__box::operator=): Handle
self-assignment in the primary template.
(__detail::__box): In the partial specialization: adjust
constraints as per P2325.  Add specialized operator= for the
case when the wrapped type is not copyable.  Constrain the
default ctor.  Avoid list-initialization.
(single_view): Constraint the default ctor.
(iota_view): Relax semiregular constraint to copyable.
Constrain the default ctor.
(iota_view::_Iterator): Constraint the default ctor.
(ref_view): Remove the default ctor.  Remove NSDMIs.
(ref_view::_Iterator): Constrain the default ctor.
(__detail::__non_propagating_cache::operator=): Define overload
for assigning from a value of the underlying type.
(filter_view): Likewise.
(filter_view::_Iterator): Likewise.
(transform_view): Likewise.
(transform_view::_Iterator): Likewise.
(take_view): Likewise.
(take_view::_Iterator): Likewise.
(take_while_view): Likewise.
(take_while_view::_Iterator): Likewise.
(drop_while_view): Likewise.
(drop_while_view::_Iterator): Likewise.
(join_view): Likewise.
(split_view::_OuterIter::__current): Adjust after changing the
type of _M_current.
(split_view::_M_current): Wrap it in a __non_propagating_cache.
(split_view::split_view): Constrain the default ctor.
(common_view): Constrain the default ctor.
(reverse_view): Likewise.
(elements_view): Likewise.
* include/std/span (enable_view>):
Define this partial specialization to true unconditionally.
* include/std/version (__cpp_lib_ranges): Adjust value.
* testsuite/std/ranges/adaptors/detail/semiregular_box.cc:
Rename to ...
* testsuite/std/ranges/adaptors/detail/copyable_box.cc: ... this.
(test02): Adjust now that __box is copyable-box not
semiregular-box.
(test03): New test.
* testsuite/std/ranges/p2325.cc: New test.
* testsuite/std/ranges/single_view.cc (test06): New test.
* testsuite/std/ranges/view.cc: Adjust now that view doesn't
require default_initializable.

(cherry picked from commit 4b4f5666b4c2f3aab2a9f3d53d394e390b9b682d)

[Bug testsuite/104481] gcc.target/i386/pr35513-8.c and g++.target/i386/pr35513-[12].C testsuire failures

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

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

H.J. Lu  changed:

   What|Removed |Added

   Keywords||patch
   Target Milestone|--- |12.0

--- Comment #9 from H.J. Lu  ---
A patch is posted at

https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590191.html

[Bug target/95082] [11] LE implementations of vec_cnttz_lsbb and vec_cntlz_lsbb are wrong

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

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

Bill Schmidt  changed:

   What|Removed |Added

  Known to work||12.0
Summary|[11/12] LE implementations  |[11] LE implementations of
   |of vec_cnttz_lsbb and   |vec_cnttz_lsbb and
   |vec_cntlz_lsbb are wrong|vec_cntlz_lsbb are wrong
  Known to fail||11.0

--- Comment #8 from Bill Schmidt  ---
This still needs a backport to 11, but I won't be able to work on that.

[Bug rtl-optimization/104498] Alias attribute being ignored by scheduler

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

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

--- Comment #7 from avieira at gcc dot gnu.org ---
And I was thinking it didn't know how to handle anchor + offset...

Anyway if I just record the swap and use it to invert the distance calculation
that seems to 'work' for the testcase. I'm happy to go bootstrap it, or would
you rather fix this some other way?

[Bug analyzer/104274] FAIL: gcc.dg/analyzer/pr97029.c (test for excess errors)

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #6 from David Malcolm  ---
Should be fixed by the above patch (I tested pr97029.c successfully with
--target=hppa64-hpux11.3); marking as resolved.

[Bug target/94395] Powerpc suboptimal 64-bit constant generation near large values with few bits set

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

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

Christophe Leroy  changed:

   What|Removed |Added

 CC||christophe.leroy at csgroup 
dot eu

--- Comment #2 from Christophe Leroy  ---
Problem still present with GCC 11.2

Linux kernel has a huge amount of sequences like:

  b4:   3d 20 fc ff lis r9,-769
  b8:   61 29 ff ff ori r9,r9,65535
  bc:   79 29 07 c6 rldicr  r9,r9,32,31
  c0:   65 29 ff ff orisr9,r9,65535
  c4:   61 29 ff ff ori r9,r9,65535
  c8:   7d 3d 03 a6 mtamr   r9

Could instead be:

  li  r9, -769
  rotldi  r9, r9, 48

[Bug analyzer/104274] FAIL: gcc.dg/analyzer/pr97029.c (test for excess errors)

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

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

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

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

commit r12-7199-gcc68ad87014a331399ccb2528db3bf47fabe6f72
Author: David Malcolm 
Date:   Thu Feb 10 19:01:30 2022 -0500

analyzer: ignore uninitialized uses of empty types [PR104274]

PR analyzer/104274 reports a false positive from
-Wanalyzer-use-of-uninitialized-value on hppa when passing
an empty struct as a function parameter.

pa_pass_by_reference returns true for empty structs, so the
call is turned into:

  struct empty arg.0;
  arg.0 = arg
  called_function (arg.0);

by gimplify_parameters.

However, gimplify_modify_expr discards assignments statments
of empty types, so that we end up with:

  struct empty arg.0;
  called_function (arg.0);

which the analyzer considers to be a use of uninitialized "arg.0";

Given that gimplify_modify_expr will discard any assignments to
such types, it seems simplest for -Wanalyzer-use-of-uninitialized-value
to ignore values of empty types.

gcc/analyzer/ChangeLog:
PR analyzer/104274
* region-model.cc (region_model::check_for_poison): Ignore
uninitialized uses of empty types.

gcc/testsuite/ChangeLog:
PR analyzer/104274
* gcc.dg/analyzer/torture/empty-struct-1.c: New test.

Signed-off-by: David Malcolm 

[Bug fortran/102330] [12 Regression] ICE in expand_gimple_stmt_1, at cfgexpand.c:3932 since r12-980-g29a2f51806c

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

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

--- Comment #11 from Thomas Schwinge  ---
Jakub, thanks again for your comments!


I've written down the following while working through the issue.  Maybe you'd
like to verify, and maybe it'll useful for someone later (if only my future
self...).


(In reply to Thomas Schwinge from comment #8)
> (In reply to Richard Biener from comment #1)
> > Confirmed.  omp expansion seems to introudce this non-gimple code and 
> > likely also makes 'i' not a register (for OACC):
> > 
> >   .data_dep.5D.4044 = .UNIQUE (OACC_PRIVATE, .data_dep.5D.4044, -1, 
> > );
> 
> That's built in 'gcc/omp-low.cc:lower_oacc_private_marker'.  It's not marked
> 'TREE_ADDRESSABLE' (per debug log above), but the address of 'i' has been
> taken (here).

> So if in 'gcc/omp-expand.cc:expand_oacc_for' I force 'TREE_ADDRESSABLE',
> then the ICE goes away, and we get valid GIMPLE generated, per my
> understanding.
> 
> So, something like this maybe (untested)?  
> 
> --- gcc/omp-low.cc
> +++ gcc/omp-low.cc
> @@ -11513,6 +11513,7 @@ lower_oacc_private_marker (omp_context *ctx)
> }
>gcc_checking_assert (decl);
>  
> +  TREE_ADDRESSABLE (decl) = 1;
>tree addr = build_fold_addr_expr (decl);
>args.safe_push (addr);
>  }

That's bogus: per 'gcc/omp-low.cc:oacc_privatization_candidate_p', we should
only be getting here for 'TREE_ADDRESSABLE' DECLs.  Adding such an 'assert', it
triggers exactly for test cases like those we're discussing here.

However, before we look into the OpenACC privatization details, let's first
turn your test case into an OpenMP-only code, as follows:

(Based on Jakub Jelinek from comment #7)
>  program p
>i = 0
>!$omp task shared(i)
>i = 1
>!$omp end task
>!$omp taskwait
> -  !$acc parallel loop
> +  !$omp parallel do
>do i = 1, 8
> + call f(i)
>end do
> +  contains
> +
> +subroutine f(v)
> +  integer :: v
> +  !integer, value :: v
> +end
>  end

The 'call f(i)' serves as a convenient means to toggle whether or not 'i' in
the loop body needs to be addressable.

Using the 'integer :: v' variant, the 'call f(i)' is by-reference, and thus 'i'
is made "early 'TREE_ADDRESSABLE'".

Relevant part of '*.original' dump:

[...]
void p ()
{
  [...]
  integer(kind=4)D.8 iD.4232;

  iD.4232 = 0;
  #pragma omp task shared(iD.4232)
{
  {
{
  iD.4232 = 1;
}
  }
}
  __builtin_GOMP_taskwaitD.494 ();
  #pragma omp parallel
{
  {
#pragma omp for nowait
for (iD.4232 = 1; iD.4232 <= 8; iD.4232 = iD.4232 + 1)
  {
{
  fD.4229 ();
}
L.1D.4233:;
  }
  }
}
}
[...]

Given this "early 'TREE_ADDRESSABLE'" (notice 'fD.4229 ();'), already
the gimplifier replaces the original loop variable 'iD.4232' with a
non-addressable 'i.1D.4239'.  Relevant part (edited) of '*.original' vs.
'*.gimple' dumps diff:

   #pragma omp parallel
 {
+  integer(kind=4)D.8 i.1D.4239;
+
-#pragma omp for nowait
-for (iD.4232 = 1; iD.4232 <= 8; iD.4232 = iD.4232 + 1)
+  #pragma omp for nowait private(i.1D.4239) private(iD.4232)
+  for (i.1D.4239 = 1; i.1D.4239 <= 8; i.1D.4239 = i.1D.4239 + 1)
 {
+  iD.4232 = i.1D.4239;
   {
 fD.4229 ();
   }

In particular, notice that now a 'private(i.1D.4239)' appears in addition to
'private(iD.4232)'.

The OMP lowering then again replaces the loop variable 'i.1D.4239' with
'i.1D.4255' (I have not researched why) -- but it doesn't update the
'private(i.1D.4239)' clause accordingly (so that one persists, continues to
point to the original, now-unused DECL), and/or it doesn't introduce a new
'private(i.1D.4255)' replacement clause.  Similar for the 'iD.4232' ->
'iD.4256' transformation and unchanged 'private(iD.4232)' clause.  Relevant
part (edited) of '*.gimple' vs. '*.omplower' dumps diff:

   #pragma omp parallel [...]
   {
-  integer(kind=4)D.8 i.1D.4239;
+  integer(kind=4)D.8 iD.4256;
+  integer(kind=4)D.8 i.1D.4255;

   #pragma omp for nowait private(i.1D.4239) private(iD.4232)
-  for (i.1D.4239 = 1; i.1D.4239 <= 8; i.1D.4239 = i.1D.4239 + 1)
+  for (i.1D.4255 = 1; i.1D.4255 <= 8; i.1D.4255 = i.1D.4255 +
1)
   {
-  iD.4232 = i.1D.4239;
+  iD.4256 = i.1D.4255;
   {
-fD.4229 ();
+fD.4229 (); [static-chain: [...]]

I have confirmed that 'lookup_decl([i.1D.4239], ctx)' -> 'i.1D.4255' and
'lookup_decl([iD.4232], ctx)' -> 'iD.4256'.  The underlying 

[Bug c++/99243] [modules] ICE in set_filename, at cp/module.cc:19143

[egor.pugin at gmail dot com via Gcc-bugs]

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

Egor Pugin  changed:

   What|Removed |Added

 CC||egor.pugin at gmail dot com

--- Comment #2 from Egor Pugin  ---
See explanation of this issue and the potential fix at the second part of the
PR.
https://github.com/urnathan/libcody/pull/27#issue-1132612910

[Bug rtl-optimization/104498] Alias attribute being ignored by scheduler

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-02-11
 Status|UNCONFIRMED |NEW

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
The problem is that compare_base_symbol_refs can swap x and y:

  if (!x_decl)
{
  std::swap (x_decl, y_decl);
  std::swap (x_base, y_base);
}

but this doesn't change the polarity of the distance added here:

  if (distance)
*distance += (SYMBOL_REF_BLOCK_OFFSET (y_base)
  - SYMBOL_REF_BLOCK_OFFSET (x_base));

[Bug c++/100617] [modules] Exported namespace not visible from outside when the module imports another module that declares the same namespace

[johelegp at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Johel Ernesto Guerrero Peña  ---
(In reply to wang ivor from comment #1)
> A workaround is to create a module that exports only the namespace A and
> 'export import' it in the module 'test1'.

I did that, but it's not enough. See Bug 102524.

I export a `detail` namespace like this to workaround the issue in its parent
namespace:
```C++
export module waarudo.details.workaround_gcc_bug_100617;

export namespace waarudo::detail {

void workaround_gcc_bug_100617() { }

} // namespace waarudo::detail

```

[Bug tree-optimization/104501] New: vector lowering for VEC_COND_EXPR does not consider smaller vectors

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

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

Bug ID: 104501
   Summary: vector lowering for VEC_COND_EXPR does not consider
smaller vectors
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

The following C++ testcase is decomposed to scalar operations by vector
lowering when compiling with just SSE2 support.  But when using a vector size
of 16 we
can produce optimized code.

typedef int vsi __attribute__((vector_size(32)));

vsi res, v1, v2, v3, v4;

void foo ()
{
  res = v1 == v2 ? v3 : v4;
}

[Bug c++/104472] ICE: SIGSEGV in cxx_eval_internal_function with __builtin_convertvector and -frounding-math

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

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

--- Comment #3 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug middle-end/104446] [9/10/11 Regression] ICE in trunc_int_for_mode, at explow.cc:59 since r9-6999

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10/11/12 Regression] ICE |[9/10/11 Regression] ICE in
   |in trunc_int_for_mode, at   |trunc_int_for_mode, at
   |explow.cc:59 since r9-6999  |explow.cc:59 since r9-6999

--- Comment #7 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/104472] ICE: SIGSEGV in cxx_eval_internal_function with __builtin_convertvector and -frounding-math

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:84993d94e13ad2ab3aee151bb5a5e767cf75d51e

commit r12-7197-g84993d94e13ad2ab3aee151bb5a5e767cf75d51e
Author: Jakub Jelinek 
Date:   Fri Feb 11 13:52:44 2022 +0100

c++: Fix up constant expression __builtin_convertvector folding [PR104472]

The following testcase ICEs, because due to the -frounding-math
fold_const_call fails, which is it returns NULL, and returning NULL from
cxx_eval* is wrong, all the callers rely on them to either return folded
value or original with *non_constant_p = true.

The following patch does that, and additionally falls through into the
default case where there is diagnostics for the !ctx->quiet case too.

2022-02-11  Jakub Jelinek  

PR c++/104472
* constexpr.cc (cxx_eval_internal_function) :
Only return fold_const_call result if it is non-NULL.  Otherwise
fall through into the default: case to return t, set
*non_constant_p
and emit diagnostics if needed.

* g++.dg/cpp0x/constexpr-104472.C: New test.

[Bug middle-end/104446] [9/10/11/12 Regression] ICE in trunc_int_for_mode, at explow.cc:59 since r9-6999

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r12-7196-gfb76c0ad35f96505ecd9213849ebc3df6163a0f7
Author: Jakub Jelinek 
Date:   Fri Feb 11 11:34:46 2022 +0100

combine: Fix ICE with substitution of CONST_INT into PRE_DEC argument
[PR104446]

The following testcase ICEs, because combine substitutes
(insn 10 9 11 2 (set (reg/v:SI 7 sp [ a ])
(const_int 0 [0])) "pr104446.c":9:5 81 {*movsi_internal}
 (nil))
(insn 13 11 14 2 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [0  S4 A32])
(reg:SI 85)) "pr104446.c":10:3 56 {*pushsi2}
 (expr_list:REG_DEAD (reg:SI 85)
(expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil
forming
(insn 13 11 14 2 (set (mem/f:SI (pre_dec:SI (const_int 0 [0])) [0  S4 A32])
(reg:SI 85)) "pr104446.c":10:3 56 {*pushsi2}
 (expr_list:REG_DEAD (reg:SI 85)
(expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil
which is invalid RTL (pre_dec's argument must be a REG).
I know substitution creates various forms of invalid RTL and hopes that
invalid RTL just won't recog.
But unfortunately in this case we ICE before we get to recog, as
try_combine does:
  if (n_auto_inc)
{
  int new_n_auto_inc = 0;
  for_each_inc_dec (newpat, count_auto_inc, _n_auto_inc);

  if (n_auto_inc != new_n_auto_inc)
{
  if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, "Number of auto_inc expressions
changed\n");
  undo_all ();
  return 0;
}
}
and for_each_inc_dec under the hood will do e.g. for the PRE_DEC case:
case PRE_DEC:
case POST_DEC:
  {
poly_int64 size = GET_MODE_SIZE (GET_MODE (mem));
rtx r1 = XEXP (x, 0);
rtx c = gen_int_mode (-size, GET_MODE (r1));
return fn (mem, x, r1, r1, c, data);
  }
and that code rightfully expects that the PRE_DEC operand has non-VOIDmode
(as it needs to be a REG) - gen_int_mode for VOIDmode results in ICE.
I think it is better not to emit the clearly invalid RTL during
substitution
like we do for other cases, than to adding workarounds for invalid IL
created by combine to rtlanal.cc and perhaps elsewhere.
As for the testcase, of course it is UB at runtime to modify sp that way,
but if such code is never reached, we must compile it, not to ICE on it.
And I don't see why on other targets which use the autoinc rtxes much more
it couldn't happen with other registers.

2022-02-11  Jakub Jelinek  

PR middle-end/104446
* combine.cc (subst): Don't substitute CONST_INTs into RTX_AUTOINC
operands.

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

[Bug rtl-optimization/104498] Alias attribute being ignored by scheduler

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

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

--- Comment #5 from avieira at gcc dot gnu.org ---
You mean this https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294

it only works for direct symbols I think it never enters
the block under: if (GET_CODE (x) == SYMBOL_REF && GET_CODE (y) == SYMBOL_REF)

which is where he made his changes. I'll go try to understand his changes
better, just had a quick look over.

[Bug tree-optimization/104499] [12 Regression] ICE: in emit_move_insn, at expr.cc:4010 at -O1

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/100617] [modules] Exported namespace not visible from outside when the module imports another module that declares the same namespace

[asynts+bugs at gmail dot com via Gcc-bugs]

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

Paul Scharnofske  changed:

   What|Removed |Added

 CC||asynts+bugs at gmail dot com

--- Comment #2 from Paul Scharnofske  ---
I ran into the same issue and produced a slightly different example:

```c++
// foo.cpp
export module foo;

import bar;

namespace foo
{
export void foo() { }
}
```
```c++
// bar.cpp
export module bar;

namespace foo
{

}
```
```c++
// baz.cpp
export module baz;

import foo;
import bar;

int main() {
foo::foo();
}
```
```none
$ ~/.local/lib/gcc-trunk/bin/g++ --version
g++ (GCC) 12.0.1 20220211 (experimental)
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ ~/.local/lib/gcc-trunk/bin/g++ -Wall -Wextra -std=c++20 -fmodules-ts bar.cpp
foo.cpp baz.cpp
baz.cpp: In function 'int main()':
baz.cpp:8:5: error: 'foo' has not been declared
8 | foo::foo();
  | ^~~
baz.cpp: At global scope:
baz.cpp:2:8: warning: not writing module 'baz' due to errors
2 | export module baz;
  |^~
```
https://godbolt.org/z/8zMaq6eqr

-   In other words, the 'export' specifier doesn't even have to be mentioned.
It is enough if the same namespace is mentioned even if it is completely
empty and not exported.

-   The issue disappears if the 'import bar' is removed from 'foo.cpp', in
other words, this only happens
if that module is actually imported.  It doesn't matter that it's still
imported in 'baz.cpp'.

[Bug sanitizer/101476] AddressSanitizer check failed, points out a (potentially) non-existing stack error and pthread_cancel

[stsp at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #17 from Stas Sergeev  ---
I sent the small patch-set here:
https://lore.kernel.org/lkml/20220126191441.3380389-1-st...@yandex.ru/
but it is so far ignored by kernel developers.
Someone from this bugzilla should give me an
Ack or Review, or this won't float.

[Bug rtl-optimization/104499] [12 Regression] ICE: in emit_move_insn, at expr.cc:4010 at -O1

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Last reconfirmed||2022-02-11
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Priority|P3  |P1
   Target Milestone|--- |12.0

--- Comment #1 from Jakub Jelinek  ---
Started with r12-5489-g0888d6bbe97e10de0e624f4ab46acc276e5ee1d7

[Bug c++/101140] [modules] no matching function for call to ‘operator new(sizetype, void*)’

[asynts+bugs at gmail dot com via Gcc-bugs]

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

Paul Scharnofske  changed:

   What|Removed |Added

 CC||asynts+bugs at gmail dot com

--- Comment #2 from Paul Scharnofske  ---
I had a very similar problem:

```c++
// foo.cpp
export module foo;

using size_t = decltype(sizeof(int));

void* operator new(size_t, void *pointer) {
return pointer;
}

export
template
void foo() {
T t;
new () T;
}
```
```c++
// bar.cpp
export module bar;

import foo;

void bar() {
foo();
}
```
```c++
// main.cpp
export module main;

import foo;
import bar;

int main() {

}
```
```none
$ ~/.local/lib/gcc-trunk/bin/g++ --version
g++ (GCC) 12.0.1 20220211 (experimental)
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ ~/.local/lib/gcc-trunk/bin/g++ -Wall -Wextra -std=c++20 -fmodules-ts foo.cpp
bar.cpp main.cpp
In module foo, imported at bar.cpp:4:
foo.cpp: In instantiation of 'void foo@foo() [with T = int]':
bar.cpp:7:13:   required from here
foo.cpp:14:5: error: no matching function for call to 'operator new(sizetype,
int*)'
   14 | new () T;
  | ^~
: note: candidate: 'void* operator new(long unsigned int)'
: note:   candidate expects 1 argument, 2 provided
: note: candidate: 'void* operator new(long unsigned int,
std::align_val_t)'
: note:   no known conversion for argument 2 from 'int*' to
'std::align_val_t'
bar.cpp:2:8: warning: not writing module 'bar' due to errors
2 | export module bar;
  |^~
In module imported at main.cpp:5:1:
bar: error: failed to read compiled module: No such file or directory
bar: note: compiled module file is 'gcm.cache/bar.gcm'
bar: note: imports must be built before being imported
bar: fatal error: returning to the gate for a mechanical issue
compilation terminated.
```
https://godbolt.org/z/es5he4hc4

It appears that the compiler tries to lookup the placement new operator in the
module
where the template instantiation happens.
In my mind, the correct behavior would be to look this up in the module where
the
template is defined.
However, I am not familiar with the standard.

There are several ways, this code can be changed to work:

 1. Add 'export' to the 'operator new'.
However, this requires that the module that defines the operator new is
imported
by the module directly.
https://godbolt.org/z/nxY681PeK

 2. Remove the template parameter from 'foo'.
https://godbolt.org/z/1T9Erjdz3

[Bug tree-optimization/102586] [12 Regression] ICE in clear_padding_type, at gimple-fold.c:4798 since r12-3433-ga25e0b5e6ac8a77a

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

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

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

Indeed, and when creating BIT_CAST_EXPR we actually verify those
trivially_copyable_p types.

This patch implements the rejection of pointers to non-trivially-copyable types
with the exception of  or , because in those cases we know it is
complete object type and so don't need to worry about it being just a
subobject.
I think the exception for that case is useful, so that users can still clear
the padding bits on them, but the restriction means that they need to use the
builtin directly or in a macro rather than through inline function.
But the risks of clobbering real data otherwise is real.

The other option would be just document that it shouldn't be called on
non-trivially-copyable base classes and make it user's responsibility.
For the  and std::bit_cast uses it doesn't really matter.

[Bug rtl-optimization/104498] Alias attribute being ignored by scheduler

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
(In reply to avieira from comment #3)
> Sorry some confusion there, I thought it was base_alias_check bailing out
> early, but that seems to return true, it is the memrefs_conflict_p that
> returns 0.
> 
> I suspect rtx_equal_for_memref_p should have returned 1 for:
> x:
> (plus:DI (mult:DI (reg:DI 99 [ off.0_1 ])
> (const_int 4 [0x4]))
> (const:DI (plus:DI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
> (const_int 16 [0x10]
> 
> and y:
> (plus:DI (mult:DI (reg:DI 99 [ off.0_1 ])
> (const_int 4 [0x4]))
> (symbol_ref:DI ("b") [flags 0x2] ))
> 
> But it does not... must be because of that trailing (equivalence notes?
> that's what I assume they are?)

It's the section anchor that breaks things.  There's a duplicate bug about this
somewhere, or a thread on the mailing list.  But IIRC Richard had fixed this?

[Bug libstdc++/104500] New: Document directory layout for installed C++ headers

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

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

Bug ID: 104500
   Summary: Document directory layout for installed C++ headers
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Keywords: documentation
  Severity: minor
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

https://gcc.gnu.org/onlinedocs/libstdc++/manual/source_organization.html
describes the directory layout in the source tree, but we have nothing
describing the post-install tree.

Draft:

Libstdc++ headers are always split across three directories:

$prefix/include/c++/$version: Most headers are here, and are
target-independent.
$prefix/include/c++/$version/$triplet: target-specific headers such as
bits/c++config.h, CPU-specific atomics (predating __atomic built-ins and
libatomic), and headers that depend on the build-time GCC config options like
the choice of thread model, locale backend, allocator backend, etc.
$prefix/include/c++/$version/backward:  and legacy headers like
.

The second one will be modified by the multilib options, so on x86_64 -m32 will
use $prefix/include/c++/$version/$triplet/32 instead.

In all cases, $version might be X.Y.Z or just X if GCC was configured with
--with-gcc-major-version-only

[Bug rtl-optimization/104498] Alias attribute being ignored by scheduler

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

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

--- Comment #3 from avieira at gcc dot gnu.org ---
Sorry some confusion there, I thought it was base_alias_check bailing out
early, but that seems to return true, it is the memrefs_conflict_p that returns
0.

I suspect rtx_equal_for_memref_p should have returned 1 for:
x:
(plus:DI (mult:DI (reg:DI 99 [ off.0_1 ])
(const_int 4 [0x4]))
(const:DI (plus:DI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
(const_int 16 [0x10]

and y:
(plus:DI (mult:DI (reg:DI 99 [ off.0_1 ])
(const_int 4 [0x4]))
(symbol_ref:DI ("b") [flags 0x2] ))

But it does not... must be because of that trailing (equivalence notes? that's
what I assume they are?)

[Bug rtl-optimization/104499] New: [12 Regression] ICE: in emit_move_insn, at expr.cc:4010 at -O1

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 104499
   Summary: [12 Regression] ICE: in emit_move_insn, at
expr.cc:4010 at -O1
   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: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c 
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:6:1: internal compiler error: in emit_move_insn, at expr.cc:4010
6 | foo (void)
  | ^~~
0x6cb317 emit_move_insn(rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/expr.cc:4010
0xe71cfa expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.cc:3994
0xe71cfa expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.cc:4028
0xe779b8 expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.cc:6069
0xe79b47 execute
/repo/gcc-trunk/gcc/cfgexpand.cc:6795
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

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

[Bug rtl-optimization/104459] [9/10/11 Regression] '-fcompare-debug' failure w/ -O2 -funswitch-loops -fno-tree-dce

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10/11/12 Regression] |[9/10/11 Regression]
   |'-fcompare-debug' failure   |'-fcompare-debug' failure
   |w/ -O2 -funswitch-loops |w/ -O2 -funswitch-loops
   |-fno-tree-dce   |-fno-tree-dce

--- Comment #6 from Jakub Jelinek  ---
Fixed on the trunk.  I'll prefer to wait quite a long before considering to
backport this though.

[Bug target/104496] [12 Regression] ICE: in as_a, at machmode.h:365 with -O -mgeneral-regs-only -msse

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug libstdc++/104495] call_once hangs in call after exceptional call

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

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

--- Comment #11 from Jonathan Wakely  ---
If you've entered any text or adjusted any dropdown selections while on the
page, then refreshing will preserve those changes.

[Bug target/104496] [12 Regression] ICE: in as_a, at machmode.h:365 with -O -mgeneral-regs-only -msse

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

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

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

https://gcc.gnu.org/g:72f8d228aff80ede554b1735533af7eb0bd4a912

commit r12-7195-g72f8d228aff80ede554b1735533af7eb0bd4a912
Author: Richard Biener 
Date:   Fri Feb 11 10:27:20 2022 +0100

middle-end/104496 - fix vectorized_internal_fn_supported_p

This fixes vectorized_internal_fn_supported_p behavior when
facing vector types with an integer mode.

2022-02-11  Richard Biener  

PR middle-end/104496
* internal-fn.cc (vectorized_internal_fn_supported_p):
Bail out for integer mode vector types.

* gcc.target/i386/pr104496.c: New testcase.

[Bug rtl-optimization/104498] Alias attribute being ignored by scheduler

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

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

--- Comment #2 from Richard Biener  ---
I don't see how it can with those MEMs.  Can you show the canonicalized (CSELIB
expanded) RTXen the base_alias_check routine sees?

[Bug rtl-optimization/104459] [9/10/11/12 Regression] '-fcompare-debug' failure w/ -O2 -funswitch-loops -fno-tree-dce

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:18c8086d65f3d539e065ea7c97e3de6f3bbdf684

commit r12-7194-g18c8086d65f3d539e065ea7c97e3de6f3bbdf684
Author: Jakub Jelinek 
Date:   Fri Feb 11 11:21:24 2022 +0100

df: Don't set bbs dirty because of debug insn moves [PR104459]

As mentioned in the PR, we get -fcompare-debug failure, which is caused by
cfg_layout_merge_blocks successfully merging two bbs where both bbs
contained just CODE_LABEL, NOTE_INSN_BASIC_BLOCK and in the -g case both
some debug insns at the end.  cfg_layout_merge_blocks calls
update_bb_for_insn_chain which for the post-label insns in the second block
(except for BARRIERs) calls df_insn_change_bb.  This function changes
the bb of the insns and for notes just punts, but for other insns calls
df_set_bb_dirty.  Now the problem is that because there were only debug
insns and notes in the second block, df_set_bb_dirty is called on both
only in the -g case and not with -g0.  df_set_bb_dirty these days
sets both the BB_MODIFIED flag and marks the bb as dirty, and the former
is what 6 spots in cfgcleanup.cc use in code-generation decisions,
in this case
  may_thread |= (target->flags & BB_MODIFIED) != 0;
in particular.  So, with -g may_thread is true while with -g0 it is not
and we diverge from that point onwards.
I've thought about introducing df_set_bb_dirty_nondebug that wouldn't
set BB_MODIFIED but would mark the bb dirty, but then I went through
history and found changes like:
https://gcc.gnu.org/legacy-ml/gcc-patches/2010-10/msg00059.html
so I've also tried just not calling df_set_bb_dirty for debug insns
at all and it passed x86_64-linux and i686-linux
--enable-checking=yes,rtl,extra,df bootstraps/regtests, so perhaps
that works too.
Now that I look at it again, if we don't need those from %d to %d messages
for debug insns in the dump files, another way to fix it would be just to
change the very first line in the hunk from
  if (!INSN_P (insn))
to
  if (!DEBUG_INSN_P (insn))
Though, df_set_bb_dirty_nondebug which will do everything but
set bb->flags |= BB_MODIFIED is yet another option I can test.
Perhaps even that PR42889 was solely about those 6 decisions in cfgcleanup
(at that point it used df_get_bb_dirty) and not about actually the
recomputation of some of the problems causing different code generations.

2022-02-11  Jakub Jelinek  

PR rtl-optimization/104459
* df-scan.cc (df_insn_change_bb): Don't call df_set_bb_dirty when
moving DEBUG_INSNs between bbs.

* gcc.dg/pr104459.c: New test.

[Bug target/104489] nvptx, sm_53: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.cc:1022

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |roger at 
nextmovesoftware dot com
   Last reconfirmed||2022-02-11

--- Comment #3 from Roger Sayle  ---
Patch proposed:
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590139.html

[Bug target/104489] nvptx, sm_53: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.cc:1022

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

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

Tom de Vries  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #2 from Tom de Vries  ---
Minimal reproducer:
...
typedef float HFtype __attribute__ ((mode (HF)));

HFtype
mulhf (HFtype a, HFtype b)
{
  return a * b;
}
...

[Bug tree-optimization/104497] [11/12 Regression] Invalid gimple produced for (A?vect:vect)[i]

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

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

--- Comment #7 from Richard Biener  ---
Interestingly the C++ frontend handles the COND_EXPR like

  (void) (VIEW_CONVERT_EXPR(y)[i] = (i & 1) != 0 ?
VIEW_CONVERT_EXPR(inv)[i] : VIEW_CONVERT_EXPR(src)[i]) >;

avoiding this issue.

[Bug tree-optimization/104497] [11/12 Regression] Invalid gimple produced for (A?vect:vect)[i]

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

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

--- Comment #6 from Richard Biener  ---
At -O0 we don't ICE but still have invalid

  _2 = VIEW_CONVERT_EXPR(iftmp.0_4)[i_7(D)];

at RTL expansion.  We're somehow recovering here, IIRC RTL expansion makes sure
to expand iftmp.0_4 to memory.

[Bug tree-optimization/104497] [11/12 Regression] Invalid gimple produced for (A?vect:vect)[i]

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

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

--- Comment #5 from Richard Biener  ---
So the issue here is that gimplification creates

  :
  iftmp.0 = inv;
  goto ;
  :
  iftmp.0 = src;
  :
  _2 = VIEW_CONVERT_EXPR(iftmp.0)[i];

that requires a non-register iftmp.0, but we neither set DECL_NOT_GIMPLE_REG_P
nor TREE_ADDRESSABLE on iftmp.0.  If we did the iftmp.0 = {inv,src}; stmts
also would need different gimplification.

Later update_address_taken comes along and "fixes" the missing
DECL_NOT_GIMPLE_REG_P but that then makes the assigns invalid IL.

We do not support ARRAY_REF (or COMPONENT_REF) on registers.

[Bug tree-optimization/104497] [11/12 Regression] Invalid gimple produced for (A?vect:vect)[i]

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Let me have a look.

[Bug rtl-optimization/104498] Alias attribute being ignored by scheduler

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

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

--- Comment #1 from avieira at gcc dot gnu.org ---
Forgot to mention, this happens during the sched1 pass.

[Bug rtl-optimization/104498] New: Alias attribute being ignored by scheduler

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

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

Bug ID: 104498
   Summary: Alias attribute being ignored by scheduler
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: avieira at gcc dot gnu.org
  Target Milestone: ---

Whilst working on a tuning structure I saw a correctness regression that I
believe is a result of the alias attribute not working properly.

You can reproduce it using an existing tuning for AArch64 using:
gcc -O2 src/gcc/gcc/testsuite/gcc.c-torture/execute/alias-2.c -S
-mtune=cortex-a34

This will lead to the 'a[off] = 2' store being moved after the b load in
'b[off] != 2'.

In RTL:

(insn 23 18 19 2 (set (reg:SI 110 [ b[off.0_1] ])
(mem:SI (plus:DI (mult:DI (reg:DI 99 [ off.0_1 ])
(const_int 4 [0x4]))
(reg/f:DI 97)) [1 b[off.0_1]+0 S4 A32]))
"gcc/gcc/testsuite/gcc.c-torture/execute/alias-2.c":10:6 52 {*movsi_aarch64}
 (expr_list:REG_DEAD (reg:DI 99 [ off.0_1 ])
(expr_list:REG_DEAD (reg/f:DI 97)
(nil
(insn 19 23 24 2 (set (mem:SI (plus:DI (mult:DI (reg:DI 99 [ off.0_1 ])
(const_int 4 [0x4]))
(reg/f:DI 104)) [1 a[off.0_1]+0 S4 A32])
(reg:SI 106)) "gcc/gcc/testsuite/gcc.c-torture/execute/alias-2.c":9:9
52 {*movsi_aarch64}
 (expr_list:REG_DEAD (reg:SI 106)
(expr_list:REG_DEAD (reg/f:DI 104)
(nil

After some debugging I found that true_dependence returns false for these two
memory accesses because base_alias_check sees they have different base objects
('a' and 'b') and deduces they can't alias based on that, without realising 'b'
isn't an actual base object but an alias to 'a'. I think we should make it so
that at expand pointers to 'b' get 'a' as a base object.

[Bug target/104496] [12 Regression] ICE: in as_a, at machmode.h:365 with -O -mgeneral-regs-only -msse

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Last reconfirmed||2022-02-11
 Ever confirmed|0   |1

--- Comment #4 from Richard Biener  ---
So the issue is that for GPR mode vectors vectorized_internal_fn_supported_p
isn't careful enough.  Let me fix that.