https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113900
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113902
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113898
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113902
--- Comment #3 from Richard Biener ---
*** Bug 113901 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113901
Richard Biener changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113902
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=113900
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-02-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113895
--- Comment #5 from Richard Biener ---
For the first testcase the issue is bitfields and 'off' being tracked in bytes.
ao_ref_init_from_vn_reference handles this by not using 'off'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113895
--- Comment #4 from Richard Biener ---
_1 = a[b.1_14][7];
we "correctly" resolve b.1_14 to 1 based on range info which is
[-INF,-1] [1, +INF]. The thing is, the get_ref_base_and_extent code
cannot do anything with this range but adjusting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113900
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113898
--- Comment #2 from Richard Biener ---
[local count: 101363582]:
# RANGE [irange] int [1, 2]
h_24 = 1;
ivtmp_25 = 1;
e[h_24][_9] = c.5_10;
so there's a missed CCP (this is late FRE). We massaged it to e[1][1] but
it should have been e[1][0]
||2024-02-13
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
Target Milestone|--- |14.0
--- Comment #1 from Richard Biener ---
Looking.
-bisection |
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Priority|P3 |P2
--- Comment #3 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113896
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #3 from Richard Biener ---
I will have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #39 from Richard Biener ---
(In reply to H.J. Lu from comment #32)
> (In reply to Michael Matz from comment #31)
> > (In reply to H.J. Lu from comment #30)
> > > (In reply to Michael Matz from comment #29)
> > > > It not only can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113847
Richard Biener changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113847
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113831
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=113734
--- Comment #21 from Richard Biener ---
loop->nb_iterations_upper_bound exactly is an upper bound on the number of
latch executions, so maybe I'm missing the point here. When we update it it as
well has to reflect an upper bound on that,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113847
--- Comment #3 from Richard Biener ---
I can't confirm a regression (testing r14-8925-g1e3f78dbb328a2 with the
offending rev reverted vs bare).
462.libquantum 20720 61.9335 S 20720 62.6331 *
462.libquantum 20720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #17 from Richard Biener ---
(In reply to Richard Biener from comment #16)
> I do wonder why __tls_get_addr would have to call the overloaded malloc, can
> we just not force-bind it to the glibc local malloc (and make sure that's
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #16 from Richard Biener ---
I do wonder why __tls_get_addr would have to call the overloaded malloc, can
we just not force-bind it to the glibc local malloc (and make sure that's
compiled with -mgeneral-regs-only)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
Richard Biener changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113863
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Last reconfirmed||2024-02-12
Ever confirmed|0 |1
--- Comment #2 from Richard Biener ---
I will try to investigate. Note this was a correctness fix, it could be
relaxed a tiny bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113882
Richard Biener changed:
What|Removed |Added
Blocks||53947
--- Comment #1 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113879
Richard Biener changed:
What|Removed |Added
Blocks||85316
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113878
--- Comment #9 from Richard Biener ---
I'd very much appreciate getting rid of TYPE_OVERFLOW_SANITIZED checks by doing
instrumentation in the frontends.
Note we do
#define TYPE_OVERFLOW_UNDEFINED(TYPE) \
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113871
Richard Biener changed:
What|Removed |Added
Target|x86_64 |x86_64-*-* i?86-*-*
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113867
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113863
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=113852
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108410
--- Comment #10 from Richard Biener ---
So this is now fixed if you use --param vect-partial-vector-usage=2, there is
at the moment no way to get masking/not masking costed against each other. In
theory vect_analyze_loop_costing and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108376
Richard Biener changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113499
--- Comment #3 from Richard Biener ---
(In reply to Richard Biener from comment #2)
> Re-confirmed. Can be reproduced both on a glibc 2.31 and glibc 2.38 system
> with
It does work with glibc 2.38, so only glibc 2.31 fails this (and possibly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113499
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-02-09
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113615
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113847
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113848
--- Comment #1 from Richard Biener ---
void * arithmetic is a GCC extension, I suggest to change that to char *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113849
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113831
--- Comment #5 from Richard Biener ---
So we have equal vn_reference but with different ao_ref. Note the recorded
vn_reference has value-numbers in operands (not sanitized via AVAIL to a
specific location) but the ao_ref is eventually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205
--- Comment #10 from Richard Biener ---
Btw, I was hoping Richard would chime in here ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113835
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-02-09
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113833
--- Comment #3 from Richard Biener ---
I suspect the issue would pop up with -Ofast -fno-vect-cost-model for any
sub-architecture. The patch referenced just adjusts costs for doing BB
vectorization (and there's reductions there as well). It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113831
Richard Biener changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113831
--- Comment #2 from Richard Biener ---
I think the issue is that we're using range info for get_ref_base_and_extent
but we fail to do so when valueizing refs.
at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Keywords||wrong-code
Target Milestone|--- |11.5
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113774
--- Comment #7 from Richard Biener ---
(In reply to Jakub Jelinek from comment #6)
> Thanks.
> The #c5 reduced testcase started to be miscompiled with
> r9-398-g6b9fc1782effc67dd9f6def16207653d79647553
> Perhaps we should move that to a
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
The following is miscompiled by FRE with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113774
--- Comment #5 from Richard Biener ---
This must go wrong during alias disambiguation, somehow figuring we can ignore
the backedge?! The ref we hoist is
_68 = VIEW_CONVERT_EXPR(b)[_146];
where _146 is _49 + 1, but _49 is an IV:
_134 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #11 from Richard Biener ---
(In reply to Tamar Christina from comment #10)
> (In reply to Richard Biener from comment #9)
> > Another bug in the dependence checking code is
> >
> > if (dr_may_alias_p (dr_ref,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #42 from Richard Biener ---
And the do_store_flag part:
diff --git a/gcc/expr.cc b/gcc/expr.cc
index fc5e998e329..44d64274071 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -13693,6 +13693,19 @@ do_store_flag (sepops ops, rtx
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
701 - 800 of 52878 matches
Mail list logo
