[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]);
  }
}

[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 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 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 .

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  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 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=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