https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191
--- Comment #9 from Jeffrey A. Law ---
Yea, I think so -- which would be undefined because the sizes are different
according to the docs you referenced. Which would also invalidate part of my
responses in c#5 and c#7.
It sounds like something o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #57 from Jeffrey A. Law ---
Below is a POC for improving the uninit analysis to handle this kind of case.
It's not complete. In particular it does not ensure that the we have the same
result on the RHS and LHS of the V_C_E. Basical
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87489
Jeffrey A. Law changed:
What|Removed |Added
Assignee|msebor at gcc dot gnu.org |law at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86010
--- Comment #14 from Jeffrey A. Law ---
I believe it's still an issue for gcc-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92539
--- Comment #6 from Jeffrey A. Law ---
I wonder if we're looking at this the wrong way.
We have several blocks with this kind of structure:
[local count: 30530247]:
if (last_12 != &MEM [(void *)"aa" + 3B])
goto ; [54.59%]
else
g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98594
--- Comment #6 from Jeffrey A. Law ---
Duh. I should have seen the reinterpret_cast as a red flag on this one. And
not surprising -fno-strict-aliasing makes the glm testsuite happy. Sorry for
the noise.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #38 from Jeffrey A. Law ---
sparc might be able to trip this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #10
Assignee: unassigned at gcc dot gnu.org
Reporter: law at redhat dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Target: s390x
Created attachment 49917
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49917&action=edit
Hacked up/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
--- Comment #18 from Jeffrey A. Law ---
Jon, there's no way for the optimizers to improve the to_derived_bad case as
there's nothing in the IL after we leave the front-end that's useful. In the
.original dump we have:
;; Function derived& to_de
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: law at redhat dot com
CC: hjl.tools at gmail dot com, jakub at redhat dot com
Target Milestone: ---
Using the "target" attribute on x86 causes a reset of the cmodel from the
command line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95381
Jeffrey A. Law changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #16 from Jeffrey A. Law
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95381
--- Comment #12 from Jeffrey A. Law ---
On 12/30/20 10:30 AM, glaubitz at physik dot fu-berlin.de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95381
>
> --- Comment #11 from John Paul Adrian Glaubitz fu-berlin.de> ---
> (In reply to Jef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95381
--- Comment #10 from Jeffrey A. Law ---
So if that bisection is accurate, the only way this could be failing would be
if something with a deprecated attribute is being used.
Maybe some printfs in warn_deprecated_use? But again, I'm a bit surpri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191
--- Comment #7 from Jeffrey A. Law ---
If you're V_C_E-ing to a narrower type, you just ignore the bits outside the
target type, it's a lot like a narrowing subreg in the RTL world.
I don't know what the semantics are for the widening case. IST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191
--- Comment #5 from Jeffrey A. Law ---
The best way to think about V_C_E is that it's the same bits, just viewed in a
different type whereas a cast can do things like sign/zero extension,
truncation of floating point values to integers, etc).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987
Bug 19987 depends on bug 96708, which changed state.
Bug 96708 Summary: Failure to optimize max pattern with comparison when using a
temporary variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96708
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96708
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987
Bug 19987 depends on bug 96679, which changed state.
Bug 96679 Summary: Failure to optimize or+and+or pattern to and+or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96679
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96679
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
|1
Status|UNCONFIRMED |NEW
CC||law at redhat dot com
--- Comment #2 from Jeffrey A. Law ---
I took a peek when Serge pointed me at the issue. I think there's a window
where a signal handler could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #55 from Jeffrey A. Law ---
So to summarize some thoughts from Richi from last year.
Converting the V_C_E into a NOP_EXPR is undesirable as the truncation becomes
sub-optimal because we end up with an additional masking operation. S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91318
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180
Bug 89180 depends on bug 91318, which changed state.
Bug 91318 Summary: [C++][PATCH] warnings about unused internal macros with
-Wunused-macros and #pragma GCC optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91318
What|Remov
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #2 from Jeffrey A. Law ---
Should be fixed on the trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97804
--- Comment #1 from Jeffrey A. Law ---
Created attachment 49550
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49550&action=edit
Testcase
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: law at redhat dot com
Target Milestone: ---
Trunk as of 5d46ec3db21d8c8926f15a634b2d6570536db5f1 faults compiling the
attached code with -O2 -std=c++17 on x86_64:
./cc1plus -O2 -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97108
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96948
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
|RESOLVED
CC||law at redhat dot com
--- Comment #6 from Jeffrey A. Law ---
Should be fixed on trunk now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987
Bug 19987 depends on bug 96701, which changed state.
Bug 96701 Summary: Failure to optimize self right-shift to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96701
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96701
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96939
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #1
|unassigned at gcc dot gnu.org |law at redhat dot com
CC||law at redhat dot com
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: law at redhat dot com
Target Milestone: ---
Compile with -O2. We should be able to eliminate the x > p1 test if we were
smart about back propagating equivalences to generate a range from the
__builtin_add_overf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #35 from Jeffrey A. Law ---
That's a reasonable idea Eric -- the barriers are primarily there for the
benefit of CFG building and manipulation and thus provide marginal, if any,
benefit once we hit the reorg pass.
I recall 81025 bein
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #33 from Jeffrey A. Law ---
Have I mentioned before that I think __builtin_unreachable is fundamentally
broken/wrong :-)
I could argue that the BARRIER in the IL is wrong because it doesn't actually
line up with the semantics of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94882
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #13 from Jeffrey A. Law ---
Hmm, there's a control dependency though in bb13:
[local count: 242478389]:
# result_21 = PHI <1(5), sign_17(6)>
switch (op_14(D)) [33.33%], case 0: [16.67%], case 1:
[50.00%], case 3: [50.00%],
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #12 from Jeffrey A. Law ---
The block in question goes away because it serves no purpose:
[local count: 242478389]:
_13 = *self_11(D);
_16 = *other_12(D);
sign_17 = _13 - _16;
if (sign_17 == 0)
goto ; [34.00%]
else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
--- Comment #14 from Jeffrey A. Law ---
The reason for turning the dereference into a trap is because we can clean up
ancillary computations -- the address computation, the RHS of a store, and the
like via standard dead code elimination algorithm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
--- Comment #13 from Jeffrey A. Law ---
Marc,
Yes, absolutely. In fact, I think that falls out of the work Martin S is doing
in this space. Conceptually we're looking to generalize that code so that we
can route more cases where the compiler d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95381
--- Comment #6 from Jeffrey A. Law ---
That's an indication that something has tried to do an out of bounds read on a
VEC object. The call chain points back to the initial quick_grow of an
auto_vec from test_vector_cst_patterns -- which is wildl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95649
--- Comment #8 from Jeffrey A. Law ---
I still don't understand why propagating one SSA_NAME for another is causing
headaches later though.
I don't see anything fundamentally wrong with your patch and it restores
previous behavior since singlet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95649
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95381
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #4
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: law at redhat dot com
Target Milestone: ---
Various ports have regressed the tree-ssa/ssa-dom-cse-2.c after this change:
commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95218
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91146
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
--- Comment #6 from Jeffrey A. Law ---
THe whole point of that change is to not require a dominating load if the
object comes from the stack.
We conditionally load from the same location, then have a PHI which selects
that loaded value or "1" an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92983
--- Comment #7 from Jeffrey A. Law ---
So I first took a clean RHEL 8.1 system with kernel-4.18.0-147 and verified
that this simple stap script would fail:
stap -p4 -e 'probe module("nfsv3").function("nfs3_commit_done") {
println($task) }'
Whic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92983
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675
Jeffrey A. Law changed:
What|Removed |Added
CC||drahflow at gmx dot de
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 94655, which changed state.
Bug 94655 Summary: [10 Regression] Implicit assignment operator triggers
stringop-overflow warning since r10-5451-gef29b12cfbb4979a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94655
|RESOLVED
CC||law at redhat dot com
--- Comment #6 from Jeffrey A. Law ---
Fundamentally if we're relying on the type of the MEM_REF, then we're going to
run into problems. It simply does not map back to what the user
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90291
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543
Jeffrey A. Law changed:
What|Removed |Added
Target Milestone|8.5 |11.0
||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85145
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94659
Jeffrey A. Law changed:
What|Removed |Added
Priority|P2 |P3
--- Comment #4 from Jeffrey A. Law
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94659
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675
--- Comment #12 from Jeffrey A. Law ---
SO it's not terrible to get the key block cleaned up. but that's not
sufficient to resolve this issue. We all missed an important tidbit.
VRP is complaining about this:
ps.D.2041.s = &MEM [(void *)&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675
--- Comment #9 from Jeffrey A. Law ---
Yea, unrolling and the array-bounds warning do have bad interactions.
I suspect if we cleaned up this block that the backwards threader would likely
kick in:
# iftmp.2_18 = PHI <1(3), 1(4), 0(5)>
_19 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92430
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19466
Bug 19466 depends on bug 15826, which changed state.
Bug 15826 Summary: don't use "if" to extract a single bit bit-field.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15826
What|Removed |Added
--
||law at redhat dot com
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=81601
Resolution|--- |FIXED
--- Comment #19 from Jeffrey A. Law ---
So the core
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987
Bug 19987 depends on bug 15826, which changed state.
Bug 15826 Summary: don't use "if" to extract a single bit bit-field.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15826
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987
Bug 19987 depends on bug 15348, which changed state.
Bug 15348 Summary: [tree-ssa] Convert (x < 0) || (y < 0) into (x | y) < 0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15348
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15348
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92233
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66087
--- Comment #5 from Jeffrey A. Law ---
Interestingly enough it fails in a similar manner with LRA, but I agree that
avoiding this earlier in the pipeline is preferable.
||2020-04-18
Ever confirmed|0 |1
CC||law at redhat dot com
--- Comment #8 from Jeffrey A. Law ---
I believe you can see the poor code generation when using the -m5200 option.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91829
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21530
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 92893, which changed state.
Bug 92893 Summary: [10 Regression] Unhelpful -Wstringop-overflow warning for a
trailing one-element array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92893
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92893
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87296
Jeffrey A. Law changed:
What|Removed |Added
CC||sbergman at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89550
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 89550, which changed state.
Bug 89550 Summary: [8/9/10 Regression] Spurious array-bounds warning when using
__PRETTY_FUNCTION__ as a string_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89550
What|Remo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91161
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91384
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #6
|RESOLVED
CC||law at redhat dot com
--- Comment #2 from Jeffrey A. Law ---
Fixed by Vlad's LRA work in March.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92893
--- Comment #6 from Jeffrey A. Law ---
Isn't this ultimately a case of relying on the type information from that MEM
expression in a place where it's not valid?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94396
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94420
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94530
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94439
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94439
--- Comment #6 from Jeffrey A. Law ---
And has likely been broken since the introduction of VTA if I'm reading the
code correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94439
Jeffrey A. Law changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94439
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94106
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94637
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90392
Jeffrey A. Law changed:
What|Removed |Added
Status|WAITING |NEW
Summary|[8/9/10 Regressi
1 - 100 of 3055 matches
Mail list logo
