--- Comment #1 from andi-gcc at firstfloor dot org 2010-06-08 09:38 ---
Ok unable to attach and I've been told reporting LTO bugs requires some magic
voodoo incarnations first.
If it helps here's the gdb information of the crash:
(gdb) pt var
(gdb) bt
#0 var_map_base
--- Comment #2 from andi-gcc at firstfloor dot org 2010-06-08 09:40 ---
The object files are at http://halobates.de/whopr-ice.tar.bz2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
noisy in kernel
builds
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot
--- Comment #3 from andi-gcc at firstfloor dot org 2010-06-09 10:13 ---
Sorry my example was not very good.
Anyways this typically happens with #ifdefs, so the some ifdef path
is actually using the variable, it's just not enabled in the current build.
In theory the ifdefs could b
--- Comment #4 from andi-gcc at firstfloor dot org 2010-06-09 10:55 ---
I was told that the whopr link step would inherit the optimization
flags from the build step. Is that not true?
Here's a reduced test case with only a single input file (reduced too)
gcc46 -O2 -fwho
--- Comment #5 from andi-gcc at firstfloor dot org 2010-06-09 10:56 ---
Created an attachment (id=20875)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20875&action=view)
reduced input file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
--- Comment #5 from andi-gcc at firstfloor dot org 2010-06-09 11:08 ---
Hmm yes there was another temporary and a inline inbetween
unsigned inlinefunc(void)
{
unsigned var;
asm(" ... " : "=r" (var));
return var;
}
#define macro(x,y)
{
unsigned var = inli
--- Comment #3 from andi-gcc at firstfloor dot org 2010-06-09 11:09 ---
Jakub, for this example: how would you suggest to work around this warning?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16427
--- Comment #16 from andi-gcc at firstfloor dot org 2010-06-09 11:21
---
I don't need a backport to 4.4 and I double checked it works as expected
in gcc 4.5. Closing.
--
andi-gcc at firstfloor dot org changed:
What|Removed |
--
andi-gcc at firstfloor dot org changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
--- Comment #9 from andi-gcc at firstfloor dot org 2010-06-09 12:16 ---
Unfortunate. Fixing that in the makefiles would be major effort for all the -f
and -m flags, which sometimes vary by target.
I thought LTO was designed to minimize makefile changes?
--
http://gcc.gnu.org
--- Comment #10 from andi-gcc at firstfloor dot org 2010-06-09 12:18
---
The tree input that leads to the NULL annotation is a "error_mark"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
--- Comment #13 from andi-gcc at firstfloor dot org 2010-06-09 13:35
---
What happens then when some files need different options that other files?
This sounds more and more like a showstopper if you're right.
I was not prepared to redesign the Makefiles
--
http://gcc.gn
--- Comment #14 from andi-gcc at firstfloor dot org 2010-06-09 13:42
---
I found this code in lto.c which seems to disagree:
/* Read the options saved from each file in the command line. Called
from lang_hooks.post_options which is called by process_options
right before all the
--- Comment #15 from andi-gcc at firstfloor dot org 2010-06-09 13:55
---
Ok seems it does not do what I want:
FIXME lto. Currently the scheme is limited in that only the
options saved on the first object file (f1.o) are read back during
the link step. This means that the
--- Comment #1 from andi-gcc at firstfloor dot org 2010-06-10 12:22 ---
I noticed that setting -fwhole-program on both compile and link stage
makes the weak problem go away. Expected?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44463
--- Comment #3 from andi-gcc at firstfloor dot org 2010-06-10 12:58 ---
On the link stage it's apparently not ignored and it fixes the weak
problem.
So just whatever weak magic -fwhole-program does would need to be done
when it's not enabled too.
--
http://gcc.gnu.or
--- Comment #16 from andi-gcc at firstfloor dot org 2010-06-10 13:20
---
I reduced another of my ICEs from this build and it's in the same place.
(gdb) bt
#0 var_map_base_init (map=0x10abe60) at ../../gcc/gcc/tree-ssa-live.c:87
#1 0x007248fb in coalesce_ssa_name
--- Comment #17 from andi-gcc at firstfloor dot org 2010-06-10 13:21
---
Created an attachment (id=20882)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20882&action=view)
other test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
--- Comment #19 from andi-gcc at firstfloor dot org 2010-06-11 17:09
---
Sorry you need -nostdlib too (forgot that)
-r is immediate linking
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
--- Comment #16 from andi-gcc at firstfloor dot org 2010-06-18 21:11
---
This turned out to be a kernel bug, rdtsc_barrier() needed to be marked
__force_inline, otherwise gcc would not inline this function.
(although it's slightly fishy for gcc too not inline a function that
onl
--- Comment #19 from andi-gcc at firstfloor dot org 2010-06-19 07:39
---
Technically I would say it was a kernel bug.
gcc can't really know how many instructions are there inside inline asm
so it's probably very conservative in its estimation.
So I would recommend t
--- Comment #21 from andi-gcc at firstfloor dot org 2010-06-19 12:23
---
This is the inline (after preprocessor)
I guess the many asm meta commands confuse the heuristic. Maybe it could
be fixed to ignore such commands.
static inline void rdtsc_barrier(void)
{
asm volatile ("6
--- Comment #23 from andi-gcc at firstfloor dot org 2010-06-19 13:13
---
It's two instructions with some metadata that controls patching these
instructions depending on the CPU capabilities.
Detecting that for gcc would be likely hard.
What would have also prevented this pr
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44899
--- Comment #1 from andi-gcc at firstfloor dot org 2010-07-10 08:15 ---
Error happens even without -j8, so no race
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44899
--- Comment #2 from andi-gcc at firstfloor dot org 2010-07-10 08:15 ---
Created an attachment (id=21171)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21171&action=view)
zlib config.log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44899
--- Comment #3 from andi-gcc at firstfloor dot org 2010-07-10 08:30 ---
What happens during the config stage is:
configure:2978: checking for C compiler default output file name
configure:3000: /home/andi/gcc/git/obj/./prev-gcc/xgcc
-B/home/andi/gcc/git/obj/./prev-gcc/
-B/pkg/gcc-4.6
--- Comment #5 from andi-gcc at firstfloor dot org 2010-07-10 08:40 ---
See comment #3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44899
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49282
Summary: malloc corruption in large lto1-wpa run during inline
edge heap resize
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49284
Summary: -fdump-ipa-cgraph leads to ICE in
generate_canonical_option, at opts-common.c:303
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priorit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49282
--- Comment #1 from Andi Kleen 2011-06-04
19:56:15 UTC ---
Some updates:
I tried with a fresh compiler (20110604). Same malloc assert
I also checked with a somewhat older compiler (from around May 11)
It segfaulted eventually too, so I suspect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49282
--- Comment #2 from Andi Kleen 2011-06-04
20:57:59 UTC ---
I found a workaround: disabling -fcoverage-arcs (gcov) makes it go
away.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49284
--- Comment #1 from Andi Kleen 2011-06-04
22:13:34 UTC ---
Some investigation:
This depends heavily on the command line used.
A simple test with a hello world works.
On my kernel build when I strip the lto link command line down I get
the erro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49284
--- Comment #2 from Andi Kleen 2011-06-05
23:43:07 UTC ---
FWIW I just commented out the offending assert and the option works
now.
Is that the correct fix?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49299
Summary: ICE in gimple_ic on profile feedback build
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49299
--- Comment #1 from Andi Kleen 2011-06-06
09:12:25 UTC ---
Created attachment 2
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=2
profile feedback input file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49299
--- Comment #3 from Andi Kleen 2011-06-06
09:50:49 UTC ---
Thanks I'll drop the noreturn as workaround
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49284
--- Comment #5 from Andi Kleen 2011-06-06
10:39:32 UTC ---
If you use my command line and just supply any random object files
for the ones specified it should reproduce I think.
If not i'll upload my builddir, but it's large.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48978
Andi Kleen changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49282
--- Comment #5 from Andi Kleen 2011-06-07
08:15:35 UTC ---
It seems GCOV is not the only cause. I just got the malloc corruption
again when building for 32bit (instead of 64bit), but still with gcov disabled.
So probably for the other build disab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49344
--- Comment #5 from Andi Kleen 2011-06-09
16:06:34 UTC ---
Hmm, it's hard to see how my patch could have caused this.
It doesn't really change any RTL.
Does the test case even use global registers?
I don't see any in native/fdlibm/strtod.c
The
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49341
--- Comment #5 from Andi Kleen 2011-06-13
02:45:50 UTC ---
Thanks for fixing. I should have gotten it done earlier.
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
icc and microsoft have a _xgetbv intrinsic for the XGETBV instruction, which is
needed to check if AVX or MPX are supported by the kernel.
gcc is missing an intrinsic for that, so
: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
The current mainline version of autofdo doesn't inline indirect calls based on
profiling data.
I instrumented a bootstrap and it never triggers.
gcc.dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828
--- Comment #3 from Andi Kleen ---
So what do you want to fix in the kernel?
Use a wrapper for taking the address of the memcpy?
(I hope nothing in gcc would remove such a wrapper)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45227
--- Comment #5 from Andi Kleen ---
I think it was the method from the info file.
But I can't quite remember. If you cannot reproduce it I guess it's ok to
close. Maybe I made some mistake.
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org,
mliska at suse dot cz
Target Milestone: ---
Created
ormal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
(not sure it's the middle-end, picked arbitrarily)
The following code
struct bf {
unsigned a : 10, b :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111743
--- Comment #2 from Andi Kleen ---
Okay then it doesn't understand that SHL_signed and SHR_unsigned can be
combined when one the values came from a shorter unsigned.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111743
--- Comment #5 from Andi Kleen ---
config/i386/i386.h:#define SLOW_BYTE_ACCESS 0
You mean it doesn't define it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116163
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115866
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116191
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
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=115866
Andi Kleen changed:
What|Removed |Added
Attachment #58804|0 |1
is obsolete|
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
Target: x86_64-linux
unsigned fclear(unsigned a, unsigned b)
{
if (a & (1 << 10))
b &= ~(1 << 20);
return b;
}
gives
c
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=116285
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
CC: hjl.tools at gmail dot com
Target Milestone: ---
Target: x86_64-linux
When writing threaded code interpreters by chaining functions with musttail the
normal
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
--- 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 #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
Andi Kleen changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
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=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
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116520
Andi Kleen changed:
What|Removed |Added
Summary|incorrect |Multiple condition lead to
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
Forked from PR83324. Applies to C/C++
It seems clang supports old style __attribute__ label attributes for musttail
(and presumably others) while gcc only supports the standard
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
On x86_64-linux:
volatile int a;
void f1(void)
{
a++;
}
int b;
void f2(void)
{
b++;
}
generates
f1:
movla(%rip), %eax
addl$1
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=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]
++
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
This blog post describes an interesting optimization technique for memory
access. https://mazzo.li/posts/value-speculation.html
A linked list walk is often be limited by the
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
Note to trigger this bug need to modify tree-tailcall to run at -O0 (which is
done for musttail), e.g. by the patches here:
https://gcc.gnu.org/pipermail/gcc
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
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 #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=107779
--- Comment #4 from Andi Kleen ---
This whole manual annotation idea (which is equivalent to marking the symbols
global and visible and that is what a large part of the kernel LTO patchkit) is
dead on arrival because the kernel people already re
: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
With recent trunk (019dc63819be)
When running the test suite on a Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113765
--- Comment #1 from Andi Kleen ---
Seems to be a regression, I tested the same setup on gcc 13 and the test passes
there:
55:PASS: gcc.dg/tree-prof/val-profiler-threads-1.c compilation,
-fprofile-generate -D_PROFILE_GENERATE
59:PASS: gcc.dg/tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113765
--- Comment #3 from Andi Kleen ---
-O1 fixes it, so an easy patch would be
diff --git a/gcc/auto-profile.cc b/gcc/auto-profile.cc
index 63d0c3dc36df..180ed7a8260f 100644
--- a/gcc/auto-profile.cc
+++ b/gcc/auto-profile.cc
@@ -1758,7 +1758,7 @@
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=30688
Andi Kleen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=80742
Andi Kleen changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|WAITING
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=68615
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=113723
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
With current trunk, but also older gcc
int f(char *s)
{
int c = 0;
int i;
for (i = 0; i < 64; i++) {
c |=
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=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 #6 from Andi Kleen ---
Yes a # check would need to be target dependent.
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
: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
On current trunk I get a bootstrap comparison failure between stage 2 and 3
with --enable-language=release on x86_64
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=115484
--- Comment #6 from Andi Kleen ---
As an interesting but irrelevant side comment clang seems to have the same bug.
401 - 500 of 598 matches
Mail list logo
