The GCC 8 lambda overhaul fixed most uses of lambdas in pack expansions, but
local enums and classes within such lambdas that depend on parameter packs
are still broken. For now, give a sorry instead of an ICE or incorrect
error.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR
On 1/27/22 20:02, Marek Polacek wrote:
Here we ICE in unify_array_domain when we're trying to deduce the type
of an array, as in
auto(*p)[i] = (int(*)[i])0;
but unify_array_domain doesn't arbitrarily complex bounds. Another
test is, e.g.,
auto (*b)[0/0] =
where the type of the array
Here we ICE in unify_array_domain when we're trying to deduce the type
of an array, as in
auto(*p)[i] = (int(*)[i])0;
but unify_array_domain doesn't arbitrarily complex bounds. Another
test is, e.g.,
auto (*b)[0/0] =
where the type of the array is
<<< Unknown tree: template_type_parm
On 1/27/22 16:47, Andrew Pinski wrote:
On Wed, Dec 8, 2021 at 8:50 AM Martin Sebor via Gcc-patches
wrote:
Even with -Wno-system-headers enabled, the -Winvalid-memory-order
code tries to make sure calls to atomic functions with invalid
memory orders are diagnosed even though the C atomic
On Thu, Jan 27, 2022 at 02:55:08PM -0600, Paul A. Clarke wrote:
> Should we add similar compile-only tests for all of the standalone include
> files?
The only reason it wasn't detected earlier is that no one actually uses
this (and tests the development compiler). That is a much bigger
problem,
On Thu, Jan 27, 2022 at 3:47 PM Andrew Pinski wrote:
>
> On Wed, Dec 8, 2021 at 8:50 AM Martin Sebor via Gcc-patches
> wrote:
> >
> > Even with -Wno-system-headers enabled, the -Winvalid-memory-order
> > code tries to make sure calls to atomic functions with invalid
> > memory orders are
On Wed, Dec 8, 2021 at 8:50 AM Martin Sebor via Gcc-patches
wrote:
>
> Even with -Wno-system-headers enabled, the -Winvalid-memory-order
> code tries to make sure calls to atomic functions with invalid
> memory orders are diagnosed even though the C atomic functions
> are defined as macros in the
Tested powerpc64le-linux, pushed to trunk.
The compiler warns about the loop in deque::_M_range_initialize because
it doesn't know that the number of nodes has already been correctly
sized to match the size of the input. Use __builtin_unreachable to tell
it that the loop will never be entered if
When reviewing the output of -fanalyzer on PR analyzer/104224 I noticed
that despite very verbose paths, the diagnostic paths for
-Wanalyzer-use-of-uninitialized-value
don't show where the uninitialized memory is allocated.
This patch adapts and simplifies material from
"[PATCH 3/6] analyzer:
Tested powerpc64le-linux, pushed to trunk. Should be backported too.
When (bound - i) or n is the most negative value of its type, the
negative of the value will overflow. Instead of abs(n) >= abs(bound - i)
use n >= (bound - i) when positive and n <= (bound - i) when negative.
The function has
On 1/27/22 13:06, Patrick Palka wrote:
On Thu, 27 Jan 2022, Patrick Palka wrote:
When deducing the type of a variable template specialization with a
constrained auto type, we might need the template arguments for
satisfaction in case the constraint is dependent.
It looks like templated
LGTM, thanks for correcting this oversight in my patch.
On Thu, Jan 27, 2022 at 2:09 PM Maciej W. Rozycki wrote:
>
> Document new `auipc' and `bitmanip' `type' attributes added respectively
> with commit 88108b27dda9 ("RISC-V: Add sifive-7 pipeline description.")
> and commit 283b1707f237
Document new `auipc' and `bitmanip' `type' attributes added respectively
with commit 88108b27dda9 ("RISC-V: Add sifive-7 pipeline description.")
and commit 283b1707f237 ("RISC-V: Implement instruction patterns for ZBA
extension.") but not listed so far.
gcc/
*
A flaw in my patch for PR51344 was that cplus_decl_attributes calls
decl_attributes after save_template_attributes, which messes up the ordering
that save_template_attributes set up. Fixed by splitting
save_template_attributes around the call to decl_attributes.
Tested x86_64-pc-linux-gnu,
The v3 patch was posted at
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574847.html
There is no progress with repeated pings since then. Glibc 2.35 and
binutils 2.38 will support GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS.
I'd like to remove copy relocation to improve security and
Hi Uroš,
> Please note that check_effective_target_ia32 test tries to compile code that
> uses __i386__ target-dependent preprocessor definition, so it is guaranteed
> to fail on all non-ia32 targets.
Thanks, I didn’t know the difference!
OK to push.
FX
On Wed, Jan 26, 2022 at 03:50:35PM -0500, David Edelsohn via Gcc-patches wrote:
> On Wed, Jan 26, 2022 at 3:45 PM Jakub Jelinek wrote:
> > r12-4717-g7d37abedf58d66 added immintrin.h and x86gprintrin.h headers
> > to rs6000, these headers are on x86 standalone headers that various
> > programs
As stated in signaling_?.f90 tests, x86-32 ABI is not suitable to
correctly handle signaling NaNs. However, XFAIL is not the correct choice
to disable these tests, since various optimizations can generate code
that avoids moves from registers to memory (and back), resulting
in the code that
On Linux/x86_64,
76ef38e3178a11e76a66b4d4c0e10e85fe186a45 is the first bad commit
commit 76ef38e3178a11e76a66b4d4c0e10e85fe186a45
Author: Martin Liska
Date: Thu Jan 27 11:22:42 2022 +0100
Improve wording for -freport-bug option.
caused
FAIL: g++.dg/modules/xtreme-header-5_a.H module-cmi
On Thu, 27 Jan 2022, Richard Biener wrote:
> > > > Index: gcc/gcc/c/c-typeck.cc
> > > > ===
> > > > --- gcc.orig/gcc/c/c-typeck.cc
> > > > +++ gcc/gcc/c/c-typeck.cc
> > > > @@ -49,6 +49,7 @@ along with GCC; see the file COPYING3.
> >
The indiscriminate PHI handling by -Wuse-after-free has caused
the false positive reported in PR 104232. The attached patch
refines the handling to only consider PHIs all of whose operands
refer to the same object and disregard the rest.
Tested on x86_64-linux and by compiling a few toolchain
On Thu, Jan 27, 2022 at 07:29:20PM +0100, Martin Liška wrote:
> I would like to support:
>
> $ git gcc-undescr `git gcc-descr`
> 9cbfbe2497c0117b0598e35658248bc723c0b931
>
> Which is done in the patch.
>
> Ready to be installed?
> Thanks,
> Martin
>
> contrib/ChangeLog:
>
> *
I would like to support:
$ git gcc-undescr `git gcc-descr`
9cbfbe2497c0117b0598e35658248bc723c0b931
Which is done in the patch.
Ready to be installed?
Thanks,
Martin
contrib/ChangeLog:
* git-undescr.sh: Support full output of git-descr.sh.
---
contrib/git-undescr.sh | 4 ++--
1 file
On Thu, Jan 27, 2022 at 5:29 PM Kyrylo Tkachov via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> Hi Christophe,
>
> > -Original Message-
> > From: Gcc-patches > bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Christophe
> > Lyon via Gcc-patches
> > Sent: Thursday, January 13,
On Thu, 27 Jan 2022, Patrick Palka wrote:
> When deducing the type of a variable template specialization with a
> constrained auto type, we might need the template arguments for
> satisfaction in case the constraint is dependent.
It looks like templated static data members need similar
On 1/27/22 16:35, Jakub Jelinek wrote:
For backwards compatibility, I'd prefer --full to be an alias to --long,
and maybe the --short handling should short=yes; long=no and
similarly --long/--full handling should long=yes; short=no
so that --short --long is --long and --long --short is --short.
Hi!
On Thu, Jan 27, 2022 at 07:21:33PM +0800, Kewen.Lin wrote:
> PR target/103627
> * config/rs6000/rs6000.cc (rs6000_option_override_internal): Disable
> MMA if !TARGET_VSX.
>
> gcc/testsuite/ChangeLog:
>
> PR target/103627
> * gcc.target/powerpc/pr103627-1.c: New
When deducing the type of a variable template specialization with a
constrained auto type, we might need the template arguments for
satisfaction in case the constraint is dependent.
Bootstrapped and reegtested on x86_64-pc-linux-gnu, does this look OK
for trunk and perhaps 11?
PR
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Christophe
> Lyon via Gcc-patches
> Sent: Thursday, January 13, 2022 2:56 PM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH v3 13/15] arm: Convert more MVE/CDE builtins to predicate
>
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Christophe
> Lyon via Gcc-patches
> Sent: Thursday, January 13, 2022 2:56 PM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH v3 12/15] arm: Convert more load/store MVE builtins to
>
Hi Christophe,
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Christophe
> Lyon via Gcc-patches
> Sent: Thursday, January 13, 2022 2:56 PM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH v3 09/15] arm: Fix vcond_mask expander for MVE (PR
This patch adjusts the NVPTX low-latency allocator that I have
previously posted (awaiting re-review). The patch assumes that all my
previously posted patches are applied already.
Given that any memory allocated from the low-latency memory space cannot
support the "access=all" allocator trait
Hi Christophe,
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Christophe
> Lyon via Gcc-patches
> Sent: Thursday, January 13, 2022 2:56 PM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH v3 08/15] arm: Implement auto-vectorized MVE
>
Hi Christophe,
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Christophe
> Lyon via Gcc-patches
> Sent: Thursday, January 13, 2022 2:56 PM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH v3 07/15] arm: Implement MVE predicates as vectors
Excerpts from Martin Liška's message of Januar 27, 2022 1:40 pm:
> That's follow up patch based on the discussion with Jakub.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> * config/rs6000/host-darwin.cc (segv_crash_handler):
> Do not use leading capital
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Christophe
> Lyon via Gcc-patches
> Sent: Thursday, January 13, 2022 2:56 PM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH v3 04/15] arm: Add GENERAL_AND_VPR_REGS regclass
>
> At some
On Thu, 27 Jan 2022, 15:06 Martin Liška, wrote:
> Hello.
>
> I've finished Martin's work and put the 2 aliases into files. The
> git-undescr.sh is basically
> unchanged, while I added better option parsing for git-descr.sh script so
> that it supports:
>
> $ git gcc-descr
>
On Thu, Jan 27, 2022 at 04:06:05PM +0100, Martin Liška wrote:
> I've finished Martin's work and put the 2 aliases into files. The
> git-undescr.sh is basically
> unchanged, while I added better option parsing for git-descr.sh script so
> that it supports:
>
> $ git gcc-descr
>
On 1/26/22 12:49, Patrick Palka wrote:
In the nested_name_specifier branch within cp_parser_class_head, we need
to update TYPE with the result of maybe_process_partial_specialization
just like we do in the template_id_p branch.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
On 1/27/22 09:02, Patrick Palka wrote:
On Wed, 26 Jan 2022, Patrick Palka wrote:
On Wed, 26 Jan 2022, Patrick Palka wrote:
On Wed, Jan 19, 2022 at 2:19 PM Jason Merrill wrote:
On 1/19/22 11:15, Patrick Palka wrote:
Here we're emitting a bogus error during ahead of time evaluation of a
Hello.
I've finished Martin's work and put the 2 aliases into files. The
git-undescr.sh is basically
unchanged, while I added better option parsing for git-descr.sh script so that
it supports:
$ git gcc-descr
r12-6895-g14f339894db6ca
$ git gcc-descr HEAD~10
r12-6886-geaa59070343326
$ git
On 1/27/22 15:25, Jonathan Wakely wrote:
I have the same patch ready to push, but I'm away from the computer. Please
push.
;) I've just pushed that to master.
Martin
On Wed, 26 Jan 2022, 22:12 Jonathan Wakely via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> On Wed, 26 Jan 2022 at 22:08, Dimitar Dimitrov wrote:
> >
> > On Tue, Jan 25, 2022 at 09:09:51PM +, Jonathan Wakely via
> Gcc-patches wrote:
> > > Tested x86_64-linux, pushed to trunk. Backports to
On Thu, 27 Jan 2022, 13:49 Martin Liška, wrote:
> Hi.
>
> May I install an obvious typo that causes build error (described in the
> PR).
>
> Ready to be installed?
>
I have the same patch ready to push, but I'm away from the computer. Please
push.
Thanks,
> Martin
>
> PR
On Thu, Jan 27, 2022 at 2:59 PM Maciej W. Rozycki wrote:
>
> On Thu, 27 Jan 2022, Richard Biener wrote:
>
> > > Index: gcc/gcc/c/c-typeck.cc
> > > ===
> > > --- gcc.orig/gcc/c/c-typeck.cc
> > > +++ gcc/gcc/c/c-typeck.cc
> > > @@
On Wed, 26 Jan 2022, Patrick Palka wrote:
> On Wed, 26 Jan 2022, Patrick Palka wrote:
>
> > On Wed, Jan 19, 2022 at 2:19 PM Jason Merrill wrote:
> > >
> > > On 1/19/22 11:15, Patrick Palka wrote:
> > > > Here we're emitting a bogus error during ahead of time evaluation of a
> > > >
On Thu, 27 Jan 2022, Richard Biener wrote:
> > Index: gcc/gcc/c/c-typeck.cc
> > ===
> > --- gcc.orig/gcc/c/c-typeck.cc
> > +++ gcc/gcc/c/c-typeck.cc
> > @@ -49,6 +49,7 @@ along with GCC; see the file COPYING3.
> > #include
Hi.
May I install an obvious typo that causes build error (described in the PR).
Ready to be installed?
Thanks,
Martin
PR libstdc++/104259
libstdc++-v3/ChangeLog:
* acinclude.m4: Fix typo.
* configure: Regenerate.
---
libstdc++-v3/acinclude.m4 | 2 +-
On Thu, Jan 27, 2022 at 1:16 PM Maciej W. Rozycki wrote:
>
> Do not mark vector element broadcast resulting from OpenCL operations as
> having side effects for targets that have a suitable hardware operation,
> so that the `vec_duplicateM' standard RTL pattern can be directly used
> for them.
On Thu, Jan 27, 2022 at 07:24:53PM +0800, Kewen.Lin wrote:
> on 2022/1/27 上午1:57, Segher Boessenkool wrote:
> > I like your original patch better. But for stage 1, sorry.
>
> Thanks Segher! Is it ok to commit it then? Or I'll repost this once
> next stage1 starts.
Either is fine in this case.
> That's follow up patch based on the discussion with Jakub.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> * config/rs6000/host-darwin.cc (segv_crash_handler):
> Do not use leading capital letter.
> (segv_handler): Likewise.
> * ipa-sra.cc
That's follow up patch based on the discussion with Jakub.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
* config/rs6000/host-darwin.cc (segv_crash_handler):
Do not use leading capital letter.
(segv_handler): Likewise.
* ipa-sra.cc
Do not mark vector element broadcast resulting from OpenCL operations as
having side effects for targets that have a suitable hardware operation,
so that the `vec_duplicateM' standard RTL pattern can be directly used
for them. This does not happen currently, because any RTL pattern named
Le 23/01/2022 à 22:08, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
conversions between different character kinds using TRANSFER exhibit
inconsistencies that can occur between expr->representation.string
(which is char*) on the one hand, and expr->->value.character.string.
One issue
Hi Segher,
on 2022/1/27 上午6:42, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Dec 23, 2021 at 10:12:19AM +0800, Kewen.Lin wrote:
>> PR target/103627
>> * config/rs6000/rs6000.c (rs6000_option_override_internal): Move the
>> hunk affecting VSX and ALTIVEC to the appropriate place.
>>
On Thu, Jan 27, 2022 at 12:38:47PM +0100, Martin Liška wrote:
> Yep, we have many more examples where a leading capital letter is used:
>
> gcc/config/cris/cris.cc: internal_error ("MULT case in %");
> gcc/config/cris/cris.h: do { if (!(x)) internal_error ("CRIS-port assertion
> failed:
Le 26/01/2022 à 21:59, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
the use of -fdefault-integer-8 exhibits several cases where
we missed to convert the result of an intrinsic from the
declared to the effective resulting type.
The attached obvious patch fixes this for IMAGE_STATUS,
Pushed as obvious.
Martin
PR analyzer/104247
gcc/analyzer/ChangeLog:
* constraint-manager.cc (bounded_ranges_manager::log_stats):
Cast to long for format purpose.
* region-model-manager.cc (log_uniq_map): Likewise.
---
gcc/analyzer/constraint-manager.cc | 2
On 1/27/22 12:06, Jakub Jelinek wrote:
On Thu, Jan 27, 2022 at 11:59:51AM +0100, Martin Liška wrote:
@@ -1988,7 +1994,7 @@ error_recursion (diagnostic_context *context)
pp_newline_and_flush (context->printer);
fnotice (stderr,
- "Internal compiler error: Error reporting
Hi Segher,
on 2022/1/27 上午6:19, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Dec 23, 2021 at 10:09:27AM +0800, Kewen.Lin wrote:
>> As PR103627 shows, there is an unexpected case where !TARGET_VSX
>> and TARGET_MMA co-exist. As ISA3.1 claims, SIMD is a requirement
>> for MMA. By looking into the
on 2022/1/27 上午1:57, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Jan 26, 2022 at 10:26:45AM +0800, Kewen.Lin wrote:
>> on 2022/1/14 上午12:31, David Edelsohn wrote:
>> Yeah, but IMHO it still can confuse new comers at first glance.
>
> Yes, or at least cause to read (well, grep) the whole backend
Hi,
As PR103627 shows, there is an unexpected case where !TARGET_VSX
and TARGET_MMA co-exist. As ISA3.1 claims, SIMD is a requirement
for MMA. By looking into the ICE, I noticed that the current
MMA implementation depends on vector pairs load/store which use
VSX register, but we don't have a
on 2022/1/26 下午3:28, Richard Biener wrote:
> On Wed, Jan 26, 2022 at 3:15 AM Kewen.Lin via Gcc-patches
> wrote:
>>
>> Gentle ping:
>>
>> https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587309.html
>
> OK.
>
Thanks Richi! Rebased, re-tested and committed as r12-6891.
BR,
Kewen
>
On Thu, Jan 27, 2022 at 11:59:51AM +0100, Martin Liška wrote:
> @@ -1988,7 +1994,7 @@ error_recursion (diagnostic_context *context)
> pp_newline_and_flush (context->printer);
>
>fnotice (stderr,
> -"Internal compiler error: Error reporting routines re-entered.\n");
> +
On 1/27/22 11:47, Jakub Jelinek wrote:
On Thu, Jan 27, 2022 at 11:37:29AM +0100, Martin Liška wrote:
@@ -665,12 +667,12 @@ diagnostic_action_after_output (diagnostic_context
*context,
if (context->abort_on_error)
real_abort ();
- fnotice (stderr, "Please submit a full
On Thu, Jan 27, 2022 at 11:37:29AM +0100, Martin Liška wrote:
> @@ -665,12 +667,12 @@ diagnostic_action_after_output (diagnostic_context
> *context,
> if (context->abort_on_error)
> real_abort ();
> - fnotice (stderr, "Please submit a full bug report,\n"
> - "with
On Thu, Jan 27, 2022 at 04:00:01PM +0530, Siddhesh Poyarekar wrote:
> Signed-off-by: Siddhesh Poyarekar
> ---
> htdocs/gcc-12/changes.html | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
> index c69b301e..c6baee75 100644
> ---
Hi.
The patch addresses a few things related to ICE report:
- 'Internal compiler error: Error reporting routines re-entered.' - unify
'internal' wording
- I shortened:
'''
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any
From: Andrew Pinski
After the quoting changes in r12-6521-g03a1a86b5ee40d4e240,
branch-protection-attr.c
fails due to expecting a different quoting type for "leaf".
This patch changes the quoting from "" to '' as that is what is used now.
Committed as obvious after a test of the testcase.
Signed-off-by: Siddhesh Poyarekar
---
htdocs/gcc-12/changes.html | 2 ++
1 file changed, 2 insertions(+)
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index c69b301e..c6baee75 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -157,6 +157,8 @@ a
Hi Richard,
Sorry for the delay in getting back to this. I'm now working on a patch to
adjust this.
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, December 14, 2021 10:48 AM
> To: Kyrylo Tkachov via Gcc-patches
> Cc: Kyrylo Tkachov
> Subject: Re:
On Thu, Jan 20, 2022 at 11:27:20AM +, Richard Earnshaw via Gcc-patches
wrote:
> gcc/ChangeLog:
>
> * config/arm/arm.opt (mfix-cortex-a57-aes-1742098): New command-line
> option.
> (mfix-cortex-a72-aes-1655431): New option alias.
> --- a/gcc/config/arm/arm.opt
> +++
On Thu, 27 Jan 2022, Jiufu Guo wrote:
> Hi Richard,
>
> Richard Biener writes:
>
> > On Tue, 25 Jan 2022, Richard Biener wrote:
> >
> >> On Tue, 25 Jan 2022, Jiufu Guo wrote:
> >>
> ...
> >> > >
> >> > > The point is that we may not change the iteration number at which
> >> > > overflow occurs
On Thu, 27 Jan 2022, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, reassoc1 miscompiles following testcase.
> We have:
> if (a.1_1 >= 0)
> goto ; [59.00%]
> else
> goto ; [41.00%]
>
>[local count: 440234144]:
> _3 = -2147483647 - a.1_1;
> _9 = a.1_1 != -2147479551;
Hi Richard,
Richard Biener writes:
> On Tue, 25 Jan 2022, Richard Biener wrote:
>
>> On Tue, 25 Jan 2022, Jiufu Guo wrote:
>>
...
>> > >
>> > > The point is that we may not change the iteration number at which
>> > > overflow occurs since that alters the result of the < compare.
>> > > Only if
Hi!
As mentioned in the PR, reassoc1 miscompiles following testcase.
We have:
if (a.1_1 >= 0)
goto ; [59.00%]
else
goto ; [41.00%]
[local count: 440234144]:
_3 = -2147483647 - a.1_1;
_9 = a.1_1 != -2147479551;
_4 = _3 == 1;
_8 = _4 | _9;
if (_8 != 0)
goto ; [34.51%]
76 matches
Mail list logo
