https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92235
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92253
Richard Biener changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #1 from Richard Bie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92816
Richard Biener changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #4 from Richard Bie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92955
--- Comment #9 from Richard Biener ---
Complete peeling is known of not eliminating all unreachable code which is why
-Warray-bounds now runs _before_ unrolling only. Note it's practically
impossible to cover all cases in peeling but there's som
at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #3 from Richard Biener ---
I will have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94226
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774
Bug 84774 depends on bug 94226, which changed state.
Bug 94226 Summary: [10 regression] r10-7272 eliminated some warning messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94226
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94233
--- Comment #1 from Richard Biener ---
get_object_alignment_1 (base, &bit_base_alignment, &bit_base_misalignment);
/* There are no bitfield references remaining in BASE, so the values
we got back must be whole bytes. */
gcc_assert (b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94034
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93465
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Component|libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94123
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94044
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94186
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94223
--- Comment #4 from Richard Biener ---
Note the code is the same on the GCC 9 branch so the issue must be latent maybe
with different testcases.
||2020-03-20
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||hubicka at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94234
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94123
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93270
Richard Biener changed:
What|Removed |Added
CC||coleb at eyesopen dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61872
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94237
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94239
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #1 from Richard Biener ---
I will have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94246
Richard Biener changed:
What|Removed |Added
Keywords||error-recovery,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94247
Richard Biener changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94247
--- Comment #3 from Richard Biener ---
Yes, it's bad programming practice to use 'char' for any arithmetic.
dot gnu.org |rguenth at gcc dot
gnu.org
Last reconfirmed||2020-03-23
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Richard Biener ---
Confirmed, mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94266
--- Comment #2 from Richard Biener ---
This looks latent somewhat. The issue is manifold - first we end up
with &TARGET_MEM_REF [_1] where the TARGET_MEM_REF was not canonicalized
to a MEM_REF because
static tree
create_mem_ref_raw (tree type,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94261
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94263
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
Seen in PR94266 IVOPTs can generate &TARGET_MEM_REF[ptr_1 + 0] which we
obviously should represent as plain ptr_1, possibly casted. Likewise
&TARGET_MEM_REF[ptr_1 +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94267
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=94266
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94261
--- Comment #2 from Richard Biener ---
So I think we can avoid swapping operands but what we cannot (current) avoid
is adjusting the tree code. The operand swapping should be subsumed by
get_slp_defs no longer looking at the scalar stmt for mapp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94261
--- Comment #3 from Richard Biener ---
(In reply to Richard Biener from comment #2)
> when placing gcc_unreachable () at the swapping place and most testcases
> still pass when removing the IL operand swapping, only vect-cselim-1.c
> runfails (in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94261
--- Comment #4 from Richard Biener ---
Created attachment 48083
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48083&action=edit
proposed patch
untested sofar.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94245
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94261
--- Comment #6 from Richard Biener ---
(In reply to rsand...@gcc.gnu.org from comment #5)
> (In reply to Richard Biener from comment #3)
> > (In reply to Richard Biener from comment #2)
> > > when placing gcc_unreachable () at the swapping place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94261
--- Comment #8 from Richard Biener ---
(In reply to rsand...@gcc.gnu.org from comment #7)
> (In reply to Richard Biener from comment #6)
> > (In reply to rsand...@gcc.gnu.org from comment #5)
> > > (In reply to Richard Biener from comment #3)
> >
at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Last reconfirmed||2020-03-23
Ever confirmed|0 |1
--- Comment #9 from Richard Biener ---
Created attachment 48087
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48087&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94043
--- Comment #9 from Richard Biener ---
OK, so it's indeed vectorizable_live_operation not paying attention to
loop-closed SSA form.
What it should do before building the lane extract is create a _new_
loop-closed PHI node for the vectorized def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94261
Richard Biener changed:
What|Removed |Added
Attachment #48083|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94276
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.4
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94277
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.4
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94274
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94273
Richard Biener changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94272
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94271
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.5
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94269
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-03-23
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94286
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94284
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94285
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94283
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94281
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94287
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94261
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94293
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
||missed-optimization
Depends on||94293
CC||rguenth at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94125
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Known to work|
: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
For the following testcase at -O3 -fgimple (gimple testcase because the
vectorizer generated code depends on not committed patches) we somehow
duplicate the load from y:
typedef double v2df
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
When the vectorizer creates sth stupid like
_11 = __MEM ((double *)vectp_y.3_4);
vect__2.5_15 = _Literal (vector(2) double) {_11, _Literal (vector(1
|1
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93946
--- Comment #10 from Richard Biener ---
(In reply to sandra from comment #9)
> Both the new test cases are failing on nios2 at -Os, -O2, and -O3. I've
> done some analysis, but I'm not sure exactly where the problem lies, and
> whether this is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94123
Richard Biener changed:
What|Removed |Added
Priority|P1 |P2
--- Comment #9 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94308
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94307
Richard Biener changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #1 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94313
--- Comment #1 from Richard Biener ---
This is likely because points-to computes the result of the string functions,
for example in g1 it computes
s_5 = { NULL STRING }
and somehow ref_maybe_used_by_stmt_p computes false for *s and f(s).
That's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94314
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94315
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94318
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94314
--- Comment #4 from Richard Biener ---
(In reply to Martin Liška from comment #3)
> Yes, I remember we discussed the topic about the user-provided new/delete
> implementations. Can please Jason or Jonathan comment about the test-case?
The testca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94322
--- Comment #1 from Richard Biener ---
We're quite lazy in freeing all memory from generator tools (genhooks as you
report) but there are also known leaks in the driver when it comes to
command-line processing.
That is, not all memory leaks are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #4 from Richard Biener ---
(In reply to Mark Wielaard from comment #3)
> (In reply to Richard Biener from comment #1)
> > Err, but isn't this interpreting the dwarf from 'date'? So doesn't this
> > mean that valgrind is "miscompiled"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94330
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94334
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94335
--- Comment #3 from Richard Biener ---
You should be using (intptr_t)t - (intptr_t)this when computing the relative
pointer, not sure if that makes a difference but pointer difference between
pointers to different objects invokes undefined behavi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94337
--- Comment #1 from Richard Biener ---
The warning only looks at the single expression it quotes which isn't really
enough to discover you are doing right. It tries to be helpful - if you know
better then disable the warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91518
Richard Biener changed:
What|Removed |Added
Priority|P1 |P3
--- Comment #7 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94043
--- Comment #13 from Richard Biener ---
(In reply to Kewen Lin from comment #12)
> Created attachment 48122 [details]
> ppc64le tested patch
>
> Thanks Richi!
>
> A patch draft attached to ensure on the right track, also
> bootstrapped/regresst
,
||rguenth at gcc dot gnu.org
Version|lto |9.2.1
Keywords||diagnostic
--- Comment #2 from Richard Biener ---
I think the testcase is ill-formed and should be diagnosed in some form.
IIRC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94339
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94273
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94342
--- Comment #2 from Richard Biener ---
I think it should belong to the same .comdat group as other parts of the
template instantiation (there's one static var per instantiation) so I don't
see how the section specification can be easily honored.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94342
--- Comment #3 from Richard Biener ---
Hmm, I see clang produces
COMDAT group section [3] `.group' [_Z5IndexIiEvi] contains 2 sections:
[Index]Name
[4] .text._Z5IndexIiEvi
[5] .rela.text._Z5IndexIiEvi
COMDAT group s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94342
--- Comment #4 from Richard Biener ---
So the section attribute then only provides naming of the comdat section used
and cannot be used to group things. Not sure that is what you are looking
after.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94043
--- Comment #17 from Richard Biener ---
(In reply to Kewen Lin from comment #16)
> Created attachment 48125 [details]
> untested patch
LGTM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94344
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94342
--- Comment #7 from Richard Biener ---
Yes, they are orthogonal. But I expected that when I use
__attribute__((section"foo")) twice then both instances will be in the
same section which is not the case here. Here just the names of the sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94273
--- Comment #9 from Richard Biener ---
OK, so during early creation of the DIE for the type we end up in
static void
gen_struct_or_union_type_die (tree type, dw_die_ref context_die,
enum debug_info_usage usage)
{
at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #10 from Richard Biener ---
I'm testing this patch now.
||2020-03-27
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #1 from Richard Biener ---
Confirmed but in essence harmless.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94338
--- Comment #8 from Richard Biener ---
(In reply to huaixin chang from comment #7)
> (In reply to Martin Sebor from comment #4)
> > Sounds like there's agreement that the code should at least get a warning
> > then, so confirmed.
> >
> > The at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94338
--- Comment #9 from Richard Biener ---
Btw,
struct X {
long a __attribute__((__aligned__(128)));
long b __attribute__((__aligned__(128)));
};
struct X A __attribute__((__aligned__(4)));
is not diagnosed (this is what your testcase is, d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90811
--- Comment #21 from Richard Biener ---
Why is LOCAL_DECL_ALIGNMENT not applied during layout_decl? (I realize for
offloading this might be suboptimal)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94352
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94273
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93597
Richard Biener changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93946
--- Comment #14 from Richard Biener ---
(In reply to sandra from comment #13)
> Well, no. The problem is that the scheduler is moving
>
> ldw r2, 0(r4)
>
> ahead of
>
> stw zero, 0(r5)
>
> which is incorrect because
101 - 200 of 49442 matches
Mail list logo
