[Bug libstdc++/115481] HAVE_* for long double math functions wrong for avrlibc (target AVR)

[dv at vollmann dot ch via Gcc-bugs]

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

--- Comment #7 from dv at vollmann dot ch ---
On 7/23/24 11:19, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115481
> 
> --- Comment #6 from Jonathan Wakely  ---
> Oh it looks like 2.2.0 is *very* new (but 2.1.0 is quite old so Fedora is 
> quite
> outdated).

Debian stable also ships 2.0.0 ...
I believe libstdc++ should at least build on top of 2.0.0.
And I think the linker error that happens with my patch
()
also should not happen with 2.0.0.

I think not providing ::*f, ::*l, std::*f and std::*l for 2.0.0
and not providing ::*l and std::*l for 2.1.0 is ok.

   Detlef

[Bug libstdc++/115512] _Float32 overloads in cmath cause ICE for default AVR

[dv at vollmann dot ch via Gcc-bugs]

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

--- Comment #3 from dv at vollmann dot ch ---
On 6/17/24 10:59, jakub at gcc dot gnu.org wrote:

> --- Comment #1 from Jakub Jelinek  ---
> Of course cmath needs to provide _Float32 overloads when _Float32 is 
> supported.
> I've provided a fix for the other bug and this is IMNSHO a non-bug.

I've now built a libstdc++ with your fix and cmath compiles fine :-)
So this indeed is a non-bug.

Thanks!

[Bug c++/115511] ICE on ambigous overload for _Float32

[dv at vollmann dot ch via Gcc-bugs]

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

--- Comment #5 from dv at vollmann dot ch ---
On 6/17/24 10:47, jakub at gcc dot gnu.org wrote:

> --- Comment #4 from Jakub Jelinek  ---
> Untested fix below.

I did a quick test for AVR and it worked :-)
I'll now do a full build of libstdc++ and see how it works.\

[Bug libstdc++/115512] _Float32 overloads in cmath cause ICE for default AVR

[dv at vollmann dot ch via Gcc-bugs]

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

--- Comment #2 from dv at vollmann dot ch ---
On 6/17/24 10:59, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115512
> 
> Jakub Jelinek  changed:
> 
> What|Removed |Added
> 
>   CC||jakub at gcc dot gnu.org
> 
> --- Comment #1 from Jakub Jelinek  ---
> Of course cmath needs to provide _Float32 overloads when _Float32 is 
> supported.
> I've provided a fix for the other bug and this is IMNSHO a non-bug.

I agree. I didn't know about _Float32 and thought it's just
a typedef.  But as a real type providing these overloads is fine.

[Bug c++/115511] ICE on ambigous overload for _Float32

[dv at vollmann dot ch via Gcc-bugs]

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

--- Comment #2 from dv at vollmann dot ch ---
On 6/16/24 16:18, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115511
> 
> Andrew Pinski  changed:
> 
> What|Removed |Added
> 
> Last reconfirmed||2024-06-16
>   Status|UNCONFIRMED |NEW
>   Ever confirmed|0   |1
> 
> --- Comment #1 from Andrew Pinski  ---
> Confirmed. I thought I had saw this before but I can't seem to find the bug
> report.

I searched again, and found this one:


It looks like my report is a duplicate of 111343.

   Detlef

[Bug libstdc++/115512] New: _Float32 overloads in cmath cause ICE for default AVR

[dv at vollmann dot ch via Gcc-bugs]

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

Bug ID: 115512
   Summary: _Float32 overloads in cmath cause ICE for default AVR
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dv at vollmann dot ch
  Target Milestone: ---
Target: avr

As reported in , g++
produces an ICE for calling functions with _Float32 for which both float and
double overloads exist.
I got it for __hypot3, but there are probably several others.
I'm wondering if cmath should provide overloads for _Float32 at all if double
is 32 bits.

The problem can be reproduced with a single line source:

#include 

avr-g++ -std=gnu++23 -o cmath-only.o -c cmath-only.cc

[Bug c++/115511] New: ICE on ambigous overload for _Float32

[dv at vollmann dot ch via Gcc-bugs]

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

Bug ID: 115511
   Summary: ICE on ambigous overload for _Float32
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dv at vollmann dot ch
  Target Milestone: ---
Target: avr

Created attachment 58445
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58445=edit
Output from -freport-bug

On AVR for the default model float and double both are 32 bit.
When calling with a _Float32, I get an internal compiler error with this
program:

void f1(float x);
void f1(double x);

void f2(_Float32 x)
{
f1(x);
}

I don't know the rules for _Float32 (this is an extremly stripped version of
the cmath header), but the program is probably ill-formed.
But still an error message would be nicer than an ICE ;-)

I used the AVR target, but this may be a problem on other targets where float
and double are the same size.

[Bug libstdc++/115482] [14/15 Regression] print.cc fails with avrlibc

[dv at vollmann dot ch via Gcc-bugs]

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

--- Comment #2 from dv at vollmann dot ch ---
On 6/14/24 11:54, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115482
> 
> Jonathan Wakely  changed:
> 
> What|Removed |Added
> 
> Last reconfirmed||2024-06-14
>   Status|UNCONFIRMED |NEW
>   Ever confirmed|0   |1
> 
> --- Comment #1 from Jonathan Wakely  ---
> The change seems reasonable, but I should probably just add a proper check for
> isatty, instead of assuming that it will exist in  if we have that
> header.

I agree, my diff is a workaround, I don't consider it a proper fix.

_GLIBCPP_HAVE_ISATTY was removed in 2003...

   Detlef

[Bug libstdc++/115481] HAVE_* for long double math functions wrong for avrlibc (target AVR)

[dv at vollmann dot ch via Gcc-bugs]

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

--- Comment #2 from dv at vollmann dot ch ---
On 6/13/24 22:30, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115481
> 
> --- Comment #1 from Andrew Pinski  ---
> Patch should be sent to gcc-patches@ (and in this case also to libstdc++@)
> after reading https://gcc.gnu.org/contribute.html too.

Will do (currently testing a patch that includes the fix
for 111639).

   Detlef

[Bug libstdc++/115482] New: print.cc fails with avrlibc

[dv at vollmann dot ch via Gcc-bugs]

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

Bug ID: 115482
   Summary: print.cc fails with avrlibc
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dv at vollmann dot ch
  Target Milestone: ---

Created attachment 58421
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58421=edit
A workaround that worked for me

avrlibc has an incomplete unistd.h that doesn't have isatty.
So building libstdc++ fails when compiling c++23/print.cc.
As a workaround I added a check for AVR.

With this workaround (and the patch from 115481) libstdc++ build for me with
AVR-LIBC 2.2.0:

../../src/gcc/configure \
--prefix=/opt/avr \
--target=avr \
--enable-languages=c,c++ \
--with-dwarf2 \
--enable-multilib \
--enable-libstdcxx \
--disable-decimal-float \
--disable-libffi \
--disable-libgomp \
--disable-libmudflap \
--disable-libquadmath \
--disable-libssp \
--disable-libstdcxx-pch \
--disable-nls \
--without-included-gettext \
--disable-libstdcxx-verbose \
--disable-shared \
--disable-threads \
--disable-tls \
--disable-plugin \
--with-system-zlib \
--with-headers=yes \
--with-gnu-as \
--with-gnu-ld \
--with-avrlibc

[Bug libstdc++/115481] New: HAVE_* for long double math functions wrong for avrlibc (target AVR)

[dv at vollmann dot ch via Gcc-bugs]

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

Bug ID: 115481
   Summary: HAVE_* for long double math functions wrong for
avrlibc (target AVR)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dv at vollmann dot ch
  Target Milestone: ---

Created attachment 58420
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58420=edit
possible patch

New versions of avrlibc provide long double math functions, but crossmake.m4
doesn't know about them.  The result is that libstdc++ doesn't build due to
duplicate definitions in math_stubs_long_double.cc.

The fix is the same as commit c6c428196d4c76208a0d34aacfa80b57a20f5097 for
AArch64 RTEMS, just at a different place.

This is somewhat related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111639.

[Bug c++/109682] coroutines: ICE in morph_fn_to_coro on wrong return type for get_return_object_on_allocation_failure

[dv at vollmann dot ch via Gcc-bugs]

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

dv at vollmann dot ch changed:

   What|Removed |Added

 CC||dv at vollmann dot ch

--- Comment #1 from dv at vollmann dot ch ---
Created attachment 54962
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54962=edit
The original file,  is a header supplied by GCC

[Bug c++/109682] New: coroutines: ICE in morph_fn_to_coro on wrong return type for get_return_object_on_allocation_failure

[dv at vollmann dot ch via Gcc-bugs]

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

Bug ID: 109682
   Summary: coroutines: ICE in morph_fn_to_coro on wrong return
type for get_return_object_on_allocation_failure
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dv at vollmann dot ch
  Target Milestone: ---

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

Returning not the expected return type from
get_return_object_on_allocation_failure causes an internal compiler error:

g++ -std=c++23 wrong-promise-type-ice.cc
wrong-promise-type-ice.cc: In function 'CoHandle produce(QType&)':
wrong-promise-type-ice.cc:155:1: internal compiler error: in morph_fn_to_coro,
at cp/coroutines.cc:4766
  155 | }
  | ^
0x70d904 morph_fn_to_coro(tree_node*, tree_node**, tree_node**)
/build/src/gcc/gcc/cp/coroutines.cc:4766
0xa65905 finish_function(bool)
/build/src/gcc/gcc/cp/decl.cc:18082
0xb64697 cp_parser_function_definition_after_declarator
/build/src/gcc/gcc/cp/parser.cc:32049
0xb65b73 cp_parser_function_definition_from_specifiers_and_declarator
/build/src/gcc/gcc/cp/parser.cc:31963
0xb65b73 cp_parser_init_declarator
/build/src/gcc/gcc/cp/parser.cc:22822
0xb3a178 cp_parser_simple_declaration
/build/src/gcc/gcc/cp/parser.cc:15435
0xb70353 cp_parser_declaration
/build/src/gcc/gcc/cp/parser.cc:15121
0xb70e4a cp_parser_toplevel_declaration
/build/src/gcc/gcc/cp/parser.cc:15142
0xb70e4a cp_parser_translation_unit
/build/src/gcc/gcc/cp/parser.cc:5131
0xb70e4a c_parse_file()
/build/src/gcc/gcc/cp/parser.cc:49627
0xcaf411 c_common_parse_file()
/build/src/gcc/gcc/c-family/c-opts.cc:1248

Version:
GNU C++23 (GCC) version 14.0.0 20230430 (experimental) (x86_64-pc-linux-gnu)

Configured with: /build/src/gcc/configure --prefix=/opt/native/gcc
--disable-nls --enable-languages=c,c++

[Bug c++/106538] Reject-valid: Substitution failure causes error with unsatisfied constraint

[dv at vollmann dot ch via Gcc-bugs]

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

--- Comment #2 from dv at vollmann dot ch ---
Thanks for the detailed explanation (and the workarounds!).
I still think it's very surprising behaviour, but I'll probably leave it to
others to bring this to WG21.

Thanks again,
  Detlef

[Bug c++/106538] New: Reject-valid: Substitution failure causes error with unsatisfied constraint

[dv at vollmann dot ch via Gcc-bugs]

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

Bug ID: 106538
   Summary: Reject-valid: Substitution failure causes error with
unsatisfied constraint
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dv at vollmann dot ch
  Target Milestone: ---

Created attachment 53417
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53417=edit
Example program that produces the error

If in the attached program ADD_CONSTRAINED_OVERLOAD is defined, the tag_invoke
for connect_t is instantiated.
This instantiation fails for a number of reasons so GCC should continue with
the next overload.  However in this case GCC rejects the code claiming the
contrained is not satisfied (which is correct, but shouldn't cause a reject).

[Bug target/104988] Zero register (R1) clobbered by __udivmodsi4 for AVR

[dv at vollmann dot ch via Gcc-bugs]

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

--- Comment #1 from dv at vollmann dot ch ---
Sorry, it looks like it's my fault: the compiler saves and clears __zero_reg__
for ISRs so I have to do this in my assembler ISRs myself and it's correct for
a function to temporarily store a non-zero value in __zero_reg__.

Sorry for the noise.

[Bug libgcc/104988] New: Zero register (R1) clobbered by __udivmodsi4 for AVR

[dv at vollmann dot ch via Gcc-bugs]

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

Bug ID: 104988
   Summary: Zero register (R1) clobbered by __udivmodsi4 for AVR
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dv at vollmann dot ch
CC: dv at vollmann dot ch
  Target Milestone: ---

Created attachment 52652
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52652=edit
compiler configuration

Line 1630 in libgcc/config/avr/lib1funcs.S defined r_cnt as __zero_reg__ and
uses it as loop count, i.e. it sets it to a non-zero value.
This is fine if the loop reaches its end, but causes chaos if there's an
interrupt before the loop end.
__zero_reg__ should never be set to a non-zero value!
Looking through the file there seem to be a number of other places where
__zero_reg__ is modified.

[Bug libstdc++/104870] [12 Regression] fast_float doesn't work for 16-bit size_t, but is used anyway by floating_from_chars.cc

[dv at vollmann dot ch via Gcc-bugs]

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

--- Comment #7 from dv at vollmann dot ch ---
Tested for AVR, works :-)
Thanks,
  Detlef

[Bug libstdc++/104866] [12 Regression] this_thread_sleep.h doesn't compile if _GLIBCXX_NO_SLEEP is defined

[dv at vollmann dot ch via Gcc-bugs]

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

--- Comment #3 from dv at vollmann dot ch ---
Thanks.
Tested for AVR, works :-)

[Bug libstdc++/104870] [12 Regression] fast_float doesn't work for 16-bit size_t, but is used anyway by floating_from_chars.cc

[dv at vollmann dot ch via Gcc-bugs]

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

--- Comment #3 from dv at vollmann dot ch ---
(In reply to Jonathan Wakely from comment #1)
> Ah that #if should match the one in 

Yes, that's better than my patch.

[Bug libstdc++/104870] New: fast_float doesn't work for 16-bit size_t, but is used anyway by floating_from_chars.cc

[dv at vollmann dot ch via Gcc-bugs]

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

Bug ID: 104870
   Summary: fast_float doesn't work for 16-bit size_t, but is used
anyway by floating_from_chars.cc
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dv at vollmann dot ch
CC: dv at vollmann dot ch
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: avr
 Build: x86_64-linux-gnu

Created attachment 52602
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52602=edit
Patch to not use fast_float on unsupported platform

libstdc++-v3/src/c++17/fast_float/fast_float.h doesn't support 16-bit
platforms:

#error Unknown platform (16-bit, unsupported)

But libstdc++-v3/src/c++17/floating_from_chars.cc includes it anyway for
specific float/double sizes:

#if _GLIBCXX_FLOAT_IS_IEEE_BINARY32 && _GLIBCXX_DOUBLE_IS_IEEE_BINARY64
# define USE_LIB_FAST_FLOAT 1

[Bug libstdc++/104866] New: this_thread_sleep.h doesn't compile if _GLIBCXX_NO_SLEEP is defined

[dv at vollmann dot ch via Gcc-bugs]

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

Bug ID: 104866
   Summary: this_thread_sleep.h doesn't compile if
_GLIBCXX_NO_SLEEP is defined
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dv at vollmann dot ch
CC: dv at vollmann dot ch
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: avr
 Build: x86_64-linux-gnu

Created attachment 52596
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52596=edit
Patch to fix the problem

this_thread_sleep.h opens the namespace std::this_thread before checking for
the define but then closes it inside the #ifndef