https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88402
--- Comment #3 from Alexander Monakov ---
However, this may be worthwhile when one of operands is an immediate, as in
that case there's no register pressure increase, and the xor just mutates the
immediate.
Essentially, we'd change e.g.
(sign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88425
Bug ID: 88425
Summary: suboptimal code for a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88402
--- Comment #4 from Alexander Monakov ---
(In reply to Alexander Monakov from comment #3)
> But unfortunately today we don't manage to use the cmp-sbb trick for
> unsigned comparison against an immediate, i.e. for
>
> unsigned long baz (unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84345
--- Comment #6 from Alexander Monakov ---
I think gcc_qsort doesn't really change things here, validation failure implies
a logic issue in the comparator, so some step is not always working as the
author intended.
And even with gcc_qsort it's st
||2018-12-13
CC||amonakov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Alexander Monakov ---
Without -O, optimization passes are not enabled, even if individual -f options
are passed on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88481
--- Comment #5 from Alexander Monakov ---
The code shown in the opening comment looks fine to me, so please isolate the
issue further using debug counters.
Add -fdbg-cnt=if_conversion:99,if_after_combine:99 to -O1. This should lead to
broken cod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88481
--- Comment #6 from Alexander Monakov ---
And just to be sure, can you confirm that -fno-if-conversion changes program
behavior (the testcase is not executable so I cannot check), and the issue is
not about debug info quality (i.e. that single-st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88425
--- Comment #4 from Alexander Monakov ---
Thanks! Should this be closed as fixed now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88481
--- Comment #9 from Alexander Monakov ---
Thanks. I still don't see what's wrong. Are you testing only by single-stepping
in gdb, or does your program overall behave differently with/without
if-conversion?
In other words, do you see if-conversio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88568
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88593
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88593
--- Comment #4 from Alexander Monakov ---
It seems to avoid this sort of gotchas cleanup_cfg should
gcc_checking_assert (!dom_info_available_p (CDI_DOMINATORS));
gcc_checking_assert (!dom_info_available_p (CDI_POST_DOMINATORS));
but maybe t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88600
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88698
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028
Bug #: 56028
Summary: Splitting a 64-bit volatile store
Classification: Unclassified
Product: gcc
Version: 4.7.2
URL: http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00870.htm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56077
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56200
--- Comment #2 from Alexander Monakov 2013-02-04
21:36:38 UTC ---
(In reply to comment #1)
> What happens if you also use -fno-ivopts ?
For me, -fno-ivopts gives a small improvement, but still slower than -O0. I
think the slowdown is r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56200
Alexander Monakov changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56507
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39851
Alexander Monakov changed:
What|Removed |Added
CC||bratsinot at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53265
--- Comment #10 from Alexander Monakov 2013-03-11
16:15:36 UTC ---
(In reply to comment #8)
> Not sure about the warning wording
What about (... "iteration %E invokes undefined behavior", max)?
> plus no idea how to call the warning o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40735
--- Comment #18 from Alexander Monakov 2012-08-28
08:48:28 UTC ---
(In reply to comment #17)
>
> richi, can you share this maxmem2 script?
It's available on the wiki: http://gcc.gnu.org/wiki/PerformanceTesting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55081
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
||amonakov at gcc dot gnu.org
Resolution||INVALID
--- Comment #2 from Alexander Monakov 2012-11-06
15:05:40 UTC ---
The code invokes undefined behavior and is invalid: accessing d[++k] implies
that modified k is less than 16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55216
--- Comment #3 from Alexander Monakov 2012-11-06
15:06:50 UTC ---
> Enhancement request to produce a warning is filed as PR 52365.
Correction: PR 53265.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65753
--- Comment #1 from Alexander Monakov ---
Example testcase:
void *lookup_f(void);
void g()
{
void (*f)(void) = lookup_f();
f();
}
With -O2 -fPIC, on x86-64 GCC produces the desired tail call:
g:
subq$8, %rsp
calllookup_f@PL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65753
--- Comment #2 from Alexander Monakov ---
For a simpler testcase:
void g(void (*f)(void))
{
f();
}
gcc/cc1 -fPIC -O2 -m32:
g:
subl$12, %esp
call*16(%esp)
addl$12, %esp
ret
Here %ebx does not come into play at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65753
--- Comment #4 from Alexander Monakov ---
The check rejecting indirect calls was introduced with commit
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=069db0ae0a5b5b61d64731a94eea002fb3c9d901
(gcc-patches thread starting at
https://gcc.gnu.org/ml/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48302
Alexander Monakov changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48442
Alexander Monakov changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65753
--- Comment #5 from Alexander Monakov ---
Author: amonakov
Date: Mon May 11 16:10:24 2015
New Revision: 223005
URL: https://gcc.gnu.org/viewcvs?rev=223005&root=gcc&view=rev
Log:
PR target/65753
* config/i386/i386.c (ix86_function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65753
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
The following testcase:
int p(void) __attribute__((const));
void g(int);
void f()
{
for (;;)
g(p());
}
is optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66512
--- Comment #2 from Alexander Monakov ---
In that case I'd like to contribute a documentation patch to make that clear in
the pure/const attribute information, but I need more explanation. I see that
int p(void) __attribute__((const));
void f()
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-w64-mingw32
Created attachment 35846
--> https://gcc.gnu.org/bugzi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55237
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
The following simple loop is no longer optimized out with 4.8 and 4.9:
int main(int argc, char* argv[])
{
int i, a = 0;
for (i=0; i < 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57511
--- Comment #1 from Alexander Monakov ---
The loop invokes signed integer overflow, but changing 1 to 10 still keeps
the missed optimization there.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
CC: uros at gcc dot gnu.org
Regressed with r192589.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57736
--- Comment #1 from Alexander Monakov ---
Oops, submitted too soon.
echo 'f(){__builtin_ia32_rdtsc();}' | gcc -xc - -S -o-
: In function âfâ:
:1:25: internal compiler error: in emit_move_insn, at expr.c:3486
0x6d9c63 emit_move_insn(rtx_def*, rtx_
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Minimal testcase:
$ cat >test.c <
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703
--- Comment #10 from Alexander Monakov ---
Bug 64420, which was marked as a duplicate, presents an example where there's
no diagnostics at build time (linking succeeds), but the resulting code is
wrong and will fail at runtime.
I believe the cor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60086
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60086
--- Comment #9 from Alexander Monakov ---
By "good code" I was referring to the fact that your 4.7 asm does not contain
stack (%rbp) references in the vectorized loop.
Historically, first scheduling (-fschedule-insns) was problematic for 32-bit
x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36750
--- Comment #7 from Alexander Monakov ---
Nightstrike, is there a particular reason you want C++ warning behavior be
adjusted? Note that unlike C, in C++ you get zero-initialization by default,
so you don't need to write ' = {0};' to zero-initial
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36750
--- Comment #9 from Alexander Monakov ---
My statement about zero-initialization was inaccurate (thanks), but the general
point still stands: in C you have to write ' = {0}' since empty-braces
initializer is not supported by the language (you get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144
Alexander Monakov changed:
What|Removed |Added
Attachment #32830|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62011
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104631
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Created attachment 52933
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52933&action=edit
testcase
Hit
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-* i?86-*-*
Minimized from PR 105504.
Compile with -O2 -mtune=haswell -mavx (other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105504
--- Comment #5 from Alexander Monakov ---
The strange xmm0 spill issue may affect more code, so I reported an isolated
testcase: PR 105513 (regression vs. gcc-8, the complete testcase in this PR
also does not spill with gcc-8).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105513
--- Comment #7 from Alexander Monakov ---
The second sequence is 3 uops vs 1/2 (issued/executed) uops in first, and on
Haswell and Skylake it ties up port 5 for two cycles.
Unclear if you're microbenchmarking latency or throughput, but in any c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61810
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #18 from Alexander Monakov ---
>From my perspective, the main blocker for a nice and clean solution is lack of
"birth" statements on GIMPLE.
Without them, expansion to RTL would either need to insert initialization at
the top of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93934
--- Comment #14 from Alexander Monakov ---
Zoltan, excuse me, could you please clarify what specifically you are worried
about? Your bug title says "results in UB" and the opening comment said "the
behavior [..] is unpredictable", but as far as I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91972
--- Comment #7 from Alexander Monakov ---
As I understand, only the gcc subdirectory changed implementation language from
C to C++, so, yes (as far as this bug is concerned).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97127
--- Comment #16 from Alexander Monakov ---
Mostly because prior to register allocation the compiler does not naturally see
that x = *mem + a*b will need an extra mov when both 'a' and 'b' are live (as
in that case registers allocated for them can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97127
--- Comment #17 from Alexander Monakov ---
To me this suggests that in fact it's okay to carry the combined form in RTL up
to register allocation, but RA should decompose it to load+fma instead of
inserting a register copy that preserves the live
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97194
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97194
--- Comment #9 from Alexander Monakov ---
(In reply to Richard Biener from comment #8)
> Note that currently RTL expansion forces a local vector typed variable
> to the stack (instead of allocating a pseudo) when there are
> variable-index access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97194
--- Comment #11 from Alexander Monakov ---
Yeah, for inserts such tactic would be inappropriate due to bad store
forwarding stalls anyway. As you've shown in earlier comments, inserts have a
very nice generic way to expand them (that does not tou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97194
--- Comment #14 from Alexander Monakov ---
I see, there are more weaknesses than I thought. For CSE (or rather fwprop?) I
was thinking about a simpler case where the extracted-from value is loaded from
memory, but even in trivial cases RTL optimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97291
--- Comment #1 from Alexander Monakov ---
Reshuffling statements and piling up extra abstraction doesn't help solve the
core issue that GIMPLE passes can duplicate any basic block, but basic blocks
of SIMT loop epilogue should be protected from t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189
Alexander Monakov changed:
What|Removed |Added
Known to fail||9.3.0
Known to work|9.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97203
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97366
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97203
--- Comment #8 from Alexander Monakov ---
No, -msoft-stack-reserve-local is really meant to be in bytes: it may not
exceed the amount of .local memory reserved by CUDA driver (which is just 1-2
KB, unless overridden via cuCtxSetLimit, which nvptx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97366
--- Comment #5 from Alexander Monakov ---
afaict LRA is just following IRA decisions, and IRA allocates that pseudo to
memory due to costs.
Not sure where strange cost is coming from, but it depends on x86 tuning
options: with -mtune=skylake we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97203
--- Comment #11 from Alexander Monakov ---
Yes, that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97734
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86096
--- Comment #8 from Alexander Monakov ---
It was fixed on the trunk only, so as the title says it remains an issue on the
gcc-8 branch (which is still open). Bugzilla doesn't have separate resolutions
for different branches, we cannot have this "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99462
--- Comment #3 from Alexander Monakov ---
(for context, the above patch was for PR 98856, but it's based on incorrect
latency analysis, see bug 98856 comment #38 )
Right now schedulers cannot easily split instructions for that purpose, it
would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99469
Alexander Monakov changed:
What|Removed |Added
Blocks||82407
--- Comment #2 from Alexander
-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Thread-local variables with hidden visibility don't need to use the
"general-dy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99582
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #30 from Alexander Monakov ---
Asm operand binding should work by looking at bound lvalue: "c"(a) binds an
lvalue so if 'a' is a register var the compiler must remember its associated
register; "c"(a+0) binds an rvalue, so what kind o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98226
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98258
--- Comment #5 from Alexander Monakov ---
One possible solution is -foffload=-fno-openmp
Another possible solution is separate compilation and linking, with only
OpenACC enabled at link step (needs explicit -lgomp):
gfortran -fopenmp -fopenacc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98258
--- Comment #8 from Alexander Monakov ---
(In reply to Chinoune from comment #7)
> $ gfortran-10 -O3 -fopenmp -fopenacc -c bug_omp_acc.f90
> $ gfortran-10 bug_omp_acc.o -lgomp -o test.x
Contrary to my suggestion, you have omitted -fopenacc from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98258
--- Comment #10 from Alexander Monakov ---
Thanks for checking. As for this:
> Please, stop suggesting untested workarounds.
Yes, I should have mentioned those are untested. I was typing the response late
at night without access to offloading-c
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Created attachment 50097
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50097&action=edit
testcase
The a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98906
--- Comment #6 from Alexander Monakov ---
Ah, -fsanitize=float-cast-overflow catches it, but it needs to be enabled
explicitly (not implied by -fsanitize=undefined). Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86948
--- Comment #8 from Alexander Monakov ---
How does your patch expand 64-bit highpart multiply (i.e. with 128-bit full
product) on 32-bit targets?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95558
--- Comment #10 from Alexander Monakov ---
As comment #5 mentioned, it is still broken, you just need -fno-inline in
addition to -O2 for the original testcase. Andrew's remark is quite useful for
situations like this, you know :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
--- Comment #7 from Alexander Monakov ---
Lawrence, thank you for the nice work reducing the testcase. For RawTherapee
the recommended course of action would be to compile everything with
-ffp-contract=off, then manually reintroduce use of fma i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106952
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
--- Comment #11 from Alexander Monakov ---
Can we move -ffp-contract=fast under the -ffast-math umbrella and default to
-ffp-contract=on/off?
Isn't it easy now to implement -ffp-contract=on by a GENERIC-only match.pd
rule?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
--- Comment #13 from Alexander Monakov ---
(In reply to Richard Biener from comment #12)
> > Isn't it easy now to implement -ffp-contract=on by a GENERIC-only match.pd
> > rule?
>
> You mean in the frontend only for -ffp-contract=on?
Yes.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
--- Comment #5 from Alexander Monakov ---
(In reply to Jiri Slaby from comment #4)
> > I am surprised that "flatten" blows up on this function. Is that with any
> > config, or again some specific settings like gcov? Is there an existing lkml
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
--- Comment #7 from Alexander Monakov ---
I wanted to understand what gets exposed in LTO mode that causes a blowup.
I'd say flatten is not appropriate for this function (I don't think you want to
force inlining of memset or _find_next_bit?), s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
--- Comment #15 from Alexander Monakov ---
(In reply to Richard Biener from comment #14)
> I can't
> seem to reproduce any vectorization for your smaller example though.
My small C samples omit some detail as they were meant to illustrate what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
--- Comment #17 from Alexander Monakov ---
(In reply to Richard Biener from comment #16)
> I do think that since the only way to
> preserve expression boundaries is by PAREN_EXPR
Yes, but...
> that the middle-end
> shouldn't care about FAST v
701 - 800 of 1080 matches
Mail list logo
