Re: Possible C++ method signature warning feature?
On Wed, Aug 10, 2022 at 6:20 PM Paul Koning via Gcc wrote: > > There's a C++ problem I keep running into, in a very large body of software > with lots of subclassing. > > There's a base class that defines a set of interface methods, not all pure > virtual (some define the default behavior). A number of subclasses override > some but not all of these. > > Now I find myself changing the argument list of some of these methods, so I > have to change the base class definitions and also track down all the > subclass redefinitions. If I miss one of the latter, that subclass method is > no longer called (it now just looks like an unrelated method with a different > argument list that isn't used anywhere). Finding these things can be hard > and time consuming. > > It would be helpful to have some way to mark a method as "this is supposed to > be an override of a base class method", in other words "warn me if this > method doesn't override some method in a base class". C++11's overload keyword sounds exactly what you want. https://en.cppreference.com/w/cpp/language/override Thanks, Andrew Pinski > > Does that sound like a possible thing to do, perhaps with some __attribute__ > magic? Would it be interesting? > > paul >
Possible C++ method signature warning feature?
There's a C++ problem I keep running into, in a very large body of software with lots of subclassing. There's a base class that defines a set of interface methods, not all pure virtual (some define the default behavior). A number of subclasses override some but not all of these. Now I find myself changing the argument list of some of these methods, so I have to change the base class definitions and also track down all the subclass redefinitions. If I miss one of the latter, that subclass method is no longer called (it now just looks like an unrelated method with a different argument list that isn't used anywhere). Finding these things can be hard and time consuming. It would be helpful to have some way to mark a method as "this is supposed to be an override of a base class method", in other words "warn me if this method doesn't override some method in a base class". Does that sound like a possible thing to do, perhaps with some __attribute__ magic? Would it be interesting? paul
Re: gccgo emits GIMPLE with temporaries for boolean expressions unlike gcc, gdc
On Wed, Aug 3, 2022 at 6:26 AM j wrote:
>
> I've proposed a patch [1] for condition coverage profiling in gcc,
> implemented in the middle-end alongside the branch coverage. I've
> written most of the tests for C and a few for C++ and finally got around
> to try it with a toy example for D and go and noticed something odd
> about Go's CFG construction.
>
> abc.c:
> int fn (int a, int b, int c) {
> if (a && (b || c))
> return a;
> else
> return b * c;
> }
>
> abc.d:
> int fn (int a, int b, int c) {
> if (a && (b || c))
> return a;
> else
> return b * c;
> }
>
> abc.go:
> func fn (a int, b int, c int) int {
> a_ := a != 0;
> b_ := b != 0;
> c_ := c != 0;
>
> if a_ && (b_ || c_) {
> return 1;
> } else {
> return 0;
> }
> }
>
> All were built with gcc --coverage -fprofile-conditions (my patch, but
> it does not affect this) and no optimization. The C and D programs
> behaved as expected:
>
> gcov --conditions abc.d:
>
> 3:3:int fn (int a, int b, int c) {
> 3*:4:if (a && (b || c))
> conditions outcomes covered 3/6
> condition 1 not covered (false)
> condition 2 not covered (true)
> condition 2 not covered (false)
> 1:5:return a;
> -:6:else
> 2:7:return b * c;
>
>
> gcov --conditions abc.go:
> 3:5:func fn (a int, b int, c int) int {
> 3:6:a_ := a != 0;
> 3:7:b_ := b != 0;
> 3:8:c_ := c != 0;
> -:9:
> 3*: 10:if a_ && (b_ || c_) {
> condition outcomes covered 2/2
> condition outcomes covered 1/2
> condition 0 not covered (true)
> condition outcomes covered 2/2
> 1: 11:return 1;
> -: 12:} else {
> 2: 13:return 0;
> -: 14:}
> -: 15:}
>
> So I dumped the gimple gcc -fdump-tree-gimple abc.go:
>
> int main.fn (int a, int b, int c)
> {
>int D.2725;
>int $ret0;
>
>$ret0 = 0;
>{
> bool a_;
> bool b_;
> bool c_;
>
> a_ = a != 0;
> b_ = b != 0;
> c_ = c != 0;
> {
>{
> GOTMP.0 = a_;
> if (GOTMP.0 != 0) goto ; else goto ;
> :
> {
>{
> GOTMP.1 = b_;
> _1 = ~GOTMP.1;
> if (_1 != 0) goto ; else goto ;
> :
> {
>GOTMP.1 = c_;
> }
> :
>}
>GOTMP.2 = GOTMP.1;
>GOTMP.0 = GOTMP.2;
> }
> :
>}
>if (GOTMP.0 != 0) goto ; else goto ;
>:
>
>
>
>{
> {
>$ret0 = 1;
>D.2725 = $ret0;
>// predicted unlikely by early return (on trees) predictor.
>return D.2725;
> }
>}
>:
>{
> {
>$ret0 = 0;
>D.2725 = $ret0;
>// predicted unlikely by early return (on trees) predictor.
>return D.2725;
> }
>}
> }
>}
> }
>
> Where as D (and C) is more-or-less as you would expect:
>
> int fn (int a, int b, int c)
>
>
>
> {
>int D.7895;
>
>if (a != 0) goto ; else goto ;
>:
>if (b != 0) goto ; else goto ;
>:
>if (c != 0) goto ; else goto ;
>:
>D.7895 = a;
>// predicted unlikely by early return (on trees) predictor.
>return D.7895;
>:
>D.7895 = b * c;
>// predicted unlikely by early return (on trees) predictor.
>return D.7895;
> }
>
> Clearly the decision inference algorithm is unable to properly
> instrument to Go program for condition coverage because of the use of
> temporaries in the emitted GIMPLE. The question is: is this intentional
> and/or required from Go's semantics or could it be considered a defect?
> Is emitting the GIMPLE without the use of temporaries feasible at all?
The Go frontend converts && and || expressions into code that uses
explicit if statements. This is done largely as an internal
simplification. Go has rules about the order in which function calls
and certain other kinds of expressions must be evaluated. Separating
out the order of evaluation imposed by && and || simplifies the
implementation of the other order of evaluation rules.
Ian
Re: Checking for built-in functions from build systems
Thank you very much, Jonathan. That's very helpful!
This test program:
int main()
{
void *a = alloca(10);
return 0;
}
Compiles fine with:
gcc -o test test.c
But then fails with:
gcc -o test test.c -fno-builtin
That's on an Arch Linux system (based on glibc)
The issue is that what happens when built-ins are not inlined is not well
defined. The libc may not implement the routine, or it's not clear which
dependency should provide it.
Thanks,
Luca Bacci
Il giorno mer 10 ago 2022 alle ore 23:27 Jonathan Wakely <
jwakely@gmail.com> ha scritto:
>
>
> On Wed, 10 Aug 2022, 23:12 Luca Bacci via Gcc, wrote:
>
>>
>> 1. Is inlining of built-ins dependant only on the target architecture and
>> command-line arguments?
>>
>
> No, I think it can depend on the arguments to the built-in as well.
>
>
> 2. If the answer to 1 is yes, could a __is_builtin_inlined (func) macro be
>> added to GCC? It should tell whether func is going to be substituted
>> inline
>> for the given compiler invocation
>
>
> I don't think that can work for some built-ins, e.g. in a single
> translation unit memcmp can be inlined for constant arguments of small
> size, and not inlined for other calls.
>
>
>
>
Re: Resend: Potential upcoming changes in mangling to PowerPC GCC
Segher Boessenkool writes:
> You can write
> double convert (__ibm128 x) { return x; }
> double convert (__ieee128 x) { return x; }
> as well. "__ieee128" and "long double" are the same type then (and the
> same as _Float128 and __float128 as well).
Oh! I see. Thanks!
Going back to Mike's original question:
>> But in changing the mangling, we have the potential to create compatibility
>> issues, of code compiled with previous GCC's that use explicit __ibm128 and
>> __float128 keywords. I don't how the users of these keywords (i.e. typically
>> libstdc++ and glibc developers, but potentially others as well).
In glibc, we use __ibm128 only once in a place that always has to be
double-double regardless of the long double type.
Everywhere else, when a double-double type is expected, long double is used.
This is also how glibc users are expected to use double-double functions from
glibc.
Meanwhile, _Float128/_float128 is used everywhere along with long double,
regardless if long double is double-double or __float128.
With that said, glibc code was designed with this in mind (thanks Joseph!), but
AFAIK nobody ever tested building glibc for ppc64le with the proposal you have
here.
If this proposal is adopted, we'd need a way to distinguish between the previous
and the new behavior, i.e. a macro.
Anyway, I believe that a newer GCC will have trouble compiling on a
system with an older glibc.
An older glibc will also have trouble building with a newer GCC, but that might
be less important.
Likewise for libdfp.
--
Tulio Magno
Re: Checking for built-in functions from build systems
On Wed, 10 Aug 2022, 23:12 Luca Bacci via Gcc, wrote: > > 1. Is inlining of built-ins dependant only on the target architecture and > command-line arguments? > No, I think it can depend on the arguments to the built-in as well. 2. If the answer to 1 is yes, could a __is_builtin_inlined (func) macro be > added to GCC? It should tell whether func is going to be substituted inline > for the given compiler invocation I don't think that can work for some built-ins, e.g. in a single translation unit memcmp can be inlined for constant arguments of small size, and not inlined for other calls.
Checking for built-in functions from build systems
Hello dear GCC developers, I am working on an issue in Meson wrt GCC built-in functions, see https://github.com/mesonbuild/meson/issues/10641. As you already know, some built-ins are always inlined, while others are inlined only at times (e.g. depending on the target architecture) and resolve to a regular function call otherwise. The issue is about the latter's, i.e. those that may emit regular function calls. In fact, even though __has_builtin(func) evaluates to 1, func may not be present in libraries (libgcc, libc, libm), causing linking errors if not inlined. Because some of the GCC built-in functions are not part of the C standard (e.g. sincos), it's not worthwhile to require having implementations in libc. In addition, should generic implementations be added to libgcc, those would likely have sub-par performance or accuracy issues (being generic). As such, I think that a build system should check if an implementation of a conditionally-inlined built-in function is provided in the target libc. I have a few questions: 1. Is inlining of built-ins dependant only on the target architecture and command-line arguments? 2. If the answer to 1 is yes, could a __is_builtin_inlined (func) macro be added to GCC? It should tell whether func is going to be substituted inline for the given compiler invocation 3. Is it true that conditionally-inlined built-ins are exactly those that come in the two variants of '__builtin_func' and 'func'? Thanks, Luca Bacci
Re: Resend: Potential upcoming changes in mangling to PowerPC GCC
On Wed, Aug 10, 2022 at 04:55:42PM -0300, Tulio Magno Quites Machado Filho
wrote:
> Michael Meissner via Gcc writes:
> > Because long double mangles the same as either __float128 or __ibm128, you
> > cannot write programs like:
> >
> > double convert (__ibm128x) { return x; }
> > double convert (__float128 x) { return x; }
> > double convert (long double x) { return x; }
> >
> > You would have to write on a system with long double being IBM 128-bit:
> >
> > double convert (__float128 x) { return x; }
> > double convert (long double x) { return x; }
> >
> > or on a system with long double being IEEE 128-bit:
> >
> > double convert (__ibm128x) { return x; }
> > double convert (long double x) { return x; }
>
> Does that mean, when long double is IEEE 128-bit, the compiler won't support
> _Float128/__float128 ?
You can write
double convert (__ibm128 x) { return x; }
double convert (__ieee128 x) { return x; }
as well. "__ieee128" and "long double" are the same type then (and the
same as _Float128 and __float128 as well).
Segher
Re: Resend: Potential upcoming changes in mangling to PowerPC GCC
Michael Meissner via Gcc writes:
> Because long double mangles the same as either __float128 or __ibm128, you
> cannot write programs like:
>
> double convert (__ibm128x) { return x; }
> double convert (__float128 x) { return x; }
> double convert (long double x) { return x; }
>
> You would have to write on a system with long double being IBM 128-bit:
>
> double convert (__float128 x) { return x; }
> double convert (long double x) { return x; }
>
> or on a system with long double being IEEE 128-bit:
>
> double convert (__ibm128x) { return x; }
> double convert (long double x) { return x; }
Does that mean, when long double is IEEE 128-bit, the compiler won't support
_Float128/__float128 ?
--
Tulio Magno
Re: Resend: Potential upcoming changes in mangling to PowerPC GCC
On Mon, Aug 08, 2022 at 05:44:36PM -0400, Michael Meissner wrote: > On Thu, Aug 04, 2022 at 03:53:55PM -0500, Segher Boessenkool wrote: > > On Thu, Aug 04, 2022 at 01:48:51PM -0400, Michael Meissner wrote: > > It would be a lot simpler and less roundabout and inside out if we could > > do this the other way around: start with the QP float and double-double > > types and modes, and point the long double type and TFmode at that. But > > alas. > > Yes if we could go back 5 years it would have been simpler to do that way. It does not require time machines: we can change the current code *now*. > > > These 3 tests use the > > > 'nanqs' built-in function, which is mapped to 'nanf128s' and it delivers a > > > _Float128 signaling NaN. But since __float128 uses a different type, the > > > signaling NaN is converted and it loses the signaling property. > > > > So you are saying __float128 and _Float128 should *not* be separate > > types? Or, the testcases are buggy, make unwarranted assumptions? > > I am saying right now, they are separate types when -mabi=ieeelongdouble is > used. They are the same type when -mabi=ibmlongdouble is used. I think they > should be the same type, no matter which way long double is defined. Ah, good. > But there are a bunch of assumptions within the compiler that need to be > changed due to these assumptions. > > > In addition, it would be nice if we could refine the setting of bits in > > > the ELF > > > header so that if you pass an explicit __float128 or __ibm128 object, it > > > doesn't set the bits that you used long double of the appropriate type. > > > But > > > the code that sets these bits is done in the RTL stages, and it only > > > looks at > > > modes, not at types. > > > > So fix that? It is a clear bug. > > It isn't so simple, Yes it is. It *is* a clear bug. Solving it might be some work, but it has to be done, it can not be avoided. > > It cannot always use IFmode? Generic code uses TFmode for long double > > (which can be double-double). > > My point is __ibm128 can potentionally be separate and always use IFmode. > Hence my question. It cannot be. Generic code (on double-double configs) uses TFmode. It is a good idea for us to use IFmode in the backend code, certainly. Segher
Re: [RISC-V] [tech-toolchain] Fw: [RISCV] RISC-V GNU Toolchain Biweekly Sync-up call (Aug 11, 2022)
BEGIN:VCALENDAR PRODID:-//zoom.us//iCalendar Event//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:PUBLISH CLASS:PUBLIC BEGIN:VTIMEZONE TZID:Asia/Singapore LAST-MODIFIED:20220317T223602Z TZURL:http://tzurl.org/zoneinfo-outlook/Asia/Singapore X-LIC-LOCATION:Asia/Singapore BEGIN:STANDARD TZNAME:+08 TZOFFSETFROM:+0800 TZOFFSETTO:+0800 DTSTART:19700101T00 END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20220713T134316Z DTSTART;TZID=Asia/Singapore:20220714T23 DTEND;TZID=Asia/Singapore:20220715T00 SUMMARY:RISC-V GNU Toolchain Biweekly Sync-up RRULE:FREQ=WEEKLY;WKST=SU;UNTIL=20230323T16;INTERVAL=2;BYDAY=TH UID:ZOOM89393600951 TZID:Asia/Singapore DESCRIPTION:Wei Wu - PLCT Lab is inviting you to a scheduled Zoom meeting .\n\nJoin Zoom Meeting\nhttps://us02web.zoom.us/j/89393600951?pwd=ZFpWMk Z6Tm1TbUFXT1hZZjZZMHhRQT09\n\nMeeting ID: 893 9360 0951\nPasscode: 89966 2\nOne tap mobile\n+6531651065\,\,89393600951#\,\,\,\,*899662# Singapore \n+6531587288\,\,89393600951#\,\,\,\,*899662# Singapore\n\nDial by your location\n+65 3165 1065 Singapore\n+65 3158 7288 Singapo re\n+1 669 900 9128 US (San Jose)\n+1 669 444 9171 US\n +1 346 248 7799 US (Houston)\n+1 253 215 8782 US (Tacoma) \n+1 312 626 6799 US (Chicago)\n+1 646 558 8656 US (New York)\n+1 646 931 3860 US\n+1 301 715 8592 US (Washingto n DC)\nMeeting ID: 893 9360 0951\nPasscode: 899662\nFind your local numb er: https://us02web.zoom.us/u/kk9cyIPNJ\n\n LOCATION:https://us02web.zoom.us/j/89393600951?pwd=ZFpWMkZ6Tm1TbUFXT1hZZj ZZMHhRQT09 BEGIN:VALARM TRIGGER:-PT10M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR
[RISCV] RISC-V GNU Toolchain Biweekly Sync-up call (Aug 11, 2022)
Hi all, Here is the agenda for tomorrow's RISC-V GNU toolchain meeting. If you have any topics want to discuss or share, please let me know and I will add them to the agenda, thanks. Agenda: - Call for contributors/maintainers: riscv-gnu-toolchain repo - Unify interface to query supported option for extension https://github.com/riscv-non-isa/riscv-toolchain-conventions/issues/24 - RVV supports progress - Open topics Zbs build failure on RV32 Wei Wu - PLCT Lab is inviting you to a scheduled Zoom meeting. Topic: RISC-V GNU Toolchain Biweekly Sync-up Time: Aug 11, 2022 11:00 PM Singapore Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://calendar.google.com/calendar/ical/lm5bddk2krcmtv5iputjgqvoio%40group.calendar.google.com/public/basic.ics Join Zoom Meeting https://zoom.us/j/89393600951?pwd=ZFpWMkZ6Tm1TbUFXT1hZZjZZMHhRQT09 Meeting ID: 893 9360 0951 Passcode: 899662 BEIJING, China 11:00pThu, Aug 11 2022 12:00aFri, Aug 11 2022 PST/PDT, Pacific Standard Time (US) 8:00aThu, Aug 11 2022 9:00aThu, Aug 11 2022 PHILADELPHIA, United States, Pennsylvania 11:00aThu, Aug 11 2022 12:00aThu, Aug 11 2022 Paris, France 17:00pThu, Aug 11 2022 18:00pThu, Aug 11 2022BEGIN:VCALENDAR PRODID:-//zoom.us//iCalendar Event//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:PUBLISH CLASS:PUBLIC BEGIN:VTIMEZONE TZID:Asia/Singapore LAST-MODIFIED:20220317T223602Z TZURL:http://tzurl.org/zoneinfo-outlook/Asia/Singapore X-LIC-LOCATION:Asia/Singapore BEGIN:STANDARD TZNAME:+08 TZOFFSETFROM:+0800 TZOFFSETTO:+0800 DTSTART:19700101T00 END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20220713T141948Z DTSTART;TZID=Asia/Singapore:20220714T15 DTEND;TZID=Asia/Singapore:20220714T16 SUMMARY:RISC-V GNU å·¥å ·é¾åå¨åæ¥ä¼ï¼ä¸æï¼ RRULE:FREQ=WEEKLY;WKST=SU;UNTIL=20230323T08;INTERVAL=2;BYDAY=TH UID:ZOOM82424890125 TZID:Asia/Singapore DESCRIPTION:Wei Wu - PLCT Lab is inviting you to a scheduled Zoom meeting .\n\nJoin Zoom Meeting\nhttps://us02web.zoom.us/j/82424890125?pwd=SVpvYk p0ZlJ2aG5CTzNJeWU2Qzdvdz09\n\nMeeting ID: 824 2489 0125\nPasscode: 53310 0\nOne tap mobile\n+6531651065\,\,82424890125#\,\,\,\,*533100# Singapore \n+6531587288\,\,82424890125#\,\,\,\,*533100# Singapore\n\nDial by your location\n+65 3165 1065 Singapore\n+65 3158 7288 Singapo re\n+1 669 900 9128 US (San Jose)\n+1 669 444 9171 US\n +1 346 248 7799 US (Houston)\n+1 253 215 8782 US (Tacoma) \n+1 646 931 3860 US\n+1 301 715 8592 US (Washington DC) \n+1 312 626 6799 US (Chicago)\n+1 646 558 8656 US (New York)\nMeeting ID: 824 2489 0125\nPasscode: 533100\nFind your local numb er: https://us02web.zoom.us/u/kd9elwl9Jv\n\n LOCATION:https://us02web.zoom.us/j/82424890125?pwd=SVpvYkp0ZlJ2aG5CTzNJeW U2Qzdvdz09 BEGIN:VALARM TRIGGER:-PT10M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR
Re: gccgo emits GIMPLE with temporaries for boolean expressions unlike gcc, gdc
CCing Go maintainer.
Martin
On 8/3/22 15:25, j wrote:
>
> Hello,
>
> I've proposed a patch [1] for condition coverage profiling in gcc,
> implemented in the middle-end alongside the branch coverage. I've written
> most of the tests for C and a few for C++ and finally got around to try it
> with a toy example for D and go and noticed something odd about Go's CFG
> construction.
>
> abc.c:
> int fn (int a, int b, int c) {
> if (a && (b || c))
> return a;
> else
> return b * c;
> }
>
> abc.d:
> int fn (int a, int b, int c) {
> if (a && (b || c))
> return a;
> else
> return b * c;
> }
>
> abc.go:
> func fn (a int, b int, c int) int {
> a_ := a != 0;
> b_ := b != 0;
> c_ := c != 0;
>
> if a_ && (b_ || c_) {
> return 1;
> } else {
> return 0;
> }
> }
>
> All were built with gcc --coverage -fprofile-conditions (my patch, but it
> does not affect this) and no optimization. The C and D programs behaved as
> expected:
>
> gcov --conditions abc.d:
>
> 3: 3:int fn (int a, int b, int c) {
> 3*: 4: if (a && (b || c))
> conditions outcomes covered 3/6
> condition 1 not covered (false)
> condition 2 not covered (true)
> condition 2 not covered (false)
> 1: 5: return a;
> -: 6: else
> 2: 7: return b * c;
>
>
> gcov --conditions abc.go:
> 3: 5:func fn (a int, b int, c int) int {
> 3: 6: a_ := a != 0;
> 3: 7: b_ := b != 0;
> 3: 8: c_ := c != 0;
> -: 9:
> 3*: 10: if a_ && (b_ || c_) {
> condition outcomes covered 2/2
> condition outcomes covered 1/2
> condition 0 not covered (true)
> condition outcomes covered 2/2
> 1: 11: return 1;
> -: 12: } else {
> 2: 13: return 0;
> -: 14: }
> -: 15:}
>
> So I dumped the gimple gcc -fdump-tree-gimple abc.go:
>
> int main.fn (int a, int b, int c)
> {
> int D.2725;
> int $ret0;
>
> $ret0 = 0;
> {
> bool a_;
> bool b_;
> bool c_;
>
> a_ = a != 0;
> b_ = b != 0;
> c_ = c != 0;
> {
> {
> GOTMP.0 = a_;
> if (GOTMP.0 != 0) goto ; else goto ;
> :
> {
> {
> GOTMP.1 = b_;
> _1 = ~GOTMP.1;
> if (_1 != 0) goto ; else goto ;
> :
> {
> GOTMP.1 = c_;
> }
> :
> }
> GOTMP.2 = GOTMP.1;
> GOTMP.0 = GOTMP.2;
> }
> :
> }
> if (GOTMP.0 != 0) goto ; else goto ;
> :
>
>
> {
> {
> $ret0 = 1;
> D.2725 = $ret0;
> // predicted unlikely by early return (on trees) predictor.
> return D.2725;
> }
> }
> :
> {
> {
> $ret0 = 0;
> D.2725 = $ret0;
> // predicted unlikely by early return (on trees) predictor.
> return D.2725;
> }
> }
> }
> }
> }
>
> Where as D (and C) is more-or-less as you would expect:
>
> int fn (int a, int b, int c)
>
>
> {
> int D.7895;
>
> if (a != 0) goto ; else goto ;
> :
> if (b != 0) goto ; else goto ;
> :
> if (c != 0) goto ; else goto ;
> :
> D.7895 = a;
> // predicted unlikely by early return (on trees) predictor.
> return D.7895;
> :
> D.7895 = b * c;
> // predicted unlikely by early return (on trees) predictor.
> return D.7895;
> }
>
> Clearly the decision inference algorithm is unable to properly instrument to
> Go program for condition coverage because of the use of temporaries in the
> emitted GIMPLE. The question is: is this intentional and/or required from
> Go's semantics or could it be considered a defect? Is emitting the GIMPLE
> without the use of temporaries feasible at all?
>
> Thanks,
> Jørgen
>
> [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598165.html
