[Bug c++/113400] Internal compiler error: Segmentation fault, regression in 13.2.1 compared to 13.2.0

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #2 from Boris Kolpackov  ---
Created attachment 57084
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57084=edit
Reproducer

[Bug c++/113400] Internal compiler error: Segmentation fault, regression in 13.2.1 compared to 13.2.0

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #1 from Boris Kolpackov  ---
Created attachment 57083
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57083=edit
Reproducer

[Bug c++/113400] New: Internal compiler error: Segmentation fault, regression in 13.2.1 compared to 13.2.0

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 113400
   Summary: Internal compiler error:  Segmentation fault,
regression in 13.2.1 compared to 13.2.0
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

We are getting this ICE since upgrading to 13.2.1.

$ g++ --version
g++ (GCC) 13.2.1 20231205 (Red Hat 13.2.1-6)

The attached files were produced with these command lines:

g++ -I/home/karen/work/build2/bpkg -I/home/karen/work/build2/bpkg
-D_GLIBCXX_ASSERTIONS -I/home/karen/work/build2/build2
-I/home/karen/work/build2/build2 -DLIBBUILD2_SHARED
-I/home/karen/work/build2/libbutl -I/home/karen/work/build2/libbutl
-DLIBBUTL_SHARED -I/home/karen/work/build2/build2
-I/home/karen/work/build2/build2 -DLIBBUILD2_BASH_SHARED
-I/home/karen/work/build2/build2 -I/home/karen/work/build2/build2
-DLIBBUILD2_IN_SHARED -I/home/karen/work/build2/build2
-I/home/karen/work/build2/build2 -DLIBBUILD2_BIN_SHARED
-I/home/karen/work/build2/build2 -I/home/karen/work/build2/build2
-DLIBBUILD2_C_SHARED -I/home/karen/work/build2/build2
-I/home/karen/work/build2/build2 -DLIBBUILD2_CC_SHARED
-I/home/karen/work/build2/build2 -I/home/karen/work/build2/build2
-DLIBBUILD2_CLI_SHARED -I/home/karen/work/build2/build2
-I/home/karen/work/build2/build2 -DLIBBUILD2_CXX_SHARED
-I/home/karen/work/build2/build2 -I/home/karen/work/build2/build2
-DLIBBUILD2_VERSION_SHARED -I/home/karen/work/build2/libbpkg
-I/home/karen/work/build2/libbpkg -DLIBBPKG_SHARED
-I/home/karen/work/odb/libodb -I/home/karen/work/odb/libodb -DLIBODB_BUILD2
-DLIBODB_SHARED -I/home/karen/work/odb/libodb-sqlite
-I/home/karen/work/odb/libodb-sqlite -DLIBODB_SQLITE_BUILD2
-DLIBODB_SQLITE_SHARED
-I/home/karen/work/build2/packaging/sqlite/sqlite/libsqlite3/libsqlite3 -W
-Wall -Wextra -Wno-unknown-pragmas -g -ggdb -fno-inline -fsanitize=address
-fsanitize=undefined -fno-omit-frame-pointer -fstack-protector-all
-Wno-maybe-uninitialized -Wno-free-nonheap-object -Wno-stringop-overread
-Wno-dangling-reference -Wno-unknown-pragmas -std=c++23 -finput-charset=UTF-8
-x c++ -MQ ^ -MD -E -fdirectives-only -MF
/home/karen/work/build2/bpkg/bpkg/manifest-utility.o.t -o
/home/karen/work/build2/bpkg/bpkg/manifest-utility.o.ii
/home/karen/work/build2/bpkg/bpkg/manifest-utility.cxx

g++ -I/home/karen/work/build2/bpkg -I/home/karen/work/build2/bpkg
-D_GLIBCXX_ASSERTIONS -I/home/karen/work/build2/build2
-I/home/karen/work/build2/build2 -DLIBBUILD2_SHARED
-I/home/karen/work/build2/libbutl -I/home/karen/work/build2/libbutl
-DLIBBUTL_SHARED -I/home/karen/work/build2/build2
-I/home/karen/work/build2/build2 -DLIBBUILD2_BASH_SHARED
-I/home/karen/work/build2/build2 -I/home/karen/work/build2/build2
-DLIBBUILD2_IN_SHARED -I/home/karen/work/build2/build2
-I/home/karen/work/build2/build2 -DLIBBUILD2_BIN_SHARED
-I/home/karen/work/build2/build2 -I/home/karen/work/build2/build2
-DLIBBUILD2_C_SHARED -I/home/karen/work/build2/build2
-I/home/karen/work/build2/build2 -DLIBBUILD2_CC_SHARED
-I/home/karen/work/build2/build2 -I/home/karen/work/build2/build2
-DLIBBUILD2_CLI_SHARED -I/home/karen/work/build2/build2
-I/home/karen/work/build2/build2 -DLIBBUILD2_CXX_SHARED
-I/home/karen/work/build2/build2 -I/home/karen/work/build2/build2
-DLIBBUILD2_VERSION_SHARED -I/home/karen/work/build2/libbpkg
-I/home/karen/work/build2/libbpkg -DLIBBPKG_SHARED
-I/home/karen/work/odb/libodb -I/home/karen/work/odb/libodb -DLIBODB_BUILD2
-DLIBODB_SHARED -I/home/karen/work/odb/libodb-sqlite
-I/home/karen/work/odb/libodb-sqlite -DLIBODB_SQLITE_BUILD2
-DLIBODB_SQLITE_SHARED
-I/home/karen/work/build2/packaging/sqlite/sqlite/libsqlite3/libsqlite3 -W
-Wall -Wextra -Wno-unknown-pragmas -g -ggdb -fno-inline -fsanitize=address
-fsanitize=undefined -fno-omit-frame-pointer -fstack-protector-all
-Wno-maybe-uninitialized -Wno-free-nonheap-object -Wno-stringop-overread
-Wno-dangling-reference -Wno-unknown-pragmas -std=c++23 -fdiagnostics-color
-finput-charset=UTF-8 -o bpkg/manifest-utility.o -c -x c++ -fpreprocessed
-fdirectives-only /home/karen/work/build2/bpkg/bpkg/manifest-utility.o.ii

In function ‘std::vector bpkg::package_b_info(const
common_options&, const dir_paths&, butl::b_info_flags)’:
cc1plus: internal compiler error: Segmentation fault
Please submit a full bug report, with preprocessed source.
See  for instructions.
Preprocessed source stored into /tmp/ccemvm8K.out file, please attach this to
your bugreport.

[Bug c++/110417] New: [modules] Segfault compiling iostream as header unit on FreeBSD

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 110417
   Summary: [modules] Segfault compiling iostream as header unit
on FreeBSD
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

[Submitting this on behalf of a build2 user who is still waiting for the
bugzilla login[1].]

GCC 12,13,14 all have compilation errors on FreeBSD when trying to compile C++
modules on FreeBSD.

When trying to compile iostream using the command: 

g++ -v -save-temps -std=c++20 -fmodules-ts -xc++-system-header iostream

GCC throws internal compiler error in exact form:

header iostream
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc12/gcc/x86_64-portbld-freebsd13.1/12.2.0/lto-wrapper
Target: x86_64-portbld-freebsd13.1
Configured with: /wrkdirs/usr/ports/lang/gcc12/work/gcc-12.2.0/configure
--enable-multilib --with-build-config=bootstrap-lto-noplugin --disable-nls
--enable-gnu-indirect-function --enable-host-shared --enable-plugin
--libdir=/usr/local/lib/gcc12 --libexecdir=/usr/local/libexec/gcc12
--program-suffix=12 --with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc12/include/c++/
--with-gxx-libcxx-include-dir=/usr/include/c++/v1 --with-ld=/usr/local/bin/ld
--with-pkgversion='FreeBSD Ports Collection' --with-system-zlib --without-zstd
--enable-languages=c,c++,objc,fortran,jit --prefix=/usr/local
--localstatedir=/var --mandir=/usr/local/man
--infodir=/usr/local/share/info/gcc12 --build=x86_64-portbld-freebsd13.1
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.0 (FreeBSD Ports Collection)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++20' '-fmodules-ts'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
 /usr/local/libexec/gcc12/gcc/x86_64-portbld-freebsd13.1/12.2.0/cc1plus -E
-fdirectives-only -fmodule-header=system -quiet -v iostream -mtune=generic
-march=x86-64 -std=c++20 -fmodules-ts -fpch-preprocess -o a-iostream.ii
ignoring nonexistent directory
"/usr/local/lib/gcc12/gcc/x86_64-portbld-freebsd13.1/12.2.0/include-fixed"
ignoring nonexistent directory
"/usr/local/lib/gcc12/gcc/x86_64-portbld-freebsd13.1/12.2.0/../../../../../x86_64-portbld-freebsd13.1/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc12/include/c++/
 /usr/local/lib/gcc12/include/c++//x86_64-portbld-freebsd13.1
 /usr/local/lib/gcc12/include/c++//backward
 /usr/local/lib/gcc12/gcc/x86_64-portbld-freebsd13.1/12.2.0/include
 /usr/local/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++20' '-fmodules-ts'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
 /usr/local/libexec/gcc12/gcc/x86_64-portbld-freebsd13.1/12.2.0/cc1plus
-fpreprocessed -fdirectives-only a-iostream.ii -fmodule-header=system -quiet
-dumpdir a- -dumpbase iostream -mtune=generic -march=x86-64 -std=c++20 -version
-fmodules-ts -o a-iostream.s
GNU C++20 (FreeBSD Ports Collection) version 12.2.0
(x86_64-portbld-freebsd13.1)
compiled by GNU C version 12.2.0, GMP version 6.2.1, MPFR version
4.2.0-p9, MPC version 1.3.1, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++20 (FreeBSD Ports Collection) version 12.2.0
(x86_64-portbld-freebsd13.1)
compiled by GNU C version 12.2.0, GMP version 6.2.1, MPFR version
4.2.0-p9, MPC version 1.3.1, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 8fd6eb50279aca98d331f0f2293361fa
/usr/local/lib/gcc12/include/c++/iostream:77:1: internal compiler error:
Segmentation fault
   77 | } // namespace
  | ^
0x8270edff3 ???
/usr/src/lib/libc/amd64/string/memmove.S:306
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

steps to reproduce:
1. Use Freebsd 13.2 or 14.0
2. pkg install gcc-12_5
3. mkdir example && cd example && g++ -v -save-temps -std=c++20 -fmodules-ts
-xc++-system-header iostream

You should now see a similar segmentation fault error.

[1] https://github.com/build2/build2/issues/284

[Bug c++/110213] Bogus (as opposed to false positive) -Wdangling-reference warning

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #1 from Boris Kolpackov  ---
Created attachment 55304
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55304=edit
reproducer

[Bug c++/110213] New: Bogus (as opposed to false positive) -Wdangling-reference warning

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 110213
   Summary: Bogus (as opposed to false positive)
-Wdangling-reference warning
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

I have a call that, AFAICS, doesn't involve any binding of references to
temporaries but which nevertheless still produces this warning. The code boils
down to the following:

const target& search (const target&, name);

void pattern::apply(target& t) const
{
  name n = ...;
  const target& p (search (t, std::move (n))); // <- Warning points here.
}

However, I was not able to reduce it to a small reproducer so it seems to
depend on the overall context. So I am attaching a partially preprocessed TU.
To reproduce, run:

$ g++ -std=c++23 -Wall -Wextra -fdirectives-only -c adhoc-rule-regex-pattern.ii

adhoc-rule-regex-pattern.cxx: In member function ‘virtual void
build2::adhoc_rule_regex_pattern::apply_prerequisites(build2::action,
build2::target&, const scope&, build2::match_extra&) const’:
adhoc-rule-regex-pattern.cxx:485:21: warning: possibly dangling reference to a
temporary [-Wdangling-reference]
  485 |   const target& pt (search (t, move (n), *s, ));
  | ^~
adhoc-rule-regex-pattern.cxx:485:32: note: the temporary was destroyed at the
end of the full expression 
‘build2::search((*(const build2::target*)(& t)), build2::name((* &
std::move(n))), (* s), (&
e.build2::adhoc_rule_regex_pattern::element::type))’
  485 |   const target& pt (search (t, move (n), *s, ));
  | ~~~^~

The last two arguments (*s, ) in the call do not make any difference.
Changing the search() function to take name by const& or && makes the warning
disappear.

$ g++ --version
g++-13 (Debian 13.1.0-3) 13.1.0

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[boris at kolpackov dot net via Gcc-bugs]

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

Boris Kolpackov  changed:

   What|Removed |Added

 CC||boris at kolpackov dot net

--- Comment #34 from Boris Kolpackov  ---
Would like to echo other's comments: getting a large number false positives in
our codebase (build2). Thankfully this warning seems to only be enabled with
-Wextra and not with -Wall as stated in #106393.

[Bug c++/110153] New: [modules] Static module mapper format cannot handle header unit paths with spaces

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 110153
   Summary: [modules] Static module mapper format cannot handle
header unit paths with spaces
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

The static module mapper format (-fmodule-mapper=[?], as described
here[1] and implemented in c++tools/resolver.cc) uses spaces to separate the
module names from BMI file names and as a result cannot handle header unit
names that contain spaces. While the header names that contain spaces are not
very likely, the header unit names include the directory components which could
plausibly contain spaces.

Possible ways to fix this that came to mind:

1. Use the same quoting/escaping mechanism as in the dynamic mapper (see the
libcody documentation[2]).

2. Currently the separator is either a space or a tab. We could change it to be
only tab (assuming that paths with tabs are a lot less likely than with
spaces).


[1] https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Module-Mapper.html
[2] https://github.com/urnathan/libcody#packet-encoding

[Bug preprocessor/109534] -fdirectives-only does not work with assembler-with-cpp

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #7 from Boris Kolpackov  ---
BTW, my understanding of the rationale for the original patch (the one that
forces -fno-directives-only) is to paper over some underlying issue with
-fdirectives-only when used on .S files, potentially the same as the one I've
encountered with a broken line directive. And the intend of the patch was to
make builds that use -fdirectives-only on .S files to work transparently by
forcing full preprocessing instead. But that "transparently" part doesn't seem
to hold (using the same test.S):


$ gcc -E -fdirectives-only -o test.Si test.S
$ 
$ gcc -x assembler-with-cpp -fpreprocessed -fdirectives-only -c -o test.o
test.Si
test.Si:1: Error: junk at end of line, first unrecognized character is `0'


The error is due to -fno-directives-only cancelling out -fdirectives-only and
just -fpreprocessed means the file is fully preprocessed.

[Bug preprocessor/109534] -fdirectives-only does not work with assembler-with-cpp

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #6 from Boris Kolpackov  ---
> The documentation says specifically-fdirectives-only is ignored if 
> -fpreprocessed is supplied.

Hm, that's not how it works, IME. Specifically, just "-fpreprocessed" means the
source code is fully preprocessed (and no further preprocessing is required)
while "-fpreprocessed -fdirectives-only" means the source code is preprocessed
to directives only (and further preprocessing is required). Here is a
demonstration:

$ cat test.c
#define FOO 2
int f () {return FOO;}
EOF

$ gcc -E -fdirectives-only -o test.i test.c

$ tail -3 test.i
# 1 "test.c"
#define FOO 2
int f () {return FOO;}

$ gcc -fpreprocessed -fdirectives-only -c -o test.o test.i

$ gcc -fpreprocessed -c -o test.o test.i
test.c: In function ‘f’:
test.c:2:18: error: ‘FOO’ undeclared (first use in this function)
2 | int f () {return FOO;}

[Bug preprocessor/109534] -fdirectives-only does not work with assembler-with-cpp

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #4 from Boris Kolpackov  ---
Thanks for the link to the patch submission though I find the
"-fdirectives-only option is incompatible with assembly" statement puzzling.

> So from what I understand this part is what you want:
>
> -   "%(trad_capable_cpp) -lang-asm %(cpp_options) -fno-directives-only\
> +   "%(trad_capable_cpp) -lang-asm %(cpp_options) %{!E:-fno-directives-only} \
>
> Because -fno-directives-only is needed without -E.

Hm, wouldn't that still break the second invocation (-fpreprocessed
-fdirectives-only)?

I think the correct fix is to remove -fno-directives-only altogether (provided
the second issue is fixed, of course) leaving the user-specified
-fdirectives-only to take effect regardless of the mode.

[Bug c/109534] New: -fdirectives-only does not work with assembler-with-cpp

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 109534
   Summary: -fdirectives-only does not work with
assembler-with-cpp
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

I've noticed that -fdirectives-only has no effect when preprocessing
assembler-with-cpp files. Instead, one always get a fully preprocessed source:


$ cat 

[Bug preprocessor/84583] -fdirectives-only does not handle CRLF properly

[boris at kolpackov dot net via Gcc-bugs]

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

Boris Kolpackov  changed:

   What|Removed |Added

Version|10.2.0  |12.2.0

--- Comment #2 from Boris Kolpackov  ---
Still present in GCC 12.2.0. Just hit it with SQLite 3.39.4 source code
(shell.c):

shell.exe.o.i:165900:40: error: unterminated string literal

[Bug c++/107555] Never constructed object destroyed during exception handling

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #6 from Boris Kolpackov  ---
I was under the impression that only something runnable would be useful, but if
all that's need is a preprocessed translation unit, then that's no problem at
all. I've also attached the translation unit with the workaround for your
reference.

Both files were produced with the following command line using GCC 12.2.0
(Debian 12.2.0-3):

g++-12 ... -DLIBBUILD2_SHARED_BUILD -DLIBBUILD2_CC_SHARED_BUILD
-DLIBBUILD2_BIN_SHARED -DLIBBUILD2_SHARED -DLIBBUTL_SHARED 
-DLIBPKG_CONFIG_SHARED -g -std=c++23 -finput-charset=UTF-8 -fPIC -E
-fdirectives-only -o compile-rule.ii compile-rule.cxx

And should be compiled with:

g++-12 -DLIBBUILD2_SHARED_BUILD -DLIBBUILD2_CC_SHARED_BUILD
-DLIBBUILD2_BIN_SHARED -DLIBBUILD2_SHARED -DLIBBUTL_SHARED
-DLIBPKG_CONFIG_SHARED -g -std=c++23 -finput-charset=UTF-8 -fPIC -o
compile-rule.o -c -fdirectives-only compile-rule.ii

Let me know if there is anything else you need.

[Bug c++/107555] Never constructed object destroyed during exception handling

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #5 from Boris Kolpackov  ---
Created attachment 53850
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53850=edit
Preprocessed translation unit with workaround

[Bug c++/107555] Never constructed object destroyed during exception handling

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #4 from Boris Kolpackov  ---
Created attachment 53849
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53849=edit
Preprocessed translation unit

[Bug c++/107555] Never constructed object destroyed during exception handling

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #2 from Boris Kolpackov  ---
There is a way to reproduce it but it requires building the actual source code
rather than a minimal reproducer. It's not that difficult. Should I provide the
instructions?

[Bug c++/107555] New: Never constructed object destroyed during exception handling

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 107555
   Summary: Never constructed object destroyed during exception
handling
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

I have a fairly complex function (nested loops, try-catch blocks, etc) that on
throwing an exceptions tries to destroy a stack object (suspected to be the
return value) that was never constructed. This feels like a mis-compilation
introduced in GCC 12 because:

1. The issue disappears if optimization is enabled.

2. The issue disappears if I get rid of the return value with otherwise minimal
changes.

3. Does not reproduce with GCC 11 or 10 in otherwise the same build.

I am not sure what's the best way to debug this. Coming up with a minimal
reproduce feels hopeless. But I can easily provide the instructions on how to
reproduce this on the actual source code. In the meantime, I will capture some
background below:

The relevant fragment of the stack trace looks like this:

#18 0x7f7472e5d270 in std::pair::~pair
(this=0x7ffdbe099e30, __in_chrg=) at
/usr/include/c++/12/bits/stl_pair.h:185
#19 0x7f7472e4ab19 in build2::cc::compile_rule::extract_headers () at
.../compile-rule.cxx:4768

The pair object being destroyed at frame #18 was never constructed and
eventually leads to "free(): invalid pointer" and abort. The extract_headers()
function has the following overall structure (only what I believe are the
relevant parts are shown):

pair compile_rule::
extract_headers ()
{

  ...

  if (something)
   return make_pair (file_cache::entry (), false);  // <-- one of early returns

  ...


  try
  {
...

if (something)
  throw failed (); // <-- the exception that is thrown

  }// <-- line 4768
  catch (const process_error& e)
  {
...

throw failed ();
  }

  ...

  return make_pair (move (psrc), puse); 
}

As can be seen, the function has a bunch of early returns. Other than the
returns, it does not construct any pair instances.

The call site look like this:

pair psrc (file_cache::entry (), false);

if (something)
{
  ...
  psrc = extract_headers (); 
}

Note that I checked and the `this` pointer from frame #18 does not point to
psrc form the call site.

I was able to work around this issue by getting rid of the return type and
instead passing the result object by reference:

void compile_rule::
extract_headers (, pair& result)
{
...

  if (something)
   return;

  ...

  result.first = move (psrc);
  result.second = puse;
}

And the call site:

pair psrc (file_cache::entry (), false);
if (something)
{
  ...
  extract_headers (, psrc);  
}

[Bug c/107448] New: GCC no longer diagnoses missing input file with -MG

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 107448
   Summary: GCC no longer diagnoses missing input file with -MG
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

With GCC 10 when trying to extract dependency information with -MG we get
diagnostics if the input file does not exist:

$ g++-10 -M -MG /tmp/no-such-file.cxx
g++-10: error: /tmp/no-such-file.cxx: No such file or directory
g++-10: fatal error: no input files
compilation terminated.

$ echo $?
1

In GCC 11 and 12 this diagnostics is gone:

$ g++-11 -M -MG /tmp/no-such-file.cxx
$ echo $?
1

$ g++-12 -M -MG /tmp/no-such-file.cxx
$ echo $?
1

[Bug sanitizer/64234] Statically sanitized executable does not export ASan symbols

[boris at kolpackov dot net via Gcc-bugs]

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

Boris Kolpackov  changed:

   What|Removed |Added

 CC||boris at kolpackov dot net

--- Comment #7 from Boris Kolpackov  ---
> But why do you want to use -static-libasan ?  Just link it dynamically...

Another reason is shared linking clobbers executable's RUNPATH:
https://github.com/google/sanitizers/issues/1219

[Bug sanitizer/101978] thread sanitizer false positive when condition variable

[boris at kolpackov dot net via Gcc-bugs]

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

Boris Kolpackov  changed:

   What|Removed |Added

 CC||boris at kolpackov dot net

--- Comment #4 from Boris Kolpackov  ---
Reproduces with GCC 11.3.0 from Debian.

There is speculation on StackOverflow that links to this bug that this is
somehow causes by holding the mutex while calling notify_all(). But in our case
we get this bogus report without holding the mutex when calling notify_all().
Here is what the relevant parts in our code look like:

{
  unique_lock l (state_->mutex);
  state_->finished = true;
}

state_->condv.notify_all ();

And:

unique_lock l (state_->mutex);

if (!state_->finished &&
!state_->condv.wait_for (l, tm, [state_] {return state_->finished;}))
  return nullopt;

Also, in our case we get two variants of this warning: as originally reported
and the second where the mutex is supposedly already destroyed (shown below).
Replacing wait_for() with wait() makes both disappear.

WARNING: ThreadSanitizer: double lock of a mutex (pid=1881)
#0 pthread_mutex_lock
../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:4240
(libtsan.so.0+0x4f30a)
#1 __gthread_mutex_lock
/usr/include/x86_64-linux-gnu/c++/11/bits/gthr-default.h:749
(libbuild2-0.15.0-a.0.ecfa0f59dab6.so+0x624ff5)
#2 std::mutex::lock() /usr/include/c++/11/bits/std_mutex.h:100
(libbuild2-0.15.0-a.0.ecfa0f59dab6.so+0x625146)
#3 std::unique_lock::lock()
/usr/include/c++/11/bits/unique_lock.h:139
(libbuild2-0.15.0-a.0.ecfa0f59dab6.so+0x62c701)
#4 std::unique_lock::unique_lock(std::mutex&)
/usr/include/c++/11/bits/unique_lock.h:69
(libbuild2-0.15.0-a.0.ecfa0f59dab6.so+0x62c64c)
#5 operator()
/tmp/bootstrap/build2-toolchain-0.15-a.0/libbutl-0.15.0-a.0.20220714150118.f07a6606e44d/libbutl/builtin.ixx:56
(libbutl-0.15.0-a.0.f07a6606e44d.so+0x24d443)
...

  Location is heap block of size 104 at 0x7b1c00017370 allocated by thread T9:
#0 operator new(unsigned long)
../../../../src/libsanitizer/tsan/tsan_new_delete.cpp:64 (libtsan.so.0+0x8857c)
#1 async_impl
/tmp/bootstrap/build2-toolchain-0.15-a.0/libbutl-0.15.0-a.0.20220714150118.f07a6606e44d/libbutl/builtin.cxx:2191
(libbutl-0.15.0-a.0.f07a6606e44d.so+0x248ee8)
#2 async_impl
/tmp/bootstrap/build2-toolchain-0.15-a.0/libbutl-0.15.0-a.0.20220714150118.f07a6606e44d/libbutl/builtin.cxx:2205
(libbutl-0.15.0-a.0.f07a6606e44d.so+0x24db72)
#3 run_pipe
/tmp/bootstrap/build2-toolchain-0.15-a.0/build2-0.15.0-a.0.20220717074539.ecfa0f59dab6/libbuild2/script/run.cxx:2160
(libbuild2-0.15.0-a.0.ecfa0f59dab6.so+0x82a1ec)
#4 run_expr
/tmp/bootstrap/build2-toolchain-0.15-a.0/build2-0.15.0-a.0.20220717074539.ecfa0f59dab6/libbuild2/script/run.cxx:2492
(libbuild2-0.15.0-a.0.ecfa0f59dab6.so+0x82c409)
...

  Mutex M810501818139374456 is already destroyed.

[Bug c++/98417] ICE when using C++ modules and -g

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #3 from Boris Kolpackov  ---
I also no longer see this with GCC 12.0.1 20220421.

[Bug c++/103524] [meta-bug] modules issue

[boris at kolpackov dot net via Gcc-bugs]

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

Bug 98760 Summary: [modules] ICE in add_module_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98760

   What|Removed |Added

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

[Bug c++/98760] [modules] ICE in add_module_decl

[boris at kolpackov dot net via Gcc-bugs]

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

Boris Kolpackov  changed:

   What|Removed |Added

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

--- Comment #3 from Boris Kolpackov  ---
This appears to be fixed in GCC 12.0.1 20220421.

[Bug c++/105329] New: Bogus restrict warning when assigning 1-char string literal to std::string

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 105329
   Summary: Bogus restrict warning when assigning 1-char string
literal to std::string
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

When compiling my codebase (build2) with GCC 12 (12.0.1 20220421) the output is
littered with new bogus (AFAICS) -Wrestrict warnings that seems to be triggered
by any attempt to assign or append a 1-char string literal to std::string:

$ cat ::_S_copy(_CharT*, const _CharT*, size_type) [with _CharT =
char; _Traits = std::char_traits; _Alloc = std::allocator]’ at
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/12.0.1/bits/basic_string.h:423:21,
inlined from ‘constexpr std::__cxx11::basic_string<_CharT, _Traits,
_Allocator>& std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_M_replace(size_type, size_type, const _CharT*, size_type) [with
_CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]’ at
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/12.0.1/bits/basic_string.tcc:532:22,
inlined from ‘constexpr std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>& std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::assign(const
_CharT*) [with _CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]’ at
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/12.0.1/bits/basic_string.h:1647:19,
inlined from ‘constexpr std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>& std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(const
_CharT*) [with _CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]’ at
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/12.0.1/bits/basic_string.h:815:28,
inlined from ‘void f(std::string&)’ at bogus-restrict.cxx:5:7:
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/12.0.1/bits/char_traits.h:431:56:
warning: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’
accessing 9223372036854775810 or more bytes at offsets -4611686018427387902 and
[-4611686018427387903, 4611686018427387904] may overlap up to
9223372036854775813 bytes at offset -3 [-Wrestrict]
  431 | return static_cast(__builtin_memcpy(__s1, __s2,
__n));
  |

[Bug c++/105327] New: Bogus use-after-free warning new in GCC 12

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 105327
   Summary: Bogus use-after-free warning new in GCC 12
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

The following translation unit now (since 12.0) causes a bogus (AFAICS)
use-after-free warning:

$ cat 
{
public:
  static void*
  allocate (std::size_t n)
  {
return operator new (n);
  }

  static void
  free (void* p)
  {
operator delete (p);
  }
};

template 
class pointer_factory
{
public:
  static P
  create ()
  {
void* v (pointer_traits::allocate (sizeof (T)));
mem_guard g (v);
P p (new (v) T);
//g.release ();
g.p_ = 0;
return p;
  }

private:
  struct mem_guard
  {
mem_guard (void* p): p_ (p) {}
~mem_guard () {if (p_) pointer_traits::free (p_);}
void release () {p_ = 0;}
void* p_;
  };
};

struct s {};

int main ()
{
  std::shared_ptr p (pointer_factory>::create ());
}
EOF

$ g++ -Wall -Wextra -O3 -c -std=c++23 use-after-free.cxx
In static member function ‘static void pointer_traits
>::free(void*) [with T = s]’,
inlined from ‘pointer_factory::mem_guard::~mem_guard() [with T = s; P
= std::shared_ptr]’ at use-after-free.cxx:42:52,
inlined from ‘static P pointer_factory::create() [with T = s; P =
std::shared_ptr]’ at use-after-free.cxx:36:3,
inlined from ‘int main()’ at use-after-free.cxx:52:74:
use-after-free.cxx:19:21: warning: pointer may be used after ‘void operator
delete(void*, std::size_t)’ [-Wuse-after-free]
   19 | operator delete (p);
  | ^~~
In file included from
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/12.0.1/bits/shared_ptr.h:53,
 from
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/12.0.1/memory:77,
 from use-after-free.cxx:1:
In constructor ‘std::__shared_count<_Lp>::__shared_count(_Ptr) [with _Ptr = s*;
__gnu_cxx::_Lock_policy _Lp = __gnu_cxx::_S_atomic]’,
inlined from ‘std::__shared_count<_Lp>::__shared_count(_Ptr,
std::false_type) [with _Ptr = s*; __gnu_cxx::_Lock_policy _Lp =
__gnu_cxx::_S_atomic]’ at
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/12.0.1/bits/shared_ptr_base.h:928:22,
inlined from ‘std::__shared_ptr<_Tp, _Lp>::__shared_ptr(_Yp*) [with _Yp =
s;  = void; _Tp = s; __gnu_cxx::_Lock_policy _Lp =
__gnu_cxx::_S_atomic]’ at
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/12.0.1/bits/shared_ptr_base.h:1469:17,
inlined from ‘std::shared_ptr<_Tp>::shared_ptr(_Yp*) [with _Yp = s;
 = void; _Tp = s]’ at
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/12.0.1/bits/shared_ptr.h:214:46,
inlined from ‘static P pointer_factory::create() [with T = s; P =
std::shared_ptr]’ at use-after-free.cxx:32:7,
inlined from ‘int main()’ at use-after-free.cxx:52:74:
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/12.0.1/bits/shared_ptr_base.h:921:15:
note: call to ‘void operator delete(void*, std::size_t)’ here
  921 |   delete __p;
  |   ^~

[Bug libstdc++/86164] std::regex crashes when matching long lines

[boris at kolpackov dot net via Gcc-bugs]

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

Boris Kolpackov  changed:

   What|Removed |Added

 CC||boris at kolpackov dot net

--- Comment #9 from Boris Kolpackov  ---
Any progress on this?

I get the segfault (due to stack overflow) with the following trivial regex:

  regex re ("#+",);
  regex_search (string (32 * 1024, '#'), re);

In comparison, MSVC's implementation crashes on much larger input (in the above
test it is still able to match 4MB string) while libc++ doesn't seem to have
any stack-related limits (I was able to match 40MB).

I see two issues here:

1. It would have been nice if implementation-related limits were reported with
an exception rather than a crash.

2. The limits seem to be really low, both practically (matching 32KB doesn't
feel unreasonable) and compared to other implementations.

[Bug c++/84583] -fdirectives-only does not handle CRLF properly

[boris at kolpackov dot net via Gcc-bugs]

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

Boris Kolpackov  changed:

   What|Removed |Added

  Component|preprocessor|c++
Version|7.2.0   |10.2.0

--- Comment #1 from Boris Kolpackov  ---
Still being bitten by this with GCC 10.2. Any translation unit that uses a line
continuation in a string literal triggers this bug. A typical example:

char copyright[] =
"@(#) Copyright (c) 1990 The Regents of the University of California.\n\
 All rights reserved.\n";

[Bug c++/101361] New: Bogus -Wstringop-overread warning with -O3

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 101361
   Summary: Bogus -Wstringop-overread warning with -O3
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

Created attachment 51113
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51113=edit
reproducer

g++ -Wall -Wextra -O3 -std=c++2a -o driver.o -c -fdirectives-only driver.ii

In file included from
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.1/string:40,
 from
/home/boris/work/build2/libbutl/tests/prefix-map/driver.cxx:7:
In static member function ‘static constexpr int
std::char_traits::compare(const char_type*, const char_type*,
std::size_t)’,
inlined from ‘int butl::compare_prefix
>::compare(const C*, butl::compare_prefix
>::size_type, const C*, butl::compare_prefix
>::size_type) const [with C = char]’ at
/home/boris/work/build2/libbutl/libbutl/prefix-map.mxx:93:35,
inlined from ‘bool butl::compare_prefix
>::prefix(const K&, const K&) const [with C = char]’ at
/home/boris/work/build2/libbutl/libbutl/prefix-map.mxx:70:18,
inlined from ‘std::pair butl::prefix_map_common::find_sub(const key_type&) const
[with M = std::map, int,
butl::compare_prefix >,
std::allocator, int> > >]’ at
/home/boris/work/build2/libbutl/libbutl/prefix-map.txx:36:21:
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.1/bits/char_traits.h:361:32:
warning: ‘int __builtin_memcmp_eq(const void*, const void*, long unsigned int)’
specified bound 18446744073709551615 exceeds maximum object size
9223372036854775807 [-Wstringop-overread]
  361 | return __builtin_memcmp(__s1, __s2, __n);
  |^
In file included from
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.1/string:55,
 from
/home/boris/work/build2/libbutl/tests/prefix-map/driver.cxx:7:
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.1/bits/basic_string.h:
In member function ‘std::pair butl::prefix_map_common::find_sub(const key_type&) const
[with M = std::map, int,
butl::compare_prefix >,
std::allocator, int> > >]’:
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.1/bits/basic_string.h:187:28:
note: source object allocated here
  187 |   { return _M_dataplus._M_p; }
  |^~~~
In file included from
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.1/string:40,
 from
/home/boris/work/build2/libbutl/tests/prefix-map/driver.cxx:7:
In static member function ‘static constexpr int
std::char_traits::compare(const char_type*, const char_type*,
std::size_t)’,
inlined from ‘int butl::compare_prefix
>::compare(const C*, butl::compare_prefix
>::size_type, const C*, butl::compare_prefix
>::size_type) const [with C = char]’ at
/home/boris/work/build2/libbutl/libbutl/prefix-map.mxx:93:35,
inlined from ‘bool butl::compare_prefix
>::prefix(const K&, const K&) const [with C = char]’ at
/home/boris/work/build2/libbutl/libbutl/prefix-map.mxx:70:18,
inlined from ‘std::pair
butl::prefix_map_common::find_sub(const key_type&) [with M =
std::map, int,
butl::compare_prefix >,
std::allocator, int> > >]’ at
/home/boris/work/build2/libbutl/libbutl/prefix-map.txx:17:21:
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.1/bits/char_traits.h:361:32:
warning: ‘int __builtin_memcmp_eq(const void*, const void*, long unsigned int)’
specified bound 18446744073709551615 exceeds maximum object size
9223372036854775807 [-Wstringop-overread]
  361 | return __builtin_memcmp(__s1, __s2, __n);
  |^
In file included from
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.1/string:55,
 from
/home/boris/work/build2/libbutl/tests/prefix-map/driver.cxx:7:
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.1/bits/basic_string.h:
In member function ‘std::pair
butl::prefix_map_common::find_sub(const key_type&) [with M =
std::map, int,
butl::compare_prefix >,
std::allocator, int> > >]’:
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.1/bits/basic_string.h:187:28:
note: source object allocated here
  187 |   { return _M_dataplus._M_p; }
  |^~~~

[Bug preprocessor/101298] New: Inclusion of a file without trailing newline breaks -fdirectives-only

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 101298
   Summary: Inclusion of a file without trailing newline breaks
-fdirectives-only
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

cat test.hxx

g++ -E -fdirectives-only -o test.ii test.cxx
In file included from test.cxx:1:
test.hxx:1:1: error: unterminated comment

echo -n "void f () {}" >test.hxx

g++ -E -fdirectives-only -o test.ii test.cxx

grep "void f () {}" test.ii
void f () {}# 2 "test.cxx" 2

g++ -c -fdirectives-only test.ii
In file included from test.cxx:1:
test.hxx:1:13: error: stray ‘#’ in program

This used to work fine prior to GCC 11. I believe this issue is similar but not
the same as bug #100646.

[Bug tree-optimization/100115] Bogus -Wmaybe-uninitialized warning with -O3

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #2 from Boris Kolpackov  ---
> I'm trying to reduce the test case to something manageable but that can take 
> many hours, even days.

Right. On our side we have spent hours, even days trying to suppress this
warning (both by rearranging the code and with #pragma) but it keep popping up
in different places and on different targets (MinGW, Mac OS, etc). In fact,
we've wasted so much time on chasing this (and similar issues in the past),
that I am seriously considering just globally disabling this warning since it
seems more trouble than it's worth. Sorry, just venting a bit here...

> It would be really helpful if you could trim it down a bit, e.g., by removing 
> the biggest non-essentials like .

I will try. The thing is, such simplifications often make the warning
disappear. We have tens of similar code fragments in our codebase, but only
this one triggers a warning on x86_64-linux (other places trigger it on MinGW
and Mac OS).

> That being said, the context of the warning mentions std::optional which has 
> been known to be challenging for analysis [...]

Yes, I can confirm that most of the issues with this warning we've encountered
in the past involved std::optional.

[Bug c++/100115] New: Bogus -Wmaybe-uninitialized warning with -O3

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 100115
   Summary: Bogus -Wmaybe-uninitialized warning with -O3
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

Created attachment 50615
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50615=edit
Reproducer

The attached translation unit produces a bogus "may be used uninitialized"
warning:

$ g++-10 -Wmaybe-uninitialized -O3 -std=c++2a -fdirectives-only -c driver.ii
In file included from
/tmp/dist2/libbutl-0.14.0-a.0.20210415102025.fc5599e0a51a/libbutl/utility.mxx:550,
 from driver.cxx:32:
/tmp/dist2/libbutl-0.14.0-a.0.20210415102025.fc5599e0a51a/libbutl/utility.ixx:
In function ‘int main(int, const char**)’:
/tmp/dist2/libbutl-0.14.0-a.0.20210415102025.fc5599e0a51a/libbutl/utility.ixx:345:17:
warning: ‘ate’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
  345 | thread_env_ = v;
  | ^~~
driver.cxx:392:19: note: ‘ate’ was declared here
  392 |   auto_thread_env ate (tevars);
  |   ^~~

The same with GCC 11:

$ g++-11 -Wmaybe-uninitialized -O3 -std=c++2a -fdirectives-only -c driver.ii
In file included from
/tmp/dist2/libbutl-0.14.0-a.0.20210415102025.fc5599e0a51a/libbutl/utility.mxx:550,
 from driver.cxx:32:
/tmp/dist2/libbutl-0.14.0-a.0.20210415102025.fc5599e0a51a/libbutl/utility.ixx:
In function ‘int main(int, const char**)’:
/tmp/dist2/libbutl-0.14.0-a.0.20210415102025.fc5599e0a51a/libbutl/utility.ixx:345:17:
warning: ‘*(const char* const**)((char*) + offsetof(butl::auto_thread_env,
butl::auto_thread_env::prev_env.std::optional::.std::_Optional_base::))’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
  345 | thread_env_ = v;
  | ^~~
driver.cxx:392:19: note: ‘*(const char* const**)((char*) +
offsetof(butl::auto_thread_env,
butl::auto_thread_env::prev_env.std::optional::.std::_Optional_base::))’ was declared here
  392 |   auto_thread_env ate (tevars);
  |   ^~~

In fact, I get a variant of this warning going all the way to GCC 4.9. The
driver.ii file was prepared on Linux (with -fdirectives-only).

[Bug c++/99377] [modules] undefined std::string_view::empty() if referenced in inline exported function

[boris at kolpackov dot net via Gcc-bugs]

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

Boris Kolpackov  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #4 from Boris Kolpackov  ---
I still get the same error if I move the inline function into an interface
partition (main.cxx is unchanged):

cat 

[Bug c++/98760] [modules] ICE in add_module_decl

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #2 from Boris Kolpackov  ---
This still reproduces as of 11.0.1 20210304 (f3641ac70e) though the location
has changed:

hello.cxx:18:25: internal compiler error: in lookup_mark, at cp/tree.c:2403
   18 | o << format_hello (n) << std::endl;
  | ^
0xde6459 lookup_mark(tree_node*, bool)
../../gcc/gcc/cp/tree.c:2403
0xc5fb19 name_lookup::search_adl(tree_node*, vec*)
../../gcc/gcc/cp/name-lookup.c:1640
0xc5fff5 lookup_arg_dependent(tree_node*, tree_node*, vec*)
../../gcc/gcc/cp/name-lookup.c:1740
0xdadd38 perform_koenig_lookup(cp_expr, vec*, int)
../../gcc/gcc/cp/semantics.c:2507
0xc92a1f cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:7658
0xc954c2 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:8818
0xc96bff cp_parser_cast_expression
../../gcc/gcc/cp/parser.c:9722
0xcc3a2c cp_parser_simple_cast_expression
../../gcc/gcc/cp/parser.c:30544
0xc9700f cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9890
0xc97c01 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:10128
0xc97f6f cp_parser_expression
../../gcc/gcc/cp/parser.c:10298
0xc9be7c cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:12012
0xc9b76a cp_parser_statement
../../gcc/gcc/cp/parser.c:11808
0xc9c42e cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:12159
0xc9c2fe cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:12109
0xcb5719 cp_parser_function_body
../../gcc/gcc/cp/parser.c:24029
0xcb5a4c cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:24080
0xcc228e cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:29997
0xcc20a6 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:29913
0xcb0156 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:21602

[Bug c++/99051] [modules] ICE/SIGSEGV in get_location_from_adhoc_loc

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #1 from Boris Kolpackov  ---
As of 11.0.1 20210304 (f3641ac70e) this no longer reproduces for me.

[Bug c++/99380] New: [modules] Unexpected MODULE-EXPORT request when partially preprocessing header unit

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 99380
   Summary: [modules] Unexpected MODULE-EXPORT request when
partially preprocessing header unit
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

A change between 11.0.0 20210217 and 11.0.1 20210304 causes an unexpected
MODULE-EXPORT request when partially preprocessing a header unit that imports
another header unit:

cat &2; }
function resp () { info "  < $*"; echo "$*"; }

while read l; do
  info "  > $l"

  case "$l" in
HELLO*)
  resp "HELLO 1 test ;"
  ;;
MODULE-REPO)
  resp "PATHNAME /"
  ;;
MODULE-EXPORT*"string_view 1"|MODULE-IMPORT*string_view)
  resp "PATHNAME $(pwd)/string_view.gcm"
  ;;
INCLUDE-TRANSLATE*)
  resp "BOOL FALSE"
  ;;
MODULE-COMPILED*)
  resp "OK"
  ;;
*)
  resp "ERROR 'unexpected request: $l'"
  ;;
  esac
done
EOF

chmod ugo+x mapper

g++ -std=c++2a -fmodules-ts -fmodule-mapper='|./mapper' -fmodule-header -x
c++-header .../include/c++/11.0.1/string_view
g++ -std=c++2a -fmodules-ts -fmodule-mapper='|./mapper' -E -fdirectives-only -o
hello.ii -fmodule-header -x c++-header hello.hxx

  > HELLO 1 GCC '' ;
  < HELLO 1 test ;
  > MODULE-REPO
  < PATHNAME /
  > MODULE-EXPORT ./hello.hxx ;
  < ERROR 'unexpected request: MODULE-EXPORT ./hello.hxx ;'
  > MODULE-IMPORT
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.1/string_view
hello.hxx: error: unknown Compiled Module Interface: unexpected request:
MODULE-EXPORT ./hello.hxx ;

However, if I change hello.hxx to #include instead of import string_view, then
there is no MODULE-EXPORT:

g++ -std=c++2a -fmodules-ts -fmodule-mapper='|./mapper' -E -fdirectives-only -o
hello.ii -fmodule-header -x c++-header hello.hxx

  > HELLO 1 GCC '' ;
  < HELLO 1 test ;
  > MODULE-REPO
  < PATHNAME /
  > INCLUDE-TRANSLATE
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.1/string_view
  < BOOL FALSE
  ...

[Bug c++/99072] [modules] Compiling header unit with partial preprocessing (-E -fdirectives-only) twice causes CRC mismatch

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #8 from Boris Kolpackov  ---
Can confirm works for me, thanks!

[Bug c++/98741] [modules] ICE/SIGSEGV reading compiled module cluster

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #4 from Boris Kolpackov  ---
Can confirm works for me, thanks!

[Bug c++/99377] New: [modules] undefined std::string_view::empty() if referenced in inline exported function

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 99377
   Summary: [modules] undefined std::string_view::empty() if
referenced in inline exported function
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

cat  const&)':
main.cxx:(.text._ZN5hello5checkERKSt17basic_string_viewIcSt11char_traitsIcEE[_ZN5hello5checkERKSt17basic_string_viewIcSt11char_traitsIcEE]+0x14):
undefined reference to `std::basic_string_view
>::empty() const'

The error goes away if hello::check is made non-inline.

[Bug c++/98718] [modules] use of partitions causes ICE in write_macro_maps

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #7 from Boris Kolpackov  ---
Can confirm works for me, thanks!

[Bug c++/99023] [modules] ICE/SIGSEGV in module_state::write_define

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #5 from Boris Kolpackov  ---
Can confirm works for me, thanks!

[Bug c++/99072] [modules] Compiling header unit with partial preprocessing (-E -fdirectives-only) twice causes CRC mismatch

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #4 from Boris Kolpackov  ---
You need to use different .ii file names on the first and second header unit
builds. Using your original command lines as a reference:

# first build of header-unit
devvm1702:45>./xg++ [...] -o 99072_a.ii 99072_a.H
devvm1702:46>./xg++ [...] -c 99072_a.ii

# second build of string
devvm1702:45>./xg++ [...] -o 99072_a.so.ii 99072_a.H
devvm1702:46>./xg++ [...] -c 99072_a.so.ii

[Bug c++/99072] [modules] Compiling header unit with partial preprocessing (-E -fdirectives-only) twice causes CRC mismatch

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #2 from Boris Kolpackov  ---
This has something to do with a different .ii file name the second time we
compile the header. Try to make this change to your command lines (notice .so 
before .ii):

# second build of string
devvm1702:45>./xg++ [...] -o 99072_a.so.ii 99072_a.H
devvm1702:46>./xg++ [...] -c 99072_a.so.ii

[Bug c++/99050] [modules] ICE in cpp_directive_only_process on include translation

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #2 from Boris Kolpackov  ---
Can confirm now works for me, thanks!

[Bug c++/99072] New: [modules] Compiling header unit with partial preprocessing (-E -fdirectives-only) twice causes CRC mismatch

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 99072
   Summary: [modules] Compiling header unit with partial
preprocessing (-E -fdirectives-only) twice causes CRC
mismatch
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

With partial preprocessing (-E -fdirectives-only) compiling the same header
with the same options twice results in two CRC-incompatible .gcm files:

cat 

[Bug c++/99051] New: [modules] ICE/SIGSEGV in get_location_from_adhoc_loc

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 99051
   Summary: [modules] ICE/SIGSEGV in get_location_from_adhoc_loc
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

cat 

[Bug preprocessor/98882] [11 Regression] ICE in in cpp_directive_only_process on empty translation unit

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #8 from Boris Kolpackov  ---
Done, bug 99050.

[Bug c++/99050] New: [modules] ICE in cpp_directive_only_process on include translation

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 99050
   Summary: [modules] ICE in cpp_directive_only_process on include
translation
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

After the fix in bug 98882 I now get an ICE (that same assert) when partially
preprocessing (-E -fdirectives-only) a TU that has an include directive that is
translated to an import:

cat &2; }
function resp () { info "  < $*"; echo "$*"; }

while read l; do
  info "  > $l"

  case "$l" in
HELLO*)
  resp "HELLO 1 test ;"
  ;;
MODULE-REPO)
  resp "PATHNAME /"
  ;;
INCLUDE-TRANSLATE*hello.hxx)
  resp "PATHNAME $(pwd)/hello.gcm"
  ;;
INCLUDE-TRANSLATE*)
  resp "BOOL FALSE"
  ;;
MODULE-EXPORT*|MODULE-IMPORT*)
  resp "PATHNAME $(pwd)/hello.gcm"
  ;;
MODULE-COMPILED*)
  resp "OK"
  ;;
*)
  resp "ERROR 'unexpected request: $l'"
  ;;
  esac
done
EOF

chmod ugo+x ./mapper

g++ -std=c++2a -fmodules-ts -fmodule-mapper='|./mapper' -fmodule-header -x c++
header hello.hxx
g++ -std=c++2a -fmodules-ts -fmodule-mapper='|./mapper' -E -fdirectives-only -x
c++ -o main.ii main.cxx

main.cxx:1: internal compiler error: in cpp_directive_only_process, at
libcpp/lex.c:4323

0x2c26a7a cpp_directive_only_process(cpp_reader*, void*, void (*)(cpp_reader*,
CPP_DO_task, void*, ...))
../../gcc/libcpp/lex.c:4323
0xf1745e scan_translation_unit_directives_only
../../gcc/gcc/c-family/c-ppoutput.c:402
0xf16928 preprocess_file(cpp_reader*)
../../gcc/gcc/c-family/c-ppoutput.c:100
0xf10e2b c_common_init()
../../gcc/gcc/c-family/c-opts.c:1195
0xbe8ea7 cxx_init()
../../gcc/gcc/cp/lex.c:332
0x180c1af lang_dependent_init
../../gcc/gcc/toplev.c:1881
0x180ca61 do_compile
../../gcc/gcc/toplev.c:2178

Note that there is no assert if we are using import directly, without include
translation.

[Bug c++/99000] [modules] declaration std::__copy_move_a2 conflicts with import

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #2 from Boris Kolpackov  ---
Thanks for pointing this out. Am I correct in interpreting the SUSPENDED status
as unlikely to be fixed for GCC 11?

[Bug c++/99023] New: [modules] ICE/SIGSEGV in module_state::write_define

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 99023
   Summary: [modules] ICE/SIGSEGV in module_state::write_define
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

Compiling the following two header units causes GCC to catch SIGSEGV in
module_state::write_define():

cat 

[Bug c++/99000] New: [modules] declaration std::__copy_move_a2 conflicts with import

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 99000
   Summary: [modules] declaration std::__copy_move_a2 conflicts
with import
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

The following header unit import causes the "declaration conflicts with import"
error:

cat ::__type
std::__copy_move_a2(std::istreambuf_iterator<_CharT, std::char_traits<_CharT>
>, std::istreambuf_iterator<_CharT, std::char_traits<_CharT> >, _CharT*)’
conflicts with import
  367 |istreambuf_iterator<_CharT> __last, _CharT*
__result)
  |   
^
In file included from
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.0/bits/char_traits.h:39,
 from
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.0/string_view:41,
 from hello.hxx:3,
of module ./hello.hxx, imported at hello.cxx:1:
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.0/bits/stl_algobase.h:471:5:
note: import declared ‘template typename
__gnu_cxx::__enable_if::__value, _CharT*>::__type
std::__copy_move_a2(std::istreambuf_iterator<_CharT, std::char_traits<_CharT>
>, std::istreambuf_iterator<_CharT, std::char_traits<_CharT> >, _CharT*)’ here
  471 | __copy_move_a2(istreambuf_iterator<_CharT, char_traits<_CharT> >,
  | ^~


Interestingly, if we change the #include and import order in hello.cxx, then
the error goes away.

[Bug preprocessor/98882] [11 Regression] ICE in in cpp_directive_only_process on empty translation unit

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #6 from Boris Kolpackov  ---
After this change I now get an ICE (that same assert) when partially
preprocessing (-E -fdirectives-only) a TU that has an include directive that is
translated to an import:

cat &2; }
function resp () { info "  < $*"; echo "$*"; }

while read l; do
  info "  > $l"

  case "$l" in
HELLO*)
  resp "HELLO 1 test ;"
  ;;
MODULE-REPO)
  resp "PATHNAME /"
  ;;
INCLUDE-TRANSLATE*hello.hxx)
  resp "PATHNAME $(pwd)/hello.gcm"
  ;;
INCLUDE-TRANSLATE*)
  resp "BOOL FALSE"
  ;;
MODULE-EXPORT*|MODULE-IMPORT*)
  resp "PATHNAME $(pwd)/hello.gcm"
  ;;
MODULE-COMPILED*)
  resp "OK"
  ;;
*)
  resp "ERROR 'unexpected request: $l'"
  ;;
  esac
done
EOF

chmod ugo+x ./mapper

g++ -std=c++2a -fmodules-ts -fmodule-mapper='|./mapper' -fmodule-header -x
c++-header hello.hxx
g++ -std=c++2a -fmodules-ts -fmodule-mapper='|./mapper' -E -fdirectives-only -x
c++ -o main.ii main.cxx

main.cxx:1: internal compiler error: in cpp_directive_only_process, at
libcpp/lex.c:4323

0x2c26a7a cpp_directive_only_process(cpp_reader*, void*, void (*)(cpp_reader*,
CPP_DO_task, void*, ...))
../../gcc/libcpp/lex.c:4323
0xf1745e scan_translation_unit_directives_only
../../gcc/gcc/c-family/c-ppoutput.c:402
0xf16928 preprocess_file(cpp_reader*)
../../gcc/gcc/c-family/c-ppoutput.c:100
0xf10e2b c_common_init()
../../gcc/gcc/c-family/c-opts.c:1195
0xbe8ea7 cxx_init()
../../gcc/gcc/cp/lex.c:332
0x180c1af lang_dependent_init
../../gcc/gcc/toplev.c:1881
0x180ca61 do_compile
../../gcc/gcc/toplev.c:2178

Note that there is no assert if we are using import directly, without include
translation.

[Bug middle-end/98753] -Wfree-nonheap-object on unreachable code with -O0

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #14 from Boris Kolpackov  ---
If this cannot be fixed for 11 (and judging by the age of 54202 I feel it's not
likely), perhaps it makes sense not to enable this warning by default? Now that
C++ operator delete() is covered by this check (see bug 57111), it's reasonable
to expect more false positives like these.

[Bug middle-end/98753] -Wfree-nonheap-object on unreachable code with -O0

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #13 from Boris Kolpackov  ---
Created attachment 50081
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50081=edit
Reproducer test-simplified.cxx

[Bug middle-end/98753] -Wfree-nonheap-object on unreachable code with -O0

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #12 from Boris Kolpackov  ---
Created attachment 50080
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50080=edit
Reproducer test.cxx

[Bug middle-end/98753] -Wfree-nonheap-object on unreachable code with -O0

[boris at kolpackov dot net via Gcc-bugs]

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

Boris Kolpackov  changed:

   What|Removed |Added

 CC||boris at kolpackov dot net

--- Comment #11 from Boris Kolpackov  ---
I believe I am encountering a similar false positive so I will attach the test
cases to this bug (but let me know if I should instead attach them to 54202 or
create a new bug). The attached test.cxx is a cleaned-up original code while
test-simplified.cxx is its further simplified version (thanks to Matthew
Krupcale for coming up with both):

g++ -O1 -c test.cxx 

In member function ‘void small_allocator::deallocate(void*,
std::size_t) [with T = f()::expr; long unsigned int N = 1; B =
small_allocator_buffer]’,
inlined from ‘std::vector<_Tp, _Alloc>::pointer std::vector<_Tp,
_Alloc>::_M_allocate_and_copy(std::vector<_Tp, _Alloc>::size_type,
_ForwardIterator, _ForwardIterator) [with _ForwardIterator = const f()::expr*;
_Tp = f()::expr; _Alloc = small_allocator >]’ at
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.0/bits/alloc_traits.h:341:23,
inlined from ‘void std::vector<_Tp, _Alloc>::reserve(std::vector<_Tp,
_Alloc>::size_type) [with _Tp = f()::expr; _Alloc = small_allocator >]’ at
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.0/bits/vector.tcc:85:36,
inlined from ‘void small_vector::reserve(std::size_t) [with T =
f()::expr; long unsigned int N = 1]’ at test.cxx:234:26,
inlined from ‘small_vector::small_vector() [with T = f()::expr; long
unsigned int N = 1]’ at test.cxx:163:15,
inlined from ‘void f()’ at test.cxx:1472:27:
test.cxx:121:27: warning: ‘void operator delete(void*)’ called on unallocated
object ‘exprs’ [-Wfree-nonheap-object]

[Bug c++/98882] New: ICE in in cpp_directive_only_process on empty translation unit

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 98882
   Summary: ICE in in cpp_directive_only_process on empty
translation unit
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

I get an internal compiler error when preprocessing with -fdirectives-only an
empty translation unit:

touch test.cxx
g++ -std=c++2a -E -fdirectives-only -o test.ii test.cxx

test.cxx:1: internal compiler error: in cpp_directive_only_process, at
libcpp/lex.c:4323
0x2c09263 cpp_directive_only_process(cpp_reader*, void*, void (*)(cpp_reader*,
CPP_DO_task, void*, ...))
../../gcc/libcpp/lex.c:4323
0xf11c8e scan_translation_unit_directives_only
../../gcc/gcc/c-family/c-ppoutput.c:402
0xf11158 preprocess_file(cpp_reader*)
../../gcc/gcc/c-family/c-ppoutput.c:100
0xf0b6e4 c_common_init()
../../gcc/gcc/c-family/c-opts.c:1188
0xbe4d7b cxx_init()
../../gcc/gcc/cp/lex.c:332
0x1805e47 lang_dependent_init
../../gcc/gcc/toplev.c:1881
0x18066f9 do_compile
../../gcc/gcc/toplev.c:2178

This is new in GCC 11.

[Bug c++/98761] [modules] use of a module causes SIGSEGV at runtime

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #1 from Boris Kolpackov  ---
Created attachment 50011
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50011=edit
Reproducer

[Bug c++/98761] New: [modules] use of a module causes SIGSEGV at runtime

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 98761
   Summary: [modules] use of a module causes SIGSEGV at runtime
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

The attached executable catches SIGSEGV when built with a module:

$ g++ -std=c++2a -fmodules-ts -x c++ -c format.mxx
$ g++ -std=c++2a -fmodules-ts -x c++ -c driver.cxx
$ g++ -std=c++2a -fmodules-ts -o test driver.o format.o
$ ./test
Segmentation fault (core dumped)
$ gdb test core
(gdb) bt
#0  __memcpy_avx_unaligned () at
../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:148
#1  0x00402cc7 in std::char_traits::copy(char*, char const*,
unsigned long) ()
#2  0x0040405c in std::__cxx11::basic_string, std::allocator >::_S_copy(char*, char const*,
unsigned long) ()
#3  0x00403f72 in std::__cxx11::basic_string, std::allocator >::_S_copy_chars(char*, char
const*, char const*) ()
#4  0x004039b0 in void std::__cxx11::basic_string, std::allocator >::_M_construct(char
const*, char const*, std::forward_iterator_tag) ()
#5  0x00403635 in void std::__cxx11::basic_string, std::allocator >::_M_construct_aux(char const*, char const*, std::__false_type)
()
#6  0x00403337 in void std::__cxx11::basic_string, std::allocator >::_M_construct(char
const*, char const*) ()
#7  0x00403072 in std::__cxx11::basic_string, std::allocator >::basic_string(char const*,
unsigned long, std::allocator const&) ()
#8  0x004033fc in std::__cxx11::basic_string, std::allocator
>::basic_string(std::__cxx11::basic_string,
std::allocator >::__sv_wrapper, std::allocator const&) ()
#9  0x004030ef in std::__cxx11::basic_string, std::allocator
>::basic_string >,
void>(std::basic_string_view > const&,
std::allocator const&) ()
#10 0x0040266b in
hello::format_hello[abi:cxx11](std::basic_string_view > const&) ()
#11 0x004020be in main ()

The same code works fine if I get rid of the module. Re-ordering the object
files during linking also helps:


$ g++ -std=c++2a -fmodules-ts -o test format.o driver.o

[Bug c++/98760] [modules] ICE in add_module_decl

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #1 from Boris Kolpackov  ---
Created attachment 50009
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50009=edit
Reproducer

[Bug c++/98760] New: [modules] ICE in add_module_decl

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 98760
   Summary: [modules] ICE in add_module_decl
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

The attached set of modules cause an internal compiler error:

c++ mxx{format}
c++ mxx{check}
c++ mxx{hello}
c++ cxx{hello} 
/home/boris/work/build2/tests/modules/gcc2/bugs/x/hello.cxx: In function ‘void
hello::say_hello(std::ostream&, const string_view&)’:
/home/boris/work/build2/tests/modules/gcc2/bugs/x/hello.cxx:18:10: internal
compiler error: in add_module_decl, at cp/name-lookup.c:4188
   18 | o << format_hello (n) << std::endl;
  |  ^~~~
0xc8ff5c add_module_decl(tree_node*, tree_node*, tree_node*)
../../gcc/gcc/cp/name-lookup.c:4188
0xc5cc17 module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14888
0xc66826 module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18036
0xc68b6c lazy_load_binding(unsigned int, tree_node*, tree_node*, binding_slot*)
../../gcc/gcc/cp/module.cc:18718
0xc80298 name_lookup::search_namespace_only(tree_node*)
../../gcc/gcc/cp/name-lookup.c:918
0xc80f82 name_lookup::search_unqualified(tree_node*, cp_binding_level*)
../../gcc/gcc/cp/name-lookup.c:1149
0xc9b77d lookup_name_1
../../gcc/gcc/cp/name-lookup.c:7910
0xc9b86d lookup_name(tree_node*, LOOK_where, LOOK_want)
../../gcc/gcc/cp/name-lookup.c:7930
0xb6f6d5 lookup_name(tree_node*, LOOK_want)
../../gcc/gcc/cp/name-lookup.h:413
0xce7da2 cp_parser_lookup_name
../../gcc/gcc/cp/parser.c:29285
0xcddbf9 cp_parser_class_name
../../gcc/gcc/cp/parser.c:24612
0xcd1b56 cp_parser_type_name
../../gcc/gcc/cp/parser.c:19162
0xcd108d cp_parser_simple_type_specifier
../../gcc/gcc/cp/parser.c:18865
0xcb90d9 cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:7420
0xcbc6aa cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:8818
0xcbddc5 cp_parser_cast_expression
../../gcc/gcc/cp/parser.c:9722
0xcea805 cp_parser_simple_cast_expression
../../gcc/gcc/cp/parser.c:30478
0xcbe1d5 cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9890
0xcbedc7 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:10128
0xcbf135 cp_parser_expression
../../gcc/gcc/cp/parser.c:10298

[Bug c++/98741] New: [modules] ICE/SIGSEGV reading compiled module cluster

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 98741
   Summary: [modules] ICE/SIGSEGV reading compiled module cluster
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

Created attachment 49998
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49998=edit
Build transcript

The following simple module causes ICE/SIGSEGV:

// hello.mxx
export module hello;
import ;
export namespace hello
{
  void say_hello (const std::string_view& name);
}

// hello.cxx
module hello;
import ;
namespace hello
{
  void say_hello (const std::string_view& n)
  {
std::cout << "Hello, " << n << '!' << std::endl;
  }
}

c++ ../../../tests/modules/gcc2/gcc-install/include/c++/11.0.0/h{string_view}
c++ ../../../tests/modules/gcc2/gcc-install/include/c++/11.0.0/h{iostream}
c++ mxx{hello}
c++ cxx{hello}
In module imported at
/home/boris/work/build2/cxx20-modules-examples/hello-module/hello/hello.mxx:2:1,
of module hello, imported at
/home/boris/work/build2/cxx20-modules-examples/hello-module/hello/hello.cxx:1:
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.0/string_view:
error: failed to read compiled module cluster 137: Bad file data
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.0/string_view:
note: compiled module file is
‘/home/boris/work/build2/cxx20-modules-examples/hello-module/build/cc/b
uild/modules/cxx/string_view-02af41185b22.gcm’
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.0/string_view:
error: failed to read compiled module cluster 448: Bad file data
/home/boris/work/build2/cxx20-modules-examples/hello-module/hello/hello.cxx:5:30:
internal compiler error: Segmentation fault
0x180310b crash_signal
../../gcc/gcc/toplev.c:327
0xa16316 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3451
0xc4a0b5 trees_in::key_mergeable(int, merge_kind, tree_node*, tree_node*,
tree_node*, tree_node*, bool)
../../gcc/gcc/cp/module.cc:10733
0xc3bd06 trees_in::decl_value()
../../gcc/gcc/cp/module.cc:8004
0xc41e8a trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9219
0xc5cc39 module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14896
0xc66826 module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18036
0xc68a3c module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18685
0xc44657 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9730
0xc47cd8 trees_in::decl_container()
../../gcc/gcc/cp/module.cc:10346
0xc3bc3a trees_in::decl_value()
../../gcc/gcc/cp/module.cc:7992
0xc41e8a trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9219
0xc5cc39 module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14896
0xc66826 module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18036
0xc68a3c module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18685
0xc44657 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9730
0xc42102 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9269
0xc36133 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6624
0xc3810e trees_in::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7148
0xc3c012 trees_in::decl_value()
../../gcc/gcc/cp/module.cc:8043

The complete build transcript is attached.

[Bug c++/98718] [modules] use of partitions causes ICE in write_macro_maps

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #1 from Boris Kolpackov  ---
Perhaps this is the same bug but with a simpler reproducer (it points to the
same location):

cat 

[Bug c++/98720] New: [modules] update __cpp_modules value

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 98720
   Summary: [modules] update __cpp_modules value
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

It is currently 201810 while it should be 201907.

[Bug c++/98719] [modules] translating importable standard headers causes various ICEs

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #1 from Boris Kolpackov  ---
Created attachment 49991
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49991=edit
 build transcript

[Bug c++/98719] New: [modules] translating importable standard headers causes various ICEs

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 98719
   Summary: [modules] translating importable standard headers
causes various ICEs
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

Created attachment 49989
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49989=edit
 build transcript

An attempt to enable include translation for all the importable standard
headers (http://eel.is/c++draft/library#headers-4) causes various internal
compiler errors. Here are a few examples:

Trying to translate from a top-level  include:

c++ ../../gcc-install/include/c++/11.0.0/h{type_traits}
c++ ../../gcc-install/include/c++/11.0.0/h{concepts}
c++ ../../gcc-install/include/c++/11.0.0/h{compare}
In file included from
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.0/bits/stl_iterator_base_types.h:71,
 from
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.0/bits/stl_algobase.h:65,
 from
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.0/bits/char_traits.h:39,
 from
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.0/string:40:
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.0/bits/iterator_concepts.h:34:
internal compiler error: in set_filename, at cp/module.cc:19081
   34 |
  |
0xc69be8 module_state::set_filename(Cody::Packet const&)
../../gcc/gcc/cp/module.cc:19081
0xc69e4f maybe_translate_include
../../gcc/gcc/cp/module.cc:19124
0x2bfcda7 _cpp_stack_file
../../gcc/libcpp/files.c:912
0x2bfd420 _cpp_stack_include
../../gcc/libcpp/files.c:1104
0x2bf15ea do_include_common
../../gcc/libcpp/directives.c:853
0x2bf1642 do_include
../../gcc/libcpp/directives.c:865
0x2bf0bc0 _cpp_handle_directive
../../gcc/libcpp/directives.c:541
0x2c094d1 cpp_directive_only_process(cpp_reader*, void*, void (*)(cpp_reader*,
CPP_DO_task, void*, ...))
../../gcc/libcpp/lex.c:4393
0xf11c8e scan_translation_unit_directives_only
../../gcc/gcc/c-family/c-ppoutput.c:402
0xf11158 preprocess_file(cpp_reader*)
../../gcc/gcc/c-family/c-ppoutput.c:100
0xf0b6e4 c_common_init()
../../gcc/gcc/c-family/c-opts.c:1188
0xbe4d7b cxx_init()
../../gcc/gcc/cp/lex.c:332
0x1805e47 lang_dependent_init
../../gcc/gcc/toplev.c:1881
0x18066f9 do_compile
../../gcc/gcc/toplev.c:2178


Trying to translate from a top-level  include:

c++ ../../gcc-install/include/c++/11.0.0/h{iosfwd}
c++ ../../gcc-install/include/c++/11.0.0/h{typeinfo}
c++ ../../gcc-install/include/c++/11.0.0/h{new}
c++ ../../gcc-install/include/c++/11.0.0/h{type_traits}
c++ ../../gcc-install/include/c++/11.0.0/h{exception}
/home/boris/work/build2/tests/modules/gcc2/gcc-install/include/c++/11.0.0/exception:
internal compiler error: in write_cluster, at cp/module.cc:14563
0xc5b52c module_state::write_cluster(elf_out*, depset**, unsigned int,
depset::hash&, unsigned int*, unsigned int*)
../../gcc/gcc/cp/module.cc:14562
0xc65808 module_state::write(elf_out*, cpp_reader*)
../../gcc/gcc/cp/module.cc:17691
0xc6bbfd finish_module_processing(cpp_reader*)
../../gcc/gcc/cp/module.cc:19747
0xb8a7a1 c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.c:5178
0xf0b805 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1233

The build transcripts for these two cases are attached.

[Bug c++/98718] New: [modules] use of partitions causes ICE in write_macro_maps

[boris at kolpackov dot net via Gcc-bugs]

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

Bug ID: 98718
   Summary: [modules] use of partitions causes ICE in
write_macro_maps
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at kolpackov dot net
  Target Milestone: ---

Created attachment 49988
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49988=edit
Reproducer

The attached set of translation units causes an internal compiler error:

hello.mxx:5:9: internal compiler error: in write_macro_maps, at
cp/module.cc:16113
5 | export module hello;
  | ^~
0xc60a67 module_state::write_macro_maps(elf_out*, location_map_info&,
module_state_config*, unsigned int*)
../../gcc/gcc/cp/module.cc:16113
0xc659f1 module_state::write(elf_out*, cpp_reader*)
../../gcc/gcc/cp/module.cc:17727
0xc6bbfd finish_module_processing(cpp_reader*)
../../gcc/gcc/cp/module.cc:19747
0xb8a7a1 c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.c:5178
0xf0b805 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1233

If I replace std::string with const char* and get rid of the 
inclusion, then the ICE disappears. The build transcript is included in the
attached archive.

[Bug c++/98417] ICE when using C++ modules and -g

[boris at kolpackov dot net via Gcc-bugs]

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

Boris Kolpackov  changed:

   What|Removed |Added

 CC||boris at kolpackov dot net

--- Comment #1 from Boris Kolpackov  ---
I am also seeing this.