[Bug c++/65211] [9/10/11/12 Regression] Type alignment lost inside templated function

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Type alignment lost inside  |[9/10/11/12 Regression]
   |templated function  |Type alignment lost inside
   ||templated function
  Known to fail||4.1.2, 4.5.3
  Known to work||4.4.7
   Target Milestone|--- |9.5

[Bug c++/65211] Type alignment lost inside templated function

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-12-05
 Ever confirmed|0   |1

--- Comment #5 from Andrew Pinski  ---
Confirmed, simplified testcase:
typedef unsigned v4ui __attribute__ ((vector_size(16), aligned (16)));
typedef unsigned v4ui_unaligned __attribute__ ((vector_size (16), aligned
(4)));
template
static v4ui t(unsigned *dest_data)
{
return ((const v4ui_unaligned*)dest_data)[0];
}
template
static v4ui t1(unsigned *dest_data)
{
typedef unsigned v4ui_1 __attribute__ ((vector_size (16), aligned (4)));
return ((const v4ui_1*)dest_data)[0];
}
v4ui g(unsigned int *array)
{
return t<1>(array+7);
}
v4ui f(unsigned int *array)
{
return t1<1>(array+7);
}

Still a bug on the trunk even.

[Bug tree-optimization/96051] alloca(0) triggers TCO for VLA

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Last reconfirmed||2021-12-05
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
  /* If the code both contains VLAs and calls alloca, then we cannot reclaim
 the stack space allocated to the VLAs.  */

And the stack restore in the case of VLA without the alloca just happens to be
after the recusive function call to no_tco_with_vla_only.

To do this optimization, we need to move the stack restore before the recusive
function call and for that we need to make sure the VLA address never escapes.

Anyways Confirmed.

[Bug c++/55918] Stack partially unwound when noexcept causes call to std::terminate

[foom at fuhm dot net via Gcc-bugs]

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

--- Comment #6 from James Y Knight  ---
I realize that my suggestion above could only solve _most_ of the problem --
e.g. the original example, where the noexcept function doesn't have a try/catch
in it.

In that original example, there's no entry for the IP of the call in the LSDA
table. The personality fn already knows during phase1 that this indicates
termination -- but it simply fails to actually trigger the terminate in phase1,
even though it easily could (& should!).


However, in the example from comment #4, there _WILL_ be an entry in the
callsite table covering the throw (necessarily, in order to to catch type
"float"), so the "missing callsite => terminate" mechanism isn't applicable in
that case. As the comment mentioned, to handle that, we'd need some alternative
indication for termination which can be put in the action list.

ISTM this could be done most straightforwardly by using an action record with a
ttype pointing to a new ABI-defined special-purpose symbol (e.g.
"__cxxabiv1::__eh_noexcept"). In libsupc++'s impl, that symbol can be an object
whose type is a new std::type_info subclass, whose __do_catch overload calls
terminate. Thus, when the personality fn falls through all the _actual_ catch
action records, and comes to this, last one, it will query whether it can catch
an exception by calling its __do_catch, and immediately trigger termination.

GCC, then, can emit that as the last "catch" action in the chain for a
try/catch in a noexcept function (instead of the cleanup action with code that
calls std::terminate explicitly in the cleanup, that it does now).

[Bug jit/103562] New: Jitted code produces incorrect result when returning 3-member struct from internal function

[andy.pj.hanson at gmail dot com via Gcc-bugs]

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

Bug ID: 103562
   Summary: Jitted code produces incorrect result when returning
3-member struct from internal function
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: andy.pj.hanson at gmail dot com
  Target Milestone: ---

Created attachment 51927
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51927=edit
File that reproduces the bug

See the attached program `jit_error.c`. To reproduce, run: `gcc jit_error.c
-lgccjit && ./a.out`. This will output: `get_a() is 140730936729392` (or some
other large number); The correct output would be 1.

The file should JIT a program like this:
```
struct my_struct { long a; long b; long c; };
struct my_struct deref(struct my_struct *ptr) { return *ptr; } 
long get_a(struct my_struct *s) { return deref(s).a; }
```

For some reason, the function `deref` is optimized in an invalid way.

The bug goes away (and the program correctly outputs 1) if you do any one of
the following:

* Set GCC_JIT_INT_OPTION_OPTIMIZATION_LEVEL to 0.
* Remove the `c` field.
* Change `func_deref` from `GCC_JIT_FUNCTION_INTERNAL` to
`GCC_JIT_FUNCTION_EXPORTED`.
* Inline the call using `gcc_jit_rvalue *callDeref =
gcc_jit_lvalue_as_rvalue(gcc_jit_rvalue_dereference(gcc_jit_param_as_rvalue(param_get_a),
NULL));`.
* Use `GCC_JIT_TYPE_INT` instead of `GCC_JIT_TYPE_LONG`.

I've tested this the GCC master branch as of 20211204, and with OpenSUSE's GCC
version.

My `gcc -v` is:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/andy/temp/gccjitrepro2/install/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../src/configure --enable-host-shared
--enable-languages=jit,c++ --disable-bootstrap --disable-shared
--prefix=/home/andy/temp/gccjitrepro2/install
--with-gmp=/home/andy/temp/gccjitrepro2/build-gmp
--with-isl==/home/andy/temp/gccjitrepro2/build-isl
--with-mpfr=/home/andy/temp/gccjitrepro2/build-mpfr
--with-mpc=/home/andy/temp/gccjitrepro2/build-mpc
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211204 (experimental) (GCC)

[Bug c++/103561] New: internal compiler error: segmentation fault when using decay copy (auto(x)) inside requires expression

[cooky.ykooc922 at gmail dot com via Gcc-bugs]

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

Bug ID: 103561
   Summary: internal compiler error: segmentation fault when using
decay copy (auto(x)) inside requires expression
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cooky.ykooc922 at gmail dot com
  Target Milestone: ---

When I attempt to use `auto(expr)` or `auto{expr}` inside `requires`
expression:

#include 
#include 

template 
constexpr std::decay_t decay_copy(T&& x) noexcept {
return std::forward(x);
}

void dummy() {
int arr[] {1, 2, 1, 1};
static_assert(requires {
// ok:
{ arr } -> std::same_as;
// ok:
{ decay_copy(arr) } -> std::same_as;
// but:
{ auto(arr) } -> std::same_as;
});
}

The following will have an internal compiler error:
: In function 'void dummy()':
:17:19: internal compiler error: Segmentation fault
   17 | { auto(arr) } -> std::same_as;
  |   ^
0x20f3889 internal_error(char const*, ...)
???:0
0xa4571d template_parms_to_args(tree_node*)
???:0
0xa4f3c9 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
???:0
0xb3f325 build_functional_cast(unsigned int, tree_node*, tree_node*, int)
???:0
0xa2858d c_parse_file()
???:0
0xbb0f02 c_common_parse_file()
???:0

I'm using godbolt since GCC 12 is still experimental
(https://godbolt.org/z/M3GbGqMnb)

[Bug libfortran/103560] New: Error: GFC_INTEGER_4 should be available for the library to compile

[brocolis at eml dot cc via Gcc-bugs]

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

Bug ID: 103560
   Summary: Error: GFC_INTEGER_4 should be available for the
library to compile
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: brocolis at eml dot cc
  Target Milestone: ---

gcc-git master commit 8d4ef2299cbf9517877dab60d48f34835758a6ee
and snapshot https://gcc.gnu.org/pub/gcc/snapshots/12-20211128/ fail to build
on Windows/mingw.

This version https://gcc.gnu.org/pub/gcc/snapshots/12-20210905/ builds using
the same build command.

Build command:

../gcc-git/configure --enable-languages=c,c++,fortran
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
--target=x86_64-w64-mingw32 --enable-shared --disable-multilib
--disable-bootstrap --prefix=/build/mingw/dest-x86_64
--with-sysroot=/build/mingw/dest-x86_64 --disable-libstdcxx-pch
--disable-libstdcxx-verbose --disable-nls --disable-win32-registry
--enable-threads=posix --enable-libgomp --with-gmp=/build/mingw/gmp-x86_64
--with-mpfr=/build/mingw/mpfr-x86_64 --with-mpc=/build/mingw/mpc-x86_64
--with-isl=/build/mingw/isl-x86_64
make

Messages:

make[3]: Entering directory
'/build/mingw/build-gcc/x86_64-w64-mingw32/libgfortran'
/bin/sh ./libtool  --tag=CC   --mode=compile /build/mingw/build-gcc/./gcc/xgcc
-B/build/mingw/build-gcc/./gcc/
-L/build/mingw/dest-x86_64/x86_64-w64-mingw32/lib
-L/build/mingw/dest-x86_64/mingw/lib -isystem
/build/mingw/dest-x86_64/x86_64-w64-mingw32/include -isystem
/build/mingw/dest-x86_64/mingw/include
-B/build/mingw/dest-x86_64/x86_64-w64-mingw32/bin/
-B/build/mingw/dest-x86_64/x86_64-w64-mingw32/lib/ -isystem
/build/mingw/dest-x86_64/x86_64-w64-mingw32/include -isystem
/build/mingw/dest-x86_64/x86_64-w64-mingw32/sys-include-DHAVE_CONFIG_H -I.
-I../../../gcc-git/libgfortran  -iquote../../../gcc-git/libgfortran/io
-I../../../gcc-git/libgfortran/../gcc
-I../../../gcc-git/libgfortran/../gcc/config
-I../../../gcc-git/libgfortran/../libquadmath -I../.././gcc
-I../../../gcc-git/libgfortran/../libgcc -I../libgcc
-I../../../gcc-git/libgfortran/../libbacktrace -I../libbacktrace
-I../libbacktrace  -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla  -fcx-fortran-rules
-ffunction-sections -fdata-sections   -g -O2 -MT bounds.lo -MD -MP -MF
.deps/bounds.Tpo -c -o bounds.lo `test -f 'runtime/bounds.c' || echo
'../../../gcc-git/libgfortran/'`runtime/bounds.c
libtool: compile:  /build/mingw/build-gcc/./gcc/xgcc
-B/build/mingw/build-gcc/./gcc/
-L/build/mingw/dest-x86_64/x86_64-w64-mingw32/lib
-L/build/mingw/dest-x86_64/mingw/lib -isystem
/build/mingw/dest-x86_64/x86_64-w64-mingw32/include -isystem
/build/mingw/dest-x86_64/mingw/include
-B/build/mingw/dest-x86_64/x86_64-w64-mingw32/bin/
-B/build/mingw/dest-x86_64/x86_64-w64-mingw32/lib/ -isystem
/build/mingw/dest-x86_64/x86_64-w64-mingw32/include -isystem
/build/mingw/dest-x86_64/x86_64-w64-mingw32/sys-include -DHAVE_CONFIG_H -I.
-I../../../gcc-git/libgfortran -iquote../../../gcc-git/libgfortran/io
-I../../../gcc-git/libgfortran/../gcc
-I../../../gcc-git/libgfortran/../gcc/config
-I../../../gcc-git/libgfortran/../libquadmath -I../.././gcc
-I../../../gcc-git/libgfortran/../libgcc -I../libgcc
-I../../../gcc-git/libgfortran/../libbacktrace -I../libbacktrace
-I../libbacktrace -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules
-ffunction-sections -fdata-sections -g -O2 -MT bounds.lo -MD -MP -MF
.deps/bounds.Tpo -c ../../../gcc-git/libgfortran/runtime/bounds.c  -DDLL_EXPORT
-DPIC -o .libs/bounds.o
In file included from ../../../gcc-git/libgfortran/runtime/bounds.c:25:
../../../gcc-git/libgfortran/libgfortran.h:252:2: error: #error "GFC_INTEGER_4
should be available for the library to compile".
  252 | #error "GFC_INTEGER_4 should be available for the library to compile".
  |  ^
../../../gcc-git/libgfortran/libgfortran.h:267:9: error: unknown type name
'GFC_UINTEGER_4'
  267 | typedef GFC_UINTEGER_4 gfc_char4_t;
  | ^~
../../../gcc-git/libgfortran/libgfortran.h:358:31: error: unknown type name
'GFC_INTEGER_1'
  358 | typedef GFC_ARRAY_DESCRIPTOR (GFC_INTEGER_1) gfc_array_i1;
  |   ^
../../../gcc-git/libgfortran/libgfortran.h:348:3: note: in definition of macro
'GFC_ARRAY_DESCRIPTOR'
  348 |   type *base_addr;\
  |   ^~~~
../../../gcc-git/libgfortran/libgfortran.h:359:31: error: unknown type name
'GFC_INTEGER_2'
  359 | typedef GFC_ARRAY_DESCRIPTOR (GFC_INTEGER_2) gfc_array_i2;
  |   ^
../../../gcc-git/libgfortran/libgfortran.h:348:3: note: in definition of macro

[Bug c++/15882] Check for return type of overloaded operator new too early

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

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

--- Comment #14 from Andrew Pinski  ---
clang gives:
:15:1: error: 'operator new' cannot have a dependent return type; use
'void *' instead

[Bug middle-end/103537] Using -fstack-protector-strong "without" optimization cause segmentation fault

[hedayat.fwd at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Hedayat Vatankhah  ---
An interesting part of the problem is that following calls:
sc2.CallSamplePrivate();
sc2.CallOverloadedPrivate(4);
sc2.CallOverloadedPrivate(4.0f);

both before and after using MakeFake<>() calls, and the MakeFake<>() calls
themselves, which are the things which actually use the PMF related code you
mentioned, are working completely fine if the XXX::Call() calls are not there
or doesn't crash; but those XXX::Call() functions which are expected to only
use the address of wrapped function, which is handled by the linker not my
code, are crashing. While something like sc2.CallSamplePrivate(), which is also
calling my wrapped functions, is working fine. 

So, while it has something to do with what I do, it is weird and doesn't look
like a simple PMF conversion error or something.

[Bug sanitizer/82802] Potential UBSAN error with pointer difference (32-bits mode)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Fixed for GCC 8.

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

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

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

Bug 49730 Summary: loop not vectorized if inside another loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49730

   What|Removed |Added

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

[Bug tree-optimization/49730] loop not vectorized if inside another loop

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |8.0
 Resolution|--- |FIXED
  Known to work||8.1.0, 9.1.0
 Status|NEW |RESOLVED

--- Comment #3 from Andrew Pinski  ---
Fixed in GCC 8.

[Bug middle-end/103537] Using -fstack-protector-strong "without" optimization cause segmentation fault

[hedayat.fwd at gmail dot com via Gcc-bugs]

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

Hedayat Vatankhah  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #6 from Hedayat Vatankhah  ---
About the unify_pmf and reinterpret_cast(func_ptr) parts you mentioned,
I will re-investigate them too. However, they are already working as intended
for non-private methods, so I guess they should be fine. unify_pmf only removes
extra qualifiers from the type of the PMF, and the void * cast is based on
"Extracting the Function Pointer from a Bound Pointer to Member Function"
extension of GCC. And the result is only used as a std::map key, and never
dereferenced there. But, it can cause duplicates if there is a problem with it.
I'll see. 

Now, I'm also getting the feeling that something is wrong with my code
actually, so I close this for now. Sorry for bothering you, and thanks for your
answers.

[Bug middle-end/103537] Using -fstack-protector-strong "without" optimization cause segmentation fault

[hedayat.fwd at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Hedayat Vatankhah  ---
Oops, maybe I'm wrong. I forgot that I've also wrapped
SampleClass::SamplePrivate, so let me investigate further. Sorry for the
inconvenience.

[Bug middle-end/103537] Using -fstack-protector-strong "without" optimization cause segmentation fault

[hedayat.fwd at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hedayat Vatankhah  ---
Well, sorry if I should gave more logs to make it more clear.

Note that the crash happens here:
https://github.com/hedayat/powerfake/blob/a4c80d6628816656796d2e85b4422218da05ce00/powerfake.h#L257

And the problematic code doesn't use any of the parts of the code you
mentioned. 

To make the scope of the problem much less, I replaced main() function as
follows and commented out all other unrelated code:

int main()
{
SampleClass2 sc2;
SamplePrivate::Call(sc2);
}

This code certainly doesn't use any of the code you mentioned. It only uses
TAG_PRIVATE_MEMBER macro, which in turn uses TagBase and
PrivateFunctionExtractor structs, and no other code. 

The behavior is as follows:

* without -fstack-protector-strong, with or without any of the sanitize options
the code runs normally. No crash, and not any messages from any of the
sanitizers.

* with -fstack-protector-strong, with or without -fsanitize=undefined, you got
a segmentation fault. Logs when running with -fsanitize=undefined:

/home/hedayat/Projects/powerfake/powerfake.h:257:40: runtime error: load of
misaligned address 0x7f64004083fc for type ' *', which requires 8 byte
alignment
0x7f64004083fc: note: pointer points here

zsh: segmentation fault (core dumped)  ./sample/samples

* with -fstack-protector-strong and with -fsanitize=address, you don't get a
crash, so -fsanitizer=address somehow fixes the problem caused with
-fstack-protector-strong. (Using address sanitizer only causes a crash when I
use OverloadedPrivateFloat::Call(sc2, 5);, which I will investigate. But that
issue seems completely unrelated to this bug. address sanitizer causes a crash
with that function even when -fstack-protector-strong is not used).

[Bug tree-optimization/103542] [10/11/12 Regregression] bogus -Warray-bounds while index is limited by switch/case

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

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Blocks||56456
 CC||msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor  ---
The IL for the function is below.  It seems quite inefficient compared to GCC
9.

void get_default_config.part.0 (const uint32_t id)
{
  uint32_t error;
  uint32_t entry;
  unsigned int _4;
  uint32_t * _5;

   [local count: 118111600]:
  goto ; [100.00%]

   [local count: 955630225]:
  entry_2 = entry_1 + 1;

   [local count: 1073741824]:
  # entry_1 = PHI 
  _4 = config[id_3(D)].num_apples;
  if (entry_1 < _4)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 118111600]:
  config[id_3(D)].num_apples = 0;
  _5 = [id_3(D)].num_lemons;
  switch (id_3(D))  [20.00%], case 0:  [20.00%], case 1: 
[20.00%], case 2:  [20.00%], case 3:  [20.00%]>

   [local count: 23622320]:
:
  MEM  [(uint32_t *)][0].num_lemons = 0;
  goto ; [100.00%]

   [local count: 23622320]:
:
  MEM  [(uint32_t *)][1].num_lemons = 0;
  goto ; [100.00%]

   [local count: 23622320]:
:
  MEM  [(uint32_t *)][2].num_lemons = 0;
  goto ; [100.00%]

   [local count: 23622320]:
:
  MEM  [(uint32_t *)][3].num_lemons = 0;
  goto ; [100.00%]

   [local count: 23622320]:
:
  MEM  [(uint32_t *)][id_3(D)].num_lemons = 0;  
<<< -Warray-bounds

   [local count: 118111602]:
  # error_14 = PHI <0(7), 255(10), 0(6), 0(9), 0(8)>
  config[id_3(D)].num_lemons = 0;
  config[id_3(D)].lemons = 0B;
  foo (0);
  return;

}

In GCC 9 both the function and the final assembly are much more compact:

et_default_config.part.0 (const uint32_t id)
{
  struct fruit_config[4] * _2;
  sizetype _13;
  sizetype _14;

   [local count: 118111601]:
  _13 = (sizetype) id_3(D);
  _14 = _13 * 16;
  _2 =  + _14;
  MEM[(unsigned int *)_2] = 0;
  config[id_3(D)].lemons = 0B;
  foo (0); [tail call]
  return;

}


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

[Bug target/103554] -mavx generates worse code on scalar code

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

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

--- Comment #1 from Andrew Pinski  ---
This is SLP happening, I thought I have seen this issue before.

[Bug fortran/102787] ICE in new test case gfortran.dg/reshape_shape_2.f90

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

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

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

https://gcc.gnu.org/g:217d8bf22b148ebe52456a4bccfe9d725e7c68e9

commit r11-9359-g217d8bf22b148ebe52456a4bccfe9d725e7c68e9
Author: Harald Anlauf 
Date:   Sat Nov 27 21:43:52 2021 +0100

Fortran: improve expansion of constant array expressions within
constructors

gcc/fortran/ChangeLog:

PR fortran/102787
* array.c (expand_constructor): When encountering a constant array
expression or array section within a constructor, simplify it to
enable better expansion.

gcc/testsuite/ChangeLog:

* gfortran.dg/array_constructor_54.f90: New test.

(cherry picked from commit 6b8ecbc6d6652d061d7c72c64352d51eca2df6ca)

[Bug fortran/102717] ICE in gfc_simplify_reshape, at fortran/simplify.c:6843

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

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

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

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

commit r11-9358-g6fa3c73e88ccbb6fffb4169bcab830fc3f4f3c9a
Author: Harald Anlauf 
Date:   Thu Oct 14 20:19:50 2021 +0200

Fortran: generate error message for negative elements in SHAPE array

gcc/fortran/ChangeLog:

PR fortran/102717
* simplify.c (gfc_simplify_reshape): Replace assert by error
message for negative elements in SHAPE array.

gcc/testsuite/ChangeLog:

PR fortran/102717
* gfortran.dg/reshape_shape_2.f90: New test.

(cherry picked from commit b47490c572c5938f887b54240af6096a7c90f640)

[Bug c++/103555] out-of-line definition of class template method fails in the presence of type named the same as template argument

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

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

--- Comment #3 from Andrew Pinski  ---
DR 1200 seems like in this area.
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1200

But there is a still an open defect report which mentions searching base
classes before template parameters even.
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#459

So maybe it is related to that.

[Bug c++/103555] out-of-line definition of class template method fails in the presence of type named the same as template argument

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

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

--- Comment #2 from Andrew Pinski  ---
Both ICC and MSVC reject it in the same way GCC rejects it so I am 99% sure
that there is either a defect report against the C++ standard or 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1787r6.html
changes the way some names are found here.

[Bug fortran/103411] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6377

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

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

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

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

commit r11-9357-g9d7add04d97cf7ac8e20cc8645c3c4173697d4ca
Author: Harald Anlauf 
Date:   Fri Nov 26 21:00:35 2021 +0100

Fortran: improve check of arguments to the RESHAPE intrinsic

gcc/fortran/ChangeLog:

PR fortran/103411
* check.c (gfc_check_reshape): Improve check of size of source
array for the RESHAPE intrinsic against the given shape when pad
is not given, and shape is a parameter.  Try other simplifications
of shape.

gcc/testsuite/ChangeLog:

PR fortran/103411
* gfortran.dg/pr68153.f90: Adjust test to improved check.
* gfortran.dg/reshape_7.f90: Likewise.
* gfortran.dg/reshape_9.f90: New test.

(cherry picked from commit 4d540c7a4a7fb87b04d06e1ee7f9b004116279a4)

[Bug c++/103555] out-of-line definition of class template method fails in the presence of type named the same as template argument

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

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

--- Comment #1 from Andrew Pinski  ---
My bet is http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1787r6.html
describes the problem and the solution to the issue here.

[Bug target/103463] [12 Regression] ICE: in ix86_attr_length_immediate_default, at config/i386/i386.c:16686 with -Os -fno-tree-dominator-opts -fno-tree-vrp

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||slyfox at gcc dot gnu.org

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

[Bug target/103557] [12 regression] ICE on tpm2-tss-3.0.3: during RTL pass: sched2: SIGSEGV in memory_operand()

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
A dup of bug 103463.

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

[Bug fortran/103473] [11/12 Regression] ICE in simplify_minmaxloc_nodim, at fortran/simplify.c:5287

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Fixed on mainline and 11-branch.  Closing.

Thanks for the report!

[Bug tree-optimization/103559] Can't optimize away < 0 check on sqrt

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization

[Bug c++/82270] incorrect warning [-Wignored-attributes]

[paul.groke at dynatrace dot com via Gcc-bugs]

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

Paul Groke  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|DUPLICATE   |---

--- Comment #4 from Paul Groke  ---
This is not the same as bug 97222.

Bug 97222 is about losing attributes that were introduced by a typedef. This
bug is about getting a bogus warning which says that this happened when:
- The attribute is attached directly to a struct
- The a typedef resolving to the struct is then used as a template argument
- Compiling for SPARC
- The attribute isn't really lost

In what is described in bug 97222 OTOH, the attribute is really lost, because
it was introduced by a typedef and not directly attached to a struct as in this
case.

[Bug tree-optimization/103559] Can't optimize away < 0 check on sqrt

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

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

--- Comment #3 from Andrew Pinski  ---
Also with -fno-trapping-math GCC is able to remove if even for < case.

[Bug tree-optimization/103559] Can't optimize away < 0 check on sqrt

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

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

--- Comment #2 from Andrew Pinski  ---
Oh it is because you are using the wrong test.
Try:
if (isless (x, 0))
__builtin_unreachable();

And yes there is a difference.

[Bug fortran/103473] [11/12 Regression] ICE in simplify_minmaxloc_nodim, at fortran/simplify.c:5287

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

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

commit r11-9356-g3c1bcaa6224f79c6532dca28ebc7b466acbbc468
Author: Harald Anlauf 
Date:   Mon Nov 29 22:56:30 2021 +0100

Fortran: error recovery when simplifying MINLOC/MAXLOC

gcc/fortran/ChangeLog:

PR fortran/103473
* simplify.c (simplify_minmaxloc_nodim): Avoid NULL pointer
dereference when shape is not set.

gcc/testsuite/ChangeLog:

PR fortran/103473
* gfortran.dg/minmaxloc_15.f90: New test.

(cherry picked from commit 36421e76a7150621f2a5c7060ddd3f80aa825a40)

[Bug fortran/103505] ICE in compare_bound_mpz_t, at fortran/resolve.c:4587 since r8-7594-g078c5aff5ed83e9c

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

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

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

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

commit r11-9355-g9e9c674dfc6fae8f967341759699b4d75943d256
Author: Harald Anlauf 
Date:   Thu Dec 2 22:33:49 2021 +0100

Fortran: improve checking of array specifications

gcc/fortran/ChangeLog:

PR fortran/103505
* array.c (match_array_element_spec): Try to simplify array
element specifications to improve early checking.
* expr.c (gfc_try_simplify_expr): New.  Try simplification of an
expression via gfc_simplify_expr.  When an error occurs, roll
back.
* gfortran.h (gfc_try_simplify_expr): Declare it.

gcc/testsuite/ChangeLog:

PR fortran/103505
* gfortran.dg/pr103505.f90: New test.

Co-authored-by: Steven G. Kargl 
(cherry picked from commit f46d32dd29b7623915e31b0508e2e925526fa7d8)

[Bug fortran/103283] ICE in gfc_trans_array_constructor_subarray, at fortran/trans-array.c:1972

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

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
I did get some progress with the attempt:

diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 87089321a3b..d5bbcd493b6 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -1929,6 +1929,8 @@ simplify_const_ref (gfc_expr *p)
/* Fall through.  */

case AR_FULL:
+ if (p->ref->next == NULL)
+   return true;
  if (p->ref->next != NULL
  && (p->ts.type == BT_CHARACTER || gfc_bt_struct
(p->ts.type)))
{

which fixes testcase z1.f90 as well as comment#3, but has a lot of regressions
in the testsuite.

But then I have to admit I do not understand that function well enough to fix
it.

[Bug d/103558] perf_event.d:2076:32: error: module 'bitmanip' is in file 'std/bitmanip.d' which cannot be read

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #1 from Iain Buclaw  ---
Fix is already in upstream, just needs to be merged in.

https://github.com/dlang/druntime/pull/3620

[Bug tree-optimization/103559] Can't optimize away < 0 check on sqrt

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

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

--- Comment #1 from Andrew Pinski  ---
I think there is another bug about this. Basically right now there is no jump
threading done for float comparisons nor any kind of VRP for them either.

[Bug tree-optimization/103559] New: Can't optimize away < 0 check on sqrt

[llvm at rifkin dot dev via Gcc-bugs]

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

Bug ID: 103559
   Summary: Can't optimize away < 0 check on sqrt
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: llvm at rifkin dot dev
  Target Milestone: ---

For a simple invocation of sqrt, gcc inserts a < 0 check to set math errno if
needed. E.g.

float f(float x) {
return sqrt(x);
}

Is generated as

f(float):
vxorps  xmm1, xmm1, xmm1
vucomissxmm1, xmm0
ja  .L10
vsqrtss xmm0, xmm0, xmm0
ret
.L10:
jmp sqrtf


Unfortunately, this check is still present when the GCC is able to prove that x
is non-negative:

float f(float x) {
if(x < 0) [[unlikely]] {
__builtin_unreachable();
} else {
return sqrt(x);
}
}

LLVM suffers from the same problem, even with __builtin_assume().
https://godbolt.org/z/ddcoMj3oz

This is a very common pattern, and I'd imagine the argument for sqrt is often
able to be shown to be positive. This would be a helpful enhancement.

[Bug c++/93614] C++ compile error with struct in template class and < operator

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
Done.

[Bug c++/93614] C++ compile error with struct in template class and < operator

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

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

--- Comment #6 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:066b3258bb1494cf3b49b6ac26da38be01f7ad8e

commit r12-5794-g066b3258bb1494cf3b49b6ac26da38be01f7ad8e
Author: Marek Polacek 
Date:   Sat Dec 4 15:29:18 2021 -0500

c++: Add fixed test [PR93614]

This was fixed by r11-86.

PR c++/93614

gcc/testsuite/ChangeLog:

* g++.dg/template/lookup18.C: New test.

[Bug target/103557] [12 regression] ICE on tpm2-tss-3.0.3: during RTL pass: sched2: SIGSEGV in memory_operand()

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

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

--- Comment #1 from Andrew Pinski  ---
There is a dup of this bug and it might already be fixed.

[Bug target/103557] [12 regression] ICE on tpm2-tss-3.0.3: during RTL pass: sched2: SIGSEGV in memory_operand()

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |12.0

[Bug c++/92211] Lamdas in unevaluated context bug

[nsajko at gmail dot com via Gcc-bugs]

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

Neven Sajko  changed:

   What|Removed |Added

 CC||nsajko at gmail dot com

--- Comment #1 from Neven Sajko  ---
I'm hitting what seems like it may be the same bug on GCC 11.1.0.

Self contained minimal or nearly minimal reproducer below. Works fine with
Clang. GCC reports no error, but the code is miscompiled (returns 3 instead of
11).
Additionally, ubsan reports: "t.cc:15:6: runtime error: execution reached the
end of a value-returning function without returning a value".
Additionally, GCC gives this bogus warning during compilation: "t.cc:15:12:
warning: parameter ‘m’ set but not used [-Wunused-but-set-parameter]".


namespace {

template
auto f(int m) -> long {
int a{2};
return Func{}(a) - m;
}

template
using Fun = decltype([](int a) -> int {
return a * n;
});

template
auto g(int m) -> long {
return f>(m);
}

}  // namespace

auto main() -> int {
int m{3};
return g<7>(m);
}

[Bug d/103558] New: perf_event.d:2076:32: error: module 'bitmanip' is in file 'std/bitmanip.d' which cannot be read

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

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

Bug ID: 103558
   Summary: perf_event.d:2076:32: error: module 'bitmanip' is in
file 'std/bitmanip.d' which cannot be read
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa*-*-linux*
Target: hppa*-*-linux*
 Build: hppa*-*-linux*

/bin/bash ../libtool --tag=D   --mode=compile /
home/dave/gnu/gcc/objdir/./gcc/gdc -B/home/dave/gnu/gcc/objdir/./gcc/
-B/home/da
ve/opt/gnu/gcc/gcc-12/hppa-linux-gnu/bin/
-B/home/dave/opt/gnu/gcc/gcc-12/hppa-l
inux-gnu/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-12/hppa-linux-gnu/include
-isy
stem /home/dave/opt/gnu/gcc/gcc-12/hppa-linux-gnu/sys-include   -fno-checking
-p
refer-pic -fversion=Shared -Wall  -frelease  -ffunction-sections
-fdata-sections
  -O2 -g  -fpreview=dip1000 -fpreview=fieldwise -fpreview=dtorfields -nostdinc
-
I ../../../../gcc/libphobos/libdruntime -I . -c -o core/sys/linux/perf_event.lo
../../../../gcc/libphobos/libdruntime/core/sys/linux/perf_event.d
libtool: compile:  /home/dave/gnu/gcc/objdir/./gcc/gdc
-B/home/dave/gnu/gcc/objd
ir/./gcc/ -B/home/dave/opt/gnu/gcc/gcc-12/hppa-linux-gnu/bin/
-B/home/dave/opt/g
nu/gcc/gcc-12/hppa-linux-gnu/lib/ -isystem
/home/dave/opt/gnu/gcc/gcc-12/hppa-li
nux-gnu/include -isystem
/home/dave/opt/gnu/gcc/gcc-12/hppa-linux-gnu/sys-includ
e -fno-checking -fversion=Shared -Wall -frelease -ffunction-sections
-fdata-sect
ions -O2 -g -fpreview=dip1000 -fpreview=fieldwise -fpreview=dtorfields
-nostdinc
 -I ../../../../gcc/libphobos/libdruntime -I . -c
../../../../gcc/libphobos/libd
runtime/core/sys/linux/perf_event.d  -fPIC -fversion=Shared -o
core/sys/linux/.l
ibs/perf_event.o
yes
../../../../gcc/libphobos/libdruntime/core/sys/linux/perf_event.d:2076:32:
error: module 'bitmanip' is in file 'std/bitmanip.d' which cannot be read
 2076 | import std.bitmanip : bitfields;
  |^
import path[0] = /home/dave/gnu/gcc/gcc-12/libphobos/libdruntime
import path[1] = /home/dave/gnu/gcc/objdir/hppa-linux-gnu/libphobos/libdruntime
make[5]: *** [Makefile:2472: core/sys/linux/perf_event.lo] Error 1

dave@mx3210:~/gnu/gcc/gcc$ find . -name bitmanip.d
./libphobos/src/std/bitmanip.d

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

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

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

Lewis Hyatt  changed:

   What|Removed |Added

 CC||lhyatt at gcc dot gnu.org

--- Comment #44 from Lewis Hyatt  ---
I have a patch for this submitted to the mailing list here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586191.html

Initially I tried resurrecting Manuel's patch from comment #10 and got it
working, however it led to other issues for C++. The problem is that, with that
change, the C++ frontend processes the pragmas too early, instead of too late;
it processes every #pragma GCC diagnostic in the file prior to handling any
tokens. This makes a large demand on the diagnostics infrastructure, namely
that it correctly handles every case of processing source lines and determining
which #pragmas are in effect at that time and which are for the future. This
infrastructure is in place and generally works, however it doesn't handle all
cases, notably a change to the argument of an option (say something like,
#pragma GCC diagnostic warning "-Wimplicit-fallthrough=4") is not tracked
properly (see also PR c/71603). The state of warning options is also often
queried directly by the frontend code, not making use of the diagnostics state
tracking facilities, and this also leads to warnings being generated or not
generated unexpectedly. So this patch leads to a lot of testcase failures, for
example, c-c++-common/Wshadow-1.c.

I think in the ideal case, it should be made to work correctly that all
diagnostic pragmas could be parsed prior to processing the tokens and
everything would work, but this seems like a large overhaul. I can try to
tackle improving that later, but for the purpose of resolving this PR, I
thought it was worth trying another approach, which is just to arrange that
every frontend does
indeed handle the #pragma when it needs to. My patch does things this way, it
adds the concept of an early pragma handler, which can be registered similar to
a normal one and runs in addition to it. The early handler for diagnostic
pragmas then filters for libcpp-generated diagnostics and processes those when
called. Then the C++ frontend, and gcc -E, are both modified to make use of it.
This asks much less of the state tracking, since only libcpp diagnostics are
handled early.

The C++ frontend changes are not too extensive, it basically notes when it sees
a CPP_PRAGMA_EOL token during initial parsing, and if so, it handles it
immediately. In order to reuse the existing handler for diagnostic pragmas, it
sets up the main lexer so that it is sufficiently prepared for pragma_lex() to
work, which is all that is needed.

For preprocessing mode, I needed to refactor the code for
handle_diagnostic_pragma a bit, since in preprocess-only mode, there is no C or
C++ parser available and the tokens need to be lexed directly from libcpp. I
also needed adjustments in c-ppoutput.c to make sure, as Manuel pointed out,
that we do still output the #pragma GCC diagnostic in the preprocessed output.

I hope this looks workable, happy to adjust the patch as needed.

[Bug c++/93614] C++ compile error with struct in template class and < operator

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2021-12-04
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

--- Comment #5 from Marek Polacek  ---
I'll add it.

[Bug target/103557] New: [12 regression] ICE on tpm2-tss-3.0.3: during RTL pass: sched2: SIGSEGV in memory_operand()

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

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

Bug ID: 103557
   Summary: [12 regression] ICE on tpm2-tss-3.0.3: during RTL
pass: sched2: SIGSEGV in memory_operand()
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Noticed as an ICE in tpm2-tss-3.0.3 against weekly gcc-12 snapshot. Here is th
extracted example:

$ cat a.c.c
// gcc-12.0.0 -O2  -c a.c.c -o a.o
struct {
  char sm3_256[32];
} TPMU_HA;
typedef struct {
  short size;
  char buffer[sizeof(TPMU_HA)];
} TPM2B_DIGEST;
typedef struct {
  TPM2B_DIGEST auths[3];
} TSS2L_SYS_AUTH_COMMAND;

void Tss2_Sys_Clear(TSS2L_SYS_AUTH_COMMAND);

void sysContext(void) {
  TPM2B_DIGEST nonce = {};
  TSS2L_SYS_AUTH_COMMAND sessionsDataIn = {{nonce}};
  Tss2_Sys_Clear(sessionsDataIn);
}


$ gcc-12.0.0 -O2  -c a.c.c -o a.o
during RTL pass: sched2
a.c.c: In function 'sysContext':
a.c.c:19:1: internal compiler error: Segmentation fault
   19 | }
  | ^
0x1e22687 internal_error(char const*, ...)
???:0
0xe7e43c memory_operand(rtx_def*, machine_mode)
???:0
0x167e598 get_attr_memory(rtx_insn*)
???:0
0x19a4bc0 insn_default_latency_generic(rtx_insn*)
???:0
0x1c74ad3 insn_sched_cost(rtx_insn*)
???:0
0x1c77934 dep_cost_1(_dep*, unsigned int)
???:0
0x1c79d7f set_priorities(rtx_insn*, rtx_insn*)
???:0
0xec28e2 compute_priorities()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ gcc-12.0.0 -v
Using built-in specs.
COLLECT_GCC=/nix/store/gqvmd777r63c5nvbrfwcgdlam0krmv4l-gcc-12.0.0/bin/gcc
COLLECT_LTO_WRAPPER=/nix/store/gqvmd777r63c5nvbrfwcgdlam0krmv4l-gcc-12.0.0/libexec/gcc/x86_64-unknown-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211128 (experimental) (GCC)

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

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

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

Bug ID: 103556
   Summary: [12 regression] rop test cases start failing after
r12-5780
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:d81722ee16e339af7c11b3d1bf51c17246557595, r12-5780
make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
powerpc.exp=gcc.target/powerpc/rop-1.c"
FAIL: gcc.target/powerpc/rop-1.c (test for excess errors)
FAIL: gcc.target/powerpc/rop-1.c (test for excess errors)
# of unexpected failures1
# of unexpected failures1
# of unexpected failures2

This was on a power 8 BE machine and fails for both 32 and 64 bit.  There were
others:

FAIL: gcc.target/powerpc/rop-1.c (test for excess errors)
FAIL: gcc.target/powerpc/rop-1.c (test for excess errors)
FAIL: gcc.target/powerpc/rop-2.c (test for excess errors)
FAIL: gcc.target/powerpc/rop-2.c (test for excess errors)
FAIL: gcc.target/powerpc/rop-4.c (test for excess errors)
FAIL: gcc.target/powerpc/rop-4.c (test for excess errors)
FAIL: gcc.target/powerpc/rop-5.c (test for excess errors)
FAIL: gcc.target/powerpc/rop-5.c (test for excess errors)
UNRESOLVED: gcc.target/powerpc/rop-1.c scan-assembler-times mhashchkM 1
UNRESOLVED: gcc.target/powerpc/rop-1.c scan-assembler-times mhashchkM 1
UNRESOLVED: gcc.target/powerpc/rop-1.c scan-assembler-times mhashstM 1
UNRESOLVED: gcc.target/powerpc/rop-1.c scan-assembler-times mhashstM 1
UNRESOLVED: gcc.target/powerpc/rop-2.c scan-assembler-times mhashchkpM
1
UNRESOLVED: gcc.target/powerpc/rop-2.c scan-assembler-times mhashchkpM
1
UNRESOLVED: gcc.target/powerpc/rop-2.c scan-assembler-times mhashstpM 1
UNRESOLVED: gcc.target/powerpc/rop-2.c scan-assembler-times mhashstpM 1
UNRESOLVED: gcc.target/powerpc/rop-4.c scan-assembler-not mhashchkM
UNRESOLVED: gcc.target/powerpc/rop-4.c scan-assembler-not mhashchkM
UNRESOLVED: gcc.target/powerpc/rop-4.c scan-assembler-not mhashstM
UNRESOLVED: gcc.target/powerpc/rop-4.c scan-assembler-not mhashstM



commit d81722ee16e339af7c11b3d1bf51c17246557595
Author: Peter Bergner 
Date:   Fri Dec 3 11:46:22 2021 -0600

rs6000: testsuite: Add rop_ok effective-target function

[Bug c++/103555] New: out-of-line definition of class template method fails in the presence of type named the same as template argument

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 103555
   Summary: out-of-line definition of class template method fails
in the presence of type named the same as template
argument
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

Following code fails to compile in GCC:
```
struct Outer {
struct MyClass {
template
void foo (SameName*);
};
struct SameName {}; //< this type breaks compilation in GCC
};

template
void Outer::MyClass::foo (SameName*) {}
```

Clang also rejected this code until version 11. Now it accepts it:
https://gcc.godbolt.org/z/s5jcjYTTK

This suggests that the code is valid (but hard for many compilers).

Related discussion: https://stackoverflow.com/q/41280133/7325599

[Bug c/83324] [feature request] Pragma or special syntax for guaranteed tail calls

[pietro.gcc at sociotechnical dot xyz via Gcc-bugs]

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

pietro  changed:

   What|Removed |Added

 CC||pietro.gcc at sociotechnical 
dot x
   ||yz

--- Comment #2 from pietro  ---
I created a plugin that lets you annotate a whole function as musttail:
https://github.com/pietro/gcc-musttail-plugin/

I think that in order to add an attribute to the return statement like clang
has done the parser for the C frontend needs to be modified.

[Bug c++/95009] [9/10/11/12 Regression] decltype of increment or decrement bitfield expressions are wrong and causes assembler errors.

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug libstdc++/103549] [12 regression] Uninitialized member warning from regex header

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

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

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

https://gcc.gnu.org/g:87710ec7b213245ecb194b778e97ae3a6790394f

commit r12-5792-g87710ec7b213245ecb194b778e97ae3a6790394f
Author: Jonathan Wakely 
Date:   Sat Dec 4 11:38:25 2021 +

libstdc++: Initialize member in std::match_results [PR103549]

This fixes a -Wuninitialized warning for std::cmatch m1, m2; m1=m2;

Also name the template parameters in the forward declaration, to get rid
of the  noise in diagnostics.

libstdc++-v3/ChangeLog:

PR libstdc++/103549
* include/bits/regex.h (match_results): Give names to template
parameters in first declaration.
(match_results::_M_begin): Add default member-initializer.

[Bug pch/71934] pch cannot be disabled so gcc cannot be position independent

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

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

--- Comment #17 from Jakub Jelinek  ---
Created attachment 51926
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51926=edit
gcc12-pr71934-reloc-wip.patch

Completely untested patch to perform PCH relocation.
Due to nested_ptr unfortunately the relocate_ptrs hook isn't always called with
the address of the pointer in the object so that we can remember at PCH save
time where the pointer is, so I had to add another argument to the hook.  In
the common case the new middle argument is NULL, which stands for the first
argument
is pointer into the object and that address should be remembered for possible
later relocation.  For the nested_ptr case the first argument is address of
some temporary pointer and the new middle argument is the pointer to the
pointer.
And the last case is for some weirdo case in tree-cfg where we call it even on
an unrelated address of LOCATION_BLOCK, it passes the same pointer to first and
second argument and the hook treats it as adjust, but don't actually remember
the address.
The relocations are then stored with what I've talked about, ushort diff from
last address if it fits, or 0 followed by size_t difference from the base.  In
a small PCH I've created for stdio.h there were ~ 56000 pointers that need
relocations in the image and I needed a single 0 entry at the start with the
size_t and all others fit into ushort.

The host pch_use_address hooks need to be adjusted so that they do support
mapping at a different address, only the Linux hook has been adjusted (and for
testing I've actually hardcoded there that it forces the relocation always).

[Bug target/103554] New: -mavx generates worse code on scalar code

[avi at scylladb dot com via Gcc-bugs]

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

Bug ID: 103554
   Summary: -mavx generates worse code on scalar code
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: avi at scylladb dot com
  Target Milestone: ---

Test case:

struct s1 {
long a, b, c, d, e, f, g, h;
};

s1 move(s1 in) {
s1 ret;

ret.a = in.d;
ret.b = in.e;
ret.c = in.a;
ret.d = in.b;
return ret;
}


-O3 generates:

move(s1):
  movq 8(%rsp), %xmm0
  movq 32(%rsp), %xmm1
  movq %rdi, %rax
  movhps 16(%rsp), %xmm0
  movhps 40(%rsp), %xmm1
  movups %xmm1, (%rdi)
  movups %xmm0, 16(%rdi)
  ret


-O3 -mavx generates:

move(s1):
pushq   %rbp
movq%rdi, %rax
movq%rsp, %rbp
vmovq   16(%rbp), %xmm2
vmovq   40(%rbp), %xmm3
vpinsrq $1, 24(%rbp), %xmm2, %xmm1
vpinsrq $1, 48(%rbp), %xmm3, %xmm0
vinsertf128 $0x1, %xmm1, %ymm0, %ymm0
vmovdqu %ymm0, (%rdi)
vzeroupper
popq%rbp
ret

Clang -O3 generates this simple code, with or without -mavx (-mavx does use VEX
instructions):

move(s1): # @move(s1)
  movq %rdi, %rax
  movups 32(%rsp), %xmm0
  movups %xmm0, (%rdi)
  movaps 8(%rsp), %xmm0
  movups %xmm0, 16(%rdi)
  retq

[Bug c++/84196] invalid call to a function template with a vector argument silently accepted

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||ppalka at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
This is rejected since r10-7622-g12f55e030ed068d5c7b14c65a74d102db925dab2
I guess we want the testcase into the testsuite in this case.

[Bug c++/93614] C++ compile error with struct in template class and < operator

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
This is accepted since r11-86-gef3479afc5ab415f00a53fc6f6a990df7f6a0747
Dunno if the PR94799 testcases cover everything we want for the testsuite or if
we want this testcase too.

[Bug c++/103553] Show what decltype deduced in static_assert

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

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

Marek Polacek  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/103553] New: Show what decltype deduced in static_assert

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

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

Bug ID: 103553
   Summary: Show what decltype deduced in static_assert
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

struct false_type { static constexpr bool value = false; };
struct true_type { static constexpr bool value = true; };
template
struct is_same : false_type {}; 
template
struct is_same : true_type {};

void
g ()
{
  int & = 42;
  static_assert (is_same::value, "");
}

yields

$ ./cc1plus -quiet w.C
w.C: In function ‘void g()’:
w.C:12:45: error: static assertion failed
   12 |   static_assert (is_same::value, "");
  |  ~~~^

It would be nice to see why though, show what type the decltype produced.

$ xclang++ -c w.C
w.C:12:3: error: static_assert failed due to requirement 'is_same::value' ""
  static_assert (is_same::value, "");
  ^  
1 error generated.

which is much better.

[Bug rtl-optimization/103550] 2 more instructions generated by gcc than clang

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #10 from cqwrteur  ---
(In reply to Roger Sayle from comment #9)
> Note adding -fno-tree-reassoc results in fewer instructions than clang.

maybe I am a little bit picky since I keep writing "portable assembly code"
with C++. I just frequently compare assembly generated by the compiler to
manually written assembly. However, I think that is how we got an improvement
on the GCC compiler since I do frequently find out suboptimal codegen with it.

The 21 instructions look really good. Do not know whether we can squeeze it
further.

Do not get me wrong. Actually, clang runs much slower for my sha512 in general
(since they generate much more instructions (around 10% more)). I just compare
GCC to openssl's manually written assembly (well it is actually generated by
perl script) and i feel it moves more registers.

[Bug c++/103552] Compile-time comparison of subobject and parent class

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||55004
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-12-04
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.
ICC also rejects this code with the following error message:
(7): note: pointer values cannot be compared because they do not point
into the same complete object or they point to subobjects with different
accessibility


Note MSVC "accepts" it (if you change < to <= so the static_assert is ok).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues

[Bug c++/59238] Dynamic allocating a list-initialized object of a type with private destructor fails.

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
Fixed.

[Bug c++/87066] new expression and potential destructor invokation

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|rejects-valid   |

--- Comment #4 from Andrew Pinski  ---
>new B{}; //error: use of deleted function ~B()
(which was rejected before) was fixed in GCC 11, see PR 59238.

The other two are still accepted so recording this PR just for that case only.

[Bug c++/103552] New: Compile-time comparison of subobject and parent class

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 103552
   Summary: Compile-time comparison of subobject and parent class
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

This program:
```
struct A{};
struct B : A { A a; };

int main() {
constexpr B b{};
static_assert( _cast(b) <  );
}
```
is accepted by GCC, but Clang rejects it with the error:
```
comparison of address of base class subobject 'A' of class 'B' to field 'a' has
unspecified value
```
Demo: https://gcc.godbolt.org/z/9G8szToPz

It looks like Clang is right here, and this indeed must be rejected.

[Bug c++/59238] Dynamic allocating a list-initialized object of a type with private destructor fails.

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||57082

--- Comment #7 from Andrew Pinski  ---
Note the accessibility case was handled in PR 57082 (that is comment #0).
The expanded case for deleted was handled here.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57082
[Bug 57082] brace initialization requires public destructor

[Bug c++/87066] new expression and potential destructor invokation

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

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

--- Comment #3 from Andrew Pinski  ---
Hmm, since GCC 11, the example in comment #0 is accepted.

[Bug c++/87275] unsequenced writes not diagnosed in constant expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-12-04
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #4 from Andrew Pinski  ---
Confirmed.

[Bug c++/102174] Unused result of undefined behavior arithmetic is accepted during constant evaluation

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-12-04
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug target/103269] Enable ZMM in MOVE_MAX and STORE_MAX_PIECES without -mprefer-vector-width=512

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

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from H.J. Lu  ---
Fixed for GCC 12.

[Bug c++/59795] [DR1837] Invalid use of "this" in a local class not diagnosed

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||98939
  Alias||cwg1837
Summary|Invalid use of "this" in a  |[DR1837] Invalid use of
   |local class not diagnosed   |"this" in a local class not
   ||diagnosed

--- Comment #1 from Andrew Pinski  ---
I actually think this is
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1837

Which means it has the following status:
[Accepted at the November, 2020 meeting as part of paper P1787R6 and moved to
DR at the February, 2021 meeting.]


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98939
[Bug 98939] [C++23] Implement P1787R6 "Declarations and where to find them"

[Bug c++/58184] Pointer to overloaded function is non-deduced context

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

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

--- Comment #3 from Andrew Pinski  ---
Note both ICC and MSVC accept the attached example.

[Bug rtl-optimization/103550] 2 more instructions generated by gcc than clang

[roger at nextmovesoftware dot com via Gcc-bugs]

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

--- Comment #9 from Roger Sayle  ---
Note adding -fno-tree-reassoc results in fewer instructions than clang.

[Bug c++/12567] [Core/253] g++ fails to recognize ill-formed-ness of initializers

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|SUSPENDED   |NEW

--- Comment #4 from Andrew Pinski  ---
[Adopted at the November, 2016 meeting as part of paper P0490R0.]

[Bug c++/57] [DR 325] GCC can't parse a non-parenthesized comma in a template-id within a default argument

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

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

--- Comment #49 from Andrew Pinski  ---
(In reply to Jonathan Wakely from comment #48)
> No, as previously stated, it's suspended until the Core issue is resolved
> and the standard is changed.
> 
> https://wg21.link/cwg325


Some news on that front too:
Additional note (November, 2020):

Paper P1787R6, adopted at the November, 2020 meeting, partially addresses this
issue.

[Bug c++/98939] [C++23] Implement P1787R6 "Declarations and where to find them"

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

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

Bug 12228 Summary: [DR 244/399] syntax error calling a qualified template dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12228

   What|Removed |Added

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

[Bug c++/94404] [meta-bug] C++ core issues

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

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

Bug 12228 Summary: [DR 244/399] syntax error calling a qualified template dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12228

   What|Removed |Added

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

[Bug c++/12228] [DR 244/399] syntax error calling a qualified template dtor

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Pinski  ---
(In reply to S. Davis Herring from comment #6)
> CWG399 was resolved by P1787R6
> .  All
> of these definitions of foo are valid, although BT and CA will be found
> during instantiation only if the template arguments provide them as members.

Fixed on the trunk by r12-3643-g18b57c1d4a8777bedf which implements part of
this paper.

[Bug rtl-optimization/103550] 2 more instructions generated by gcc than clang

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #8 from Roger Sayle  ---
I think this is a reassociation problem (rather than a register allocation
issue).
On x86-like machines, it's better to evaluate "*mem + op" as tmp=op; tmp +=
*mem";  taking advantage of the available addressing modes, than as "tmp =
*mem; tmp2 = op;  tmp += tmp2".

This is demonstrated by the following simplified (and over-simplified) test
case:
inline unsigned long s0(unsigned long x) {
  return (x>>8) | (x<<56);
}

void foo(unsigned long *x) {
  x[0] += s0(x[1]) + x[9];
}

void bar(unsigned long *x) {
  x[0] += s0(x[1]) + s0(x[14]) + x[9];
}

In the over-simplified foo, GCC generates optimal code, performing the
computation (rotation) first, then adding from memory, and finally adding to
memory.

foo:movq8(%rdi), %rax
rorq$8, %rax
addq72(%rdi), %rax
addq%rax, (%rdi)
ret

which is much better than the (hypothetical) reverse order, which requires
more instructions (the extra moves observed by cqwrteur) and extra registers.

badfoo: movq(%rdi), %rax
addq72(%rdi), %rax
movq8(%rdi), %rdx
rorq$8, %rdx
addq%rdx, %rax
movq%rax, (%rdi)
ret

Alas, this is exactly what happens for more complex cases, like bar above.
With is currently compiled by mainline GCC to:

bar:movq8(%rdi), %rdx
movq(%rdi), %rax
addq72(%rdi), %rax
rorq$8, %rdx
addq%rdx, %rax
movq112(%rdi), %rdx
rorq$8, %rdx
addq%rdx, %rax
movq%rax, (%rdi)
ret

The issue appears in the tree-ssa optimizers.  The .t006.gimple for bar
initially has the additions of memory last:

void bar (long unsigned int * x)
{
  long unsigned int D.1990;

  _1 = x + 8;
  _2 = *_1;
  _3 = s0 (_2);
  _4 = x + 112;
  _5 = *_4;
  _6 = s0 (_5);
  _7 = _3 + _6;
  _8 = x + 72;
  _9 = *_8;
  D.1990 = _7 + _9;
  _10 = *x;
  _11 = D.1990 + _10;
  *x = _11;
}

but by the time the tree-ssa optimizers have finished with it, the reads from
memory have been reassociated to the front, so 250t.optimized contains:

void bar (long unsigned int * x)
{
  long unsigned int _1;
  long unsigned int _2;
  long unsigned int _4;
  long unsigned int _5;
  long unsigned int _6;
  long unsigned int _9;
  long unsigned int _10;
  long unsigned int _13;
  long unsigned int _14;

   [local count: 1073741824]:
  _1 = MEM[(long unsigned int *)x_7(D) + 8B];
  _9 = _1 r>> 8;
  _2 = MEM[(long unsigned int *)x_7(D) + 112B];
  _10 = _2 r>> 8;
  _4 = MEM[(long unsigned int *)x_7(D) + 72B];
  _5 = *x_7(D);
  _13 = _4 + _5;
  _14 = _9 + _13;
  _6 = _10 + _14;
  *x_7(D) = _6;
  return;
}

Notice the first addition, _4 + _5 mentions two memory references, rather than
the computations _9 or _10. I believe that a suitable heuristic is that when
reassociating, memory references should come last, or at least not first.
Hence (mem1 + mem2 + op3 + mem4 + op5) should reassociate as (op3 + op5 + mem1
+ mem2 + mem4).  And ideally, any destination memory should appear last, so
mem2 = (mem1 + mem2 + op3 + mem4 + op5) should be reassociated as mem2 = (op3 +
op5 + mem1 + mem4 + mem2).

I suspect the intent of moving memory references "early" is perhaps to reduce
memory latency, so perhaps the ideal compromise/hybrid is to reassociate a
computation first, then memory accesses as early as possible, and finally the
destination memory last, i.e. mem2 = (op3 + mem1 + mem4 + op5 + mem2).

[Bug c++/13590] [DR39] Non-existing ambiguity when inheriting through virtuals two identical using declarations.

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

[Bug c++/91768] gcc try to resolve member of dependent type too soon

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
g++.dg/cpp23/lookup2.C is basically this example.
So this was fixed on purpose.

[Bug preprocessor/102432] [11/12 Regression] ICE in _cpp_lex_direct with function like macro without arguments within "pragma omp" statement

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug preprocessor/102432] [11/12 Regression] ICE in _cpp_lex_direct with function like macro without arguments within "pragma omp" statement

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

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

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

https://gcc.gnu.org/g:2fdef526a3a8cb4a6f89852979c7ca6437b994f3

commit r11-9354-g2fdef526a3a8cb4a6f89852979c7ca6437b994f3
Author: Jakub Jelinek 
Date:   Sat Dec 4 11:00:09 2021 +0100

libcpp: Fix up handling of deferred pragmas [PR102432]

The https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557903.html
change broke the following testcases.  The problem is when a pragma
namespace allows expansion (i.e. p->is_nspace && p->allow_expansion),
e.g. the omp or acc namespaces do, then when parsing the second pragma
token we do it with pfile->state.in_directive set,
pfile->state.prevent_expansion clear and pfile->state.in_deferred_pragma
clear (the last one because we don't know yet if it will be a deferred
pragma or not).  If the pragma line only contains a single name
and newline after it, and there exists a function-like macro with the
same name, the preprocessor needs to peek in funlike_invocation_p
the next token whether it isn't ( but in this case it will see a newline.
As pfile->state.in_directive is set, we don't read anything after the
newline, pfile->buffer->need_line is set and CPP_EOF is lexed, which
funlike_invocation_p doesn't push back.  Because name is a function-like
macro and on the pragma line there is no ( after the name, it isn't
expanded, and control flow returns to do_pragma.  If name is valid
deferred pragma, we set pfile->state.in_deferred_pragma (and really
need it set so that e.g. end_directive later on doesn't eat all the
tokens from the pragma line).

Before Nathan's change (which unfortunately didn't contain rationale
on why it is better to do it like that), this wasn't a problem,
next _cpp_lex_direct called when we want next token would return
CPP_PRAGMA_EOF when it saw buffer->need_line, which would turn off
pfile->state.in_deferred_pragma and following get token would already
read the next line.  But Nathan's patch replaced it with an assertion
failure that now triggers and CPP_PRAGMA_EOL is done only when lexing
the '\n'.  Except for this special case that works fine, but in
this case it doesn't because when peeking the token we still didn't know
that it will be a deferred pragma.
I've tried to fix that up in do_pragma by detecting this and pushing
CPP_PRAGMA_EOL as lookahead, but that doesn't work because end_directive
still needs to see pfile->state.in_deferred_pragma set.

So, this patch affectively reverts part of Nathan's change, CPP_PRAGMA_EOL
addition isn't done only when parsing the '\n', but is now done in both
places, in the first one instead of the assertion failure.

2021-12-04  Jakub Jelinek  

PR preprocessor/102432
* lex.c (_cpp_lex_direct): If buffer->need_line while
pfile->state.in_deferred_pragma, return CPP_PRAGMA_EOL token
instead
of assertion failure.

* c-c++-common/gomp/pr102432.c: New test.
* c-c++-common/goacc/pr102432.c: New test.

(cherry picked from commit 55dfce4d5cb4a366ced7e1194a1c7f04389e3087)

[Bug preprocessor/102432] [11/12 Regression] ICE in _cpp_lex_direct with function like macro without arguments within "pragma omp" statement

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

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

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

https://gcc.gnu.org/g:55dfce4d5cb4a366ced7e1194a1c7f04389e3087

commit r12-5788-g55dfce4d5cb4a366ced7e1194a1c7f04389e3087
Author: Jakub Jelinek 
Date:   Sat Dec 4 11:00:09 2021 +0100

libcpp: Fix up handling of deferred pragmas [PR102432]

The https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557903.html
change broke the following testcases.  The problem is when a pragma
namespace allows expansion (i.e. p->is_nspace && p->allow_expansion),
e.g. the omp or acc namespaces do, then when parsing the second pragma
token we do it with pfile->state.in_directive set,
pfile->state.prevent_expansion clear and pfile->state.in_deferred_pragma
clear (the last one because we don't know yet if it will be a deferred
pragma or not).  If the pragma line only contains a single name
and newline after it, and there exists a function-like macro with the
same name, the preprocessor needs to peek in funlike_invocation_p
the next token whether it isn't ( but in this case it will see a newline.
As pfile->state.in_directive is set, we don't read anything after the
newline, pfile->buffer->need_line is set and CPP_EOF is lexed, which
funlike_invocation_p doesn't push back.  Because name is a function-like
macro and on the pragma line there is no ( after the name, it isn't
expanded, and control flow returns to do_pragma.  If name is valid
deferred pragma, we set pfile->state.in_deferred_pragma (and really
need it set so that e.g. end_directive later on doesn't eat all the
tokens from the pragma line).

Before Nathan's change (which unfortunately didn't contain rationale
on why it is better to do it like that), this wasn't a problem,
next _cpp_lex_direct called when we want next token would return
CPP_PRAGMA_EOF when it saw buffer->need_line, which would turn off
pfile->state.in_deferred_pragma and following get token would already
read the next line.  But Nathan's patch replaced it with an assertion
failure that now triggers and CPP_PRAGMA_EOL is done only when lexing
the '\n'.  Except for this special case that works fine, but in
this case it doesn't because when peeking the token we still didn't know
that it will be a deferred pragma.
I've tried to fix that up in do_pragma by detecting this and pushing
CPP_PRAGMA_EOL as lookahead, but that doesn't work because end_directive
still needs to see pfile->state.in_deferred_pragma set.

So, this patch affectively reverts part of Nathan's change, CPP_PRAGMA_EOL
addition isn't done only when parsing the '\n', but is now done in both
places, in the first one instead of the assertion failure.

2021-12-04  Jakub Jelinek  

PR preprocessor/102432
* lex.c (_cpp_lex_direct): If buffer->need_line while
pfile->state.in_deferred_pragma, return CPP_PRAGMA_EOL token
instead
of assertion failure.

* c-c++-common/gomp/pr102432.c: New test.
* c-c++-common/goacc/pr102432.c: New test.

[Bug c++/81609] incompatible extern C declarations of the same extern function at local scope accepted

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |11.0

--- Comment #6 from Andrew Pinski  ---
Fixed.

[Bug tree-optimization/103551] [12 Regression] wrong code with -O1 -fno-tree-dominator-opts -ftree-vectorize -ftree-vrp

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-12-04
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
VRP2 is check in BB3:
;;   basic block 3, loop depth 0, count 105119324 (estimated locally), maybe
hot
;;prev block 2, next block 4, flags: (NEW, VISITED)
;;pred:   2 [89.0% (guessed)]  count:105119324 (estimated locally)
(TRUE_VALUE,EXECUTABLE)
  _35 = offset_13(D) + 65535;
  if (_35 <= 6)
goto ; [10.00%]
  else
goto ; [90.00%]
;;succ:   4 [90.0% (guessed)]  count:94607391 (estimated locally)
(FALSE_VALUE,EXECUTABLE)
;;9 [10.0% (guessed)]  count:10511933 (estimated locally)
(TRUE_VALUE)

Folding statement: _35 = offset_13(D) + 65535;
 Registering value_relation (_35 < offset_13(D)) (bb3) at _35 = offset_13(D) +
65535;
Not folded
Folding statement: if (_35 <= 6)

Visiting conditional with predicate: if (_35 <= 6)

With known ranges
_35: short unsigned int [0, 65534]

Predicate evaluates to: DON'T KNOW
Folded into: if (0 != 0)

[Bug tree-optimization/103551] [12 Regression] wrong code with -O1 -fno-tree-dominator-opts -ftree-vectorize -ftree-vrp

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug c++/32042] linkage confused with scope?

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Fixed.

[Bug c++/91075] Wrong code generated for static variable with local redeclaration

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> Seems fixed in GCC 11+.

Most likely r11-3699.

[Bug tree-optimization/103551] New: [12 Regression] wrong code with -O1 -fno-tree-dominator-opts -ftree-vectorize -ftree-vrp

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 103551
   Summary: [12 Regression] wrong code with -O1
-fno-tree-dominator-opts -ftree-vectorize -ftree-vrp
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 51925
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51925=edit
reduced testcase (from OpenTTD sources)

Output:
$ x86_64-pc-linux-gnu-g++ -O1 -fno-tree-dominator-opts -ftree-vectorize
-ftree-vrp testcase.C
$ valgrind -q ./a.out 
==4448== Invalid write of size 8
==4448==at 0x40116E: S::S(unsigned short, unsigned short, unsigned short)
(in /home/smatz/gcc-bug/97/a.out)
==4448==by 0x4011EC: _GLOBAL__sub_I__ZN1SC2Ettt (in
/home/smatz/gcc-bug/97/a.out)
==4448==by 0x40124C: __libc_csu_init (in /home/smatz/gcc-bug/97/a.out)
==4448==by 0x4C8777C: (below main) (in /lib64/libc-2.33.so)
==4448==  Address 0x4e31c88 is 8 bytes inside a block of size 10 alloc'd
==4448==at 0x483F835: malloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==4448==by 0x401144: S::S(unsigned short, unsigned short, unsigned short)
(in /home/smatz/gcc-bug/97/a.out)
==4448==by 0x4011EC: _GLOBAL__sub_I__ZN1SC2Ettt (in
/home/smatz/gcc-bug/97/a.out)
==4448==by 0x40124C: __libc_csu_init (in /home/smatz/gcc-bug/97/a.out)
==4448==by 0x4C8777C: (below main) (in /lib64/libc-2.33.so)
==4448== 
==4448== Invalid write of size 8
==4448==at 0x401178: S::S(unsigned short, unsigned short, unsigned short)
(in /home/smatz/gcc-bug/97/a.out)
==4448==by 0x4011EC: _GLOBAL__sub_I__ZN1SC2Ettt (in
/home/smatz/gcc-bug/97/a.out)
==4448==by 0x40124C: __libc_csu_init (in /home/smatz/gcc-bug/97/a.out)
==4448==by 0x4C8777C: (below main) (in /lib64/libc-2.33.so)
==4448==  Address 0x4e31ca0 is 22 bytes after a block of size 10 alloc'd
==4448==at 0x483F835: malloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==4448==by 0x401144: S::S(unsigned short, unsigned short, unsigned short)
(in /home/smatz/gcc-bug/97/a.out)
==4448==by 0x4011EC: _GLOBAL__sub_I__ZN1SC2Ettt (in
/home/smatz/gcc-bug/97/a.out)
==4448==by 0x40124C: __libc_csu_init (in /home/smatz/gcc-bug/97/a.out)
==4448==by 0x4C8777C: (below main) (in /lib64/libc-2.33.so)
==4448== 
==4448== 
==4448== Process terminating with default action of signal 11 (SIGSEGV)
==4448==  Access not within mapped region at address 0x522
==4448==at 0x401178: S::S(unsigned short, unsigned short, unsigned short)
(in /home/smatz/gcc-bug/97/a.out)
==4448==by 0x4011EC: _GLOBAL__sub_I__ZN1SC2Ettt (in
/home/smatz/gcc-bug/97/a.out)
==4448==by 0x40124C: __libc_csu_init (in /home/smatz/gcc-bug/97/a.out)
==4448==by 0x4C8777C: (below main) (in /lib64/libc-2.33.so)
==4448==  If you believe this happened as a result of a stack
==4448==  overflow in your program's main thread (unlikely but
==4448==  possible), you can try to increase the size of the
==4448==  main thread stack using the --main-stacksize= flag.
==4448==  The main thread stack size used in this run was 8388608.
Segmentation fault

   0x00401164 <+78>:movzwl %cx,%ecx
   0x00401167 <+81>:shl$0x4,%rcx
   0x0040116b <+85>:add%rax,%rcx
=> 0x0040116e <+88>:movups %xmm0,(%rax)
   0x00401171 <+91>:add$0x10,%rax
   0x00401175 <+95>:cmp%rax,%rcx
   0x00401178 <+98>:jne0x40116e <_ZN1SC2Ettt+88>

$ x86_64-pc-linux-gnu-g++ -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-g++
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-5767-20211203172717-g6262e3a22b3-checking-yes-rtl-df-extra-nobootstrap-pr103149-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--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-5767-20211203172717-g6262e3a22b3-checking-yes-rtl-df-extra-nobootstrap-pr103149-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20211203 (experimental) (GCC)

[Bug c++/82204] G++ doesn't connect friend and extern declarations

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Fixed.