[Bug libstdc++/114879] New: std::ios::sync_with_stdio(false) triggers undefined behaviour of fflush(stdin)

[campbell+gcc-bugzilla at mumble dot net via Gcc-bugs]

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

Bug ID: 114879
   Summary: std::ios::sync_with_stdio(false) triggers undefined
behaviour of fflush(stdin)
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: campbell+gcc-bugzilla at mumble dot net
  Target Milestone: ---

std::ios::sync_with_stdio(false) creates a stdio_filebuf over stdin with mode
in:

 182 new (_cin) stdio_filebuf(stdin, ios_base::in);

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/src/c%2B%2B98/ios_init.cc;h=ace94b992b5ac7559352f5e7e94c67f64317bd9d;hb=c891d8dc23e1a46ad9f3e757d09e57b500d40044#l182

The stdio_filebuf constructor for these parameter types passes the arguments on
to __basic_file::sys_open:

 158   this->_M_file.sys_open(__f, __mode);

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/ext/stdio_filebuf.h;h=98b8fa2a095acf190237887d4e21394212d1f38a;hb=c891d8dc23e1a46ad9f3e757d09e57b500d40044#l158

With these parameter types, __basic_file::sys_open will, in turn, pass
stdin to fflush in this case, and will only actually open the file if fflush
succeeds:

 216 do
 217   __err = fflush(__file);
 218 while (__err && errno == EINTR);
 219 errno = __save_errno;
 220 if (!__err)
 221   {
 222 _M_cfile = __file;
 223 _M_cfile_created = false;
 224 __ret = this;
 225   }

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/config/io/basic_file_stdio.cc;h=27c2ad2afe3ade7284ec9d487b74d3d04dd756f4;hb=c891d8dc23e1a46ad9f3e757d09e57b500d40044#l216

But stdin is an input stream, not an output or update stream.  And calling
fflush on an input stream is undefined behaviour in standard C:

> If stream points to an output stream or an update stream in which
> the most recent operation was not input, the fflush function causes
> any unwritten data for that stream to be delivered to the host
> environment to be written to the file; otherwise, the behavior is
> undefined.
> 
> (ISO C11 and ISO C17, Sec. 7.21.5.2 `The fflush function')

On NetBSD 9, what fflush(stdin) does depends on whether fd 0 is open for
writing or not:

- If fd 0 is open for writing (unlikely but possible), it will write a buffer's
worth of heap garbage to fd 0.
- If fd 0 is not open for writing (more likely), fflush will fail with EBADF,
causing __basic_file::sys_open to fail, after which although
std::cin.good() will initially return true, std::cin will otherwise be
nonfunctional (https://gnats.NetBSD.org/58206).

Fix: Don't call fflush if the mode is input.

(This bug first appeared no later than GCC 7, which NetBSD 9 ships with and
where I found the bug, and still appears in GCC 13.2.0, as quoted in the code
above.)

[Bug c/113973] New: Pleas issue a warning when using plain character values in bitwise operations

[gcc-bugzilla at mkarcher dot dialup.fu-berlin.de via Gcc-bugs]

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

Bug ID: 113973
   Summary: Pleas issue a warning when using plain character
values in bitwise operations
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at mkarcher dot dialup.fu-berlin.de
  Target Milestone: ---

This example program compiles without any kind of warning in gcc:

static char x = 0xD8;

int main(void)
{
return 0x1200 | x;
}

The value returned from main is 0xFFD8 on architectures with 32-bit int and
signed characters by default. After just fixing a bug that was caused by an
unexpected sign expansion when building an int from individual bytes, I'd
rather have a warning if

1) A variable of type char is promoted to int.
2) The int value is used in an bitwise expression
3) More than 8 bits of the results are actually used
4) More than 8 bits may be non-zero

Because of condition 3, this will yiels no warning on "char y = x | 0x40;" (top
bits truncated, so condition 3 fails) and no warning on "int y = x & 0x40;"
(all high bits are guaranteed to be zero, so condition 4 fails).

The real-world bug that motivates this enhancement proposal is
https://github.com/hfst/hfst-ospell/issues/43

[Bug sanitizer/113244] Potential thread sanitizer false positive with future exception

[gcc-bugzilla at mhxnet dot de via Gcc-bugs]

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

--- Comment #2 from Marcus Holland-Moritz  ---
(In reply to Andrew Pinski from comment #1)
> I suspect this is because libstdc++.so is NOT instrumented for TSAN.

This is certainly possible.

Is there documentation available on how to build a suitably instrumented
libstdc++.so?

I've spent a few hours now trying to build

- all of gcc-13.2/gcc-12.3
- only libstdc++-v3 from gcc-13.2/gcc-12.3

with the following flags:

  CFLAGS="-fsanitize=thread -g -O2 -fno-omit-frame-pointer"
  CXXFLAGS="-fsanitize=thread -g -O2 -fno-omit-frame-pointer"
  LDFLAGS="-fsanitize=thread"

All of my attempts failed due to strange errors (which I can list here more
systematically if desired). A "plain" gcc build with no sanitizer-specific
compiler/linker flags works just fine.

Given that "libstdc++.so is NOT instrumented for TSAN" is a frequent response
to similar false positive reports, I'm somewhat surprised by the lack of easily
discoverable information on how to build an instrumented library. It also makes
me wonder how useful the thread sanitizer (maybe other sanitizers as well) is
at all without such an instrumented library. If an instrumented library is a
requirement for `-fsanitize=thread` to work properly, there should probably
exist a `configure` option to automatically build the required instrumented
library versions (and ideally the right version would be used when linking with
`-fsanitize=thread`).

[Bug sanitizer/113244] New: Potential thread sanitizer false positive with future exception

[gcc-bugzilla at mhxnet dot de via Gcc-bugs]

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

Bug ID: 113244
   Summary: Potential thread sanitizer false positive with future
exception
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at mhxnet dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Created attachment 56994
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56994=edit
C++ code to reproduce the issue

Using `g++-13 (Gentoo 13.2.1_p20230826 p7) 13.2.1 20230826` and compiling the
attached program with

g++-13 -std=c++20 -g -O2 -fsanitize=thread -fno-omit-frame-pointer -o
packaged_task packaged_task.cpp

Thread Sanitizer will likely, but not always, report several data races related
to the exception stored in the future. The races are between reading from the
exception object in the catch block on the main thread and destroying the
exception as a result of packaged_task going out of scope in one of the worker
threads.

==
WARNING: ThreadSanitizer: data race on vptr (ctor/dtor vs virtual call)
(pid=7610)
  Write of size 8 at 0x7b2c00031460 by thread T9:
#0 ~error_base /home/mhx/src/c++/test/packaged_task.cpp:12
(packaged_task+0x5574)
#1 ~my_error /home/mhx/src/c++/test/packaged_task.cpp:22
(packaged_task+0x5574)
#2 std::__exception_ptr::exception_ptr::_M_release()
/var/tmp/portage/sys-devel/gcc-13.2.1_p20230826/work/gcc-13-20230826/libstdc++-v3/libsupc++/eh_ptr.cc:105
(libstdc++.so.6+0xb2f30)
#3 std::__future_base::_Result::_M_destroy()
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/future:672
(packaged_task+0x5287)
#4
std::__future_base::_Result_base::_Deleter::operator()(std::__future_base::_Result_base*)
const /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/future:229
(packaged_task+0x5287)
#5 std::unique_ptr::~unique_ptr()
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/unique_ptr.h:404
(packaged_task+0x5287)
#6 std::__future_base::_State_baseV2::~_State_baseV2()
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/future:344
(packaged_task+0x5287)
#7 std::__future_base::_Task_state_base::~_Task_state_base()
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/future:1450
(packaged_task+0x5287)
#8 ~_Task_state
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/future:1477
(packaged_task+0x5287)
#9 destroy_at,
std::allocator, void()> >
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/stl_construct.h:88
(packaged_task+0x5287)
#10 destroy,
std::allocator, void()> >
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/alloc_traits.h:559
(packaged_task+0x5287)
#11 _M_dispose
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/shared_ptr_base.h:613
(packaged_task+0x5287)
#12
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release_last_use()
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/shared_ptr_base.h:175
(packaged_task+0x83bc)
#13 std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release()
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/shared_ptr_base.h:361
(packaged_task+0x83bc)
#14 std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count()
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/shared_ptr_base.h:1071
(packaged_task+0x83bc)
#15 std::__shared_ptr,
(__gnu_cxx::_Lock_policy)2>::~__shared_ptr()
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/shared_ptr_base.h:1524
(packaged_task+0x83bc)
#16 std::shared_ptr
>::~shared_ptr()
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/shared_ptr.h:175
(packaged_task+0x83bc)
#17 std::packaged_task::~packaged_task()
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/future:1594
(packaged_task+0x83bc)
#18 std::_Optional_payload_base
>::_M_destroy()
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/optional:287
(packaged_task+0x645c)
#19 std::_Optional_payload_base
>::_M_reset() /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/optional:318
(packaged_task+0x645c)
#20 std::_Optional_payload, false, false,
false>::~_Optional_payload()
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/optional:439
(packaged_task+0x645c)
#21 std::_Optional_base, false,
false>::~_Optional_base()
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/optional:510
(packaged_task+0x645c)
#22 std::optional >::~optional()
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/optional:705
(packaged_task+0x645c)
#23 worker /home/mhx/src/c++/test/packaged_task.cpp:45
(pac

[Bug driver/86030] specs file processing does not create response files for input directories

[john.soo+gcc-bugzilla at arista dot com via Gcc-bugs]

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

--- Comment #20 from John Soo  ---
I think that in order to really rid gcc of the E2BIG problem on linux,
COLLECT_*_OPTIONS will have to be deprecated and removed. This is particularly
a problem when executing spec files, it seems.

[Bug driver/86030] specs file processing does not create response files for input directories

[john.soo+gcc-bugzilla at arista dot com via Gcc-bugs]

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

--- Comment #19 from John Soo  ---
I verified the proposed patch sent argv through @file, but COLLECT_GCC_OPTIONS
still caused E2BIG. In the failing execve, COLLECT_GCC_OPTIONS was 134227
characters long.

[Bug driver/86030] specs file processing does not create response files for input directories

[john.soo+gcc-bugzilla at arista dot com via Gcc-bugs]

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

--- Comment #18 from John Soo  ---
And actually the proposed patch is not conservative enough, because the size of
the strings in argv/env also matter.

[Bug driver/86030] specs file processing does not create response files for input directories

[john.soo+gcc-bugzilla at arista dot com via Gcc-bugs]

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

--- Comment #17 from John Soo  ---
Created attachment 55910
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55910=edit
libiberty, Unix: pass argv over ARG_MAX through an @file

This does not handle environ being too large, but it is an adaptation of the
argv fix in pex-win32.c.

[Bug driver/86030] specs file processing does not create response files for input directories

[john.soo+gcc-bugzilla at arista dot com via Gcc-bugs]

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

--- Comment #16 from John Soo  ---
It is actually somewhat likely that ARG_MAX will be hit when running on linux
because it is hit when the stack can't contain enough pointers to contain argv
and environ (see exec.c in the kernel
https://github.com/torvalds/linux/blob/master/fs/exec.c#L509).

The bad news is that response files can only mitigate the problem since environ
must also be small enough to fit into an execv* call.

Is there a reasonable way to keep only the env vars required to exec
subprocesses?

[Bug driver/86030] specs file processing does not create response files for input directories

[john.soo+gcc-bugzilla at arista dot com via Gcc-bugs]

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

--- Comment #15 from John Soo  ---
Just for some context on what limit is hit: under man sysconf you will find a
description of ARG_MAX
(https://www.man7.org/linux/man-pages/man3/sysconf.3.html)

> ARG_MAX - _SC_ARG_MAX
> The maximum length of the arguments to the exec(3) family
> of functions.  Must not be less than _POSIX_ARG_MAX
> (4096).

Exceeding ARG_MAX will result in E2BIG
(https://man7.org/linux/man-pages/man3/errno.3.html).

> E2BIG  Argument list too long (POSIX.1-2001).

[Bug driver/86030] specs file processing does not create response files for input directories

[john.soo+gcc-bugzilla at arista dot com via Gcc-bugs]

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

--- Comment #14 from John Soo  ---
> Here though it seems that you are dealing with another sort of limit which is 
> much larger (I have seen 128K being mentioned on the GH page).If this 
> somehow corrupts the command line, it wouldn't help if that command line went 
> into a response file because it would still be wrong.To my knowledge, 
> Linux-based systems don't have a command line length limitation, so I can't 
> see how a response file approach would be useful at the point where the 
> subprocess is spawned.Whether something similar can be used at an earlier 
> point to save it from the 128K limit, whatever it is, is unknown to me.

It is a much larger limit (ARG_MAX resulting in E2BIG), but it is fundamentally
the same problem. I think we should assume that the command line is correct and
still respect ARG_MAX on linux/unix systems, too. It seems to me that the
temporary response file is the best way to do this.

[Bug driver/86030] specs file processing does not create response files for input directories

[john.soo+gcc-bugzilla at arista dot com via Gcc-bugs]

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

--- Comment #12 from John Soo  ---
I think the general problem in that issue is that ARG_MAX is not respected when
the driver (or any subprocess) execs things on linux. I think that it is not
the same as the original issue here, though.

> I don't know if its going to be helpful to see that patch as a guide

Do you think using response files like in pex-win32.c in pex-unix.c could help?
I tried this out and it seems like this may not solve all the ARG_MAX problems.

[Bug driver/86030] specs file processing does not create response files for input directories

[john.soo+gcc-bugzilla at arista dot com via Gcc-bugs]

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

--- Comment #10 from John Soo  ---
I'm also not sure
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=180ebb8a24d24fc5b105f2257d6216f6dfde62df
fixes the collect bug because collect uses collect_execute instead of the pex_*
exec functions.

[Bug driver/86030] specs file processing does not create response files for input directories

[john.soo+gcc-bugzilla at arista dot com via Gcc-bugs]

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

--- Comment #9 from John Soo  ---
Would a patch for unix doing something similar to
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=180ebb8a24d24fc5b105f2257d6216f6dfde62df
be accepted? I am happy to start working on something like it but I have no gcc
contributions yet and would like to know ahead of time if it is desired.

[Bug driver/86030] specs file processing does not create response files for input directories

[john.soo+gcc-bugzilla at arista dot com via Gcc-bugs]

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

--- Comment #8 from John Soo  ---
> Also, it is typically Windows that suffers from this limitation of command 
> line length.

Ok that may be true but I am effected by this on linux as are quite a few
others in this issue https://github.com/NixOS/nixpkgs/issues/41340

[Bug driver/86030] specs file processing does not create response files for input directories

[john.soo+gcc-bugzilla at arista dot com via Gcc-bugs]

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

John Soo  changed:

   What|Removed |Added

 CC||john.soo+gcc-bugzilla@arist
   ||a.com

--- Comment #6 from John Soo  ---
This is not a Windows-only bug, so I don't think it is fixed.

[Bug libstdc++/110970] clang / c++23 missing 'typename' prior to dependent type name 'iterator_traits<_It>::iterator_category'

[gcc-bugzilla at zulan dot net via Gcc-bugs]

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

--- Comment #2 from gcc-bugzilla at zulan dot net ---
Yes, apologies for the missing information

clang version 15.0.7
g++ (GCC) 13.2.1 20230801
(Arch)

According to https://clang.llvm.org/cxx_status.html
P0634R3 / "Down with typename!" is implemented since Clang 16 (released in
March). So maybe this is actually not a problem for much longer. Might only
affect the combination of a very recent GCC with slightly outdated Clang.

[Bug libstdc++/110970] New: clang / c++23 missing 'typename' prior to dependent type name 'iterator_traits<_It>::iterator_category'

[gcc-bugzilla at zulan dot net via Gcc-bugs]

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

Bug ID: 110970
   Summary: clang / c++23 missing 'typename' prior to dependent
type name 'iterator_traits<_It>::iterator_category'
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at zulan dot net
  Target Milestone: ---

Using clang with the current libstdc++ and c++23 (2b) fails:

echo "#include " | clang++ -std=c++2b -stdlib=libstdc++ -c -x c++ -
In file included from :1:
In file included from
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/algorithm:60:
In file included from
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/stl_algobase.h:67:
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/stl_iterator.h:2618:35:
error: missing 'typename' prior to dependent type name
'iterator_traits<_It>::iterator_category'
  { using iterator_category = iterator_traits<_It>::iterator_category; };


The line is unchanged in the current git, so I presume this is not fixed yet.

Simply adding `typename` to the line does fix the issue with clang.

This is similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100900. I won't
try to language lawyer what is technically correct here. In the other issue it
was decided to be nice and support other implementations even though it is a
(very low cost) workaround.

[Bug c/110878] -Wstringop-overflow incorrectly warns about arguments to functions with static array parameter declarations

[campbell+gcc-bugzilla at mumble dot net via Gcc-bugs]

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

--- Comment #3 from Taylor R Campbell  
---
(In reply to Andrew Pinski from comment #1)
> There is another bug report dealing with this. But IIRC this is an expected
> warning as foo is being passed an array which is size 16 but then passed to
> bar as size 128 which would be undefined.

There is nothing undefined here.

The caller's requirement as noted in the comment (which is not formally
expressible in C, as far as I know, but is obviously extremely
widespread practice) is that for foo(p, n) or bar(p, n), p must point
to the first element of an array of at least n elements.

foo additionally imposes the requirement that p have at least 16
elements.  bar additionally imposes the requirement that p have at
least 128 elements.

When the caller meets foo's contract, foo meets bar's contract.  So
there is nothing undefined.

>From C11, Sec. 6.7.6.3 `Function declarators (including prototypes)',
paragraph 7, p. 133:

> A declaration of a parameter as ``array of type'' shall be adjusted
> to ``qualified pointer to type'', where the type qualifiers (if any)
> are those specified within the [ and ] of the array type derivation.
> If the keyword static also appears within the [ and ] of the array
> type derivation, then for each call to the function, the value of the
> corresponding actual argument shall provide access to the first
> element of an array with at least as many elements as specified by
> the size expression.

Here, as required, the value of the corresponding actual argument does
provide access to the first element of an array with at least as many
elements as specified by the size expression.

In other words, this states a requirement about run-time values, which
the code meets, not about compile-time parameter declarations, which is
what GCC appears to object to.

(In reply to Andrew Pinski from comment #2)
> This is basically a dup of bug 108154 I think.

That one appears to be different: it trips -Wstringop-overread, not
-Wstringop-overflow.

[Bug c/110878] New: -Wstringop-overread incorrectly warns about arguments to functions with static array parameter declarations

[campbell+gcc-bugzilla at mumble dot net via Gcc-bugs]

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

Bug ID: 110878
   Summary: -Wstringop-overread incorrectly warns about arguments
to functions with static array parameter declarations
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: campbell+gcc-bugzilla at mumble dot net
  Target Milestone: ---

Isolated from code passing a pointer into an array and the length of the array
as separate arguments, where each function has the minimum length of the array
encoded in its parameter declaration, and uses runtime conditionals to
guarantee the minimum is met:

// bar(p, n) may access p[0], p[1], ..., p[n-1], and requires n >= 128
void bar(unsigned char[static 128], unsigned);

// foo(p, n) may access p[0], p[1], ..., p[n-1], and requires n >= 16
void
foo(unsigned char p[static 16], unsigned n)
{

if (n % 128)
n -= n % 128;
if (n)
bar(p, n);
}

: In function 'foo':
:12:17: error: 'bar' accessing 128 bytes in a region of size 16
[-Werror=stringop-overflow=]
   12 | bar(p, n);
  | ^
:12:17: note: referencing argument 1 of type 'unsigned char[128]'
:2:6: note: in a call to function 'bar'
2 | void bar(unsigned char[static 128], unsigned n);
  |  ^~~
cc1: all warnings being treated as errors
Compiler returned: 1

Reproduced in GCC 10.5, 11.4, and 12.3.  Not reproduced in any earlier versions
of GCC.

Using `if (n >= 128)' doesn't change anything, presumably because GCC doesn't
know the connection between p and n.

[Bug target/110592] [SPARC] GCC should default to TSO memory model when compiling for sparc32

[campbell+gcc-bugzilla at mumble dot net via Gcc-bugs]

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

--- Comment #10 from Taylor R Campbell  ---
(In reply to Eric Botcazou from comment #9)
> > I don't understand, how would that help?  As I understand it, whenever
> > `-mcpu=v7', the memory model is just ignored -- even if we set it to TSO --
> > because all rules that depend on it are gated on TARGET_V8 || TARGET_V9 or
> > simila
> 
> Well, the subject of the PR is "GCC should default to TSO memory model when
> compiling for sparc32" so you'll get exactly that.

But defaulting to TSO doesn't seem to help with generating LDSTUB in
sparcv7-only instruction streams, unless I misunderstand how this is different
from trying to combine `-mcpu' and `-mmemory-model'?

> So you want to mix memory models and synchronization instructions with
> -mcpu=v7, although they were introduced in the V8 architecture?

Correct.  The idea is to have a way to generate code that works both on sparcv7
-- by avoiding v8-only instructions like SMUL/UMUL, as `-mcpu=v7' does -- and
on sparcv8 -- by generating LDSTUB instructions where store-before-load
ordering is needed, as `-mcpu=v8 -mmemory-model=tso' does.  I tried to spell
this request as `-mcpu=v7 -mmemory-model=tso' but that doesn't generate the
LDSTUB instructions needed for store-before-load ordering.

(Note that LDSTUB is available in v7 -- what's new in v8 is the relaxation of
store-before-load order of TSO, in contrast to SC.  So these requirements
aren't contradictory.)

Is that how Linux and Solaris work by default?  I wasn't able to elicit that
behaviour by combining explicit `-mcpu' and `-mmemory-model' options, so I
assumed that it wouldn't be possible for it to be the default -- and I don't
see how it could work given how the code generation rules for memory barriers
are gated on TARGET_V8 || TARGET_V9 or similar.

[Bug target/110592] [SPARC] GCC should default to TSO memory model when compiling for sparc32

[campbell+gcc-bugzilla at mumble dot net via Gcc-bugs]

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

--- Comment #7 from Taylor R Campbell  
---
> Sorry, no, NetBSD/sparc is too obscure a platform to justify changing the
> default for the entire compiler.  But you can do like Linux & Solaris and
> add sparc/tso.h to the tm_file list of sparc-*-netbsdelf*) in config.gcc.

I don't understand, how would that help?  As I understand it, whenever
`-mcpu=v7', the memory model is just ignored -- even if we set it to TSO --
because all rules that depend on it are gated on TARGET_V8 || TARGET_V9 or
similar.

I'm not asking for you to change defaults in Linux or Solaris -- I'm just
asking to be _able_ to say `-mcpu=v7 -mmemory-model=tso' and get v7-only
instruction streams with the LDSTUBs needed for TSO.  Right now, with
`-mcpu=v7', passing `-mmemory-model=tso' has no effect.

[Bug target/110592] [SPARC] GCC should default to TSO memory model when compiling for sparc32

[campbell+gcc-bugzilla at mumble dot net via Gcc-bugs]

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

Taylor R Campbell  changed:

   What|Removed |Added

 CC||campbell+gcc-bugzilla@mumbl
   ||e.net

--- Comment #5 from Taylor R Campbell  
---
(In reply to Eric Botcazou from comment #4)
> Well, you need to elaborate a bit here, because the current configuration
> has been there for a quarter of century and everybody had apparently
> survived it until a couple of days ago.

For most of that quarter century, memory ordering was limited to out-of-line
barrier/fence subroutines implemented in assembly, like membar_sync in Solaris
and NetBSD, or the thread-switch assembly routines in the kernel.

It is only relatively recently, since C11 and C++11, that a lot of programs
started using in-line barriers/fences and ordered memory operations like
store-release/load-acquire.

In that time, sparcv7 and sparcv8 haven't gotten a lot of attention, of course.

But since they were introduced, NetBSD has had a common userland for sparcv7
and sparcv8, just called `NetBSD/sparc', with a special libc loaded on sparcv8
to use v8-only instructions like SMUL and UMUL for runtime multiplication
subroutines to improve performance.  (We could in principle do the same for
LDSTUB in membar_sync on sparcv7, although we don't at the moment.)

But now that programs rely on compiler-generated barriers, there's a conflict
between gcc's v7 and v8 code generation:

1. `gcc -mcpu=v7' generates code that lacks LDSTUB where store-before-load
barriers are needed, so anything that uses Dekker's algorithm with in-line
barriers won't work correctly on a sparcv8 CPU (but it will only manifest in
extremely rare, hard-to-diagnose scenarios, because Dekker's algorithm is so
obscure).

2. `gcc -mcpu=v8' generates code that uses SMUL and UMUL and other instructions
that don't exist on sparcv7.

Evidently gcc can be made to generate SMUL/UMUL but omit LDSTUB barriers by
using `gcc -mcpu=v8 -mmemory-model=sc', but the other way around doesn't work:
`gcc -mcpu=v7 -mmemory-model=tso' still omits the LDSTUB barriers, because the
code generation rules for barriers are all gated on TARGET_V8 || TARGET_V9.

What we would like to do for NetBSD/sparc is use `-mcpu=v7 -mmemory-model=tso'
-- that is, if it worked -- by default.  The original submitter drafted a
relatively small patch to achieve this, mostly by removing TARGET_V8 ||
TARGET_V9 conditionals or changing TARGET_V8 to !TARGET_V9 in membar-related
code generation rules.  But we'd also like to avoid diverging from gcc
upstream.  Could we convince you to take up an approach like this?

Applications built to run on v7-only, of course, could omit the LDSTUBs by
using `-mcpu=v7 -mmemory-model=sc' (or perhaps we could have the default be
`-mcpu=v7 -mmemory-model=sc', but have bare `-mcpu=v7' imply `-mcpu=v7
-mmemory-model=sc' or something), and applications built to run on v8-only can
still use `-mcpu=v8' to take advantage of `SMUL/UMUL'.

I expect this would only affect a tiny fraction of programs in extremely rare
scenarios -- those that actually rely on Dekker's algorithm (already rare), and
hit problems with memory ordering (also rare, only under high contention),
using in-line barriers or ordered memory operations (which wasn't the norm a
quarter century ago when v7 and v8 were relevant).  So you have to go out of
your way to hit problems in practice, and any negative performance impact of
the extra LDSTUBs on v7 CPUs that don't need them is likely negligible.  But
it's clear from code inspection and theory that the problem is there.

[Bug c++/110441] c++17: temporary causes static member function call to confuse required copy elision

[matt.cross+gcc-bugzilla at gmail dot com via Gcc-bugs]

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

Matt Cross  changed:

   What|Removed |Added

 CC||matt.cross+gcc-bugzilla@gma
   ||il.com

--- Comment #5 from Matt Cross  ---

I have also found that
* Making the function f() non-static works.  https://godbolt.org/z/jn6Ms1n5h
* Making a unique_ptr to an S fails: "auto sp = std::make_unique(); return
sp->f();"  https://godbolt.org/z/85e9MW91b

I suspect it is the same root cause, but just in case there's wrinkles here I
thought these additional test cases might be helpful.

[Bug c++/110140] New: Vector extensions cause false conflict in template argument deduction

[gcc-bugzilla at richardebeling dot de via Gcc-bugs]

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

Bug ID: 110140
   Summary: Vector extensions cause false conflict in template
argument deduction
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at richardebeling dot de
  Target Milestone: ---

This code snippet does not compile with GCC 13.1 and the current "trunk"
version on godbolt (see https://godbolt.org/z/7zcTq4nGz)

```c++
template 
using Vec __attribute__((vector_size(16))) = T;

template 
void foo(Vec arg1, T arg2) {}

void bar() {
foo(Vec{}, 1);
}
```

with this error:
```
: In function 'void bar()':
:8:8: error: no matching function for call to 'foo(Vec, int)'
8 | foo(Vec{}, 1);
  | ~~~^~~
:5:6: note: candidate: 'template void foo(Vec, T)'
5 | void foo(Vec arg1, T arg2) {}
  |  ^~~
:5:6: note:   template argument deduction/substitution failed:
:8:8: note:   deduced conflicting types for parameter 'T' ('__vector(4)
int' and 'int')
8 | foo(Vec{}, 1);
  | ~~~^~~
```

To me, it seems like `T` should be deduced to be `int` here and the conflicting
detected type `__vector(4) int` is a bug.

If the call to `foo` is changed to explicitly name the template argument as
`int` (-> `foo(Vec{}, 1);`), the code compiles.

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

[gcc-bugzilla at al42and dot me via Gcc-bugs]

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

--- Comment #29 from Andrey Alekseenko  ---
> it seems like we should treat *any* class with a reference member as a 
> reference wrapper. 

And any class with a pointer, I suspect.

This is a reduced/simplified example from our codebase still triggering the
error even with 59bfdd5f467292a368d0d628084a4b65d1bb06bb:

$ cat test.cpp 
struct ArrayRef
{
ArrayRef(int* ptr) : ptr_(ptr) {}
int& operator[](int n) const { return ptr_[n]; }
int* ptr_;
};

int main()
{
inta;
const int& r = ArrayRef()[0];
}

$ g++ -std=c++17 -Wdangling-reference test.cpp -o test
test.cpp: In function ‘int main()’:
test.cpp:11:16: warning: possibly dangling reference to a temporary
[-Wdangling-reference]
   11 | const int& r = ArrayRef()[0];
  |^
test.cpp:11:34: note: the temporary was destroyed at the end of the full
expression ‘ArrayRef((& a)).ArrayRef::operator[](0)’
   11 | const int& r = ArrayRef()[0];
  |  ^

[Bug c/108483] gcc warns about suspicious constructs for unevaluted ?: operand

[gcc-bugzilla at mkarcher dot dialup.fu-berlin.de via Gcc-bugs]

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

--- Comment #3 from Michael Karcher  ---
Thanks for the pointer to #4210. Note that 4210 is slightly different, though.
In that report, the condition and the warnable expression are in different
statements, and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210#c13
explicitly mentioned using a ternary expression to enable gcc to see the
deadness of the code, using a flag called "skip_evaluation".

This PR concerns a case that uses ?:, so I wonder whether skip_evaluation still
exists, and could be used to gate the sizeof-pointer-div warning.

[Bug c/108483] New: gcc warns about suspicious constructs for unevaluted ?: operand

[gcc-bugzilla at mkarcher dot dialup.fu-berlin.de via Gcc-bugs]

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

Bug ID: 108483
   Summary: gcc warns about suspicious constructs for unevaluted
?: operand
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at mkarcher dot dialup.fu-berlin.de
  Target Milestone: ---

Created attachment 54318
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54318=edit
minimal example

A well-known construct to determine array sizes at compile time is

#define ARRAY_SIZE(x) (sizeof(x)/sizeof(*(x)))

gcc helpfully warns for dangerous mis-use of this macro, as it only works with
real arrays, not with pointer, for example. Assuming NULL is defined as
((void*)0), ARRAY_SIZE(NULL) yields a valid C expression, as long as we use the
gcc extension that sizeof(void) equals one:

ARRAY_SIZE(NULL) is expanded to essentially sizeof(void*)/sizeof(void)

which yields 8 on usual 64-bit systems and 4 on usual 32-bit system. While this
expression is valid, the result of this expression is likely not what the
programmer intended, so the gcc warning "division ‘sizeof (void *) / sizeof
(void)’ does not compute the number of array elements" is warranted.

The Linux kernel contains a macro essentially being

#define ARRAY_SIZE_MAYBENULL(x)  ( __builtin_types_compatible_p(typeof(x),
void*) ? 0 : (sizeof(x)/sizeof(*x)) )

which is intended to be invocable using actual array operands (returning the
array size) or the compile-time constant NULL (returning zero).

gcc correctly evaluates ARRAY_SIZE_MAYBENULL(NULL) to zero, but emits about the
suspicious pattern in the third operand of the ternary operator. This is not
helpful for the programmer, and breaks builds using -Wall -Werror.

This is a feature request to omit warnings about dubious constructs like this
if it can be statically determined that they are not evaluated.

The example in the attachment compiles correctly and initializes x to 1, but
emits the spurious warning about the unevaluated sizeof pattern.

[Bug c++/108195] New: Incorrect implicit conversion when assigning initializer_list to std::vector

[gcc-bugzilla at al42and dot me via Gcc-bugs]

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

Bug ID: 108195
   Summary: Incorrect implicit conversion when assigning
initializer_list to std::vector
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at al42and dot me
  Target Milestone: ---

The following code compiles fine with Clang 15 and GCC 12 and outputs "3" when
run.

With GCC 13, it produces a warning about narrowing conversion and constructs a
vector of length 2.

$ cat test.cpp 
#include 
#include 

struct S
{
S(bool) {}
};

int main()
{
std::vector v = { true, false, true };
std::cout << v.size() << std::endl;
}

$ g++ -std=c++17 test.cpp -o test
test.cpp: In function ‘int main()’:
test.cpp:11:44: warning: narrowing conversion of ‘(((void)const bool [3]{true,
false, true}), ((const bool*)(&)))’ from ‘const bool*’ to ‘bool’
[-Wnarrowing]
   11 | std::vector v = { true, false, true };
  |^
test.cpp:11:44: warning: narrowing conversion of ‘(((const
bool*)(&)) + 3)’ from ‘const bool*’ to ‘bool’ [-Wnarrowing]

$ ./test
2

Using a constructor instead of the assignment avoids this problem:
std::vector v { true, false, true }; // works fine

Creating an initializer_list separately is also ok:
std::initializer_list il = { true, false, true };
std::vector   v  = il; // no problem here, vector has three elements

Tested with GCC fdc7469cf597ec11229ddfc3e9c7a06f3d0fba9d. Bisection points to
d081807d8d70e3e87eae41e1560e54d503f4d465 (PR105838).

[Bug c++/107732] ICE in lower_bound, at value-range.h:350

[gcc-bugzilla at al42and dot me via Gcc-bugs]

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

--- Comment #2 from Andrey Alekseenko  ---
@Aldy Hernandez, thank you. Can confirm that your patch fully resolves the
issue for me.

[Bug c++/107732] New: ICE in lower_bound, at value-range.h:350

[gcc-bugzilla at al42and dot me via Gcc-bugs]

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

Bug ID: 107732
   Summary: ICE in lower_bound, at value-range.h:350
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at al42and dot me
  Target Milestone: ---

Created attachment 53916
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53916=edit
Preprocessed source (-freport-bug)

The following code (reduced example) triggers an ICE with a recent `master`
(96e4244ef3ccf4867ca4e37fbc6800e64ef30af6).

$ cat test.ii 
extern "C" double sqrt(double);
double a, b, c;
void d() {
  for (;;) {
c = __builtin_fabs(a);
sqrt(c);
if (a)
  a = b;
  }
}

$ /home/aland/gcc-trunk/bin/g++ -O2 -c test.ii
during GIMPLE pass: thread
test.ii: In function ‘void d()’:
test.ii:3:6: internal compiler error: in lower_bound, at value-range.h:350
3 | void d() {
  |  ^
0x9a92fc frange::lower_bound() const
../.././gcc/value-range.h:350
0x9a947d frange::lower_bound() const
../.././gcc/value-range.h:1127
0x9a947d foperator_abs::op1_range(frange&, tree_node*, frange const&, frange
const&, relation_trio) const
../.././gcc/range-op-float.cc:1413
0x211bc78 foperator_abs::op1_range(frange&, tree_node*, frange const&, frange
const&, relation_trio) const
../.././gcc/range-op-float.cc:1390
0x2002c25 gori_compute::compute_operand1_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
../.././gcc/gimple-range-gori.cc:1095
0x2001913 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
../.././gcc/gimple-range-gori.cc:692
0x2002c9f gori_compute::compute_operand1_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
../.././gcc/gimple-range-gori.cc:1150
0x2001913 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
../.././gcc/gimple-range-gori.cc:692
0x2005742 gori_compute::outgoing_edge_range_p(vrange&, edge_def*, tree_node*,
range_query&)
../.././gcc/gimple-range-gori.cc:1373
0x13d21fd path_range_query::compute_ranges_in_block(basic_block_def*)
../.././gcc/gimple-range-path.cc:454
0x13d28a2 path_range_query::compute_ranges(bitmap_head const*)
../.././gcc/gimple-range-path.cc:622
0x14569e9 back_threader::find_taken_edge_cond(vec const&, gcond*)
../.././gcc/tree-ssa-threadbackward.cc:324
0x1456b9e back_threader::maybe_register_path(back_threader_profitability&)
../.././gcc/tree-ssa-threadbackward.cc:248
0x1456ec8 back_threader::find_paths_to_names(basic_block_def*, bitmap_head*,
unsigned int, back_threader_profitability&)
../.././gcc/tree-ssa-threadbackward.cc:371
0x145737c back_threader::find_paths_to_names(basic_block_def*, bitmap_head*,
unsigned int, back_threader_profitability&)
../.././gcc/tree-ssa-threadbackward.cc:479
0x145737c back_threader::find_paths_to_names(basic_block_def*, bitmap_head*,
unsigned int, back_threader_profitability&)
../.././gcc/tree-ssa-threadbackward.cc:479
0x1457dbf back_threader::maybe_thread_block(basic_block_def*)
../.././gcc/tree-ssa-threadbackward.cc:551
0x1457e71 back_threader::thread_blocks()
../.././gcc/tree-ssa-threadbackward.cc:979
0x1457ed0 execute
../.././gcc/tree-ssa-threadbackward.cc:1081
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug c++/107466] [12/13 Regression] invalid -Wnarrowing error with std::subtract_with_carry_engine

[littlefox+gcc-bugzilla--- via Gcc-bugs]

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

--- Comment #3 from Mara Sophie Grosch  ---
Standard explicitly allows using unsigned short though:
https://en.cppreference.com/w/cpp/numeric/random/subtract_with_carry_engine

[Bug c++/103081] [ICE] with "using enum"

[chris-gcc-bugzilla at cybermato dot com via Gcc-bugs]

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

--- Comment #9 from Chris MacGregor  
---
With the testcase I just attached, using 13.0.0 20221030 via Godbolt:
https://godbolt.org/z/8Y4cr6MxY

: In instantiation of 'Event::Event(EventCat, auto:1) [with auto:1 =
int]':
:38:32:   required from here
:30:30: internal compiler error: tree check: expected enumeral_type,
have record_type in tsubst_copy, at cp/pt.cc:17024
   30 | boundsCheck(a_category, kEventCat_Min);  // using
"EventCat::kEventCat_Min" instead of just "kEventCat_Min" makes this not fail
  | ~^~~

[Bug c++/103081] [ICE] with "using enum"

[chris-gcc-bugzilla at cybermato dot com via Gcc-bugs]

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

Chris MacGregor  changed:

   What|Removed |Added

 CC||chris-gcc-bugzilla@cybermat
   ||o.com

--- Comment #7 from Chris MacGregor  
---
Created attachment 53800
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53800=edit
testcase originally for bug 107460

Now that bug 107460 (ICE with "using enum" member passed to template function,
g++ 11.x-13) is marked a dup of this (indirectly, via bug 105787), attaching
the testcase here; hopefully that's helpful.

[Bug c++/107460] ICE with "using enum" member passed to template function (g++ 11.x-13)

[chris-gcc-bugzilla at cybermato dot com via Gcc-bugs]

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

--- Comment #4 from Chris MacGregor  
---
@Andrew, how did you get the output in comment #2, with "tree check: expected
enumeral_type, have record_type in tsubst_copy" in it?

Also, should this be marked as directly a dup of 103081, rather than as dup of
a dup (105787)?  (I did look at 103081, but it wasn't clear that it was
necessarily the same bug, since the upper part of the backtrace is different
from what I saw, and the lower part seems to be missing in the 103081 report.)

[Bug c++/107466] New: [12 Regression] invalid -Wnarrowing error

[littlefox+gcc-bugzilla--- via Gcc-bugs]

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

Bug ID: 107466
   Summary: [12 Regression] invalid -Wnarrowing error
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: littlefox+gcc-bugzi...@lf-net.org
  Target Milestone: ---

Created attachment 53797
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53797=edit
Code triggering the error

Hi,

the attached code (and Godbolt[1]) fails in gcc 12+ with an -Wnarrowing error
in a stdlibc++ template instantiated with an uint16_t and apparently trying to
work with a 2^31:

/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/random.tcc:545:9:
error: narrowing conversion of '2147483563' from 'unsigned int' to 'short
unsigned int' [-Wnarrowing]
  545 | __lcg(__value == 0u ? default_seed : __value);

The code works fine in 11.3 and clang (14) and since it also works in clang
using libstdc++ 12.2, this error is probably in gcc itself and not in
libstdc++.

Tested this on my machine (debian testing), where it broke after a some system
updates where installed - including a gcc update. Then tested this in Godbolt
to check compiler versions and other configurations and asked in
libera.chat/#c++ for others to verify if my code makes sense - which it seems
to do.

Best, Mara

[1] Godbolt link: https://godbolt.org/z/sj18Mv5j9

[Bug c++/107460] ICE with "using enum" member passed to template function (g++ 11.x-13)

[chris-gcc-bugzilla at cybermato dot com via Gcc-bugs]

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

--- Comment #1 from Chris MacGregor  
---
Created attachment 53794
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53794=edit
preprocessed source

[Bug c++/107460] New: ICE with "using enum" member passed to template function (g++ 11.x-13)

[chris-gcc-bugzilla at cybermato dot com via Gcc-bugs]

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

Bug ID: 107460
   Summary: ICE with "using enum" member passed to template
function (g++ 11.x-13)
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chris-gcc-bugzilla at cybermato dot com
  Target Milestone: ---

Created attachment 53793
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53793=edit
file generated by -freport-bug

The following code (also attached) causes an ICE in tsubst_copy on every
version of g++ that can handle "using enum", with either -std=c++20 or
-std=gnu++20, regardless of -O0, -O1, -O2, etc.:

  trunk (13.0.0 20221028)  (Godbolt)
  12.2.0  (Godbolt)
  12.1.0  (Ubuntu 22.04)
  11.3.0  (Godbolt)
  11.2.0  (Ubuntu 22.04)
  11.1(Ubuntu 20.04)
  (10.4 and earlier don't seem to support "using enum")

clang 13, 14, and 15 compile it with no complaint, as does MSVC (19.33 per
Godbolt, plus VS 2019 and VS 2022).

If I pass 'EventCat::kEventCat_Min' to boundsCheck() instead of just
'kEventCat_Min', it compiles without error.

-
void fatal [[noreturn]] (const char * msg);

template 
ToType boundsCheck(const FromType & value, const MinType & min)
{
if (int(value) >= int(min))
{
return static_cast(value);
}

fatal ("nope");
}

enum class EventCat
{
kEventCat_NeverUseThis = 0,
kUninitialized,
kTesting,

kEventCat_Min = kEventCat_NeverUseThis + 1,
};

struct Event
{
using enum EventCat;

Event(EventCat a_category, auto)
: category(a_category)
{
boundsCheck(a_category, kEventCat_Min);  // using
"EventCat::kEventCat_Min" instead of just "kEventCat_Min" makes this not fail
}

EventCat category = EventCat::kUninitialized;
};

void foo()
{
Event(EventCat::kTesting, 0);
}
-
On Ubuntu 22.04 using g++-12 (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0:

$ g++-12 -c -std=c++20 g++-ice-in-tsubst_copy.cpp
g++-ice-in-tsubst_copy.cpp: In instantiation of ‘Event::Event(EventCat, auto:1)
[with auto:1 = int]’:
g++-ice-in-tsubst_copy.cpp:38:32:   required from here
g++-ice-in-tsubst_copy.cpp:30:30: internal compiler error: in tsubst_copy, at
cp/pt.cc:16919
   30 | boundsCheck(a_category, kEventCat_Min);  // using
"EventCat::kEventCat_Min" instead of just "kEventCat_Min" makes this not fail
  | ~^~~
0x661b9b tsubst_copy
../../src/gcc/cp/pt.cc:16919
0x80f2ce tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.cc:21399
0x81e961 tsubst_copy_and_build_call_args
../../src/gcc/cp/pt.cc:19937
0x80f8c0 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.cc:20687
0x8200e8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.cc:19491
0x821097 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.cc:18462
0x821097 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.cc:18504
0x820c28 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.cc:18462
0x820c28 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.cc:18833
0x821632 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.cc:18462
0x821632 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.cc:18476
0x820c28 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.cc:18462
0x820c28 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.cc:18833
0x81f63c tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.cc:26412
0x81f63c instantiate_body
../../src/gcc/cp/pt.cc:26412
0x81ff09 instantiate_decl(tree_node*, bool, bool)
../../src/gcc/cp/pt.cc:26704
0x834bdb instantiate_pending_templates(int)
../../src/gcc/cp/pt.cc:26783
0x739197 c_parse_final_cleanups()
../../src/gcc/cp/decl2.cc:5128
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.

[Bug c++/106713] [11/12/13 Regression] Coroutine regression in GCC 11.3.0: if (co_await ...) crashes with a jump to ud2 since r12-3529-g70ee703c479081ac

[gcc-bugzilla at decltype dot org via Gcc-bugs]

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

Pablo Busse  changed:

   What|Removed |Added

 CC||gcc-bugzilla at decltype dot 
org

--- Comment #4 from Pablo Busse  ---
Duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106188.

[Bug c++/106188] New: [11.3 Regression] [coroutines] Incorrect frame layout after transforming conditional statement without top-level bind expression

[gcc-bugzilla at decltype dot org via Gcc-bugs]

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

Bug ID: 106188
   Summary: [11.3 Regression] [coroutines] Incorrect frame layout
after transforming conditional statement without
top-level bind expression
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at decltype dot org
  Target Milestone: ---

Created attachment 53257
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53257=edit
Minimal test case

During `morph_fn_to_coro`, `await_statement_walker` rewrites IF and SWITCH
statements by breaking the condition out into a local variable. The new
variable is inserted at the beginning of the containing bind expression.

If the original function lacked a top-level bind expression, this pushes the
resume function pointer and all following fixed-layout frame members away from
their intended placement.

Expected frame layout:
_Coro_resume_fn
_Coro_destroy_fn
_Coro_promise
_Coro_self_handle
params
_Coro_resume_index
_Coro_frame_needs_free
_Coro_initial_await_resume_called
locals (ifcd/swch)

Actual frame layout (since 11.3.0):
locals (ifcd/swch) <- out of place
_Coro_resume_fn
_Coro_destroy_fn
_Coro_promise
_Coro_self_handle
params
_Coro_resume_index
_Coro_frame_needs_free
_Coro_initial_await_resume_called

The attached program triggers this error and crashes. Uncommenting the unused
local variable resolves the crash.

[Bug rtl-optimization/102150] New: Speculative execution of inline assembly causes divide error

[jeremy-gcc-bugzilla at sawicki dot us via Gcc-bugs]

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

Bug ID: 102150
   Summary: Speculative execution of inline assembly causes divide
error
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeremy-gcc-bugzilla at sawicki dot us
  Target Milestone: ---

Created attachment 51391
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51391=edit
Reproducible test case

The attached test case uses inline assembly to wrap the x86_64 DIV instruction.
 GCC speculatively executes the inline assembly on inputs that the source
program does not, resulting in a divide error.

The GCC documentation says that non-volatile inline assembly may be discarded
or moved out of loops.  It is not obvious whether speculative execution is also
permitted.  I asked on gcc-help and was asked to file a report.

A related report points out that many projects currently wrap the DIV
instruction without using volatile:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82677

Another related report considers the similar issue of whether pure/const
functions must be non-trapping for inputs they don't actually receive:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93491

If it is determined that volatile is required, it would helpful to clarify in
the documentation that speculative execution may occur without volatile:
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Volatile

gcc version 11.2.0 (GCC)
Target: x86_64-pc-linux-gnu
Configured with: /home/jeremys/gcc-11.2.0/configure
--prefix=/home/jeremys/gcc-11.2.0-install --disable-multilib

Command line: g++ -O3 -o divasm divasm.cpp
No compiler errors/warnings are produced
When executed, a divide error occurs

[Bug libstdc++/95048] [9/10/11/12 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters

[gcc-bugzilla at m dot chronial.de via Gcc-bugs]

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

--- Comment #11 from Christian Fersch  ---
Would you accept a patch that implements my solution from comment 6? It seems
to me like that would be an improvement over the current situation.

[Bug libgcc/99157] [ARM] libgcc -mcmse check always fail

[gcc-bugzilla at garstig dot org via Gcc-bugs]

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

kratenko  changed:

   What|Removed |Added

 CC||gcc-bugzilla at garstig dot org

--- Comment #1 from kratenko  ---
Some cross links to this issue:

Original stackoverflow question:
https://stackoverflow.com/q/66240436/1358283

Question to arm embedded toolchain:
https://answers.launchpad.net/gcc-arm-embedded/+question/695596

[Bug c++/96555] "template argument involves template parameter(s)" with dot or arrow operator in partial specialization

[gcc-bugzilla at contacts dot eelis.net via Gcc-bugs]

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

Eelis  changed:

   What|Removed |Added

 CC||gcc-bugzilla at contacts dot 
eelis
   ||.net

--- Comment #2 from Eelis  ---
The following slightly simpler testcase is also accepted by clang and rejected
by gcc with the same "involves template parameter" error:

  template
  struct X;
  template
  struct X {};

[Bug c++/96299] Defaulted operator <=> implicitly deleted when a member has operator < and operator == and return type is specified

[gcc-bugzilla at mysko dot org via Gcc-bugs]

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

henrik  changed:

   What|Removed |Added

 CC||gcc-bugzilla at mysko dot org

--- Comment #2 from henrik  ---
I suggest that support for P1186R3 should not be advertised as available in GCC
at https://gcc.gnu.org/projects/cxx-status.html until this bug is resolved. 

The status page is a bit misleading since no example of the P1186R3 paper works
(as far as I know).

[Bug libstdc++/95048] [9/10/11 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters

[gcc-bugzilla at m dot chronial.de via Gcc-bugs]

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

--- Comment #9 from Christian Fersch  ---
But is it possible to query the value of -fwide-exec-charset? I had quick look
and couldn't find anything.

[Bug libstdc++/95048] [9/10/11 Regression] wstring-constructor of std::filesystem::path throws for non-ASCII characters

[gcc-bugzilla at m dot chronial.de via Gcc-bugs]

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

Christian Fersch  changed:

   What|Removed |Added

 CC||gcc-bugzilla at m dot 
chronial.de

--- Comment #6 from Christian Fersch  ---
It seems like the solution would be to use codecvt_utf8 if wchar_t is 32bit and
 codecvt_utf8_utf16 if wchar_t is 16bit. This also seems to be what libc++ is
doing. Would you accept a patch for this?

Do we need to handle systems where wchar_t is something other than 16 or 32 bit
wide?

[Bug c/96606] Shift operator not working correctly

[gcc-bugzilla at ryuar dot in]

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

RyuaNerin  changed:

   What|Removed |Added

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

--- Comment #2 from RyuaNerin  ---
Unsigned long int is 64bit integer in x64.

[Bug c/96606] Shift operator not working correctly

[gcc-bugzilla at ryuar dot in]

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

--- Comment #1 from RyuaNerin  ---
Created attachment 49059
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49059=edit
msvc vs gcc

[Bug c/96606] New: Shift operator not working correctly

[gcc-bugzilla at ryuar dot in]

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

Bug ID: 96606
   Summary: Shift operator not working correctly
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at ryuar dot in
  Target Milestone: ---

Created attachment 49058
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49058=edit
source code.

Hello.

The shift operator doesn't work correctly in some situations.

Please check the attached file.

after compiling with `gcc KISA_SEED_ECB.c`, The output below is shown.

9292920F 73870FC4 05D1ED04 182F3919
A = 9292920F >> 8 = C4929292
B = 73870FC4 >> 8 = 0F73870F



I think the correct operation result is
9292920F 73870FC4 05D1ED04 182F3919
A = 9292920F >> 8 = 00929292
B = 73870FC4 >> 8 = 0073870F


There seems to be a problem between line 353 and line 453.

Please let me know if you think I'm mistaken.

[Bug c++/96299] New: Defaulted operator <=> implicitly deleted when a member has operator < and operator == and return type is specified

[gcc-bugzilla at mysko dot org]

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

Bug ID: 96299
   Summary: Defaulted operator <=> implicitly deleted when a
member has operator < and operator == and return type
is specified
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at mysko dot org
  Target Milestone: ---

The following sample fails to compile with GCC 10.1 and with trunk as of
2020-07-22.

===
#include 

struct Legacy
{
  bool operator==(Legacy const&) const;
  bool operator<(Legacy const&) const;
};

struct A
{
  std::strong_ordering operator <=> (A const& other) const = default;
  Legacy l;
};

int main()
{
  A a, b;

  return a < b;
}
===

With the following error:
: In function 'int main()':

:19:14: error: use of deleted function 'constexpr std::strong_ordering
A::operator<=>(const A&) const'

   19 |   return a < b;

  |  ^

:11:24: note: 'constexpr std::strong_ordering A::operator<=>(const A&)
const' is implicitly deleted because the default definition would be
ill-formed:

   11 |   std::strong_ordering operator <=> (A const& other) const = default;

  |^~~~

:11:24: error: no match for 'operator<=>' (operand types are 'Legacy'
and 'Legacy')


>From my understanding of p1186r3
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1186r3.html) the code
should be accepted. The GCC standards support table lists p1186r3 as
implemented in GCC 10. According to p1186r3, the defaulted operator <=> should
use the member's < and == operators if the return type is specified
(strong/weak/partial), and should not require a <=> operator for the member.

[Bug analyzer/95152] New: internal compiler error: in get_or_create_mem_ref, at analyzer/region-model.cc:6938

[pieter+gcc-bugzilla at plexis dot eu]

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

Bug ID: 95152
   Summary: internal compiler error: in get_or_create_mem_ref, at
analyzer/region-model.cc:6938
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: pieter+gcc-bugzilla at plexis dot eu
  Target Milestone: ---

Created attachment 48545
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48545=edit
The pre-processed source

While compiling dnsdist[1] from git with '-fanalyzer', GCC 10.1.0 has an
internal compiler error:

during IPA pass: analyzer
In file included from dnsdist.hh:24,
 from dnsdist-lua-bindings.cc:23:
ext/luawrapper/include/LuaContext.hpp: In lambda function:
ext/luawrapper/include/LuaContext.hpp:1241:27: internal compiler error: in
get_or_create_mem_ref, at analyzer/region-model.cc:6938
 1241 | writeFunction_(*object, value);
  | ~~^~~~
Please submit a full bug report,
with preprocessed source if appropriate.

The full commandline is as follows:

g++ -DHAVE_CONFIG_H -I.  -I. -I. -pthread   -I/usr/include/luajit-2.0 
-I/usr/include/editline-I./ext/yahttp  -march=x86-64 -mtune=generic -O2
-pipe -fno-plt -DNETSNMP_ENABLE_IPV6 -fno-strict-aliasing -DNETSNMP_REMOVE_U64
-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -Ulinux -Dlinux=linux
-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe
-fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -I/usr/lib/perl5/5.30/core_perl/CORE
-I/usr/include/libnl3 -D_FORTIFY_SOURCE=2 -I. -I/usr/include 
-DSYSCONFDIR=\"/usr/local/etc\"   -fPIE -DPIE -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=2 --param ssp-buffer-size=4 -fstack-protector -g -O3 -Wall
-Wextra -Wshadow -Wno-unused-parameter -Wmissing-declarations -Wredundant-decls
-fanalyzer -MT dnsdist-lua-bindings.o -MD -MP -MF $depbase.Tpo -c -o
dnsdist-lua-bindings.o dnsdist-lua-bindings.cc

This is a ArchLinux system, where 'g++ -v' shows this:

Using built-in specs.
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.1.0 (GCC) 

The triggering line is in the LuaWrapper[2], a project that can wrap C++
objects and to Lua. I have attached the pre-processed source.

If you need more information, let me know!

1 - https://dnsdist.org
2 -
https://github.com/PowerDNS/pdns/blob/134755f54093a595610e035d01a07f125df3ab13/ext/luawrapper/include/LuaContext.hpp#L1241

[Bug target/94504] On powerpc, -ffunction-sections -fdata-sections is not as effective as expected for non-PIE executables.

[gcc-bugzilla at mkarcher dot dialup.fu-berlin.de]

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

--- Comment #5 from Michael Karcher  ---
I got the command line of gcc wrong. "-pie" just sets the linker flags for PIE
linking, but it does *not* compile source code as PIE. If I use "-fpie",
garbage collection does what it is supposed to do.

As I found out, the acutal problem I have is completely unrelated to gcc (sorry
for the noise here), because it concerns object files created by rustc (which
has an llvm backend) linked by binutil's ld tool. At the moment I was able to
reproduce the same symptom I have with those rust objects with a ten-line C
program, I considered fixing the problem (if possible) for C first a good idea.

As it stands now, the issue in gcc (no effective garbage collection for non-PIE
executables with function pointers in global data structures) still stands, so
I am not closing the bug right away.

[Bug target/94504] On powerpc, -ffunction-sections -fdata-sections is not as effective as expected for PIE executables.

[gcc-bugzilla at mkarcher dot dialup.fu-berlin.de]

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

--- Comment #3 from Michael Karcher  ---
(In reply to Richard Biener from comment #2)
> Huh, looking at the assembly & the object file this seems to be fully a linker
> issue who seems to be responsible for building the GOT.  I suggest to move
> this over to sourceware.  Alan?

I'm not so sure about this. I think it might actually be a limitation of ELF on
ppc32:

If I compare the code generated by gcc on ppc32, gcc does output a GOT fragment
in the .got2 section that references all globals that are used in the current
object:

$ objdump -r -j .got2 bla32.o

bla32.o: file format elf32-powerpc

RELOCATION RECORDS FOR [.got2]:
OFFSET   TYPE  VALUE
 R_PPC_ADDR32  fptr
0004 R_PPC_ADDR32  x

This section can not be elided, because it is referenced from main:

$ objdump -r -j .text.main bla32.o

bla32.o: file format elf32-powerpc

RELOCATION RECORDS FOR [.text.main]:
OFFSET   TYPE  VALUE
0022 R_PPC_REL16_HA.got2+0x8006
0026 R_PPC_REL16_LO.got2+0x800a

The linker has no obvious way to detect which GOT slots are actually used
inside main, because the offset(s) of the slot(s) inside .got2 used by main are
hardcoded inside main.

On the other hand, on ppc64, there is no GOT fragment generated by the
compiler, but instead the compiler just asks the linker to create a GOT slot
and fill in the necessary information:

$ objdump -r -j .text.main bla64.o

bla64.o: file format elf64-powerpc

RELOCATION RECORDS FOR [.text.main]:
OFFSET   TYPE  VALUE
000e R_PPC64_TOC16_HA  x
0012 R_PPC64_TOC16_LO  x

[Bug target/94504] New: On powerpc, -ffunction-sections -fdata-sections is not as effective as expected for PIE executables.

[gcc-bugzilla at mkarcher dot dialup.fu-berlin.de]

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

Bug ID: 94504
   Summary: On powerpc, -ffunction-sections -fdata-sections is not
as effective as expected for PIE executables.
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at mkarcher dot dialup.fu-berlin.de
  Target Milestone: ---

I try to compile the following test program using

gcc -ffunction-sections -fdata-sections -pie -Wl,--gc-sections input.c

The linking step fails, because g is not defined. On most architectures except
powerpc (32 bit), the garbage collection is able to discard both fptr and f,
and so the reference to g vanishes. This is not the case on powerpc, where f is
referencing fptr through a GOT entry in the .got2 section.

This issue (I don't dare to call it "bug" yet) is the cause of of
https://bugs.debian.org/955845. The librsvg build process is quirky and
building the tests only works if garbage collection is able to collect a hughe
amount of dead code. Garbage collection is able to do that on all architectures
Debian tried it on except for powerpc (and possibly ppc64, see
https://bugs.debian.org/895723). The attached example program does compile fine
on ppc64, though.

/* dead code */
extern void g(int x, ...);
extern void (*fptr)();
void f()
{
/* using fptr creates a GOT entry for fptr */
g(0, fptr);
}
/* fptr is reference from the GOT. Let's reference f from fptr */
void (*fptr)() = f;

/* Non-dead code */
int x = 5;
int main(void)
{
/* using x goes through the GOT. This prevents the GC to kill it */
return x;
}

[Bug libstdc++/94409] std::regexp (std::collate?) with GCC 7.3.1 on AIX, Japanese

[gcc-bugzilla at vlasiu dot net]

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

--- Comment #4 from gcc-bugzilla at vlasiu dot net ---
That's really bad news for us. Well, we'll wait for a patch and maybe we are
going to backport-it. If it's going to be too complicated we are probably going
to switch to one of the supported versions (we kind of need to be in sync with
RHEL SCL version of GCC).
Thank you.

[Bug libstdc++/94409] std::regexp (std::collate?) with GCC 7.3.1 on AIX, Japanese

[gcc-bugzilla at vlasiu dot net]

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

--- Comment #2 from gcc-bugzilla at vlasiu dot net ---
(In reply to Jonathan Wakely from comment #1)
> N.B. GCC 7 is no longer supported and will not be fixed (but the bug is also
> present in supported releases).

We are going to switch soon to GCC 8.3.1 or 9.1.1. It would be nice to have a
patch for any of those versions. Thank you.

[Bug c++/94409] New: std::regexp (std::collate?) with GCC 7.3.1 on AIX, Japanese

[gcc-bugzilla at vlasiu dot net]

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

Bug ID: 94409
   Summary: std::regexp (std::collate?) with GCC 7.3.1 on AIX,
Japanese
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at vlasiu dot net
  Target Milestone: ---

std::regexp constructor fail on AIX (Japanese). Works fine for English,
Spanish, Italian, French and German languages.

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/freeware/libexec/gcc/powerpc-ibm-aix7.1.0.0/7.3.1/lto-wrapper
Target: powerpc-ibm-aix7.1.0.0
Configured with: ../gcc-7.3.1-20180303/configure --with-as=/usr/bin/as
--with-ld=/usr/bin/ld --enable-languages=c,c++,fortran --prefix=/opt/freeware
--mandir=/opt/freeware/man --infodir=/opt/freeware/info
--enable-version-specific-runtime-libs
--disable-nls --enable-decimal-float=dpd --enable-bootstrap
--build=powerpc-ibm-aix7.1.0.0
Thread model: aix
gcc version 7.3.1 20180303 (GCC) 

The code:

#include 
#include 
#include 

using namespace std;

int main()
{
   char* pLocale = setlocale(LC_ALL, NULL);
   std::cout << "setlocale(): " << pLocale << std::endl;

   const std::regex r1("^(\\s+)?(.*?)(\\s+)?=(\\s+)?(.*?)(\\s+)?");
   std::cout << "std::regex r1: OK" << std::endl;

   setlocale(LC_ALL, "Ja_JP");
   pLocale = setlocale(LC_ALL, NULL);
   std::cout << "setlocale(): " << pLocale << std::endl;

   const std::regex r2("asdf");
   std::cout << "std::regex r2: OK" << std::endl;

   // const std::regex r3("^(\\s+)?(.*?)(\\s+)?=(\\s+)?(.*?)(\\s+)?");
   const std::regex r3("\\s+");
   std::cout << "std::regex r3: OK" << std::endl;

   return 0;
}

The output:

$ ./a.out 
setlocale(): C C C C C C
std::regex r1: OK
setlocale(): Ja_JP Ja_JP Ja_JP Ja_JP Ja_JP Ja_JP
std::regex r2: OK
terminate called after throwing an instance of 'std::length_error'
  what():  basic_string::append
IOT/Abort trap (core dumped)
$

$ gdb -c ./core ./a.out
...
(gdb) backtrace
#0  0x0957ff14 in pthread_kill () from
/usr/lib/libpthreads.a(shr_xpg5_64.o)
#1  0x0957f768 in _p_raise () from
/usr/lib/libpthreads.a(shr_xpg5_64.o)
#2  0x0903956c in raise () from /usr/lib/threads/libc.a(shr_64.o)
#3  0x09055f68 in abort () from /usr/lib/threads/libc.a(shr_64.o)
#4  0x090001c91740 in __gnu_cxx::__verbose_terminate_handler() () from
/usr/lpp/pd/lib64/libstdc++.a(libstdc++.so.6)
#5  0x090001ca0a4c in __cxxabiv1::__terminate(void (*)()) () from
/usr/lpp/pd/lib64/libstdc++.a(libstdc++.so.6)
#6  0x090001c91530 in std::terminate() () from
/usr/lpp/pd/lib64/libstdc++.a(libstdc++.so.6)
#7  0x090001c9fc90 in __cxa_rethrow () from
/usr/lpp/pd/lib64/libstdc++.a(libstdc++.so.6)
#8  0x090001cdbc50 in std::__cxx11::collate::do_transform () from
/usr/lpp/pd/lib64/libstdc++.a(libstdc++.so.6)
#9  0x090001cfea54 in std::__cxx11::collate::transform () from
/usr/lpp/pd/lib64/libstdc++.a(libstdc++.so.6)
#10 0x00010002dba0 in std::__cxx11::basic_string, std::allocator >
std::__cxx11::regex_traits::transform(char*, char*) const ()
#11 0x00010002c6c0 in std::__cxx11::basic_string, std::allocator >
std::__cxx11::regex_traits::transform_primary(char const*,
char const*) const ()
#12 0x00010002ae60 in
std::__detail::_BracketMatcher, false,
false>::_M_apply(char, std::integral_constant)
const::{lambda()#1}::operator()() const ()
#13 0x00010002ab2c in
std::__detail::_BracketMatcher, false,
false>::_M_apply(char, std::integral_constant) const ()
#14 0x00010002a6f8 in
std::__detail::_BracketMatcher, false,
false>::_M_make_cache(std::integral_constant) ()
#15 0x000100026294 in
std::__detail::_BracketMatcher, false,
false>::_M_ready() ()
#16 0x000100022600 in void
std::__detail::_Compiler
>::_M_insert_character_class_matcher() ()
#17 0x000100013208 in
std::__detail::_Compiler >::_M_atom() ()
#18 0x0001000101d8 in
std::__detail::_Compiler >::_M_term() ()
#19 0x000100010028 in
std::__detail::_Compiler >::_M_alternative()
()
#20 0x0001fe48 in
std::__detail::_Compiler >::_M_disjunction()
()#21 0x00012460 in
std::__detail::_Compiler >::_Compiler(char
const*, char const*, std::locale
const&, std::regex_constants::syntax_option_type) ()
#22 0x0001206c in
std::enable_if::value,
std::shared_ptr > const>
>::type std::__detail::__compile_nfa >(char const*, char const*,
std::__cxx11::regex_traits::locale_type const&,
std::regex_constants::syntax_option_type) ()
#23 0x00011e70 in std::__cxx11::basic_regex >::basic_regex(char const*, char
const*, std::locale, std::regex_constants::syntax_option

[Bug libstdc++/92143] std::pmr::polymorphic_allocator throws bad_alloc on macOS

[gcc-bugzilla at daryl dot haresign.com]

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

--- Comment #8 from Daryl Haresign  ---
(In reply to Jonathan Wakely from comment #5)
> C11 6.2.8 says "Valid alignments
> include only those values returned by an _Alignof expression for fundamental
> types, plus an additional implementation-defined set of values, which may be
> empty. Every valid alignment shall be a nonnegative integral power of two."
> 
> _Alignof(char) and _Alignof(short) and _Alignof(int) are valid alignments
> supported by the implementation, and so aligned_alloc is wrong to reject
> them.

Read together I agree it does sound that way.

(In reply to Jonathan Wakely from comment #7)
> Fixed on trunk so far, but I'll backport it too.

Great, thanks!

[Bug libstdc++/92143] std::pmr::polymorphic_allocator throws bad_alloc on macOS

[gcc-bugzilla at daryl dot haresign.com]

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

--- Comment #4 from Daryl Haresign  ---
As for conformance, the latest C draft says:

The aligned_alloc function allocates space for an object whose alignment is
specified by alignment, whose size is specified by size, and whose value is
indeterminate. If the value of alignment is not a valid alignment supported by
the implementation the function shall fail by returning a null pointer.

C11 said:

The aligned_alloc function allocates space for an object whose alignment is
specified by alignment, whose size is specified by size, and whose value is
indeterminate. The value of alignment shall be a valid alignment supported by
the implementation and the value of size shall be an integral multiple of
alignment.

So it seems macOS and AIX's implementations are technically conformant. 
Perhaps GCC should determine whether the platform supports alignments less than
sizeof(void*) when GCC is built, and put a new macro in c++config.h (assuming
that's how that file is constructed)?

[Bug libstdc++/92143] std::pmr::polymorphic_allocator throws bad_alloc on macOS

[gcc-bugzilla at daryl dot haresign.com]

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

--- Comment #3 from Daryl Haresign  ---
$ g++-9 -E -dM test.cc | grep ALIGNED
#define _GLIBCXX_HAVE_ALIGNED_ALLOC 1

[Bug c++/92143] New: std::pmr::polymorphic_allocator throws bad_alloc on macOS

[gcc-bugzilla at daryl dot haresign.com]

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

Bug ID: 92143
   Summary: std::pmr::polymorphic_allocator throws bad_alloc
on macOS
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at daryl dot haresign.com
  Target Milestone: ---

The following code throws a std::bad_alloc on macOS (seen via GCC 9.2 installed
with Homebrew, on macOS Catalina 10.15):

  #include 
  #include 
  int main()
  {
std::pmr::string s { "0123456789abcdef" };
  }

16 characters is required to get it to overflow SSO.

The same issue can be seen with the following code:

  #include 
  int main()
  {
std::pmr::polymorphic_allocator alloc {
  std::pmr::new_delete_resource()
};
alloc.allocate(1);
  }

Changing the type from char to short, and char to int, yields the same error. 
Once you get to long, it starts working.

Presumably power-of-two alignments less than sizeof(void *) are not supported
(that's certainly what posix_memalign says).

Looking through the wording, it's all down to a question of whether
[mem.res.private] p2 allows for your memory resources to force the alignment to
be at least alignof(void *).  I would say the answer is probably yes.

http://eel.is/c++draft/mem.res#private-2

[Bug lto/91988] Inlining fails with LTO enabled

[gcc-bugzilla at tobias dot goedderz.info]

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

--- Comment #1 from Tobias Gödderz  
---
Happens with GCC 9.1.0 as well.

[Bug lto/91988] New: Inlining fails with LTO enabled

[gcc-bugzilla at tobias dot goedderz.info]

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

Bug ID: 91988
   Summary: Inlining fails with LTO enabled
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at tobias dot goedderz.info
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Inlining fails with LTO when there is an argument with a destructor. This seems
unintentional to me, given the following behaviour.

Given the following example files:

==> main.cpp <==
#include "lib.h"

int main() {
  return fun(A{});
}

==> lib.h <==
#ifndef LIB_H
#define LIB_H

class A { public: ~A() {} };

__attribute__((always_inline))
int fun(A);

#endif // LIB_H

==> lib.cpp <==
#include "lib.h"

__attribute__((always_inline))
int fun(A a) { return 0; }


and compiling with

/usr/bin/g++-8 -g -Wall -pedantic -O3 -std=c++14 -flto -c lib.cpp
/usr/bin/g++-8 -g -Wall -pedantic -O3 -std=c++14 -flto -c main.cpp
/usr/bin/g++-8 -g -Wall -pedantic -O3 -std=c++14 -flto -o main-gcc main.o lib.o

fails with
  error: inlining failed in call to always_inline ‘fun(A)’: mismatched
arguments
in the last step.

Removing "__attribute__((always_inline))" and inspecting the deassembled output
confirms that the function isn't inlined.

If the body is moved to the header file (and the "inline" specifier added), the
function is inlined.

If the destructor of "A" is removed, or changed to "~A() = default", the
function is inlined.

If the argument to "fun" is changed to a "const&", the function is inlined.

[Bug c++/91387] New: Segfault using -flto

[gcc-bugzilla at tobias dot goedderz.info]

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

Bug ID: 91387
   Summary: Segfault using -flto
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at tobias dot goedderz.info
  Target Milestone: ---

Created attachment 46684
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46684=edit
Preprocessed source code

Hi,

I'm experiencing g++ segfaults during compilation. This is a "minimal" example
in terms of command line parameters, using the preprocessed source (which is
not minimal):

> $ /usr/bin/g++-8 -std=c++14 -O2 -flto -fno-devirtualize -c 
> ShapeContainerTest.ii
> during IPA pass: cp
> /home/tobias/Documents/ArangoDB/arangodb/arangodb/tests/Geo/ShapeContainerTest.cpp:
>  In function ‘arangodb::velocypack::Builder::openCompoundValue(unsigned char) 
> [clone .part.119]’:
> /home/tobias/Documents/ArangoDB/arangodb/arangodb/tests/Geo/ShapeContainerTest.cpp:427:2:
>  internal compiler error: Segmentation fault
>  }}
>   ^
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.

This is with g++ (Ubuntu 8.3.0-6ubuntu1~18.04.1) 8.3.0.

I have two other files exhibiting a similar error, if it's of interest. The one
referenced above is attached.

Please tell me if and how I can be of further help.

Best regards,

Tobias

[Bug other/89635] More ANSI SGR codes in diagnostics?

[gcc-bugzilla at lucaswerkmeister dot de]

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

Lucas Werkmeister  changed:

   What|Removed |Added

 CC||gcc-bugzilla@lucaswerkmeist
   ||er.de

--- Comment #1 from Lucas Werkmeister  
---
Note that not all terminals support underlining – systemd had some issues with
this, compare https://github.com/systemd/systemd/pull/6778 and linked issues.

[Bug target/88592] New: Passing of packed structures on sparc64 different than in clang

[gcc-bugzilla at mkarcher dot dialup.fu-berlin.de]

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

Bug ID: 88592
   Summary: Passing of packed structures on sparc64 different than
in clang
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at mkarcher dot dialup.fu-berlin.de
  Target Milestone: ---

As noted while filing a bug on rustc because rustc does not correctly implement
the Sparc64 ABI regarding floating point fields of "small" structures, I
stumbled across a difference between gcc an clang, as shown in
https://github.com/rust-lang/rust/issues/57103 (the important piece is quoted
below):

struct str3 {
  float f;  // passed in most-significant half of %o0 (gcc) or in %f0 (clang)
  int i;// passed in least-significant half of %o0
} __attribute__((packed));

Without __attribute__((packed)), clang, gcc and the ABI standard agree to pass
f in %f0. The ABI standard doesn't contain anything about packed structures, so
I don't see a way to decide whether gcc or clang is right. I report a bug on
both products to raise awareness.

[Bug c/85696] OpenMP with variably modified and default(none) won't compile

[gcc-bugzilla at zulan dot net]

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

--- Comment #2 from gcc-bugzilla at zulan dot net ---
Created attachment 44087
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44087=edit
minimal example

[Bug c/85696] OpenMP with variably modified and default(none) won't compile

[gcc-bugzilla at zulan dot net]

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

gcc-bugzilla at zulan dot net changed:

   What|Removed |Added

  Attachment #44085|0   |1
is obsolete||

--- Comment #1 from gcc-bugzilla at zulan dot net ---
Created attachment 44086
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44086=edit
pologies, wrong gcc version. The error of 8.1.0 is exactly the same though.

[Bug c/85696] New: OpenMP with variably modified and default(none) won't compile

[gcc-bugzilla at zulan dot net]

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

Bug ID: 85696
   Summary: OpenMP with variably modified and default(none) won't
compile
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at zulan dot net
  Target Milestone: ---

Created attachment 44085
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44085=edit
gcc -v (Archlinux)

The following trivial code

void foo(int n, int a[][n])
{
#pragma omp parallel shared(a) default(none)
a[23][0] = 42;
}

fails to compile:

$ gcc -c -fopenmp minimal.c 
minimal.c: In function ‘foo’:
minimal.c:3:6: error: ‘n.0’ not specified in enclosing ‘parallel’
 a[23][0] = 42;
  ^
minimal.c:2:9: error: enclosing ‘parallel’
 #pragma omp parallel shared(a) default(none)
 ^~~

It appears that there is an internal copy n.0 of n to compute the index to any
further access to a. This internal copy is not handled properly in the
default(none) parallel region.

Interestingly in the 004t.gimple pass, it is actually listed as shared(n.0):

#pragma omp parallel default(none) shared(a) shared(n.0)


The bug exists at least since 4.8 and was first reported at
https://stackoverflow.com/q/47081274/620382

[Bug c++/84222] [[deprecated]] class complains about internal class usage

[gcc-bugzilla at daryl dot haresign.com]

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

--- Comment #2 from Daryl Haresign  ---
See also bug 79817.

[Bug c++/84222] [[deprecated]] class complains about internal class usage

[gcc-bugzilla at daryl dot haresign.com]

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

--- Comment #1 from Daryl Haresign  ---
Additionally, any external use of a static method of a deprecated class should
probably (but does not currently) emit a warning (Clang emits a warning).

class [[deprecated]] C {
  public:
void fn() {}
};

int main()
{
C::fn();  // does not emit a deprecation warning
}

[Bug c++/84222] New: [[deprecated]] class complains about internal class usage

[gcc-bugzilla at daryl dot haresign.com]

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

Bug ID: 84222
   Summary: [[deprecated]] class complains about internal class
usage
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at daryl dot haresign.com
  Target Milestone: ---

If I mark a class with the [[deprecated]] annotation, it complains when the
class uses its own name in the implementation:

class [[deprecated]] C {
  public:
C() {}
C(const C&) = default;  // emits a deprecation warning
C(C&&) = delete;// also emits a warning
};

[Bug preprocessor/80005] New: cpp expands __has_include() filename parts

[tim+gcc-bugzilla at centricular dot com]

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

Bug ID: 80005
   Summary: cpp expands __has_include() filename parts
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tim+gcc-bugzilla at centricular dot com
  Target Milestone: ---

gcc (Debian 6.3.0-4) 6.3.0 20170121
cpp (Debian 6.3.0-4) 6.3.0 20170121
Also happens with latest gcc7 snapshot on https://gcc.godbolt.org/

Linux 4.9.0-1-amd64 #1 SMP Debian 4.9.2-2 (2017-01-12) x86_64 GNU/Linux

I believe this is a gcc preprocessor bug. It works fine with clang fwiw.


1) Precondition:

/usr/include/linux/memfd.h exists (it does).


2) Source code to reproduce:


#ifdef __has_include
 #if !__has_include()
  #error "Header 'linux/memfd.h' could not be found"
 #endif
#endif



3) Steps to reproduce:

$ cpp inctest.c out
inctest.c:3:12: error: #error "Header 'linux/memfd.h' could not be found"

$ strace -f cpp inctest.c out 2>&1 | grep memfd.h | grep /usr/include
[pid  8935] open("/usr/include/1/memfd.h", O_RDONLY|O_NOCTTY) = -1 ENOENT

Note that linux/memfd.h was expanded to 1/memfd.h here.

Presumably #define linux 1 is one of the compiler/preprocessor predefines?

I believe it should not expand filenames (clang doesn't, fwiw).

Adding a #undef linux "fixes" the issue.

[Bug libstdc++/79254] [5/6/7 Regression] basic_string::operator= isn't exception safe

[gcc-bugzilla at daryl dot haresign.com]

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

--- Comment #7 from Daryl Haresign  ---
I would also be inclined to reverse your Guard: have it take 'this', have an
'activate' method which swaps in the new values, have a 'deactivate' method
which releases the memory, and have its destructor swap back the old values. 
Something like this (formatting and naming aside):

void
_M_copy_assign(const basic_string& __str, true_type)
{
  struct _Guard {
_Guard(basic_string *__s)
: _M_self(__s)
, _M_alloc(_M_self->_M_get_allocator())
{
}

~_Guard() {
  if (_M_ptr)
{
  _M_self->_M_data(_m_ptr);
  _M_self->_M_set_length(_M_size)
  _M_self->_M_get_allocator() = _M_alloc;
}
}

void _M_activate() {
_M_ptr = _M_self->_M_data();
_M_size = _M_self->_M_allocated_capacity;
_M_self->_M_data(_M_local_data());
_M_self->_M_set_length(0);
}

void _M_deactivate() {
  if (_M_ptr)
{
  _Alloc_traits::deallocate(_M_alloc, _M_ptr, _M_size + 1);
  _M_ptr = nullptr;
}
}

basic_string *_M_self;
allocator_type _M_alloc;
pointer _M_ptr = nullptr;
size_type _M_size = 0;
  };
  _Guard __guard(this);
  if (!_Alloc_traits::_S_always_equal() && !_M_is_local()
  && _M_get_allocator() != __str._M_get_allocator())
{
  // Replacement allocator cannot free existing storage.
  __guard._M_activate();
}
  _M_get_allocator() = __str._M_get_allocator();
  this->_M_assign(__str);
  __guard._M_deactivate();
}

[Bug libstdc++/79254] [5/6/7 Regression] basic_string::operator= isn't exception safe

[gcc-bugzilla at daryl dot haresign.com]

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

--- Comment #6 from Daryl Haresign  ---
I guess you don't want _M_copy_assign to be public, either.

[Bug libstdc++/79254] New: basic_string::operator= isn't exception safe

[gcc-bugzilla at daryl dot haresign.com]

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

Bug ID: 79254
   Summary: basic_string::operator= isn't exception safe
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at daryl dot haresign.com
  Target Milestone: ---

Assigning one string to another, where they have non-equal
propagate-on-copy-assignment allocators, does a `_M_destroy()`, followed by an
`assign()`.  The `assign()` may throw, which leaves the string in a cleared
state.

This seems to violate the requirement specified here:
  http://eel.is/c++draft/basic.string#string.require-2

A contrived example to show this:
  http://coliru.stacked-crooked.com/a/1891a2678a9589d3

[Bug go/79037] gccgo: Binaries crash with parforsetup: pos is not aligned on m68k

[gcc-bugzilla at mkarcher dot dialup.fu-berlin.de]

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

--- Comment #10 from Michael Karcher  ---
OK, I got it. I retract my last comment.

[Bug go/79037] gccgo: Binaries crash with parforsetup: pos is not aligned on m68k

[gcc-bugzilla at mkarcher dot dialup.fu-berlin.de]

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

--- Comment #8 from Michael Karcher  ---
The patch looks like it should work fine, I guess John Paul Adrian Glaubitz is
going to test it soon. But I wonder whether the determination of alignment is
in types.cc really needed, as user-specified alignment directives can only make
alignment stricter. So always passing 4 to implicit variable should do no harm
and keep the code simpler.

[Bug go/79037] gccgo: Binaries crash with parforsetup: pos is not aligned on m68k

[gcc-bugzilla at mkarcher dot dialup.fu-berlin.de]

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

--- Comment #5 from Michael Karcher  ---
The root issue now is that the ABI gcc implements on m68k is incompatible with
the Go runtime shipped with gcc.

The Go runtime uses the lowest two bits in the type information pointer as
flags (called PRECISE and LOOP) and relies on the fact that the actual type
information structure is aligned to a 32-bit boundary. The type descriptors are
Go literals created by the Go frontend as standard Go structures.

In the gcc backend for Go, the layout and alignment rules of Go structures
match the rules for C structures (which is most likely necessary for
interoperability). On m68k this means we get 16-bit alignment for historical
reasons. The current interface between the go frontend and its backend has no
interface to request stricter alignment, so the Go frontend is unable to ensure
that type descriptors are aligned to 32-bit boundaries.

A possible way of solving this would be to extend
Backend::struct_type(vector<...> fields) by an (optional?) second parameter to
communicate alignment requests, such that Gcc_backend::struct_type can use
DECL_ALIGN before calling fill_in_struct. This enables the Go frontend to
request the required alignment for its type descriptors. Requesting increased
alignment for Go type descriptors is impossible to break legacy ABIs on m68k as
there is no ABI involving Go type descriptors yet.

This change should possibly go align with adding "__attribute__((aligned(4)))"
to several types in libgo/runtime/go-type.h if type descriptors are ever
created from the C side of things.

Proof for the issue:

(sid-m68)root:~# nm --dynamic /usr/lib/m68k-linux-gnu/libgo.so.9 | grep __go_td
 | head -n 6
00bcc410 V __go_td_AAAN5_uint8ee1e
00bcc440 V __go_td_AAAN5_uint8ee1e$gc
00bd0058 V __go_td_AAAN5_uint8eee
00bd0080 V __go_td_AAAN5_uint8eee$gc
00bfc4e6 V __go_td_AAAN6_uint329e3e16e
00bfc5d2 V __go_td_AAAN6_uint329e3e16e$gc

shows unaligned type descriptors.

[Bug c++/78966] Unjustified variadic template instantiation

[gcc-bugzilla at contacts dot eelis.net]

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

Eelis  changed:

   What|Removed |Added

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

--- Comment #6 from Eelis  ---
Ah, thanks for the explanation! That makes sense.

I guess that to avoid this problem, one should adhere to a rule along the lines
of:

"If you're about to write a function like

  template
  R f(X);

then if f is potentially overloaded, and X cannot be instantiated with an empty
pack, you better write f as:

  template
  R f(X)

because otherwise calls to those other fs may end up requiring X to be
instantiable with an empty pack."

I now use this workaround for my operator<< for std::variant.

Closing.

[Bug c++/78966] Unjustified variadic template instantiation

[gcc-bugzilla at contacts dot eelis.net]

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

--- Comment #2 from Eelis  ---
The testcase was a minimized version of the (imho innocuous looking):

  #include 
  #include 

  template
  std::ostream & operator<<(std::ostream &, std::variant const &);

  int main() { std::cout << std::endl; }

This gives:

  error: invalid use of incomplete type ‘struct std::variant_alternative<0,
std::variant<> >’

I'd be curious to know the rule that makes this ill-formed. Anybody happen to
know it, or the number of the DR (if there is one)?

In any case, feel free to close the ticket if GCC is really correct here. In
that case, sorry for the noise. :)

[Bug c++/78966] New: Unjustified variadic template instantiation

[gcc-bugzilla at contacts dot eelis.net]

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

Bug ID: 78966
   Summary: Unjustified variadic template instantiation
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at contacts dot eelis.net
  Target Milestone: ---

Consider:

  template
  struct vari
  {
static_assert(sizeof...(TT) != 0, "bleh");
  };

  template struct X {};

  void f(void(*)(X));

  template void f(vari);
// if this line is commented out, code compiles fine

  template void g(X);

  void h() { f(g); }

When compiled with gcc 7.0.0 20161219, the static assert triggers:

  prog.cc: In instantiation of 'struct vari<>':
  prog.cc:16:15:   required from here
  prog.cc:4:3: error: static assertion failed: bleh
 static_assert(sizeof...(TT) != 0, "bleh");

But there's no reason for vari to be instantiated without arguments here, is
there?

[Bug c++/78511] New: ICE on using concept name as a "requires" parameter

[gcc-bugzilla at minijackson dot 33mail.com]

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

Bug ID: 78511
   Summary: ICE on using concept name as a "requires" parameter
   Product: gcc
   Version: c++-concepts
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at minijackson dot 33mail.com
  Target Milestone: ---

GCC version and system:

gcc (Gentoo 6.2.0-r1 p1.1) 6.2.0


Compilation options:

-altivec -awt -cilk cxx -debug -doc -fixed-point fortran gcj -go -graphite
-hardened -jit -libssp -mpx multilib nls nptl -objc -objc++ -objc-gc openmp pch
-pie -regression-test sanitize -ssp -vanilla vtv


Example program (test.cpp):

template 
concept bool A = true;

template 
concept bool B = requires(A a) {
a;
}


Command line:

g++ -fconcepts -std=c++1z test.cpp


Error:

test.cpp:5:27: internal compiler error: in synthesize_implicit_template_parm,
at cp/parser.c:37866
 concept bool B = requires(A a) {
   ^


test.ii generated file:

# 1 "test.cpp"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "test.cpp"
template 
concept bool A = true;

template 
concept bool B = requires(A a) {
 a;
}

[Bug c++/42490] using-directive in namespace doesn't work properly

[gcc-bugzilla at contacts dot eelis.net]

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

Eelis  changed:

   What|Removed |Added

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

--- Comment #4 from Eelis  ---
Seems to be fixed, thanks!

[Bug c++/10619] Error message for no matching function calls does not list explicitly-specified template arguments

[gcc-bugzilla at contacts dot eelis.net]

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

Eelis  changed:

   What|Removed |Added

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

--- Comment #6 from Eelis  ---
GCC now emits additional diagnostics explaining why the candidate f could not
be used, which is exactly what I wanted. Thanks!

[Bug libstdc++/77994] New: std::sample uses incorrect integer types internally

[gcc-bugzilla at contacts dot eelis.net]

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

Bug ID: 77994
   Summary: std::sample uses incorrect integer types internally
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at contacts dot eelis.net
  Target Milestone: ---

Both the reservoir sampling and the selection sampling implementations use a
uniform_int_distribution<_Size> to generate integers distributed over the
population size, but _Size is merely the type of the user-supplied argument
specifying the desired selection size, and that type may not be large enough to
represent integers distributed over the population size.

The selection sampling implementation also uses _Size for __unsampled_sz, which
is incorrect for the same reason.

[Bug c++/33952] -Wfatal-errors truncates multi-line error messages.

[gcc-bugzilla at contacts dot eelis.net]

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

--- Comment #5 from Eelis  ---
(In reply to David Malcolm from comment #4)
> Eelis: FWIW, gcc has a -fmax-errors=n option; I wonder if setting that to 1
> might be a better fit for geordi?  (just thinking aloud here).

It also truncates the error in the testcase.

[Bug c/77436] Incorrect constant result for summing loop inserted

[gcc-bugzilla at lucaswerkmeister dot de]

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

--- Comment #3 from Lucas Werkmeister  
---
Sorry, I wasn’t aware that wrapping is defined but overflow isn’t. The bug also
happens if the summand type is changed to long (or, precisely, int64_t), where
overflow shouldn’t happen (we’re adding at most 2^31 integers with the same
sign, each of which doesn’t exceed 2^31 in magnitude, so 2^63 should be enough
for the sum).

[Bug c/77436] New: Incorrect constant result for summing loop inserted

[gcc-bugzilla at lucaswerkmeister dot de]

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

Bug ID: 77436
   Summary: Incorrect constant result for summing loop inserted
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at lucaswerkmeister dot de
  Target Milestone: ---

Created attachment 39529
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39529=edit
Preprocessed version of a small C program that sums up all integers from
-(INT_MAX-1) to INT_MAX-1 (including both limits).

The attached program computes the sum of all integers from -(INT_MAX-1) and
INT_MAX-1. Since the lower limit is the additive inverse of the upper limit,
all summands must cancel each other out and the result must be zero (this is
still true with overflow). When compiled with -O0, that result is indeed
printed. With -O1 and -O2, gcc optimizes the constant calculation and fills in
the printf() call with the known result (though the loop is only removed on
-O2); however, the inserted result is incorrect: instead of 0x, it is
0x8000 – the highest bit has been flipped.

The bug appears to depend on the width of the summation window. Starting at
INT_MIN + 32768 + 8192 + 4096 + 1024 + 256 + 2 and summing up to INT_MAX - 1
still exhibits the same bug; starting one later (+ 1) no longer does.
Subtracting the same constant value from start and end does not change the
result (provided the “shift” doesn’t cause overflow at the start).

Output of gcc -v -save-temps -O1 gcc-bug.c:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc-multilib/src/gcc/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release
Thread model: posix
gcc version 6.1.1 20160802 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/cc1 -E -quiet -v gcc-bug.c
-mtune=generic -march=x86-64 -O1 -fpch-preprocess -o gcc-bug.i
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/cc1 -fpreprocessed gcc-bug.i -quiet
-dumpbase gcc-bug.c -mtune=generic -march=x86-64 -auxbase gcc-bug -O1 -version
-o gcc-bug.s
GNU C11 (GCC) version 6.1.1 20160802 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.1.1 20160802, GMP version 6.1.1, MPFR
version 3.1.4-p1, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (GCC) version 6.1.1 20160802 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.1.1 20160802, GMP version 6.1.1, MPFR
version 3.1.4-p1, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 0344da0e3652e90e95fdb0223debdba9
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-mtune=generic' '-march=x86-64'
 as -v --64 -o gcc-bug.o gcc-bug.s
GNU assembler version 2.27 (x86_64-pc-linux-gnu) using BFD version (GNU
Binutils) 2.27
COMPILER_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/collect2 -plugin
/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/lto-wrapper
-plugin-opt=-fresolution=gcc-bug.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --b

[Bug libstdc++/71945] New: Integer overflow in use counter of shared pointers

[gcc-bugzilla at chwress dot at]

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

Bug ID: 71945
   Summary: Integer overflow in use counter of shared pointers
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at chwress dot at
  Target Milestone: ---

Created attachment 38942
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38942=edit
A small program demonstrating the issue

We (Fabian Yamaguchi, Christian Wressnegger, and Alwin Maier) would like
to report an integer overflow of the use counter in the `share_pointer`
object of the Standard C++ Libraries version 5.4, 6.1 and before.
Exploiting the flaw requires some very specific prerequisites to be met,
a successful attempt however allows an attacker to execute code.
Consequently, this might be worth addressing.

The following conditions must hold true in order to trigger the
overflow:

(1) The target is compiled and runs on an architecture where
sizeof(size_t) is larger than sizeof(int), e.g. 64 bit systems with the
LP64 (Linux/ BSD) or LLP64 (Windows) data model in order to allocate
more UINT_MAX Objects.

(2) The attacker is capable of triggering the creation of a multitude of
shared objects.

(3) The attacker can make one of these shared pointers go out of scope,
e.g., by instructing the system to remove a state object.

The following short program (shared_ptr_overflow.cpp) demonstrates the
bug: First, we create a shared pointer referencing a minimal class
`MyClass`. Second, 0x more references are created which results
in the use counter to flip over to 0 again. Finally, we add one more
reference (use counter is incremented to 1) and make one of the shared
pointers go out of scope. As a result the use counter is decremented to
0 and the contained object is freed, leaving 0x shared pointer
object behind, that still reference that memory region.
Subsequently, an attacker may allocate memory containing arbitrary data
such as executable code to take the place of the freed object and make
all references left behind point to that piece of data.


--- snip (shared_ptr_overflow.cpp) 

//#define HAS_ENOUGH_MEMORY

int main()
{
std::cout << "1) Create an object and pass it over to a shared pointer..."
<< std::endl;
// We initialize the object on the heap and set x to 10.
shared_ptr ptr(new MyClass(10));
std::cout << "   ptr.use_count() -> " << ptr.use_count() << std::endl;
// use-count is 1

const size_t numPtrs = (size_t) 0x;
#ifdef HAS_ENOUGH_MEMORY
std::cout << "2) Create 0x" << std::hex << numPtrs << " more references to
that object..." << std::endl;
std::vector<shared_ptr> v(numPtrs);

for (size_t i = 0; i < numPtrs; i++)
{
v[i] = ptr;
}
std::cout << "   ptr.use_count() -> " << ptr.use_count() << std::endl;
// use-count is 0


std::cout << "3) Create one more reference..." << std::endl;
{
shared_ptr ptr2 = ptr;
std::cout << "   ptr.use_count() -> " << ptr.use_count() << std::endl;
// use-count is 1

std::cout << "4) That last reference goes out of scope again now..." <<
std::endl;
}
#else
{
std::cout << "2) Create an extra reference to that object..." <<
std::endl;
shared_ptr ptr2 = ptr;
std::cout << "   ptr.use_count() -> " << ptr.use_count() << std::endl;
// use-count is 2

std::cout << "3) Emulate 0x" << std::hex << numPtrs << " more
references to that object..." << std::endl;
for(size_t i = 0; i < numPtrs; i++){
memset(, '\0', sizeof(shared_ptr));
ptr = ptr2;
}
std::cout << "   ptr.use_count() -> " << ptr.use_count() << std::endl;
// use-count is 1

std::cout << "4) One reference goes out of scope again now..." <<
std::endl;
}
#endif
std::cout << "   ptr.use_count() -> " << ptr.use_count() << std::endl;
// use-count is 0

std::cout << "5) We now spray the heap with 'A's to overwrite the freed
memory" << std::endl;
for(int i = 0; i < 1000; i++){
char *foo = new char[4];
memset(foo, 'A', 4);
}

// The address stored in ptr is still that of the free'd object
std::cout << "   ptr: " << (void *) ptr.get() << std::endl;

// ptr->x is now 0x41414141
std::cout << "   value: " << std::hex << ptr-&

[Bug c++/71173] [6/7 regression] Qualified name lookup

[gcc-bugzilla at zulan dot net]

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

--- Comment #6 from gcc-bugzilla at zulan dot net ---
As far as I can tell it is fixed. Tested with Archlinux "6.1.1" which seems to
be git/1bbd3999).

[Bug c++/59832] [c++11] ICE in reshape_init_class with initializer list

[gcc-bugzilla at zulan dot net]

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

gcc-bugzilla at zulan dot net changed:

   What|Removed |Added

 CC||gcc-bugzilla at zulan dot net

--- Comment #12 from gcc-bugzilla at zulan dot net ---
This shows the same error (tested with gcc 6.1.1):

#include

template
void foo(T bar) {
constexpr auto baz = std::array<int, 1>{{1}};
}

int main() {
foo(13);
}

[Bug tree-optimization/68008] New: Pessimization of simple non-tail-recursive functions

[gcc-bugzilla at mkarcher dot dialup.fu-berlin.de]

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

Bug ID: 68008
   Summary: Pessimization of simple non-tail-recursive functions
   Product: gcc
   Version: 5.1.1
   URL: http://stackoverflow.com/questions/32974625
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at mkarcher dot dialup.fu-berlin.de
  Target Milestone: ---

Created attachment 36537
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36537=edit
preprocessed source code

As discussed on Stack Overflow in http://stackoverflow.com/questions/32974625
(Misleading title: "Is gcc's asm volatile equivalent to the gfortran default
setting for recursions?"), gcc pessimizes the example fibonacci function, which
can be avoided by "-fno-optimize-sibling-calls" (which is the reason I assigned
the bug to tree-optimization)

The non-optimal code is generated at least by
  gcc 4.5.3 (Debian 4.5.3-12)
  gcc version 4.9.2 (Debian 4.9.2-10)
  gcc version 5.1.1 20150507 (Debian 5.1.1-5)

I will focus on gcc 5.1.1 in the remaining report.

Configured with: ../src/configure -v --with-pkgversion='Debian 5.1.1-5'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=c++98 --disable-libstdcxx-dual-abi
--enable-gnu-unique-object --disable-vtable-verify --enable-libmpx
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu

gcc is invoked as: g++-5 -O3 -march=core2 -std=c++0x
stack-overflow-32974625.cc; ./a.out
compared to g++-5 -O3 -march=core2 -std=c++0x -fno-optimize-sibling-calls
stack-overflow-32974625.cc; ./a.out


There are no error or warning messages printed by the compiler or linker (even
if warning would be enabled by -Wall -Wextra)

The file stack-overflow-32974625.ii is attached.

Timing with g++ 5.1.1 on a Core2Duo T7200 under 64-bit linux (cpu frequency
scaling set to "performance"):
With -fno-optimize-sibling-calls: 34.5us/iteration
Without -fno-optimize-sibling-calls: 68us/iteration

[Bug c++/68003] New: Variable declared in condition in for loop is destroyed too soon

[gcc-bugzilla at contacts dot eelis.net]

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

Bug ID: 68003
   Summary: Variable declared in condition in for loop is
destroyed too soon
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at contacts dot eelis.net
  Target Milestone: ---

Consider:

  #include 
  #include 

  struct X
  {
bool alive = true;
~X() { alive = false; }

explicit operator bool() const { return true; }
  } ;

  int main()
  {
for(int i = 0; X x = X(); assert(x.alive))
  if (++i == 3)
break;
  else
std::cout << i << std::endl;
  }

When compiled with gcc trunk, the program outputs:

  1
  a.out: t.cpp:14: int main(): Assertion `x.alive' failed.

When compiled with clang trunk, the program outputs:

  1
  2

[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs

[gcc-bugzilla at mkarcher dot dialup.fu-berlin.de]

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

Michael Karcher gcc-bugzilla at mkarcher dot dialup.fu-berlin.de changed:

   What|Removed |Added

 CC||gcc-bugzilla at mkarcher dot 
dialu
   ||p.fu-berlin.de

--- Comment #15 from Michael Karcher gcc-bugzilla at mkarcher dot 
dialup.fu-berlin.de ---
Created attachment 36134
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36134action=edit
even further reduced test case

I manually reduced the example even more. Interestingly it doesn't contain any
C++ specific statements any more, yet it only fails -fcompare-debug with -x
c++, but passes with -x c

[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs

[gcc-bugzilla at mkarcher dot dialup.fu-berlin.de]

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

--- Comment #16 from Michael Karcher gcc-bugzilla at mkarcher dot 
dialup.fu-berlin.de ---
The bug seems to be quite similar to the infamous sloth that was dropped on
the head as a baby-bug Linus discovered (https://lkml.org/lkml/2014/7/24/584 ,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61904). -fcompare-debug passes if
-fno-var-tracking-assignments is passed as compiler option.

[Bug rtl-optimization/65371] arm loop with volatile variable

[gcc-bugzilla at enginuities dot com]

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

--- Comment #4 from Stuart gcc-bugzilla at enginuities dot com ---
The assembly generated from Comment #1 looks good.

However, the assembly generated from Comment #3 hasn't improved, it still
contains the unnecessary mov instruction on line 2 (mov r2, r3).

The first instruction movs the address in to r3 and the second movs r3 in to
r2. The instruction at label .L2 loads data in to r3 from the address in r2,
overwriting r3 and making the instruction on line 2 unnecessary...

I would have expected to see:

func:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov r2, #1073741824
ldr r1, [r2]
.L2:
ldr r3, [r2]
subsr3, r3, r1
uxthr3, r3
cmp r3, r0
bcc .L2
bx  lr

[Bug rtl-optimization/65371] arm loop with volatile variable

[gcc-bugzilla at enginuities dot com]

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

--- Comment #2 from Stuart gcc-bugzilla at enginuities dot com ---
I compiled it for x86_64 and thought it was fine, however, after your comment I
tried compiling it with clang/llvm and can see the difference (I'm not
particularly familiar with the full instruction set)...

I've found another case which could also be improved:

func.c:

#include stdint.h

#define PERIPH_BASE0x4000
#define PERIPH ((PERIPH_TypeDef *) PERIPH_BASE)

typedef struct
{
volatile uint32_t REG1;
} PERIPH_TypeDef;

void func(uint16_t a)
{
uint32_t t = PERIPH-REG1;

while ((uint16_t) (PERIPH-REG1 - t)  a) { }
}

gives:

 func:
   0:   f04f 4380   mov.w   r3, #1073741824 ; 0x4000
   4:   461amov r2, r3
   6:   6819ldr r1, [r3, #0]
   8:   6813ldr r3, [r2, #0]
   a:   1a5bsubsr3, r3, r1
   c:   b29buxthr3, r3
   e:   4283cmp r3, r0
  10:   d3fabcc.n   8 func+0x8
  12:   4770bx  lr

For some reason r3 is moved in to r2 and then value at the address in r2 is
loaded in to r3 for the loop!

I would expect the following:

 func:
   0:   f04f 4180   mov.w   r1, #1073741824 ; 0x4000
   4:   680aldr r2, [r1, #0]
   6:   680bldr r3, [r1, #0]
   8:   1a9bsubsr3, r3, r2
   a:   b29buxthr3, r3
   c:   4283cmp r3, r0
   e:   d3fabcc.n   6 func+0x6
  10:   4770bx  lr

[Bug target/65371] New: arm loop with volatile variable

[gcc-bugzilla at enginuities dot com]

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

Bug ID: 65371
   Summary: arm loop with volatile variable
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at enginuities dot com
Target: arm-none-eabi (Cortex-M3)

I've found this behaviour with gcc 4.8.4, 4.9.2, and 5.0.0 (20150308) (all
compiled with the same flags) on Arch Linux (3.18.2-2-ARCH x86_64).

I've also had the same behaviour using the precompiled gcc-arm-embedded
toolchain from Launchpad (gcc-arm-none-eabi-4_9-2014q4).

Compiling func.c:

#define PERIPH_BASE0x4001000
#define PERIPH ((PERIPH_TypeDef *) PERIPH_BASE)

typedef struct
{
volatile unsigned long REG1;
} PERIPH_TypeDef;

void func()
{
PERIPH-REG1 |= 0x0001;
while (!(PERIPH-REG1  0x0002)) { }
PERIPH-REG1 |= 0x0100;
}

With:

arm-none-eabi-gcc -mthumb -mcpu=cortex-m3 -Os -c func.c

Results in the following disassembly of func.o:

 func:
   0:   4b06ldr r3, [pc, #24]   ; (1c func+0x1c)
   2:   681aldr r2, [r3, #0]
   4:   f442 3280   orr.w   r2, r2, #65536  ; 0x1
   8:   601astr r2, [r3, #0]
   a:   6819ldr r1, [r3, #0]
   c:   4a03ldr r2, [pc, #12]   ; (1c func+0x1c)
   e:   0389lslsr1, r1, #14
  10:   d5fbbpl.n   a func+0xa
  12:   6813ldr r3, [r2, #0]
  14:   f043 7380   orr.w   r3, r3, #16777216   ; 0x100
  18:   6013str r3, [r2, #0]
  1a:   4770bx  lr
  1c:   04001000streq   r1, [r0], #-0

The last line in func.c (PERIPH-REG1 |= 0x0100;) causes the compiled code
to load the address of PERIPH-REG1 in to r2 during the loop at func+0x0c
(ldr r2, [pc, #12]) and then use r2 after the loop even though the address
contained in r2 was loaded in to r3 at func+0x00 (ldr r3, [pc, #24]) and
doesn't change.

As such I would expect something like this disassembly of func.o:

 func:
   0:   4b06ldr r3, [pc, #24]   ; (1c func+0x1c)
   2:   681aldr r2, [r3, #0]
   4:   f442 3280   orr.w   r2, r2, #65536  ; 0x1
   8:   601astr r2, [r3, #0]
   a:   681aldr r2, [r3, #0]
   c:   0392lslsr2, r2, #14
   e:   d5fcbpl.n   a func+0xa
  10:   681aldr r2, [r3, #0]
  12:   f042 7280   orr.w   r2, r2, #16777216   ; 0x100
  16:   601astr r2, [r3, #0]
  18:   4770bx  lr
  1a:   bf00nop
  1c:   04001000streq   r1, [r0], #-0

arm-none-eabi-gcc -v:

Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/home/test_user/toolchain/libexec/gcc/arm-none-eabi/5.0.0/lto-wrapper
Target: arm-none-eabi
Configured with: /home/test_user/temp/gcc-5-20150308/gcc-5-20150308/configure
--disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap
--disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls
--disable-shared --disable-threads --disable-tls --enable-languages=c,c++
--prefix=/home/test_user/toolchain --target=arm-none-eabi
--with-gmp=/home/test_user/toolchain --with-gnu-as --with-gnu-ld
--with-mpc=/home/test_user/toolchain --with-mpfr=/home/test_user/toolchain
--with-newlib --without-headers
Thread model: single
gcc version 5.0.0 20150308 (experimental) (GCC)