https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113705
Richard Biener changed:
What|Removed |Added
CC||sayle at gcc dot gnu.org
Target
||rguenth at gcc dot gnu.org
--- Comment #1 from Richard Biener ---
I think the point is we fail to represent
Analyzing # of iterations of loop 1
exit condition [i_5(D) + 1, + , 1] < n_11(D)
bounds on difference of bases: -18446744073709551615 ... 18446744073709551
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113255
--- Comment #16 from Richard Biener ---
The "interesting" part is that the i386 + simplify_rtx parts fix the issue but
if you add the alias.cc part ontop it again fails at -O1 (the alias.cc part
alone also "fixes" it). This all of course shows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113255
--- Comment #15 from Richard Biener ---
The issue is also that via CSELIB we go from the good
(minus:DI (reg/f:DI 119)
(reg:DI 115))
to
(minus:DI (value:DI 11:11 @0x41fca00/0x41ec410)
(value:DI 10:15448 @0x41fc9e8/0x41ec3e0))
and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113701
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113693
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
Richard Biener changed:
What|Removed |Added
CC||ams at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #32 from Richard Biener ---
Btw, AVX512 knotb will invert all 8 bits and there's no knot just affecting
the lowest 4 or 2 bits.
It all feels like desaster waiting to happen ;)
For example BIT_NOT_EXPR is RTL expanded like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113694
--- Comment #1 from Richard Biener ---
You could provide an alias to __stack_chk_guard/__stack_chk_fail in your code
though.
|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #2 from Richard Biener ---
We have
[local count: 955630224]:
# _236 = PHI <_101(11)>
_110 = .UADDC (prephitmp_250, 0, _101);
and _101 is defined in the loop just exited. This is broken by
#0 set_ssa_use_from_pt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113692
--- Comment #3 from Richard Biener ---
integer to pointer conversions are not constrained in GIMPLE, only
pointer-to-int widening conversions are.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113690
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113687
Richard Biener changed:
What|Removed |Added
Blocks||56456
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113685
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-02-01
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113684
--- Comment #3 from Richard Biener ---
I'm usually having cross assembler/linker around as they are easy to build.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110176
Richard Biener changed:
What|Removed |Added
Known to work||14.0
Summary|[11/12/13/14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113641
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113546
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113611
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113542
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110390
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105275
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92444
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113681
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113681
Richard Biener changed:
What|Removed |Added
Keywords||error-recovery
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113682
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110176
--- Comment #9 from Richard Biener ---
With all VARYING we simplify
i_19 = (int) _2;
_6 = (int) _5;
Value numbering stmt = _7 = _6 <= i_19;
Applying pattern match.pd:6775, gimple-match-4.cc:1795
Match-and-simplified _6 <= i_19 to 1
where _5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111444
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113680
Richard Biener changed:
What|Removed |Added
Component|rtl-optimization|middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113134
--- Comment #20 from Richard Biener ---
I think we want split_loop () handle this case. That means extending it to
handle loops with multiple exits. OTOH after loop rotation to
if (i_21 == 1001)
goto ; [1.00%]
else
goto ;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113630
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Summary|[11/12/13/14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111444
--- Comment #10 from Richard Biener ---
Hmm, I have another fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111444
--- Comment #9 from Richard Biener ---
(In reply to Richard Biener from comment #8)
> The best fix would likely be to pre-insert all the IPA-CP known constants
> instead of trying to discover them "late".
>
> I'm testing the easy fix for now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111444
--- Comment #8 from Richard Biener ---
OK, so the issue is that we're recording the IPA result with the wrong VUSE
since we're calling vn_reference_lookup_2 with !data->last_vuse_ptr but
data->finish (vr->set, vr->base_set, v) inserts a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113670
Richard Biener changed:
What|Removed |Added
Known to fail|14.0|
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113678
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-01-31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113677
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-01-31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113676
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
Summary|[11/12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113674
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113673
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #2 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113672
Richard Biener changed:
What|Removed |Added
Keywords||testsuite-fail
Target Milestone|---
|ASSIGNED
Last reconfirmed||2024-01-31
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #3 from Richard Biener ---
I'll hunt it down.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113669
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-01-31
||rguenth at gcc dot gnu.org
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113667
Richard Biener changed:
What|Removed |Added
Keywords||ABI
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395
--- Comment #13 from Richard Biener ---
(In reply to JuzheZhong from comment #12)
> OK. It seems it has data dependency issue:
>
> missed: not vectorized, possible dependence between data-refs a[i_15] and
> a[_4]
>
> a[i_15] = _3; STMT 1
>
|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #7 from Richard Biener ---
I will have a look then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113665
--- Comment #9 from Richard Biener ---
(In reply to Jan Hubicka from comment #8)
> > Honza - ICF seems to fixup points-to sets when merging variables, so there
> > should be a way to kill off flow-sensitive info inside prevailing bodies
> > as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395
--- Comment #9 from Richard Biener ---
(In reply to JuzheZhong from comment #8)
> Hi, Richard.
>
> Now, I find the time to GCC vectorization optimization.
>
> I find this case:
>
> _2 = a[_1];
> ...
> a[i_16] = _4;
> ,,,
> _7 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113659
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059
--- Comment #21 from Richard Biener ---
(In reply to Jakub Jelinek from comment #19)
> Created attachment 57258 [details]
> gcc14-pr113059.patch
>
> So in patch form like this. Untested so far.
LGTM.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059
--- Comment #17 from Richard Biener ---
(In reply to Jakub Jelinek from comment #16)
> The question is revert what exactly?
> If we revert r14-6210, we get back the other P1. Or do you mean revert
> r14-5355?
> I guess another option is move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #29 from Richard Biener ---
(In reply to Hongtao Liu from comment #28)
> I saw we already maskoff integral modes for vector mask in store_constructor
>
> /* Use sign-extension for uniform boolean vectors with
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113659
--- Comment #3 from Richard Biener ---
So the issue is similar to gcc.c-torture/execute/20150611-1.c, this time
the main exit ends in a path without a virtual use (__builtin_unreachable ()).
We can do the same as we do for the alternate exits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #27 from Richard Biener ---
(In reply to Hongtao Liu from comment #25)
> (In reply to Tamar Christina from comment #24)
> > Just to avoid confusion, are you still working on this one Richi?
>
> I'm working on a patch to add a
,
||rguenth at gcc dot gnu.org
Priority|P3 |P2
--- Comment #6 from Richard Biener ---
Honza - ICF seems to fixup points-to sets when merging variables, so there
should be a way to kill off flow-sensitive info inside prevailing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113665
--- Comment #5 from Richard Biener ---
Well, ICF figures out the other part of the partial inlined test() are equal
and I think they are. The
if (i >= S){
return false;
}
tests are inlined and eliminated (I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113664
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-01-30
|1
Last reconfirmed||2024-01-30
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113659
--- Comment #1 from Richard Biener ---
I will have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113562
--- Comment #4 from Richard Biener ---
(In reply to Richard Biener from comment #3)
> Just to put it somewhere I ran dwlocstat on cc1plus before/after the
> offending change and it looks almost the same. We go from
>
> cov%samples cumul
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113562
--- Comment #3 from Richard Biener ---
Just to put it somewhere I ran dwlocstat on cc1plus before/after the offending
change and it looks almost the same. We go from
cov%samples cumul
0..10 1280217/38% 1280217/38%
11..20 55668/1%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
Richard Biener changed:
What|Removed |Added
Attachment #57214|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113622
Richard Biener changed:
What|Removed |Added
Known to work||14.0
Summary|[11/12/13/14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
Richard Biener changed:
What|Removed |Added
Target||powerpc
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113651
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113650
--- Comment #1 from Richard Biener ---
I don't think these are supposed to be used by the user ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113622
--- Comment #16 from Richard Biener ---
typedef double __attribute__ ((vector_size (16))) vec;
void
test (void)
{
register vec a asm("xmm1"), b asm("xmm2"), c asm("xmm3");
for (int i = 0; i < 2; i++)
c[i] = a[i] < b[i] ? 0.1 : 0.2;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113622
--- Comment #15 from Richard Biener ---
(In reply to Jakub Jelinek from comment #11)
> I think it is most important we don't ICE and generate correct code. I
> doubt this is used too much in real-world code, otherwise it would have been
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113622
--- Comment #10 from Richard Biener ---
(In reply to Jakub Jelinek from comment #8)
> Guess for an rvalue (if even that crashes) we want to expand it to some
> permutation or whole vector shift which moves the indexed elements first and
> then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113646
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113631
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-01-29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113644
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #5 from Richard Biener ---
(In reply to Andrew Pinski from comment #2)
> Confirmed.
>
> I really think what PRE does is correct here since we have an aliasing set
> of 0 for both. Now what is incorrect is hoist_ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113630
--- Comment #4 from Richard Biener ---
(In reply to Andrew Pinski from comment #3)
> Note LLVM produces decent code here by only using one load:
> ```
> xor eax, eax
> testesi, esi
> seteal
> mov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113625
--- Comment #1 from Richard Biener ---
Other targets (x86_64) default to -mtune=generic. Maybe configure time
selection somehow interferes with this on aarch64?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113622
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113618
--- Comment #2 from Richard Biener ---
It might be good to recognize this pattern in strlenopt or a related pass.
A purely local transform would turn it into
memcpy (temp, a, 64);
memmove (b, a, 64);
relying on DSE to eliminate the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103047
Richard Biener changed:
What|Removed |Added
Known to work||14.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29461
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27672
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26827
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-01-26
CC|
||2024-01-26
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Known to fail||13.2.1
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Richard Biener ---
Confirmed, still happens. But maybe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19954
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14169
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2005-12-28 06:11:40 |2024-1-26
--- Comment #2 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539
--- Comment #8 from Richard Biener ---
Does this still happen after r14-8413-g578c7b91f418eb?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #22 from Richard Biener ---
Is this fixed meanwhile?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85800
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
I'm seeing a lot of ICEs like this when running libgomp testsuite with
offloading for gfx1030.
/space/rguenther/src/gcc-autopar_devel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113602
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113612
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #2 from Richard Biener ---
(gdb) p tem.last ()
$2 = (vn_reference_op_struct &) @0x7fffc820: {opcode = VAR_DECL,
clique = 0, base = 0, reverse = 0, align = 0, off = {coeffs = {-1}},
type = , op0 = ,
op1 = , op2 = }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113600
--- Comment #3 from Richard Biener ---
I'll note that esp. two-lane reductions (or in general two-lane BB
vectorization) is hardly profitable on modern x86 uarchs unless the vectorized
code is interleaved with other non-vectorized code that can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113596
--- Comment #10 from Richard Biener ---
(In reply to Jakub Jelinek from comment #9)
> Created attachment 57215 [details]
> gcc14-pr113596.patch
>
> Untested patch to do that.
> The disadvantage of doing that is that it may penalize inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #12 from Richard Biener ---
Created attachment 57214
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57214=edit
prototype fix
The attached prototype fixes the testcase for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #11 from Richard Biener ---
In DSE the only differences is
fbt (0x751a1a50: (plus:DI (reg/v/f:DI 117 [ u ])
-(reg:DI 146 [ _44 ]))) == (address 0)
+(reg:DI 146 [ _44 ]))) == (nil)
fbt (0x7700b3c0: (reg/f:DI 64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113575
--- Comment #13 from Richard Biener ---
(In reply to Robin Dapp from comment #12)
> Created attachment 57209 [details]
> Tentative
>
> I tested the attached "fix". On my machine with 13.2 host compiler it
> reduced the build time for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #10 from Richard Biener ---
Created attachment 57212
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57212=edit
patch for debugging
Btw, I've used the attached to investigate other issues with the change. It
will show the
801 - 900 of 52871 matches
Mail list logo
