https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108938
--- Comment #12 from Jakub Jelinek ---
(In reply to Hongtao.liu from comment #11)
> (In reply to Jakub Jelinek from comment #9)
> > Though, if more than one replacement operation is emitted, one needs to be
> > careful not to emit more expensive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
--- Comment #8 from Ulrich Weigand ---
(In reply to Jakub Jelinek from comment #5)
> Though, relying on DW_OP_entry_value is not reliable, if e.g. tail calls are
> (or could be) involved, then GDB needs to punt.
The only way a tail call could h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
--- Comment #9 from Ulrich Weigand ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Ulrich Weigand from comment #4)
> > (In reply to Jakub Jelinek from comment #3)
> > > What is done on other arches?
> >
> > That depends on the pl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109050
Bug ID: 109050
Summary: UBsan failed to detect out-of-bound at -O0/1/2/s
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
--- Comment #10 from Jakub Jelinek ---
(In reply to Ulrich Weigand from comment #8)
> (In reply to Jakub Jelinek from comment #5)
> > Though, relying on DW_OP_entry_value is not reliable, if e.g. tail calls are
> > (or could be) involved, then G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108938
--- Comment #13 from Hongtao.liu ---
(In reply to Jakub Jelinek from comment #12)
> (In reply to Hongtao.liu from comment #11)
> > (In reply to Jakub Jelinek from comment #9)
> > > Though, if more than one replacement operation is emitted, one n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109040
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109044
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109045
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109046
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58331
--- Comment #6 from Tobias Burnus ---
> So shall we proceed?
Looks like. I think it mostly needs a bunch of testcases to ensure it works,
including the coarray-testcase mentioned in one of the comments. If something
fails, we can have another lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109048
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109048
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109048
--- Comment #6 from rguenther at suse dot de ---
On Tue, 7 Mar 2023, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109048
>
> Jakub Jelinek changed:
>
>What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
--- Comment #15 from avieira at gcc dot gnu.org ---
@richi: Yeah and as I mentioned on IRC I can confirm it fixes the issue, I also
bootstrapped and regression tested the change on aarch64-unknown-linux-gnu.
Simon, I can't compile your minimal r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103166
--- Comment #10 from Christophe Lyon ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Christophe Lyon from comment #0)
> > Maybe there's something wrong with the detection of HAVE_GETENTROPY in
> > configure?
>
> We only do a co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #18 from niXman ---
tested on i686 and x86_64 mingw-w64 - works as expected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
--- Comment #16 from Marc Poulhiès ---
(In reply to avieira from comment #15)
> @richi: Yeah and as I mentioned on IRC I can confirm it fixes the issue, I
> also bootstrapped and regression tested the change on
> aarch64-unknown-linux-gnu.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
--- Comment #17 from Marc Poulhiès ---
FWIW, can confirm the above fix works for the small reproducer (x86_64-linux)
/* Bail out if the representative is BLKmode as we will not be able to
vectorize this. */
- if (TYPE_MODE (TREE_TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
--- Comment #18 from Iain Sandoe ---
(In reply to Marc Poulhiès from comment #17)
> FWIW, can confirm the above fix works for the small reproducer (x86_64-linux)
>
>/* Bail out if the representative is BLKmode as we will not be able to
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103166
--- Comment #11 from Jonathan Wakely ---
(In reply to Christophe Lyon from comment #10)
> Why do we avoid link tests? Is that because of something like
> https://lists.gnu.org/archive/html/autoconf/2007-03/msg00085.html ?
No, I don't think it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594
--- Comment #21 from Roger Sayle ---
I completely agree that Richard Sandiford's patch is a much better solution,
but I'd like to counter the claims that the change originally proposed in
comment #8 is obviously universally bad.
Segher has prop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108925
--- Comment #6 from Mikael Morin ---
Created attachment 54598
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54598&action=edit
Tentative patch
Indeed the namespaces created during module loading are not stored anywhere, so
they are leaked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #13 from Richard Biener ---
The question is what we want to do for GCC 13 - I suppose iterating would work
but it'll be slow (what's the range to binary search here?). Doing the math
"right" probably differs for each reverse operati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #14 from Jakub Jelinek ---
Created attachment 54599
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54599&action=edit
gcc13-pr109008-wip.patch
I have now this WIP but it doesn't work correctly yet, need to debug it now,
just fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #15 from Jakub Jelinek ---
I believe worst case the above would do (for IEEE quad) something like 16
checks because of 16-bit exponent, roughly one range_arithmetic, one (for
mult/div 2?) frange_arithmetic and real_equal + real_isfin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109049
--- Comment #1 from Jonathan Wakely ---
Who cares? Taking the address of std::declval is forbidden, and you can't call
that specialization anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #16 from Richard Biener ---
(In reply to Jakub Jelinek from comment #14)
> Created attachment 54599 [details]
> gcc13-pr109008-wip.patch
>
> I have now this WIP but it doesn't work correctly yet, need to debug it now,
> just finishe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #17 from Richard Biener ---
(In reply to Jakub Jelinek from comment #15)
> I believe worst case the above would do (for IEEE quad) something like 16
> checks because of 16-bit exponent, roughly one range_arithmetic, one (for
> mult/d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109049
--- Comment #2 from Jonathan Wakely ---
The reason it behaves this way is that we define declval as:
template
auto declval() noexcept -> decltype(__declval<_Tp>(0));
and decltype(__declval<_Tp>(0)) drops the cv-qualifiers. This implement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109051
Bug ID: 109051
Summary: Configure takes long time for multibuild of run-time
libraries
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109051
Martin Liška changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109051
--- Comment #2 from Richard Biener ---
Are you sure it's not really stuck? Is it linking many target libs in
parallel?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109051
--- Comment #3 from Martin Liška ---
(In reply to Richard Biener from comment #2)
> Are you sure it's not really stuck? Is it linking many target libs in
> parallel?
Dunno, it's slow even on a reasonably fast machine, so I can imagine it can
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
--- Comment #13 from Jan Hubicka ---
> So .. for promotion of target expression temporaries to frame vars, one of:
> - a) we need to find a different way to name them
I think we can just count number of fields within a given frame type?
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109052
Bug ID: 109052
Summary: Unnecessary reload with -mfpmath=both
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109052
Uroš Bizjak changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
Key
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #18 from Jakub Jelinek ---
(In reply to Richard Biener from comment #16)
> (In reply to Jakub Jelinek from comment #14)
> > Created attachment 54599 [details]
> > gcc13-pr109008-wip.patch
> >
> > I have now this WIP but it doesn't w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #19 from Richard Biener ---
I still think we should avoid iteration. Looking at plus we have
x = y + a
which is actually
x = y + a +- 0.5ulp (y + a)
(0.5ulp of the y + a result), so we can compute a as
a = x - y +- 0.5ulp (y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
--- Comment #19 from simon at pushface dot org ---
(In reply to avieira from comment #15)
> Simon, I can't compile your minimal reproducer, first it complains about
> missing the body keyword, so I added that, but then it complains about
> missi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #20 from Richard Biener ---
(In reply to Richard Biener from comment #19)
> I still think we should avoid iteration. Looking at plus we have
>
> x = y + a
>
> which is actually
>
> x = y + a +- 0.5ulp (y + a)
>
> (0.5ulp of th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109051
--- Comment #4 from Andreas Schwab ---
This appears to be the effect of make's output sync, and configuring umpteen
multilibs just takes a long time (3357s during the last sucessful build).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108185
--- Comment #6 from CVS Commits ---
The master branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:247cacc9e381d666a492dfa4ed61b7b19e2d008f
commit r13-6524-g247cacc9e381d666a492dfa4ed61b7b19e2d008f
Author: Pan Li
Date: Tue Mar 7 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108654
--- Comment #1 from CVS Commits ---
The master branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:247cacc9e381d666a492dfa4ed61b7b19e2d008f
commit r13-6524-g247cacc9e381d666a492dfa4ed61b7b19e2d008f
Author: Pan Li
Date: Tue Mar 7 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #21 from Richard Biener ---
So without messing with real.cc to try exposing 0.5ulp adjustments for GCC 13
I'd simply do something like the following:
diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc
index ff42b95de4f..1ae6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109052
--- Comment #2 from Uroš Bizjak ---
The original testcase is:
double foo (double a, double b)
{
double z = __builtin_fmod (a, 3.14);
return z * b;
}
-O2 -fno-math-errno:
foo:
fldl.LC0(%rip)
movsd %xmm0, -8(%rsp)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
--- Comment #20 from avieira at gcc dot gnu.org ---
It's probably obvious to people that know Ada, so I just have to apologize for
my ignorance in that area :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #22 from Richard Biener ---
New real.h API could be
extern void real_unround (REAL_VALUE_TYPE *, format_helper, int dir);
where for dir < 0 it produces the least significant bits so that rounding
produces the original while for dir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109053
Bug ID: 109053
Summary: [missed optimization] value-range tracking fails in
simple case with __builtin_unreachable
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49475
--- Comment #4 from Tom Tromey ---
Note that ifort implemented this and gdb supports that now.
See https://sourceware.org/bugzilla/show_bug.cgi?id=22497
for some info.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
--- Comment #21 from avieira at gcc dot gnu.org ---
Something else that might be obvious, how do I create a minimal ifcvt_demo.adb
file that uses the .ads, so that I can add it as a testcase to gcc, as the
testsuite seems to pick up .adb files on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
--- Comment #22 from rguenther at suse dot de ---
On Tue, 7 Mar 2023, avieira at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
>
> --- Comment #21 from avieira at gcc dot gnu.org ---
> Something else that might b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108060
--- Comment #4 from Martin Liška ---
(In reply to Martin Liška from comment #3)
> @Marek, can you please take a look?
PING please
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109050
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108060
--- Comment #5 from Martin Liška ---
*** Bug 109050 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108060
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108997
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109017
Martin Liška changed:
What|Removed |Added
Summary|ICE on unexpanded pack from |ICE on unexpanded pack from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109027
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2023-03-07
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
--- Comment #14 from Iain Sandoe ---
(In reply to Jan Hubicka from comment #13)
> > So .. for promotion of target expression temporaries to frame vars, one of:
> > - a) we need to find a different way to name them
> I think we can just count nu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109049
--- Comment #3 from Jiang An ---
I've mailed to LWG Chair to request legitimation of libc++ and libstdc++'s
current strategy.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107939
--- Comment #6 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:e09bc034d1b4d692b409fa5af52ae34480a6f4dc
commit r13-6525-ge09bc034d1b4d692b409fa5af52ae34480a6f4dc
Author: Marek Polacek
Date: Fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109030
--- Comment #3 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:e4692319fd5fc7d740436e8bb338f44cb8df6c58
commit r13-6526-ge4692319fd5fc7d740436e8bb338f44cb8df6c58
Author: Marek Polacek
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109030
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107939
Marek Polacek changed:
What|Removed |Added
Summary|[11/12/13 Regression] |[11/12 Regression] Rejects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107939
--- Comment #8 from CVS Commits ---
The releases/gcc-12 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:19ed6bf44c3fec882cf4c825f3ffa4f2ecdc78e6
commit r12-9232-g19ed6bf44c3fec882cf4c825f3ffa4f2ecdc78e6
Author: Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 107939, which changed state.
Bug 107939 Summary: [11 Regression] Rejects use of `extern const` variable in a
template since r11-557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107939
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107939
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109042
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:0d573c1f002fa77a4483aa9ebe310746a313082e
commit r13-6527-g0d573c1f002fa77a4483aa9ebe310746a313082e
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109042
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109054
Bug ID: 109054
Summary: _Unwind_GetLanguageSpecificData should have protected
visibility
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109049
--- Comment #4 from Jonathan Wakely ---
I thought it was already allowed, because std::declval is not an addressable
function ([namespace.std]) but that only covers forming pointers and references
to functions. We should extend that to cover thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61882
Pekka S changed:
What|Removed |Added
CC||p...@gcc-bugzilla.mail.kaps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109041
ishikawa,chiaki changed:
What|Removed |Added
CC||ishikawa at yk dot rim.or.jp
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109054
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109041
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|1 |0
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109055
Bug ID: 109055
Summary: Code generation error when function decorated for
execution in SRAM
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532
--- Comment #11 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:80f0052b3924569af904d1bab0858fe985f33a94
commit r13-6529-g80f0052b3924569af904d1bab0858fe985f33a94
Author: Marek Polacek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
Marek Polacek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109054
Jakub Jelinek changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
--- Comment #15 from Jan Hubicka ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
>
> --- Comment #14 from Iain Sandoe ---
> (In reply to Jan Hubicka from comment #13)
> > > So .. for promotion of target expression temporaries to fram
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107079
--- Comment #8 from CVS Commits ---
The releases/gcc-12 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:fb82334341e21ad0254f63e942be276f62d111cf
commit r12-9233-gfb82334341e21ad0254f63e942be276f62d111cf
Author: Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107079
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
--- Comment #16 from Iain Sandoe ---
(In reply to Jan Hubicka from comment #15)
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
> >
> > --- Comment #14 from Iain Sandoe ---
> > (In reply to Jan Hubicka from comment #13)
> > > > So .. f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107023
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109056
Bug ID: 109056
Summary: cppcheck: no warning for suspicious return type
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109056
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109056
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> -Wconversion is needed for this warning in GCC.
Which turns on -Wsign-conversion .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109056
--- Comment #3 from David Binderman ---
(In reply to Andrew Pinski from comment #2)
> Which turns on -Wsign-conversion .
-Wsign-conversion seems close, but not quite right. The problem is
in potential overflow, not sign conversion.
-Woverflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109057
Bug ID: 109057
Summary: Does GCC interpret assembly when deciding to optimize
away a variable?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109057
--- Comment #1 from Henry ---
Two caveats:
1. If you add something like `xor %0,%0` inside the assembly text, LUT is not
optimized
inline void DoNotOptimize( uint8_t value) {
asm volatile("xor %0,%0" : : "r,m"(value) : "memory");
}
void fun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109057
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109057
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109057
--- Comment #4 from Henry ---
Yes it is optimized away.
Note that even in this case the entire static array is optimized away from the
object file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109057
--- Comment #5 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #2)
> No it is not. you just don't notice it there because goldbolt is hiding
> things because it thinks it is unused.
This actually isn't godbolt hiding anything (wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109057
--- Comment #6 from Henry ---
Still, why is it then if you change the type to uint32_t the behavior changes?
And why the entire static array is cut out from the object file?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109057
--- Comment #7 from Jakub Jelinek ---
I certainly can't reproduce the LUT array not being emitted, tried GCC 11, 12
and trunk,
C and C++ (all -O2).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109057
--- Comment #8 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to Andrew Pinski from comment #2)
> > No it is not. you just don't notice it there because goldbolt is hiding
> > things because it thinks it is unused
1 - 100 of 156 matches
Mail list logo
