[Bug c++/109390] New: Does not reject specialized non-type argument of dependent type in class template partial specialization

[sbergman at redhat dot com via Gcc-bugs]

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

Bug ID: 109390
   Summary: Does not reject specialized non-type argument of
dependent type in class template partial
specialization
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

As seen with e.g. gcc-c++-12.2.1-4.fc37.x86_64, it does not reject

> $ cat test.cc
> template struct S {};
> template struct S {};
> $ g++ -fsyntax-only test.cc

even though I think it should per (e.g. C++20) [temp.class.spec]/9.1 "The type
of a template parameter corresponding to a specialized non-type argument shall
not be dependent on a parameter of the specialization."

(I'm not sure whether or not this should be considered a duplicate of bug
102158 "[C++20] Specialized non-type template argument violates
[temp.spec.partial#general-9] but accepted by GCC".)

[Bug tree-optimization/106881] [13 Regression] ice in init_from_control_deps, at gimple-predicate-analysis.cc:1740 since r13-2500-g0a4a2667dc115ca7

[sbergman at redhat dot com via Gcc-bugs]

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

Stephan Bergmann  changed:

   What|Removed |Added

 CC||sbergman at redhat dot com

--- Comment #9 from Stephan Bergmann  ---
*** Bug 106891 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/106891] internal compiler error: in init_from_control_deps, at gimple-predicate-analysis.cc:1740

[sbergman at redhat dot com via Gcc-bugs]

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

Stephan Bergmann  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Stephan Bergmann  ---
(In reply to Richard Biener from comment #2)
> I believe this was fixed with r13-2537-gc8d3b44dfa2851, aka duplicate of
> PR106881

Yes, thanks, a fresh pull fixed my issue.

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

[Bug tree-optimization/106891] internal compiler error: in init_from_control_deps, at gimple-predicate-analysis.cc:1740

[sbergman at redhat dot com via Gcc-bugs]

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

--- Comment #1 from Stephan Bergmann  ---
Created attachment 53553
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53553=edit
preprocessed source, gzipped to avoid bugzilla size limit

[Bug tree-optimization/106891] New: internal compiler error: in init_from_control_deps, at gimple-predicate-analysis.cc:1740

[sbergman at redhat dot com via Gcc-bugs]

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

Bug ID: 106891
   Summary: internal compiler error: in init_from_control_deps, at
gimple-predicate-analysis.cc:1740
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

Bisecting shows this started with
<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0a4a2667dc115ca73b552fcabf8570620dfbe55f>
"tree-optimization/106754 - fix compute_control_dep_chain defect":

> $ CCACHE_CPP2=1  /home/sbergman/gcc/trunk/inst/bin/g++ 
> -fdiagnostics-color=always -DBOOST_ERROR_CODE_HEADER_ONLY 
> -DBOOST_SYSTEM_NO_DEPRECATED -DCPPU_ENV=gcc3 -DDBG_UTIL -DLINUX 
> -DOSL_DEBUG_LEVEL=1 -DSAL_LOG_INFO -DSAL_LOG_WARN -DUNIX -DUNX -DX86_64 
> -D_DEBUG -D_GLIBCXX_DEBUG -D_PTHREADS -D_REENTRANT   -fvisibility=hidden 
> -Werror   -Wall -Wno-missing-braces -Wnon-virtual-dtor -Wendif-labels -Wextra 
> -Wundef -Wunreachable-code -Wshadow -Wunused-macros  -finput-charset=UTF-8 
> -fmessage-length=0 -fno-common -pipe -fstack-protector-strong  
> -Wdeprecated-copy-dtor -Wduplicated-cond -Wlogical-op -Wshift-overflow=2 
> -Wunused-const-variable=1 -Wno-cast-function-type -fvisibility-inlines-hidden 
> -fPIC -Wshadow -Woverloaded-virtual -std=c++23 -pthread  -O2 -ggdb2 
> -gsplit-dwarf -gdwarf-4 -ggnu-pubnames  -DEXCEPTIONS_ON -fexceptions
> -DLIBO_INTERNAL_ONLY  -c $S/configmgr/source/xcsparser.cxx -o 
> $W/CxxObject/configmgr/source/xcsparser.o -MMD -MT 
> $W/CxxObject/configmgr/source/xcsparser.o -MP -MF 
> $W/Dep/CxxObject/configmgr/source/xcsparser.d_ -I$S/external/boost/include 
> -I$W/UnpackedTarball/boost -I$S/include -I/usr/lib/jvm/java-17/include 
> -I/usr/lib/jvm/java-17/include/linux -I$S/config_host   -I/usr/include/dconf 
> -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include 
> -I/usr/include/sysprof-4 -I/usr/include/libmount -I/usr/include/blkid 
> -pthread   -I$W/UnoApiHeadersTarget/udkapi/normal 
> -I$W/UnoApiHeadersTarget/offapi/normal -freport-bug
> during GIMPLE pass: uninit
> /home/sbergman/lo2/core/configmgr/source/xcsparser.cxx: In member function 
> ‘void configmgr::XcsParser::handleProp(xmlreader::XmlReader&)’:
> /home/sbergman/lo2/core/configmgr/source/xcsparser.cxx:415:6: internal 
> compiler error: in init_from_control_deps, at 
> gimple-predicate-analysis.cc:1740
>   415 | void XcsParser::handleProp(xmlreader::XmlReader & reader) {
>   |  ^
> 0x94a678 predicate::init_from_control_deps(vec 
> const*, unsigned int, bool)
>   ../../src/gcc/gimple-predicate-analysis.cc:1740
> 0x1f65eaf predicate::init_from_control_deps(vec 
> const*, unsigned int, bool)
>   ../../src/gcc/gimple-predicate-analysis.cc:1715
> 0x1f65eaf uninit_analysis::init_use_preds(predicate&, basic_block_def*, 
> basic_block_def*)
>   ../../src/gcc/gimple-predicate-analysis.cc:1986
> 0x1f68fbf uninit_analysis::is_use_guarded(gimple*, basic_block_def*, gphi*, 
> unsigned int, hash_set >*)
>   ../../src/gcc/gimple-predicate-analysis.cc:2136
> 0x1f695d8 uninit_analysis::is_use_guarded(gimple*, basic_block_def*, gphi*, 
> unsigned int)
>   ../../src/gcc/gimple-predicate-analysis.cc:2177
> 0x1409ccc find_uninit_use
>   ../../src/gcc/tree-ssa-uninit.cc:1238
> 0x140a5fe warn_uninitialized_phi
>   ../../src/gcc/tree-ssa-uninit.cc:1308
> 0x140a5fe execute_late_warn_uninitialized
>   ../../src/gcc/tree-ssa-uninit.cc:1429
> 0x140a5fe execute
>   ../../src/gcc/tree-ssa-uninit.cc:1446
> Please submit a full bug report, with preprocessed source.
> Please include the complete backtrace with any bug report.
> See <https://gcc.gnu.org/bugs/> for instructions.
> Preprocessed source stored into /tmp/ccFZ1yef.out file, please attach this to 
> your bugreport.

[Bug target/106355] Linux s390x -O2 argument passing miscompile

[sbergman at redhat dot com via Gcc-bugs]

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

--- Comment #2 from Stephan Bergmann  ---
(In reply to Richard Biener from comment #1)
> Did you see whether this is changed behavior from GCC 11?

I didn't check that myself, but the Debian LibreOffice maintainer claims that
he sees the same symptoms when building with some GCC 11 (against some GCC 12
libstdc++, though).  (It appears that this issue only happened to start to hit
builds of LibreOffice after some recent code changes in LibreOffice, so we
don't have any historic data on which versions of GCC would not have had this
issue.)

[Bug other/106355] New: Linux s390x -O2 argument passing miscompile

[sbergman at redhat dot com via Gcc-bugs]

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

Bug ID: 106355
   Summary: Linux s390x -O2 argument passing miscompile
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

(I ran into this when trying to build recent LibreOffice 7.5 master on Fedora
36 on s390x causing a crash in one of the executables generated during the
build.  I tracked that down to a member function S::f2(arg1,args2,arg3) calling
S::f1(arg1,arg2,arg3,std::nullopt) but within
S::f1(arg1,arg2,arg3,std::optional x) then x.has_value()
evaluates to true, or even to some random non-zero value like 163:)

At least with gcc-c++-12.1.1-1.fc36.s390x:

> $ cat test.cc
> #include 
> #include 
> int f1(int, int, int, int, std::optional x) {
>   if (x) std::abort();
>   return 0;
> }
> int f2(int a, int b, int c, int d) {
>   return f1(a, b, c, d, std::nullopt);
> }

> $ g++ -std=c++17 -O2 -fpic -S test.cc

> $ cat test.s
> .file   "test.cc"
> .machinemode zarch
> .machine "zEC12"
> .text
> .align  8
> .align  16
> .globl _Z2f1St8optionalItE
> .type   _Z2f1St8optionalItE, @function
> _Z2f1St8optionalItE:
> .LFB284:
> .cfi_startproc
> tmll%r6,65280
> jne .L7
> lghi%r2,0
> br  %r14
> .L7:
> stmg%r14,%r15,112(%r15)
> .cfi_offset 14, -48
> .cfi_offset 15, -40
> lay %r15,-168(%r15)
> .cfi_def_cfa_offset 328
> brasl   %r14,abort@PLT
> .cfi_endproc
> .LFE284:
> .size   _Z2f1St8optionalItE, .-_Z2f1St8optionalItE
> .align  8
> .align  16
> .globl _Z2f2
> .type   _Z2f2, @function
> _Z2f2:
> .LFB287:
> .cfi_startproc
> ldgr%f0,%r15
> .cfi_register 15, 16
> lay %r15,-168(%r15)
> .cfi_def_cfa_offset 328
> mvi 166(%r15),0
> lgdr%r15,%f0
> .cfi_restore 15
> .cfi_def_cfa_offset 160
> jg  _Z2f1St8optionalItE@PLT
> .cfi_endproc
> .LFE287:
> .size   _Z2f2, .-_Z2f2
> .ident  "GCC: (GNU) 12.1.1 20220507 (Red Hat 12.1.1-1)"
> .section.note.GNU-stack,"",@progbits

With my limited understanding of s390x assembly, f2 sets the optional's bool
_M_engaged flag byte to 0 on the stack with

lay %r15,-168(%r15)
mvi 166(%r15),0

but then f1 expects to test that byte in %r6 with

tmll%r6,65280

[Bug c++/87729] Please include -Woverloaded-virtual in -Wall

[sbergman at redhat dot com via Gcc-bugs]

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

--- Comment #12 from Stephan Bergmann  ---
(In reply to CVS Commits from comment #11)
> The master branch has been updated by Jason Merrill :
> 
> https://gcc.gnu.org/g:81bec060e31b6ef2feeb3046c6f13a207c6f698a
> 
> commit r13-1559-g81bec060e31b6ef2feeb3046c6f13a207c6f698a
> Author: Jason Merrill 
> Date:   Thu Jul 7 10:12:04 2022 -0400
> 
> c++: -Woverloaded-virtual and dtors [PR87729]

This still starts to produces spurious warnings for diamond inheritance:

> $ cat test.cc
> struct S1 { virtual void f(); };
> struct S2: S1 {};
> struct S3: S1 {};
> struct S4: S2, S3 { void f(); };

> $ g++ -Woverloaded-virtual -fsyntax-only test.cc
> test.cc:1:26: warning: ‘virtual void S1::f()’ was hidden 
> [-Woverloaded-virtual=]
> 1 | struct S1 { virtual void f(); };
>   |  ^
> test.cc:4:26: note:   by ‘virtual void S4::f()’
> 4 | struct S4: S2, S3 { void f(); };
>   |  ^

[Bug c++/87729] Please include -Woverloaded-virtual in -Wall

[sbergman at redhat dot com via Gcc-bugs]

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

Stephan Bergmann  changed:

   What|Removed |Added

 CC||sbergman at redhat dot com

--- Comment #10 from Stephan Bergmann  ---
(In reply to CVS Commits from comment #8)
> The master branch has been updated by Jason Merrill :
> 
> https://gcc.gnu.org/g:113844d68e94f4e9c0e946db351ba7d3d4a1335a
> 
> commit r13-1262-g113844d68e94f4e9c0e946db351ba7d3d4a1335a
> Author: Jason Merrill 
> Date:   Fri Jun 24 14:40:12 2022 -0400
> 
> c++: Include -Woverloaded-virtual in -Wall [PR87729]

This started to cause spurious -Woverloaded-virtual= warnings now (first
reported at <https://gcc.gnu.org/pipermail/gcc-patches/2022-July/597670.html>
"Re: [pushed] c++: Include -Woverloaded-virtual in -Wall [PR87729]"):

> $ cat test.cc
> struct S1 {};
> struct S2: S1 { virtual ~S2(); };
> struct S3 { virtual ~S3(); };
> struct S4: S2, S3 { virtual ~S4(); };

> $ g++ -Woverloaded-virtual -fsyntax-only test.cc
> test.cc:3:21: warning: ‘virtual S3::~S3()’ was hidden [-Woverloaded-virtual=]
> 3 | struct S3 { virtual ~S3(); };
>   | ^
> test.cc:4:29: note:   by ‘virtual S4::~S4()’
> 4 | struct S4: S2, S3 { virtual ~S4(); };
>   | ^
> test.cc:3:21: warning: ‘virtual S3::~S3()’ was hidden [-Woverloaded-virtual=]
> 3 | struct S3 { virtual ~S3(); };
>   | ^
> test.cc:4:29: note:   by ‘virtual S4::~S4()’
> 4 | struct S4: S2, S3 { virtual ~S4(); };
>   | ^
> test.cc:3:21: warning: ‘virtual S3::~S3()’ was hidden [-Woverloaded-virtual=]
> 3 | struct S3 { virtual ~S3(); };
>   | ^
> test.cc:4:29: note:   by ‘virtual S4::~S4()’
> 4 | struct S4: S2, S3 { virtual ~S4(); };
>   | ^

[Bug libstdc++/105291] include/c++/12.0.1/debug/safe_unordered_container.h:71:28: error: captured variable '__local_end' cannot appear here

[sbergman at redhat dot com via Gcc-bugs]

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

Stephan Bergmann  changed:

   What|Removed |Added

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

--- Comment #5 from Stephan Bergmann  ---
(In reply to corentinjabot from comment #4)
> Agreed, clang should implement the proposed resolution to CWG2569 very soon
> so there isn't anything that needs to change in libstdc++

Thanks; seen fixed with

"[Clang] Use of decltype(capture) in parameter-declaration-clause".

[Bug libstdc++/105291] New: include/c++/12.0.1/debug/safe_unordered_container.h:71:28: error: captured variable '__local_end' cannot appear here

[sbergman at redhat dot com via Gcc-bugs]

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

Bug ID: 105291
   Summary: include/c++/12.0.1/debug/safe_unordered_container.h:71
:28: error: captured variable '__local_end' cannot
appear here
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

Since
<https://github.com/llvm/llvm-project/commit/04000c2f928a7adc32138a664d167f01b642bef3>
"[clang] Implement Change scope of lambda trailing-return-type", Clang 15 trunk
implements
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2036r3.html> "Change
scope of lambda trailing-return-type" as a DR (in line with
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/n4902.html> "N4902
Editors’ Report – Programming Languages – C++"; so enabled with all -std=
versions).

That stated to cause

> $ cat test.cc 
> #define _GLIBCXX_DEBUG
> #include 

> $ clang++ -fsyntax-only test.cc
> In file included from test.cc:2:
> In file included from 
> /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/unordered_map:52:
> In file included from 
> /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/debug/unordered_map:49:
> /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/debug/safe_unordered_container.h:71:28:
>  error: captured variable '__local_end' cannot appear here
> [__local_end](__decltype(__local_end) __it)
>  ^
> /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/debug/safe_unordered_container.h:71:4:
>  note: variable '__local_end' is explicitly captured here
> [__local_end](__decltype(__local_end) __it)
>  ^
> /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/debug/safe_unordered_container.h:69:2:
>  note: '__local_end' declared here
> auto __local_end = _M_cont()._M_base().cend(0);
> ^
> /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/debug/safe_unordered_container.h:169:44:
>  error: captured variable '__end' cannot appear here
> this->_M_invalidate_if([__end](__decltype(__end) __it)
>   ^
> /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/debug/safe_unordered_container.h:169:26:
>  note: variable '__end' is explicitly captured here
> this->_M_invalidate_if([__end](__decltype(__end) __it)
> ^
> /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/debug/safe_unordered_container.h:168:2:
>  note: '__end' declared here
> auto __end = _M_cont()._M_base().cend();
> ^
> 2 errors generated.

to fail.

The relevant code in libstdc++-v3/include/debug/safe_unordered_container.h got
added with
<https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=4b763deedb282b480fe4c2b3a8ad07192393f1b1>
"2018-10-24  François Dumont  ".

What made things work for me is

> diff --git a/libstdc++-v3/include/debug/safe_unordered_container.h 
> b/libstdc++-v3/include/debug/safe_unordered_container.h
> index 91be256611a..71468198573 100644
> --- a/libstdc++-v3/include/debug/safe_unordered_container.h
> +++ b/libstdc++-v3/include/debug/safe_unordered_container.h
> @@ -67,8 +67,9 @@ namespace __gnu_debug
>_M_invalidate_locals()
>{
> auto __local_end = _M_cont()._M_base().cend(0);
> +   using __local_end_t = __decltype(__local_end);
> this->_M_invalidate_local_if(
> -   [__local_end](__decltype(__local_end) __it)
> +   [__local_end](__local_end_t __it)
> { return __it != __local_end; });
>}
>  
> @@ -166,7 +167,8 @@ namespace __gnu_debug
>_M_invalidate_all()
>{
> auto __end = _M_cont()._M_base().cend();
> -   this->_M_invalidate_if([__end](__decltype(__end) __it)
> +   using __end_t = __decltype(__end);
> +   this->_M_invalidate_if([__end](__end_t __it)
>{ return __it != __end; });
> _M_invalidate_locals();
>}

[Bug preprocessor/104030] [12 Regression] -Wbidi-chars should not warn about UCNs

[sbergman at redhat dot com via Gcc-bugs]

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

--- Comment #7 from Stephan Bergmann  ---
(In reply to Jakub Jelinek from comment #2)
> Of course, if something like libreoffice (I bet) carefully ensures it is
> paired, but constructs it from smaller separate literals, then it is fine.

(Or doesn't even need to ensure that e.g. a LRO is paired with a PDF, as my
understanding of  "Unicode
Bidirectional Algorithm" is that such an LRO doesn't require a matching PDF, in
which case its effect extends to the end of the paragraph, which appears to be
what the example LibreOffice code in comment 0 makes use of.)

[Bug preprocessor/104030] New: -Wbidi-chars should not warn about UCNs

[sbergman at redhat dot com via Gcc-bugs]

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

Bug ID: 104030
   Summary: -Wbidi-chars should not warn about UCNs
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

As discussed in the sub-thread starting at
<https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585710.html> "Re:
[PATCH] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026]",
-Wbidi-chars should not emit warnings when the problematic characters are
written as UCNs rather than verbatim.  For example, the line

> aText = u"\u202D" + aText;

found in the LibreOffice source code should not cause a warning (which couldn't
even be silenced with a local `#pragma GCC diagnostic ignored "-Wbidi-chars"`
due to bug 53431).

[Bug c++/104007] New: new (std::nothrow) S[n] always calls ~S

[sbergman at redhat dot com via Gcc-bugs]

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

Bug ID: 104007
   Summary: new (std::nothrow) S[n] always calls ~S
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

Apparently a recent regression on GCC trunk:

> $ cat test.cc
> #include 
> #include 
> struct S { ~S() { std::abort(); } };
> int main() {
> new (std::nothrow) S[1];
> }

> $ g++ test.cc
> $ ./a.out
> Aborted (core dumped)

[Bug c++/103991] New: Bogus -Wreturn-type with constexpr if and local var with destructor

[sbergman at redhat dot com via Gcc-bugs]

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

Bug ID: 103991
   Summary: Bogus -Wreturn-type with constexpr if and local var
with destructor
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

Apparently a recent regression on GCC trunk:

> $ cat test.cc
> struct S { ~S(); };
> int f() {
> S s;
> if constexpr (true) return 0;
> else return 0;
> }

> $ g++ -c test.cc
> test.cc: In function ‘int f()’:
> test.cc:6:1: warning: control reaches end of non-void function [-Wreturn-type]
> 6 | }
>   | ^

[Bug c++/103597] New: False -Wimplicit-fallthrough= involving macro

[sbergman at redhat dot com via Gcc-bugs]

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

Bug ID: 103597
   Summary: False -Wimplicit-fallthrough= involving macro
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

I think this is a recent regression on GCC 12 trunk (I'm at
basepoints/gcc-12-5818-g30a08286e67; it doesn't happen with e.g.
gcc-c++-11.2.1-1.fc35.x86_64):

> $ cat test.cc
> #define E(c, e) if (c) e
> int f(int n) {
> switch (n) {
> case 0:
> E(true, return 0);
> case 1:
> return 1;
> }
> return 2;
> }

> $ g++ -c -Wimplicit-fallthrough test.cc
> test.cc: In function ‘int f(int)’:
> test.cc:1:17: warning: this statement may fall through 
> [-Wimplicit-fallthrough=]
> 1 | #define E(c, e) if (c) e
>   | ^~
> test.cc:5:9: note: in expansion of macro ‘E’
> 5 | E(true, return 0);
>   | ^
> test.cc:6:5: note: here
> 6 | case 1:
>   | ^~~~

[Bug libstdc++/103022] New: std::begin on empty std::valarray causes _GLIBCXX_DEBUG assertion

[sbergman at redhat dot com via Gcc-bugs]

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

Bug ID: 103022
   Summary: std::begin on empty std::valarray causes
_GLIBCXX_DEBUG assertion
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

At least with GCC 11.2.1:

> $ cat test.cc
> #include 
> int main() {
> std::valarray v;
> std::begin(v);
> }

> $ g++ -D_GLIBCXX_DEBUG test.cc
> $ ./a.out
> /usr/include/c++/11/valarray:594: _Tp& 
> std::valarray<_Tp>::operator[](std::size_t) [with _Tp = double; std::size_t = 
> long unsigned int]: Assertion '__i < this->size()' failed.
> Aborted

because the std::begin overload is implemented via

  return std::__addressof(__va[0]);

ever since
<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f67a9881a86bcdeb67fa52c0a8eb45ce9d4134d4>
"[multiple changes]" and the std::valarray subscript operator calls

  __glibcxx_requires_subscript(__i);

ever since
<https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=285b36d6a58c08792e78f9fedb3f84bdba3a4eee>
"[multiple changes]".

(See
<https://git.libreoffice.org/core/+/82047d042e9d5d24b334eba63fd7e4c5022e%5E%21>
"crashtesting: assert on conversion of fdo67521-1.odg to pdf" for an issue this
caused in LibreOffice.)

[Bug c++/102101] New: Another spurious -Warray-bounds

[sbergman at redhat dot com via Gcc-bugs]

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

Bug ID: 102101
   Summary: Another spurious -Warray-bounds
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

On recent trunk (basepoints/gcc-12-3135-gdb3d4129b6f):

> $ cat test.cc
> #include 
> #include 
> long dummy();
> void * rtl_allocateMemory();
> struct XInterface {
> virtual void acquire() = 0;
> void release();
> };
> struct WeakComponentImplHelperBase: XInterface {
> static void * operator new(std::size_t) { return rtl_allocateMemory(); }
> static void operator delete(void *);
> virtual void acquire();
> };
> struct XPrimitive2D: XInterface {};
> struct PartialWeakComponentImplHelper: WeakComponentImplHelperBase, 
> XPrimitive2D {
> void acquire() { WeakComponentImplHelperBase::acquire(); }
> };
> struct FillHatchPrimitive2D: PartialWeakComponentImplHelper {
> FillHatchPrimitive2D();
> };
> struct Reference {
> XInterface * _pInterface;
> ~Reference() { if (_pInterface) _pInterface->release(); }
> Reference(XPrimitive2D * pInterface) {
> _pInterface = static_cast(static_cast *>(pInterface));
> if (_pInterface) _pInterface->acquire();
> }
> };
> struct Size {
> Size();
> bool IsEmpty() const { return nA || nB; }
> int nA, nB;
> };
> struct PropertyHolder {
> bool getLineOrFillActive() { return mbLineColor || mbFillColor; }
> bool mbLineColor, mbFillColor;
> };
> struct NonOverlappingFillGradientPrimitive2D: FillHatchPrimitive2D {
> void create2DDecomposition() { if (dummy()) dummy(); }
> NonOverlappingFillGradientPrimitive2D() {}
> };
> void implInterpretMetafile(PropertyHolder & rPropertyHolders) {
> int nCount = dummy();
> int nAction = 0;
> switch(dummy()) {
> case 0:
> while (0 == dummy() && nAction < nCount) {}
> case 1:
> while (0 == dummy() && nAction < nCount) {}
> case 2:
> if (rPropertyHolders.getLineOrFillActive()) {
> Size rRectangle;
> if (rRectangle.IsEmpty()) {
> Size aRange;
> if (aRange.IsEmpty()) dummy();
> }
> }
> case 3:
> if (rPropertyHolders.getLineOrFillActive()) {
> Size rRectangle;
> if (rRectangle.IsEmpty()) {
> Size aRange;
> if (aRange.IsEmpty()) dummy();
> }
> }
> case 4:
> if (rPropertyHolders.getLineOrFillActive()) {
> Size rRectangle;
> if (rRectangle.IsEmpty()) {
> Size aRange;
> if (aRange.IsEmpty()) dummy();
> }
> }
> case 5:
> if (rPropertyHolders.getLineOrFillActive()) {
> Size rRectangle;
> if (rRectangle.IsEmpty()) {
> Size aRange;
> if (aRange.IsEmpty()) dummy();
> }
> }
> case 6:
> if (rPropertyHolders.getLineOrFillActive()) {
> Size rRectangle;
> if (rRectangle.IsEmpty()) {
> Size aRange;
> if (aRange.IsEmpty()) dummy();
> }
> }
> case 7:
> if (rPropertyHolders.getLineOrFillActive()) dummy();
> case 8:
> if (rPropertyHolders.getLineOrFillActive()) dummy();
> case 9:
> if (rPropertyHolders.getLineOrFillActive()) dummy();
> case 10:
> if (rPropertyHolders.getLineOrFillActive()) dummy();
> case 11:
> if (rPropertyHolders.getLineOrFillActive()) dummy();
> case 12:
> {
> int nTextLength = dummy();
> int nTextIndex = dummy();
> int nStringLength = dummy();
> if (nTextLength + nTextIndex > nStringLength) {
> nTextLength = nTextIndex > nStringLength ? 0 : nStringLength 
> - nTextIndex;
> }
> if (nTextLength && dummy()) {
> std::vector< double > aDXArray;
> aDXArray.reserve(nTextLength);
> }
> }
> case 13:
> if (dummy() && dummy())
> if (dummy() && dummy()) dummy();
> case 14:
> {
> Size rRectangle;
> if (rRectangle.IsEmpty() && dummy()) dummy();
>  

[Bug c++/68257] Reject empty abi_tag attribute on inline namespace

[sbergman at redhat dot com via Gcc-bugs]

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

--- Comment #10 from Stephan Bergmann  ---
(In reply to Andrew Pinski from comment #9)
> There does seems some inconsitency though:
> inline namespace n __attribute__((__abi_tag__(""))) {}
> is rejected but
> inline namespace n __attribute__((__abi_tag__())) {}
> 
> Is not.

How is that inconsistent?  When providing the empty string as argument, it is
rejected with "arguments to the ‘abi_tag’ attribute must contain valid
identifiers" (just like e.g.

> inline namespace n __attribute__((__abi_tag__("+"))) {}

would be, too).  But when providing no argument, the behavior documented in
attachment 36974 "updated documentation patch" kicks in.

[Bug c++/101600] New: Spurious -Warray-bounds

[sbergman at redhat dot com via Gcc-bugs]

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

Bug ID: 101600
   Summary: Spurious -Warray-bounds
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

With recent GCC 12 trunk (but not with e.g. gcc-c++-11.1.1-3.fc34.x86_64):

> $ cat test.cc
> struct S1 { virtual ~S1(); };
> struct S2 { int m; };
> struct S3 { virtual ~S3(); };
> struct S4: S1, S2, S3 {};
> int f1();
> void f2(S3 *);
> void f3(S2 * p) {
> for (int i = f1(); f1();) {
> if (i == 0) {
> p = nullptr;
> break;
> }
> }
> f2(static_cast(p));
> }

> $ g++ -c -O2 -Warray-bounds -O2 test.cc
> test.cc: In function ‘void f3(S2*)’:
> test.cc:14:7: warning: array subscript 0 is outside array bounds of ‘S2 
> [2305843009213693951]’ [-Warray-bounds]
>14 | f2(static_cast(p));
>   | ~~^~
> test.cc:7:14: note: at offset -8 into object ‘p’ of size [0, 
> 9223372036854775807]
> 7 | void f3(S2 * p) {
>   | ~^

[Bug c++/100797] [10/11/12 Regression] using declaration causing virtual call with wrongly adjusted this pointer

[sbergman at redhat dot com via Gcc-bugs]

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

--- Comment #6 from Stephan Bergmann  ---
(In reply to Jason Merrill from comment #5)
> Stephan, can you verify that this fixes the LibreOffice issue?

Yes, thanks, tested the master branch fix and it fixes the LibreOffice issue
for me.

[Bug c++/100797] New: using declaration causing virtual call with wrongly adjusted this pointer

[sbergman at redhat dot com via Gcc-bugs]

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

Bug ID: 100797
   Summary: using declaration causing virtual call with wrongly
adjusted this pointer
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

(I stripped this down from an issue found in LibreOffice,
<https://git.libreoffice.org/core/+/0d3dd9d9f6f0e6236c8db8ebdea44c78854639a8%5E%21>
"tdf#142467 crash on calling 'getInfoHelper' in final class", where the
original code had the most derived class, S4 in the below stripped down
example, marked as final, and where removing the "final" fixed things.  In the
below stripped down example, there is no difference in behavior whether or not
S4 is marked final, but I hope the issue exposed by the stripped down example
is still the same as the one originally experienced in the LibreOffice code.)

At least with gcc-11.1.1-1.fc34.x86_64 and with a recent trunk build towards
GCC 12:

> $ cat test.cc
> #include 
> struct S1 { virtual ~S1() = default; };
> struct S2 { virtual void f1() = 0; };
> struct S3: S1, S2 {
> void f1() { f2(); }
> virtual void f2() = 0;
> };
> struct S4: S3 {
> void f2() { std::cout << "called\n"; }
> using S2::f1;
> };
> int main() { S4().f1(); }

> $ g++ test.cc
> $ ./a.out
> Segmentation fault

instead of printing "called".  The issue goes away when removing the

  using S2::f1;

declaration from S4.

[Bug preprocessor/99446] [11 Regression] ICE in linemap_position_for_loc_and_offset, at libcpp/line-map.c:1005

[sbergman at redhat dot com via Gcc-bugs]

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

--- Comment #3 from Stephan Bergmann  ---
(In reply to Stephan Bergmann from comment #2)
> At least with recent GCC master (bc2127767a0076afdbc9075fda29f97f82ef7ec6),
> I can consistently reproduce the following:

what I failed to include in comment 2 is

> $ cat test.cc
> #include 

[Bug preprocessor/99446] [11 Regression] ICE in linemap_position_for_loc_and_offset, at libcpp/line-map.c:1005

[sbergman at redhat dot com via Gcc-bugs]

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

Stephan Bergmann  changed:

   What|Removed |Added

 CC||sbergman at redhat dot com

--- Comment #2 from Stephan Bergmann  ---
At least with recent GCC master (bc2127767a0076afdbc9075fda29f97f82ef7ec6), I
can consistently reproduce the following:

> $ cat dir1/file2
> #pragma GCC diagnostic push
> #include_next 
> #pragma GCC diagnostic pop

> $ cat dir2/file1
> #include 

> $ cat dir2/file2

> $ g++ -Idir1 -Idir2 -fsyntax-only test.cc
> test.cc:2: internal compiler error: in linemap_position_for_loc_and_offset, 
> at libcpp/line-map.c:1005
> 0x1ca855b linemap_position_for_loc_and_offset(line_maps*, unsigned int, 
> unsigned int)
> ../../src/libcpp/line-map.c:1005
> 0xa94ef3 cp_lexer_new_main
> ../../src/gcc/cp/parser.c:676
> 0xa94ef3 c_parse_file()
> ../../src/gcc/cp/parser.c:45237
> 0xbb8ead c_common_parse_file()
> ../../src/gcc/c-family/c-opts.c:1218
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See <https://gcc.gnu.org/bugs/> for instructions.

[Bug c++/98752] New: wrong "error: ‘this’ is not a constant expression" with consteval constructor

[sbergman at redhat dot com via Gcc-bugs]

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

Bug ID: 98752
   Summary: wrong "error: ‘this’ is not a constant expression"
with consteval constructor
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

At least with gcc-c++-10.2.1-9.fc33.x86_64 and with a local GCC 11 trunk build:

> $ cat test.cc
> struct S1 { consteval S1(int) {} };
> struct S2 {
>   S1 x;
>   S2(): x(0) {}
> };

> $ g++ -std=c++20 -fsyntax-only test.cc
> test.cc: In constructor ‘S2::S2()’:
> test.cc:4:12: error: ‘this’ is not a constant expression
> 4 |   S2(): x(0) {}
>   |^

[Bug c++/98305] spurious -Wmismatched-new-delete on template instance

[sbergman at redhat dot com via Gcc-bugs]

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

--- Comment #3 from Stephan Bergmann  ---
(In reply to Martin Sebor from comment #2)
> https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562141.html

Thanks; can confirm that fixes my LibreOffice build.

[Bug c++/98305] New: Incomprehensible -Wmismatched-new-delete warning

[sbergman at redhat dot com via Gcc-bugs]

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

Bug ID: 98305
   Summary: Incomprehensible -Wmismatched-new-delete warning
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

With recent GCC 11 trunk (at git commit
8dede2411195eb2fd672d8d0c758f94732bd6d77):

> $ cat test.cc
> #include 
> template struct Reference {};
> template struct S2 {
>   static void * operator new(std::size_t);
>   static void operator delete(void *);
>   S2();
> };
> void f() { new S2>; }

> $ g++ -Wmismatched-new-delete -c test.cc
> test.cc: In function ‘void f()’:
> test.cc:8:16: warning: ‘static void S2<  >::operator 
> delete(void*) [with  = Reference]’ called on 
> pointer returned from a mismatched allocation function 
> [-Wmismatched-new-delete]
> 8 | void f() { new S2>; }
>   |^~
> test.cc:8:16: note: returned from ‘static void* S2<  
> >::operator new(std::size_t) [with  = Reference]’

(And oddly enough, the warning disappears when Reference is renamed to e.g.
S1.)

[Bug c++/96994] New: Missing code from consteval constructor initializing const variable

[sbergman at redhat dot com]

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

Bug ID: 96994
   Summary: Missing code from consteval constructor initializing
const variable
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

At least with a local build of recent GCC 11 trunk and with
gcc-c++-10.2.1-1.fc32.x86_64:

> $ cat test.cc
> #include 
> struct S1 {
> consteval S1() { i = 1; }
> int i = 0;
> };
> struct S2 {
> constexpr S2() { i = 1; }
> int i = 0;
> };
> S1 const s1a;
> constexpr S1 s1b;
> S2 const s2;
> int main() { std::cout << s1a.i << ' ' << s1b.i << ' ' << s2.i << '\n'; }

> $ g++ -std=c++20 test.cc
> $ ./a.out
> 0 1 1

The first "0" is not as expected, the following two "1" demonstrate how slight
modifications of the code would lead to the expected outcome.

[Bug c++/96878] Failed class template argument deduction in unevaluated, parenthesized context

[sbergman at redhat dot com]

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

--- Comment #1 from Stephan Bergmann  ---
A similar failure happens with typeid (but where the parentheses are not
redundant), and I naively assume it's the same underlying issue:

> $ cat test.cc
> #include 
> template struct S { S(char const (& s)[N]); };
> void f() { (void) typeid (S("")); }

> $ g++ -std=c++17 -fsyntax-only test.cc
> test.cc: In function ‘void f()’:
> test.cc:3:27: error: missing template arguments after ‘S<...auto...>’
> 3 | void f() { (void) typeid (S("")); }
>   |   ^
> test.cc:2:24: note: ‘template struct S’ declared here
> 2 | template struct S { S(char const (& s)[N]); };
>   |^

[Bug c++/96878] New: Failed class template argument deduction in unevaluated, parenthesized context

[sbergman at redhat dot com]

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

Bug ID: 96878
   Summary: Failed class template argument deduction in
unevaluated, parenthesized context
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

At least with recent GCC 11 trunk and with gcc-c++-10.2.1-1.fc32.x86_64:

> $ cat test.cc
> template struct S { S(char const (& s)[N]); };
> auto n = sizeof (S(""));

> $ g++ -std=c++17 -fsyntax-only test.cc
> test.cc:2:18: error: missing template arguments after ‘S<...auto...>’
> 2 | auto n = sizeof (S(""));
>   |  ^
> test.cc:1:24: note: ‘template struct S’ declared here
> 1 | template struct S { S(char const (& s)[N]); };
>   |^

If you change `sizeof (S(""))` to `sizeof S("")`, compilation succeeds.

[Bug c++/96003] [11 Regression] spurious -Wnonnull calling a member on the result of static_cast

[sbergman at redhat dot com]

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

--- Comment #13 from Stephan Bergmann  ---
FTR, with that second patch building recent LibreOffice succeeds without false
positives.

[Bug c++/96003] [11 Regression] spurious -Wnonnull calling a member on the result of static_cast

[sbergman at redhat dot com]

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

--- Comment #11 from Stephan Bergmann  ---
(In reply to Martin Sebor from comment #10)
> Patch for the static cast:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550231.html

LibreOffice runs into the same issue, but while the above patch fixes my first
reduced test case

> $ cat test1.cc
> struct S1 {};
> struct S2: S1 {};
> struct S3: S1 {};
> struct S4: S2, S3 { void f(); };
> void g(S3 * p) { static_cast(p)->f(); }

it does not fix the second

> $ cat test2.cc
> struct S1 { virtual ~S1(); };
> struct S2 { virtual ~S2(); };
> struct S3: S1, S2 { void f() const; };
> void g(S2 * p) { static_cast(p)->f(); }

> $ g++ -Wnonnull -fsyntax-only test2.cc
> test2.cc: In function ‘void g(S2*)’:
> test2.cc:4:48: warning: ‘this’ pointer null [-Wnonnull]
> 4 | void g(S2 * p) { static_cast(p)->f(); }
>   |^
> test2.cc:3:26: note: in a call to non-static member function ‘void S3::f() 
> const’
> 3 | struct S3: S1, S2 { void f() const; };
>   |  ^

[Bug c++/95719] New: SEGV in tree_check

[sbergman at redhat dot com]

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

Bug ID: 95719
   Summary: SEGV in tree_check
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

With a locally-built recent GCC 11 trunk (git rev
48b6386f5d0bdcbe5c901678a043516d544a9f7f), but not with e.g.
gcc-c++-10.1.1-1.fc32.x86_64:

> $ cat test.cc
> struct S1 { virtual ~S1(); };
> struct S2 {
> virtual ~S2();
> virtual void f();
> };
> struct S3 final: S1, S2 { using S2::f; };
> void g(S3 & s) { s.f(); }

> $ g++ -fsyntax-only test.cc
> test.cc: In function ‘void g(S3&)’:
> test.cc:7:22: internal compiler error: Segmentation fault
> 7 | void g(S3 & s) { s.f(); }
>   |  ^
> 0x100471f crash_signal
>   ../../src/gcc/toplev.c:328
> 0x7f245b447aaf ???
>   
> /usr/src/debug/glibc-2.31-17-gab029a2801/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
> 0x8afd41 tree_check(tree_node*, char const*, int, char const*, tree_code)
>   ../../src/gcc/tree.h:3300
> 0x8afd41 lookup_vfn_in_binfo(tree_node*, tree_node*)
>   ../../src/gcc/cp/class.c:2459
> 0x89f872 build_over_call
>   ../../src/gcc/cp/call.c:8697
> 0x8a1a2c build_new_method_call_1
>   ../../src/gcc/cp/call.c:10352
> 0x8a294f build_new_method_call(tree_node*, tree_node*, vec vl_embed>**, tree_node*, int, tree_node**, int)
>   ../../src/gcc/cp/call.c:10427
> 0x9d408c cp_parser_postfix_expression
>   ../../src/gcc/cp/parser.c:7481
> 0x9b61ca cp_parser_binary_expression
>   ../../src/gcc/cp/parser.c:9609
> 0x9b7d2e cp_parser_assignment_expression
>   ../../src/gcc/cp/parser.c:9914
> 0x9b8052 cp_parser_expression
>   ../../src/gcc/cp/parser.c:10082
> 0x9baee8 cp_parser_expression_statement
>   ../../src/gcc/cp/parser.c:11742
> 0x9c6290 cp_parser_statement
>   ../../src/gcc/cp/parser.c:11538
> 0x9c7b68 cp_parser_statement_seq_opt
>   ../../src/gcc/cp/parser.c:11889
> 0x9c7c48 cp_parser_compound_statement
>   ../../src/gcc/cp/parser.c:11839
> 0x9df215 cp_parser_function_body
>   ../../src/gcc/cp/parser.c:23115
> 0x9df215 cp_parser_ctor_initializer_opt_and_function_body
>   ../../src/gcc/cp/parser.c:23166
> 0x9e253d cp_parser_function_definition_after_declarator
>   ../../src/gcc/cp/parser.c:29062
> 0x9e3529 cp_parser_function_definition_from_specifiers_and_declarator
>   ../../src/gcc/cp/parser.c:28978
> 0x9e3529 cp_parser_init_declarator
>   ../../src/gcc/cp/parser.c:20721
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See <https://gcc.gnu.org/bugs/> for instructions.

[Bug c++/95103] Unexpected -Wclobbered in bits/vector.tcc with -O2

[sbergman at redhat dot com]

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

--- Comment #2 from Stephan Bergmann  ---
(In reply to Richard Biener from comment #1)
> Does it work placing the initial part of the function in a separate { }?

Yes,

> @@ -14,11 +14,13 @@
>  return true;
>  }
>  void f3() {
> +{
>  std::vector v;
>  for (int i = 0; i != 2; ++i) {
>  if (!f2("xx")) f1();
>  v.push_back(0);
>  }
> +}
>  std::jmp_buf b;
>  setjmp(b);
>  }

stops the warning for the reproducer.

[Bug c++/95103] New: Unexpected -Wclobbered in bits/vector.tcc with -O2

[sbergman at redhat dot com]

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

Bug ID: 95103
   Summary: Unexpected -Wclobbered in bits/vector.tcc with -O2
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

I have seen this with at least some GCC 7, and still see it with GCC 10 and
with recent trunk:

> $ cat test.cc
> #include 
> #include 
> struct S {
> S(int);
> ~S();
> };
> void f1();
> bool f2(char const (& s)[3]) {
> for (int i = 0; i != 2; ++i) {
> if (s[i] != 'x') {
> return false;
> }
> }
> return true;
> }
> void f3() {
> std::vector v;
> for (int i = 0; i != 2; ++i) {
> if (!f2("xx")) f1();
> v.push_back(0);
> }
> std::jmp_buf b;
> setjmp(b);
> }

> $ g++ -Wclobbered -O2 -c test.cc
> In file included from /usr/include/c++/10/vector:72,
>  from test.cc:2:
> /usr/include/c++/10/bits/vector.tcc: In function ‘void f3()’:
> /usr/include/c++/10/bits/vector.tcc:441:15: warning: variable ‘__new_finish’ 
> might be clobbered by ‘longjmp’ or ‘vfork’ [-Wclobbered]
>   441 |   pointer __new_finish(__new_start);
>   |   ^~~~

[Bug tree-optimization/92893] [10 Regression] Unhelpful -Wstringop-overflow warning for a trailing one-element array

[sbergman at redhat dot com]

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

--- Comment #9 from Stephan Bergmann  ---
(In reply to Martin Sebor from comment #2)
> Defining Str like so works for the test case:
> 
> struct Str {
>   template Str(Cat c)
>   {
> struct Flex { char c, a[]; } *p = (Flex*)get();
> c.add(p->a);
>   }
> };

So I had created  "Silence bogus
-Wstringop-overflow with GCC trunk towards GCC 10" back in last December, and
it sufficed to suppress all those warnings when compiling LibreOffice with
then-trunk GCC, with optimizations enabled.  However, meanwhile GCC has changed
again so that at least one place in the LibreOffice code now produces two
-Werror=stringop-overflow= in one such

  struct Hack { char c; char a[]; };

workaround.  (While in general the workarounds appear to still be effective in
suppressing other such warnings.)  Bisecting, I found that first

> commit ef29b12cfbb4979a89b3cbadbf485a77c8fd8fce
> Author: Martin Sebor 
> Date:   Sat Dec 14 00:52:46 2019 +
> 
> PR middle-end/91582 - missing heap overflow detection for strcpy

caused a new "writing 1 byte into a region of size 0" at

> In file included from /home/user/libreoffice/include/rtl/string.hxx:41,
>  from /home/user/libreoffice/include/rtl/ustring.hxx:37,
>  from 
> /home/user/libreoffice/include/unotest/filters-test.hxx:14,
>  from 
> /home/user/libreoffice/unotest/source/cpp/filters-test.cxx:14:
> In member function ‘char* rtl::OStringConcat::addData(char*) const 
> [with T1 = rtl::OStringLiteral; T2 = const char [2]]’,
> inlined from ‘char* rtl::OStringConcat::addData(char*) const 
> [with T1 = rtl::OStringConcat; T2 = 
> rtl::OString]’ at /home/user/libreoffice/include/rtl/stringconcat.hxx:256:114,
> inlined from ‘rtl::OString::OString(rtl::OStringConcat&&) [with 
> T1 = rtl::OStringConcat; T2 = 
> rtl::OString]’ at /home/user/libreoffice/include/rtl/string.hxx:281:34,
> inlined from ‘void test::FiltersTest::recursiveScan(test::filterStatus, 
> const rtl::OUString&, const rtl::OUString&, const rtl::OUString&, 
> SfxFilterFlags, SotClipboardFormatId, unsigned int, bool)’ at 
> /home/user/libreoffice/unotest/source/cpp/filters-test.cxx:111:67:
> /home/user/libreoffice/include/rtl/stringconcat.hxx:77:11: error: writing 1 
> byte into a region of size 0 [-Werror=stringop-overflow=]
>77 | memcpy( buffer, data, length );
>   | ~~^~~~
> In file included from /home/user/libreoffice/include/rtl/ustring.hxx:37,
>  from 
> /home/user/libreoffice/include/unotest/filters-test.hxx:14,
>  from 
> /home/user/libreoffice/unotest/source/cpp/filters-test.cxx:14:
> /home/user/libreoffice/include/rtl/string.hxx: In member function ‘void 
> test::FiltersTest::recursiveScan(test::filterStatus, const rtl::OUString&, 
> const rtl::OUString&, const rtl::OUString&, SfxFilterFlags, 
> SotClipboardFormatId, unsigned int, bool)’:
> /home/user/libreoffice/include/rtl/string.hxx:280:32: note: at offset 0 to 
> object ‘rtl::OString::OString(rtl::OStringConcat&&) [with T1 = 
> rtl::OStringConcat; T2 = 
> rtl::OString]::Hack::c’ with size 1 declared here
>   280 | struct Hack { char c; char a[]; };
>   |^

and later

> commit a9a437ffc4269650e34af92c4fb095b7ed98f94a
> Author: Jakub Jelinek 
> Date:   Tue Mar 17 13:36:41 2020 +0100
> 
> tree-ssa-strlen: Fix up count_nonzero_bytes* [PR94015]

started to even cause an additional "writing 4 bytes into a region of size 1"

> In file included from /home/user/libreoffice/include/rtl/string.hxx:41,
>  from /home/user/libreoffice/include/rtl/ustring.hxx:37,
>  from 
> /home/user/libreoffice/include/unotest/filters-test.hxx:14,
>  from 
> /home/user/libreoffice/unotest/source/cpp/filters-test.cxx:14:
> In function ‘char* rtl::addDataHelper(char*, const char*, std::size_t)’,
> inlined from ‘static char* 
> rtl::ToStringHelper::addData(char*, const 
> rtl::OStringLiteral&)’ at 
> /home/user/libreoffice/include/rtl/string.hxx:1907:91,
> inlined from ‘char* rtl::OStringConcat::addData(char*) const 
> [with T1 = rtl::OStringLiteral; T2 = const char [2]]’ at 
> /home/user/libreoffice/include/rtl/stringconcat.hxx:222:103,
> inlined from ‘char* rtl::OStringConcat::addData(char*) const 
> [with T1 = rtl::OStringConcat; T2 = 
> rtl::OString]’ at /home/user/libreoffice/include/rtl/stringconcat.hxx:256:114,
> inlined from ‘rtl::OString::OString(rtl::OStringConcat&&) [with 
> T1 = rtl::OStringConcat; T2 = 
> rtl::OString]’ at /home/user/libreoffice/include/rtl/string.hxx:281:34,
> inlined from ‘void test::FiltersTest::recursiveScan(test::filterStatus, 
> const rtl::OUString&, const rtl::OUString&, const rtl::OUString&, 
> SfxFilterFlags, SotClipboardFormatId, unsigned int, bool)’ at 
> 

[Bug lto/94202] New: lto1: internal compiler error: in do_estimate_edge_time, at ipa-inline-analysis.c:222

[sbergman at redhat dot com]

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

Bug ID: 94202
   Summary: lto1: internal compiler error: in
do_estimate_edge_time, at ipa-inline-analysis.c:222
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

At least with current GCC 10 trunk on Linux x86-64:

> $ cat test.cc
> struct S1 {
>   virtual ~S1();
>   virtual void v();
> };
> struct S2: S1 {};
> struct S3: S1, S2 { void v(); };
> struct S4: S3 { void v(); };
> void S4::v() { S3::v(); }
> struct R {
>   S1 * m;
>   void f(S2 * x) {
> static_cast(x)->v();
> x->v();
> m = x;
>   }
> };
> void f() {
>   R r;
>   r.f(new S4);
>   r.f(new S3);
> }

> $ g++ -flto -fPIC -O2 -shared test.cc
> test.cc:6:8: warning: direct base ‘S1’ inaccessible in ‘S3’ due to ambiguity 
> [-Winaccessible-base]
> 6 | struct S3: S1, S2 { void v(); };
>   |^~
> during IPA pass: inline
> lto1: internal compiler error: in do_estimate_edge_time, at 
> ipa-inline-analysis.c:222
> 0x63483d do_estimate_edge_time(cgraph_edge*, sreal*)
> ../../src/gcc/ipa-inline-analysis.c:222
> 0xa6edc0 do_estimate_edge_size(cgraph_edge*)
> ../../src/gcc/ipa-inline-analysis.c:318
> 0x15bb63e estimate_edge_size
> ../../src/gcc/ipa-inline.h:78
> 0x15bb63e inline_small_functions
> ../../src/gcc/ipa-inline.c:2052
> 0x15bb63e ipa_inline
> ../../src/gcc/ipa-inline.c:2685
> 0x15bb63e execute
> ../../src/gcc/ipa-inline.c:3087
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See <https://gcc.gnu.org/bugs/> for instructions.
> lto-wrapper: fatal error: /data/sbergman/gcc/trunk/inst/bin/g++ returned 1 
> exit status
> compilation terminated.
> /usr/bin/ld: error: lto-wrapper failed
> collect2: error: ld returned 1 exit status

What makes that

>   gcc_assert (chk_size == size && chk_time == time
>   && chk_nonspec_time == nonspec_time
>   && chk_hints == hints);

trigger is chk_hints=32 (i.e., INLINE_HINT_declared_inline) vs. hints=33 (i.e.,
INLINE_HINT_indirect_call|INLINE_HINT_declared_inline).

I don't know whether this is related to bug 92508, but that is claimed to be
fixed since November 2019.

[Bug c++/93922] [10 Regression] Fails to emit inline class template destructor instantiation, but which is called

[sbergman at redhat dot com]

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

Stephan Bergmann  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #9 from Stephan Bergmann  ---
(In reply to Jakub Jelinek from comment #8)
> commit r10-7110-g14af5d9b19b0f4ee1d929e505e245ae5c2f6bdc6
> Author: Jason Merrill 
> Date:   Tue Mar 10 16:05:18 2020 -0400
> 
> c++: Partially revert patch for PR66139.

I can confirm that this fixes my original issue (building Skia as part of
LibreOffice), from which the reproducer in comment 0 had been distilled.

[Bug c++/93922] New: Fails to emit inline class template destructor instantiation, but which is called

[sbergman at redhat dot com]

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

Bug ID: 93922
   Summary: Fails to emit inline class template destructor
instantiation, but which is called
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

I came across this when building LibreOffice and its bundled Skia with recent
GCC 10 trunk and it failed to link due to two undefined references.  I hope the
below is a faithfully stripped-down reproducer for the error I encountered:

> $ cat test.cc
> template struct sk_sp {
> template sk_sp(sk_sp const &);
> ~sk_sp() {}
> };
> struct SkPicture {};
> struct Wrapped: SkPicture {
> Wrapped(SkPicture const &);
> };
> struct S {
> sk_sp x;
> Wrapped y;
> };
> sk_sp ref(SkPicture *);
> void f(SkPicture * x, SkPicture const & y) {
> new S(ref(x), y);
> }

> $ g++ -std=c++2a -S test.cc -o - | grep _ZN5sk_spIK9SkPictureED1Ev
> call_ZN5sk_spIK9SkPictureED1Ev

shows that sk_sp::~sk_sp() (i.e., _ZN5sk_spIK9SkPictureED1Ev)
is called (from f) but not emitted.

[Bug c++/93824] -Wredundant-tags false positives

[sbergman at redhat dot com]

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

--- Comment #5 from Stephan Bergmann  ---
(In reply to Stephan Bergmann from comment #4)
> So users will have to be careful when they fix a -Wredundant-tags warning in
> an included file.  They may have to introduce a forward declaration into the
> included file

...or use a qualified name like "::S" as would be necessary in the example
below...

> in order not to break (or silently alter) other translation
> units that also include that file.  (A case where removal of the "redundant"
> tag in the included file inc.h
> 
> > struct S {};
> > namespace N {
> >   int f(struct S); // -Wredundant-tags
> > }
> 
> can silently alter the behavior of another translation unit is when that
> other translation unit contains
> 
> > namespace N { int S = 0; }
> > #include "inc.h"
> 
> so that N::f would now be a variable rather than a function there.)

[Bug c++/93824] -Wredundant-tags false positives

[sbergman at redhat dot com]

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

--- Comment #4 from Stephan Bergmann  ---
(In reply to Martin Sebor from comment #3)
> Ah, I see.  I'm not sure there's anything I can do about the first case --
> the warning there is by design.

So users will have to be careful when they fix a -Wredundant-tags warning in an
included file.  They may have to introduce a forward declaration into the
included file in order not to break (or silently alter) other translation units
that also include that file.  (A case where removal of the "redundant" tag in
the included file inc.h

> struct S {};
> namespace N {
>   int f(struct S); // -Wredundant-tags
> }

can silently alter the behavior of another translation unit is when that other
translation unit contains

> namespace N { int S = 0; }
> #include "inc.h"

so that N::f would now be a variable rather than a function there.)

> Out of curiosity, what is your interest in -Wredundant-tag?  (Are you hoping
> to use it to clean up a code base or something else?)

My motivation is to see if -Wmismatched-tags and -Wredundant-tags could be used
by LibreOffice.  The former would be useful for compatibility with MSVC, where
mismatched tags already produce a warning (i.e., error, with our
--enable-werror regime).  And we have a number of source files that migrated
from C to C++ over time, where the latter could help clean up some accidental
clutter.  (Plus, LibreOffice always proves to be a good testbed for new
diagnostics. :)

[Bug c++/93824] -Wredundant-tags false positives

[sbergman at redhat dot com]

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

--- Comment #2 from Stephan Bergmann  ---
(In reply to Martin Sebor from comment #1)
> The tag is redundant in both cases and can be removed without causing an
> ambiguity.  Why do you think the warnings are wrong?

In the test2.cc case, S has not yet been declared, so the elaborated type
specifier is needed to declare it.

In the test1.cc case, dropping the (redundant) tag from incB.h will cause
test2.cc to no longer compile, see above.

[Bug c++/93869] New: ICE in contains_struct_check with -Wmismatched-tags upon redundant typename

[sbergman at redhat dot com]

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

Bug ID: 93869
   Summary: ICE in contains_struct_check with -Wmismatched-tags
upon redundant typename
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

With recent GCC trunk (incl. the fix from bug 93801 comment 3, though I do not
know whether that makes a difference):

> $ cat test.cc
> namespace N { typedef int T; }
> typename N::T x;

> $ g++ -fsyntax-only -Wmismatched-tags test.cc
> test.cc:2:13: internal compiler error: Segmentation fault
> 2 | typename N::T x;
>   | ^
> 0xfd962f crash_signal
>   ../../src/gcc/toplev.c:328
> 0x7f55158a16af ???
>   
> /usr/src/debug/glibc-2.30-34-g994e529a37/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
> 0x9a1c0f contains_struct_check(tree_node*, tree_node_structure_enum, char 
> const*, int, char const*)
>   ../../src/gcc/tree.h:3391
> 0x9a1c0f cp_parser_check_class_key
>   ../../src/gcc/cp/parser.c:30991
> 0x9c5ad4 cp_parser_elaborated_type_specifier
>   ../../src/gcc/cp/parser.c:18930
> 0x9aea83 cp_parser_type_specifier
>   ../../src/gcc/cp/parser.c:17681
> 0x9afbcf cp_parser_decl_specifier_seq
>   ../../src/gcc/cp/parser.c:14303
> 0x9b0600 cp_parser_simple_declaration
>   ../../src/gcc/cp/parser.c:13557
> 0x9d9302 cp_parser_declaration
>   ../../src/gcc/cp/parser.c:13377
> 0x9d9a82 cp_parser_translation_unit
>   ../../src/gcc/cp/parser.c:4731
> 0x9d9a82 c_parse_file()
>   ../../src/gcc/cp/parser.c:43716
> 0xaedd0b c_common_parse_file()
>   ../../src/gcc/c-family/c-opts.c:1186
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See <https://gcc.gnu.org/bugs/> for instructions.

[Bug c++/93824] New: -Wredundant-tags false positives

[sbergman at redhat dot com]

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

Bug ID: 93824
   Summary: -Wredundant-tags false positives
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

With recent GCC trunk and

> $ cat incA.h
> struct S {};

> $ cat incB.h
> void f(struct S *);

> $ cat test1.cc
> #include "incA.h"
> #include "incB.h"

> $ cat test2.cc
> #include "incB.h"

> $ g++ -Wredundant-tags -fsyntax-only test1.cc
> In file included from test1.cc:2:
> incB.h:1:8: warning: redundant class-key ‘struct’ in reference to ‘struct S’ 
> [-Wredundant-tags]
> 1 | void f(struct S *);
>   |^~
>   |--

> $ g++ -Wredundant-tags -fsyntax-only test2.cc
> In file included from test2.cc:1:
> incB.h:1:8: warning: redundant class-key ‘struct’ in reference to ‘struct S’ 
> [-Wredundant-tags]
> 1 | void f(struct S *);
>   |^~
>   |--

there should IMO not be warnings when compiling neither test1.ccc nor test2.cc.
 test2.cc clearly is a false positive, and arguably test1.cc is as well, albeit
a little more subtly.

[Bug c++/93801] New: False -Wmismatched-tags upon redundant typename

[sbergman at redhat dot com]

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

Bug ID: 93801
   Summary: False -Wmismatched-tags upon redundant typename
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

With recent GCC trunk:

> $ cat test.cc
> namespace N { struct S {}; }
> typename N::S s;
> 
> $ g++ -fsyntax-only -Wmismatched-tags test.cc
> test.cc:2:13: warning: ‘N::S’ declared with a mismatched class-key ‘class’ 
> [-Wmismatched-tags]
> 2 | typename N::S s;
>   | ^
> test.cc:2:13: note: remove the class-key or replace it with ‘struct’
> test.cc:1:22: note: ‘N::S’ defined as ‘struct’ here
> 1 | namespace N { struct S {}; }
>   |  ^

[Bug c++/93273] New: "error: missing definition" and "internal compiler error: verify_ssa failed", in code involving _setjmp

[sbergman at redhat dot com]

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

Bug ID: 93273
   Summary: "error: missing definition" and "internal compiler
error: verify_ssa failed", in code involving _setjmp
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

With recent trunk (at g:ddd792fa53345180c782494aa597e438a73b6248):

> $ cat test.cc
> void _setjmp(void *);
> struct S { ~S(); };
> void * (* fn)();
> void f();
> void g() {
> S s;
> _setjmp(fn());
> []{ f(); }();
> }

> $ g++ -c test.cc
> test.cc: In function ‘void g()’:
> test.cc:5:6: error: missing definition
> 5 | void g() {
>   |  ^
> for SSA_NAME: .MEM_22 in statement:
> # .MEM_14(ab) = VDEF <.MEM_22>
> S::~S ();
> during GIMPLE pass: ehdisp
> test.cc:5:6: internal compiler error: verify_ssa failed
> 0x11c8802 verify_ssa(bool, bool)
> ../../src/gcc/tree-ssa.c:1208
> 0xeeef55 execute_function_todo
> ../../src/gcc/passes.c:1990
> 0xeefc8c do_per_function
> ../../src/gcc/passes.c:1638
> 0xeefc8c execute_todo
> ../../src/gcc/passes.c:2037
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See <https://gcc.gnu.org/bugs/> for instructions.

If I rename _setjmp to e.g. f2, it compiles fine.

[Bug c++/93238] [10 Regression] ICE in tree check: expected integer_cst, have mult_expr in to_wide, at tree.h:5855 since g:337ea6b216afd412

[sbergman at redhat dot com]

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

Stephan Bergmann  changed:

   What|Removed |Added

 CC||sbergman at redhat dot com

--- Comment #1 from Stephan Bergmann  ---
I assume that current trunk

> $ cat test.cc
> enum { E };
> int f(short n) { return n >> E; }

> $ g++ -fsyntax-only test.cc
> test.cc: In function ‘int f(short int)’:
> test.cc:2:30: internal compiler error: tree check: expected integer_cst, have 
> nop_expr in to_wide, at tree.h:5860
> 2 | int f(short n) { return n >> E; }
>   |  ^
[...]

is the same issue.  (Goes away when reverting
g:337ea6b216afd412b85f3fda78a36467ffe4a817.)

[Bug c++/93173] New: "error: incorrect sharing of tree nodes" and "internal compiler error: verify_gimple failed"

[sbergman at redhat dot com]

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

Bug ID: 93173
   Summary: "error: incorrect sharing of tree nodes" and "internal
compiler error: verify_gimple failed"
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

I think this only started recently on GCC trunk, I observe it at least with a
build based on today's 62a72308e1c5479bb3a9e8cacd45d49db219aaec "New bitfield
testcases":

> $ cat test.cc
> template struct S1 {
>   S1(S1 &);
>   ~S1();
> };
> struct S2 {
>   S1 x;
>   int y;
>   int z;
> };
> void f(S1 x, int y, int z) { new S2{x, y, z}; }

> $ g++ -c test.cc
> test.cc: In function ‘void f(S1, int, int)’:
> test.cc:10:6: error: incorrect sharing of tree nodes
>10 | void f(S1 x, int y, int z) { new S2{x, y, z}; }
>   |  ^
> MEM[(struct S2 *)D.2374]
> MEM[(struct S2 *)D.2374].z = z;
> during GIMPLE pass: cfg
> test.cc:10:6: internal compiler error: verify_gimple failed
> 0xfda96a verify_gimple_in_cfg(function*, bool)
>   ../../src/gcc/tree-cfg.c:5445
> 0xec1caf execute_function_todo
>   ../../src/gcc/passes.c:1983
> 0xec2aec do_per_function
>   ../../src/gcc/passes.c:1638
> 0xec2aec execute_todo
>   ../../src/gcc/passes.c:2037
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See <https://gcc.gnu.org/bugs/> for instructions.

(I assume this is a different issue than open issue 93033, given my build
includes b5cabe5e4b2778223d7a910ac3a5bbd61bff007c "PR c++/93033 - incorrect
tree node sharing with array init.")

[Bug c++/92893] [10 Regression] Unhelpful -Wstringop-overflow warning for a trailing one-element array

[sbergman at redhat dot com]

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

--- Comment #4 from Stephan Bergmann  ---
(FWIW, the amount of cases where this issue hits the build of LibreOffice seems
to have increased further with more recent GCC trunk builds after I filed the
issue.)

[Bug c++/92893] New: Unhelpful -Wstringop-overflow warning

[sbergman at redhat dot com]

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

Bug ID: 92893
   Summary: Unhelpful -Wstringop-overflow warning
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

Recent GCC 10 trunk produces a -Wstringop-overflow warning that at least
gcc-c++-9.2.1-1.fc31.x86_64 does not produce.  Unfortunately the minimal
reproducer I came up with is still a bit lengthy:

> $ cat test.cc
> #include 
> 
> struct View {
>   View(char const * s): s_(s), n_(std::strlen(s)) {}
>   char const * s_;
>   std::size_t n_;
> };
> 
> template struct Add {
>   static char * add(char * buf, T const &);
> };
> 
> template struct Add {
>   static char * add(char * buf, char const s[N]) {
> std::memcpy(buf, s, N);
> return buf + N;
>   }
> };
> 
> template<> struct Add {
>   static char * add(char * buf, View const & v) {
> std::memcpy(buf, v.s_, v.n_);
> return buf + v.n_;
>   }
> };
> 
> template struct Cat {
>   Cat(T1 const & x, T2 const & y): x_(x), y_(y) {}
>   char * add(char * buf) const
>   { return Add::add(Add::add(buf, x_), y_); }
>   T1 const & x_;
>   T2 const & y_;
> };
> 
> template struct Add> {
>   static char * add(char * buf, Cat const & c) { return c.add(buf); }
> };
> 
> Cat catA(char const()[1], View const & y) {
>   return {x, y};
> }
> 
> Cat, char const[4]> catB(
>   Cat const & x, char const ()[4])
> {
>   return {x, y};
> }
> 
> struct Buf { char buf[1]; };
> 
> Buf * get();
> 
> struct Str {
>   template Str(Cat c)
>   { c.add(get()->buf); }
> };
> 
> void f(char const * p) { Str(catB(catA("", View(p)), "xxx")); }

> $ g++ -O2 -c test.cc
> In member function ‘char* Cat::add(char*) const [with T1 = Cat char [1], View>; T2 = const char [4]]’,
> inlined from ‘Str::Str(Cat) [with T1 = Cat; 
> T2 = const char [4]]’ at test.cc:55:10,
> inlined from ‘void f(const char*)’ at test.cc:58:26:
> test.cc:15:16: warning: writing 4 bytes into a region of size 1 
> [-Wstringop-overflow=]
>15 | std::memcpy(buf, s, N);
>   | ~~~^~~

The warning only appears with this specific case where catB takes a char[4],
not for other char[N].

Buff::buf is meant to be a trailing flexible array member.  In the original
code, it needs to stay that way for compatibility reasons, but also if it is
replaced with the canonical GCC-extended flexible array member syntax,

> struct Buf { char buf[0]; };

the warning remains (this time as "writing 4 bytes into a region of size 0").

At least in the original code, I found no range of code that could be wrapped
in

> #pragma GCC diagnostic push
> #pragma GCC diagnostic ignored "-Wstringop-overflow"
[...]
> #pragma GCC diagnostic push

short of disabling the warning completely.  But maybe there is a way to
annotate the call to c.add(get()->buf) in the Str constructor, to break the
connection that Buf::buf is nominally of size 1 there?

[Bug c++/88136] -Wdeprecated-copy is draconian and shouldn't be in -Wall

[sbergman at redhat dot com]

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

Stephan Bergmann  changed:

   What|Removed |Added

 CC||sbergman at redhat dot com

--- Comment #9 from Stephan Bergmann  ---
(In reply to Ville Voutilainen from comment #2)
> This is not just a Qt problem. I will write a proposal to undeprecate this
> deprecation for C++20 before the next committee meeting.

Can you give a link to that proposal?

[Bug preprocessor/92696] #pragma GCC diagnostic ... interferes with if/else

[sbergman at redhat dot com]

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

--- Comment #5 from Stephan Bergmann  ---
...but something that needs proper documentation?

[Bug preprocessor/92696] New: #pragma GCC diagnostic ... interferes with if/else

[sbergman at redhat dot com]

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

Bug ID: 92696
   Summary: #pragma GCC diagnostic ... interferes with if/else
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

At least with "gcc (GCC) 9.2.1 20190827 (Red Hat 9.2.1-1)" and with recent GCC
10 trunk:

> $ cat test.c
> void f(int);
> void g(int b) {
>   if (b)
> f(0);
> #pragma GCC diagnostic ignored "-Wformat"
>   else
> f(1);
> }

> $ gcc -fsyntax-only test.c
> test.c: In function ‘g’:
> test.c:6:3: error: ‘else’ without a previous ‘if’
> 6 |   else
>   |   ^~~~

[Bug c++/92598] New: explicit specialization of template from unnamed namespace using unqualified-id in enclosing namespace

[sbergman at redhat dot com]

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

Bug ID: 92598
   Summary: explicit specialization of template from unnamed
namespace using unqualified-id in enclosing namespace
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

At least with "gcc (GCC) 9.2.1 20190827 (Red Hat 9.2.1-1)",

> $ cat test.cc
> namespace { template class C; }
> template<> class C;

> $ g++ -fsyntax-only -std=c++17 test.cc
> test.cc:2:18: error: explicit specialization of ‘template class 
> {anonymous}::C’ outside its namespace must use a nested-name-specifier 
> [-fpermissive]
> 2 | template<> class C;
>   |  ^~~

That appears to violate the note added with
<http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1838> "Definition
via unqualified-id and using-declaration":

"[Note: An explicit instantiation (17.8.2 [temp.explicit]) or explicit
specialization (17.8.3 [temp.expl.spec]) of a template does not introduce a
name and thus may be declared using an unqualified-id in a member of the
enclosing namespace set, if the primary template is declared in an inline
namespace. —end note]"

[Bug c++/92201] [9/10 Regression] "internal compiler error: ‘verify_gimple’ failed" with -std=c++2a

[sbergman at redhat dot com]

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

--- Comment #3 from Stephan Bergmann  ---
(In reply to Jakub Jelinek from comment #2)
> Untested fix.

Building LibreOffice (from which I had distilled the reproducer) works fine for
me again with that patch.  Thanks!

[Bug c++/92201] New: "internal compiler error: ‘verify_gimple’ failed" with -std=c++2a

[sbergman at redhat dot com]

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

Bug ID: 92201
   Summary: "internal compiler error: ‘verify_gimple’ failed" with
-std=c++2a
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

With recent trunk:

> $ gcc/trunk/inst/bin/g++ --version
> g++ (GCC) 10.0.0 20191023 (experimental)
> Copyright (C) 2019 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

> $ cat test.cc
> int f(void (*p)()) { return (*reinterpret_cast(p))(); }

> $ gcc/trunk/inst/bin/g++ -std=c++2a -c test.cc
> test.cc: In function ‘int f(void (*)())’:
> test.cc:1:5: error: invalid conversion in gimple call
> 1 | int f(void (*p)()) { return (*reinterpret_cast(p))(); }
>   | ^
> int
> 
> void
> 
> D.2079 = p.0_1 ();
> test.cc:1:5: internal compiler error: ‘verify_gimple’ failed
> 0xeebc2d verify_gimple_in_seq(gimple*)
>   ../../src/gcc/tree-cfg.c:5079
> 0xc4ea46 gimplify_body(tree_node*, bool)
>   ../../src/gcc/gimplify.c:14440
> 0xc4ec13 gimplify_function_tree(tree_node*)
>   ../../src/gcc/gimplify.c:14530
> 0xada597 cgraph_node::analyze()
>   ../../src/gcc/cgraphunit.c:667
> 0xadcdcf analyze_functions
>   ../../src/gcc/cgraphunit.c:1126
> 0xadd9b2 symbol_table::finalize_compilation_unit()
>   ../../src/gcc/cgraphunit.c:2840
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See <https://gcc.gnu.org/bugs/> for instructions.

[Bug c++/92001] New: missing -Wclass-memaccess with array as first argument to memset

[sbergman at redhat dot com]

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

Bug ID: 92001
   Summary: missing -Wclass-memaccess with array as first argument
to memset
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

With at least both GCC 9.2.1 and recent trunk towards GCC 10,

  #include 
  struct S { S(); };
  void f() {
S s[1];
std::memset(s, 0, sizeof s);
  }

does not emit a -Wclass-memaccess (but it does when you change s to be of
non-array type).

(See
<https://gerrit.libreoffice.org/plugins/gitiles/core/+/d03041e19215592f21ba1222d3cfa29e1f94260a%5E%21>
"Drop bogus memsets" for a real-life case of such a false negative.  There were
about half a dozen similar cases across the LibreOffice code base.)

[Bug preprocessor/71102] _Pragma("GCC warning ...") should concatenate string literals

[sbergman at redhat dot com]

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

Stephan Bergmann  changed:

   What|Removed |Added

 CC||sbergman at redhat dot com

--- Comment #1 from Stephan Bergmann  ---
This affects deprecation warnings emitted by GLib, see the discussion in the
commit message of
<https://gitlab.gnome.org/GNOME/glib/commit/91cb1710574309b4c52b388bb5cc7a4e899050bc>
"Improve GLIB_DEPRECATED_MACRO_FOR output":  "That recent GCC only prints
'Deprecated pre-processor symbol, repace with ' appears to be a bug in GCC that
GLIB_UNAVAILABLE_MACRO already suffers from, too."  (Though it's not a bug but
just unexpected implementation-defined behavior, especially unexpected given
that unlike

  #pragma GCC warning "foo" "bar"

the similar

  #pragma message "foo" "bar"

does print all the given strings and not just the first one.)

[Bug c++/91391] Bogus -Wcomma-subscript

[sbergman at redhat dot com]

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

--- Comment #5 from Stephan Bergmann  ---
(In reply to Stephan Bergmann from comment #0)
[...]
> template-parameter-list, and I wonder whether it should warn about a
> (hypothetical) comma expression in a call to an overloaded operator [] at
> all.

([expr.pre]/2 "Overloaded operators obey the rules for syntax and evaluation
order specified in [expr.compound], but the requirements of operand type and
value category are replaced [...]", so it presumably shall warn there)

[Bug c++/91391] New: Bogus -Wcomma-subscript

[sbergman at redhat dot com]

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

Bug ID: 91391
   Summary: Bogus -Wcomma-subscript
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

With recent git master (4ad9380bafd772cea54392c7189cab07a2121fc9 here):

> $ cat test.cc
> #include 
> #include 
> int main() {
> std::map, int> m;
> m[std::pair(0, 0)] = 0;
> }

> $ g++ -fsyntax-only -std=c++2a test.cc
> test.cc: In function ‘int main()’:
> test.cc:5:20: warning: top-level comma expression in array subscript is 
> deprecated [-Wcomma-subscript]
> 5 | m[std::pair(0, 0)] = 0;
>   |^

It should apparently not warn about the nested comma in the
template-parameter-list, and I wonder whether it should warn about a
(hypothetical) comma expression in a call to an overloaded operator [] at all.

[Bug c++/90909] New: call devirtualized to pure virtual

[sbergman at redhat dot com]

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

Bug ID: 90909
   Summary: call devirtualized to pure virtual
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

Recent trunk (I'm at git rev 665de37f60068204ea9b4757dd79bc7f75588733) started
to miscompile

> $ cat test.cc
> struct S1 { virtual void f() = 0; };
> struct S2: S1 { virtual void f() {} };
> struct S3: S2 { using S1::f; };
> struct S4 final: S3 { void g(); };
> void S4::g() { f(); }
> int main() { S4().g(); }

> $ gcc/trunk/inst/bin/g++ test.cc
> /usr/bin/ld: /tmp/ccCRKkqm.o: in function `S4::g()':
> test.cc:(.text+0x14): undefined reference to `S1::f()'
> collect2: error: ld returned 1 exit status

(If you look at the disassembly, it's the call of f() in S4::g that gets
devirtualized to S1::f.)

[Bug debug/90575] -gsplit-dwarf leaves behind .dwo file in cwd

[sbergman at redhat dot com]

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

--- Comment #3 from Stephan Bergmann  ---
Or, to put it differently:  It looks odd that while `gcc -gsplit-dwarf -c
test.c -o /path/test.o` puts test.dwo next to test.o into /path/, `gcc
-gsplit-dwarf test.c -o /path/test` puts it into cwd.

[Bug debug/90575] -gsplit-dwarf leaves behind .dwo file in cwd

[sbergman at redhat dot com]

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

--- Comment #2 from Stephan Bergmann  ---
(In reply to Richard Biener from comment #1)
> But that's how -gsplit-dwarf is designed.

Shouldn't it then be documented where any .dwo files are stored?  At least in
combination with -o in comment 0, cwd looks like a strange choice.

[Bug debug/90575] New: -gsplit-dwarf leaves behind .dwo file in cwd

[sbergman at redhat dot com]

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

Bug ID: 90575
   Summary: -gsplit-dwarf leaves behind .dwo file in cwd
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

At least with current GCC 9.1.1:

> $ mkdir testdir
> $ echo 'int main(void) { return 0; }' > testdir/test.c
> $ gcc -gsplit-dwarf testdir/test.c -o testdir/test
> $ ls
> testdir  test.dwo

I at least wouldn't expect the above to leave behind a test.dwo in the current
working dir.

[Bug c++/86586] [7/8/9 Regression] -Wsign-compare affects code generation

[sbergman at redhat dot com]

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

Stephan Bergmann  changed:

   What|Removed |Added

 CC||sbergman at redhat dot com

--- Comment #10 from Stephan Bergmann  ---
(In reply to Jason Merrill from comment #8)
> Author: jason
> Date: Wed Apr  3 20:12:00 2019
> New Revision: 270136
> 
> URL: https://gcc.gnu.org/viewcvs?rev=270136=gcc=rev
> Log:
>   PR c++/86586 - -fcompare-debug=-Wsign-compare.
> 
> This patch limits constexpr folding for -Wsign-compare to only cases that we
> would warn for without considering constant values, avoiding the folding in
> the testcase in question.

Starting with that commit,

  constexpr int f() { return 0; }
  bool b = f() != 0xU;

now emits a -Wsign-compare, while the similar

  constexpr int f() { return 0; }
  constexpr int n = f();
  bool b = n != 0xU;

still does not.

I assume that is an unintended regression?

[Bug preprocessor/90382] New: internal compiler error: in linemap_macro_map_loc_to_exp_point, at libcpp/line-map.c:1061

[sbergman at redhat dot com]

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

Bug ID: 90382
   Summary: internal compiler error: in
linemap_macro_map_loc_to_exp_point, at
libcpp/line-map.c:1061
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

I encountered this ICE with recent GCC trunk with

  #include "boost/spirit/include/phoenix.hpp"

but could only strip it down to the following reproducer that still includes
some boost/preprocessor/ include files (from boost-devel-1.69.0-6.fc30.x86_64
on Fedora 30 in my case).  The failure was not reproducible with -E
preprocessed sources.

$ cat test.cc
> #include "boost/preprocessor/repetition/enum_params.hpp"
> #include "boost/preprocessor/repetition/repeat_from_to.hpp"
> 
> template struct S {};
> 
> #define N S
> 
> #define M(z, n, d) template void 
> f(N const &);
> 
> BOOST_PP_REPEAT_FROM_TO(0, 1, M,)

$ gcc/trunk/inst/bin/g++ -c test.cc
> test.cc:8:109: internal compiler error: in 
> linemap_macro_map_loc_to_exp_point, at libcpp/line-map.c:1061
> 8 |  d) template void 
> f(N const &);
>   |   
>^
> 
> /usr/include/boost/preprocessor/repetition/repeat_from_to.hpp:83:54: note: in 
> expansion of macro ‘M’
>83 | # define BOOST_PP_REPEAT_FROM_TO_M_1_II(z, n, m, dt) m(z, n, dt)
>   |  ^
> 0x18ecbef linemap_macro_map_loc_to_exp_point
>   ../../src/libcpp/line-map.c:1061
> 0x18ecbef linemap_macro_map_loc_to_exp_point
>   ../../src/libcpp/line-map.c:1054
> 0x18ee6a7 first_map_in_common_1
>   ../../src/libcpp/line-map.c:1269
> 0x18ee6a7 first_map_in_common
>   ../../src/libcpp/line-map.c:1306
> 0x18ee6a7 linemap_compare_locations(line_maps*, unsigned int, unsigned int)
>   ../../src/libcpp/line-map.c:1349
> 0x905d8d linemap_location_before_p(line_maps*, unsigned int, unsigned int)
>   ../../src/gcc/../libcpp/include/line-map.h:1273
> 0x905d8d min_location
>   ../../src/gcc/cp/decl.c:10069
> 0x91cdbb grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*, 
> decl_context, int, tree_node**)
>   ../../src/gcc/cp/decl.c:10427
> 0x9c3e0e cp_parser_parameter_declaration_list
>   ../../src/gcc/cp/parser.c:22197
> 0x9c41ab cp_parser_parameter_declaration_clause
>   ../../src/gcc/cp/parser.c:22114
> 0x9b8d9d cp_parser_direct_declarator
>   ../../src/gcc/cp/parser.c:20806
> 0x9b8d9d cp_parser_declarator
>   ../../src/gcc/cp/parser.c:20674
> 0x9c6bb5 cp_parser_init_declarator
>   ../../src/gcc/cp/parser.c:20184
> 0x9ca294 cp_parser_single_declaration
>   ../../src/gcc/cp/parser.c:28268
> 0x9caed7 cp_parser_explicit_specialization
>   ../../src/gcc/cp/parser.c:17323
> 0x9cd826 cp_parser_declaration
>   ../../src/gcc/cp/parser.c:13184
> 0x9cde1f cp_parser_translation_unit
>   ../../src/gcc/cp/parser.c:4701
> 0x9cde1f c_parse_file()
>   ../../src/gcc/cp/parser.c:41181
> 0xad3beb c_common_parse_file()
>   ../../src/gcc/c-family/c-opts.c:1156
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See <https://gcc.gnu.org/bugs/> for instructions.

[Bug c++/89507] New: bogus "size of array exceeds maximum object size"

[sbergman at redhat dot com]

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

Bug ID: 89507
   Summary: bogus "size of array exceeds maximum object size"
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
CC: caolanm at redhat dot com, msebor at gcc dot gnu.org
  Target Milestone: ---

With current trunk (towards GCC 9),

> $ cat test.cc
> unsigned char const n = 128;
> int * p = new int[n];
>
> $ g++ -c test.cc
> test.cc:2:20: error: size ‘128’ of array exceeds maximum object size 
> ‘9223372036854775807’
> 2 | int * p = new int[n];
>   |^

This looks like a regression introduced with
<https://gcc.gnu.org/viewcvs/gcc?view=revision=268774> "PR c++/87996 -
size of array is negative error when SIZE_MAX/2 < sizeof(array) <= SIZE_MAX". 
(This breaks the build of LibreOffice,

> [CXX] i18npool/source/characterclassification/cclass_unicode_parser.cxx
> i18npool/source/characterclassification/cclass_unicode_parser.cxx: In member 
> function ‘void i18npool::cclass_Unicode::initParserTable(const 
> com::sun::star::lang::Locale&, sal_Int32, const rtl::OUString&, sal_Int32, 
> const rtl::OUString&)’:
> i18npool/source/characterclassification/cclass_unicode_parser.cxx:417:45: 
> error: size ‘128’ of array exceeds maximum object size ‘9223372036854775807’
>   417 | pTable.reset(new ParserFlags[nDefCnt]);
>   | ^

.)

[Bug ipa/89009] [7/8/9 Regression] Miscompilation (missing function call) with -fvisibility=hidden -fpic -O2 -fno-inline

[sbergman at redhat dot com]

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

--- Comment #8 from Stephan Bergmann  ---
...and adding to the test.cc from comment 0 an additional

> $ cat main.cc
> void f1();
> struct S1 { static void f2(); };
> struct __attribute__ ((visibility("default"))) S2: S1 { static void f2(); };
> struct S3: S1 { static void f2(); };
> struct S4: S3 { static void f2(); };
> void f1() { __builtin_printf("f1\n"); }
> void S1::f2() { __builtin_printf("S1::f2\n"); }
> int main() { S4::f2(); }
> 
> $ g++ -fvisibility=hidden -fpic -O2 -fno-inline test.cc main.cc
> $ ./a.out
> f1

to form a complete program still fails for me (GCC 8.2.1).

[Bug ipa/89009] [7/8/9 Regression] Miscompilation (missing function call) with -fvisibility=hidden -fpic -O2 -fno-inline

[sbergman at redhat dot com]

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

--- Comment #6 from Stephan Bergmann  ---
(In reply to Martin Liška from comment #5)
> Well, I believe the test-case is invalid as one can't have hidden visibility
> and then defined S1::f2 in a different translation unit.

Why?  Isn't hidden visibility just about symbol visibility at the
executable/dynamic library level?

[Bug c++/89009] New: Miscompilation (missing function call) with -fvisibility=hidden -fpic -O2 -fno-inline

[sbergman at redhat dot com]

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

Bug ID: 89009
   Summary: Miscompilation (missing function call) with
-fvisibility=hidden -fpic -O2 -fno-inline
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

On Linux x86-64 with at least with GCC 8.2.1 (gcc-8.2.1-6.fc29.x86_64) and
recent trunk towards GCC 9, compiling

> $ cat test.cc
> void f1();
> struct S1 { static void f2(); };
> struct __attribute__ ((visibility("default"))) S2: S1 { static void f2(); };
> struct S3: S1 { static void f2(); };
> struct S4: S3 { static void f2(); };
> void S2::f2() { S1::f2(); }
> void S3::f2() { S1::f2(); }
> void S4::f2() {
> f1();
> S3::f2(); // MISSING
> }
> 
> $ g++ -fvisibility=hidden -fpic -O2 -fno-inline -S test.cc

causes the call to S3::f2 to be missing from the code generated for S4::f2:

> .globl  _ZN2S42f2Ev
> .hidden _ZN2S42f2Ev
> .type   _ZN2S42f2Ev, @function
> _ZN2S42f2Ev:
> .LFB2:
> .cfi_startproc
> jmp _Z2f1v@PLT
> .cfi_endproc
> .LFE2:
> .size   _ZN2S42f2Ev, .-_ZN2S42f2Ev

[Bug c++/87150] [8 Regression] move ctor wrongly chosen in return stmt (derived vs. base)

[sbergman at redhat dot com]

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

--- Comment #18 from Stephan Bergmann  ---
(In reply to Jonathan Wakely from comment #17)
> Yes please.

bug 87378

[Bug c++/87378] New: False -Wredundant-move (derived vs. base)

[sbergman at redhat dot com]

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

Bug ID: 87378
   Summary: False -Wredundant-move (derived vs. base)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

On recent trunk, with bug 87150 fixed (so that the compiler agrees that the
std::move is actually required):

> ~ cat test.cc
> #include 
> struct S1 { S1(S1 &&); };
> struct S2: S1 {};
> S1 f(S2 s) { return std::move(s); }
> 
> ~ g++ -Wredundant-move -c test.cc
> test.cc: In function ‘S1 f(S2)’:
> test.cc:4:30: warning: redundant move in return statement [-Wredundant-move]
> 4 | S1 f(S2 s) { return std::move(s); }
>   | ~^~~
> test.cc:4:30: note: remove ‘std::move’ call

[Bug c++/87150] [8 Regression] move ctor wrongly chosen in return stmt (derived vs. base)

[sbergman at redhat dot com]

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

--- Comment #16 from Stephan Bergmann  ---
(In reply to Stephan Bergmann from comment #15)
> I see that with the fix from comment 13 included, the slightly changed source
> 
>   #include 
>   struct S1 { S1(S1 &&); };
>   struct S2: S1 {};
>   S1 f(S2 s) { return std::move(s); }
> 
> causes -Wredundant-move (when that warning is explicitly requested).

Shall I file a separate issue for that?

[Bug c++/87150] [8 Regression] move ctor wrongly chosen in return stmt (derived vs. base)

[sbergman at redhat dot com]

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

--- Comment #15 from Stephan Bergmann  ---
I see that with the fix from comment 13 included, the slightly changed source

  #include 
  struct S1 { S1(S1 &&); };
  struct S2: S1 {};
  S1 f(S2 s) { return std::move(s); }

causes -Wredundant-move (when that warning is explicitly requested).

[Bug c++/87150] [8/9 Regression] move ctor wrongly chosen in return stmt (derived vs. base)

[sbergman at redhat dot com]

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

--- Comment #9 from Stephan Bergmann  ---
(In reply to Marek Polacek from comment #8)
> It appears that the sentiment is that this testcase should actually be
> valid

Do you have a reference for that?  The reason for this not to be valid,
presented at the bottom of
 "Re:
[cfe-dev] return lvalue move instead of copy?" looks rather convincing to me.

[Bug c++/87150] [8/9 Regression] move ctor wrongly chosen in return stmt (derived vs. base)

[sbergman at redhat dot com]

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

--- Comment #3 from Stephan Bergmann  ---
(In reply to Jakub Jelinek from comment #2)
> This changed with r251035 aka PR80452 aka C++ Core issue 1579.
> So, is this really invalid?

but CWG1579 didn't change the "if the type of the first parameter of the
selected constructor is not an rvalue reference to the object’s type (possibly
cv-qualified), overload resolution is performed again, considering the object
as an
lvalue." part

[Bug c++/87150] New: move ctor wrongly chosen in return stmt (derived vs. base)

[sbergman at redhat dot com]

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

Bug ID: 87150
   Summary: move ctor wrongly chosen in return stmt (derived vs.
base)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

struct S1 { S1(S1 &&); };
  struct S2: S1 {};
  S1 f(S2 s) { return s; }

is accepted by GCC 8.1 but violates [class.copy.elision]/3, which dismisses the
move ctor if "the type of the first parameter of the selected constructor is
not an rvalue reference to the object’s type (possibly cv-qualified)" (and
which is the case here, where the object's type is S2 but the ctor parameter's
type is S1&&.  (Referring to C++17, but wording is similar back to C++11, and
GCC's behavior is the same for -std=c++{11,14,17}.)

Checking on godbolt.org, the error of accepting the code appears to have been
introduced between GCC 7.3 and 8.1.

(Also see mail thread starting at
<http://lists.llvm.org/pipermail/cfe-dev/2018-August/059186.html> "return
lvalue move instead of copy?".)

[Bug libstdc++/86658] New: Debug mode: std::copy(..., std::inserter(...)) causes "Error: attempt to copy-construct an iterator from a singular iterator."

[sbergman at redhat dot com]

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

Bug ID: 86658
   Summary: Debug mode: std::copy(..., std::inserter(...)) causes
"Error: attempt to copy-construct an iterator from a
singular iterator."
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

With recent GCC trunk:

> $ cat test.cc
> #define _GLIBCXX_DEBUG
> #include 
> #include 
> #include 
> int main() {
>   std::vector v1{0};
>   std::vector v2;
>   std::copy(v1.begin(), v1.end(), std::inserter(v2, v2.end()));
>   std::copy(v1.begin(), v1.end(), std::inserter(v2, v2.end()));
> }
> 
> $ gcc/inst/bin/g++ --version
> g++ (GCC) 9.0.0 20180724 (experimental)
> Copyright (C) 2018 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> $ gcc/inst/bin/g++ test.cc
> $ LD_LIBRARY_PATH=/home/sbergman/gcc/inst/lib64 ./a.out
> /home/sbergman/gcc/inst/include/c++/9.0.0/debug/safe_iterator.h:140:
> In function:
> __gnu_debug::_Safe_iterator<_Iterator, _Sequence>::_Safe_iterator(const 
> __gnu_debug::_Safe_iterator<_Iterator, _Sequence>&) [with _Iterator = 
> __gnu_cxx::__normal_iterator std::allocator > >; _Sequence = std::__debug::vector]
> 
> Error: attempt to copy-construct an iterator from a singular iterator.
> 
> Objects involved in the operation:
> iterator "this" @ 0x0x7fff69d830c8 {
>   type = __gnu_cxx::__normal_iterator std::allocator > > (mutable iterator);
>   state = singular;
> }
> iterator "other" @ 0x0x7fff69d83178 {
>   type = __gnu_cxx::__normal_iterator std::allocator > > (mutable iterator);
>   state = singular;
>   references sequence with type 'std::__debug::vector std::allocator >' @ 0x0x7fff69d83280
> }
> Aborted (core dumped)

[Bug c/86196] New: Bogus -Wrestrict on memcpy

[sbergman at redhat dot com]

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

Bug ID: 86196
   Summary: Bogus -Wrestrict on memcpy
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

With recent trunk (on Linux x86_64), and doesn't seem to be covered by existing
bugs referenced from meta bug 84774:

> $ gcc --version
> gcc (GCC) 9.0.0 20180618 (experimental)
> Copyright (C) 2018 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

> $ cat test.c
> #include 
> struct S {
> int n;
> void * p;
> };
> void f(struct S * a, size_t n) {
> size_t i = 0, j = 0;
> for (; i != n; ++i) {
> if (a[i].n == 0) {
> if (i != j) {
> memcpy([j], [i], sizeof (struct S));
> }
> ++j;
> }
> }
> }

> $ gcc -Wall -c test.c
> test.c: In function ‘f’:
> test.c:11:17: warning: ‘memcpy’ accessing 16 bytes at offsets [0, 8] and [0, 
> 8] overlaps between 8 and 16 bytes at offset [0, 8] [-Wrestrict]
>  memcpy([j], [i], sizeof (struct S));
>  ^~~

Also, I do not understand what that "offset [0, 8]" notation is supposed to
mean.

[Bug c++/71882] elaborated-type-specifier friend not looked up in unnamed namespace

[sbergman at redhat dot com]

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

--- Comment #3 from Stephan Bergmann  ---
(In reply to Jonathan Wakely from comment #2)
> 10.3.1.2 [namespace.memdef] p3 says "the lookup to determine whether the
> entity has been previously declared shall not consider any scopes outside
> the innermost enclosing namespace." The struct S is not declared in the
> innermost enclosing namespace, but it is visible there, so normal name
> lookup would find it. But then this isn't normal name lookup, because it
> doesn't keep looking in enclosing namespaces, only the innermost.

I guess when I originally filed this bug I interpreted the quoted part of
[namespace.memdef] to mean that the lookup is done as per 6.4.1
[basic.lookup.unqual] but ignores scopes *outside* the innermost enclosing
namespace, but not scopes *inside* it, like a nested unnamed namespace.

[Bug c++/83942] New: False -Wunused-but-set-variable when const scoped enum is cast to int

[sbergman at redhat dot com]

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

Bug ID: 83942
   Summary: False -Wunused-but-set-variable when const scoped enum
is cast to int
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

With recent trunk "g++ (GCC) 8.0.1 20180119 (experimental)" towards GCC 8:

> $ cat test.cc
> enum class E { E1 };
> int main() {
> E const e = E::E1;
> return static_cast(e);
> }
> 
> $ g++ -Wall test.cc
> test.cc: In function ‘int main()’:
> test.cc:3:13: warning: variable ‘e’ set but not used 
> [-Wunused-but-set-variable]
>  E const e = E::E1;
>  ^

(which hit me when trying to build LibreOffice)

[Bug c++/83534] New: C++17: typeinfo for noexcept function lacks noexcept information

[sbergman at redhat dot com]

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

Bug ID: 83534
   Summary: C++17: typeinfo for noexcept function lacks noexcept
information
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

At least with current trunk towards GCC 8.0, but also with GCC 7.2.1:

> ~ cat test.cc
> #include 
> #include 
> void f1();
> void f2() noexcept;
> int main() { std::cout << (typeid(f1) == typeid(f2)) << '\n'; }
> 
> ~ g++ -std=c++17 test.cc
> ~ ./a.out
> 1

should print "0" instead, as those are different types since C++17 (and using

  typeid() == tpyeid()

instead correctly prints "0").

[Bug c++/81796] New: error: no matching function for call to ‘S2::operator delete(void*)’

[sbergman at redhat dot com]

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

Bug ID: 81796
   Summary: error: no matching function for call to ‘S2::operator
delete(void*)’
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

> $ g++ --version
> g++ (GCC) 8.0.0 20170810 (experimental)
> Copyright (C) 2017 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> $ cat test.cc
> #include 
> struct S1 { virtual ~S1(); };
> struct S2: S1 {
> static void * operator new(std::size_t);
> static void operator delete(void *, std::size_t);
> };
> 
> $ g++ -fsyntax-only test.cc
> test.cc:3:8: error: no matching function for call to ‘S2::operator 
> delete(void*)’
>  struct S2: S1 {
> ^~
> test.cc:5:17: note: candidate: ‘static void S2::operator delete(void*, 
> std::size_t)’
>  static void operator delete(void *, std::size_t);
>  ^~~~
> test.cc:5:17: note:   candidate expects 2 arguments, 1 provided

[Bug c/80354] Poor support to silence -Wformat-truncation=1

[sbergman at redhat dot com]

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

--- Comment #5 from Stephan Bergmann  ---
(In reply to Martin Sebor from comment #3)
> The warning does just what it's designed to do: point out the potential
> unhandled truncation.

But it is unusable in practice if there is no reliable way to silence false
positives.

> If the argument values are such that the truncation
> cannot occur then using snprintf is unnecessary and sprintf can be used
> instead.  Otherwise, if there is a combination of argument values that can
> result in truncation a warning is issued.  Note that the length of output
> produced by each directive can be constrained by specifying a precision for
> %s (e.g., "%.24s" if arena->m_name in the LibreOffice code cannot be longer
> than 24 characters), or by asserting that an integer argument is in some
> limited range of its type (or by using a narrower type to store it).

None of that applies in the case I mentioned, where an at-most 31-character
prefix of "%s_%lu" shall be produced, where the %s argument is known to be a
string of 0..31 characters and the %lu argument is an effectively unconstrained
value of type unsigned long.

> Like all warnings that depend on data flow analysis it is subject to false
> positives but there is no evidence to suggest that on balance it's unhelpful
> or difficult to use.  Quite the contrary.

One cannot even silence the warning locally with a #pragma GCC diagnostic
push/ignored "-Wformat-truncation"/pop just around that call to snprintf:  The
warning is reported on the first line of the function definition containing the
call (see below), and the pragma is only effective if the push/ignored
"-Wformat-truncation" part precedes that first line of the whole function
definition.

> /data/sbergman/lo-gcc/core/sal/rtl/alloc_arena.cxx: In function 
> ‘rtl_arena_type* {anonymous}::rtl_arena_activate(rtl_arena_type*, const 
> char*, sal_Size, sal_Size, rtl_arena_type*, void* (*)(rtl_arena_type*, 
> sal_Size*), void (*)(rtl_arena_type*, void*, sal_Size))’:
> /data/sbergman/lo-gcc/core/sal/rtl/alloc_arena.cxx:672:1: error: ‘%lu’ 
> directive output may be truncated writing between 1 and 20 bytes into a 
> region of size between 0 and 31 [-Werror=format-truncation=]
>  rtl_arena_activate (
>  ^~
> /data/sbergman/lo-gcc/core/sal/rtl/alloc_arena.cxx:717:17: note: ‘snprintf’ 
> output between 3 and 53 bytes into a destination of size 32
>  (void) snprintf (namebuf, sizeof(namebuf), "%s_%" 
> SAL_PRIuUINTPTR, arena->m_name, size);
>  
> ^~~

[Bug c/80354] Poor support to silence -Wformat-truncation=1

[sbergman at redhat dot com]

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

--- Comment #2 from Stephan Bergmann  ---
But that makes this warning extremely hard to use.  Is it really useful for
-Wall in that case?

I came across this with a real-world use-case in the LibreOffice code base,
where some code deliberately uses snprintf to produce a fixed-size prefix, see
 "WaE: ‘%lu’ directive output may be
truncated".  (And older builds of GCC towards GCC 7 did not emit that unhelpful
warning with -Wall => -Wformat-truncation=1, but would only have emitted it
with an explicit -Wformat-truncation=2.)

Addressing false positives for this warning thus becomes an unpleasant
whack-a-mole (given different builds of the code are done with different
optimization switches), unpleasant enough so that we'll likely have to use
-Wall -Wformat-truncation=0 for LibreOffice.  Which is unfortunate, given that
casting-to-void would be a well-understood and well-accepted way to silence
false positives (but one hard to implement in GCC, if I understand you
correctly).

[Bug c/80354] New: Poor support to silence -Wformat-truncation=1

[sbergman at redhat dot com]

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

Bug ID: 80354
   Summary: Poor support to silence -Wformat-truncation=1
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

With recent trunk

> $ gcc --version
> gcc (GCC) 7.0.1 20170406 (experimental)
> Copyright (C) 2017 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

and test.c

> #include 
> struct S { char a[3]; };
> void f1(struct S * s, int n) {
> char b[2];
> (void) snprintf(b, sizeof (b), "%s%d", s->a, n);
> }
> void f2(struct S * s, int n) {
> char b[2];
> int e = snprintf(b, sizeof (b), "%s%d", s->a, n);
> (void) e;
> }
> void f3(struct S * s, int n) {
> char b[2];
> int e = snprintf(b, sizeof (b), "%s%d", s->a, n);
> if (e >= sizeof (b)) {}
> }
> void f4(struct S * s, int n) {
> char b[2];
> int e = snprintf(b, sizeof (b), "%s%d", s->a, n);
> if (e >= sizeof (b)) b[1] = 0;
> }

the documentation of -Wformat-truncation=1 (as enabled by -Wall) in
gcc/doc/invoke.texi states it "warns only about calls to bounded functions
whose return value is unused [...]"

However, depending on e.g. -O0 vs. -Og, GCC will warn about f1 (gcc -Wall -O0
-c test.c) or even f1, f2, f3 (gcc -Wall -Og -c test.c), while I think it
should warn about none:

> test.c: In function ‘f1’:
> test.c:5:39: warning: ‘%d’ directive output may be truncated writing between 
> 1 and 11 bytes into a region of size between 0 and 2 [-Wformat-truncation=]
>  (void) snprintf(b, sizeof (b), "%s%d", s->a, n);
>^~
> test.c:5:5: note: ‘snprintf’ output between 2 and 14 bytes into a destination 
> of size 2
>  (void) snprintf(b, sizeof (b), "%s%d", s->a, n);
>  ^~~
> test.c: In function ‘f2’:
> test.c:9:40: warning: ‘%d’ directive output may be truncated writing between 
> 1 and 11 bytes into a region of size between 0 and 2 [-Wformat-truncation=]
>  int e = snprintf(b, sizeof (b), "%s%d", s->a, n);
> ^~
> test.c:9:9: note: ‘snprintf’ output between 2 and 14 bytes into a destination 
> of size 2
>  int e = snprintf(b, sizeof (b), "%s%d", s->a, n);
>  ^
> test.c: In function ‘f3’:
> test.c:14:40: warning: ‘%d’ directive output may be truncated writing between 
> 1 and 11 bytes into a region of size between 0 and 2 [-Wformat-truncation=]
>  int e = snprintf(b, sizeof (b), "%s%d", s->a, n);
> ^~
> test.c:14:9: note: ‘snprintf’ output between 2 and 14 bytes into a 
> destination of size 2
>  int e = snprintf(b, sizeof (b), "%s%d", s->a, n);
>  ^

[Bug c/79691] New: -Wformat-truncation suppressed by (and only by) -Og

[sbergman at redhat dot com]

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

Bug ID: 79691
   Summary: -Wformat-truncation suppressed by (and only by) -Og
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

At least with a recent GCC 7 trunk build ("gcc (GCC) 7.0.1 20170221
(experimental)"), I noticed that -Wformat-truncation warnings happen to
not be emitted if and only if -Og is given:

> $ cat test.c
> #include 
> int main() {
> char buf[3];
> snprintf(buf, sizeof buf, "%s", "foo");
> return 0;
> }
> $ gcc -Wformat-truncation -Og ~/test.c
> $ gcc -Wformat-truncation -O ~/test.c
> test.c: In function ‘main’:
> test.c:4:34: warning: ‘snprintf’ output truncated before the last
> format character [-Wformat-truncation=]
>  snprintf(buf, sizeof buf, "%s", "foo");
>   ^
> test.c:4:5: note: ‘snprintf’ output 4 bytes into a destination of size 3
>  snprintf(buf, sizeof buf, "%s", "foo");
>  ^~

Any other optimization level (-O0..3/s/fast) does emit the warning.

(See mail thread starting at <https://gcc.gnu.org/ml/gcc/2017-02/msg00103.html>
"New GCC 7 -Wformat-truncation suppressed by (and only by) -Og?".)

[Bug c++/79679] New: [C++17] Missing destruction of temporary within constructor's mem-initializer-list

[sbergman at redhat dot com]

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

Bug ID: 79679
   Summary: [C++17] Missing destruction of temporary within
constructor's mem-initializer-list
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

At least with a recent GCC trunk build ("gcc (GCC) 7.0.1 20170221
(experimental)"), the below program does not print "dtor" when built with
-std=c++17 (but does when built with -std=c++14, or with an older GCC,
gcc-c++-6.3.1-1.fc25.x86_64).  Appears that in the U ctor, a temporary
shared_ptr is copy-created but not destroyed.


#include 
#include 
struct S { ~S() { std::cout << "dtor\n"; } };
struct T {
std::shared_ptr s_;
T(std::shared_ptr s): s_(s) {}
};
struct U {
T t_;
U(std::shared_ptr const & s): t_(s) {}
};
int main() {
auto s = std::make_shared();
U u(s);
}

[Bug c++/79661] New: Bogus "destructor is private within this context" only in C++17 mode

[sbergman at redhat dot com]

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

Bug ID: 79661
   Summary: Bogus "destructor is private within this context" only
in C++17 mode
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

At least with a recent GCC trunk build:

> $ g++ --version
> g++ (GCC) 7.0.1 20170220 (experimental)
> Copyright (C) 2017 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> $ cat test.cc
> template struct R { R(T *); };
> struct S {
>  S(int);
> private:
>  ~S();
> };
> void f() { R(new S(0)); }
> 
> $ g++ -std=c++17 -fsyntax-only test.cc
> test.cc: In function ‘void f()’:
> test.cc:7:24: error: ‘S::~S()’ is private within this context
>  void f() { R(new S(0)); }
> ^
> test.cc:5:2: note: declared private here
>   ~S();
>   ^

Compilation succeeds when dropping the S constructor's int parameter (or even
merely giving it a default value and removing the argument from 'new S()'), or
when dropping the R(...) wrapper, or when compiling as -std=c++14, or when
compiling with GCC 6.3.1 (gcc-c++-6.3.1-1.fc25.x86_64).  So I assume this is a
bug rather than an actual C++17 requirement that I'm not aware of.

(The used GCC trunk version already includes the fix for somewhat-similar bug
78469.)

[Bug c++/79533] New: ICE in build_over_call under -std=c++17 in 'S s(static_cast(f()));'

[sbergman at redhat dot com]

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

Bug ID: 79533
   Summary: ICE in build_over_call under -std=c++17 in 'S
s(static_cast(f()));'
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

At least with a recent GCC trunk build:

> $ g++ --version
> g++ (GCC) 7.0.1 20170214 (experimental)
> Copyright (C) 2017 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> $ cat test.cc
> struct S {};
> S f();
> S s(static_cast(f()));
> 
> $ g++ -std=c++17 -fsyntax-only test.cc
> test.cc:3:32: internal compiler error: in build_over_call, at cp/call.c:7978
>  S s(static_cast(f()));
> ^
> 0x5c34ec build_over_call
> ../../src/gcc/cp/call.c:7975
> 0x5c443e build_new_method_call_1
> ../../src/gcc/cp/call.c:8801
> 0x5c443e build_new_method_call(tree_node*, tree_node*, vec<tree_node*, va_gc, 
> vl_embed>**, tree_node*, int, tree_node**, int)
> ../../src/gcc/cp/call.c:8870
> 0x5c58c9 build_special_member_call(tree_node*, tree_node*, vec<tree_node*, 
> va_gc, vl_embed>**, tree_node*, int, int)
> ../../src/gcc/cp/call.c:8399
> 0x74dfe4 expand_default_init
> ../../src/gcc/cp/init.c:1790
> 0x74dfe4 expand_aggr_init_1
> ../../src/gcc/cp/init.c:1905
> 0x74ebeb build_aggr_init(tree_node*, tree_node*, int, int)
> ../../src/gcc/cp/init.c:1643
> 0x5e05df build_aggr_init_full_exprs
> ../../src/gcc/cp/decl.c:6164
> 0x5e05df check_initializer
> ../../src/gcc/cp/decl.c:6312
> 0x60aabc cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
> ../../src/gcc/cp/decl.c:7025
> 0x7090a3 cp_parser_init_declarator
> ../../src/gcc/cp/parser.c:19389
> 0x709a6c cp_parser_simple_declaration
> ../../src/gcc/cp/parser.c:12792
> 0x70a825 cp_parser_block_declaration
> ../../src/gcc/cp/parser.c:12617
> 0x6e33d4 cp_parser_declaration
> ../../src/gcc/cp/parser.c:12515
> 0x713e6b cp_parser_declaration_seq_opt
> ../../src/gcc/cp/parser.c:12391
> 0x71414a cp_parser_translation_unit
> ../../src/gcc/cp/parser.c:4366
> 0x71414a c_parse_file()
> ../../src/gcc/cp/parser.c:38425
> 0x873ac3 c_common_parse_file()
> ../../src/gcc/c-family/c-opts.c:1107
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See <https://gcc.gnu.org/bugs/> for instructions.

The ICE happens with -std=c++17/-std=gnu++17, doesn't happen with -std=c++14
etc.  I cannot reproduce it with g++ from gcc-c++-6.3.1-1.fc25.x86_64, but
maybe that one's built without assertions.

[Bug c++/20710] g++ should warn when hiding non-virtual method in base class

[sbergman at redhat dot com]

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

Stephan Bergmann  changed:

   What|Removed |Added

 CC||sbergman at redhat dot com

--- Comment #9 from Stephan Bergmann  ---
(In reply to Jonathan Wakely from comment #7)
> The C++0x override control works for virtual and non-virtual names

That's not true for what then became the C++11 standard, right?  "A
virt-specifier-seq shall appear only in the declaration of a virtual member
function (10.3)."

[Bug c++/70909] Libiberty Demangler segfaults (4)

[sbergman at redhat dot com]

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

Stephan Bergmann  changed:

   What|Removed |Added

 CC||sbergman at redhat dot com

--- Comment #1 from Stephan Bergmann  ---
(In reply to Marcel Böhme from comment #0)
> This specific stack overflow has not been reported but with a bit of
> searching it seems to be linked to the open bugs PR61460, PR68700, PR67738,
> PR68383, PR70517, PR61805, PR62279, and the meta bug PR67264. The prepared
> patch addresses all of these.

Is that patch available anywhere?

[Bug other/61460] Demangler crash (GDB PR 17043)

[sbergman at redhat dot com]

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

Stephan Bergmann  changed:

   What|Removed |Added

 CC||sbergman at redhat dot com

--- Comment #1 from Stephan Bergmann  ---
Experienced a similar c++filt SIGSEV (due to recursive stack overflow) now with
the symbol

_ZNK6clover6detail11basic_rangeINS_13adaptor_rangeIZNS_6kernel6launchERNS_13command_queueERKSt6vectorImSaImEESA_SA_EUlmE_JRS8_EEENS0_16iterator_adaptorISB_JN9__gnu_cxx17__normal_iteratorIPmS8_ESJ_EcvT_IS6_IPjSaISN_EEvEEv

(also while debugging a process involving libMesaOpenCL; on Fedora 24).  Bug
70909 presumably discusses the root cause of these crashes.

[Bug c++/71882] New: elaborated-type-specifier friend not looked up in unnamed namespace

[sbergman at redhat dot com]

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

Bug ID: 71882
   Summary: elaborated-type-specifier friend not looked up in
unnamed namespace
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

At least with both GCC 6.1.1 and recent trunk, compiling

  namespace { struct S; }
  class C {
friend struct S;
static void f();
  };
  namespace { struct S { void f() { C::f(); } }; }

fails with

> $ g++ -c test.cc
> test.cc: In member function ‘void {anonymous}::S::f()’:
> test.cc:6:42: error: ‘static void C::f()’ is private within this context
>namespace { struct S { void f() { C::f(); } }; }
>   ^
> test.cc:4:17: note: declared private here
>  static void f();
>  ^

[Bug c++/70476] New: C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage

[sbergman at redhat dot com]

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

Bug ID: 70476
   Summary: C++11: Function name declared in unnamed namespace
extern "C" gets exernal linkage
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

My reading of the C++11-and-beyond Standard is that the name of a function with
extern "C" language linkage declared in an unnamed namespace should have
internal linkage:  Per [basic.link], it has the same linkage as the enclosing
unnamed namespace (i.e., internal).  And [dcl.link]'s "A declaration directly
contained in a linkage-specification is treated as if it contains the extern
specifier..." is irrelevant, as even a function declared with the "extern"
storage specifier in an unnamed namespace has internal linkage.  (See also
<https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/oyLCkCUKpfU>
"Linkage of: namespace { extern "C" { void f() {} } }".)

That is, with test.cc being

 void external01() {}
  extern void external02() {}
  static void internal03() {}
 extern "C"  void external04() {}
 extern "C" {void external05() {} }
 extern "C" { extern void external06() {} }
 extern "C" { static void internal07() {} }
 namespace { void internal08() {}   }
 namespace {  extern void internal09() {}   }
 namespace {  static void internal10() {}   }
 namespace { extern "C"  void internal11() {}   }
 namespace { extern "C" {void internal12() {} } }
 namespace { extern "C" { extern void internal13() {} } }
 namespace { extern "C" { static void internal14() {} } }

all external* should have external linkage and all internal* should have
internal linkage when compiled as C++11 or later.

But (at least on Linux with recent GCC trunk)

> $ gcc/trunk/inst/bin/g++ --version
> g++ (GCC) 6.0.0 20160331 (experimental)
> Copyright (C) 2016 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> $ gcc/trunk/inst/bin/g++ -std=c++11 -c test.cc && nm test.o | grep -w T
> 0015 T external04
> 001c T external05
> 0023 T external06
> 0046 T internal11
> 004d T internal12
> 0054 T internal13
>  T _Z10external01v
> 0007 T _Z10external02v

shows that internal11--13 erroneously get external linkage.

[Bug c++/69922] New: Bogus -Wnonnull-compare for: ... ? static_cast<T*>(this) : nullptr

[sbergman at redhat dot com]

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

Bug ID: 69922
   Summary: Bogus -Wnonnull-compare for: ... ?
static_cast<T*>(this) : nullptr
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

With trunk@233631:

> $ cat test.cc
> struct S2 { virtual ~S2(); };
> struct S1 {
> virtual ~S1();
> S2 * f(bool);
> };
> struct S3: S1, S2 {};
> S2 * S1::f(bool b) { return b ? static_cast(this) : nullptr; }

> $ g++ -Werror -Wnonnull-compare -c test.cc
> test.cc: In member function ‘S2* S1::f(bool)’:
> test.cc:7:59: error: nonnull argument ‘this’ compared to NULL 
> [-Werror=nonnull-compare]
>  S2 * S1::f(bool b) { return b ? static_cast(this) : nullptr; }
>^~~
> cc1plus: all warnings being treated as errors

[Bug c/69914] New: ICE in check_global_declaration, upon -Wunused-variable of an array

[sbergman at redhat dot com]

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

Bug ID: 69914
   Summary: ICE in check_global_declaration, upon
-Wunused-variable of an array
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

With recent trunk@233620:

> $ cat test.c
> typedef struct S {
>   int a;
>   void * b;
>   int c;
> } S;
> void f(void) {
> S a[] = {
> {0x0120, ((void *)0), 0},
> {0x0120, ((void *)0), 0},
> {0x0120, ((void *)0), 0},
> {0x0120, ((void *)0), 0},
> {0, ((void *)0), 0},
> {0, ((void *)0), 0}
> };
> }

> $ gcc -Wunused-variable -c test.c
> test.c: In function ‘f’:
> test.c:7:7: warning: unused variable ‘a’ [-Wunused-variable]
>  S a[] = {
>^
> At top level:
> cc1: internal compiler error: Segmentation fault
> 0xb2497f crash_signal
>   ../../src/gcc/toplev.c:335
> 0x7506bd check_global_declaration
>   ../../src/gcc/cgraphunit.c:947
> 0x7506bd analyze_functions
>   ../../src/gcc/cgraphunit.c:1168
> 0x750f98 symbol_table::finalize_compilation_unit()
>   ../../src/gcc/cgraphunit.c:2537

[Bug c++/69902] New: Bogus -Wnonnull-compare for: dynamic_cast<T*>() == nullptr

[sbergman at redhat dot com]

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

Bug ID: 69902
   Summary: Bogus -Wnonnull-compare for: dynamic_cast<T*>() ==
nullptr
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

With GCC built from trunk@233597:

> $ cat test.cc
> struct A { virtual ~A(); };
> struct B: A {};
> bool f(A & a) { return dynamic_cast() == nullptr; }

> $ gcc/trunk/inst/bin/g++ -Werror -Wnonnull-compare test.cc
> test.cc: In function ‘bool f(A&)’:
> test.cc:3:46: error: nonnull argument ‘a’ compared to NULL 
> [-Werror=nonnull-compare]
>  bool f(A & a) { return dynamic_cast() == nullptr; }
> ~~^~
> cc1plus: all warnings being treated as errors

(The warning goes away when changing "== nullptr" to "!= nullptr", or when
adding -fsyntax-only.)

[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro

[sbergman at redhat dot com]

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

--- Comment #24 from Stephan Bergmann  ---
(In reply to Manuel López-Ibáñez from comment #23)
> That is weird. If you use "GCC diagnostic warning" instead of "ignored", you
> should be able to see some changes in locations between -O0 and -O1 and
> before/after the bug appeared, don't you?

No.  The reported locations remain unaffected (errors/warnings at test.cc:12:5
and test.cc:12:7, notes at test.cc:9:34).  Just that (after replacing "ignored"
with "warning") they get reported as errors with -O1 and r232893 included, and
as warnings otherwise (i.e., either with -O0 and r232893 included, or with
either -O0/1 and r232893 reverted).

[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro

[sbergman at redhat dot com]

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

--- Comment #22 from Stephan Bergmann  ---
(In reply to Jakub Jelinek from comment #20)
> Does the http://gcc.gnu.org/ml/gcc-patches/2016-01/msg02347.html workaround
> help here in any way?

No, unfortunately not.  Doesn't change the behaviour in any way.