[Bug c++/102357] New: The type specified by explicitly defaulted special member function that is different with it should have had is well-formed

[xmh970252187 at gmail dot com via Gcc-bugs]

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

Bug ID: 102357
   Summary: The type specified by explicitly defaulted special
member function that is different with it should have
had is well-formed
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xmh970252187 at gmail dot com
  Target Milestone: ---

struct C{
C() = default;
C(C const volatile&) = default;
};
int main() {
}

GCC reports an error as a diagnosis while Clang merely reports a warning.
According to [dcl.fct.def#default-2]

> The type T1 of an explicitly defaulted special member function F is allowed 
> to differ from the type T2 it would have had if it were implicitly declared, 
> as follows: 

>> [...]

> if T1 differs from T2
>> if F is an assignment operator, and the return type of T2 differs from the 
>> return type of T2 or T1's parameter type is not a reference, the program is 
>> ill-formed;

>> **otherwise, if F is explicitly defaulted on its first declaration, it is 
>> defined as deleted;** 
>>otherwise, the program is ill-formed.


As per the following
> otherwise, if F is explicitly defaulted on its first declaration, it is 
> defined as deleted;

There are no requirements to let implementations report an diagnosis, let alone
make the program ill-formed. A warning is sufficient here.

[Bug c/102356] New: compile-time explosion at -O3

[haoxintu at gmail dot com via Gcc-bugs]

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

Bug ID: 102356
   Summary: compile-time explosion at -O3
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi all.

It's quite weird that the following small valid program makes GCC spend too
much time on compiling at -O3 with the "-g" enabled. It seems GCC-11.x onwards
versions all suffer this issue.

$cat s.c
#include 
int8_t c_5 = 0x0;
uint8_t uc_9 = 0x09;
uint64_t uli_10 = 0xF1FBFC17225F7A57;
int32_t i_12 = 0x3A6667C6;
uint8_t func( uint32_t ui_14) {
uint32_t *ptr_16 = _14;
if((uli_10 /= ((0 * (*ptr_16 *= uc_9)) <= 0))) 
;
i_12 = 9;
for ( ;i_12 > 2; i_12 -= 2 ) {
uli_10 = -2;
do  
if ((*ptr_16 *= *ptr_16)){
c_5 = 4;
do{
c_5 -=  3; 
if ((*ptr_16 *= *ptr_16))   
uc_9 = 9;  
} while (c_5 > 2 );
}
while ( uli_10 ++ );
}
}

$time gcc -g -O3 -c s.c

real10m25.417s
user9m58.685s
sys 0m0.142s


$time gcc -g -O2 -c s.c

real0m0.124s
user0m0.045s
sys 0m0.011s


$gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/haoxin/haoxin-data/compilers/gcc/build/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure
--prefix=/home/haoxin/haoxin-data/compilers/gcc/build/ --enable-bootstrap
--enable-checking=release --enable-languages=c,c++ --enable-multilib :
(reconfigured) ../configure
--prefix=/home/haoxin/haoxin-data/compilers/gcc/build/ --enable-bootstrap
--enable-checking=release --enable-languages=c,c++ --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210913 (experimental) (GCC) 

Reproduced in Godbolt: https://godbolt.org/z/47dqnPbad

Thanks,
Haoxin

[Bug target/89040] [9 Regressiom] Wrong code with -mno-mmx

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Hongtao.liu from comment #3)
> > foo3b:
> > .LFB0:
> > .cfi_startproc
> > movq%xmm0, %rax   This should be "movd %xmm0, %eax".
> 
> The issue can't be reproduced on current trunk.

Right it seems like it was fixed in GCC 10.1.0.  I have not looked into why
though.

[Bug target/89040] [9 Regressiom] Wrong code with -mno-mmx

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---

> foo3b:
> .LFB0:
>   .cfi_startproc
>   movq%xmm0, %rax   This should be "movd %xmm0, %eax".

The issue can't be reproduced on current trunk.

[Bug middle-end/49899] ICE when redeclaring a static function as weak

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Fixed in GCC 7+ with r7-296.

[Bug tree-optimization/95171] ICE: verify_flow_info failed (error: wrong outgoing edge flags at end of bb 2)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Pinski  ---
Fixed for GCC 10.3.0.

[Bug target/102355] excessive stack usage

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
I suspect is more related to how GCC handles frame pointers and stack pointers.
As seen by -fno-omit-frame-pointer with both GCC and LLVM.

The frame pointer needs to be 16 byte aligned and you can see LLVM generates
the same code as GCC does when this is true:

pushq   %rbp
movq%rsp, %rbp
subq$16, %rsp
leaq-8(%rbp), %rdi
callq   escape(unsigned long long&)
addq$16, %rsp
popq%rbp
retq

GCC omitting the frame pointer is not much difference than when it is not
omitting it except it just does not use the frame pointer at all.

subq$24, %rsp
leaq8(%rsp), %rdi
callescape(unsigned long long&)
addq$24, %rsp
ret

So GCC stack frame is
GCC makes this stack layout:
8 bytes padding 
8 bytes variable "local"
8 bytes padding (where the frame pointer would be stored)
8 bytes return address

It just happens LLVM decides to reuse that location for local variables.

[Bug ipa/93772] ICE in cgraph.c with lto when symbol not defined

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

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

--- Comment #3 from Andrew Pinski  ---
Any news on the testcase?

[Bug target/102355] New: excessive stack usage

[vanyacpp at gmail dot com via Gcc-bugs]

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

Bug ID: 102355
   Summary: excessive stack usage
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vanyacpp at gmail dot com
  Target Milestone: ---

void escape(unsigned long long& a);

void foobar()
{
unsigned long long local;
escape(local);
}

For the function "foobar" GCC allocates excessive stack space:

foobar():
sub rsp, 24
lea rdi, [rsp+8]
callescape(unsigned long long&)
add rsp, 24
ret

The function "foobar" only needs 8 bytes of stack space, but GCC allocates 24.
Please note, that this excessive allocation isn't needed for stack alignment: 8
bytes of local variables are enough to keep the stack aligned. I also tested
Clang and it allocates 8 bytes.

GCC makes this stack layout:
8 bytes padding
8 bytes variable "local"
8 bytes padding
8 bytes return address

I believe the problem is related to the fact that GCC aligns the stack twice:
the first time after the return address placement and the second time after the
local variables are placed. Playing with -mpreferred-stack-boundary confirms
this:

-mpreferred-stack-boundary | stack usage
 3 8
   4 (default)24
 556
 6   120

https://godbolt.org/z/h56aoKvvh

In all cases the stack usage is twice as much (minus 8 bytes for return
address) as the required alignment. I believe stack space can be conserved by
doing alignment only once.

[Bug ipa/60865] ICE: verify_cgraph_node failed: comdat-local function called by outside its comdat with -fdeclone-ctor-dtor

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-checking

--- Comment #3 from Andrew Pinski  ---
This looks like it was fixed on the trunk.  Also it was only ICE with checking
so it is going to be hard to figure out where it was fixed.

[Bug tree-optimization/90134] ICE in duplicate_eh_regions_1, at except.c:557

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

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

--- Comment #3 from Andrew Pinski  ---
This no longer ICEs on the trunk because DSE does:
  Deleted trivially dead stmt: _14 = fq_13(D)->te;

This was done in r12-248 but I suspect there is a missing trapping check.

This code is all undefined anyways .

[Bug target/91102] [9 Regression] aarch64 ICE on Linux kernel with -Os starting with r270266

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|aarch64-linux   |aarch64-linux,
   ||x86_64-linux-gnu

--- Comment #14 from Andrew Pinski  ---
Here is an x86_64 testcase:

register unsigned long a __asm__("r14");
register unsigned long b __asm__("r15");

void test(void)
{
b = a << 4;
}

[Bug target/91102] [9 Regression] aarch64 ICE on Linux kernel with -Os starting with r270266

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||novalazy at gmail dot com

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

[Bug rtl-optimization/91430] [9 Regression] ICE in curr_insn_transform, at lra-constraints.c:3962

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE in curr_insn_transform, |[9 Regression] ICE in
   |at lra-constraints.c:3962   |curr_insn_transform, at
   ||lra-constraints.c:3962
 Status|NEW |RESOLVED
   Target Milestone|--- |9.5
 Resolution|--- |DUPLICATE

--- Comment #3 from Andrew Pinski  ---
Dup of bug 91102.

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

[Bug target/102353] powerpc64le-linux-gnu build failure when build != host

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

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

--- Comment #4 from sandra at gcc dot gnu.org ---
I think rs6000-gen-builtins is supposed to be a build binary, not a host
binary?  I'm seeing this at the end of my build log with that patch.

./rs6000-gen-builtins /path/to/gcc/config/rs6000/rs6000-builtin-new.def \
/path/to/gcc/config/rs6000/rs6000-overload.def rs6000-builtins.h \
rs6000-builtins.c rs6000-vecdefines.h
/path/to/bin/bash: ./rs6000-gen-builtins: cannot execute binary file: Exec
format error
/path/to/gcc/config/rs6000/t-rs6000:67: recipe for target 'rs6000-builtins.c'
failed

[Bug c++/88578] Static C++ objects with flexible array members overlap when initializes are non-const

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

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

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

https://gcc.gnu.org/g:352c0b2668a1e3ce28060ccc265d3427f19e175d

commit r11-8999-g352c0b2668a1e3ce28060ccc265d3427f19e175d
Author: Jakub Jelinek 
Date:   Wed Sep 15 22:21:17 2021 +0200

c++: Fix handling of decls with flexible array members initialized with
side-effects [PR88578]

> > Note, if the flexible array member is initialized only with
non-constant
> > initializers, we have a worse bug that this patch doesn't solve, the
> > splitting of initializers into constant and dynamic initialization
removes
> > the initializer and we don't have just wrong DECL_*SIZE, but nothing is
> > emitted when emitting those vars into assembly either and so the
dynamic
> > initialization clobbers other vars that may overlap the variable.
> > I think we need keep an empty CONSTRUCTOR elt in DECL_INITIAL for the
> > flexible array member in that case.
>
> Makes sense.

So, the following patch fixes that.

The typeck2.c change makes sure we keep those CONSTRUCTORs around (although
they should be empty because all their elts had side-effects/was
non-constant if it was removed earlier), and the varasm.c change is to
avoid
ICEs on those as well as ICEs on other flex array members that had some
initializers without side-effects, but not on the last array element.

The code was already asserting that the (index of the last elt in the
CONSTRUCTOR + 1) times elt size is equal to TYPE_SIZE_UNIT of the
local->val
type, which is true for C flex arrays or for C++ if they don't have any
side-effects or the last elt doesn't have side-effects, this patch changes
that to assertion that the TYPE_SIZE_UNIT is greater than equal to the
offset of the end of last element in the CONSTRUCTOR and uses
TYPE_SIZE_UNIT
(int_size_in_bytes) in the code later on.

2021-09-15  Jakub Jelinek  

PR c++/88578
PR c++/102295
gcc/
* varasm.c (output_constructor_regular_field): Instead of assertion
that array_size_for_constructor result is equal to size of
TREE_TYPE (local->val) in bytes, assert that the type size is
greater
or equal to array_size_for_constructor result and use type size as
fieldsize.
gcc/cp/
* typeck2.c (split_nonconstant_init_1): Don't throw away empty
initializers of flexible array members if they have non-zero type
size.
gcc/testsuite/
* g++.dg/ext/flexary39.C: New test.
* g++.dg/ext/flexary40.C: New test.

(cherry picked from commit e5d1af8a07ae9fcc40ea5c781c3ad46d20ea12a6)

[Bug c++/102295] ELF symbol sizes for variable-length objects are too small (C++)

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

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

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

https://gcc.gnu.org/g:352c0b2668a1e3ce28060ccc265d3427f19e175d

commit r11-8999-g352c0b2668a1e3ce28060ccc265d3427f19e175d
Author: Jakub Jelinek 
Date:   Wed Sep 15 22:21:17 2021 +0200

c++: Fix handling of decls with flexible array members initialized with
side-effects [PR88578]

> > Note, if the flexible array member is initialized only with
non-constant
> > initializers, we have a worse bug that this patch doesn't solve, the
> > splitting of initializers into constant and dynamic initialization
removes
> > the initializer and we don't have just wrong DECL_*SIZE, but nothing is
> > emitted when emitting those vars into assembly either and so the
dynamic
> > initialization clobbers other vars that may overlap the variable.
> > I think we need keep an empty CONSTRUCTOR elt in DECL_INITIAL for the
> > flexible array member in that case.
>
> Makes sense.

So, the following patch fixes that.

The typeck2.c change makes sure we keep those CONSTRUCTORs around (although
they should be empty because all their elts had side-effects/was
non-constant if it was removed earlier), and the varasm.c change is to
avoid
ICEs on those as well as ICEs on other flex array members that had some
initializers without side-effects, but not on the last array element.

The code was already asserting that the (index of the last elt in the
CONSTRUCTOR + 1) times elt size is equal to TYPE_SIZE_UNIT of the
local->val
type, which is true for C flex arrays or for C++ if they don't have any
side-effects or the last elt doesn't have side-effects, this patch changes
that to assertion that the TYPE_SIZE_UNIT is greater than equal to the
offset of the end of last element in the CONSTRUCTOR and uses
TYPE_SIZE_UNIT
(int_size_in_bytes) in the code later on.

2021-09-15  Jakub Jelinek  

PR c++/88578
PR c++/102295
gcc/
* varasm.c (output_constructor_regular_field): Instead of assertion
that array_size_for_constructor result is equal to size of
TREE_TYPE (local->val) in bytes, assert that the type size is
greater
or equal to array_size_for_constructor result and use type size as
fieldsize.
gcc/cp/
* typeck2.c (split_nonconstant_init_1): Don't throw away empty
initializers of flexible array members if they have non-zero type
size.
gcc/testsuite/
* g++.dg/ext/flexary39.C: New test.
* g++.dg/ext/flexary40.C: New test.

(cherry picked from commit e5d1af8a07ae9fcc40ea5c781c3ad46d20ea12a6)

[Bug c++/102295] ELF symbol sizes for variable-length objects are too small (C++)

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

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

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

https://gcc.gnu.org/g:6550198bd8467f435959fa25b69c217a6ef75c7a

commit r11-8998-g6550198bd8467f435959fa25b69c217a6ef75c7a
Author: Jakub Jelinek 
Date:   Tue Sep 14 16:56:30 2021 +0200

c++: Update DECL_*SIZE for objects with flexible array members with
initializers [PR102295]

The C FE updates DECL_*SIZE for vars which have initializers for flexible
array members for many years, but C++ FE kept DECL_*SIZE the same as the
type size (i.e. as if there were zero elements in the flexible array
member).  This results e.g. in ELF symbol sizes being too small.

Note, if the flexible array member is initialized only with non-constant
initializers, we have a worse bug that this patch doesn't solve, the
splitting of initializers into constant and dynamic initialization removes
the initializer and we don't have just wrong DECL_*SIZE, but nothing is
emitted when emitting those vars into assembly either and so the dynamic
initialization clobbers other vars that may overlap the variable.
I think we need keep an empty CONSTRUCTOR elt in DECL_INITIAL for the
flexible array member in that case.

2021-09-14  Jakub Jelinek  

PR c++/102295
* decl.c (layout_var_decl): For aggregates ending with a flexible
array member, add the size of the initializer for that member to
DECL_SIZE and DECL_SIZE_UNIT.

* g++.target/i386/pr102295.C: New test.

(cherry picked from commit 818c505188ff5cd8eb048eb0e614c4ef732225bd)

[Bug c++/102305] intrinsic __is_constructible is wrong for templated abstract classes

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

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

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

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

commit r11-8997-g6f61195e0433f907e5aa1a16f02d4106503d3351
Author: Jakub Jelinek 
Date:   Tue Sep 14 16:55:04 2021 +0200

c++: Fix __is_*constructible/assignable for templates [PR102305]

is_xible_helper returns error_mark_node (i.e. false from the traits)
for abstract classes by testing ABSTRACT_CLASS_TYPE_P (to) early.
Unfortunately, as the testcase shows, that doesn't work on class templates
that haven't been instantiated yet, ABSTRACT_CLASS_TYPE_P for them is false
until it is instantiated, which is done when the routine later constructs
a dummy object with that type.

The following patch fixes this by calling complete_type first, so that
ABSTRACT_CLASS_TYPE_P test will work properly, while keeping the handling
of arrays with unknown bounds, or incomplete types where it is done
currently.

2021-09-14  Jakub Jelinek  

PR c++/102305
* method.c (is_xible_helper): Call complete_type on to.

* g++.dg/cpp0x/pr102305.C: New test.

(cherry picked from commit f008fd3a480e3718436156697ebe7eeb47841457)

[Bug c++/101904] Wrong result of decltype during instantiation of std::result_of

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:22806064a67cf30599957c1ffb322aa30e9e57e7

commit r12-3559-g22806064a67cf30599957c1ffb322aa30e9e57e7
Author: Patrick Palka 
Date:   Wed Sep 15 18:41:21 2021 -0400

c++: shortcut bad convs during overload resolution, part 2 [PR101904]

The r12-3346 change makes us avoid computing excess argument conversions
during overload resolution, but only when it turns out there's a
strictly viable candidate in the overload set.  If there's no such
candidate then we still need to compute more conversions than strictly
necessary because subsequent conversions after the first bad conversion
can turn a non-strictly viable candidate into an unviable one, and that
affects the outcome of overload resolution and the behavior of its
callers (because of -fpermissive).

But at least in a SFINAE context, the distinction between a non-strictly
viable and an unviable candidate shouldn't matter all that much since
performing a bad conversion is always an error (even with -fpermissive),
and so forming a call to a non-strictly viable candidate will end up
being a SFINAE error anyway, just like in the unviable case.  Hence a
non-strictly viable candidate is effectively unviable (in a SFINAE
context), and we don't really need to distinguish between the two kinds.
We can take advantage of this observation to avoid computing excess
argument conversions even when there's no strictly viable candidate in
the overload set.

This patch implements this idea.  We usually detect a SFINAE context by
looking for the absence of the tf_error flag, but that's not specific
enough: we can also get here from build_user_type_conversion with
tf_error cleared, and there the distinction between a non-strictly
viable candidate and an unviable candidate still matters (it determines
whether a user-defined conversion is bad or just doesn't exist).  So this
patch sets and checks for the tf_conv flag to detect this situation too,
which avoids regressing conv2.C below.

Unlike the previous change, this one does affect the outcome of overload
resolution, but it should do so only in a way that preserves backwards
compatibility with -fpermissive.

PR c++/101904

gcc/cp/ChangeLog:

* call.c (build_user_type_conversion_1): Add tf_conv to complain.
(add_candidates): When in a SFINAE context, instead of adding a
candidate to bad_fns just mark it unviable.

gcc/testsuite/ChangeLog:

* g++.dg/ext/conv2.C: New test.
* g++.dg/template/conv17.C: Extend test.

[Bug middle-end/78463] pure/const functions are assumed not to trap

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

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

--- Comment #1 from Andrew Pinski  ---
I thought this was just fixed recently but I could be wrong.

[Bug fortran/102331] ICE in attr_decl1, at fortran/decl.c:8691

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

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

--- Comment #4 from Steve Kargl  ---
On Wed, Sep 15, 2021 at 08:57:45PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102331
> 
> --- Comment #3 from anlauf at gcc dot gnu.org ---
> (In reply to kargl from comment #2)
> > The following patch fixes the problem.  It has not been regression tested.
> 
> This restores the error, but for CLASS I now get:
> 
> pr102331.f90:2:3:
> 
> 2 |   allocatable :: f
>   |   1
> Error: Unclassifiable statement at (1)
> pr102331.f90:1:0:
> 
> 1 | class(t) function f()
>   | 
> Error: The type for function 'f' at (1) is not accessible
> 
> while the error message for line 2 does not show up for TYPE.
> Maybe there are a few more places that need fixing.
> (Not only the obvious one after the second hunk for parse.c).
> 

Yes, likely, 'ts.type == BT_CLASS' needs to be sprinkled in
other places.  Unfortunately, the 'Unclassifiable statement' 
error is a last resort catch-all error.  I know little about
the CLASS implementation.  I suspect BT_CLASS takes a much
different path through the compiler.

[Bug tree-optimization/90556] [meta-bug] bogus/missing -Wreturn-local-addr

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

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

Martin Sebor  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-09-15

[Bug c/82520] Missing warning when stack addresses escape the current scope

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||barry.revzin at gmail dot com

--- Comment #5 from Martin Sebor  ---
*** Bug 102263 has been marked as a duplicate of this bug. ***

[Bug middle-end/102263] Requesting enhanced warning on returning pointer/reference to local

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
 Resolution|--- |DUPLICATE
  Component|c++ |middle-end
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Martin Sebor  ---
Confirmed as a duplicate of pr82520.

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

[Bug tree-optimization/90556] [meta-bug] bogus/missing -Wreturn-local-addr

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

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

Bug 94312 Summary: missing -Wreturn-local-addr on returning local address via 
memchr or memset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94312

   What|Removed |Added

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

[Bug middle-end/94312] missing -Wreturn-local-addr on returning local address via memchr or memset

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

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |10.0

--- Comment #2 from Martin Sebor  ---
Fixed in GCC 10 by r273261.

[Bug c/20785] Pragma STDC * (C99 FP) unimplemented

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

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

--- Comment #11 from Andrew Pinski  ---
I have idea on how to fix the FENV_ACCESS issue (for gimple), basically you add
an extra virtual use op for float gimples and virtual define for functions and
inline-asm. Now I am not going to implement this but I want to record it
somewhere.

[Bug c++/102350] __builtin_source_location not available in earlier language modes

[pdimov at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Peter Dimov  ---
On the surface this looks not hard to fix - use ::__source_location_impl (or
std::__source_location_impl) instead of std::source_location:__impl as the
layout struct - but I'm not sure whether this would pose some further problems.

[Bug c/59159] Need opaque pass-through as optimization barrier

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

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

--- Comment #6 from Andrew Pinski  ---
__builtin_assoc_barrier is being implemented
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578935.html That
should solve part of this.

[Bug fortran/102315] ICE tree check: expected integer_cst, have save_expr in gfc_trans_array_constructor_value, at fortran/trans-array.c:2056

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

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Looks familiar, and I am pretty sure there's a duplicate.

Removing one set of [] makes the code compile:

  y = [character(8) :: 'a'//trim(x), 'b', 'c', 'd', 'e']

is obviously "fine".

[Bug bootstrap/67102] Parallel build fails in libffi/configure

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-Septemb
   ||er/579524.html

--- Comment #3 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579524.html

[Bug fortran/102331] ICE in attr_decl1, at fortran/decl.c:8691

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

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #2)
> The following patch fixes the problem.  It has not been regression tested.

This restores the error, but for CLASS I now get:

pr102331.f90:2:3:

2 |   allocatable :: f
  |   1
Error: Unclassifiable statement at (1)
pr102331.f90:1:0:

1 | class(t) function f()
  | 
Error: The type for function 'f' at (1) is not accessible

while the error message for line 2 does not show up for TYPE.
Maybe there are a few more places that need fixing.
(Not only the obvious one after the second hunk for parse.c).

[Bug other/92435] % format codes for diagnostics are not documented in the GCC internals manual

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-09-15

--- Comment #3 from Martin Sebor  ---
See also the following question:
  https://gcc.gnu.org/pipermail/gcc/2021-September/237281.html
It would be helpful to document the GCC specific directives somewhere.  The
-Wformat-diag GCC-developer warning option could also stand to be documented.

[Bug target/102336] plugins for xtensa-elf gcc cannot be built because xtensa-config.h is missing

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
fxied.

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

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

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

Bug 102327 Summary: gcc/config/i386/i386-expand.c:14678: Suspicious coding ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102327

   What|Removed |Added

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

[Bug target/102327] gcc/config/i386/i386-expand.c:14678: Suspicious coding ?

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug c++/102283] Inconsistent/wrong overload resolution when using an initializer list and a defaulted template parameter

[dangelog at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Giuseppe D'Angelo  ---
Hi,

Do you think that in my original testcase the call should be rejected as
ambiguous as well? (It seems "reasonable" to me, but maybe I'm missing some
niche detail about overload resolution when combined with template deduction.)


This small variation over the testcase:


struct A { };
struct B { };

template 
void f(T &&); // #1
void f(const B&) = delete; // #2

int main() {
  f({});
}

This now makes GCC select #2, and fail to compile because it's deleted; Clang
and MSVC still select #1. But a further, minor change:


struct A { };
struct B { };

template  // <-- changed this
void f(T &&); // #1
void f(const B&) = delete; // #2

int main() {
  f({});
}

makes GCC select #1...

[Bug c++/102295] ELF symbol sizes for variable-length objects are too small (C++)

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

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

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

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

commit r12-3556-ge5d1af8a07ae9fcc40ea5c781c3ad46d20ea12a6
Author: Jakub Jelinek 
Date:   Wed Sep 15 22:21:17 2021 +0200

c++: Fix handling of decls with flexible array members initialized with
side-effects [PR88578]

> > Note, if the flexible array member is initialized only with
non-constant
> > initializers, we have a worse bug that this patch doesn't solve, the
> > splitting of initializers into constant and dynamic initialization
removes
> > the initializer and we don't have just wrong DECL_*SIZE, but nothing is
> > emitted when emitting those vars into assembly either and so the
dynamic
> > initialization clobbers other vars that may overlap the variable.
> > I think we need keep an empty CONSTRUCTOR elt in DECL_INITIAL for the
> > flexible array member in that case.
>
> Makes sense.

So, the following patch fixes that.

The typeck2.c change makes sure we keep those CONSTRUCTORs around (although
they should be empty because all their elts had side-effects/was
non-constant if it was removed earlier), and the varasm.c change is to
avoid
ICEs on those as well as ICEs on other flex array members that had some
initializers without side-effects, but not on the last array element.

The code was already asserting that the (index of the last elt in the
CONSTRUCTOR + 1) times elt size is equal to TYPE_SIZE_UNIT of the
local->val
type, which is true for C flex arrays or for C++ if they don't have any
side-effects or the last elt doesn't have side-effects, this patch changes
that to assertion that the TYPE_SIZE_UNIT is greater than equal to the
offset of the end of last element in the CONSTRUCTOR and uses
TYPE_SIZE_UNIT
(int_size_in_bytes) in the code later on.

2021-09-15  Jakub Jelinek  

PR c++/88578
PR c++/102295
gcc/
* varasm.c (output_constructor_regular_field): Instead of assertion
that array_size_for_constructor result is equal to size of
TREE_TYPE (local->val) in bytes, assert that the type size is
greater
or equal to array_size_for_constructor result and use type size as
fieldsize.
gcc/cp/
* typeck2.c (split_nonconstant_init_1): Don't throw away empty
initializers of flexible array members if they have non-zero type
size.
gcc/testsuite/
* g++.dg/ext/flexary39.C: New test.
* g++.dg/ext/flexary40.C: New test.

[Bug c++/88578] Static C++ objects with flexible array members overlap when initializes are non-const

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

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

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

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

commit r12-3556-ge5d1af8a07ae9fcc40ea5c781c3ad46d20ea12a6
Author: Jakub Jelinek 
Date:   Wed Sep 15 22:21:17 2021 +0200

c++: Fix handling of decls with flexible array members initialized with
side-effects [PR88578]

> > Note, if the flexible array member is initialized only with
non-constant
> > initializers, we have a worse bug that this patch doesn't solve, the
> > splitting of initializers into constant and dynamic initialization
removes
> > the initializer and we don't have just wrong DECL_*SIZE, but nothing is
> > emitted when emitting those vars into assembly either and so the
dynamic
> > initialization clobbers other vars that may overlap the variable.
> > I think we need keep an empty CONSTRUCTOR elt in DECL_INITIAL for the
> > flexible array member in that case.
>
> Makes sense.

So, the following patch fixes that.

The typeck2.c change makes sure we keep those CONSTRUCTORs around (although
they should be empty because all their elts had side-effects/was
non-constant if it was removed earlier), and the varasm.c change is to
avoid
ICEs on those as well as ICEs on other flex array members that had some
initializers without side-effects, but not on the last array element.

The code was already asserting that the (index of the last elt in the
CONSTRUCTOR + 1) times elt size is equal to TYPE_SIZE_UNIT of the
local->val
type, which is true for C flex arrays or for C++ if they don't have any
side-effects or the last elt doesn't have side-effects, this patch changes
that to assertion that the TYPE_SIZE_UNIT is greater than equal to the
offset of the end of last element in the CONSTRUCTOR and uses
TYPE_SIZE_UNIT
(int_size_in_bytes) in the code later on.

2021-09-15  Jakub Jelinek  

PR c++/88578
PR c++/102295
gcc/
* varasm.c (output_constructor_regular_field): Instead of assertion
that array_size_for_constructor result is equal to size of
TREE_TYPE (local->val) in bytes, assert that the type size is
greater
or equal to array_size_for_constructor result and use type size as
fieldsize.
gcc/cp/
* typeck2.c (split_nonconstant_init_1): Don't throw away empty
initializers of flexible array members if they have non-zero type
size.
gcc/testsuite/
* g++.dg/ext/flexary39.C: New test.
* g++.dg/ext/flexary40.C: New test.

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

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

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

Bug 102346 Summary: Missing -Warray-bounds due to constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102346

   What|Removed |Added

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

[Bug middle-end/35587] -Warray-bounds does not work at all or does not find all trivial cases, and :works only with -O2 or -O3

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||fredrik.hederstierna@securi
   ||tas-direct.com

--- Comment #14 from Martin Sebor  ---
*** Bug 102346 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/102346] Missing -Warray-bounds due to constant folding

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

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

Martin Sebor  changed:

   What|Removed |Added

Summary|Missing warning for array   |Missing -Warray-bounds due
   |bounds  |to constant folding
  Component|c   |tree-optimization
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE
   Last reconfirmed||2021-9-15
 CC||msebor at gcc dot gnu.org

--- Comment #1 from Martin Sebor  ---
The root cause of the missing warning is the same as that of some of the same
false negatives discussed in pr35587 and pr86691: GCC folds accesses to
elements of constant arrays with initializers very early on.  Accesses to
elements for which  no initializer has been explicitly provided (and those that
are implicitly zero) are folded to zero.  The folding is done without regard to
the index and even without optimization.  At the time the warning runs the
accesses are gone from the IL.  The simple test case below shows this effect:

$ cat z.c && gcc -O2 -S -Wall -fdump-tree-original=/dev/stdout
-fdump-tree-gimple=/dev/stdout z.c 
const int a[1] = { 1 };

int f (void)
{
  return a[1];
}

;; Function f (null)
;; enabled by -tree-original


{
  return (int) a[1];
}

int f ()
{
  int D.1982;

  D.1982 = 0;
  return D.1982;
}

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

[Bug target/102352] Add -mstack-protector-guard=... for arm32

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/102353] powerpc64le-linux-gnu build failure when build != host

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

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

--- Comment #3 from Bill Schmidt  ---
Hi Sandra,

Does the following work for your cross?

diff --git a/gcc/config/rs6000/t-rs6000 b/gcc/config/rs6000/t-rs6000
index 92766d8ea25..738d4cf9493 100644
--- a/gcc/config/rs6000/t-rs6000
+++ b/gcc/config/rs6000/t-rs6000
@@ -53,8 +53,7 @@ rbtree.o: $(srcdir)/config/rs6000/rbtree.c
$(POSTCOMPILE)

 rs6000-gen-builtins: rs6000-gen-builtins.o rbtree.o
-   $(LINKER_FOR_BUILD) $(BUILD_LINKERFLAGS) $(BUILD_LDFLAGS) -o $@ \
-   $(filter-out $(BUILD_LIBDEPS), $^) $(BUILD_LIBS)
+   $(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) $< rbtree.o -o $@

 # TODO: Whenever GNU make 4.3 is the minimum required, we should use
 # grouped targets on this:

Thanks!
Bill

[Bug libstdc++/102354] std::advance overloaded for path::iterator will never be called

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-09-15
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Oops!

[Bug c++/102350] __builtin_source_location not available in earlier language modes

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

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

--- Comment #3 from Jonathan Wakely  ---
That would be non-conforming though, because source_location isn't a reserved
name in C++17, so programs can use that as a (really dumb) macro name, which
would then break the header.

[Bug tree-optimization/102238] alias_offset in gimple-ssa-sprintf.c is broken

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Martin Sebor from comment #2)
> > The source and the destination arrays in the test case do not overlap so
> > there is no warning.  The preprocessed output makes it easier to see than
> > the original (the destination of the call is the a member of the object
> > pointed to by the function argument s3 and the %s argument the local array
> > 'a'):
> 
> Silly mistake on my part, it is still buggy:

You can add 
  _Static_assert (offsetof(struct S3, s2_2.s_1.a) == 40);

To see that 40 is the offiset of s2_2.s_1.a.

[Bug tree-optimization/102216] [12 Regression] missed optimization causing Warray-bounds

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

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

Bug 102238 Summary: alias_offset in gimple-ssa-sprintf.c is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102238

   What|Removed |Added

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

[Bug tree-optimization/102238] alias_offset in gimple-ssa-sprintf.c is broken

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Martin Sebor from comment #2)
> The source and the destination arrays in the test case do not overlap so
> there is no warning.  The preprocessed output makes it easier to see than
> the original (the destination of the call is the a member of the object
> pointed to by the function argument s3 and the %s argument the local array
> 'a'):

Silly mistake on my part, it is still buggy:

/* 
   { dg-do compile }
   { dg-options "-O2 -Wno-format-overflow -Wrestrict -ftrack-macro-expansion=0"
}
*/
void sink (int);
#define S10 "0123456789"
extern char a2[2][22];
#define T(d, ...) do {  \
char a[22] = S10;   \
sink (__builtin_sprintf ((d), __VA_ARGS__));\
  } while (0)
struct S {
  char a[4];
  char b[4];
};
struct S2 {
  struct S s_1;
  struct S s_2;
  struct S sa3[3];
};
struct S3 {
  struct S2 s2_1;
  struct S2 s2_2;

  struct {
struct {
  struct {
struct S sa_3[3];
  } a_1[3];
} a_2[3][3];
  } a_3[3][3][3];

  char fa[];
};
void test_struct_member_array (struct S3 *s3, int i)
{
  char *a1 = (char*)s3;
  char *d;
  const char *s;
  d = s3->s2_2.s_1.a;
  s = s3->s2_2.s_1.a;
  T (d, "%s", a1 + 40);   /* { dg-warning "overlaps" } */
  T (d, "%s", a1 + 41);   /* { dg-warning "may overlap" } */
  T (d, "%s", a1 + 42);   /* { dg-warning "may overlap" } */
}

[Bug analyzer/102328] Obsolete version of GCC analyzer on Compiler Explorer

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #4 from David Malcolm  ---
godbolt.org now no longer shows "x86-64 gcc (static analysis)" as an option
(unless following a link such as the one in comment #0 which uses it).

Marking this as resolved.

Sorry again about the confusion.

[Bug target/101761] Random hang with 29_atomics/atomic_ref/wait_notify.cc

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

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

--- Comment #11 from Thomas Rodgers  ---
(In reply to Jonathan Wakely from comment #10)
> http://eel.is/c++draft/atomics#ref.generic.general-3.sentence-2
> 
> "While any atomic_­ref instances exist that reference the *ptr object, all
> accesses to that object shall exclusively occur through those atomic_­ref
> instances."

Yes. I will submit a patch for this test shortly.

Having said that, the atomic integral tests also spuriously deadlock, they
don't have this UB issue.

[Bug target/101761] Random hang with 29_atomics/atomic_ref/wait_notify.cc

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

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

--- Comment #10 from Jonathan Wakely  ---
http://eel.is/c++draft/atomics#ref.generic.general-3.sentence-2

"While any atomic_­ref instances exist that reference the *ptr object, all
accesses to that object shall exclusively occur through those atomic_­ref
instances."

[Bug target/101761] Random hang with 29_atomics/atomic_ref/wait_notify.cc

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

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

--- Comment #9 from Jonathan Wakely  ---
My point is that *any* read of aa is undefined while there is an atomic_ref
using it, even in the absence of other threads.

It happens to cause the race you describe, because the value of aa is changing
concurrently. But it's undefined according to the standard even without that.

[Bug target/101761] Random hang with 29_atomics/atomic_ref/wait_notify.cc

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

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

--- Comment #8 from Jonathan Wakely  ---
It's a test for std::atomic_ref, it has to use atomic_ref :-)

[Bug target/101761] Random hang with 29_atomics/atomic_ref/wait_notify.cc

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

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

--- Comment #7 from Florian Weimer  ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Florian Weimer from comment #4)
> >   a.wait(aa);
> 
> This line is undefined and needs to be a.wait(va) anyway.

Yes, that's what I meant. Or  the test needs to use std::atomic, not
std::atomic_ref.

[Bug target/101761] Random hang with 29_atomics/atomic_ref/wait_notify.cc

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

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Florian Weimer from comment #4)
>   a.wait(aa);

This line is undefined and needs to be a.wait(va) anyway.

[Bug target/101761] Random hang with 29_atomics/atomic_ref/wait_notify.cc

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

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

--- Comment #5 from Thomas Rodgers  ---
(In reply to Florian Weimer from comment #4)
> I think it's a test bug:
> 
>   std::atomic_ref a{ aa };
> 
>   std::thread t([&]
> {
> a.store(bb);
> a.notify_one();
> });
>   a.wait(aa);
> 
> Due to the use of std::atomic_ref, store() overwrites aa with the value of
> bb. If the notify_one() call completes before the wait() call, wait() blocks
> because aa == bb (due to the previous store()), and the wakeup never happens
> because wakes are not queued.

This was my initial suspicion. It applies to all of the
29_atomics/**/wait_notify.cc tests. The libc++ tests for wait/notify have the
same problem (see
https://github.com/llvm/llvm-project/blob/main/libcxx/test/std/atomics/atomics.types.operations/atomics.types.operations.wait/atomic_wait.pass.cpp)

I have, as part of this investigation, extensively re-reviewed the
implementation detail in bits/atomic_wait.h and I think there is a race
condition lurking in the implementation which also needs to be address.
Specifically tracking waiters to try to void making the syscall for
FUTEX_WAKE_PRIVATE if there are no current waiters. In order for this to work
the increment of the waiter count would have to be atomic with syscall. I
believe that libc++ also has this same issue.

[Bug target/102349] [12 Regression] crash in rs6000_xcoff_encode_section_info since r12-446-g8b5b814d51ff73bc739c0c037ae18df07acf2d96

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

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

--- Comment #8 from David Edelsohn  ---
This needs an additional adjustment.  The encoding decoration needs to be
applied if the decl isn't an alias.  That means both a null summary *OR* the
decl is not explicitly an alias.

I'm proposing the following:

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index d0830a95027..ad81dfb316d 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -21728,8 +21728,8 @@ rs6000_xcoff_encode_section_info (tree decl, rtx rtl,
in
t first)
   if (decl
   && DECL_P (decl)
   && VAR_OR_FUNCTION_DECL_P (decl)
-  && symtab_node::get (decl) != NULL
-  && symtab_node::get (decl)->alias == 0
+  && (symtab_node::get (decl) == NULL
+ || symtab_node::get (decl)->alias == 0)
   && symname[strlen (symname) - 1] != ']')
 {
   const char *smclass = NULL;

[Bug c++/101725] simple requirement of parameter in defaulted non-type template parameter considered non-dependent

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

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

--- Comment #4 from Patrick Palka  ---
*** Bug 94499 has been marked as a duplicate of this bug. ***

[Bug c++/94499] [concepts] bogus "local variable may not appear in this context" error

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #1 from Patrick Palka  ---
Dup of the already-fixed PR101725

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

[Bug c++/98486] Variable template specialization doesn't account for primary's constraints

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |11.3
 CC||ppalka at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

[Bug tree-optimization/102200] [12 Regression] ice in put_ref, at pointer-query.cc:1351 since r12-3300-gece28da924ddda8b

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
The pointer_query code assumes that both pointer operands of a MIN_EXPR and
MAX_EXPR refer to the same object as required by the language.  The test case
violates that assumption by setting curr to point to the function first and
then comparing it to the address of the local variable end.  pointer_query
simply needs to avoid making this assumption (ideally while also arranging for
the invalid pointer relational expressions to be diagnosed).

[Bug c++/102050] Nonempty list-initialization rejects constructor with defaulted std::initializer_list

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #2 from Patrick Palka  ---
Fixed for GCC 12.

[Bug libstdc++/102354] New: std::advance overloaded for path::iterator will never be called

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 102354
   Summary: std::advance overloaded for path::iterator will never
be called
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

r267057 seems to be implemented incorrectly:

  template
void
advance(filesystem::path::iterator& __i, _Distance __n)
{ __path_iter_advance(__i, static_cast(__n)); }


The only way to call this std::advance is to explicitly specify _InputIterator,
for example:

  std::filesystem::path p = "/a/b/c/d/e/f/g";
  auto it = p.begin();
  std::advance(it, 1);

[Bug c++/102050] Nonempty list-initialization rejects constructor with defaulted std::initializer_list

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r12-3555-g2ab5c3d5457f0d480c6423ee7ac52ce1f98592c9
Author: Patrick Palka 
Date:   Wed Sep 15 13:54:53 2021 -0400

c++: default ctor that's also a list ctor [PR102050]

In grok_special_member_properties we need to set TYPE_HAS_COPY_CTOR,
TYPE_HAS_DEFAULT_CONSTRUCTOR and TYPE_HAS_LIST_CTOR independently
from each other because a constructor can be both a default and list
constructor (as in the first testcase), or both a default and copy
constructor (as in the second testcase).

PR c++/102050

gcc/cp/ChangeLog:

* decl.c (grok_special_member_properties): Set
TYPE_HAS_COPY_CTOR, TYPE_HAS_DEFAULT_CONSTRUCTOR
and TYPE_HAS_LIST_CTOR independently from each other.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist125.C: New test.
* g++.dg/cpp0x/initlist126.C: New test.

[Bug target/102353] powerpc64le-linux-gnu build failure when build != host

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

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

Bill Schmidt  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |wschmidt at gcc dot 
gnu.org
 Ever confirmed|0   |1
 CC||wschmidt at gcc dot gnu.org
   Last reconfirmed||2021-09-15
 Status|UNCONFIRMED |NEW

--- Comment #2 from Bill Schmidt  ---
Ah, sorry for the silly mistake.  Mine.

[Bug c++/102350] __builtin_source_location not available in earlier language modes

[pdimov at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Peter Dimov  ---
(In reply to Jakub Jelinek from comment #1)
> __builtin_source_location doesn't require -std=c++20, but indeed does
> require  or some compatible definition of
> std::source_location::__impl class, and as it doesn't have hardcoded layout
> of that structure but instead matches whatever the source header provides
> (looks up fields it needs in there and uses whatever types and layout they
> have), there is no way around that.

That was my guess. I suppose that's inevitable then, and there's nothing to ask
for on the compiler side,  just needs to not disable itself
completely for pre-C++20 as it does now. (It's not going to work, but it can
still provide __impl so that the builtin can see it.)

[Bug target/102353] powerpc64le-linux-gnu build failure when build != host

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

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

--- Comment #1 from sandra at gcc dot gnu.org ---
Ooops, I meant x86_64-linux-gnu build, not host.  :-(

[Bug target/102353] New: powerpc64le-linux-gnu build failure when build != host

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

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

Bug ID: 102353
   Summary: powerpc64le-linux-gnu build failure when build != host
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
CC: wschmidt at linux dot ibm.com
  Target Milestone: ---
  Host: powerpc64le-linux-gnu
Target: powerpc64le-linux-gnu
 Build: x86_64-linux-gnu

I'm trying to build gcc for powerpc64le-linux-gnu host and target from
x86_64-linux-gnu host using scripts that have been known to work within the
last month or so.  I'm seeing multiple linker errors like 

ld: rs6000-gen-builtins.o: Relocations in generic ELF (EM: 21)

followed by

ld: rs6000-gen-builtins.o: error adding symbols: file in wrong format

And indeed, looking at config/rs6000/t-rs6000, this seems to be broken:

rs6000-gen-builtins.o: $(srcdir)/config/rs6000/rs6000-gen-builtins.c
$(COMPILE) $<
$(POSTCOMPILE)

rbtree.o: $(srcdir)/config/rs6000/rbtree.c
$(COMPILE) $<
$(POSTCOMPILE)

rs6000-gen-builtins: rs6000-gen-builtins.o rbtree.o
$(LINKER_FOR_BUILD) $(BUILD_LINKERFLAGS) $(BUILD_LDFLAGS) -o $@ \
$(filter-out $(BUILD_LIBDEPS), $^) $(BUILD_LIBS)

The two .o files are being built with the *host* compiler, and we're trying to
link them with the *build* linker.  ???

[Bug fortran/102331] ICE in attr_decl1, at fortran/decl.c:8691

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
The following patch fixes the problem.  It has not been regression tested.

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 05081c40f1e..85c95cea17f 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -8695,7 +8695,9 @@ attr_decl1 (void)
   /* Update symbol table.  DIMENSION attribute is set in
  gfc_set_array_spec().  For CLASS variables, this must be applied
  to the first component, or '_data' field.  */
-  if (sym->ts.type == BT_CLASS && sym->ts.u.derived->attr.is_class)
+  if (sym->ts.type == BT_CLASS
+  && sym->ts.u.derived
+  && sym->ts.u.derived->attr.is_class)
 {
   /* gfc_set_array_spec sets sym->attr not CLASS_DATA(sym)->attr.  Check
 for duplicate attribute here.  */
diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
index 6d7845e8517..8d6d4f4e98f 100644
--- a/gcc/fortran/parse.c
+++ b/gcc/fortran/parse.c
@@ -3813,7 +3813,7 @@ match_deferred_characteristics (gfc_typespec * ts)
   m = gfc_match_prefix (ts);
   gfc_buffer_error (false);

-  if (ts->type == BT_DERIVED)
+  if (ts->type == BT_DERIVED || ts->type == BT_CLASS)
 {
   ts->kind = 0;

@@ -4094,7 +4094,7 @@ declSt:
   if (bad_characteristic)
 {
   ts = _current_block ()->result->ts;
-  if (ts->type != BT_DERIVED)
+  if (ts->type != BT_DERIVED && ts->type != BT_CLASS)
gfc_error ("Bad kind expression for function %qs at %L",
   gfc_current_block ()->name,
   _current_block ()->declared_at);

[Bug tree-optimization/102216] [12 Regression] missed optimization causing Warray-bounds

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

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

Bug 102238 Summary: alias_offset in gimple-ssa-sprintf.c is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102238

   What|Removed |Added

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

[Bug tree-optimization/102238] alias_offset in gimple-ssa-sprintf.c is broken

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
The source and the destination arrays in the test case do not overlap so there
is no warning.  The preprocessed output makes it easier to see than the
original (the destination of the call is the a member of the object pointed to
by the function argument s3 and the %s argument the local array 'a'):

gcc -E pr102238.c
# 0 "pr102238.c"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "pr102238.c"
void sink (int);

extern char a2[2][22];




struct S {
  char a[4];
  char b[4];
};
struct S2 {
  struct S s_1;
  struct S s_2;
  struct S sa3[3];
};
struct S3 {
  struct S2 s2_1;
  struct S2 s2_2;

  struct {
struct {
  struct {
struct S sa_3[3];
  } a_1[3];
} a_2[3][3];
  } a_3[3][3][3];

  char fa[];
};
void test_struct_member_array (struct S3 *s3, int i)
{
  char *a = (char*)s3;
  char *d = s3->s2_2.s_1.a;
  const char *s = s3->s2_2.s_1.a;

  do { char a[22] = "0123456789"; sink (__builtin_sprintf ((d), "%s", a + 40));
} while (0);
  do { char a[22] = "0123456789"; sink (__builtin_sprintf ((d), "%s", a + 41));
} while (0);
  do { char a[22] = "0123456789"; sink (__builtin_sprintf ((d), "%s", a + 42));
} while (0);
}

[Bug c++/102350] __builtin_source_location not available in earlier language modes

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
__builtin_source_location doesn't require -std=c++20, but indeed does require
 or some compatible definition of std::source_location::__impl
class, and as it doesn't have hardcoded layout of that structure but instead
matches whatever the source header provides (looks up fields it needs in there
and uses whatever types and layout they have), there is no way around that.
Of course, without -std=c++20 the usefulness of it is limited because it relies
on consteval that is only supported in C++20 or later.

[Bug target/102352] New: Add -mstack-protector-guard=... for arm32

[kees at outflux dot net via Gcc-bugs]

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

Bug ID: 102352
   Summary: Add -mstack-protector-guard=... for arm32
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kees at outflux dot net
  Target Milestone: ---

As done for powerpc (1b3254e4bbe82245421a55324bc8fe34a99c6e3c), aarch64
(cd0b2d361df82c848dc7e1c3078651bb0624c3c6), riscv
(c931e8d5a96463427040b0d11f9c4352ac22b2b0), and x86
(e1769bdd4cef522ada32aec863feba41116b183a), the arm32 target needs
mstack-protector-guard= support as well, so that the kernel can gain per-thread
stack canaries on arm32:
https://github.com/KSPP/linux/issues/29

[Bug c++/102283] Inconsistent/wrong overload resolution when using an initializer list and a defaulted template parameter

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
Reduced testcase:

struct A { };
struct B { };

void f(A&&); // #1
void f(const B&) = delete; // #2

int main() {
  f({});
}

It seems Clang and MSVC consider the ICS for #1 to be better than that for #2,
but I'm not sure why.

According to http://eel.is/c++draft/over.ics.rank#3.3 the two ICSes should be
incomparable since they initialize different classes, so at least according to
that paragraph it appears GCC is behaving correctly here.

[Bug middle-end/102243] [12 Regression] ICE in get_range_query since r12-3300-gece28da924dd

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
get_range() calls get_range_query (cfun); the cfun pointer is null in this
context without optimization.

$ gcc -S -Wall pr102243.C
pr102243.C:12:47: internal compiler error: Segmentation fault
   12 |  new (s_message[1].s) int);
  |   ^~~
0x16e3bd6 crash_signal
/src/gcc/master/gcc/toplev.c:328
0x12161c8 get_range_query(function const*)
/src/gcc/master/gcc/function.h:728
0x19a7479 get_range(tree_node*, gimple*, generic_wide_int*,
range_query*)
/src/gcc/master/gcc/tree-ssa-strlen.c:211
0x15971d6 get_offset_range
/src/gcc/master/gcc/pointer-query.cc:91
0x159d0e4 handle_array_ref
/src/gcc/master/gcc/pointer-query.cc:1568
0x159e0da compute_objsize_r
/src/gcc/master/gcc/pointer-query.cc:1809
0x159dccf compute_objsize_r
/src/gcc/master/gcc/pointer-query.cc:1755
0x159f336 compute_objsize(tree_node*, int, access_ref*, range_query*)
/src/gcc/master/gcc/pointer-query.cc:2086
0xc194a0 warn_placement_new_too_small
/src/gcc/master/gcc/cp/init.c:2614
0xc1c06b build_new_1
/src/gcc/master/gcc/cp/init.c:3280
0xc1db04 build_new(unsigned int, vec**,
tree_node*, tree_node*, vec**, int, int)
/src/gcc/master/gcc/cp/init.c:3831
0xcfb261 cp_parser_new_expression
/src/gcc/master/gcc/cp/parser.c:9161
0xcf9ea5 cp_parser_unary_expression
/src/gcc/master/gcc/cp/parser.c:8613
0xcfbf67 cp_parser_cast_expression
/src/gcc/master/gcc/cp/parser.c:9795
0xcfc05a cp_parser_binary_expression
/src/gcc/master/gcc/cp/parser.c:9898
0xcfcea5 cp_parser_assignment_expression
/src/gcc/master/gcc/cp/parser.c:10203
0xcfd716 cp_parser_constant_expression
/src/gcc/master/gcc/cp/parser.c:10504
0xcf94b2 cp_parser_parenthesized_expression_list
/src/gcc/master/gcc/cp/parser.c:8306
0xd1bb63 cp_parser_initializer
/src/gcc/master/gcc/cp/parser.c:24953
0xd16c15 cp_parser_init_declarator
/src/gcc/master/gcc/cp/parser.c:22580
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

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

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

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

Bug 101936 Summary: [12 Regression] 538.imagick_r -Ofast regression on Kabylake 
since g:872da9a6f664a06d73c987aa0cb2e5b830158a10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101936

   What|Removed |Added

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

[Bug target/101936] [12 Regression] 538.imagick_r -Ofast regression on Kabylake since g:872da9a6f664a06d73c987aa0cb2e5b830158a10

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Liška  ---
The performance is back, thus closing..

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

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

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

Bug 101935 Summary: [12 Regression] 538.imagick_r LTO -Ofast regression on Zen2 
and Kabylake caused by r12-2666-g29f0e955c97
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101935

   What|Removed |Added

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

[Bug target/101935] [12 Regression] 538.imagick_r LTO -Ofast regression on Zen2 and Kabylake caused by r12-2666-g29f0e955c97

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
(In reply to Martin Jambor from comment #0)
> When compiled with -flto -Ofast -march=native, the benchmark
> 538.imagick_r is about 28% slower on AMD zen2 machines (see
> https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=287.507.0 )
> and about 18% slower on Intel Kabylake (see
> https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=11.507.0 )

Both testers are back regarding the speed. Thus I'm closing this issue..

[Bug c++/55203] No unused warning for variables of non-trivial types

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

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

Martin Sebor  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-09-15
 Status|UNCONFIRMED |NEW

--- Comment #22 from Martin Sebor  ---
Confirmed as a useful enhancement.

[Bug target/102351] error: ‘TARGET_PENTIUM4’ was not declared in this scope; did you mean ‘TARGET_ENQCMD’?

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Fixed now.

[Bug target/102351] error: ‘TARGET_PENTIUM4’ was not declared in this scope; did you mean ‘TARGET_ENQCMD’?

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

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

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

https://gcc.gnu.org/g:7bdf51557d18aafdb300e1ad2b4f6fb7ef456f2b

commit r12-3553-g7bdf51557d18aafdb300e1ad2b4f6fb7ef456f2b
Author: Martin Liska 
Date:   Wed Sep 15 17:45:21 2021 +0200

i386: port vxworks to TARGET_CPU_P macro

PR target/102351

gcc/ChangeLog:

* config/i386/vxworks.h: Use new macro TARGET_CPU_P.

[Bug tree-optimization/102329] pointer "maybe uninitialized" right after assignment

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

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

--- Comment #4 from Martin Sebor  ---
The text of the warning should be adjusted to make it clear that it's the
object the pointer points to that may be used uninitialized by the function. 
For functions like pthread_getspecific() and pthread_setspecific() that do not
access the object GCC provides attribute access none to suppress the warning:

  extern __attribute__ ((access (none, 1))) void f1 (const void *pointer);

[Bug target/102351] error: ‘TARGET_PENTIUM4’ was not declared in this scope; did you mean ‘TARGET_ENQCMD’?

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Oh, it's mine as it started with g:f23881fcf081a6edd538d6d54fa0068d716973d7.

[Bug target/102351] New: error: ‘TARGET_PENTIUM4’ was not declared in this scope; did you mean ‘TARGET_ENQCMD’?

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

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

Bug ID: 102351
   Summary: error: ‘TARGET_PENTIUM4’ was not declared in this
scope; did you mean ‘TARGET_ENQCMD’?
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: i686-wrs-vxworksae

The cross compiler build fails due to:

g++  -fno-PIE -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g   -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -Ic-family
-I/home/marxin/Programming/gcc/gcc -I/home/marxin/Programming/gcc/gcc/c-family
-I/home/marxin/Programming/gcc/gcc/../include
-I/home/marxin/Programming/gcc/gcc/../libcpp/include
-I/home/marxin/Programming/gcc/gcc/../libcody 
-I/home/marxin/Programming/gcc/gcc/../libdecnumber
-I/home/marxin/Programming/gcc/gcc/../libdecnumber/dpd -I../libdecnumber
-I/home/marxin/Programming/gcc/gcc/../libbacktrace   -o c-family/c-cppbuiltin.o
-MT c-family/c-cppbuiltin.o -MMD -MP -MF c-family/.deps/c-cppbuiltin.TPo
/home/marxin/Programming/gcc/gcc/c-family/c-cppbuiltin.c
In file included from ./tm.h:29,
 from /home/marxin/Programming/gcc/gcc/target.h:52,
 from
/home/marxin/Programming/gcc/gcc/c-family/c-cppbuiltin.c:23:
/home/marxin/Programming/gcc/gcc/c-family/c-cppbuiltin.c: In function ‘void
c_cpp_builtins(cpp_reader*)’:
/home/marxin/Programming/gcc/gcc/config/i386/vxworks.h:76:16: error:
‘TARGET_PENTIUM4’ was not declared in this scope; did you mean ‘TARGET_ENQCMD’?
   76 |   else if (TARGET_PENTIUM4) \
  |^~~
/home/marxin/Programming/gcc/gcc/c-family/c-cppbuiltin.c:1552:3: note: in
expansion of macro ‘TARGET_OS_CPP_BUILTINS’
 1552 |   TARGET_OS_CPP_BUILTINS ();
  |   ^~
/home/marxin/Programming/gcc/gcc/config/i386/vxworks.h:81:16: error:
‘TARGET_CORE2’ was not declared in this scope; did you mean ‘TARGET_SSE2’?
   81 |   else if (TARGET_CORE2)\
  |^~~~

[Bug target/102349] [12 Regression] crash in rs6000_xcoff_encode_section_info since r12-446-g8b5b814d51ff73bc739c0c037ae18df07acf2d96

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

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

--- Comment #7 from David Edelsohn  ---
As we discussed on IRC

symtab_node::exists (decl) && symtab_node::get (decl)->alias

seems better because that function does not need to create the summary for its
internal use.  The function should not encode the section info on an alias
because that creates conflicting AIX XCOFF encodings.

Thanks!

[Bug target/102349] [12 Regression] crash in rs6000_xcoff_encode_section_info since r12-446-g8b5b814d51ff73bc739c0c037ae18df07acf2d96

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Fixed.

[Bug target/102349] [12 Regression] crash in rs6000_xcoff_encode_section_info since r12-446-g8b5b814d51ff73bc739c0c037ae18df07acf2d96

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

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

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

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

commit r12-3551-gadddfc85c07143f7c8097a90a83bfb15b8bd52e8
Author: Martin Liska 
Date:   Wed Sep 15 17:19:58 2021 +0200

rs6000: fix symtab_node::get == NULL issue

PR target/102349

gcc/ChangeLog:

* config/rs6000/rs6000.c (rs6000_xcoff_encode_section_info):
Check that we have a symbol summary for a symbol.

[Bug middle-end/102337] bogus -Wformat-truncation due to incomplete sprintf/strlen integration

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

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

Martin Sebor  changed:

   What|Removed |Added

 Blocks||85741
Summary|possibly wrong warning  |bogus -Wformat-truncation
   |about truncation|due to incomplete
   ||sprintf/strlen integration

--- Comment #1 from Martin Sebor  ---
In the absence of data flow information -Wformat-truncation (and
-Wformat-overflow) uses the sizes of the arrays pointed to by arguments to the
%s directive as the upper bound of the lengths of the strings being formatted. 
In the test case in comment #0 the results of the first two snprintf calls
computed by GCC are discarded (not used for subsequent data flow analysis) and
so the warning assumes that the length of each of the two strings in the last
call to snprintf() is 127 and triggers.  To do better the warning needs to be
enhanced to feed the results of snprintf calls to the strlen pass so that they
are available when computing the lengths of strings in subsequent calls.  This
enhancement is the subject of pr92813 so this bug is effectively a duplicate of
that one.

(Replacing the first two snprintf calls with strcpy avoids the warning because
string lengths computed by GCC for arguments of strcpy calls are available to
the snprintf warning.)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741
[Bug 85741] [meta-bug] bogus/missing -Wformat-overflow

[Bug c++/102350] New: __builtin_source_location not available in earlier language modes

[pdimov at gmail dot com via Gcc-bugs]

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

Bug ID: 102350
   Summary: __builtin_source_location not available in earlier
language modes
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pdimov at gmail dot com
  Target Milestone: ---

Currently, `__builtin_source_location` requires (a) `` to be
included and (b) -std=c++20. Are there good reasons for these restrictions? The
builtin would still be extremely valuable in earlier language modes.

Libraries that still support 03/11/14/17 (Boost.System, for instance) could
transparently supply source locations by using a default `void const* loc =
__builtin_source_location()` argument.

[Bug target/102349] [12 Regression] crash in rs6000_xcoff_encode_section_info since r12-446-g8b5b814d51ff73bc739c0c037ae18df07acf2d96

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

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

--- Comment #4 from Martin Liška  ---
The following helps:

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index b0ec8108007..89868c39e27 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -21728,7 +21728,7 @@ rs6000_xcoff_encode_section_info (tree decl, rtx rtl,
int first)
   if (decl
   && DECL_P (decl)
   && VAR_OR_FUNCTION_DECL_P (decl)
-  && symtab_node::get (decl)->alias == 0
+  && symtab_node::get_create (decl)->alias == 0
   && symname[strlen (symname) - 1] != ']')
 {
   const char *smclass = NULL;

[Bug target/102349] [12 Regression] crash in rs6000_xcoff_encode_section_info since r12-446-g8b5b814d51ff73bc739c0c037ae18df07acf2d96

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

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

--- Comment #3 from Martin Liška  ---
(gdb) p symtab_node::get (decl)
$2 = 

[Bug target/102349] [12 Regression] crash in rs6000_xcoff_encode_section_info since r12-446-g8b5b814d51ff73bc739c0c037ae18df07acf2d96

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

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

--- Comment #2 from Martin Liška  ---
Sorry, the line numbers are wrong because I didn't use the vanilla repository.

So for a37d7d6fc1dbd9906bbb2c6bf5ba9d30fd17a584 I see:

/dev/shm/objdir2/./gcc/xgcc -B/dev/shm/objdir2/./gcc/ -xc -nostdinc /dev/null
-S -o /dev/null
-fself-test=/home/marxin/Programming/gcc/gcc/testsuite/selftests
/dev/null: internal compiler error: Segmentation fault
0x13ce86c crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:328
0x7786239f ???
../sysdeps/unix/sysv/linux/sigaction.c:10
0x19290ae rs6000_xcoff_encode_section_info
/home/marxin/Programming/gcc/gcc/config/rs6000/rs6000.c:21731
0x18a6e06 make_decl_rtl(tree_node*)
/home/marxin/Programming/gcc/gcc/varasm.c:1639
0x1202d5b init_one_libfunc_visibility(char const*, symbol_visibility)
/home/marxin/Programming/gcc/gcc/optabs-libfuncs.c:773
0x1202d86 init_one_libfunc(char const*)
/home/marxin/Programming/gcc/gcc/optabs-libfuncs.c:779
0x1202ec1 set_optab_libfunc(optab_tag, machine_mode, char const*)
/home/marxin/Programming/gcc/gcc/optabs-libfuncs.c:814
0x120316a init_optabs()
/home/marxin/Programming/gcc/gcc/optabs-libfuncs.c:886
0x13d204a lang_dependent_init_target
/home/marxin/Programming/gcc/gcc/toplev.c:1869
0x13d2317 lang_dependent_init
/home/marxin/Programming/gcc/gcc/toplev.c:1955
0x13d2bee do_compile
/home/marxin/Programming/gcc/gcc/toplev.c:2218

 21728if (decl
 21729&& DECL_P (decl)
 21730&& VAR_OR_FUNCTION_DECL_P (decl)
 21731&& symtab_node::get (decl)->alias == 0
 21732&& symname[strlen (symname) - 1] != ']')
 21733  {

and valgrind tells:

==31369== Invalid read of size 1
==31369==at 0x19290AE: rs6000_xcoff_encode_section_info(tree_node*,
rtx_def*, int) (rs6000.c:21731)
==31369==by 0x18A6E06: make_decl_rtl(tree_node*) (varasm.c:1639)
==31369==by 0x1202D5B: init_one_libfunc_visibility(char const*,
symbol_visibility) (optabs-libfuncs.c:773)
==31369==by 0x1202D86: init_one_libfunc(char const*)
(optabs-libfuncs.c:779)
==31369==by 0x1202EC1: set_optab_libfunc(optab_tag, machine_mode, char
const*) (optabs-libfuncs.c:814)
==31369==by 0x120316A: init_optabs() (optabs-libfuncs.c:886)
==31369==by 0x13D204A: lang_dependent_init_target() (toplev.c:1869)
==31369==by 0x13D2317: lang_dependent_init(char const*) (toplev.c:1955)
==31369==by 0x13D2BEE: do_compile() (toplev.c:2218)
==31369==by 0x13D2FEC: toplev::main(int, char**) (toplev.c:2372)
==31369==by 0x249BF5F: main (main.c:39)
==31369==  Address 0x2 is not stack'd, malloc'd or (recently) free'd

[Bug target/102349] [12 Regression] crash in rs6000_xcoff_encode_section_info since r12-446-g8b5b814d51ff73bc739c0c037ae18df07acf2d96

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

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

--- Comment #1 from David Edelsohn  ---
I can't duplicate this failure in a native build.  And rs6000.c:21750 doesn't
correspond to any statement.  Can you provide some additional information or
source code context?

rs6000_xcoff_encode_section_info() could be missing some decl validation, but I
cannot reproduce it myself.

[Bug target/102349] [12 Regression] crash in rs6000_xcoff_encode_section_info since r12-446-g8b5b814d51ff73bc739c0c037ae18df07acf2d96

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-15
   Target Milestone|--- |12.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug target/102349] New: [12 Regression] crash in rs6000_xcoff_encode_section_info since r12-446-g8b5b814d51ff73bc739c0c037ae18df07acf2d96

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

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

Bug ID: 102349
   Summary: [12 Regression] crash in
rs6000_xcoff_encode_section_info since
r12-446-g8b5b814d51ff73bc739c0c037ae18df07acf2d96
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: dje at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: powerpc-ibm-aix7.2

The built compiler crashes:

/dev/shm/objdir2/./gcc/xgcc -B/dev/shm/objdir2/./gcc/ -xc -nostdinc /dev/null
-S -o /dev/null
-fself-test=/home/marxin/Programming/gcc/gcc/testsuite/selftests
/dev/null: internal compiler error: Segmentation fault
0x134008e crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:327
0x7786239f ???
../sysdeps/unix/sysv/linux/sigaction.c:10
0x187ab08 rs6000_xcoff_encode_section_info
/home/marxin/Programming/gcc/gcc/config/rs6000/rs6000.c:21750
0x17f9e60 make_decl_rtl(tree_node*)
/home/marxin/Programming/gcc/gcc/varasm.c:1639
0x1181bdb init_one_libfunc_visibility(char const*, symbol_visibility)
/home/marxin/Programming/gcc/gcc/optabs-libfuncs.c:773
0x1181c06 init_one_libfunc(char const*)
/home/marxin/Programming/gcc/gcc/optabs-libfuncs.c:779
0x1181d41 set_optab_libfunc(optab_tag, machine_mode, char const*)
/home/marxin/Programming/gcc/gcc/optabs-libfuncs.c:814
0x1181fea init_optabs()
/home/marxin/Programming/gcc/gcc/optabs-libfuncs.c:886
0x13437ac lang_dependent_init_target
/home/marxin/Programming/gcc/gcc/toplev.c:1837
0x1343a79 lang_dependent_init
/home/marxin/Programming/gcc/gcc/toplev.c:1923
0x1344350 do_compile
/home/marxin/Programming/gcc/gcc/toplev.c:2186
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[2]: *** [/home/marxin/Programming/gcc/gcc/c/Make-lang.in:127:
s-selftest-c] Error 1
make[2]: Leaving directory '/dev/shm/objdir2/gcc'
make[1]: *** [Makefile:4412: all-gcc] Error 2
make[1]: Leaving directory '/dev/shm/objdir2'
make: *** [Makefile:942: all] Error 2

[Bug target/102348] error: #error You must define PREFERRED_DEBUGGING_TYPE

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/102348] error: #error You must define PREFERRED_DEBUGGING_TYPE

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

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

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

https://gcc.gnu.org/g:26d4ba05b92d0082c7db8067021e9b3109400557

commit r12-3548-g26d4ba05b92d0082c7db8067021e9b3109400557
Author: Richard Biener 
Date:   Wed Sep 15 16:01:44 2021 +0200

target/102348 - fix powerpc-lynxos build

This fixes a similar issue for powerpc-lynxos as fixed for i686-lynxos
already.

2021-09-15  Richard Biener  

PR target/102348
* config/rs6000/lynx.h: Remove undef of PREFERRED_DEBUGGING_TYPE
to inherit from elfos.h