Re: [PATCH] libstdc++: Members missing in std::numeric_limits

Thank you for reviewing my patch and committing it! I'm glad that I've been able to contribute to such an important project. Thanks, Mateusz Zych On Wed, Jul 9, 2025 at 2:17 PM Jonathan Wakely wrote: > On Fri, 4 Jul 2025 at 13:11, Mateusz Zych wrote: > > > > Hello!

Re: [PATCH] libstdc++: Members missing in std::numeric_limits

Hello! I've updated the ChangeLog, since I forgot to do it before. Thanks, Mateusz Zych On Thu, Jul 3, 2025 at 9:49 PM Mateusz Zych wrote: > Hello! > > I've prepared a patch, which adds all members missing from > std::numeric_limits<> specializations for integ

Re: [PATCH] libstdc++: Members missing in std::numeric_limits

integer-class types I've defined variable template verify_numeric_limits_values_not_meaningful_for<> to avoid code duplication and have clear and readable code. I hope this is OK. Thanks, Mateusz Zych On Wed, Jul 2, 2025 at 7:30 PM Jonathan Wakely wrote: > On Wed, 2 J

Re: [PATCH] libstdc++: Members missing in std::numeric_limits

OK, then I’ll prepare appropriate patch with tests and send it when I’m done implementing it. Thanks, Mateusz Zych On Wed, 2 Jul 2025 at 16:59, Jonathan Wakely wrote: > On Wed, 2 Jul 2025 at 14:45, Mateusz Zych wrote: > > > > > Oh actually the radix members should be of typ

Re: [PATCH] libstdc++: Members missing in std::numeric_limits

ss types should be defined identically to std::numeric_limits<> specializations for extended integer types, and thus define all static data members and static member functions. Am I reading this correctly? Thank you, Mateusz Zych On Wed, Jul 2, 2025 at 1:59 PM Jonathan Wakely wrote: >

[PATCH] libstdc++: Members missing in std::numeric_limits

.org/z/E7z4WYfj4 Since adding missing member constants, which are the most relevant to integer-like types, was not a lot of code, I have prepared a Git patch with relevant changes. I hope this patch is useful, Mateusz Zych From 1e83287bbd6adf6ad8f483bd2f891692e0bed0c7 Mon Sep 17 00:00:00 2001 From: M

Re: [Patch] Bug 88521 - gcc 9.0 from r266355 miscompile x265 for mingw-w64 target

4f; return v; } double fun3(void) { return 3.13; } typedef struct {double x;} Double; Double fun4(void) { Double v; v.x = 3.13; return v; } Mateusz@Mateusz-i7 /c/temp $ g++ -c -Wall -O2 -o t.o t.cpp Mateusz@Mateusz-i7 /c/temp $ objdump -dr t.o t.o: file format pe-x86-6

Re: GIMPLE and intent of variables

During determining the intent of variable I run into problems with PHI nodes. The problematical GIMPLE code looks: # BLOCK 196 # PRED: 194 (false) (...) ndycD.8665_1099 = 1; # BLOCK 197 # PRED: 196 (true) 207 (false) # ndycD.8665_4 = PHI (...) # BLOC

Re: GIMPLE and intent of variables

Mateusz Grabowski wrote: > > > If a function calls another, the intent of variables should be passed to the first one. But what if the callee is in the other compilation unit? Does anyone have knowledge of using LTO mode? > > At this moment I have many compilation units.

Re: GIMPLE and intent of variables

Richard Guenther-2 wrote: > > > The latter. > > But how to do it? I want to have all functions after SSA pass, but before any optimizations. Maybe you could tell me how to enforce it (or even better - a small example)? Thanks in advance. -- View this message in context: http://old.nabble.

Re: GIMPLE and intent of variables

Thank you for all the answers. Now I have another problem. When I reach a function call during statement iteration, I want to go to this function's code. if (is_gimple_call(stmt)) { tree fndecl = gimple_call_fndecl(stmt); // This returns function_decl ;-)