https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93302
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93303
Andrew Pinski changed:
What|Removed |Added
Depends on||93221
--- Comment #2 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93119
Andrew Pinski changed:
What|Removed |Added
Keywords||patch
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93313
--- Comment #1 from Andrew Pinski ---
So the problem here is the parser uses the standard stack and therefor limits
the max levels of nested parentheses. THIS IS NOT a bug really.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93221
--- Comment #2 from Andrew Pinski ---
So we have:
(insn 4 3 5 2 (set (reg:OI 92)
(subreg:OI (reg:V4SI 93) 0)) "t.c":9:1 3402 {*aarch64_movoi}
(expr_list:REG_DEAD (reg:V4SI 93)
(nil)))
(insn 5 4 7 2 (set (subreg:V4SI (reg:OI 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93221
Andrew Pinski changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93135
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93303
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93221
Andrew Pinski changed:
What|Removed |Added
Severity|normal |blocker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93221
Andrew Pinski changed:
What|Removed |Added
CC||doko at ubuntu dot com
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93242
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Target|mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93242
--- Comment #2 from Andrew Pinski ---
'(' Start a nested ".set noreorder" block.
')' End a nested ".set noreorder" block.
For some reason it is not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93242
--- Comment #3 from Andrew Pinski ---
The problem is here:
unsigned i;
for (i = 0; i < patch_area_size; ++i)
fprintf (file, "\t%s\n", nop_templ);
inside default_print_patchable_function_entry.
at gcc dot gnu.org |pinskia at gcc dot
gnu.org
--- Comment #4 from Andrew Pinski ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93242
Andrew Pinski changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91320
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67180
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59421
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56877
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55089
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49579
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55506
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53883
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80314
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53604
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78177
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77897
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48548
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66939
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33536
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36525
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36698
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36829
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36972
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31945
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46721
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46225
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54956
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92692
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20083
--- Comment #3 from Andrew Pinski ---
Here is another testcase which should produce the same code:
int f3(int i, int j, int l)
{
int t = i | j;
_Bool t1 = l != 0;
_Bool t2 = t ? 1 : t1;
return t2;
}
int f4(int i, int j, int l)
{
int t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20083
--- Comment #4 from Andrew Pinski ---
Take f4, if we compile with -O1 -fno-tree-sink, you will see the behavior we
get for f.
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Created attachment 47677
--> https://gcc.gnu.org/bugzi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93322
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.0
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93322
--- Comment #2 from Andrew Pinski ---
It worked with:
gcc version 9.0.0 20181231 (experimental)
g:c6579387bdc84adc76fbb0aa04e4942dd21d4ff0
Trying to do a git bisect right now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93322
Andrew Pinski changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93322
--- Comment #4 from Andrew Pinski ---
size_info->size = 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93321
--- Comment #1 from Andrew Pinski ---
I don't think this is a bug.
You requested inlining a lot. And that increases the number of basic blocks by
a lot because of recursive inlining.
I can decrease the stack recusriveness slightly by peeling of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93321
--- Comment #2 from Andrew Pinski ---
Created attachment 47679
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47679&action=edit
fully untested patch
This patch improves prepare_block_for_update but there might be others.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93321
--- Comment #3 from Andrew Pinski ---
Note prepare_block_for_update has been this way since 2005 with
g:0bca51f080dfff5e943b1f1775d874a73bbc441a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93321
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93321
Andrew Pinski changed:
What|Removed |Added
Keywords||patch
URL|
||2020-01-20
Component|target |tree-optimization
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #4 from Andrew Pinski ---
Mine for GCC 11.
I can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91753
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91753
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> If we had a way to generate XImode directly from 4 V16QI, and only generate
> one move statement, then the register allocator would act better.
That or split the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93242
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80028
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90722
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91753
--- Comment #7 from Andrew Pinski ---
(In reply to Wilco from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > lower-subreg should have be able to help here. I wonder why it did not ...
>
> I'm not sure how it can help. When you wr
: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
#define N 100
#define M
struct S { int a ; int b ; int c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93341
--- Comment #3 from Andrew Pinski ---
/* We should be able to reverse all conditions. */
gcc_assert (inv_cond_code != UNKNOWN);
Obvious this code is broken because The quiet UN* was converted into the an
unordered-si
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93321
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93359
--- Comment #1 from Andrew Pinski ---
In c++, it is undefined behavior if you fall through to the end of a function
without a return if the type is non void.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86761
Andrew Pinski changed:
What|Removed |Added
CC||volconscious at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90516
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #2 from Andrew Pin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86761
Andrew Pinski changed:
What|Removed |Added
CC||matszpk at interia dot pl
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90349
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #5 from Andrew Pin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93359
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91585
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #4 from Andrew Pin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86761
Andrew Pinski changed:
What|Removed |Added
CC||lucien.gentis at waika9 dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86761
Andrew Pinski changed:
What|Removed |Added
CC||matthijs at stdin dot nl
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89448
Andrew Pinski changed:
What|Removed |Added
CC||Keith.S.Thompson at gmail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91980
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93357
Andrew Pinski changed:
What|Removed |Added
Summary|Misleading diagnostic for |Misleading diagnostic for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67413
Andrew Pinski changed:
What|Removed |Added
Component|rtl-optimization|tree-optimization
--- Comment #2 from An
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68687
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93346
--- Comment #4 from Andrew Pinski ---
(In reply to andi from comment #3)
> > The bzhi patterns all match some odd if_then_else only to guard against
> > inx & 255 == 0:
>
> Is that guard needed? At least clang doesn't seem to care about it.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93350
--- Comment #1 from Andrew Pinski ---
Looks like make_region_for_type does not support VECTOR_TYPE at all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93119
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46555
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|pinskia at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33989
Andrew Pinski changed:
What|Removed |Added
Target||powerpc*-*
Component|middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93380
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-debug
Target|cortex a9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35629
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|pinskia at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30187
--- Comment #3 from Andrew Pinski ---
Here is the interesting thing:
#define vector __attribute__((vector_size(16)))
float f(vector float t, int i)
{
vector int tt = {i, i, i, i};
vector float r = __builtin_shuffle(t, tt);
return r[0];
}
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30187
Andrew Pinski changed:
What|Removed |Added
Status|NEW |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93384
Andrew Pinski changed:
What|Removed |Added
Keywords||assemble-failure
--- Comment #1 from And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93384
--- Comment #2 from Andrew Pinski ---
Can you use -save-temps and look at the generated assembler file in around
those two lines? This could be some inline-asm that causes the error too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
--- Comment #2 from Andrew Pinski ---
If we force d to be used after the mod. Then we get working code.
I suspect the inlininer is doing some kind of dce detection.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #3 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92810
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93399
Andrew Pinski changed:
What|Removed |Added
Target|x86_64-*-* |
--- Comment #3 from Andrew Pinski ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91882
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93399
--- Comment #4 from Andrew Pinski ---
dwarf2out.c:27492 or so
in dwarf2out_var_location.
I think ...
Here is a reduced testcase without any headers:
extern __inline __attribute__ ((__always_inline__)) __attribute__
((__gnu_inline__)) char *
strs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93177
--- Comment #12 from Andrew Pinski ---
If PowerPC back-end supported the "Flag Output Operands" part of GCC's
inline-asm, you could use that to do the correct thing. But sadly PowerPC does
not currently.
https://gcc.gnu.org/onlinedocs/gcc/Exten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91882
--- Comment #3 from Andrew Pinski ---
This is a job for reassociation pass really.
coming into that pass we have:
_1 = a_3(D) | b_4(D);
if (_1 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
_5 = a_3(D) &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93410
--- Comment #1 from Andrew Pinski ---
I doubt GCC 9 is going to change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418
Andrew Pinski changed:
What|Removed |Added
Component|regression |target
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418
--- Comment #2 from Andrew Pinski ---
The bug is most likely inside ix86_fold_builtin.
901 - 1000 of 16095 matches
Mail list logo
