http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50786
Bug #: 50786
Summary: temporary files not cleaned up on LTO errors
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Prior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50786
--- Comment #2 from Andi Kleen 2011-10-19
14:40:53 UTC ---
I'm not 100% sure which stage generates them, but I have lots of
cc*.o and some others (.res etc.) left over after the LTRANS failure.
After two failures in a row i always have a full /.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50786
--- Comment #4 from Andi Kleen 2011-10-19
15:28:07 UTC ---
I'm not, this was a normal lto bootstrap without any special flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50636
Andi Kleen changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #7 from Andi Kleen 2011-10-20
05:53:49 UTC ---
Can someone mark this as a regression please? This still keeps crashing and
crashing.
I don't see why I need to debug a clear regression when I already bisected
it.
IMHO this should be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #9 from Andi Kleen 2011-10-20
14:05:49 UTC ---
Previously the builds produced working code. Now they just segfault.
If I revert the patches (plus the ones depending on it) I get working
code again.
In my book that's a "fix". I don't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #11 from Andi Kleen 2011-10-20
16:30:27 UTC ---
I did fire gdb up of course, the output is in the initial report.
I also tracked it down to exactly your commit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #13 from Andi Kleen 2011-10-20
16:44:42 UTC ---
I only have a core file. It's really hard to catch the correct lto1
in gdb in a complex LTO build. The only sane way I found to at least
get some gdb information is to use -dH and use th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50824
Bug #: 50824
Summary: memset or memcpy on structure prevents SRA
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #14 from Andi Kleen 2011-10-29
11:31:31 UTC ---
Created attachment 25658
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25658
3 files
I managed to reduce a test case to 3 LTO files now
unpack the tar on x86-64 and
gcc47 -O2 -fl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
--- Comment #7 from Andi Kleen 2011-10-29
12:12:09 UTC ---
Created attachment 25659
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25659
reproducer
Managed to minimize now
Unpack the tar file and on x86-64
% gcc47 -m32 -O2 -flto arch/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45631
--- Comment #3 from Andi Kleen 2011-10-30
02:33:29 UTC ---
Honza, any further ideas how to proceed? Should the threshold just be lowered?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
--- Comment #9 from Andi Kleen 2011-10-30
15:53:10 UTC ---
Sorry made a mistake and i supplied the wrong command line
With this
gcc47 -O2 -m32-freg-struct-return io_apic.i -flto -c
gcc47 -O2 -flto io_apic.o
the test case ICEs hwith any pat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49934
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49677
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
--- Comment #13 from Andi Kleen 2012-05-02
14:23:57 UTC ---
This still happens with a recent 4.7 and bites 32bit Linux kernel builds badly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53126
--- Comment #4 from Andi Kleen 2012-05-02
20:04:50 UTC ---
Patch looks good. Thanks Jakub.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
--- Comment #17 from Andi Kleen 2012-05-03
14:57:13 UTC ---
Hmm, my assumption was always that this option would be passed through and then
used by lto1 step. That's true for other -f* options at least.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53291
--- Comment #3 from Andi Kleen 2012-05-09
17:17:56 UTC ---
Correction. We can keep the xor %reg,%reg. We just need it because setnz only
sets 8 bit to initialize the higher order bits.
Alternatively the value can be zero extended afterwards or
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315
Bug #: 53315
Summary: simple xtest program generates ICE
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315
Andi Kleen changed:
What|Removed |Added
CC||kirill.yukhin at intel dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53291
--- Comment #6 from Andi Kleen 2012-05-10
22:52:30 UTC ---
Uros patch fixes it and the code is correct now. Please commit.
However in testing it I quickly hit PR53315
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53291
--- Comment #9 from Andi Kleen 2012-05-11
03:36:11 UTC ---
The example in PR53315 is a runtime test case, except:
- it needs cpuid checks to be part of the test suite
- the printfs need to be replaced with asserts
- it needs to stop iceing first
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315
--- Comment #8 from Andi Kleen 2012-05-11
18:02:43 UTC ---
I tested HJs fix on the test case and also on a more complex program and it all
works as expected. Please commit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315
--- Comment #9 from Andi Kleen 2012-05-11
21:35:47 UTC ---
Sorry I was wrong earlier. Retested now fully with a full test case and HJs
patch and i always get aborts
The xbegin gets miscompiled now, the in transaction branch disappears.
400460
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315
--- Comment #14 from Andi Kleen 2012-05-12
16:04:27 UTC ---
I can confirm the simple test program works correctly with Jakub's patch.
I'll leave full bootstrap to HJ.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315
--- Comment #15 from Andi Kleen 2012-05-12
16:06:00 UTC ---
Oh yes and it would be really nice to have those peepholes for xbegin Jakub.
I normally use my own macros with asm goto to avoid the ugly code.
Do you think machine reorg could be done
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53404
Andi Kleen changed:
What|Removed |Added
Component|c |preprocessor
--- Comment #1 from Andi Kleen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53404
Bug #: 53404
Summary: warning column reported on comment in warning during
bootstrap
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831
--- Comment #21 from Andi Kleen 2012-07-04
12:24:45 UTC ---
For non fat ("slim") LTO builds you need to use these tools yes. ar needs to
know the symbol table for its index and that needs LTO specific knowledge.
This follows other slim lto compi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54095
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52762
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56912
--- Comment #6 from Andi Kleen ---
Seems to be fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51109
Bug #: 51109
Summary: bdver1 scheduler state machine too large
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
--- Comment #10 from Andi Kleen 2011-11-23
00:22:46 UTC ---
FWIW the problem is still there and prevents any 32bit kernel LTO builds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51417
--- Comment #2 from Andi Kleen 2011-12-07
18:54:57 UTC ---
Hmm, you mean a copy with the version number in addition? Would be reasonable I
guess.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
--- Comment #12 from Andi Kleen 2012-01-08
01:37:29 UTC ---
LTO saves the options in the object files and collects them for the final
link. This works as far as I know.
The only thing it cannot handle is different incompatible options in differe
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
Don't have a small test case currently, happens during a large LTO Linux kernel
build.
With gcc trunk (20181222) with checking en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88573
--- Comment #1 from Andi Kleen ---
Created attachment 45281
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45281&action=edit
test case (unminimized)
gcc-9 -O2 -S -flto arch/x86/events/intel/pt.i
/home/ak/lsrc/linux/arch/x86/events/intel/pt
nt: c
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
gcc 9 added -Wpacked-not-aligned to Wall. In Linux kernel builds this warning
is very noisy. There's a Linux kernel patch now to disable it. But I suspect
other soft
Priority: P3
Component: target
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=88622
Andi Kleen changed:
What|Removed |Added
Target||x86_64-linux
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88622
Andi Kleen changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #3 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88622
--- Comment #4 from Andi Kleen ---
Ok that means that this code you pasted in ix86_option_override_internal
somehow doesn't get executed correctly for LTO switching between different
options.
Adding Honza.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86404
--- Comment #4 from Andi Kleen ---
Does something like this help?
(untested, cut-n-pasted, possibly with other values)
iff --git a/gcc/config/i386/gcc-auto-profile b/gcc/config/i386/gcc-auto-profile
index 5da5c63cd845..8744b9f091df 100755
--- a/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50639
--- Comment #2 from Andi Kleen ---
FWIW the problem disappeared for me at some point (could have been newer kernel
or different make). I don't see it anymore.
I think it was some problems with the pipes used by the job server losing a
token
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50639
--- Comment #4 from Andi Kleen ---
I doubt it's fixed. It's a race so can be unstable.
Especially since judging from the growing cc list other people keep seeing it
It may not be something that gcc can fix, if anything it's more likely in make
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Created attachment 42820
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42820&action=edit
test case
Attached te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83346
--- Comment #1 from Andi Kleen ---
This fixes it. Don't know why that node has no decl.
Will submit after a test cycle.
diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
index 7846e93d119..dcd8a3de1ac 100644
--- a/gcc/ipa-inline.c
+++ b/gcc/ipa-
: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Running in gdb shows that there is a very deep recursion in get_index_by_decl
until it overflows the stack.
This
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Created attachment 42842
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42842&acti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83375
--- Comment #1 from Andi Kleen ---
Actually -flto-partition=max
: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Don't have a small test case right now, but will bisect
When building Linux kernel LTO with gcc 8 I currently get an ICE. Doesn't
happen on 7 a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83355
--- Comment #3 from Andi Kleen ---
patch checked in
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
lto1: fatal error: error writing to vmlinux.ltrans15.s: No space left on device
gcc: internal compiler error: Aborted signal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83376
Andi Kleen changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Created attachment 42844
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42844&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83346
--- Comment #3 from Andi Kleen ---
Fixed by https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00764.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83397
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
The ELF section from the previous function doesn't get reset before top level
asm statements:
e.g.
__attribute__((section("foo"))) void func(void)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83375
--- Comment #6 from Andi Kleen ---
This breaks Linux kernel LTO builds. I currently have a workaround (disabling
LTO for that file), but I don't think your "is not common" argument is valid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61727
--- Comment #4 from Andi Kleen ---
This was originally about the #pragma simd in CIlk+, which has been removed.
But it lives on in #pragma omp simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42587
--- Comment #11 from Andi Kleen ---
Only when the first test case is fixed too
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
Target: x86_64
On x86, when using a builtin that is not supported by the target configuration,
e.g.
gcc -c -m32 -ptwrite t.c.c
with t.c being
void f(void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88096
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88231
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88277
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55461
Bug #: 55461
Summary: _mm_loadu_si128 generates wrong instruction on 4.8
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55461
--- Comment #2 from Andi Kleen 2012-11-25
18:07:49 UTC ---
That's a design not matching the hardware then -- read up on reformatting
penalties.
Also the way the rule in the md file is written it more looks like a bug to me.
It seems to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55461
Andi Kleen changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55947
Bug #: 55947
Summary: non constant memory models lose HLE qualifiers
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55948
Bug #: 55948
Summary: __atomic_clear / __atomic_store_n ignore HLE_RELEASE
flags
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55947
--- Comment #2 from Andi Kleen 2013-01-11
22:01:49 UTC ---
I would probably add at least a warning. The whole concept of a runtime
switched memory barrier is imho ill-defined.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966
Bug #: 55966
Summary: __atomic_fetch_* generate wrong code for HLE
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966
--- Comment #1 from Andi Kleen 2013-01-14
19:06:02 UTC ---
Here's a test case. This requires the libstdc++ HLE patch from
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00673.html
g++ -std=gnu++0x
#include
#define ACQ memory_order_a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966
--- Comment #2 from Andi Kleen 2013-01-14
19:52:03 UTC ---
Created attachment 29163
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29163
preprocessed testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966
Andi Kleen changed:
What|Removed |Added
Attachment #29163|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966
--- Comment #6 from Andi Kleen 2013-01-14
22:05:38 UTC ---
Hmm that's true. x86 doesn't have xand, x_or, x_xor, only xadd
Maybe cmpxchg is the only way?
For some special cases it can be done (like and single bit-> btr, or single bit
->
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966
--- Comment #8 from Andi Kleen 2013-01-14
22:32:06 UTC ---
forbid = give warning and drop bit
It's a hint, but in a good implementation it should not be silently dropped or
code generated that has no chance to elide. It's a quality of im
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17886
--- Comment #25 from Andi Kleen 2013-01-14
22:32:59 UTC ---
Also i need to look more closely, but most likely the C++ atomic code should be
changed to avoid this situation. This would give much better code on x86 in any
case even without e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966
--- Comment #9 from Andi Kleen 2013-01-14
22:34:16 UTC ---
Also i need to look more closely, but most likely the C++ atomic code should be
changed to avoid this situation. This would give much better code on x86 in any
case even without el
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17886
--- Comment #26 from Andi Kleen 2013-01-14
22:37:34 UTC ---
Sorry commented on the wrong bug. ignore.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55233
--- Comment #2 from Andi Kleen 2013-01-21
01:22:14 UTC ---
Oops typo, I'll fix the ChangeLog
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
I've been working on building gcc with an autofdo bootstrap.
Currently I always run into an crash while rebuilding tree.c with the stage2
compiler and the au
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70427
--- Comment #1 from Andi Kleen ---
Created attachment 38109
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38109&action=edit
ipa-profile input
Here's the source of the miscompiled file from the compiler
cc1plus -O2 ipa-profile.i -S
unfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70427
--- Comment #2 from Andi Kleen ---
Created attachment 38110
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38110&action=edit
somewhat reduced input file, only single function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70427
--- Comment #3 from Andi Kleen ---
Analyzing the code more it looks like the compiler generates it correctly, the
edge returned should not be 0 here.
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
When doing API refactorings it is reasonable common to have too many or not
enough arguments in function calls. The existing errors in gcc/g++ are not very
good for
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
gcc gives quite poor error messages when forgetting a semicolon after a
prototype (common mistake when cut'n'pasting a function definit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80378
--- Comment #4 from Andi Kleen ---
I tested it now and the inline trick doesn't work. Here's a test case
extern void *do_alloc(int a, int b);
static inline __attribute__((alloc_size(1))) void check_alloc_size(int size)
{
}
static inline void *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80378
--- Comment #6 from Andi Kleen ---
In the kernel there is also an upper limit on allocations.
Perhaps just a generic assert builtin that:
- uses value range information
- uses constant propagation
- is a nop when the compiler doesn't have either
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80378
--- Comment #8 from Andi Kleen ---
__builtin_constant_p does not cover variable range information, which is what
we're looking for here to prevent security bugs.
Also in my experience these explicit expressions tend to be somewhat fragile
and is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77684
--- Comment #4 from Andi Kleen ---
Thanks for tracing that down.
So perf runs out of memory for the locked trace buffers
Increasing the limit is a good workaround
ulimit -l may also work, but also needs root.
We could just pass a smaller -m v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77684
--- Comment #5 from Andi Kleen ---
Created attachment 41337
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41337&action=edit
limit perf buffer size
This patch allows parallelism upto 16 with the default setting.
Currently testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79067
--- Comment #2 from Andi Kleen ---
There's a separate fix for the random failures (or w/a increase
/proc/sys/kernel/perf_event_mlock_kb), see PR 77684
Not running the test on systems without FDO seems best. I don't think it does
anything useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79067
--- Comment #3 from Andi Kleen ---
sandra,
does this patch fix it?
diff --git a/gcc/testsuite/gcc.dg/tree-prof/cold_partition_label.c
b/gcc/testsuite/gcc.dg/tree-prof/cold_partition_label.c
index 6214e3629f2..924a270e1bd 100644
--- a/gcc/testsu
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
Disabling ISAs with attribute target doesn't seem to work on x86_64
e.g.
typedef float __m128 __attribute__ ((vector_size (16)));
__attribute__((target("no-sse2"
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
I've been adding alloc_size attributes to the Linux kernel allocators.
However there are some allocator patterns that can currently n
: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
I get an extra
note: code may be misoptimized unless -fno-strict-aliasing is used
note for type mismatches in LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80378
--- Comment #1 from Andi Kleen ---
Small correction: argument 4 would need to be a constant for shifted by.
101 - 200 of 598 matches
Mail list logo
