https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94617
--- Comment #1 from Richard Biener ---
Why do you think this is terrible? Aggressive use of conditional moves is not
a good idea in general.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94617
--- Comment #3 from Richard Biener ---
Note the RTL if-conversion pass doesn't recognize what we present to it.
If you alter initial RTL expansion via -fno-tree-ter (not recommended in
general)
we produce a more 1:1 translation of the code as
_Z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94617
--- Comment #4 from Richard Biener ---
IIRC you can also express the range test this way:
const char* vanilla_bandpass(int a, int b, int x, const char* low, const char*
high)
{
const bool within_interval { (unsigned long)x - a < (unsigned long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33315
--- Comment #14 from Richard Biener ---
(In reply to Richard Biener from comment #13)
> (In reply to Richard Biener from comment #12)
> > Created attachment 48279 [details]
> > patch
> >
> > Patch forward ported to current trunk.
>
> Surprising
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94617
--- Comment #7 from Richard Biener ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to David Seifert from comment #5)
> > just benchmarked the code on an oldish Ivybridge. GCC with vanilla_bandpass
> > is 2.1x slower than GCC with funk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94129
--- Comment #10 from Richard Biener ---
(In reply to Martin Liška from comment #9)
> (In reply to Martin Liška from comment #8)
> > @Richi: Can you please enable zstd for our nvptx cross compiler:
> >
> > $ x86_64-suse-linux-accel-nvptx-none-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94612
--- Comment #10 from Richard Biener ---
(In reply to Martin Liška from comment #3)
> It's likely dup of PR94129.
Note that that one ICEs on matching compression algorithms which here
the ICE notes the compressed data stream is corrupt.
There mu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94618
Richard Biener changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
K
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94621
--- Comment #6 from Richard Biener ---
(In reply to Ola Olsson from comment #5)
> My god. Insanely fast. Dobra robota/prace!
The power of Free Software / Open Source.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94621
--- Comment #7 from Richard Biener ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 48294 [details]
> gcc10-pr94621.patch
>
> Untested fix.
LGTM (obvious even)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94628
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94627
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94630
Richard Biener changed:
What|Removed |Added
Version|unknown |10.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629
--- Comment #1 from Richard Biener ---
Picking those obvious to me at the moment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629
--- Comment #2 from Richard Biener ---
Created attachment 48298
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48298&action=edit
parts I am testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94618
--- Comment #6 from Richard Biener ---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 48293 [details]
> gcc10-pr94618.patch
>
> Untested fix.
Looks logically correct - but are there no helpers for this on the RTL side?
Like LA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94631
--- Comment #4 from Richard Biener ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Rich Felker from comment #2)
> > So basically the outcome of DR120 was allowing the GCC behavior? It still
> > seems like a bad thing, not required,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94634
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
--- Comment #19 from Richard Biener ---
(In reply to Martin Jambor from comment #17)
> Created attachment 48302 [details]
> Untested fix
>
> I'm playing with this - only very mildly tested - fix.
Ugh.
I was thinking of altering the parameter s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94645
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.0
Summary|incorrect conce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94647
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.0
--- Comment #2 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
--- Comment #1 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94650
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94655
Richard Biener changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Target Mile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94658
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
Richard Biener changed:
What|Removed |Added
CC||pascal_cuoq at hotmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94656
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #22 from Richard Biener ---
Created attachment 48311
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48311&action=edit
patch
Note that apart from the possible bad impact on optimization when fixing this
bug an actual fix is comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #23 from Richard Biener ---
(In reply to Richard Biener from comment #22)
> Created attachment 48311 [details]
> patch
>
> Note that apart from the possible bad impact on optimization when fixing this
> bug an actual fix is complicat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #24 from Richard Biener ---
(In reply to Richard Biener from comment #22)
> Created attachment 48311 [details]
> patch
>
> Note that apart from the possible bad impact on optimization when fixing this
> bug an actual fix is complicat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671
--- Comment #3 from Richard Biener ---
The question is whether the standard allows eliding of the side-effect setting
newCalled to true.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94546
Richard Biener changed:
What|Removed |Added
Known to work||9.3.0
--- Comment #3 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94549
Richard Biener changed:
What|Removed |Added
Known to work||9.3.0
--- Comment #2 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94583
Richard Biener changed:
What|Removed |Added
Priority|P1 |P2
--- Comment #3 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94592
Richard Biener changed:
What|Removed |Added
Known to work||9.3.0
--- Comment #9 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92430
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|9.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90591
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
Richard Biener changed:
What|Removed |Added
Blocks||53947
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #27 from Richard Biener ---
(In reply to Richard Biener from comment #24)
> (In reply to Richard Biener from comment #22)
> > Created attachment 48311 [details]
> > patch
> >
> > Note that apart from the possible bad impact on optimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
--- Comment #14 from Richard Biener ---
(In reply to Joel Yliluoma from comment #13)
> GCC 4.1.2 is indicated in the bug report headers.
> Luckily, Compiler Explorer has a copy of that exact version, and it indeed
> vectorizes the second function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.4
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675
Richard Biener changed:
What|Removed |Added
Known to fail||10.0, 9.3.0
Summary|[9 regre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
Richard Biener changed:
What|Removed |Added
Priority|P1 |P2
--- Comment #31 from Richard Biener
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
IPA SRA should elide 'out' in
struct outs { int kind; int i; };
void foo (struct outs *out)
{
if (out->kind == 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94693
Richard Biener changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
Ke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94693
Richard Biener changed:
What|Removed |Added
Blocks||90591
--- Comment #1 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94693
--- Comment #2 from Richard Biener ---
Another testcase would be like
int foo (void **ret)
{
*ret = NULL;
return 0;
}
int bar ()
{
void *dummy;
return bar (&dummy);
}
int main()
{
void *dummy;
if (!foo (&dummy))
return 0;
ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94693
--- Comment #3 from Richard Biener ---
Or a bit more twisty
struct A { int key; double payload_A; };
struct B { int key; int payload_B; };
void foo (int *key)
{
switch (*key)
{
case 1:
((struct A *)key)->payload_A = 1.0;
break;
,
||rguenth at gcc dot gnu.org
--- Comment #2 from Richard Biener ---
Note in another bug it was said that libgfortran requires a C99 runtime, when
that's not available you should disable gfortran build. GCC (or libgfortran)
is in no position to disable par
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694
Richard Biener changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694
--- Comment #6 from Richard Biener ---
(In reply to Richard Earnshaw from comment #5)
> (In reply to Richard Biener from comment #2)
...
> > Since Fortran isn't release critical the only P1-ish part is that fortran
> > build is enabled on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512
--- Comment #28 from Richard Biener ---
Note a possibility would be to emit the packing/unpacking functions as
inline functions so whether inlining happens would be decided by the
middle-end inlining heuristics. That has the advantage of inlinin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92983
Richard Biener changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #8 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94703
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94703
Richard Biener changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94708
--- Comment #1 from Richard Biener ---
fold guards it with !HONOR_SIGNED_ZEROS && !HONOR_NANS
(fold_cond_expr_with_comparison). I think the flag_unsafe_math_optmizations
check is bogus.
Note we now have fmax/fmin named patterns that can be used
at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #3 from Richard Biener ---
ACtually I'll give it a quick try.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94703
--- Comment #4 from Richard Biener ---
Created attachment 48335
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48335&action=edit
untested patch
Patch, easier than expected. Possibly needs some adjustment to the gimplifier,
we'll see.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94279
--- Comment #2 from Richard Biener ---
set_noop_p is clearly buggy here, expecting a constant selector
/* It is a NOOP if destination overlaps with selected src vector
elements. */
if (GET_CODE (src) == VEC_SELECT
&& REG_P (XEXP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94718
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-04-23
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94725
Richard Biener changed:
What|Removed |Added
CC||jvdelisle2 at outlook dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94727
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
--- Comment #2 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94727
--- Comment #3 from Richard Biener ---
(In reply to Richard Biener from comment #2)
> test() is basic-block vectorized on the c-loop body which has the d- and
> e-loops
> completely unrolled. We create some weird
>
> mask__84.17_18 = vect_cst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94715
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94728
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93507
--- Comment #2 from Richard Biener ---
The fix for PR94703 at least makes RTL optimze it to
foo:
.LFB0:
.cfi_startproc
movl%edi, %eax
ret
GIMPLE is still
foo (unsigned int x)
{
long unsigned int dst;
long unsign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94715
Richard Biener changed:
What|Removed |Added
Keywords|wrong-code |missed-optimization
Summary|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94727
--- Comment #6 from Richard Biener ---
(In reply to rsand...@gcc.gnu.org from comment #5)
> Well, this is a bit of mess (surprise). We have a "<" comparison
> between two booleans that are leaves of the SLP tree, so
> vectorizable_comparison fal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645
--- Comment #23 from Richard Biener ---
So the issue is we're both not doing enough and too much, the half way early
optimizations do confuse us later. Another such opportunity would maybe
be:
short unsigned int _950;
_950 = BIT_FIELD_REF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94741
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
--- Comment #8 from Richard Biener ---
In particular tree_could_trap_p woudl consider the load possibly trapping
due to the variable indexing but the patch seems to override that which
I agree is bogus. I think we need to revert it and re-implem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
--- Comment #9 from Richard Biener ---
(In reply to Richard Biener from comment #8)
> In particular tree_could_trap_p woudl consider the load possibly trapping
> due to the variable indexing but the patch seems to override that which
> I agree is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94726
Richard Biener changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
--- Comment #15 from Richard Biener ---
(In reply to Jakub Jelinek from comment #13)
> Even better.
Note none of the committed testcases would be handled with this. There's
also the issue of store data races (not sure if the notrap handling is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94708
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #41 from Richard Biener ---
If this is now fixed can you close the bug as such please, John?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94745
Richard Biener changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91518
Richard Biener changed:
What|Removed |Added
Known to fail||9.3.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94755
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94757
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-04-27
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94762
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94767
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic, wrong-code
Ever confirm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94772
Richard Biener changed:
What|Removed |Added
Keywords||rejects-valid
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94775
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
Richard Biener changed:
What|Removed |Added
Status|REOPENED|NEW
--- Comment #7 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94780
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.5
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94782
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94783
Richard Biener changed:
What|Removed |Added
Component|tree-optimization |middle-end
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94781
Richard Biener changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #4 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94785
Richard Biener changed:
What|Removed |Added
Component|tree-optimization |middle-end
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #28 from Richard Biener ---
OK, so more "advanced" testcases are a bit difficult because the
ref_always_accessed_p logic is too simple and it's required for
store-motion of accesses in conditional paths. Basically if
we have if (test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #29 from Richard Biener ---
And another testcase showing that with a conditional invariant store we may
_never_ apply store-motion since conditional means we do not know the
original order of stores in the loop. *sigh*
typedef int A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94793
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94792
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94790
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-04-27
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94789
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-04-27
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94787
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-04-27
Status|UNCONFIRM
401 - 500 of 49442 matches
Mail list logo
