https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987
Bug 19987 depends on bug 94916, which changed state.
Bug 94916 Summary: Failure to optimize pattern into difference or zero selector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94916
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94916
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3507
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|rask at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95408
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #30 from Xi Ruoyao ---
https://reviews.llvm.org/D150505.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94893
--- Comment #3 from Andrew Pinski ---
Note we also don't optimize:
inline int sign1(int x)
{
return (x < 0 ? -1 : 0) | (x > 0 ? 1 : 0);
}
bool f1(int x)
{
return sign1(x) < 1;
}
To be just `x <= 0`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98710
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2021-04-26 00:00:00 |2023-5-12
--- Comment #2 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #34 from Miklos Karacsony ---
(In reply to Sergei Trofimovich from comment #32)
> Created attachment 55068 [details]
> gzip.c.c
>
> > > You should be able to extract preprocessed file using
> > > https://gcc.gnu.org/bugs/#need: you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #33 from Miklos Karacsony ---
Created attachment 55073
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55073=edit
gcc 12.3.1 preprocessed source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94911
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-05-13
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #29 from Xi Ruoyao ---
(In reply to Xi Ruoyao from comment #28)
> (In reply to Alexander Monakov from comment #21)
> > (In reply to Xi Ruoyao from comment #18)
> > > Maybe. Should we send a patch?
> >
> > Yes, if we have a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #28 from Xi Ruoyao ---
(In reply to Alexander Monakov from comment #21)
> (In reply to Xi Ruoyao from comment #18)
> > Maybe. Should we send a patch?
>
> Yes, if we have a volunteer.
I'm creating it, but from the description of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
--- Comment #12 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:99488a6048745a7b999c22f46e5814d02ebf88d9
commit r14-804-g99488a6048745a7b999c22f46e5814d02ebf88d9
Author: Andrew Pinski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109839
Bug ID: 109839
Summary: -Wanalyzer-fd-leak false positive with routine dup2
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #24 from Janez Zemva ---
I'll go libm shopping them, I know just the thing to try out first:
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/libs/libm/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109825
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109838
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109825
Andrew Pinski changed:
What|Removed |Added
CC||slyfox at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109838
Bug ID: 109838
Summary: [14 Regression] ICE on libaom-3.6.0: in
ix86_widen_mult_cost, at config/i386/i386.cc:20444
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #23 from Jonathan Wakely ---
No, the built-in functions just call the functions defined in libm. GCC doesn't
implement them.
Look at the code for a call to __builtin_acosh:
https://godbolt.org/z/dPf46sKxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109824
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #22 from Janez Zemva ---
They are very sloppy, so I doubt even what they provide is working 100%. This
is why I suggested the generative approach. gcc has many built-in functions,
surely a rudimentary could be cobbled out of them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109824
Andrew Pinski changed:
What|Removed |Added
Summary|aligned attribute lost on |aligned attribute lost when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109837
Bug ID: 109837
Summary: [OpenMP] despite 'requires unified_address' there is
segfault when 'is_device_ptr' is not used
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109824
Stas Sergeev changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109814
--- Comment #10 from Arsen Arsenović ---
(In reply to lesto fante from comment #9)
> To be fair I have no idea what would be the impact of removing freestanding,
> from a quick test does not seems to have a realistic impact.
>
> I guess what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-05-12
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
--- Comment #9 from Sam James ---
(In reply to Sam James from comment #8)
> Created attachment 55071 [details]
> graphite2-GlyphCache.cpp.ii (maybe related)
I guess this is really the same given the operations it's doing (its own
bswaps).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
--- Comment #8 from Sam James ---
Created attachment 55071
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55071=edit
graphite2-GlyphCache.cpp.ii (maybe related)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #21 from Jonathan Wakely ---
Oh, checking FLT_EVAL_METHOD doesn't work, because that's defined in
not . So another djgpp-specific "NO_FLOAT_TYPES" macro will be needed.
Sigh.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #20 from Jonathan Wakely ---
Created attachment 55070
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55070=edit
Patch to make cmath configure tests more granular
Something like this might work, but it's horrible.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59905
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |4.9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #19 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #15)
> A proper fix would be to split up the configure test for USE_C99_MATH_TR1 to
> be more fine-grained, so that we use the subset of functions that are
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109745
--- Comment #8 from Carlos Galvez ---
Thanks a lot for the quick fix!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109835
--- Comment #2 from Sam James ---
Okay, fair point, I gave examples but not *motivating* examples.
I have some non-harmless examples:
1.
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1e0e5c4d289004fa779c86da9319cf2bb18548b1
(a nasty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
--- Comment #7 from Andrew Pinski ---
Reduced further:
int split_subtables(char v)
{
return __builtin_popcount((int)__builtin_bswap16(v));
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
--- Comment #6 from Sam James ---
Created attachment 55069
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55069=edit
reduced.ii
I might reduce the graphite2 one for fun just to see how different it is but no
promises.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
--- Comment #5 from Andrew Pinski ---
(In reply to Mikael Morin from comment #4)
> (In reply to Andrew Pinski from comment #2)
> > I am 99% sure it was introduced by r14-673-g5fdcfe3c5776
> >
> I think the correct link is r14-673-gc0dd80e4c4c3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109654
Andrew Pinski changed:
What|Removed |Added
CC||stsp at users dot
sourceforge.net
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109824
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109828
--- Comment #6 from Andrew Pinski ---
here is another example where we output a bogus `.zero` (though it does not
ICE):
struct s { int i; char c[]; };
const struct s *t = &(struct s) { .c = {'2','\0'}, };
We get:
.size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
--- Comment #21 from CVS Commits ---
The master branch has been updated by Jerry DeLisle :
https://gcc.gnu.org/g:96cc09dea48b562a0fc93d43fb3b702ac20b89fd
commit r14-802-g96cc09dea48b562a0fc93d43fb3b702ac20b89fd
Author: Jerry DeLisle
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
--- Comment #20 from CVS Commits ---
The master branch has been updated by Jerry DeLisle :
https://gcc.gnu.org/g:cf3b032b8fb681516ccacbe3689f1cad43a1773a
commit r14-801-gcf3b032b8fb681516ccacbe3689f1cad43a1773a
Author: Jerry DeLisle
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109577
Paul Eggert changed:
What|Removed |Added
CC||eggert at cs dot ucla.edu
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #32 from Sergei Trofimovich ---
Created attachment 55068
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55068=edit
gzip.c.c
> > You should be able to extract preprocessed file using
> > https://gcc.gnu.org/bugs/#need: you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106168
Eric Botcazou changed:
What|Removed |Added
Status|REOPENED|SUSPENDED
--- Comment #5 from Eric
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109829
--- Comment #6 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #4)
> Or does match.pd try to invert all the COND_EXPR conditions and swap the
> operands?
match does not try but phiopt does in gimple_simplify_phiopt .
Or even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109814
--- Comment #9 from lesto fante ---
To be fair I have no idea what would be the impact of removing freestanding,
from a quick test does not seems to have a realistic impact.
I guess what happen here is that the freestanding option should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109829
--- Comment #5 from Jakub Jelinek ---
Or canonicalize COND_EXPRs such that only ne and not eq appears in condition
(and similarly to other comparisons)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109829
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472
--- Comment #26 from matoro ---
We also had somebody report on IRC that they observed this on powerpc (not sure
what tuple), again with -j1. It does not seem to show up with -j2, so likely
-j1 is necessary to trigger.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472
--- Comment #25 from matoro ---
Created attachment 55067
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55067=edit
build.log for gcc-13.1
This bug is still present on 13.1.0, attaching log
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109788
--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #11)
> If you e.g. put breakpoint on the spot I changed and stopon the testcase
> with -Os when t == global_trees[TI_VOID_LIST_NODE] you can then see in
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109826
--- Comment #2 from Andrew Pinski ---
The warning is not even controlled by an option either so only -Werror turns it
into an error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109829
--- Comment #3 from Andrew Pinski ---
Should add this one too:
(simplify
(cond (ne (SIGNBIT @0) zero_p@1) @0 (neg @0))
(neg (abs @0)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #27 from Andrew Pinski ---
(In reply to Alexander Monakov from comment #26)
> Would that help? GCC raises its own stack limit to 64MB:
>
> gcc.cc: stack_limit_increase (64 * 1024 * 1024);
> toplev.cc: stack_limit_increase (64 *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #26 from Alexander Monakov ---
Would that help? GCC raises its own stack limit to 64MB:
gcc.cc: stack_limit_increase (64 * 1024 * 1024);
toplev.cc: stack_limit_increase (64 * 1024 * 1024);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106168
Pascal Pignard changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109829
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #25 from Andrew Pinski ---
(In reply to Alexander Monakov from comment #24)
> Appreciate the advice. So far I've managed to reduce the number of LTO
> inputs down to two files, RegisterBankInfo.cpp.o plus APInt.cpp.o. I also
> built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109828
--- Comment #5 from Andrew Pinski ---
(In reply to Yann Droneaud from comment #4)
> I'm still playing with this, for example https://godbolt.org/z/dfjr8veh5,
> and I've noticed the size of the compound_initializer is incorrect too:
> Maybe it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109828
--- Comment #4 from Yann Droneaud ---
I'm still playing with this, for example https://godbolt.org/z/dfjr8veh5, and
I've noticed the size of the compound_initializer is incorrect too:
struct s { char i; char c[]; };
const struct s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #24 from Alexander Monakov ---
Appreciate the advice. So far I've managed to reduce the number of LTO inputs
down to two files, RegisterBankInfo.cpp.o plus APInt.cpp.o. I also built
gcc-12.3 with lineinfo and have a better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109828
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|C2x:static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087
Andrew Pinski changed:
What|Removed |Added
Status|REOPENED|NEW
Summary|Misleading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087
Andrew Pinski changed:
What|Removed |Added
CC||ideasman42 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71202
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #2 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109836
--- Comment #3 from Jakub Jelinek ---
This is already enabled by -Wall and -pedantic and error with -pedantic-errors,
I'm not sure we want to warn by default here.
At least, we'd need details on how many extra warnings does that result on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109836
--- Comment #2 from Andrew Pinski ---
I had thought this was documented as an extension too. But I can't find that
part of the documentation.
But the option is definitely documented as being enabled with -Wpedantic:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109836
--- Comment #1 from Andrew Pinski ---
It is enabled for -pedantic ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109829
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109836
Bug ID: 109836
Summary: -Wpointer-sign must be enabled by default
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: accepts-invalid, diagnostic
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109833
Andrew Pinski changed:
What|Removed |Added
Known to fail||7.1.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109832
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101806
Andrew Pinski changed:
What|Removed |Added
CC||acoplan at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
--- Comment #3 from Andrew Pinski ---
(In reply to Sam James from comment #1)
> The *other* main issue I have is with graphite2:
It is a similar enough issue; that is there was two locations where the bad
code was introduced with that patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109698
--- Comment #5 from David Richards ---
To add a bit more (not much - just a tad). I was able to build gcc/g++
version 12.3.0 just recently released without any problems.
Then I attempted to build 13.1 with 12.3 and still no luck. Same error...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109830
Gaius Mulley changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
Andrew Pinski changed:
What|Removed |Added
Keywords|wrong-code |ice-on-valid-code
--- Comment #23 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109835
--- Comment #1 from Florian Weimer ---
Presumably the idea is to enable -Werror=incompatible-function-pointer-types
(in spirit) because it is more severe than -Wincompatible-pointer-types? I'm
not sure this is actually true.
Your first example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109830
--- Comment #3 from CVS Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:1953c0cfb006a696723baa7d5ea14038f6d901a4
commit r14-795-g1953c0cfb006a696723baa7d5ea14038f6d901a4
Author: Gaius Mulley
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 109797, which changed state.
Bug 109797 Summary: 456.hmmer compiled with -O2 -flto regressed by 15% on AMD
zen3 between r14-487-g6f18f344338b37 and r14-540-gb7fe38c14e5f1b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109797
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #18 from Jonathan Wakely ---
No, the functionality belongs in the C library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109797
--- Comment #11 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:75aa95694ed9bab50b5e152f7a755eb5f5e8014e
commit r14-794-g75aa95694ed9bab50b5e152f7a755eb5f5e8014e
Author: Uros Bizjak
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
--- Comment #2 from Andrew Pinski ---
I am 99% sure it was introduced by r14-673-g5fdcfe3c5776
The bug is:
+ (if (prec0 == prec1 || (prec0 > prec1 && TYPE_UNSIGNED (@1)))
Should have been:
+ (if (prec0 == prec1 || (prec0 >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #17 from Janez Zemva ---
Perhaps missing functionality could also be auto-generated? I am a big fan of
generative programming.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95445
Sam James changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109835
Bug ID: 109835
Summary: -Wincompatible-function-pointer-types as a subset of
-Wincompatible-pointer-types?
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109834
--- Comment #1 from Sam James ---
The *other* main issue I have is with graphite2:
```
FAILED: src/CMakeFiles/graphite2.dir/GlyphCache.cpp.o
/usr/bin/aarch64-unknown-linux-gnu-g++ -DGRAPHITE2_NTRACING -Dgraphite2_EXPORTS
.0. p, commit 29d805847dc870c92f705ed9c5e7eac955c7e7d4)
14.0.0 20230512 (experimental) f52bf590e3336979ee47658d74a8478e3234da9b
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #22 from Alexander Monakov ---
(In reply to Jan Hubicka from comment #19)
> It would be really nice to have the ranger bug fixed. Since lifetime
> DSE is all handled in C++ FE there is no good reason why it should not
> work to LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95445
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #21 from Alexander Monakov ---
(In reply to Xi Ruoyao from comment #18)
> Maybe. Should we send a patch?
Yes, if we have a volunteer.
> If I read the LLVM code correctly, -fno-strict-aliasing is enabled for
> Clang, but not other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #20 from Xi Ruoyao ---
(In reply to Jan Hubicka from comment #19)
> > > Is there any need to over-engineer this like that? I would hope enabling
> > > -fno-lifetime-dse globally would not be controversial for LLVM
>
> It would be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109833
Bug ID: 109833
Summary: The value of constexpr anonymous union can be changed
in runtime
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
1 - 100 of 213 matches
Mail list logo
