https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #41 from Richard Biener ---
(In reply to Hongtao Liu from comment #38)
> > I think we should also mask off the upper bits of variable mask?
> >
> > notl%esi
> > orl %esi, %edi
> > notl%edi
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113811
--- Comment #1 from Richard Biener ---
In case __n is the minimum signed integer and __k is -1 the division would also
trap ;) So yes, they should be unsigned.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #36 from Richard Biener ---
For example with AVX512VL and the following, using -O -fgimple -mavx512vl
we get simply
notl%esi
orl %esi, %edi
cmpb$15, %dil
je .L6
typedef long v4si
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113796
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113808
--- Comment #8 from Richard Biener ---
It's surely a bug in the vectorizer early exit handling. I just don't know
what exactly is wrong right now ;)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113808
--- Comment #6 from Richard Biener ---
With the following I don't see things going wrong, but we end up with the loop
having the STOP exit last instead and thus a PEELED case.
function bar (n) result (k)
integer :: n, k
!$omp simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113808
--- Comment #5 from Richard Biener ---
(In reply to Jakub Jelinek from comment #3)
> Started with r14-8768-g85094e2aa6dba7908f053046f02dd443e8f65d72
> The regression status is unclear because we emitted sorry on this
> before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113808
--- Comment #4 from Richard Biener ---
Reduced a bit, w/o collapse:
program main
integer :: n, i,k
n = 11
do i = 1, n,2
!$omp simd lastprivate(k)
do k = 1, i + 41
if (k > 11 + 41 .or. k < 1) error stop
end do
end do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113808
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
The following reduced testcase from libgomp.fortran/non-rectangular-loop-1.f90
fails execution:
program main
integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113803
--- Comment #4 from Richard Biener ---
The return address should be still on the stack for most archs, unless we run
into zero by "overflowing" the IP, of course.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113796
--- Comment #7 from Richard Biener ---
We're removing flow-sensitive info in combine_blocks, but after inserting
and folding stmts comprising the PHI replacements. There's possibly
latent issues when building up the predicates themselves since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113801
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111478
--- Comment #9 from Richard Biener ---
(In reply to Saurabh Jha from comment #8)
> Hi Richard,
>
> Are you also planning to backport it to gcc-12?
Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #9 from Richard Biener ---
Another bug in the dependence checking code is
if (dr_may_alias_p (dr_ref, dr_read, loop_nest))
which will end up using TBAA - dr_may_alias_p doesn't think you are ever
going to move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #8 from Richard Biener ---
(In reply to Tamar Christina from comment #6)
> The reason for the miscompile popping up is this change from the previous
> patch
>
> diff --git a/gcc/tree-vect-data-refs.cc b/gcc/tree-vect-data-refs.cc
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113796
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=113790
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #11 from Richard Biener ---
Btw, there's related IPA modref wrong-code issues where IPA and late summaries
are merged incorrectly (also receiving no attention)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
Richard Biener changed:
What|Removed |Added
Target||aarch64
--- Comment #10 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #7 from Richard Biener ---
(In reply to Tamar Christina from comment #6)
> The reason for the miscompile popping up is this change from the previous
> patch
>
> diff --git a/gcc/tree-vect-data-refs.cc b/gcc/tree-vect-data-refs.cc
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111478
Richard Biener changed:
What|Removed |Added
Summary|[12/13 Regression] aarch64 |[12 Regression] aarch64 SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 112618, which changed state.
Bug 112618 Summary: [13 Regression] internal compiler error: in
expand_MASK_CALL, at internal-fn.cc:4529
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112618
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112618
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110243
--- Comment #16 from Richard Biener ---
Backporting to GCC 13 causes gcc.dg/tree-ssa/ldist-17.c to FAIL.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113779
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113703
--- Comment #5 from Richard Biener ---
It's going wrong in iv_elimination_compare_lt which tries to exactly handle
this kind of loop:
We aim to handle the following situation:
sometype *base, *p;
int a, b, i;
i = a;
p = p_0 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 109559, which changed state.
Bug 109559 Summary: [12/13/14 Regression] Unexpected -Wmaybe-uninitialized
warning when inlining with system header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109559
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109559
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113765
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #10 from Richard Biener ---
I see the 'pair' type is marked TYPE_CXX_ODR_P, I'd say you should see a
ODR type violation diagnostic, and if you don't, this means we force different
alias sets for both? Not sure - Honza added this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113779
--- Comment #2 from Richard Biener ---
I don't think IVOPTs would use postinc for the intermediate increments. It's
constant propagation/forwarding that accumulates the increments to a constant
offset which removes dependences on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113775
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113765
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109559
--- Comment #8 from Richard Biener ---
Created attachment 57325
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57325=edit
patch
Patch. Breaks expected diagnostics for inlines from system headers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109559
--- Comment #7 from Richard Biener ---
So the 2nd hunk tests OK but the first for example runs into
FAIL: gcc.dg/Wfree-nonheap-object-4.c (test for warnings, line 19)
where we explicitly seem to expect the warning when the system header code
||msebor at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #6 from Richard Biener ---
Note the diagnostic is "valid" and for
FilonIntegral::integrate ()
function_base::has_trivial_copy_and_destroy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113707
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113703
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
|1
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Last reconfirmed||2024-02-05
Status|UNCONFIRMED |ASSIGNED
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
There's not much documentation on what part of a tcc_reference chain
(handled_component_p + base) needs to reflect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113736
--- Comment #4 from Richard Biener ---
(In reply to rguent...@suse.de from comment #3)
> On Sat, 3 Feb 2024, jakub at gcc dot gnu.org wrote:
> > Bitint lowering changes here
> > MEM < _BitInt(768)> [( struct T
> > *)p_2(D)] =
> > s_4(D);
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113756
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113749
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113746
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113707
Richard Biener changed:
What|Removed |Added
CC||shaohua.li at inf dot ethz.ch
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113725
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113707
--- Comment #4 from Richard Biener ---
It shows two issues. One we do too many LC-SSA preserving avails, the other
that eliminate_avail can result in different answers for the same name
dependent on later avails - that's of course not OK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113712
Richard Biener changed:
What|Removed |Added
Blocks||26163
Priority|P3
|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #3 from Richard Biener ---
Mine.
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.
1201 - 1300 of 53323 matches
Mail list logo
