[Bug libstdc++/96626] New: utf-8 string literal not convertible to std::string with -std=c++20

[rcopley at gmail dot com]

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

Bug ID: 96626
   Summary: utf-8 string literal not convertible to std::string
with -std=c++20
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rcopley at gmail dot com
  Target Milestone: ---

This is accepted with -std=c++17 and rejected with -std=c++20:


#include 
#include 

int main ()
{
  std::string s = u8"Hello, ";
  std::cout << u8"World!";
  return 0;
}


The error output with -std=c++20 is:

g++ -Wall -Wextra -std=c++2a x.cpp
x.cpp: In function 'int main()':
x.cpp:6:19: error: conversion from 'const char8_t [8]' to non-scalar type
'std::string' {aka 'std::__cxx11::basic_string'} requested
6 |   std::string s = u8"Hello, ";
  |   ^~~
x.cpp:7:16: error: use of deleted function 'std::basic_ostream&
std::operator<<(std::basic_ostream&, const char8_t*) [with
_Traits = std::char_traits]'
7 |   std::cout << u8"World!";
  |^~
In file included from c:/msys64/mingw64/include/c++/10.2.0/iostream:39,
 from x.cpp:2:
c:/msys64/mingw64/include/c++/10.2.0/ostream:640:5: note: declared here
  640 | operator<<(basic_ostream&, const char8_t*) = delete;
  | ^~~~

[Bug libstdc++/96626] utf-8 string literal not convertible to std::string with -std=c++20

[rcopley at gmail dot com]

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

R Copley  changed:

   What|Removed |Added

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

--- Comment #1 from R Copley  ---
This is as specified[1][2].

[1] http://eel.is/c++draft/diff.cpp17.input.output
[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0482r6.html

[Bug target/54412] New: Request for 32-byte stack alignment with -mavx on Windows

[rcopley at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412

 Bug #: 54412
   Summary: Request for 32-byte stack alignment with -mavx on
Windows
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rcop...@gmail.com


Created attachment 28103
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28103
Self-contained C source, with AVX alignment bug on Windows

Code generated by GCC 4.7.1 for the Windows x86_64-w64-mingw32 target, with
"-mavx", can segfault due to alignment errors when the 32-byte ymm registers
are spilled onto the stack. May I please submit a feature request for 32-byte
stack alignment on this target where necessary?

Compiled for Windows with "gcc -O0 -m64 -mavx bug.c" using GCC 4.7.1 with the
MingGW W64 toolchain, the attached program segfaults. Specifically, it uses
vmovapd to copy the value of %ymm0 to a location on the stack before calling
f(), but doesn't align the location to 32 bytes as required by that
instruction. In contrast, the generated code for Linux (using GCC 4.6.3 from
Ubuntu) does explicitly align the stack to 32 bytes.

The lack of stack alignment on Windows has been noted before; see for
example http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49001 and
http://stackoverflow.com/questions/5983389.

[Bug target/54412] Request for 32-byte stack alignment with -mavx on Windows

[rcopley at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412

--- Comment #2 from R Copley  ---
Created attachment 30793
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30793&action=edit
As before, but with explicitly 32-byte aligned variables

[Bug target/54412] Request for 32-byte stack alignment with -mavx on Windows

[rcopley at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412

--- Comment #3 from R Copley  ---
Created attachment 30794
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30794&action=edit
Assembly-language code compiled from attachment 1

Compiled with GCC 4.7.2 from the MinGW-w64 toolchain.
Compile command: "gcc -O0 -m64 -mavx -S bug1.c -o bug1.s".
gcc -v output:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.2/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: /home/ruben/mingw-w64/src/gcc/configure
--host=x86_64-w64-mingw32 --build=x86_64-linux-gnu --target=x86_64-w64-mingw32
--with-sysroot=/home/ruben/mingw-w64/mingw64mingw64/mingw64
--prefix=/home/ruben/mingw-w64/mingw64mingw64/mingw64
--with-gmp=/home/ruben/mingw-w64/prereq/x86_64-w64-mingw32/install
--with-mpfr=/home/ruben/mingw-w64/prereq/x86_64-w64-mingw32/install
--with-mpc=/home/ruben/mingw-w64/prereq/x86_64-w64-mingw32/install
--with-ppl=/home/ruben/mingw-w64/prereq/x86_64-w64-mingw32/install
--with-cloog=/home/ruben/mingw-w64/prereq/x86_64-w64-mingw32/install
--disable-ppl-version-check --disable-cloog-version-check
--enable-cloog-backend=isl --with-host-libstdcxx='-static -lstdc++ -lm'
--enable-shared --enable-static --enable-threads=win32 --enable-plugins
--disable-multilib --enable-languages=c,lto,c++,objc,obj-c++,fortran,java
--enable-libgomp --enable-fully-dynamic-string --enable-libstdcxx-time
--disable-nls --disable-werror --enable-checking=release --with-gnu-as
--with-gnu-ld --disable-win32-registry --disable-rpath --disable-werror
--with-libiconv-prefix=/home/ruben/mingw-w64/prereq/x86_64-w64-mingw32/install
--with-pkgversion=rubenvb-4.7.2-release
--with-bugurl=mingw-w64-pub...@lists.sourceforge.net CC= CFLAGS='-O2
-march=nocona -mtune=core2 -fomit-frame-pointer -momit-leaf-frame-pointer'
LDFLAGS=
Thread model: win32
gcc version 4.7.2 (rubenvb-4.7.2-release)

[Bug target/54412] Request for 32-byte stack alignment with -mavx on Windows

[rcopley at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412

--- Comment #4 from R Copley  ---
(In reply to Kai Tietz from comment #1)
> MS' abi doesn't allow this.  So I doubt we will be able to implement that
> for this target.  If we want to re-align stack on function-base we will run
> into troubles with SEH-information.

You might be right, I'm not sure. Are you aware that on 64-bit Windows, SEH is
table-based, not frame-based (see, e.g.,
http://www.osronline.com/article.cfm?article=469)?

> Doesn't it work to align explicit the variable itself?

No (see attachments 2 and 3). If I understand correctly, the alignment
specification is redundant anyway, because the variables are supposed to be
naturally aligned, on their size.

Assembling attachment 3 with "-g" and running it in gdb gives:

Program received signal SIGSEGV, Segmentation fault.
main () at bug1.s:46
46  vmovapd %ymm0, -96(%rbp)

Thanks.

[Bug c/91440] New: Precompiled headers regression in 9.2

[rcopley at gmail dot com]

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

Bug ID: 91440
   Summary: Precompiled headers regression in 9.2
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rcopley at gmail dot com
  Target Milestone: ---

In some circumstances, builds using precompiled headers which worked with GCC
9.1 no longer work with GCC 9.2.

Complete test case (as a bash script):

>precompiled.h echo "void f();"
>main.c echo "void f() {}"
mkdir some-subdir
gcc -Winvalid-pch -pedantic -c -o some-subdir/precompiled.h.gch precompiled.h
gcc -Winvalid-pch -pedantic -c -include some-subdir/precompiled.h -o main.o
main.c
# END OF SCRIPT

Expected behaviour (as seen with GCC 9.1) is to succeed, with no output.

Actual behaviour with GCC 9.2 is to fail, with output:

cc1.exe: warning: ./.obj/precompiled.h.gch: had text segment at different
address
cc1.exe: error: one or more PCH files were found, but they were invalid
cc1.exe: fatal error: .obj/precompiled.h: No such file or directory

(The errors don't happen if you remove all occurrences of " -pedantic" and/or
"some-subdir/" from the recipe.)

Output of gcc -v (in 9.2):
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-9.2.0/configure --prefix=/mingw64
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
--libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64
--with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++
--enable-shared --enable-static --enable-libatomic --enable-threads=posix
--enable-graphite --enable-fully-dynamic-string
--enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes
--disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check
--enable-lto --enable-libgomp --disable-multilib --enable-checking=release
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --enable-plugin --with-libiconv --with-system-zlib
--with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64
--with-isl=/mingw64 --with-pkgversion='Rev1, Built by MSYS2 project'
--with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as
--with-gnu-ld
Thread model: posix
gcc version 9.2.0 (Rev1, Built by MSYS2 project)

[Bug c/91440] Precompiled headers regression in 9.2

[rcopley at gmail dot com]

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

--- Comment #1 from R Copley  ---
The recipe isn't as stable as I thought. The same recipe on a different machine
doesn't reproduce the issue. Apologies.

On that machine with a real project (sorry, no minimal example) I'm now seeing
this error:

internal error in mingw32_gt_pch_use_address, at
config/i386/host-mingw32.c:186: MapViewOfFileEx: Attempt to access invalid
address. 
: fatal error: had to relocate PCH

As this is in mingw32-specific code it's probably for them to look at; also
note that the MSYS2 package-build script also has a patch in this area


I tried the obvious experiment of editing the binaries to disable ASLR. Sure
enough, this makes the problem go away. Note though that this didn't change
between 9.1 and 9.2. The MSYS2 binaries for both versions have ASLR enabled.

[Bug pch/91440] Precompiled headers regression in 9.2

[rcopley at gmail dot com]

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

--- Comment #3 from R Copley  ---
Yes, I'll try and bisect.

Apologies for my confusion: ASLR is enabled in the 9.2 binaries and not in the
9.1 binaries (see below).
This change isn't explicit in the MSYS2 PKGBUILD change[1] going from 9.1 to
9.2. It might be unintentional.

For the GCC 9.1.0-3 MSYS2 packages (assuming they're still in your cache):

pacman -U
/var/cache/pacman/pkg/mingw-w64-x86_64-{gcc-9.1.0-3,gcc-libs-9.1.0-3}-any.pkg.tar.xz
--noconfirm
objdump -p /mingw64/lib/gcc/x86_64-w64-mingw32/9.1.0/cc1.exe | grep
DllCharacteristics

Output:
DllCharacteristics  

For the GCC 9.2.0-1 MSYS2 packages:

pacman -U
/var/cache/pacman/pkg/mingw-w64-x86_64-{gcc-9.2.0-1,gcc-libs-9.2.0-1}-any.pkg.tar.xz
--noconfirm
objdump -p /mingw64/lib/gcc/x86_64-w64-mingw32/9.2.0/cc1.exe | grep
DllCharacteristics

Output:
DllCharacteristics  0160

Hex 160 is[2]:
  0x040 (IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE) (i.e., ASLR enabled)
| 0x100 (IMAGE_DLLCHARACTERISTICS_NX_COMPAT) (i.e., DEP enabled)
| 0x020 (??)

[1] https://github.com/msys2/MINGW-packages/commit/35081384
[2]
https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-image_optional_header32

[Bug pch/91440] Precompiled headers regression in 9.2

[rcopley at gmail dot com]

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

--- Comment #5 from R Copley  ---
> But is probably the reason for the failures...  mingw might not implement
> the necessary relocation support for ASLR.

Yes, I think that's it. (I should have said so more explicitly.)

> You can try enable it on 9.1 and see if it fails then too...

Yes, it fails then too.

[Bug pch/91440] Precompiled headers regression in 9.2

[rcopley at gmail dot com]

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

--- Comment #6 from R Copley  ---
> Yes, I'll try and bisect.

Just to check, I rebuilt GCC 9.1 using the version of the MSYS2 package-build
from before the update to 9.2, and the binaries have ASLR enabled and do show
failures with using PCH. Looks like it's something else in the MSYS2
environment that has changed, not GCC. I've brought it up with MSYS2[1].

[1] https://github.com/msys2/MINGW-packages/issues/5719

[Bug libstdc++/67932] New: Incorrect conversion to hexfloat

[rcopley at gmail dot com]

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

Bug ID: 67932
   Summary: Incorrect conversion to hexfloat
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rcopley at gmail dot com
  Target Milestone: ---

Created attachment 36481
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36481&action=edit
Preprocessed source file that demonstrates incorrect conversion from
floating-point value to string in hexfloat format

In GCC 5.2, in C++11, converting a floating-point value to a string in
hexadecimal floating-point (hexfloat) format gives incorrect results. The same
incorrect results occur when using std::printf from  or using the
iostreams manipulator std::hexfloat. Using printf from  gives the
correct results (even in C++).

Output of gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=C:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/5.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-5.2.0/configure --host=x86_64-w64-mingw32
--build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64
--with-sysroot=/c/mingw520/x86_64-520-posix-seh-rt_v4-rev0/mingw64
--with-gxx-include-dir=/mingw64/x86_64-w64-mingw32/include/c++ --enable-shared
--enable-static --disable-multilib
--enable-languages=c,c++,fortran,objc,obj-c++,lto --enable-libstdcxx-time=yes
--enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto
--enable-graphite --enable-checking=release --enable-fully-dynamic-string
--enable-version-specific-runtime-libs --disable-isl-version-check
--disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona
--with-tune=core2 --with-libiconv --with-system-zlib
--with-gmp=/c/mingw520/prerequisites/x86_64-w64-mingw32-static
--with-mpfr=/c/mingw520/prerequisites/x86_64-w64-mingw32-static
--with-mpc=/c/mingw520/prerequisites/x86_64-w64-mingw32-static
--with-isl=/c/mingw520/prerequisites/x86_64-w64-mingw32-static
--with-pkgversion='x86_64-posix-seh-rev0, Built by MinGW-W64 project'
--with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe
-I/c/mingw520/x86_64-520-posix-seh-rt_v4-rev0/mingw64/opt/include
-I/c/mingw520/prerequisites/x86_64-zlib-static/include
-I/c/mingw520/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2
-pipe -I/c/mingw520/x86_64-520-posix-seh-rt_v4-rev0/mingw64/opt/include
-I/c/mingw520/prerequisites/x86_64-zlib-static/include
-I/c/mingw520/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS=
LDFLAGS='-pipe -L/c/mingw520/x86_64-520-posix-seh-rt_v4-rev0/mingw64/opt/lib
-L/c/mingw520/prerequisites/x86_64-zlib-static/lib
-L/c/mingw520/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: posix
gcc version 5.2.0 (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 

Complete command line that triggers the bug:
g++ -save-temps -std=c++11 -o hexfloat-bug.exe hexfloat-bug.cpp &&
hexfloat-bug.exe

Compiler output: none.

Preprocessed source file: see attached.

Expected program output:
1.0002e+000 0x1.1p+00x1.00p+0
1.0036e+000 0x1.00010p+00x1.00p+0
1.0568e+000 0x1.00100p+00x1.00p+0
1.9095e+000 0x1.01000p+00x1.00p+0
1.00145519e+000 0x1.1p+00x1.00p+0
1.02328306e+000 0x1.00010p+00x1.00p+0
1.37252903e+000 0x1.00100p+00x1.00p+0
1.000596046448e+000 0x1.01000p+00x1.01p+0
1.009536743164e+000 0x1.1p+00x1.10p+0
1.152587890625e+000 0x1.00010p+00x1.000100p+0

Actual program output:
1.0002e+000 0x8.0p-55   0x8p-55
1.0036e+000 0x8.0p-51   0x8p-51
1.0568e+000 0x8.0p-47   0x8p-47
1.9095e+000 0x8.0p-43   0x8p-43
1.00145519e+000 0x8.0p-39   0x8p-39
1.02328306e+000 0x8.0p-35   0x8p-35
1.37252903e+000 0x8.00800p-30x0p-63
1.000596046448e+000 0x8.08000p-30x0p-63
1.009536743164e+000 0x0.0p-55   0x0p-63
1.152587890625e+000 0x0.0p-55   0x0p-63

[Bug libstdc++/67932] Incorrect conversion to hexfloat

[rcopley at gmail dot com]

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

--- Comment #2 from R Copley  ---
Thanks Jonathan. It's clear enough from what I wrote that:

(1) The same kind of incorrect output is produced by (a) including  and
using std::printf, and (b) using iostreams and std::hexfloat;

(2) The correct output is produced by including  and using ::printf.

I think (but I am by no means certain!) that (by (2)) my C library works, and
(by (1)) there is a problem with GCC's standard library implementation.

[Bug libstdc++/67932] Incorrect conversion to hexfloat

[rcopley at gmail dot com]

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

--- Comment #4 from R Copley  ---
That's what I understood to be the case. Nevertheless, with the toolchain I am
using (see above for version; same command-line etc.), I get the results below. 

Both testcases below give the correct results with g++-4.8 on Ubuntu (the idea
of installing 5.2 seems to confuse and infuriate the community there), so I
think I must report this to the MinGW-W64 maintainers instead. Thanks.

#include 
int main () { printf ("%a", 0x1.08p+0); }
// Preprocessed source: see attachment "hexfloat-bug-2a.ii"
// Output: 0x1.08p+0

#include 
int main () { printf /*sic*/ ("%a", 0x108p+0); }
// Preprocessed source: see attachment "hexfloat-bug-2b.ii"
// Output: 0x0p-63

[Bug libstdc++/67932] Incorrect conversion to hexfloat

[rcopley at gmail dot com]

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

--- Comment #5 from R Copley  ---
Created attachment 36489
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36489&action=edit
hexfloat-bug-2a.ii (see Comment 4)

[Bug libstdc++/67932] Incorrect conversion to hexfloat

[rcopley at gmail dot com]

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

--- Comment #6 from R Copley  ---
Created attachment 36490
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36490&action=edit
hexfloat-bug-2b.ii (see Comment 4)

[Bug libstdc++/67932] Incorrect conversion to hexfloat

[rcopley at gmail dot com]

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

--- Comment #8 from R Copley  ---
Thanks. I've emailed the mingw-w64 list at
http://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public. (You expressed it
better but I hadn't seen your last comment.)

[Bug libstdc++/67932] Incorrect conversion to hexfloat

[rcopley at gmail dot com]

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

--- Comment #9 from R Copley  ---
For information, this has already been entered on the mingw-w64 issue tracker
(months ago) (see http://sourceforge.net/p/mingw-w64/bugs/459/).

[Bug target/54412] Request for 32-byte stack alignment with -mavx on Windows

[rcopley at gmail dot com]

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

--- Comment #6 from R Copley  ---
As I mentioned in the description, this request was indeed related to that bug.
The test-case no longer crashes with recent MinGW-W64 toolchains (GCC 4.9.1).

[Bug target/54412] Request for 32-byte stack alignment with -mavx on Windows

[rcopley at gmail dot com]

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

--- Comment #8 from R Copley  ---
No, I use the mingw-builds distro too.

gcc --version
gcc (x86_64-win32-seh-rev0, Built by MinGW-W64 project) 4.9.1

Bizarrely, the attached program exits with a random error code unless I add a
"return 0;" statement to the end of the main function.
But it doesn't segfault.

[Bug target/54412] Request for 32-byte stack alignment with -mavx on Windows

[rcopley at gmail dot com]

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

--- Comment #9 from R Copley  ---
Heh, sorry. I don't really know C, I assumed it had an implicit "return 0;"
like C++. Apparently C99 has this but earlier C standards do not. So, not
bizarre at all.

[Bug target/54412] Request for 32-byte stack alignment with -mavx on Windows

[rcopley at gmail dot com]

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

--- Comment #11 from R Copley  ---
On 20 September 2014 07:08, roland at rschulz dot eu
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
>
> --- Comment #10 from Roland Schulz  ---
> Created attachment 33520
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33520&action=edit
> Slightly modified testcase
>
> This slightly modified testcase in which the return value isn't stored, still
> segfaults for me. With the 32bit mingw64 binary ((i686-win32-dwarf-rev1, Built
> by MinGW-W64 project) 4.9.1) it is OK, but with the 64bit binary
> ((x86_64-win32-seh-rev1, Built by MinGW-W64 project) 4.9.1) it segfaults.

Confirmed (with the same compiler, in the mingw-builds toolchain). I
compiled your testcase with command "gcc -O0 -g -ggdb -m64 -mavx
bug.c". It segfaults on the instruction marked "=>" below.

(gdb) disassemble /m
Dump of assembler code for function f:
6   {
   0x004014f0 <+0>: push   %rbp
   0x004014f1 <+1>: mov%rsp,%rbp
   0x004014f4 <+4>: mov%rcx,0x10(%rbp)
   0x004014f8 <+8>: sub$0x40,%rsp
   0x004014fc <+12>:mov%rsp,%rax
   0x004014ff <+15>:add$0x1f,%rax
   0x00401503 <+19>:shr$0x5,%rax
   0x00401507 <+23>:shl$0x5,%rax

7 v4d x __attribute__ ((aligned (32))) = { 1.0, 2.0, 3.0, 4.0, };
   0x0040150b <+27>:vmovapd 0x2aed(%rip),%ymm0# 0x404000
   0x00401513 <+35>:vmovapd %ymm0,(%rax)

8 return x;
   0x00401517 <+39>:mov0x10(%rbp),%rdx
   0x0040151b <+43>:vmovapd (%rax),%ymm0
=> 0x0040151f <+47>:vmovapd %ymm0,(%rdx)

9   }
   0x00401523 <+51>:mov0x10(%rbp),%rax
   0x00401527 <+55>:mov%rbp,%rsp
   0x0040152a <+58>:pop%rbp
   0x0040152b <+59>:retq

End of assembler dump.
(gdb) print $rdx % 32
$1 = 16

[Bug libstdc++/99907] New: (On MS Windows) Multiple definition errors with included in two translation units

[rcopley at gmail dot com via Gcc-bugs]

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

Bug ID: 99907
   Summary: (On MS Windows) Multiple definition errors with
 included in two translation units
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rcopley at gmail dot com
  Target Milestone: ---

Created attachment 50506
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50506&action=edit
testcase

The attached testcase has two translation units main.cpp and coro2.cpp which
both include .

Linking the program with g++ (from the mingw-w64 toolchain built by the MSYS2
project on Microsoft Windows) fails with the following errors:

ld.exe: coro2.o:coro2.cpp:(.text+0x0): multiple definition of
`.weak._ZNSt7__n486122__dummy_resume_destroyEv._ZSt21is_constant_evaluatedv'; 

main.o:main.cpp:(.text+0x0): first defined here

ld.exe: coro2.o:coro2.cpp:(.data+0x0): multiple definition of
`.weak._ZNSt7__n486114__noop_coro_frE._ZSt21is_constant_evaluatedv'; 

main.o:main.cpp:(.data+0x0): first defined here


The issue is present in the versions of  in the 10.2 release and the
10.3 release candidate, but not in the current head version in the gcc repo. It
is fixed in this commit:

  94fd05f1f76faca9dc9033b55d44c960155d38e9
  libstdc++: Define noop coroutine details private and inline [PR 95917]

Some discussion here: https://gcc.gnu.org/pipermail/gcc/2021-April/235305.html

[Bug pch/91440] Precompiled headers don't work with ASLR on mingw

[rcopley at gmail dot com via Gcc-bugs]

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

R Copley  changed:

   What|Removed |Added

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

--- Comment #8 from R Copley  ---
Fixed with PR71934. Precompiled headers are now relocatable. Thanks!

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

[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows

[rcopley at gmail dot com via Gcc-bugs]

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

--- Comment #38 from R Copley  ---
(A patch to emit unaligned instructions should probably resolve bug 49001
instead of this one, 54412.)

Could dynamic alignment be achieved, not for automatic variables and function
parameters, but for registers spilled to the stack (due to register exhaustion,
or because they may be clobbered)? So that users can write code that stores
over-aligned objects on the heap only.

If SEH is the problem, can alignment be accounted for in cases where SEH is not
in use (if there are any such cases)? I'm thinking of -fno-exceptions, and
dwarf (on x86) or setjump/longjump exceptions.

Sorry if those are stupid questions.

[Bug c++/101907] New: ICE in build_special_member_call (with co_await and initializer list)

[rcopley at gmail dot com via Gcc-bugs]

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

Bug ID: 101907
   Summary: ICE in build_special_member_call (with co_await and
initializer list)
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rcopley at gmail dot com
  Target Milestone: ---

The C++ program included at the end of this message causes an ICE at the last
line, in GCC versions 10.3.0, 11.1.0, 11.2.0 and on trunk. It compiles
successfully in version 10.2.0.

Compile command "g++ -std=c++2a -fcoroutines -c x.cpp".

See <https://www.godbolt.org/z/3YEnox3sz>.

The error message from version 11.2.0 is:
source>:24:33: internal compiler error: in build_special_member_call, at
cp/call.c:10188
   24 | dummy f2() { co_await g2({{}}); } // ICE
  | ^
0x1786229 internal_error(char const*, ...)
???:0
0x678608 fancy_abort(char const*, int, char const*)
???:0
0x694170 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
???:0
0xfba6f5 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0xfba6f5 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0xfbad4e walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0xfba6f5 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0xfba6f5 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x6cd85b morph_fn_to_coro(tree_node*, tree_node**, tree_node**)
???:0
0x6fd221 finish_function(bool)
???:0
0x7c47db c_parse_file()
???:0
0x896762 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Compiler returned: 1

--

#include 
#include 
#include 

struct dummy
{
  struct promise_type
  {
std::suspend_always initial_suspend() noexcept;
std::suspend_always final_suspend() noexcept;
void unhandled_exception() noexcept;
void get_return_object() noexcept;
  };

  bool await_ready() const noexcept;
  template  void await_suspend(U);
  void await_resume();
};

dummy g1(std::vector);
dummy f1() { co_await g1({}); } // no ICE

dummy g2(std::vector);
dummy f2() { co_await g2({{}}); } // ICE

[Bug c++/109359] New: Compile-time rounding of double literal to float is incorrect with -frounding-math

[rcopley at gmail dot com via Gcc-bugs]

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

Bug ID: 109359
   Summary: Compile-time rounding of double literal to float is
incorrect with -frounding-math
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rcopley at gmail dot com
  Target Milestone: ---

The following program should print:
0.001914
0.630538

With "g++ -frounding-math", it prints instead:
-8023756970655744.00
0.872496

This bug is present in trunk, and since gcc 12.1, and does not appear to be
platform specific.

Compiler explorer link: https://godbolt.org/z/aMhcYcY66



#include 
float xs[] = {0.001914, 0.630539};
int main() {
  std::size_t size = sizeof xs / sizeof xs[0];
  for (std::size_t i = 0; i != size; ++i) {
std::printf("%f\n", xs[i]);
  }
}