https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #40 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:fe19699ae2883b252d30f98481d32dabff00744b
commit r10-7035-gfe19699ae2883b252d30f98481d32dabff00744b
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #38 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b07e4e7c7520ca3e798f514dec0711eea2c027be
commit r10-6994-gb07e4e7c7520ca3e798f514dec0711eea2c027be
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #37 from Jakub Jelinek ---
(In reply to rguent...@suse.de from comment #36)
> Yeah, just add a insert_p flag to the lookup function and the context
> struct, for lookups only valid under a mask we indeed may not record
> those into th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #36 from rguenther at suse dot de ---
On Fri, 28 Feb 2020, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
>
> --- Comment #35 from Jakub Jelinek ---
> Unfortunately, it breaks miserably, e.g. m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #35 from Jakub Jelinek ---
Unfortunately, it breaks miserably, e.g. miscompiles libcpp/macro.c.
Reduced testcase from that:
--- gcc/testsuite/gcc.c-torture/execute/pr93582.c.jj2020-02-28
12:27:51.280925113 +0100
+++ gcc/testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #34 from Jakub Jelinek ---
Created attachment 47923
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47923&action=edit
gcc10-pr93582-wip.patch
WIP patch that fixes the original regression (handling of lookup through masked
loads)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #33 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:5f9cd512c4278621435cce486dd00248ea2e821c
commit r10-6885-g5f9cd512c4278621435cce486dd00248ea2e821c
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #32 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:7f5617b00445dcc861a498a4cecc8aaa59e05b8c
commit r10-6809-g7f5617b00445dcc861a498a4cecc8aaa59e05b8c
Author: Jakub Jelinek
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #31 from Richard Biener ---
(In reply to Jakub Jelinek from comment #29)
> Passed bootstrap/regtest on all of {x86_64,i686,powerpc64{,le}}-linux now,
> with powerpc64-linux doing both -m32/-m64 testing.
LGTM.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #29 from Jakub Jelinek ---
Passed bootstrap/regtest on all of {x86_64,i686,powerpc64{,le}}-linux now, with
powerpc64-linux doing both -m32/-m64 testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
Jakub Jelinek changed:
What|Removed |Added
Attachment #47863|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #27 from rguenther at suse dot de ---
On Mon, 17 Feb 2020, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
>
> --- Comment #26 from Jakub Jelinek ---
> Created attachment 47863
> --> https://g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #26 from Jakub Jelinek ---
Created attachment 47863
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47863&action=edit
gcc10-pr93582-2-wip.patch
WIP on the merging from multiple stores. BIG_ENDIAN still not implemented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #25 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8aba425f4ebc5e2c054776d3cdddf13f7c1918f8
commit r10-6614-g8aba425f4ebc5e2c054776d3cdddf13f7c1918f8
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #24 from Jakub Jelinek ---
Created attachment 47826
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47826&action=edit
gcc10-pr93582.patch
Untested patch for the first step, going to test this now on both little and
big endian.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #23 from rguenther at suse dot de ---
On Tue, 11 Feb 2020, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
>
> --- Comment #22 from Jakub Jelinek ---
> (In reply to Richard Biener from comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #22 from Jakub Jelinek ---
(In reply to Richard Biener from comment #21)
> The shift_bytes_in_array_{left,right} routines should go next to
> native_{encode,interpret} where maybe also a comment should indicate how to
> combine both?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #21 from Richard Biener ---
The shift_bytes_in_array_{left,right} routines should go next to
native_{encode,interpret} where maybe also a comment should indicate how to
combine both?
The vn_reference_lookup_3 part looks OK to me, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #20 from Jakub Jelinek ---
Created attachment 47814
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47814&action=edit
gcc10-pr93582-wip.patch
WIP patch, so far only the store covering all the bits (the reconstruction from
pieces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #19 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #18)
> > For bitfields there's also the ever present bitfield-lowering idea...
>
> I understood Andrew P. is working on something, but no idea how far it is.
I am wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #18 from Jakub Jelinek ---
(In reply to Richard Biener from comment #17)
> As for the more complex case of handling non-constants mixed with constants
> I do have some patches in the queue for stage1 for the partial overlap case
> but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #17 from Richard Biener ---
(In reply to Jakub Jelinek from comment #16)
> I'll play with it next week.
What can be handled specially is certainly size2i == maxsizei for the
known_subrange_p case. Then we can pun the RHS directly wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
Jakub Jelinek changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #15 from Jakub Jelinek ---
With
struct S {
unsigned int s1:1;
unsigned int s2:1;
unsigned int s3:1;
unsigned int s4:1;
unsigned int s5:4;
unsigned char s6;
unsigned short s7;
unsigned short s8;
};
struct T {
int t1;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #14 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #12)
> The warning is in dead code, but due to the optimize_bit_field_compare
> "optimization" we aren't able to find that out until combine.
I am not a fan of that o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
Martin Sebor changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #13 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
Jakub Jelinek changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #11 from Martin Sebor ---
-mtune=z13 seems to enable more inlining so many of the past-the-end references
to the tempGrab local variable end up inlined into the bodies of the functions
that define them.
For example:
PassivGrab.c: In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #10 from Marek Polacek ---
Cross-compiled s390x-redhat-linux gcc shows that the warning appears with
-mtune=z13, but not without it (using -O2).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #9 from Marek Polacek ---
Created attachment 47778
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47778&action=edit
original .i file
Attaching the original .i file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #8 from Martin Sebor ---
We would need to see the original code (the translation unit) to tell for sure
why the warning is only issued on some targets and not on others, but the most
likely answer is that the code results in different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #7 from Adam Jackson ---
(In reply to Marek Polacek from comment #6)
> Well, zero-length arrays are a GNU C extension, but pre-C99 you could use
> pixels[1] and post-C99 you can use pixels[]. Is non of that an option?
The code coul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #6 from Marek Polacek ---
(In reply to Adam Jackson from comment #5)
> (In reply to Martin Sebor from comment #4)
> > It seems like the reporter might be conflating the forming of a past-the-end
> > pointer (what the GRABEXT macro doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
Adam Jackson changed:
What|Removed |Added
CC||ajax at redhat dot com
--- Comment #5 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #3 from Marek Polacek ---
This is about us not accepting the code anymore, I think it's what libXt relies
on. Quoting Adam J.:
"Where GRABEXT here is just doing the standard C trick for incrementing
past the current struct and retur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
--- Comment #2 from Martin Sebor ---
Below is a simplified C test case. The warning is justified and works
correctly, but the index and the type it prints might be a little confusing.
The index corresponds to the MEM_REF offset which is set to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582
Marek Polacek changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Target Miles
41 matches
Mail list logo
