https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #15 from Richard Biener ---
(In reply to Sam James from comment #14)
> I tried 'if (candidate && candidate->src != EDGE_PRED (loop->latch,
> 0)->src)' as well given that seems way more sensible and that works too, but
> obviously if
Priority: P3
Component: rust
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org
Target Milestone: ---
With --disable-plugin we probably elide -ldl but crab1 calls dlopen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113479
Richard Biener changed:
What|Removed |Added
Component|c |tree-optimization
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113480
Richard Biener changed:
What|Removed |Added
Summary|[14 Regression] avr:|avr: internal compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113481
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113483
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: normal
Priority: P3
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
../configure --enable-languages=m2 --disable-plugin
will not build or install m2rte.so but the m2 driver will still attempt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113480
Richard Biener changed:
What|Removed |Added
Keywords||ice-checking
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
Richard Biener changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #11 from Richard Biener ---
if (candidate && candidate->src != EDGE_PRED (loop->latch, 0))
return NULL;
then ;)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113475
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113478
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Last reconfirmed||2024-01-18
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
I have a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #2 from Richard Biener ---
In fact it occurs elsewhere as well:
==1854== 81,616 bytes in 2 blocks are possibly lost in loss record 1,363 of
1,373
==1854==at 0x505A1DF: operator new[](unsigned long) (in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #1 from Richard Biener ---
Created attachment 57138
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57138=edit
testcase
For convenience here it is. I checked
valgrind --leak-check=full ./cc1 -quiet -O3 -march=znver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
Richard Biener changed:
What|Removed |Added
CC||amacleod at redhat dot com
Target
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
I see
==1854== 122,424 bytes in 3 blocks are possibly lost in loss record 1,365 of
1,373
==1854==at 0x505A1DF: operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113475
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
We allocate phi_group in gimple-range-phi.cc:460:
// Try to create a group based on m_current. If a result comes back
// with a range that isn't varying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113471
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #8 from Richard Biener ---
(In reply to Richard Biener from comment #7)
> Does the following fix the issue?
>
> diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
> index 330c4571c8d..b67ee783002 100644
> ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #7 from Richard Biener ---
I do wonder whether LOOP_VINFO_EARLY_BREAKS_VECT_PEELED actually works (since
without early exits we cannot handle a non-empty latch because of correctness
issues). I'd very much have preferred to deal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113459
Richard Biener changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113459
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=113458
--- Comment #4 from Richard Biener ---
(In reply to Hongtao Liu from comment #2)
> > But if we reduce n to 4, the loop based vectorizer is not able to handle it
> > either.
>
> Do we support 1 element vector(i.e V1SI) in vectorizer?
Yes, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113458
--- Comment #3 from Richard Biener ---
On x86_64 with -mavx2 we vectorize
t.c:7:13: note: Vectorizing SLP tree:
t.c:7:13: note: Root stmt: sum_26 = _20 + sum_25;
t.c:7:13: note: node 0x57386c0 (max_nunits=4, refcnt=1) vector(4) int
t.c:7:13:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113431
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113374
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113445
Richard Biener changed:
What|Removed |Added
Keywords||compare-debug-failure
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441
Richard Biener changed:
What|Removed |Added
Known to work||13.2.0
Known to fail|
||2024-01-17
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #1 from Richard Biener ---
Fixed by one of my pending changes, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113440
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113438
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-01-17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113437
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113431
--- Comment #14 from Richard Biener ---
So the issue is that we ignore the dependence because
vect_preserves_scalar_order_p - which is correct iff we'd execute the
stmt within the vectorized loop body. But as we discover it invariant
we hoist
||14.0
Priority|P1 |P2
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #6 from Richard Biener ---
Fixed by r14-5320-ge5f1956498251a4973d52c8aad3faf34d0443169, I'll take that for
backporting.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111554
Richard Biener changed:
What|Removed |Added
Target Milestone|12.4|14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113431
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=113431
--- Comment #12 from Richard Biener ---
(In reply to JuzheZhong from comment #11)
> I think this following:
>
> https://godbolt.org/z/5sWEWWGox
>
> ARM SVE GCC-11 correctly vectorize this codes.
>
> But both GCC-12 and GCC-13 failed to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111554
Richard Biener changed:
What|Removed |Added
Summary|[12/13/14 regression] |[12/13 regression] Timeout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113371
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113435
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113434
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113433
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113431
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113428
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113426
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113374
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=111956
--- Comment #17 from Richard Biener ---
Note that the default C long double is what is controlled by
--with-long-double-128 and --with-long-double-format, those configs do not tell
you
whether using __ieee128 with -mabi=ieeelongdouble will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113373
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=113371
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=113419
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
For example gcc.dg/tree-ssa/pr94969.c has
int a = 0, b = 0, c = 0;
struct S {
signed m : 7;
signed e : 2;
};
struct S f[2] = {{0, 0}, {0, 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113395
--- Comment #5 from Richard Biener ---
Without fully lowering this on GIMPLE we could substitute the representative
for the bitfield member in the MEM_EXPR and adjust adjust_address_1 to
instead of using attrs.size to constrain the extent of
||2024-01-16
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #1 from Richard Biener ---
For next stage1.
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
For pointer-to-integer conversions we need to know whether to sign- or
zero-extend. For the default address-space using ptr_mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113411
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113407
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113402
--- Comment #4 from Richard Biener ---
I'm OK with renaming (but then some namespace prefix would be nice, at least
two underscores, but __gcc_ might be better)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111956
--- Comment #15 from Richard Biener ---
(In reply to Gaius Mulley from comment #14)
> Ah apologies, is it best that I revert:
>
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;
> h=81d5ca0b9b8431f1bd7a5ec8a2c94f04bb0cf032
>
> happy to do this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113372
--- Comment #15 from Richard Biener ---
(In reply to Jakub Jelinek from comment #14)
> Created attachment 57085 [details]
> gcc14-pr113372.patch
>
> The non-propagation workaround which seems to fix^H^H^Hworkaround all those
> 4 issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113399
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113400
Richard Biener changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112580
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 112580, which changed state.
Bug 112580 Summary: [14 Regression]: g++.dg/modules/xtreme-header-4_b.C et al;
ICE tree check: expected class 'type', have 'declaration'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112580
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112419
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112103
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111850
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111811
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56
Richard Biener changed:
What|Removed |Added
Keywords||needs-bisection
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109705
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113372
--- Comment #11 from Richard Biener ---
So the key would be to make the object live again after a CLOBBER when such
address SSA name is used (but before any other explicit mention appears)?
The current algorithm relies on explitic mentions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113397
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113372
--- Comment #8 from Richard Biener ---
(In reply to Jakub Jelinek from comment #6)
> So, couldn't we attempt at least a partial workaround at add_scope_conflicts
> time?
> I mean, for SSA_NAME uses in statements with some caching try to check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113395
Richard Biener changed:
What|Removed |Added
Summary|RTL expansion drops |RTL expansion of bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113395
--- Comment #1 from Richard Biener ---
Because of
#0 adjust_address_1 (memref=0x771e8db0, mode=E_HImode, offset=...,
validate=1, adjust_address=1, adjust_object=1, size=...)
at /space/rguenther/src/gcc/gcc/emit-rtl.cc:2409
#1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113385
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
struct S {
signed m : 7;
signed e : 2;
} g;
void
k()
{
g.e ^= 1;
}
expands as
(insn 8 7 0 (parallel [
(set (mem/j/c:HI (reg/f:DI 100) [0 +0 S2 A32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113390
Richard Biener changed:
What|Removed |Added
Keywords||needs-bisection
Target
|P1
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #4 from Richard Biener ---
Confirmed. The ICE means that loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113384
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113380
--- Comment #1 from Richard Biener ---
Interesting - smells like fold-const.cc stuff not in match.pd.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113378
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113379
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113374
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #5 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113373
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113371
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #2 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113369
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113364
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113361
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
,
||rguenth at gcc dot gnu.org
Target||aarch64
--- Comment #8 from Richard Biener ---
All these might also point to IPA mod-ref issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113358
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
||rguenth at gcc dot gnu.org
Target||powerpc*-*-*
Summary|Many powerpc platforms do |[14 Regression] Many
|_not_ have support for |powerpc platforms do _not_
|IEEE754 long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113347
Richard Biener changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111267
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
---
||hubicka at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
--- Comment #4 from Richard Biener ---
Honza? Why do we consider to split before anotherfunc(5)? It's an odd
place since we'll always arrive there from the point we insert
1001 - 1100 of 52878 matches
Mail list logo
