[Bug c++/64961] nested template implementation crossing namespace fails with access error

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Confirmed. I think GCC is doing access checks too soon in this case. 

For a function definition, I don't think access checking applies.

bar::Bar::Ba::Fo::foo is the same as
Foo<1>::Fo::foo which should be valid to define in the foo namespace.
ICC, clang and MSVC all accept the code.

[Bug c++/67012] decltype(auto) with trailing return type

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug c++/51501] [DR 1433] decltype over-agressive SFINAE

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|SUSPENDED   |NEW
  Known to fail||7.5.0
   Keywords||accepts-invalid,
   ||needs-bisection
  Known to work||8.1.0

--- Comment #14 from Andrew Pinski  ---
(In reply to Jonathan Wakely from comment #13)
> And maybe issue a diagnostic for comment 12, as EDG and clang do?

We started to reject comment #12 in GCC 8+.

[Bug c++/60625] attributes on template member function definition inside class definition not supported

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-12-10
 Ever confirmed|0   |1
   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW

--- Comment #4 from Andrew Pinski  ---
Confirmed, the non-template case should have been rejected.

Note if you use the C++11 style attribute [[gnu::always_inline]], GCC does warn
about it when used after the function declaration and such.

[Bug c++/48518] Inconsistent instantiation behavior depending on operator overloading

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=42260
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Andrew Pinski  ---
GCC, ICC, MSVC and clang all agree here with the post GCC 4.5.x behavior.
So closing as invalid.

[Bug c++/42355] Segmentation fault

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2010-01-04 19:39:44 |2021-12-9
  Known to fail||

--- Comment #14 from Andrew Pinski  ---
Interesting clang is able to compile this reasonably but GCC and ICC have a
hard time.

[Bug c++/31164] Problem with GCC 4.1 and Boost signals

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #11 from Andrew Pinski  ---
The original issue was fixed upstream in boost 1.34 (according to the opensuse
bug). So closing as moved. The sourceforge bug link for boost does not work any
more.

[Bug target/99932] OpenACC/nvptx offloading execution regressions starting with CUDA 11.2-era Nvidia Driver 460.27.04

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

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

--- Comment #7 from Tom de Vries  ---
(In reply to Tom de Vries from comment #6)
> (In reply to Tom de Vries from comment #5)
> > FIled https://developer.nvidia.com/nvidia_bug/3299227
> 
> Nvidia reported it will be fixed in the next major cuda release. I've asked
> about driver fixes.

I've tested 470.86, and can confirm that the failure as reported to nvidia has
disappeared.

However, the example from comment 2 still passes with GOMP_NVPTX_JIT=-O0, and
starts failing at GOMP_NVPTX_JIT=-O1.

So it looks like we'll need to file another bug-report at nvidia.

[Bug c++/87656] Useful flags to enable with -Wall or -Wextra

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

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

--- Comment #10 from Eric Gallager  ---
(In reply to Segher Boessenkool from comment #9)
> (In reply to Eric Gallager from comment #8)
> > Any reason not to put -Wnested-externs in -Wall or -Wextra?
> 
> It warns for any "extern" declaration in other than file scope.  This is
> completely standard C, and useful as well.
> 
> It is harmful to warn about idiomatic code, especially if there is no real
> alternative.
> 
> I don't think anyone will accidentally do this either (you don't type
> "extern" if you don't mean it, after all).
> 
> Do you have any example where this warning helped you find a bug?

It may have been idiomatic 30 years ago, but it isn't any longer. And there's
an easy alternative: just move the declaration out of the function and up to
file scope. It makes more sense that way and looks better. Or, better yet,
include the proper header file for the extern declaration. Most instances I've
seen of the warning have been stuff like people putting "extern int errno"
inside of a function instead of realizing that they're supposed to just do
#include  instead (possibly because the code is from before the header
was standardized?). In the errno case it's particularly harmful because errno
may be defined as a macro that's incompatible with the declaration being used.

[Bug d/103529] [12 regression] d21 SIGBUS on SPARC

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #4 from Iain Buclaw  ---
Fix committed.

[Bug d/103529] [12 regression] d21 SIGBUS on SPARC

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

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

commit r12-5887-g9c7d5e8846edb28e5421211ee8eaad93e234de2c
Author: Iain Buclaw 
Date:   Fri Dec 10 03:14:20 2021 +0100

d: Merge upstream dmd 3982604c5, druntime bc58b1e9, phobos 12329adb6.

D front-end changes:

- Import dmd mainline development.
- Split off enum EXP from enum TOK.
- Integer promotions now follow C integral promotions by default.
- Implements __traits(initSymbol).
- Lowering of array construction has been moved to the dmd
  front-end.
- Fix segfault in dmd.lexer from unaligned read (PR103529).

Druntime changes:

- Import druntime mainline development.
- Define SIG_BLOCK for Solaris (PR103528).

Phobos changes:

- Import phobos mainline development.

gcc/d/ChangeLog:

PR d/103529
* dmd/MERGE: Merge upstream dmd 3982604c5.
* Make-lang.in (D_FRONTEND_OBJS): Add d/root-optional.o.
* d-attribs.cc (build_attributes): Update for new front-end
interface.
* d-codegen.cc (d_build_call): Likewise.
* d-compiler.cc (Compiler::paintAsType): Likewise.
* d-lang.cc (d_handle_option): Remove OPT_fpreview_intpromote, add
handling of OPT_frevert_intpromote.
* d-port.cc (Port::valcpy): Assert buffer is aligned.
* d-target.cc (Target::isVectorOpSupported): Update for new
front-end
interface.
* decl.cc (layout_class_initializer): Likewise.
* expr.cc (lvalue_p): Likewise.
(binop_assignment): Likewise.
(ExprVisitor::visit): Likewise.
(ExprVisitor::visit (AssignExp *)): Remove generation of
_d_arrayctor
and _d_arraysetctor library helpers.
(ExprVisitor::visit (VarExp *)): Support __traits(initSymbol).
* intrinsics.cc (expand_intrinsic_rotate): Update for new front-end
interface.
* lang.opt (fpreview=intpromote): Remove.
(frevert=intpromote): New.
* runtime.def (ARRAYCTOR): Remove.
(ARRAYSETCTOR): Remove.
* toir.cc (IRVisitor::visit): Update for new front-end interface.
* types.cc (layout_aggregate_members): Likewise.
* dmd/root/optional.d: New file.
* dmd/root/optional.h: New file.

libphobos/ChangeLog:

PR d/103528
* libdruntime/MERGE: Merge upstream druntime bc58b1e9.
* libdruntime/Makefile.am (DRUNTIME_DSOURCES_LINUX): Remove
core/sys/linux/syscalls.d.
* libdruntime/Makefile.in: Regenerate.
* src/MERGE: Merge upstream phobos 12329adb6.
* testsuite/libphobos.config/config.exp: Add test22523.
* libdruntime/core/sys/linux/syscalls.d: Removed.
* testsuite/libphobos.config/test22523.d: New test.

[Bug d/103528] [12 regression] d21 doesn't build on Solaris

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

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

commit r12-5887-g9c7d5e8846edb28e5421211ee8eaad93e234de2c
Author: Iain Buclaw 
Date:   Fri Dec 10 03:14:20 2021 +0100

d: Merge upstream dmd 3982604c5, druntime bc58b1e9, phobos 12329adb6.

D front-end changes:

- Import dmd mainline development.
- Split off enum EXP from enum TOK.
- Integer promotions now follow C integral promotions by default.
- Implements __traits(initSymbol).
- Lowering of array construction has been moved to the dmd
  front-end.
- Fix segfault in dmd.lexer from unaligned read (PR103529).

Druntime changes:

- Import druntime mainline development.
- Define SIG_BLOCK for Solaris (PR103528).

Phobos changes:

- Import phobos mainline development.

gcc/d/ChangeLog:

PR d/103529
* dmd/MERGE: Merge upstream dmd 3982604c5.
* Make-lang.in (D_FRONTEND_OBJS): Add d/root-optional.o.
* d-attribs.cc (build_attributes): Update for new front-end
interface.
* d-codegen.cc (d_build_call): Likewise.
* d-compiler.cc (Compiler::paintAsType): Likewise.
* d-lang.cc (d_handle_option): Remove OPT_fpreview_intpromote, add
handling of OPT_frevert_intpromote.
* d-port.cc (Port::valcpy): Assert buffer is aligned.
* d-target.cc (Target::isVectorOpSupported): Update for new
front-end
interface.
* decl.cc (layout_class_initializer): Likewise.
* expr.cc (lvalue_p): Likewise.
(binop_assignment): Likewise.
(ExprVisitor::visit): Likewise.
(ExprVisitor::visit (AssignExp *)): Remove generation of
_d_arrayctor
and _d_arraysetctor library helpers.
(ExprVisitor::visit (VarExp *)): Support __traits(initSymbol).
* intrinsics.cc (expand_intrinsic_rotate): Update for new front-end
interface.
* lang.opt (fpreview=intpromote): Remove.
(frevert=intpromote): New.
* runtime.def (ARRAYCTOR): Remove.
(ARRAYSETCTOR): Remove.
* toir.cc (IRVisitor::visit): Update for new front-end interface.
* types.cc (layout_aggregate_members): Likewise.
* dmd/root/optional.d: New file.
* dmd/root/optional.h: New file.

libphobos/ChangeLog:

PR d/103528
* libdruntime/MERGE: Merge upstream druntime bc58b1e9.
* libdruntime/Makefile.am (DRUNTIME_DSOURCES_LINUX): Remove
core/sys/linux/syscalls.d.
* libdruntime/Makefile.in: Regenerate.
* src/MERGE: Merge upstream phobos 12329adb6.
* testsuite/libphobos.config/config.exp: Add test22523.
* libdruntime/core/sys/linux/syscalls.d: Removed.
* testsuite/libphobos.config/test22523.d: New test.

[Bug middle-end/100786] [9/10/11/12 Regression] ICE: in fold_convert_loc with alias attribute and different types and different sizes

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-12-10
   Target Milestone|--- |9.5
  Known to fail||11.1.0, 4.9.0, 5.1.0
  Known to work||4.7.1, 4.8.5
 Ever confirmed|0   |1
Summary|ICE: in fold_convert_loc|[9/10/11/12 Regression]
   |with alias attribute and|ICE: in fold_convert_loc
   |different types and |with alias attribute and
   |different sizes |different types and
   ||different sizes

--- Comment #2 from Andrew Pinski  ---
Can also reproduce using the following code with the C++ front-end:
extern const double a = 0;
extern int b __attribute__((alias("a")));
int inc() { b++; }

Confirmed.  I think the alias should be rejected if the following is true:
(TREE_CODE (a) == FUNCTION_DECL) != (TREE_CODE (b) == FUNCTION_DECL)
|| (sizeof (a) != sizeof (b))

[Bug target/103623] [12 Regression] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
Summary|error: unable to generate   |[12 Regression] error:
   |reloads (ICE in |unable to generate reloads
   |curr_insn_transform, at |(ICE in
   |lra-constraints.c:4132), or |curr_insn_transform, at
   |error: insn does not|lra-constraints.c:4132), or
   |satisfy its constraints |error: insn does not
   |(ICE in |satisfy its constraints
   |extract_constrain_insn_cach |(ICE in
   |ed, at recog.c:2682)|extract_constrain_insn_cach
   ||ed, at recog.c:2682)

[Bug libgcc/103510] _Unwind_GetGR crashed for uninitialized registers

[ashimida at linux dot alibaba.com via Gcc-bugs]

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

--- Comment #5 from ashimida  ---
(In reply to Andrew Pinski from comment #3)
> The only registers which are saved are the callee saved register IIRC. So
> you need to know the ABI.

Hi Andrew,

Is it reasonable to save all registers (include callee-used registers) at
the entry of functions such as _Unwind_Backtrace/_Unwind_RaiseException
(through a change in uw_init_context)?  

Then all registers will have initial values and will not affect the
execution of .cfi directives. I think this would not violate the 
IA-64 C++ ABI.

I'd like to add a patch for this if it sounds reasonable.

Thanks,
Dan

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

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

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Thomas Rodgers
:

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

commit r11-9371-gaca7d4e8790bff32ee749936bb0224d873c46052
Author: Thomas Rodgers 
Date:   Thu Dec 9 15:35:25 2021 -0800

libstdc++: Make atomic::wait() const [PR102994]

This was an oversight in the original commit adding wait/notify
to atomic.

libstdc++-v3/ChangeLog:

PR libstdc++/102994
* include/bits/atomic_base.h (__atomic_base<_PTp*>::wait()):
Add const qualifier.
* include/std/atomic (atomic<_Tp*>::wait(), atomic_wait()):
Likewise.
* testsuite/29_atomics/atomic/wait_notify/102994.cc:
New test.

(cherry picked from commit 38c60e5075f89265a560eab166d43247624a7535)

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

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Thomas Rodgers :

https://gcc.gnu.org/g:38c60e5075f89265a560eab166d43247624a7535

commit r12-5886-g38c60e5075f89265a560eab166d43247624a7535
Author: Thomas Rodgers 
Date:   Thu Dec 9 15:35:25 2021 -0800

libstdc++: Make atomic::wait() const [PR102994]

This was an oversight in the original commit adding wait/notify
to atomic.

libstdc++-v3/ChangeLog:

PR libstdc++/102994
* include/bits/atomic_base.h (__atomic_base<_PTp*>::wait()):
Add const qualifier.
* include/std/atomic (atomic<_Tp*>::wait(), atomic_wait()):
Likewise.
* testsuite/29_atomics/atomic/wait_notify/102994.cc:
New test.

[Bug c/103640] asm goto w/ outputs numbering with tied outputs differs from clang

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Nick Desaulniers from comment #0)
> While we can change this in clang (https://reviews.llvm.org/D115471), I do
> think it would be more ergonomic for developers if the order of operands for
> the outputs templates matched the order of the asm operands.  

It is kinda of odd that there is no associated documentation change when you
submit a clang change like this too 

[Bug target/103623] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain_insn_cached, at

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

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

Kewen Lin  changed:

   What|Removed |Added

 CC||linkw at gcc dot gnu.org

--- Comment #1 from Kewen Lin  ---
Thanks for reporting this as well as PR103622.

Confirmed.  It's starting to fail from r12-5752, but isn't a dup of PR103622.

With r12-5751, we will get the error messages like:

test.c: In function ‘main’:
test.c:2:16: error: ‘__builtin_unpack_longdouble’ requires the
‘-mlong-double-128’ option
2 | #define UNPACK __builtin_unpack_longdouble
  |^
test.c:11:15: note: in expansion of macro ‘UNPACK’
   11 |   double x0 = UNPACK (a, 0);
  |   ^~

In the previous bif support, __builtin_{pack,unpack}_longdouble are guarded
with bif mask (RS6000_BTM_HARD_FLOAT | RS6000_BTM_LDBL128), but new bif support
puts them under "always" stanza.

One fix seems to introduce one stanza for 128bit long double like previous
RS6000_BTM_LDBL128 which is enabled only if (TARGET_LONG_DOUBLE_128 &&
TARGET_HARD_FLOAT && !TARGET_IEEEQUAD), and guard
__builtin_{pack,unpack}_longdouble under this new stanza.

I also noticed that there also is a TODO for long double vs. ibm128.

[Bug c/103640] asm goto w/ outputs numbering with tied outputs differs from clang

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

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

--- Comment #2 from Andrew Pinski  ---
Since the feature of out inline-asm with gotos was added in GCC 11, the manual
has always been clear for released versions of GCC with the support for it.

[Bug inline-asm/98096] Inconsistent operand numbering for asm goto with in-out operands

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||ndesaulniers at google dot com

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

[Bug c/103640] asm goto w/ outputs numbering with tied outputs differs from clang

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
The GCC manual
(https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Extended-Asm.html#Goto-Labels)
is now clear here:
To reference a label in the assembler template, prefix it with ‘%l’ (lowercase
‘L’) followed by its (zero-based) position in GotoLabels plus the number of
input and output operands. Output operand with constraint modifier ‘+’ is
counted as two operands because it is considered as one output and one input
operand. For example, if the asm has three inputs, one output operand with
constraint modifier ‘+’ and one output operand with constraint modifier ‘=’ and
references two labels, refer to the first label as ‘%l6’ and the second as
‘%l7’).

And has been clear since GCC 11.1.0.
This is a dup of bug 98096 which changed the manual in Feburary.

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

[Bug objc/103639] [REGRESSION] GCC 11.2 (or even earlier) breaks switch case with break in fast enumeration loop

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||iains at gcc dot gnu.org,
   ||mikestump at comcast dot net

--- Comment #5 from Eric Gallager  ---
cc-ing objc maintainers

[Bug c/103640] New: asm goto w/ outputs numbering with tied outputs differs from clang

[ndesaulniers at google dot com via Gcc-bugs]

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

Bug ID: 103640
   Summary: asm goto w/ outputs numbering with tied outputs
differs from clang
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ndesaulniers at google dot com
CC: foom at fuhm dot net, segher at gcc dot gnu.org, vmakarov 
at redhat dot com
  Target Milestone: ---

Consider the following input:

void *x(void) {
  void *p = &
  asm goto ("# %0\n\t# %l1":"+r"(p):::foo);
  foo:;
  return p;
}

%0 refers to the 0th operand `p`.
%l1 refers to the 1st operand `foo`.

This code compiles in Clang, but not GCC.

If you change %l1 to %l2, that will compile in GCC but not clang.

Because +r constraint is being used, I suspect there's a hidden input being
tied to the output.

While we can change this in clang (https://reviews.llvm.org/D115471), I do
think it would be more ergonomic for developers if the order of operands for
the outputs templates matched the order of the asm operands.  Otherwise,
developers need to understand hidden inputs, or use symbolic names like:

asm goto ("# %0\n\t# %l[foo]":"+r"(p):::foo);

I suspect there's not enough users yet of asm goto w/ outputs to notice such a
change, either way.

[Bug fortran/56670] Allocatable-length character var causes bogus warning with -Wuninitialized

[vivekrao4 at yahoo dot com via Gcc-bugs]

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

Vivek Rao  changed:

   What|Removed |Added

 CC||vivekrao4 at yahoo dot com

--- Comment #13 from Vivek Rao  ---
Many warnings that I think are spurious for the code

program main
implicit none
character (len=:), allocatable :: words(:)
words = ["dog","cat"]
print*,words
end program main

compiled with gfortran -Wall xalloc_char.f90
using GNU Fortran (GCC) 12.0.0 20211024 (experimental) from equation.com on
Windows gives

xalloc_char.f90:3:42:

3 | character (len=:), allocatable :: words(:)
  |  ^
Warning: '.words' is used uninitialized [-Wuninitialized]
xalloc_char.f90:1:12:

1 | program main
  |^
note: '.words' was declared here
xalloc_char.f90:4:21:

4 | words = ["dog","cat"]
  | ^
Warning: 'words.offset' is used uninitialized [-Wuninitialized]
xalloc_char.f90:3:42:

3 | character (len=:), allocatable :: words(:)
  |  ^
note: 'words' declared here
xalloc_char.f90:4:21:

4 | words = ["dog","cat"]
  | ^
Warning: 'words.dim[0].lbound' is used uninitialized [-Wuninitialized]
xalloc_char.f90:3:42:

3 | character (len=:), allocatable :: words(:)
  |  ^
note: 'words' declared here
xalloc_char.f90:4:21:

4 | words = ["dog","cat"]
  | ^
Warning: 'words.dim[0].ubound' is used uninitialized [-Wuninitialized]
xalloc_char.f90:3:42:

3 | character (len=:), allocatable :: words(:)
  |  ^
note: 'words' declared here
xalloc_char.f90:4:21:

4 | words = ["dog","cat"]
  | ^
Warning: 'words.dim[0].lbound' may be used uninitialized
[-Wmaybe-uninitialized]
xalloc_char.f90:3:42:

3 | character (len=:), allocatable :: words(:)
  |  ^
note: 'words' declared here
xalloc_char.f90:4:21:

4 | words = ["dog","cat"]
  | ^
Warning: 'words.dim[0].ubound' may be used uninitialized
[-Wmaybe-uninitialized]
xalloc_char.f90:3:42:

3 | character (len=:), allocatable :: words(:)
  |  ^
note: 'words' declared here
xalloc_char.f90:4:21:

4 | words = ["dog","cat"]
  | ^
Warning: 'words.dim[0].ubound' may be used uninitialized
[-Wmaybe-uninitialized]
xalloc_char.f90:3:42:

3 | character (len=:), allocatable :: words(:)
  |  ^
note: 'words' declared here
xalloc_char.f90:4:21:

4 | words = ["dog","cat"]
  | ^
Warning: 'words.dim[0].lbound' may be used uninitialized
[-Wmaybe-uninitialized]
xalloc_char.f90:3:42:

3 | character (len=:), allocatable :: words(:)
  |  ^
note: 'words' declared here

[Bug c++/67491] [meta-bug] concepts issues

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

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

Bug 71174 Summary: [concepts] Segmentation fault while processing concepts error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71174

   What|Removed |Added

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

[Bug c++/71174] [concepts] Segmentation fault while processing concepts error

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
Closing as the patch is specifically about self-recursive concept
(satisfaction).

[Bug target/103635] size_t and uintptr_t have wrong sizes with x86_64-w64-mingw32-g++ -mabi=sysv

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2021-12-10

--- Comment #5 from Andrew Pinski  ---
My bet it is a bug in the stddef.h header file.
Can you do the following:
x86_64-w64-mingw32-g++ -mabi=sysv -c tmp.cpp -save-temps -g3

and attach the preprocessed source?

[Bug c++/71982] Wrong error and note range with macro

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

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

--- Comment #3 from Andrew Pinski  ---
Trunk gives:
[apinski@xeond2 src]$ ~/upstream-gcc/bin/gcc t.cc
t.cc: In instantiation of ‘bool operator==(const A&, const A&) [with T =
const B]’:
t.cc:25:30:   required from here
t.cc:1:34: error: no match for ‘operator==’ (operand types are ‘const B’ and
‘const B’)
1 | #define MACRO(left, right) *left == *right
  |  ^
t.cc:15:10: note: in expansion of macro ‘MACRO’
   15 |   return MACRO(_left, _right);
  |  ^
t.cc:10:6: note: candidate: ‘template bool operator==(const A&,
const A&)’
   10 | bool operator==(const A& left, const A& right)
  |  ^~~~
t.cc:10:6: note:   template argument deduction/substitution failed:
t.cc:1:34: note:   ‘const B’ is not derived from ‘const A’
1 | #define MACRO(left, right) *left == *right
  |  ^
t.cc:15:10: note: in expansion of macro ‘MACRO’
   15 |   return MACRO(_left, _right);
  |  ^
t.cc:24:6: note: candidate: ‘bool operator==(C&, C&)’
   24 | bool operator==(C& left, C& right) {
  |  ^~~~
t.cc:24:20: note:   no known conversion for argument 1 from ‘const B’ to ‘C&’
   24 | bool operator==(C& left, C& right) {
  | ~~~^~~~


Which looks fine.
While GCC 10.1.0 gives:
t.cc: In instantiation of 'bool operator==(const A&, const A&) [with T =
const B]':
t.cc:25:30:   required from here
t.cc:1:34: error: no match for 'operator==' (operand types are 'const B' and
'const B')
1 | #define MACRO(left, right) *left == *right
  |~~^
2 |
  |
3 | template 
  | ~
4 | struct A {


This is on the same machine. This happens on both aarch64 and x86_64.
The problem is not the code is being rejected (correctly) but the warning
location includes so much more than it should in previous versions of GCC.

[Bug target/103635] size_t and uintptr_t have wrong sizes with x86_64-w64-mingw32-g++ -mabi=sysv

[mark at harmstone dot com via Gcc-bugs]

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

--- Comment #4 from Mark Harmstone  ---
Thanks, but I mentioned  just to illustrate that this isn't purely a
hypothetical bug.

[Bug target/103635] size_t and uintptr_t have wrong sizes with x86_64-w64-mingw32-g++ -mabi=sysv

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

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

--- Comment #3 from Jonathan Wakely  ---
There's an explicit instantiation declaration at the end of the header, which
means the entire thing is externally defined in libstdc++.so and the only code
that gets instantiated in your own translation unit is for tiny functions which
are inlined. The rest will refer to the extern template definitions in the
shared library.

[Bug middle-end/103637] [12 Regression] missing warning writing past the end of one of multiple elements of the same array

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug ipa/103636] [12 Regression] Clang build fails with -flto -fno-strict-aliaisng -flifetime-dse=1 -fprofile-generate

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |12.0
Summary|Clang build fails with  |[12 Regression] Clang build
   |-flto -fno-strict-aliaisng  |fails with -flto
   |-flifetime-dse=1|-fno-strict-aliaisng
   |-fprofile-generate  |-flifetime-dse=1
   ||-fprofile-generate

[Bug libstdc++/103638] [11/12 Regression] #include gives errors for --disable-threads builds

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.3

[Bug libstdc++/103382] condition_variable::wait() is not cancellable because it is marked noexcept

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

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

--- Comment #6 from Jonathan Wakely  ---
The incorrect noexcept is fixed for GCC 12, but isn't suitable to backport.

For the branches we should consider disabling cancellation as suggested in
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586406.html

[Bug libstdc++/85813] make_exception_ptr should support __cxa_init_primary_exception path even with -fno-exceptions

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #11 from Jonathan Wakely  ---
Implemented for GCC 12.

[Bug libstdc++/59769] please add ios_base::__noreplace

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
Implemented for GCC 12.

[Bug libstdc++/92300] Useless allocator call in std::map, when insert does not perform any insertion.

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Implemented for GCC 12.

[Bug libstdc++/103630] [9/10/11 Regression] std::make_exception_ptr(t) is ill-formed

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

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[9/10/11/12 Regression] |[9/10/11 Regression]
   |std::make_exception_ptr |std::make_exception_ptr
   |(t) is ill-formed   |(t) is ill-formed

--- Comment #3 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug libstdc++/64135] Allocator base classes should use reserved names

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Fixed for GCC 12, not suitable for backports.

[Bug libstdc++/68297] Faster std::make_exception

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

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

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

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

commit r12-5880-ga8e02a00a0fcac42657c8ef7921566e42db8ef49
Author: Jonathan Wakely 
Date:   Thu Dec 9 18:37:38 2021 +

libstdc++: Make std::make_exception_ptr work with -fno-exceptions [PR85813]

This allows std::make_exception_ptr to be used in a translation unit
compiled with -fno-exceptions. This works because the new implementation
added for PR 68297 doesn't need to throw or catch anything. The catch is
there to handle exceptions from the constructor of the exception object,
which we can assume won't happen in a -fno-exceptions TU and so use the
__catch macro instead. If the constructor does throw (because it's
defined in a different TU which was compiled with exceptions enabled)
then that exception will propagate to the make_exception_ptr caller.
That seems acceptable for a program that is trying to mix & match TUs
compiled with and without exceptions, and using types that throw when
constructed. That should be rare, and can't reasonably be expected to
have sensible behaviour.

This also enables the new implementation for targets that use a
non-standard calling convention for the exceptionDestructor callback
(specifically, mingw, which uses __thiscall). All we need to do is mark
the __dest_thunk function template with the right calling convention.

Finally, the useless no-op definition of make_exception_ptr (which is
only used if both RTTI and exceptions are disabled) is marked
always_inline, to ensure that the linker won't keep that definition and
discard the functional ones when both definitions of the function are
present in the link. An alternative would be to add the abi_tag
attribute to the useless definition, but making it always_inline should
work, and it's small enough to always be inlined reliably.

libstdc++-v3/ChangeLog:

PR libstdc++/85813
* libsupc++/exception_ptr.h (__dest_thunk): Add macro for
destructor calling convention.
(make_exception_ptr): Enable non-throwing implementation for
-fno-exceptions and for non-standard calling conventions. Use
always_inline attribute on the useless no-rtti no-exceptions
definition.
* testsuite/18_support/exception_ptr/64241.cc: Add -fno-rtti so
the no-op implementation is still used.

[Bug libstdc++/85813] make_exception_ptr should support __cxa_init_primary_exception path even with -fno-exceptions

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

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

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

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

commit r12-5880-ga8e02a00a0fcac42657c8ef7921566e42db8ef49
Author: Jonathan Wakely 
Date:   Thu Dec 9 18:37:38 2021 +

libstdc++: Make std::make_exception_ptr work with -fno-exceptions [PR85813]

This allows std::make_exception_ptr to be used in a translation unit
compiled with -fno-exceptions. This works because the new implementation
added for PR 68297 doesn't need to throw or catch anything. The catch is
there to handle exceptions from the constructor of the exception object,
which we can assume won't happen in a -fno-exceptions TU and so use the
__catch macro instead. If the constructor does throw (because it's
defined in a different TU which was compiled with exceptions enabled)
then that exception will propagate to the make_exception_ptr caller.
That seems acceptable for a program that is trying to mix & match TUs
compiled with and without exceptions, and using types that throw when
constructed. That should be rare, and can't reasonably be expected to
have sensible behaviour.

This also enables the new implementation for targets that use a
non-standard calling convention for the exceptionDestructor callback
(specifically, mingw, which uses __thiscall). All we need to do is mark
the __dest_thunk function template with the right calling convention.

Finally, the useless no-op definition of make_exception_ptr (which is
only used if both RTTI and exceptions are disabled) is marked
always_inline, to ensure that the linker won't keep that definition and
discard the functional ones when both definitions of the function are
present in the link. An alternative would be to add the abi_tag
attribute to the useless definition, but making it always_inline should
work, and it's small enough to always be inlined reliably.

libstdc++-v3/ChangeLog:

PR libstdc++/85813
* libsupc++/exception_ptr.h (__dest_thunk): Add macro for
destructor calling convention.
(make_exception_ptr): Enable non-throwing implementation for
-fno-exceptions and for non-standard calling conventions. Use
always_inline attribute on the useless no-rtti no-exceptions
definition.
* testsuite/18_support/exception_ptr/64241.cc: Add -fno-rtti so
the no-op implementation is still used.

[Bug libstdc++/103630] [9/10/11/12 Regression] std::make_exception_ptr(t) is ill-formed

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

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

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

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

commit r12-5879-ga1ca039fc0fe934ef36c25d8284e6e116bcaffa7
Author: Jonathan Wakely 
Date:   Thu Dec 9 13:54:39 2021 +

libstdc++: Fix std::exception_ptr regressions [PR103630]

This restores support for std::make_exception_ptr and for using
std::exception_ptr in C++98.

Because the new non-throwing implementation needs to use std::decay to
handle references the original throwing implementation is used for
C++98.

We also need to change the typeid expression so it doesn't yield the
dynamic type when the function parameter is a reference to a polymorphic
type. Otherwise the new exception object could be caught by any handler
matching the dynamic type, even though the actual exception object is
only a copy of the base class, sliced to the static type.

libstdc++-v3/ChangeLog:

PR libstdc++/103630
* libsupc++/exception_ptr.h (exception_ptr): Fix exception
specifications on inline definitions.
(make_exception_ptr): Decay the template parameter. Use typeid
of the static type.
* testsuite/18_support/exception_ptr/103630.cc: New test.

[Bug libstdc++/59769] please add ios_base::__noreplace

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

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

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

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

commit r12-5878-ga219139e986a4200a9105d7c1fa63735d2945994
Author: Jonathan Wakely 
Date:   Wed Dec 8 20:58:11 2021 +

libstdc++: Implement std::ios_base::noreplace for C++23 [PR59769]

This implements my P2467R0 proposal to support opening an fstream in
exclusive mode. The new constant is also supported pre-C++23 as
std::ios_base::__noreplace.

This proposal hasn't been approved for C++23 yet, but I am confident it
will be, as this is restoring a feture found in pre-ISO C++ iostreams
implementations (and still present in the MSVC library as _Noreplace).
If the proposal fails for C++23 we can remove the ios::noreplace
name and just keep ios::__noreplace as an extension.

libstdc++-v3/ChangeLog:

PR libstdc++/59769
* config/io/basic_file_stdio.cc (fopen_mode): Add support for
exclusive mode.
* include/bits/ios_base.h (_S_noreplace): Define new enumerator.
(ios_base::__noreplace): Define.
(ios_base::noreplace): Define for C++23.
* include/std/version (__cpp_lib_ios_noreplace): Define.
* testsuite/27_io/basic_ofstream/open/char/noreplace.cc: New test.
* testsuite/27_io/basic_ofstream/open/wchar_t/noreplace.cc: New
test.

[Bug libstdc++/103382] condition_variable::wait() is not cancellable because it is marked noexcept

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

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

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

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

commit r12-5877-g9e18a25331fa25c3907249fede65a02c6817b06e
Author: Jonathan Wakely 
Date:   Tue Dec 7 15:11:15 2021 +

libstdc++: Allow std::condition_variable waits to be cancelled [PR103382]

std::condition_variable::wait(unique_lock&) is incorrectly marked
noexcept, which means that the __forced_unwind exception used by NPTL
cancellation will terminate the process. It should allow exceptions to
pass through, so that a thread can be cleanly cancelled when waiting on
a condition variable.

The new behaviour is exported as a new version of the symbol, to avoid
an ABI break for existing code linked to the non-throwing definition of
the function. Code linked against older releases will have a reference
to the @GLIBCXX_3.4.11 version, andcode compiled against the new
libstdc++ will get a reference to the @@GLIBCXX_3.4.30 version.

libstdc++-v3/ChangeLog:

PR libstdc++/103382
* config/abi/pre/gnu.ver (GLIBCXX_3.4.11): Do not export old
symbol if .symver renaming is supported.
(GLIBCXX_3.4.30): Export new symbol if .symver renaming is
supported.
* doc/xml/manual/evolution.xml: Document change.
* doc/html/manual/api.html: Regenerate.
* include/bits/std_mutex.h (__condvar::wait,
__condvar::wait_until):
Remove noexcept.
* include/std/condition_variable (condition_variable::wait):
Likewise.
* src/c++11/condition_variable.cc (condition_variable::wait):
Likewise.
* src/c++11/compatibility-condvar.cc (__nothrow_wait_cv::wait):
Define nothrow wrapper around std::condition_variable::wait and
export the old symbol as an alias to it.
* testsuite/30_threads/condition_variable/members/103382.cc: New
test.

[Bug libstdc++/92300] Useless allocator call in std::map, when insert does not perform any insertion.

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

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

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

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

commit r12-5876-gdb5fa0837e464b595a3d63766060bae1c9ac5ccc
Author: Jonathan Wakely 
Date:   Fri Dec 3 14:33:13 2021 +

libstdc++: Avoid unnecessary allocations in std::map insertions [PR92300]

Inserting a pair into a map will allocate a new
node and construct a pair in the node, then check if
the Key is already present in the map. That is because pair
is not the same type as the map's value_type. But it only differs in the
const-qualification on the Key, and so we should be able to do the
lookup directly, without allocating a new node. This avoids allocating
and then deallocating a node for the case where the key is already found
and nothing gets inserted.

We can take this optimization further and lookup the key directly for a
pair, pair, pair etc. for any X. A strict
reading of the standard says we can only do this when we know the
allocator won't do anything funky with the value when constructing a
pair from a slightly different type. Inserting that
type only requires the value_type to be Cpp17EmplaceInsertable into the
container, and that doesn't have any requirement that the value is
unchanged (unlike Cpp17CopyInsertable and Cpp17MoveInsertable). For that
reason, the optimization is only done for maps using std::allocator.

A similar optimization can be done for map.emplace(key, value) where the
first argument is similar to the key_type and so can be looked up
without allocating a new node and constructing a key_type.

Finally, both of the insert and emplace cases can use the same
optimization when key_type is a scalar type and some other scalar is
being passed as the insert/emplace argument. Converting from one scalar
type to another won't have surprising value-altering behaviour, and has
no side effects (unlike e.g. constructing a std::string from a const
char* argument, which might allocate).

We don't need to do this for std::multimap, because we always insert the
new node even if the key is already present. So there's no benefit to
doing the lookup before allocating the new node.

libstdc++-v3/ChangeLog:

PR libstdc++/92300
* include/bits/stl_map.h (insert(Pair&&), emplace(Args&&...)):
Check whether the arguments can be looked up directly without
constructing a temporary node first.
* include/bits/stl_pair.h (__is_pair): Move to here, from ...
* include/bits/uses_allocator_args.h (__is_pair): ... here.
* testsuite/23_containers/map/modifiers/emplace/92300.cc: New test.
* testsuite/23_containers/map/modifiers/insert/92300.cc: New test.

[Bug middle-end/103483] context-sensitive ranges change triggers stringop-overread

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

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

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

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

commit r12-5874-gf8463b0e3ec2438b4cfb8c9a468d59761db2c8a0
Author: Jonathan Wakely 
Date:   Thu Dec 2 13:19:41 2021 +

libstdc++: Disable over-zealous warnings about std::string copies
[PR103332]

These warnings are triggered by perfectly valid code using std::string.
They're particularly bad when --enable-fully-dynamic-string is used,
because even std::string().begin() will give a warning.

Use pragmas to stop the troublesome warnings for copies done by
std::char_traits.

libstdc++-v3/ChangeLog:

PR libstdc++/103332
PR libstdc++/102958
PR libstdc++/103483
* include/bits/char_traits.h: Suppress stringop and array-bounds
warnings.

[Bug tree-optimization/103332] [12 Regression] Spurious -Wstringop-overflow on string concatenation in libstdc++ tests

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

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

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

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

commit r12-5874-gf8463b0e3ec2438b4cfb8c9a468d59761db2c8a0
Author: Jonathan Wakely 
Date:   Thu Dec 2 13:19:41 2021 +

libstdc++: Disable over-zealous warnings about std::string copies
[PR103332]

These warnings are triggered by perfectly valid code using std::string.
They're particularly bad when --enable-fully-dynamic-string is used,
because even std::string().begin() will give a warning.

Use pragmas to stop the troublesome warnings for copies done by
std::char_traits.

libstdc++-v3/ChangeLog:

PR libstdc++/103332
PR libstdc++/102958
PR libstdc++/103483
* include/bits/char_traits.h: Suppress stringop and array-bounds
warnings.

[Bug tree-optimization/102958] std::u8string suboptimal compared to std::string, triggers warnings

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

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

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

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

commit r12-5874-gf8463b0e3ec2438b4cfb8c9a468d59761db2c8a0
Author: Jonathan Wakely 
Date:   Thu Dec 2 13:19:41 2021 +

libstdc++: Disable over-zealous warnings about std::string copies
[PR103332]

These warnings are triggered by perfectly valid code using std::string.
They're particularly bad when --enable-fully-dynamic-string is used,
because even std::string().begin() will give a warning.

Use pragmas to stop the troublesome warnings for copies done by
std::char_traits.

libstdc++-v3/ChangeLog:

PR libstdc++/103332
PR libstdc++/102958
PR libstdc++/103483
* include/bits/char_traits.h: Suppress stringop and array-bounds
warnings.

[Bug libstdc++/64135] Allocator base classes should use reserved names

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

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

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

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

commit r12-5873-gfe9571a35db53e5203326f854f73e432691d67f6
Author: Jonathan Wakely 
Date:   Wed Dec 1 17:56:23 2021 +

libstdc++: Fix non-reserved name in std::allocator base class [PR64135]

The possible base classes of std::allocator are new_allocator and
malloc_allocator, which both cause a non-reserved name to be declared in
every program that includes the definition of std::allocator. This is
non-conforming.

This change replaces __gnu_cxx::new_allocator with std::__new_allocator
which is identical except for using a reserved name. The non-standard
extension __gnu_cxx::new_allocator is preserved as a thin wrapper over
std::__new_allocator. There is no problem with the extension using a
non-reserved name now that it's not included by default in other
headers.

The same change could be done to __gnu_cxx::malloc_allocator but as it's
not the default configuration it can wait.

libstdc++-v3/ChangeLog:

PR libstdc++/64135
* config/allocator/new_allocator_base.h: Include
 instead of .
(__allocator_base): Use std::__new_allocator instead of
__gnu_cxx::new_allocator.
* doc/xml/manual/allocator.xml: Document new default base class
for std::allocator.
* doc/xml/manual/evolution.xml: Likewise.
* doc/html/*: Regenerate.
* include/Makefile.am: Add bits/new_allocator.h.
* include/Makefile.in: Regenerate.
* include/experimental/memory_resource (new_delete_resource):
Use std::__new_allocator instead of __gnu_cxx::new_allocator.
* include/ext/new_allocator.h (new_allocator): Derive from
std::__new_allocator. Move implementation to ...
* include/bits/new_allocator.h: New file.
* testsuite/20_util/allocator/64135.cc: New test.

[Bug target/103635] size_t and uintptr_t have wrong sizes with x86_64-w64-mingw32-g++ -mabi=sysv

[mark at harmstone dot com via Gcc-bugs]

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

--- Comment #2 from Mark Harmstone  ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Mark Harmstone from comment #0)
> > The practical problem this causes is that you can't #include  on
> > mingw with -mabi=sysv,
> 
> I don't think that's going to work anyway, is it?
> 
> I would expect that you need to rebuild the whole of libstdc++ to be able to
> use a different -mabi switch.

Possibly, possibly not. I think a lot of  is templated rather than
precompiled. That wouldn't have been a blocker to what I was working on,
anyway.

[Bug target/103635] size_t and uintptr_t have wrong sizes with x86_64-w64-mingw32-g++ -mabi=sysv

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

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Mark Harmstone from comment #0)
> The practical problem this causes is that you can't #include  on
> mingw with -mabi=sysv,

I don't think that's going to work anyway, is it?

I would expect that you need to rebuild the whole of libstdc++ to be able to
use a different -mabi switch.

[Bug fortran/103609] [11/12 Regression] ICE in gfc_sym_get_dummy_args, at fortran/symbol.c:5243 since r11-2578-g27eac9ee6137a6b5

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-12, and on 11-branch.  Closing.

Thanks for the report!

[Bug fortran/103609] [11/12 Regression] ICE in gfc_sym_get_dummy_args, at fortran/symbol.c:5243 since r11-2578-g27eac9ee6137a6b5

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

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

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

https://gcc.gnu.org/g:81ffb19017daf7197445ed0793e925674a3970d5

commit r11-9368-g81ffb19017daf7197445ed0793e925674a3970d5
Author: Harald Anlauf 
Date:   Wed Dec 8 21:14:19 2021 +0100

Fortran: avoid NULL pointer dereference on missing or bad dummy arguments

gcc/fortran/ChangeLog:

PR fortran/103609
* symbol.c (gfc_sym_get_dummy_args): Catch NULL pointer
dereference.

gcc/testsuite/ChangeLog:

PR fortran/103609
* gfortran.dg/pr103609.f90: New test.

(cherry picked from commit b77968a70537429b4f548f90c369d26e6b6943cc)

[Bug c++/21678] Using inline disables warnings about missing return statements

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #10 from Jason Merrill  ---
(In reply to Richard Biener from comment #4)
> Actually with inline functions we don't reach building the cfg but throw
> away the function early:

I think that's a mistake; we shouldn't throw away the function until after
we've done enough to check for (some?) warnings.  Inline functions usually
aren't big enough for this to make a significant difference to compile time.

[Bug objc/103639] [REGRESSION] GCC 11.2 (or even earlier) breaks switch case with break in fast enumeration loop

[js-gcc at webkeks dot org via Gcc-bugs]

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

js-gcc at webkeks dot org changed:

   What|Removed |Added

   Keywords|wrong-code  |

--- Comment #4 from js-gcc at webkeks dot org ---
Sure:

#import 

int
main()
{
OFArray *array = [OFArray arrayWithObjects: @"a", @"b", nil];
int someVar = 0;
for (id object in array) {
switch (someVar) {
case 0:
OFLog(@"%@", object);
break;
}
OFLog(@"foo");
}

return 0;
}

Sorry, but something free-standing isn't possible as you need a collection
object. The same code should work with GNUstep by just replacing OF with NS.

[Bug objc/103639] [REGRESSION] GCC 11.2 (or even earlier) breaks switch case with break in fast enumeration loop

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-12-09
 Status|UNCONFIRMED |WAITING

--- Comment #3 from Andrew Pinski  ---
Do you have a full testcase?

[Bug target/103622] ICE: Segmentation fault (in altivec_resolve_new_overloaded_builtin)

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

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

--- Comment #5 from Bill Schmidt  ---
Expected behavior is:

pr103622.c: In function 'get_float128_exponent':
pr103622.c:4:3: error: invalid parameter combination for AltiVec intrinsic
'__builtin_vec_scalar_extract_exp'
4 |   return __builtin_vec_scalar_extract_exp (a);
  |   ^~

[Bug rtl-optimization/98782] [11/12 Regression] Bad interaction between IPA frequences and IRA resulting in spills due to changes in BB frequencies

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

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

--- Comment #21 from pthaugen at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #20)
> With g:r12-5872-gf157c5362b4844f7676cae2aba81a4cf75bd68d5 we should no
> longer need -fno-inline-functions-called-once

Yes, I see that now with an updated trunk.

[Bug target/103622] ICE: Segmentation fault (in altivec_resolve_new_overloaded_builtin)

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

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

Bill Schmidt  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |wschmidt at gcc dot 
gnu.org
   Target Milestone|--- |12.0

--- Comment #4 from Bill Schmidt  ---
I'll have a look.

[Bug objc/103639] [REGRESSION] GCC 11.2 (or even earlier) breaks switch case with break in fast enumeration loop

[js-gcc at webkeks dot org via Gcc-bugs]

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

--- Comment #2 from js-gcc at webkeks dot org ---
Oh, forgot to clarify in the example:

Assume more than 1 object in the collection and someVar to be 0.

[Bug rtl-optimization/101995] [9/10/11/12 Regression] regression built-in memset missed-optimization arm -Os since r9-3594

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

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

--- Comment #11 from Segher Boessenkool  ---
Yeah, that could be much more robust.

OTOH this stuff is completely opportunistic in the first place: it handles
only function return values, not any other hard registers (like local
register vars).

[Bug objc/103639] [REGRESSION] GCC 11.2 (or even earlier) breaks switch case with break in fast enumeration loop

[js-gcc at webkeks dot org via Gcc-bugs]

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

js-gcc at webkeks dot org changed:

   What|Removed |Added

 CC||js-gcc at webkeks dot org

--- Comment #1 from js-gcc at webkeks dot org ---
Can confirm the same happens with 11.1.0. 10.2 seems to be fine.

[Bug objc/103639] New: [REGRESSION] GCC 11.2 (or even earlier) breaks switch case with break in fast enumeration loop

[js-gcc at webkeks dot org via Gcc-bugs]

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

Bug ID: 103639
   Summary: [REGRESSION] GCC 11.2 (or even earlier) breaks switch
case with break in fast enumeration loop
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: js-gcc at webkeks dot org
  Target Milestone: ---

The following code is miscompiled by GCC 11.2.1. I don't know when this
started, but this is a regression and used to work just fine in older version:

for (id object in someCollection) {
  switch (someVar) {
  case 0:
 puts("0");
 break;
  }
  puts("this should print but doesn't");
}

The break breaks out of the for loop instead of the switch case.

Changing the code to this makes it work:

for (id object in someCollection) {
  if (someVar == 0) {
 puts("0");
 break;
  }
  puts("this should print and does");
}

This worked just fine with older GCC versions and also works fine with all
versions of Clang.

[Bug ipa/103513] [12 Regression] ICE in evaluate_conditions_for_known_args, at ipa-fnsummary.c:516 with -O2 and above since r12-5531-g1b0acc4b800b589a

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Zhendong Su  changed:

   What|Removed |Added

 CC||zhendong.su at inf dot ethz.ch

--- Comment #6 from Zhendong Su  ---
Another test that fails at -Os and above:

[576] % gcctk -O1 -c small.c
[577] % 
[577] % gcctk -Os -c small.c
during IPA pass: inline
small.c:8:1: internal compiler error: in evaluate_conditions_for_known_args, at
ipa-fnsummary.c:516
8 | }
  | ^
0xbd4256 evaluate_conditions_for_known_args
../../gcc-trunk/gcc/ipa-fnsummary.c:516
0xbd952e evaluate_properties_for_edge(cgraph_edge*, bool, unsigned int*,
unsigned int*, ipa_auto_call_arg_values*, bool)
../../gcc-trunk/gcc/ipa-fnsummary.c:726
0xbf0323 do_estimate_edge_time(cgraph_edge*, sreal*)
../../gcc-trunk/gcc/ipa-inline-analysis.c:197
0xbf1d34 do_estimate_edge_size(cgraph_edge*)
../../gcc-trunk/gcc/ipa-inline-analysis.c:319
0x1c0bc14 estimate_edge_size
../../gcc-trunk/gcc/ipa-inline.h:79
0x1c0bc14 estimate_edge_growth
../../gcc-trunk/gcc/ipa-inline.h:100
0x1c0eb89 want_inline_small_function_p
../../gcc-trunk/gcc/ipa-inline.c:912
0x1c1425c inline_small_functions
../../gcc-trunk/gcc/ipa-inline.c:2050
0x1c1425c ipa_inline
../../gcc-trunk/gcc/ipa-inline.c:2756
0x1c1425c execute
../../gcc-trunk/gcc/ipa-inline.c:3155
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[578] % 
[578] % cat small.c
int a;
void b(int c) {
  int d = 3;
  d ^= c < 2;
  if (d < 3 && a)
while (1)
  b(!a);
}

[Bug libstdc++/103638] New: [11/12 Regression] #include gives errors for --disable-threads builds

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

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

Bug ID: 103638
   Summary: [11/12 Regression] #include  gives errors for
--disable-threads builds
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

bits/atomic_timed_wait.h:144: error: '__condvar' was not declared in this scope
bits/atomic_timed_wait.h:144: error: '__cv' was not declared in this scope
bits/atomic_timed_wait.h:144: error: 'mutex' was not declared in this scope
bits/atomic_timed_wait.h:144: error: '__mx' was not declared in this scope
bits/atomic_timed_wait.h:145: error: expected primary-expression before 'const'
bits/atomic_timed_wait.h:145: error: expected primary-expression before '>'
token
bits/atomic_timed_wait.h:145: error: '__atime' was not declared in this scope
bits/atomic_timed_wait.h:145: error: expression list treated as compound
expression in initializer [-fpermissive]
bits/atomic_timed_wait.h:145: error: expected ';' before '{' token
bits/atomic_timed_wait.h:171: error: '__condvar' was not declared in this scope
bits/atomic_timed_wait.h:171: error: '__cv' was not declared in this scope
bits/atomic_timed_wait.h:171: error: 'mutex' was not declared in this scope
bits/atomic_timed_wait.h:171: error: '__mx' was not declared in this scope
bits/atomic_timed_wait.h:172: error: expected primary-expression before 'const'
bits/atomic_timed_wait.h:172: error: expected primary-expression before '>'
token
bits/atomic_timed_wait.h:172: error: '__atime' was not declared in this scope
bits/atomic_timed_wait.h:172: error: expression list treated as compound
expression in initializer [-fpermissive]
bits/atomic_timed_wait.h:172: error: expected ';' before '{' token

The timed wait implementation needs to be conditional on _GLIBCXX_HAS_GTHREADS.

[Bug tree-optimization/102943] [12 Regression] Jump threader compile-time hog with 521.wrf_r

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

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

--- Comment #31 from Jan Hubicka  ---
With g:r12-5872-gf157c5362b4844f7676cae2aba81a4cf75bd68d5 I limited inliner to
not produce such a large function, so bumping up --param
max-inline-functions-called-once-insns will be necessary to reproduce the
problem.

I will re-do time stats for 1-partition cc1plus LTO build, but I did the same
for linking clang with LTO and passes with over 2% time are:
Time variable   usr   sys  wall
  GGC
 garbage collection :  26.88 (  3%)   0.27 (  1%)  28.53 (  3%)
0  (  0%)
 ipa lto gimple in  :  19.84 (  2%)   1.86 (  4%)  28.42 (  3%)
 3660M ( 13%)
 cfg cleanup:  15.36 (  2%)   0.39 (  1%)  16.38 (  2%)
  154M (  1%)
 df live regs   :  16.20 (  2%)   0.35 (  1%)  18.29 (  2%)
0  (  0%)
 df reg dead/unused notes   :  17.94 (  2%)   0.43 (  1%)  19.35 (  2%)
  361M (  1%)
 alias analysis :  19.87 (  2%)   0.24 (  1%)  21.05 (  2%)
  853M (  3%)
 alias stmt walking :  22.90 (  2%)   1.25 (  3%)  25.44 (  2%)
   68M (  0%)
 tree VRP   :  22.79 (  2%)   1.06 (  2%)  24.22 (  2%)
  488M (  2%)
 tree PTA   :  30.37 (  3%)   1.84 (  4%)  32.71 (  3%)
  215M (  1%)
 tree operand scan  :  19.04 (  2%)   0.86 (  2%)  21.70 (  2%)
 1233M (  5%)
 dominator optimization :  28.85 (  3%)   1.66 (  4%)  32.00 (  3%)
  531M (  2%)
 backwards jump threading   :  23.00 (  2%)   1.37 (  3%)  24.52 (  2%)
  154M (  1%)
 tree PRE   :  21.81 (  2%)   1.11 (  3%)  24.55 (  2%)
  500M (  2%)
 tree FRE   :  18.69 (  2%)   1.40 (  3%)  20.12 (  2%)
  221M (  1%)
 expand :  21.35 (  2%)   1.14 (  3%)  23.27 (  2%)
 2399M (  9%)
 CSE:  20.69 (  2%)   0.78 (  2%)  21.82 (  2%)
  124M (  0%)
 CPROP  :  16.27 (  2%)   0.62 (  1%)  17.10 (  2%)
  419M (  2%)
 combiner   :  27.46 (  3%)   0.81 (  2%)  30.46 (  3%)
  854M (  3%)
 integrated RA  :  70.76 (  7%)   1.82 (  4%)  72.74 (  7%)
 3795M ( 14%)
 LRA non-specific   :  19.51 (  2%)   0.54 (  1%)  20.89 (  2%)
  159M (  1%)
 reload CSE regs:  20.32 (  2%)   0.49 (  1%)  19.98 (  2%)
  290M (  1%)
 scheduling 2   :  44.95 (  5%)   0.98 (  2%)  48.23 (  4%)
  163M (  1%)
 rest of compilation:  30.44 (  3%)   1.92 (  4%)  32.03 (  3%)
  366M (  1%)
 TOTAL  : 985.14 42.92   1082.89   
27226M

So dominators, VRP, and backward searching seems to be still slow on trunk from
20211204

[Bug rtl-optimization/98782] [11/12 Regression] Bad interaction between IPA frequences and IRA resulting in spills due to changes in BB frequencies

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

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

--- Comment #20 from Jan Hubicka  ---
With g:r12-5872-gf157c5362b4844f7676cae2aba81a4cf75bd68d5 we should no longer
need -fno-inline-functions-called-once

[Bug libfortran/103634] Runtime crash with PACK on zero-sized arrays

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2021-December/057149.html

[Bug middle-end/103454] -finline-functions-called-once is both compile-time and runtime loss at average for spec2006, spec2017 and tramp3d

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

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

commit r12-5872-gf157c5362b4844f7676cae2aba81a4cf75bd68d5
Author: Jan Hubicka 
Date:   Thu Dec 9 21:02:17 2021 +0100

Limit inlining functions called once

as dicussed in PR ipa/103454 there are several benchmarks that regresses
for -finline-functions-called once. Runtmes:
 - tramp3d with -Ofast. 31%
 - exchange2 with -Ofast 11-21%
 - roms O2 9%-10%
 - tonto 2.5-3.5% with LTO
Build times:
 - specfp2006 41% (mostly wrf that builds 71% faster)
 - specint2006 1.5-3%
 - specfp2017 64% (again mostly wrf)
 - specint2017 2.5-3.5%

This patch adds two params to tweak the behaviour:
 1) max-inline-functions-called-once-loop-depth limiting the loop depth
(this is useful primarily for exchange where the inlined function is in
 loop depth 9)
 2) max-inline-functions-called-once-insns
We already have large-function-insns/growth parameters, but these are
limiting also inlining small functions, so reducing them will regress
very large functions that are hot.

Because inlining functions called once is meant just as a cleanup pass
I think it makes sense to have separate limit for it.
gcc/ChangeLog:

2021-12-09  Jan Hubicka  

* doc/invoke.texi (max-inline-functions-called-once-loop-depth,
max-inline-functions-called-once-insns): New parameters.
* ipa-inline.c (check_callers): Handle
param_inline_functions_called_once_loop_depth and
param_inline_functions_called_once_insns.
(edge_badness): Fix linebreaks.
* params.opt (param=max-inline-functions-called-once-loop-depth,
param=max-inline-functions-called-once-insn): New params.

[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 103215, which changed state.

Bug 103215 Summary: [12 regression] gcc generates unexpected warnings on 
libx11-1.7.2: error: array subscript -2 is outside array bounds of since 
r12-3124-g820f0940d7ace130
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103215

   What|Removed |Added

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

[Bug tree-optimization/103215] [12 regression] gcc generates unexpected warnings on libx11-1.7.2: error: array subscript -2 is outside array bounds of since r12-3124-g820f0940d7ace130

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Sebor  ---
Fixed, but not without a price: some false negatives (pr103637).

[Bug rtl-optimization/98782] [11/12 Regression] Bad interaction between IPA frequences and IRA resulting in spills due to changes in BB frequencies

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

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

--- Comment #19 from pthaugen at gcc dot gnu.org ---
I tried -fno-inline-functions-called-once and the patches on a Power9 system.
Following are the run times and spill counts (grep -c Spilling
exchange2.fppized.f90.298r.ira). Interesting that the spill counts increase
when -fno-inline-functions-called-once is added, but obviously that additional
spill is on cold paths since execution time improves. Compiler options used are
"-O3 -mcpu=power9 -fpeel-loops -funroll-loops -ffast-math".

  time(sec)  Spill
base473   3284

no-inline-functions-called-once 370   5410

patches 1 & 2   397461

patches 1 & 2
+ no-inline-functions-called-once   299870

[Bug tree-optimization/103215] [12 regression] gcc generates unexpected warnings on libx11-1.7.2: error: array subscript -2 is outside array bounds of since r12-3124-g820f0940d7ace130

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

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

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

https://gcc.gnu.org/g:243a980437b5e7fca56587bf86667005bdf343a7

commit r12-5871-g243a980437b5e7fca56587bf86667005bdf343a7
Author: Martin Sebor 
Date:   Thu Dec 9 12:49:28 2021 -0700

Extend the offset and size of merged object references [PR103215].

Resolves:
PR tree-optimization/103215 - bogus -Warray-bounds with two pointers with
different offsets each

gcc/ChangeLog:

PR tree-optimization/103215
* pointer-query.cc (access_ref::merge_ref): Extend the offset and
size of the merged object instead of using the larger.

gcc/testsuite/ChangeLog:

PR tree-optimization/103215
* gcc.dg/Wstringop-overflow-58.c: Adjust and xfail expected
warnings.
* gcc.dg/Wstringop-overflow-59.c: Same.
* gcc.dg/warn-strnlen-no-nul.c: Same.
* gcc.dg/Warray-bounds-91.c: New test.
* gcc.dg/Warray-bounds-92.c: New test.
* gcc.dg/Wstringop-overflow-85.c: New test.
* gcc.dg/Wstringop-overflow-87.c: New test.

[Bug ipa/103636] Clang build fails with -flto -fno-strict-aliaisng -flifetime-dse=1 -fprofile-generate

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

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

--- Comment #4 from Jan Hubicka  ---
aha, it was missunderstanding then :)
I wanted you to simply move the hunk to can_early_inline_edge_p.  There is no
specific bit to check for einline being finished.

[Bug middle-end/103637] New: [12 Regression] missing warning writing past the end of one of multiple elements of the same array

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

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

Bug ID: 103637
   Summary: [12 Regression] missing warning writing past the end
of one of multiple elements of the same array
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The fix for pr103215 is too conservative and causes false negatives for past
the end accesses to array elements like in gcc.dg/warn-strnlen-no-nul.c.  A
simple test case that shows the problem is below.  The dump shows that both
strcpy calls are plainly out of bounds and both could and should be diagnosed.

$ cat y.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout y.c
extern int x;

extern char b[5][7];

void f (const char *s)
{
  __builtin_strncpy (b[3], s, 9);  // warning (good)
}

void g (int i, const char *s)
{
  char *d = i ? b[3] : b[4];
  __builtin_strncpy (d, s, 9); // warning in GCC 11, missing in 12
}

;; Function f (f, funcdef_no=0, decl_uid=1980, cgraph_uid=1, symbol_order=0)

void f (const char * s)
{
   [local count: 1073741824]:
  __builtin_strncpy ([3], s_2(D), 9); [tail call]
  return;

}


y.c: In function ‘f’:
y.c:7:3: warning: ‘__builtin_strncpy’ writing 9 bytes into a region of size 7
overflows the destination [-Wstringop-overflow=]
7 |   __builtin_strncpy (b[3], s, 9);  // warning (good)
  |   ^~
y.c:3:13: note: at offset 21 into destination object ‘b’ of size 28
3 | extern char b[5][7];
  | ^

;; Function g (g, funcdef_no=1, decl_uid=1984, cgraph_uid=2, symbol_order=1)

Removing basic block 3
void g (int i, const char * s)
{
  char * iftmp.0_1;

   [local count: 1073741824]:
  if (i_2(D) != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870912]:

   [local count: 1073741824]:
  # iftmp.0_1 = PHI <[3](2), [4](3)>
  __builtin_strncpy (iftmp.0_1, s_4(D), 9); [tail call]
  return;

}

[Bug ipa/103636] Clang build fails with -flto -fno-strict-aliaisng -flifetime-dse=1 -fprofile-generate

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
So a correct version was installed where I thought that DECL_STRUCT_FUNCTION
(origin->decl)->always_inline_functions_inlined is the right check for function
being before or after einline. Lemme fix that.

[Bug ipa/103636] Clang build fails with -flto -fno-strict-aliaisng -flifetime-dse=1 -fprofile-generate

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

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

--- Comment #2 from Martin Liška  ---
(In reply to Jan Hubicka from comment #1)
> I found the email here
> http://patches-tcwg.linaro.org/patch/56399/
> I have suggested moving the check to einline only path but the v2 version of
> patch did not implemented it and later it got in with the additional loop
> walking clones.  Is there any reason to prevent inlining
> post-instrumentation?

Oh, I likely installed the wrong version of the patch because I remember I
wrote the patch..

[Bug rtl-optimization/103465] Invalid note with -fno-reorder-blocks-and-partition

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |12.0

--- Comment #15 from Martin Liška  ---
All right, got it even with the cross compiler. So what happens with the
test-case
without the optimize attribute:

- options are parsed and finish_options is called:

  if (opts->x_flag_unwind_tables
  && !targetm_common.unwind_tables_default
  && opts->x_flag_reorder_blocks_and_partition
  && (ui_except == UI_SJLJ || ui_except >= UI_TARGET))
{
  if (opts_set->x_flag_reorder_blocks_and_partition)
inform (loc,
"%<-freorder-blocks-and-partition%> does not support "
"unwind info on this architecture");
  opts->x_flag_reorder_blocks_and_partition = 0;
  opts->x_flag_reorder_blocks = 1;
}

It's not triggered because of opts->x_flag_unwind_tables is false by default,
but
the option is overwritten in target:

#0  ix86_recompute_optlev_based_flags (opts=0x3c6b1c0 ,
opts_set=0x3c6c8a0 ) at
/home/marxin/Programming/gcc/gcc/config/i386/i386-options.c:1787
#1  0x01b1c126 in ix86_option_override_internal (main_args_p=true,
opts=0x3c6b1c0 , opts_set=0x3c6c8a0 ) at
/home/marxin/Programming/gcc/gcc/config/i386/i386-options.c:2332
#2  0x01b1de5f in ix86_option_override () at
/home/marxin/Programming/gcc/gcc/config/i386/i386-options.c:2961
#3  0x014e44be in process_options (no_backend=false) at
/home/marxin/Programming/gcc/gcc/toplev.c:1238
#4  0x014e6925 in toplev::main (this=0x7fffdb7a, argc=21,
argv=0x7fffdcc8) at /home/marxin/Programming/gcc/gcc/toplev.c:2320
#5  0x02d423c8 in main (argc=21, argv=0x7fffdcc8) at
/home/marxin/Programming/gcc/gcc/main.c:39

...
  if (TARGET_64BIT_P (opts->x_ix86_isa_flags))
{
  if (opts->x_optimize >= 1)
SET_OPTION_IF_UNSET (opts, opts_set, flag_omit_frame_pointer,
 !USE_IX86_FRAME_POINTER);
  if (opts->x_flag_asynchronous_unwind_tables
  && TARGET_64BIT_MS_ABI)
SET_OPTION_IF_UNSET (opts, opts_set, flag_unwind_tables, 1);
...

and so x_flag_reorder_blocks_and_partition is not dropped. On the other hand,
when optimize attribute
is used, then finish_options is called for it and we see the note and the
flagged dropped.
So the checking code should be called both from process_options and
finish_options.

Option handling is a can of worms. Lemme test a patch tomorrow.

[Bug ipa/103636] Clang build fails with -flto -fno-strict-aliaisng -flifetime-dse=1 -fprofile-generate

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

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

--- Comment #1 from Jan Hubicka  ---
I found the email here
http://patches-tcwg.linaro.org/patch/56399/
I have suggested moving the check to einline only path but the v2 version of
patch did not implemented it and later it got in with the additional loop
walking clones.  Is there any reason to prevent inlining post-instrumentation?
If not, I think we want to remove the loop and move the check into
can_early_inline_edge_p as suggested originally.

[Bug ipa/103636] New: Clang build fails with -flto -fno-strict-aliaisng -flifetime-dse=1 -fprofile-generate

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

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

Bug ID: 103636
   Summary: Clang build fails with -flto -fno-strict-aliaisng
-flifetime-dse=1 -fprofile-generate
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Buid fails with:
during IPA pass: inline
lto1: internal compiler error: Segmentation fault
0x9ed401 crash_signal
../../gcc/toplev.c:322
0x4ec993 can_inline_edge_p
../../gcc/ipa-inline.c:409
0x12f3be4 inline_small_functions
../../gcc/ipa-inline.c:2036
0x12f3be4 ipa_inline
../../gcc/ipa-inline.c:2743
0x12f3be4 execute
../../gcc/ipa-inline.c:3142

the failure is:
aad72d2ea837 (Martin Liska   2021-06-22 10:09:01 +0200  399)   else if
(profile_arc_flag
aad72d2ea837 (Martin Liska   2021-06-22 10:09:01 +0200  400)   &&
(lookup_attribute ("no_profile_instrument_function",
aad72d2ea837 (Martin Liska   2021-06-22 10:09:01 +0200  401)   
 DECL_ATTRIBUTES (caller->decl)) == NULL_TREE)
aad72d2ea837 (Martin Liska   2021-06-22 10:09:01 +0200  402)   !=
(lookup_attribute ("no_profile_instrument_function",
aad72d2ea837 (Martin Liska   2021-06-22 10:09:01 +0200  403)   
 DECL_ATTRIBUTES (callee->decl)) == NULL_TREE))
aad72d2ea837 (Martin Liska   2021-06-22 10:09:01 +0200  404) {
aad72d2ea837 (Martin Liska   2021-06-22 10:09:01 +0200  405)  
cgraph_node *origin = caller;
aad72d2ea837 (Martin Liska   2021-06-22 10:09:01 +0200  406)  
while (origin->clone_of)
aad72d2ea837 (Martin Liska   2021-06-22 10:09:01 +0200  407)origin
= origin->clone_of;
aad72d2ea837 (Martin Liska   2021-06-22 10:09:01 +0200  408)
aad72d2ea837 (Martin Liska   2021-06-22 10:09:01 +0200  409)   if
(!DECL_STRUCT_FUNCTION (origin->decl)->always_inline_functions_inlined)
aad72d2ea837 (Martin Liska   2021-06-22 10:09:01 +0200  410){
aad72d2ea837 (Martin Liska   2021-06-22 10:09:01 +0200  411) 
e->inline_failed = CIF_UNSPECIFIED;
aad72d2ea837 (Martin Liska   2021-06-22 10:09:01 +0200  412) 
inlinable = false;
aad72d2ea837 (Martin Liska   2021-06-22 10:09:01 +0200  413)}
aad72d2ea837 (Martin Liska   2021-06-22 10:09:01 +0200  414) }
aad72d2ea837 (Martin Liska   2021-06-22 10:09:01 +0200  415)
9a4841a37014 (Jan Hubicka2018-01-30 14:23:39 +0100  416)   if
(!inlinable && report)
9a4841a37014 (Jan Hubicka2018-01-30 14:23:39 +0100  417)
report_inline_failed_reason (e);
9a4841a37014 (Jan Hubicka2018-01-30 14:23:39 +0100  418)   return
inlinable;

one can not access DECL_STRUCT_FUNCTION in WPA.   g:aad72d2ea837 speaks about
einline, so why it is not tested in can_early_inline_edge_p?

[Bug c++/19992] -fhosted/-ffreestanding for C++

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

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

Joseph S. Myers  changed:

   What|Removed |Added

  Known to fail||4.2.0
   Target Milestone|--- |4.3.0
  Known to work||4.3.0
 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Joseph S. Myers  ---
Fixed for GCC 4.3 by:

Author: Dirk Mueller 
Date:   Fri May 4 00:46:02 2007 +

c.opt (Wmain,ffreestanding): Enable for C++,ObjC++.

2007-05-04  Dirk Mueller  

* c.opt(Wmain,ffreestanding): Enable for C++,ObjC++.

* cp-tree.h (DECL_MAIN_P): only if -ffreestanding is
not in effect.

From-SVN: r124404

[Bug c++/102396] [11/12 Regression] ICE when using concepts, in get, at cp/constraint.cc:2637 since r11-6245-g79f57d5cb070bb02

[dangelog at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Giuseppe D'Angelo  ---
To elaborate on the last comment, this testcase does complain about the
redefinition. 


#include 
#include 


template  class S;

template 
static inline std::true_type is_S_impl(const S&);
static inline std::false_type is_S_impl(...);

template 
concept is_S = decltype(is_S_impl(std::declval()))::value;



template 
struct S {
using type = T;
T data;

S();
explicit S(const T &);

template 
requires is_S && (!is_S) &&
std::equality_comparable_with
friend bool operator==(const V , const U ) { return v.data == u; }
};

void f() {
S s1; s1 == 123;
S s2; s2 == 123.4;
}

[Bug c++/102396] [11/12 Regression] ICE when using concepts, in get, at cp/constraint.cc:2637 since r11-6245-g79f57d5cb070bb02

[dangelog at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Giuseppe D'Angelo  ---
Hello Patrick,

Thank you for the insights. I'm left wondering however if the CWG resolution
would possibly ever allow the operator== to be defined as a hidden friend; the
workaround you mentioned may lead to redefinition errors (as now it doesn't
depend on S any more)?

[Bug tree-optimization/92860] [9/10/11/12 regression] Global flags affected by -O settings are clobbered by optimize attribute

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #61 from David Binderman  ---
Created attachment 51964
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51964=edit
C source code

Command line used to compile file:

/home/dcb/gcc/working.2/./gcc/xgcc -B/home/dcb/gcc/working.2/./gcc/
-B/home/dcb/gcc/results.20211209/x86_64-pc-linux-gnu/bin/
-B/home/dcb/gcc/results.20211209/x86_64-pc-linux-gnu/lib/ -isystem
/home/dcb/gcc/results.20211209/x86_64-pc-linux-gnu/include -isystem
/home/dcb/gcc/results.20211209/x86_64-pc-linux-gnu/sys-include   -fchecking=1
-g -O3 -march=native -O2  -g -O3 -march=native -DIN_GCC-W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag
-Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag
-Wold-style-definition  -isystem ./include  -fpic -mlong-double-80
-DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector  -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection
-mshstk -I. -I. -I../.././gcc -I../../../trunk.git/libgcc
-I../../../trunk.git/libgcc/. -I../../../trunk.git/libgcc/../gcc
-I../../../trunk.git/libgcc/../include
-I../../../trunk.git/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT
-DHAVE_CC_TLS  -DUSE_TLS  -o unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF
unwind-dw2.dep -fexceptions -c ../../../trunk.git/libgcc/unwind-dw2.c
-fvisibility=hidden -DHIDE_EXPORTS

[Bug tree-optimization/92860] [9/10/11/12 regression] Global flags affected by -O settings are clobbered by optimize attribute

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #60 from David Binderman  ---
(In reply to Martin Liška from comment #59)
> Most of the issues were fixed in GCC 12 stage1.
> There are still corner cases, but the current situation should be much
> better.

Not for me, they aren't. 

I can reproduce it on today's trunk, but any *.i file I produce seems to 
compile fine ;-<

I will attach the *.i file and the command line.

[Bug libstdc++/85813] make_exception_ptr should support __cxa_init_primary_exception path even with -fno-exceptions

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

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Mathias Stearn from comment #3)
> My assumption was that if E(...) throws and it can't be caught, it should be
> treated as any other case when an -fno-exceptions TU calls a throwing
> function. In this case that would mean calling terminate() due to the
> noexcept, which seems better than returning a null exception_ptr.

Unfortunately, if E(...) throws and std::make_exception_ptr was compiled
with -fno-exceptions, the noexcept on that function is ignored and the
exception propagates to the caller of std::make_exception_ptr. So exceptions
can propagate out of a noexcept function compiled with -fno-exceptions, which
is pretty counterintuitive because that's the last kind of function you'd
expect to throw when you call it! But that's not unique to
std::make_exception_ptr, it's true for any noexcept function compiled with
-fno-exceptions that calls that could throw.

(In reply to Mathias Stearn from comment #7)
> Silently dropping errors always skeeves me out. I'm not sure if anyone is
> well served by the current behavior. If it were up to me (and I know it
> isn't) I'd make that case call std::terminate() or similar rather than
> returning the "no error" value. That seems consistent with the behavior of
> the __throw* functions, but it is a breaking change. Or even better, since
> gcc seems fine throwing through functions marked noexcept in -fno-exceptions
> TUs, maybe in the (very rare) case where copying/moving an exception throws
> inside an -fno-exceptions TU, just let it bubble out.

I'm persuaded that if constructing the E throws, we should just let it bubble
out. We can't really do anything else.

But we still have the case of -fno-rtti -fno-exceptions case where we can't use
the newer non-throwing implementation of make_exception_ptr (because it uses
typeid) and we can't use the original throwing one (because it uses throw). So
that either has to terminate or return an empty exception_ptr, and either case
is a problem if you mix'n'match, so ...

> Do you think this case warrants a [[gnu::always_inline]]?

I now think the -fno-rtti -fno-exceptions case should be always_inline.

Here's what I'm considering ...

  /// Obtain an exception_ptr pointing to a copy of the supplied object.
#if (__cplusplus >= 201103L && __cpp_rtti) || __cpp_exceptions
  template
exception_ptr
make_exception_ptr(_Ex __ex) _GLIBCXX_USE_NOEXCEPT
{
#if __cplusplus >= 201103L && __cpp_rtti
  using _Ex2 = typename decay<_Ex>::type;
  void* __e = __cxxabiv1::__cxa_allocate_exception(sizeof(_Ex));
  (void) __cxxabiv1::__cxa_init_primary_exception(
  __e, const_cast((_Ex)),
  __exception_ptr::__dest_thunk<_Ex2>);
  __try
{
  ::new (__e) _Ex2(__ex);
  return exception_ptr(__e);
}
  __catch(...)
{
  __cxxabiv1::__cxa_free_exception(__e);
  return current_exception();
}
#else
  try
{
  throw __ex;
}
  catch(...)
{
  return current_exception();
}
#endif
}
#else // no RTTI and no exceptions
  // This is always_inline so the linker will never use this useless definition
  // instead of a working one compiled with RTTI and/or exceptions enabled.
  template
__attribute__ ((__always_inline))
exception_ptr
make_exception_ptr(_Ex) _GLIBCXX_USE_NOEXCEPT
{ return exception_ptr(); }
#endif

Because only the no-op implementation is always_inline, there won't be any
bloat caused by inlining the working implementation into a hot path.

[Bug c++/102229] [11/12 Regression] 'decltype(auto)' cannot be cv-qualified

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

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

--- Comment #9 from Marek Polacek  ---
This is supposed to be valid, so I'll try to come up with a fix soon.

[Bug testsuite/101751] asan_test.C fails with excess error with glibc-2.34

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

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

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

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

commit r12-5870-g9eeca99ccce4b56765920bd3c839abb77bbd4280
Author: Martin Sebor 
Date:   Thu Dec 9 11:24:14 2021 -0700

Avoid expecting nonzero size for access none void* arguments [PR101751].

Resolves:
PR middle-end/101751 - attribute access none with void pointer expects
nonzero size

gcc/ChangeLog:

PR middle-end/101751
* doc/extend.texi (attribute access): Adjust.
* gimple-ssa-warn-access.cc
(pass_waccess::maybe_check_access_sizes):
Treat access mode none on a void* argument as expecting as few as
zero bytes.

gcc/testsuite/ChangeLog:

PR middle-end/101751
* gcc.dg/Wstringop-overflow-86.c: New test.

[Bug libfortran/103634] Runtime crash with PACK on zero-sized arrays

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Component|fortran |libfortran
   Last reconfirmed||2021-12-09
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
Untested fix:

diff --git a/libgfortran/intrinsics/pack_generic.c
b/libgfortran/intrinsics/pack_generic.c
index cad2fbbfbcd..f629e0e8469 100644
--- a/libgfortran/intrinsics/pack_generic.c
+++ b/libgfortran/intrinsics/pack_generic.c
@@ -126,6 +126,10 @@ pack_internal (gfc_array_char *ret, const gfc_array_char
*array,
   if (mstride[0] == 0)
 mstride[0] = mask_kind;

+  for (n = 0; n < dim; n++)
+if (extent[n] == 0)
+  return;
+
   if (ret->base_addr == NULL || unlikely (compile_options.bounds_check))
 {
   /* Count the elements, either for allocating memory or

[Bug c++/103635] New: size_t and uintptr_t have wrong sizes with x86_64-w64-mingw32-g++ -mabi=sysv

[mark at harmstone dot com via Gcc-bugs]

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

Bug ID: 103635
   Summary: size_t and uintptr_t have wrong sizes with
x86_64-w64-mingw32-g++ -mabi=sysv
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mark at harmstone dot com
  Target Milestone: ---

When you add the option -mabi=sysv to mingw for amd64, it changes size_t and
uintptr_t from 64 to 32 bits.

Minimal example:

tmp.cpp:
#include 
static_assert(sizeof(size_t) == 8, "!");
static_assert(sizeof(uintptr_t) == 8, "!");

Working:
x86_64-pc-linux-gnu-g++ -mabi=ms -c tmp.cpp
x86_64-pc-linux-gnu-g++ -mabi=sysv -c tmp.cpp
x86_64-pc-cygwin-g++ -mabi=ms -c tmp.cpp
x86_64-pc-cygwin-g++ -mabi=sysv -c tmp.cpp
x86_64-w64-mingw32-g++ -mabi=ms -c tmp.cpp

Not working:
x86_64-w64-mingw32-g++ -mabi=sysv -c tmp.cpp
tmp.cpp:2:30: error: static assertion failed: !
2 | static_assert(sizeof(size_t) == 8, "!");
  |   ~~~^~~~
tmp.cpp:3:33: error: static assertion failed: !
3 | static_assert(sizeof(uintptr_t) == 8, "!");
  | 

My hunch is that perhaps GCC is assuming that long is the same size as a
pointer, which it's not on Windows. The SysV specs say that size_t is
equivalent to unsigned long on LP64 (but unsurprisingly doesn't mention the
LLP64 that Windows uses).

The practical problem this causes is that you can't #include  on mingw
with -mabi=sysv, as _mm_malloc amongst others uses size_t to do pointer
arithmetic.

[Bug fortran/103634] New: Runtime crash with PACK on zero-sized arrays

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

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

Bug ID: 103634
   Summary: Runtime crash with PACK on zero-sized arrays
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gcc dot gnu.org
  Target Milestone: ---

I thought we had fixed this one (see PR31001), but maybe not completely:

program p
  implicit none
  type t
 real :: r(24) = -99.
  end type
  type(t), allocatable :: new(:), old(:)
  logical, allocatable :: mask(:)
  integer  :: n, m
! m = 1! works
  m = 0! fails
  allocate (old(m), mask(m))
  mask(:) = .false.
  n = count (mask)
  allocate (new(n))
  new(:) = pack (old, mask)
  print *, size (new)
end

% ./a.out 

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x151ef209949f in ???
#1  0x151ef2e263e0 in pack_internal
at ../../../gcc-trunk/libgfortran/intrinsics/pack_generic.c:182
#2  0x401194 in p
at /home/anlauf/gcc-bugs/pack-bug.f90:15
#3  0x401255 in main
at /home/anlauf/gcc-bugs/pack-bug.f90:17

[Bug other/103617] Debugging gcc: can't use 'pp' command for irange

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #5 from Andrew Macleod  ---
Well, I don't know :-(

It looks like the temporary variable PP uses deosn't work right for references?

263   r.set_undefined ();
(gdb) n
266   if ((idx = tracer.header ("range_of_stmt (")))
(gdb) pp s
w9.0_1 = w9;
(gdb) pp r
Attempt to take address of value not located in memory.
(gdb) p $debug_arg
$9 = {m_num_ranges = 0 '\000', m_max_ranges = 255 '\377', m_kind =
VR_UNDEFINED, m_base = 0x7fffbbd0}
(gdb) p $debug_arg.dump(stderr)
Attempt to take address of value not located in memory.
(gdb) p $debug_arg.m_num_ranges
$10 = 0 '\000'


It looks like it can't create a 'this' pointer by taking the address of the
object..

Is this even suppose to work?  It doesn't seem to work for wide_ints either:


(gdb) call r.set_varying (name->typed.type)
(gdb) p r.dump(stderr)
int VARYING$11 = void
(gdb) set $test = r.lower_bound(0)
(gdb) p $test
$13 = { = {val = {-2147483648, 25376563, 140737332737664,
140737488324960, 140737488312144, 15963520, 140737488312240, 64771920,
140737488312152}, len = 1, precision = 32}, 
  static is_sign_extended = true}
(gdb) p ::debug ($test)
Attempt to take address of value not located in memory.

[Bug c++/103401] [11/12 Regression] gcc accepts decltype(auto(0)) as the parameter of the function

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Should be fixed now.

[Bug c++/71527] wrong type mismatch while template argument deduction/substitution

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug c++/71982] Wrong error and note range with macro

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |NEW

[Bug c++/67829] Bogus "ambiguous template instantiation" error with partial specializations involving a template template parameter

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pyer4 at free dot fr

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

[Bug c++/77335] templates and ambiguous call to overloaded function

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Andrew Pinski  ---
Dup of bug 67829

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

[Bug middle-end/101397] [11 Regression] spurious warning writing to the result of stpcpy minus 1

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

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

Bug 103143 Summary: [12 Regression] ICE due to infinite recursion in 
pointer-query.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103143

   What|Removed |Added

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

[Bug middle-end/103143] [12 Regression] ICE due to infinite recursion in pointer-query.cc

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Fixed in r12-5861.