https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115432
Richard Biener changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115432
--- Comment #1 from Richard Biener ---
In case output_stream is not the same or derived from file_output_stream
or contains a file_output_stream object as first member you invoke undefined
behavior when the calls following might read from the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115426
--- Comment #3 from Richard Biener ---
I think this is a gimplification failure. 'r' is neither TREE_ADDRESSABLE
nor DECL_NOT_GIMPLE_REG and the =X constraint results in both allow_reg
and allow_mem but we gimplify it as is_gimple_lvalue which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115426
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=115423
--- Comment #2 from Richard Biener ---
You could also say rtl-optimization does a bad job with the inlined version.
Or we should inline strcmp on GIMPLE to get the first char optimized.
Consider
strcmp (c, "ABCDEFGHabcdefgh")
|| strcmp (c,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
Richard Biener changed:
What|Removed |Added
CC||ilg at livius dot net
--- Comment #28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115421
Richard Biener changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115416
Richard Biener changed:
What|Removed |Added
Version|unknown |14.1.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115427
--- Comment #2 from Richard Biener ---
The canonical way would be to handle these in the ISEL pass and remove
the (fallback) expansion. But then we can see whether the expander FAILs
(ideally expanders would never be allowed to FAIL, and for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115388
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115405
--- Comment #3 from Richard Biener ---
It's not visible but I assume that _4 doesn't have _BitInt(17) type?
The
if (known_eq (offset, 0)
&& !reverse
&& poly_int_tree_p (TYPE_SIZE (type), _size)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115395
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115388
--- Comment #4 from Richard Biener ---
It's DSE5 deleting
Deleted dead store: a[b.19_216] = 1;
there's a big irreducible region following the loop with this store, but
I fail to see how we can reach the load without going through the other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115386
--- Comment #8 from Richard Biener ---
(In reply to David Binderman from comment #7)
> (In reply to Richard Biener from comment #6)
> > Are you using a compiler with release checking?
>
> No, with asan & ubsan.
>
> I tried running cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115411
Richard Biener changed:
What|Removed |Added
Component|c |middle-end
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115395
--- Comment #6 from Richard Biener ---
In fact, the main loop ends up not using SLP but the epilogue one does and
we end up setting STMT_VINFO_REDUC_EPILOGUE_ADJUSTMENT which we do not
support for SLP.
The question is whether to add that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115395
--- Comment #5 from Richard Biener ---
It needs epilogue vectorization to trigger and it's the path re-using the
vector accumulator from the earlier loop that goes wrong when the main
vector loop is skipped.
We apply the initial value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115386
Richard Biener changed:
What|Removed |Added
Version|unknown |15.0
--- Comment #6 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115382
--- Comment #4 from Richard Biener ---
(In reply to Robin Dapp from comment #3)
> For the record - the hunk before bootstrapped and regtested on the cfarm
> machines and tested successfully on aarch64 qemu with sve. I still need to
> set up a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115404
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |15.0
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115395
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=115394
Richard Biener changed:
What|Removed |Added
Keywords||internal-improvement
--- Comment #1
|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Version|unknown |15.0
--- Comment #3 from Richard Biener ---
Ah, finally a small testcase. I'll have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115384
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115383
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115382
--- Comment #2 from Richard Biener ---
I think it should work, but there's also prepare_vec_mask which is using a
cache but I have no idea whether this is applicable for non-load/store and
whether there's extra work to be done for it to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115385
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
Consider
void __attribute__((noipa)) foo(unsigned char * __restrict x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115383
--- Comment #4 from Richard Biener ---
Created attachment 58378
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58378=edit
patch
I'm testing this, but I do not have hardware to test correctness (and qemu not
set up).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115383
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
---
|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Priority|P3 |P1
--- Comment #2 from Richard Biener ---
I can reproduce.
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
vectorize_fold_left_reduction does
if (LOOP_VINFO_FULLY_MASKED_P (loop_vinfo))
mask = vect_get_loop_mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115381
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-06-07
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115381
--- Comment #1 from Richard Biener ---
-fno-semantic-interposition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115373
Richard Biener changed:
What|Removed |Added
Target|riscv |riscv, aarch64
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115375
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115374
--- Comment #9 from Richard Biener ---
Yep, it's call DCE which elides the errno setting function call iff the result
is not NaN.
||rguenth at gcc dot gnu.org
Target||riscv
Keywords||testsuite-fail
--- Comment #2 from Richard Biener ---
This also wasn't seen in precommit CI. I can confirm it on trunk and the
issue is that we prefer
||testsuite-fail
CC||rguenth at gcc dot gnu.org
Target||riscv
--- Comment #2 from Richard Biener ---
I don't remember seeing FAIL: gcc.dg/vect/pr97428.c in the precommit CI, this
one should get one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115370
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |15.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115365
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115364
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115363
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115362
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-06-06
,
||rguenth at gcc dot gnu.org
--- Comment #1 from Richard Biener ---
The issue is probably get_odr_name_for_type returning sth non-NULL for both.
But yeah, duping before copying looks wrong since we seem to expect
NULL eventually.
if (name1 = cplus_demangle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115358
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115355
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115355
Richard Biener changed:
What|Removed |Added
Target||powerpc64le
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114932
--- Comment #10 from Richard Biener ---
I think the question is why IVOPTs ends up using both the signed and unsigned
variant of the same IV instead of expressing all uses of both with one IV?
That's where I'd look into.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115354
Richard Biener changed:
What|Removed |Added
Summary|Large -Os code size |[14/15 Regression] Large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115351
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
Summary|[14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115347
Richard Biener changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115346
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99258
Richard Biener changed:
What|Removed |Added
CC||patrick at rivosinc dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115345
--- Comment #12 from Richard Biener ---
(In reply to Djordje Baljozovic from comment #11)
> (In reply to Djordje Baljozovic from comment #9)
> > (In reply to Andrew Pinski from comment #7)
> > > A few questions, does `-fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115344
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115342
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110381
Richard Biener changed:
What|Removed |Added
Summary|[11/12 Regression] double |[11 Regression] double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115340
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-06-04
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115331
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115326
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115327
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115304
Richard Biener changed:
What|Removed |Added
Target|sparc*-sun-solaris2.11 GCN |GCN
--- Comment #8 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115304
--- Comment #6 from Richard Biener ---
For GCN the issue is that with vector(64) unsigned short we fail the permute
(but we have { target vect64 } for this reason), but we then re-try with
the same mode but with SLP disabled and that succeeds.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #48 from Richard Biener ---
(In reply to Christopher Nerz from comment #47)
> But shouldn't both give the same value?
I'm not sure what the standard says to this. Does std::launder(...)
sanitize earlier "undefined behavior"? For
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
Richard Biener changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115312
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115310
--- Comment #6 from Richard Biener ---
(In reply to Florian Weimer from comment #3)
> This is just following the previous GCC behavior. For example, with GCC 11:
>
> $ gcc -S -Werror=return-type -std=gnu89 t.c
> t.c:1:1: error: return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115311
--- Comment #3 from Richard Biener ---
Note we handle -Wno-xyz similarly, but of course a typo like -fno-builtin-sun
(s/sun/sin) isn't noticed this way which is the drawback.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115255
Richard Biener changed:
What|Removed |Added
CC|richard.guenther at gmail dot com |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115310
Richard Biener changed:
What|Removed |Added
CC||fweimer at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115307
--- Comment #1 from Richard Biener ---
The issue is that we probably fold isinff early. On x86 I see already in
.original:
return !(ABS_EXPR u<= 3.4028234663852885981170418348451692544e+38);
I think your option is to provide optabs for
Priority|P3 |P1
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Target|powerpc64-linux-gnu |powerpc64*-linux-gnu
Status|NEW |ASSIGNED
--- Comment #3 from Richard Biener ---
Ah
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115303
--- Comment #2 from Richard Biener ---
Yeah, if requiring vect_shift works for you that's pre-approved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115304
Richard Biener changed:
What|Removed |Added
Keywords||testsuite-fail
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115305
Richard Biener changed:
What|Removed |Added
Target||i686-darwin9
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115278
Richard Biener changed:
What|Removed |Added
Summary|[13/14/15 Regression] |[13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115278
--- Comment #6 from Richard Biener ---
(In reply to avieira from comment #5)
> > I think we fixed similar bug on the read side.
>
> I don't have the best memory, but the one I can remember is PR 111882, where
> we had the SAVE_EXPR. And the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115300
--- Comment #3 from Richard Biener ---
Can you try --disable-plugin? It might be the mingw equivalent of exporting
all dynamic symbols from the cc1 binary runs into target limitations? It looks
like the default on *-*-mingw* is disabled
|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #4 from Richard Biener ---
It's actually a latent issue, unrelated to bitfields? We elide the store via
tree lhs = gimple_get_lhs (stmt);
ao_ref write;
ao_ref_init (, lhs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115297
Richard Biener changed:
What|Removed |Added
Summary|[14 regression] alpha: ICE |[14/15 regression] alpha:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115294
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115292
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |15.0
Version|9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115290
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115278
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #3 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115277
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115298
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115282
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |15.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115275
Richard Biener changed:
What|Removed |Added
Known to work||13.3.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115273
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115272
--- Comment #2 from Richard Biener ---
(In reply to Richard Biener from comment #1)
> How does it work for 'double' vs. 'long double' themselves?
>
> <1><32>: Abbrev Number: 3 (DW_TAG_base_type)
> <33> DW_AT_byte_size : 16
> <34>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115272
--- Comment #1 from Richard Biener ---
How does it work for 'double' vs. 'long double' themselves?
<1><32>: Abbrev Number: 3 (DW_TAG_base_type)
<33> DW_AT_byte_size : 16
<34> DW_AT_encoding: 4(float)
<35>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115252
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 115252, which changed state.
Bug 115252 Summary: The SLP vectorizer failed to perform automatic
vectorization on pixel_sub_wxh of x264
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115252
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114435
--- Comment #10 from Richard Biener ---
(In reply to Richard Biener from comment #9)
> So the "pcom messes up SLP" part should be fixed now. The pass dependence
> of invariant/store motion and unswitching (and likely also loop splitting) is
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 114435, which changed state.
Bug 114435 Summary: PCOM messes up vectorization some times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114435
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 114435, which changed state.
Bug 114435 Summary: PCOM messes up vectorization some times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114435
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114435
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
1 - 100 of 53405 matches
Mail list logo
