https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99082
--- Comment #2 from Richard Biener ---
I wonder whether we need some bit-copy propagation or change the bswap pass to
track bits and not only bytes, producing then optimal bit shuffling
sequences...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922
Martin Liška changed:
What|Removed |Added
Target Milestone|11.0|12.0
--- Comment #7 from Martin Liška --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99079
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:70099a6acf5169eca55ef74549fb64de14e668f0
commit r11-7242-g70099a6acf5169eca55ef74549fb64de14e668f0
Author: Jakub Jelinek
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99079
Jakub Jelinek changed:
What|Removed |Added
Summary|Maybe a wrong code since|[8/9/10 Regression] Maybe a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #2 from Richard Biener ---
The following ira-color.c piece has heuristics that get triggered differently:
/* Return TRUE if spilling pseudo-registers whose numbers are in array
REGNOS is better than spilling pseudo-registers with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99084
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99085
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99087
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99089
--- Comment #1 from Richard Biener ---
isn't REE that pass?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99085
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99085
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|11.0|10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99092
Richard Biener changed:
What|Removed |Added
Component|fortran |target
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99092
--- Comment #2 from Martin Liška ---
The problem is very likely in LLVM assembler, GAS works fine.
Please take a look here:
https://reviews.llvm.org/D40011
Can you please paste the output of GCC invocation with --verbose argument?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99092
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99100
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2021-02-15
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
Bug ID: 99101
Summary: optimization bug with -ffinite-loops
Product: gcc
Version: og10 (devel/omp/gcc-10)
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99100
Richard Biener changed:
What|Removed |Added
Component|tree-optimization |target
--- Comment #2 from Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99092
Iain Sandoe changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99097
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99092
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=99092
--- Comment #6 from Iain Sandoe ---
(In reply to ktkachov from comment #5)
> I do think it's one of those LLVM assembler issues.
> Maybe it's due to the fact that "prfmPLDL1KEEP, [x0, -8]"
> is just the alias to the:
> prfum pldl1keep, [x0,
> I've just tried to reproduce it:
> ../configure --with-build-config=bootstrap-lto --enable-checking=release
> --disable-plugin
>
> But the build is fine for me.
On our dhcp230 (zen III machine) it works if you make system linker ld,
if system linker is gold (from tumbleweed) it fails
GNU gold (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99097
--- Comment #3 from Jan Hubicka ---
> I've just tried to reproduce it:
> ../configure --with-build-config=bootstrap-lto --enable-checking=release
> --disable-plugin
>
> But the build is fine for me.
On our dhcp230 (zen III machine) it works if y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
Richard Biener changed:
What|Removed |Added
Version|og10 (devel/omp/gcc-10) |11.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99100
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99097
--- Comment #4 from Richard Biener ---
Works on the branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99097
--- Comment #5 from Martin Liška ---
(In reply to Jan Hubicka from comment #3)
> > I've just tried to reproduce it:
> > ../configure --with-build-config=bootstrap-lto --enable-checking=release
> > --disable-plugin
> >
> > But the build is fine f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99083
--- Comment #3 from Uroš Bizjak ---
It looks to me another one is in reload1.c, find_reg:
if (this_cost < best_cost
/* Among registers with equal cost, prefer caller-saved ones, or
use REG_ALLOC_ORDER if
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99097
>
> --- Comment #5 from Martin Liška ---
> (In reply to Jan Hubicka from comment #3)
> > > I've just tried to reproduce it:
> > > ../configure --with-build-config=bootstrap-lto --enable-checking=release
> > > --disable-plugin
> > >
> > > But t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99097
--- Comment #6 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99097
>
> --- Comment #5 from Martin Liška ---
> (In reply to Jan Hubicka from comment #3)
> > > I've just tried to reproduce it:
> > > ../configure --with-build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
Richard Biener changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99102
Bug ID: 99102
Summary: SVE: Wrong code with -O2 -ftree-vectorize
-march=armv8.2-a+sve -msve-vector-bits=256
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99097
--- Comment #7 from Martin Liška ---
> Ah, you are right. It is binutils trunk (unpatched). Will figure out
> what is going on here.
Good! If the failure happens quickly, you can likely bisect binutils quickly.
In which build stage do you see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98014
--- Comment #1 from Jakub Jelinek ---
!$omp parallel &
!$omp num_threads(4) &
!$omp !comment
!$omp end parallel
end
is also rejected. And in
!$omp parallel &
!$omp num_threads(4) &
!$omp&!comment
!$omp end parallel
end
we treat that !$omp&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #3 from Rex <251078896 at qq dot com> ---
Dear Richard,
Your post is informative, but I can't follow them all. Where does those "", "basic block 14", "local count" come from? I'm very interested in this
kind of analysis (and tools). C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #4 from Jakub Jelinek ---
If there are EH edges, doesn't it fit then the -ffinite-loops description:
'-ffinite-loops'
Assume that a loop with an exit will eventually take the exit and
not loop indefinitely. This allows the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99091
Jakub Jelinek changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
Richard Biener changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #6 from Richard Biener ---
(In reply to Jakub Jelinek from comment #4)
> If there are EH edges, doesn't it fit then the -ffinite-loops description:
> '-ffinite-loops'
> Assume that a loop with an exit will eventually take the exi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98881
--- Comment #3 from Pilar Latiesa ---
Including vector + any header from range-v3 also triggers the ICE.
For example (https://godbolt.org/z/qnMe45):
module;
#include
#include
export module M;
void f()
{
std::vector v;
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99102
Alex Coplan changed:
What|Removed |Added
Summary|SVE: Wrong code with -O2|[11 Regression] SVE: Wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99103
Bug ID: 99103
Summary: Initializer-list constructors in CTAD for vector is
still wrong
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93787
--- Comment #4 from Tobias Burnus ---
The problem is in count_types_test:
For 'type(*),dimension(..)', compare_type_rank_if accepts a scalar integer
For 'type(*),dimension(*)', it does not.
As 'dimension(..)' accepts scalars, the symmetry is br
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99104
Bug ID: 99104
Summary: [11 Regression] ICE: Segmentation fault (in
bitmap_list_find_element)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99099
--- Comment #2 from Stephen Leake ---
Removing -gnat2020 from the compiler options makes the error go away.
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.
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=99104
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Sta
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=98014
Tobias Burnus changed:
What|Removed |Added
Summary|[Fortran OpenACC] Empty |[Fortran][OpenACC][OpenMP]
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=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=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=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=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=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 #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=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=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=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
--- 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
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
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=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
> 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=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
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=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=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=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=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=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=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 #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=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=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=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=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 #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 #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 #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 #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=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=99104
Jakub Jelinek changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment #4 f
> 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=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
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=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=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=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=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=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=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=99104
Jakub Jelinek changed:
What|Removed |Added
Attachment #50186|0 |1
is obsolete|
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=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 #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=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=98872
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
1 - 100 of 146 matches
Mail list logo
