https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
Richard Biener changed:
What|Removed |Added
Component|middle-end |libstdc++
--- Comment #2 from Richard B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Component|c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99114
--- Comment #4 from Eric Botcazou ---
> I'll try, but please consider investigating this without one. It happens
> after a very lengthy compilation process (compiling a buggy gcc with a buggy
> cross-compiler, then compiling JIT code with that, g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99116
Richard Biener changed:
What|Removed |Added
Priority|P2 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99114
--- Comment #3 from Richard Biener ---
If
(gtu (subreg:SI (reg:HI 593)) (const_int 1))
is incorrect, why is it then recognized? And why should (subreg:SI (and:HI
..))
be OK?
The way I read WORD_REGISTER_OPERATIONS it's a bad design to make th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99113
--- Comment #8 from Richard Biener ---
Well, certainly expected as you changed the semantics of 'used' ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99112
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99111
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99109
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99108
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #2 from R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99106
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Summary|ICE in tree_to_po
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
Bug ID: 99117
Summary: cannot accumulate std::valarray
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99116
Marek Polacek changed:
What|Removed |Added
Target Milestone|--- |11.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99116
Bug ID: 99116
Summary: [11 Regression] ICE in
set_identifier_type_value_with_scope, at
cp/name-lookup.c:4764
Product: gcc
Version: 11.0
Status: UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125
--- Comment #14 from Alan Modra ---
-fpatchable-function-entry isn't used by the powerpc linux kernel.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99114
--- Comment #2 from pipcet at gmail dot com ---
(In reply to Eric Botcazou from comment #1)
> Please provide a reproducer as documented in https://gcc.gnu.org/bugs
I'll try, but please consider investigating this without one. It happens after
a v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99111
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99113
H.J. Lu changed:
What|Removed |Added
Keywords||patch
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99114
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99115
Kurt Miller changed:
What|Removed |Added
Target||alpha-unknown-openbsd6.8
C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99115
--- Comment #1 from Kurt Miller ---
Created attachment 50192
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50192&action=edit
testcase preprocessed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99115
Bug ID: 99115
Summary: ICE in extract_insn, at recog.c:2309 on hppa (error:
unrecognizable insn) with -O2
Product: gcc
Version: 8.4.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98722
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98777
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
--- Comment #15 from Jan Hubicka ---
GCC10 testing time is:
Testing Time: 656.80s
Unsupported : 104
Passed : 21273
Expectedly Failed:26
I will see tomorrow if I can get GCC11 testing to finish.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99113
--- Comment #6 from H.J. Lu ---
Created attachment 50190
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50190&action=edit
A kernel patch to pass -fno-gnu-retain
This patch makes kernel to boot.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99113
H.J. Lu changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot
com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
Jan Hubicka changed:
What|Removed |Added
Summary|profile streaming scales|[11 regression] profile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98686
--- Comment #5 from Jerry DeLisle ---
The wording in the F2018 standard goes all the way back to F95. I do not plan
to put this behind any check for any particular standard.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99114
Bug ID: 99114
Summary: [WORD_REGISTER_OPERATIONS] wrong code for (u16_var &
3) == (u32)1
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99113
--- Comment #4 from Sergei Trofimovich ---
(In reply to H.J. Lu from comment #3)
> (In reply to Sergei Trofimovich from comment #2)
> > 3. I tried to add '.data.event*' (and similar) to linux ldscript and it was
> > not enough for me to built a k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99113
--- Comment #3 from H.J. Lu ---
(In reply to Sergei Trofimovich from comment #2)
> 3. I tried to add '.data.event*' (and similar) to linux ldscript and it was
> not enough for me to built a kernel that does not crash. Which might hint at
> binuti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99103
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Ever confi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99109
--- Comment #3 from Jakub Jelinek ---
array_bounds_checker::check_mem_ref certainly shouldn't try to pretend there is
any ARRAY_TYPE that wasn't in the source if the type is overaligned (its size
is not a multiple of the alignment).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99113
Sergei Trofimovich changed:
What|Removed |Added
CC||slyfox at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99109
Jakub Jelinek changed:
What|Removed |Added
Summary|[9/10/11 Regression] ICE: |[9/10/11 Regression] ICE:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99113
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2021-02-15
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99113
Bug ID: 99113
Summary: SHF_GNU_RETAIN doesn't work with Linux kernel
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99109
Marek Polacek changed:
What|Removed |Added
Target Milestone|--- |9.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99109
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99112
Bug ID: 99112
Summary: [11 Regression] ICE in gfc_conv_component_ref, at
fortran/trans-expr.c:2646
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99111
Bug ID: 99111
Summary: [10/11 Regression] ICE in gfc_conv_expr_descriptor, at
fortran/trans-array.c:7336
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99110
Bug ID: 99110
Summary: ICE in function_and_variable_visibility, at
ipa-visibility.c:716
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99108
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2021-02-15
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99109
Bug ID: 99109
Summary: [9/10/11 Regression] ICE: Error reporting routines
re-entered
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99108
Bug ID: 99108
Summary: ICE in ix86_get_function_versions_dispatcher, at
config/i386/i386-features.c:2862
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98872
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99088
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #46 from Rich Felker ---
It's a standard and completely reasonable assumption that, if you statically
linked libstdc++ into your shared library, the copy there is for *internal use
only* and cannot share objects of the standard librar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #45 from Florian Weimer ---
Statically linking libstdc++ into shared objects is also not too uncommon.
With luck, the libstdc++ symbols are hidden, but operating on globally shared
across multiple libstdc++s exposes similar issues ev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #44 from Rich Felker ---
Uhg. I don't know what kind of retroactive fix for that is possible, if any,
but going forward this kind of thing (assumptions that impose ABI boundaries)
should not be inlined by the template. It should just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99104
Jakub Jelinek changed:
What|Removed |Added
Attachment #50186|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86010
--- Comment #14 from Jeffrey A. Law ---
I believe it's still an issue for gcc-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98872
--- Comment #3 from CVS Commits ---
The master branch has been updated by Peter Bergner :
https://gcc.gnu.org/g:a33927c9ab4af3f4595251ce0c8ba54db821b039
commit r11-7249-ga33927c9ab4af3f4595251ce0c8ba54db821b039
Author: Peter Bergner
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99089
--- Comment #2 from Jim Wilson ---
I don't know if REE can do this optimization, but it is a good place to start
looking.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
--- Comment #13 from Jan Hubicka ---
> And please remeasure with the AppArmor disabled.
> It may slow down each I/O-related syscall rapidly!
I tried disabling apparmor and it does not make much difference..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99085
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 98863, which changed state.
Bug 98863 Summary: [11 Regression] WRF with LTO consumes a lot of memory in
REE, FWPROP and x86 specific passes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolutio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
--- Comment #12 from Jan Hubicka ---
> Ah, yeah, that will make a big difference.
> So clang is using 'make check', running a test-suite for a PGO build, right?
It uses
make check-llvm
make check-clang
and then it rebuilds whole llvm with the in
> Ah, yeah, that will make a big difference.
> So clang is using 'make check', running a test-suite for a PGO build, right?
It uses
make check-llvm
make check-clang
and then it rebuilds whole llvm with the instrumented compiler.
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99104
Jakub Jelinek changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment #4 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
--- Comment #11 from Martin Liška ---
> Yep, this is usual profile I see. Perhaps you want to try profile "make
> check"
Ah, yeah, that will make a big difference.
So clang is using 'make check', running a test-suite for a PGO build, right?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
--- Comment #10 from Martin Liška ---
> From the perf it seems that simply the syscall overhead plays important
> role (about 20% at kernel side, plus 9% on glibc side) followed by some
> stupidness of opensuse setup - apparmor and btrfs.
And pl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
--- Comment #9 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
>
> --- Comment #8 from Martin Liška ---
> This is what I see for GCC PGO in train stage. It's from perf top:
>
>4.33% cc1plus
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
>
> --- Comment #8 from Martin Liška ---
> This is what I see for GCC PGO in train stage. It's from perf top:
>
>4.33% cc1plus [.]
> __gcov_indirect_call_profiler_v4
> ◆
>2.28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
--- Comment #8 from Martin Liška ---
This is what I see for GCC PGO in train stage. It's from perf top:
4.33% cc1plus [.] __gcov_indirect_call_profiler_v4
◆
2.28% cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
--- Comment #7 from Jan Hubicka ---
> > Because user apps may do funny thins with stdio such as they do with
> > malloc. Fewer library stuff we rely on, the less likely we will hit the
> > problems. So I am not sure if simply fixing i/o isn't b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98863
--- Comment #47 from CVS Commits ---
The master branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:abe07a74bb7a2692eff2af151ca54e749ed5eba6
commit r11-7246-gabe07a74bb7a2692eff2af151ca54e749ed5eba6
Author: Richard Sandiford
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #43 from Jonathan Wakely ---
(In reply to Rich Felker from comment #42)
> I'm confused why this is an ABI boundary at all. Was the old implementation
> of std::call_once being inlined into callers?
Yes, it's a function template:
htt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
--- Comment #6 from Martin Liška ---
(In reply to Jan Hubicka from comment #5)
> > > So it effectively replaces gcov's own buffered I/O by stdio. First I am
> > > not sure how safe it is (as we had a lot of fun about using malloc)
> >
> > Why i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99107
Bug ID: 99107
Summary: Ignored inconsistent parameter/arguments types in
variadic templates
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
--- Comment #5 from Jan Hubicka ---
> > So it effectively replaces gcov's own buffered I/O by stdio. First I am
> > not sure how safe it is (as we had a lot of fun about using malloc)
>
> Why is not safe? We use filesystem locking for .gcda fil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99104
--- Comment #3 from Richard Biener ---
Well, at least if split() does not maintain DF then split patterns may not use
DF. It's as simple as that ;) Note you need DF analyze anyway since even
if present, the DF problem might be out-of-date.
Not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96252
--- Comment #6 from Jan Hubicka ---
Thinking of it, perhaps also inliner could take a hint that it is
inlining a tail call and do not produce unnecesary copy of the
functio parameter passed by value.
More generally, mod/ref has good chance to de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
--- Comment #4 from Martin Liška ---
(In reply to Jan Hubicka from comment #3)
> > A small improvement can be achieved by the removal of libgcov I/O buffering:
> > https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=5a17015c096012b9e43a8dd45768a8d5fb3a3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98791
--- Comment #3 from Alex Coplan ---
And here is a testcase (using SVE intrinsics) that ICEs without the param:
#include
extern char a[11];
extern long b[];
void f() {
for (int d; d < 10; d++) {
a[d] = svaddv(svptrue_b8(), svdup_u8(0));
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99106
Bug ID: 99106
Summary: ICE in tree_to_poly_int64, at tree.c:3091
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
--- Comment #3 from Jan Hubicka ---
> A small improvement can be achieved by the removal of libgcov I/O buffering:
> https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=5a17015c096012b9e43a8dd45768a8d5fb3a3aee
So it effectively replaces gcov's own buff
> A small improvement can be achieved by the removal of libgcov I/O buffering:
> https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=5a17015c096012b9e43a8dd45768a8d5fb3a3aee
So it effectively replaces gcov's own buffered I/O by stdio. First I am
not sure how safe it is (as we had a lot of fun about usin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #42 from Rich Felker ---
I'm confused why this is an ABI boundary at all. Was the old implementation of
std::call_once being inlined into callers? Otherwise all code operating on the
same once object should be using a common implement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95615
--- Comment #3 from Iain Sandoe ---
Actually, I don't think the example goes far enough.
ISTM, [on exception in the places noted] that non-trivial DTORs for frame
copies of parms should be run after the GRO and promise DTOR but before the
frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
--- Comment #2 from Martin Liška ---
Thank you for the bug report. It's really something we should improve for the
next GCC release.
A small improvement can be achieved by the removal of libgcov I/O buffering:
https://gcc.gnu.org/git/?p=gcc.git;a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
--- Comment #1 from Jan Hubicka ---
I use following:
cmake -G 'Unix Makefiles' /home/jan/llvm-project/llvm
-DCLANG_TABLEGEN=/home/jan/llmm-build2-lto-fdo/stage1/bin/clang-tblgen
-DCMAKE_AR=/home/jan/trunk-instal/bin/gcc-ar -DCMAKE_BUILD_TY
PE=Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99105
Bug ID: 99105
Summary: profile streaming scales poorly to projects with many
source files
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #10 from Uroš Bizjak ---
(In reply to Richard Biener from comment #7)
> There are a lot of targets that define REG_ALLOC_ORDER ^
> HONOR_REG_ALLOC_ORDER and thus are affected by this change...
The following patch should solve this is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #9 from Martin Jambor ---
I will benchmark the patch later this week, just so that we know, but I agree
that reverting the patch and applying it again at the beginning of stage1 is
probably the best.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #7 from Richard Biener ---
So
@@ -1661,6 +1662,7 @@ perform_tree_ssa_dce (bool aggressive)
if (aggressive)
{
/* Compute control dependence. */
+ connect_infinite_loops_to_exit ();
calculate_dominance_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #8 from Uroš Bizjak ---
(In reply to Richard Biener from comment #7)
> Btw, for GCC 11 it might be tempting to simply revert the "no-op" change?
I agree, this is the safest way at this time. The situation now looks like
going into ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #41 from Jonathan Wakely ---
The new std::call_once using a futex is not backwards compatible, so I think it
needs to be reverted, or hidden behind an ABI-breaking flag.
The new std::once_flag::_M_activate() function sets _M_once=1 w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99104
--- Comment #2 from Jakub Jelinek ---
Created attachment 50186
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50186&action=edit
gcc11-pr99104.patch
What a mess! Can we finally get rid of sel-sched?
The x86 backend uses DF inside of the sp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #7 from Richard Biener ---
Btw, for GCC 11 it might be tempting to simply revert the "no-op" change?
There are a lot of targets that define REG_ALLOC_ORDER ^ HONOR_REG_ALLOC_ORDER
and thus are affected by this change...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #6 from Uroš Bizjak ---
As a side note, it is strange that ADJUST_REG_ALLOC_ORDER somehow require
REG_ALLOC_ORDER to be defined (c.f. Comment #3), while its documentation says:
The macro body should not assume anything about the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98014
Tobias Burnus changed:
What|Removed |Added
Summary|[Fortran OpenACC] Empty |[Fortran][OpenACC][OpenMP]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99102
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99104
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #5 from Uroš Bizjak ---
Martin, can you please benchmark the patch from Comment #4?
The patch is not totally trivial, because it introduces HONOR_REG_ALLOC_ORDER
to x86 and this define disables some other code in ira-color.c,
assign_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #4 from Uroš Bizjak ---
Created attachment 50185
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50185&action=edit
Proposed patch
Proposed patch that fixes ira-color.c and introduces HONOR_REG_ALLOC_ORDER.
1 - 100 of 146 matches
Mail list logo
