https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118469
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118468
Andi Kleen changed:
What|Removed |Added
Summary|vectorizer: extra phi |vectorizer: if conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95834
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118468
Bug ID: 118468
Summary: vectorizer: extra phi blocks vectorization of if
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118373
--- Comment #13 from Andi Kleen ---
If it immediately reboots (and you didn't use panic=XXX to reboot quickly) then
it might be a triple fault. These are unfortunately harder to debug because
they don't produce any console output in a native set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118373
--- Comment #8 from Andi Kleen ---
Classical "make photo of panic" screen method should be enough.
The critical part is the Code: line that shows the bad instruction, and the
name of the function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106883
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118289
--- Comment #2 from Andi Kleen ---
Yes sorry for the dup.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118289
Bug ID: 118289
Summary: Using new crc builtins leads to ICE on x86_64
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118288
Bug ID: 118288
Summary: Using new crc builtins on i386 leads to ICE
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118198
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118250
--- Comment #2 from Andi Kleen ---
With
--param=switch-lower-slow-alg-max-cases=1
(so using greedy) trunk includes "38" in the first bit cluster, but the LLVM
code is still better. I've seen the dynamic programing algorithm miss clusters
like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118252
Bug ID: 118252
Summary: i386 should implement CASE_VECTOR_SHORTEN_MODE
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118251
Bug ID: 118251
Summary: i386: Use carry bits of shifts
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118168
--- Comment #11 from Andi Kleen ---
Fix posted here:
https://inbox.sourceware.org/gcc-patches/20241227024559.2224623-1-a...@firstfloor.org/T/#t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118211
Bug ID: 118211
Summary: tree-vectorize: vectorize input.cc, find_end_of_line
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113149
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118050
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118168
--- Comment #10 from Andi Kleen ---
My earlier analysis was wrong. The file cache is exactly supposed to avoid
this quadratic case.
But the cache only works if the linemap knows the total number of lines,
otherwise it uses a much slower fallba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118168
--- Comment #9 from Andi Kleen ---
Created attachment 59954
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59954&action=edit
add tunables for file cache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118168
--- Comment #8 from Andi Kleen ---
Oh actually it's not the beginning, but some point file size / 100 (the scaled
down line cache)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118168
--- Comment #7 from Andi Kleen ---
Actually in my case where i interrupted and the difference was 60k i think the
problem was that the lexer offset was beyond the 100 lines where the position
is cached, and when that happens the file_cache just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118168
--- Comment #6 from Andi Kleen ---
So the file cache has a window of 100 lines:
static const size_t line_record_size = 100;
The indentation code rereads the line of the guard, body, next statement and
that is all cached if it's all within 100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118168
--- Comment #3 from Andi Kleen ---
never mind, i had an old compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118168
--- Comment #1 from Andi Kleen ---
Did you attach the correct file? I get
mypy.c:9524:5: error: implicit declaration of function
‘__builtin_c23_va_start’; did you mean ‘__builtin_ms_va_start’?
[-Wimplicit-function-declaration]
9524 | __bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117091
--- Comment #9 from Andi Kleen ---
Yes I guess we should keep better switches at -O1 because machine generated
code may have lot of switches.
I don't think we need perfect clustering? Perhaps there is some heuristic that
is good enough. Maybe j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117091
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116970
Bug ID: 116970
Summary: -ftime-report -fdiagnostics-format=sarif-file causes
ICE
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116520
--- Comment #7 from Andi Kleen ---
Tamas also gave this example in PR115866 which shows the same problem:
short a[100];
int foo(int n, int counter)
{
for (int i = 0; i < n; i++)
{
if (a[i] == 1 || a[i] == 2 || a[i] == 7 || a[i]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115866
--- Comment #8 from Andi Kleen ---
It doesn't even try to convert the switch because of
t.c.179.ifcvt:
Can not ifcvt due to multiple exits
if (loop->num_nodes > 2)
{
/* More than one loop exit is too much to handle. */
if (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116599
Bug ID: 116599
Summary: volatile generates unexpected RMW on global
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116545
Bug ID: 116545
Summary: Support old style statement attributes
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116520
Andi Kleen changed:
What|Removed |Added
Summary|incorrect |Multiple condition lead to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116520
Bug ID: 116520
Summary: incorrect
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116500
--- Comment #4 from Andi Kleen ---
It seems sparc doesn't support comparisons in vectorization?
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-switch-ifcvt-1.c:13:7:
missed: not vectorized: relevant stmt not supported: _13 = _1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116500
--- Comment #2 from Andi Kleen ---
Do you have the dump file from tree-vect?
I guess it just doesn't vectorize something here.
The right fix is probably to skip it for sparc, or adjust the vect_int target
test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
Andi Kleen changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
--- Comment #21 from Andi Kleen ---
As HJ pointed out the change is not needed, the compiler DTRT with
no_callee_saved_registers on the callees.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
--- Comment #16 from Andi Kleen ---
Created attachment 59013
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59013&action=edit
test case
This test case using Pinski's clobber trick shows the benefit.
If you compile with -O2 -mgeneral-regs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
--- Comment #1 from Andi Kleen ---
Disable check for no_caller_saved_registers enforcing non FP.
diff --git a/gcc/config/i386/i386-options.cc b/gcc/config/i386/i386-options.cc
index f79257cc764..cec652cc9e6 100644
--- a/gcc/config/i386/i386-opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
Bug ID: 116497
Summary: Need no_caller_saved_registers with SSE support
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116285
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71672
Andi Kleen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116264
Bug ID: 116264
Summary: Spurious {NF}s in APX code
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115866
Andi Kleen changed:
What|Removed |Added
Attachment #58804|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166
--- Comment #13 from Andi Kleen ---
Created attachment 58842
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58842&action=edit
add a param to limit BBs for dominator pass
Maybe something like this patch. It adds a check to disable the dom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116191
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115866
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116163
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
Andi Kleen changed:
What|Removed |Added
Attachment #58761|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
--- Comment #8 from Andi Kleen ---
Patch was reverted, it just made a bunch of tests unsupported.
problems:
- Need unique name for each new test to not confuse the caching
- -O0 tests need to use musttail explictly because the musttail pass
onl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116019
Andi Kleen changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116019
Andi Kleen changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116126
Bug ID: 116126
Summary: vectorize libcpp search_line_fast
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116019
Andi Kleen changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
--- Comment #6 from Andi Kleen ---
Created attachment 58761
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58761&action=edit
Improve test suite tail call checks
This patch should fix it. We must run the test suite tail call probes without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116087
Bug ID: 116087
Summary: Add optional warning for too large macro expansion
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
--- Comment #2 from Andi Kleen ---
Also can you upload the whole log files somewhere? I would like to see what the
output of check_effective_target_struct_tail_call is. It should have caught
some of these problems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
--- Comment #1 from Andi Kleen ---
Yes it is known that powerpc (or some flavors of it) has poor tail call support
due to ABI limitations.
Just need to figure out how to skip the test. I guess it needs a better test in
check_effective_target_ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116014
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116047
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83355
Andi Kleen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116019
Bug ID: 116019
Summary: Incorrect cannot-tail messages on targets
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324
--- Comment #19 from Andi Kleen ---
Middle/back-end parts are in, still need acks for the C/C++ frontend parts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115979
--- Comment #3 from Andi Kleen ---
Doing it in the frontend would require some duplication between C/C++ at least?
I was thinking to just keep searching if has_mustail is set, but was wary of
endless loops walking single basic block precessors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115255
Andi Kleen changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115979
Bug ID: 115979
Summary: Implicitly generated C++ calls stop musttail search
early
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115813
--- Comment #2 from Andi Kleen ---
Is that the right pattern for the example? It looks different
Enabling match.pd debugging for the scalar version shows:
taddbit.c.034t.ccp1:Applying pattern match.pd:3960, gimple-match.cc:18437
taddbit.c.034t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115813
Bug ID: 115813
Summary: missing constant evaluation for vectors
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115274
--- Comment #10 from Andi Kleen ---
-fno-thread-jumps fixes it, so it's probably a dup of PR109071 (same problem
with a different warning)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115274
--- Comment #8 from Andi Kleen ---
Ah never mind. I ran it with the wrong option with -O3 it shows the warning.
Unfortunately the run time is very long so it will be difficult to minimize.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115274
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79465
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115344
--- Comment #5 from Andi Kleen ---
Also the other problem is that doloop optimization is only for known bounds,
while generic reversal works for unknown too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115344
--- Comment #4 from Andi Kleen ---
Pedantry aside the basic problem is that doloop optimization depends on the
target supporting doloop, but the loop reversal would be useful everywhere.
So there are two options: add doloop to every target of i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115606
Andi Kleen changed:
What|Removed |Added
Target|arm-*-* |
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115344
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115606
Bug ID: 115606
Summary: return slot opt prevents tail calls
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63384
Andi Kleen changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85099
Bug 85099 depends on bug 63384, which changed state.
Bug 63384 Summary: scheduler loops on endless fence list with
-fselective-scheduling2 on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63384
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115484
--- Comment #6 from Andi Kleen ---
As an interesting but irrelevant side comment clang seems to have the same bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115584
Andi Kleen changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115584
Bug ID: 115584
Summary: Boot strap comparison failure on trunk with
--enable-checking=release
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324
--- Comment #14 from Andi Kleen ---
Latest patchkit is here, but stalled due to lack of reviewers:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653319.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115496
--- Comment #6 from Andi Kleen ---
Yes a # check would need to be target dependent.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115496
--- Comment #3 from Andi Kleen ---
When writing inline assembler an alternative to \n is to use ; as separator
e.g.
asm("movl $1,%eax ; "
"movl %eax,%ebx")
there can be also comment mistake here like
asm("movl $1,%eax # comment ;"
"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115496
--- Comment #2 from Andi Kleen ---
It would need some heuristic that if the line nearly fills a standard line
length (how defined) don't trigger it. Otherwise people breaking the string due
to line length restrictions might trigger it incorrectl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115484
Bug ID: 115484
Summary: AVX vectorization is limited to 3 comparisons
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113723
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63556
--- Comment #7 from Andi Kleen ---
I'm not sure how it would speed up the linker if gcc did it. The linker would
still need to do it because there might be matches between different .o files.
Also linker wouldn't know if the compiler supported th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68615
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82013
Andi Kleen changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80742
Andi Kleen changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63556
Andi Kleen changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30688
Andi Kleen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80379
--- Comment #5 from Andi Kleen ---
This bug is about printing a unnecessary message. If your code is actually
miscompiled even with -fno-strict-aliasing set (so it is ignored somewhere) it
is something different and you would need a test case to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115255
--- Comment #7 from Andi Kleen ---
The patch can be even more minimized. The thumb2_reorg change is not needed
because nothing does df_verify() after it (I just noticed it because I added
some extra for debugging). So even though thumb2_reorg br
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115255
--- Comment #6 from Andi Kleen ---
Created attachment 58324
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58324&action=edit
patch to fix arm sibcalls with -O0
Better patch that uses the existing cfun flag for tail calls.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115255
--- Comment #4 from Andi Kleen ---
Created attachment 58323
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58323&action=edit
hack patch to fix arm sibcalls at -O0
The attached patch makes the test case pass on arm.
- Some of the sibcall
1 - 100 of 114 matches
Mail list logo
