https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110069
--- Comment #2 from Chip Weinberger ---
The 35 bytes figure is from -O0. This is a debug feature.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110069
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110069
--- Comment #1 from Andrew Pinski ---
In your backend you could implement all of this I think.
Are you talking about -O0 code generation or -O2?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110069
Bug ID: 110069
Summary: [Perf] -finstrument-functions causes program size to
double
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110068
--- Comment #1 from Andrew Pinski ---
here is another one:
```
unsigned
f5 (unsigned x)
{
bool t = x >= 1U<<(sizeof(x)*8-1);
if (!t)
;
else
x = 1U<<(sizeof(x)*8-1);
return x;
}
```
this time LLVM does not detect it either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110044
--- Comment #7 from Sergey Fedorov ---
(In reply to Iain Sandoe from comment #6)
> I'm going to test the following (which will take some time since the
> hardware is needed for testing releases too).
>
> The test for AGGREGATE_TYPE_P() could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110068
Bug ID: 110068
Summary: missing min detection
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84849
--- Comment #10 from Jason Merrill ---
(In reply to ensadc from comment #7)
> (In reply to Zhihao Yuan from comment #6)
>
> I think this is a different bug. GCC thinks the implicitly-deleted move
> assignment operator `pair&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101024
--- Comment #11 from Andrew Pinski ---
A few testcases that have not been added to the testsuite yet.
Note it takes f1 to phiopt2 to optimize that because there is an extra
statement left behind because match does not deal with `(signed)a < 0`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110067
--- Comment #4 from Hongtao.liu ---
For
br64 = br;
br64 = ((br64 << 16) & 0x00ffull) | (br64 & 0xff00ull);
n->n is 0x300200.
n->range is 32.
n->type is uint64.
Currently the code assumes n->range is same as TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110067
--- Comment #4 from Hongtao.liu ---
For
br64 = br;
br64 = ((br64 << 16) & 0x00ffull) | (br64 & 0xff00ull);
n->n is 0x300200.
n->range is 32.
n->type is uint64.
Currently the code assumes n->range is same as TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110067
--- Comment #3 from Hongtao.liu ---
(In reply to Sergei Trofimovich from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > I am suspecting it was caused by r14-1402-gd8545fb2c71683f407bfd9670 .
>
> I did not bisect and tested only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109930
--- Comment #5 from Simon Richter ---
> Btw if you know the old state then there is presumably no concurrent access
> here and so you don't need atomic, let alone sequential consistency.
I know it in some, but not all cases.
Basically, what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110047
--- Comment #2 from Eric Gallager ---
Oh, one other thing I'd note here is that gcc/README.portability contains a
part about this, too; I'm copying and pasting it here:
Implicit int
In C, the 'int' keyword can often be omitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
--- Comment #2 from Andrew Pinski ---
I am not 100% sure the all of the objects in the vector has to be in type of
C. Because you could do some tricks dealing with inplacement new.
>if this applies to raw arrays
It does applies to raw arrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
--- Comment #1 from Andrew Pinski ---
I don't think it should be checking ssa dump (which is the output right after
going into ssa mode) but rather optimized.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99242
Andrew Pinski changed:
What|Removed |Added
CC||saifi.khan at nishan dot io
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 110056, which changed state.
Bug 110056 Summary: ICE on trying to generate header unit for 'execution'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110056
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110056
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110055
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> > C.0 ={v} {CLOBBER(eol)};
>
>
> Should never have been emitted from the gimplifier.
>
>
> Confirmed, I have not reduced the testcase yet.
> But I can also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110055
Andrew Pinski changed:
What|Removed |Added
Target|aarch64-linux-gnu |aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110055
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110060
--- Comment #6 from Andrew Pinski ---
Note you can reduce main to just:
```
int main()
{
std::vector v(5);
const std::vector w(1);
v.resize(1);
// v.insert(v.begin(), 0);
//v.insert(v.begin(), 1, 0);
// v.insert(v.begin(), w.begin(),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110060
--- Comment #5 from Jonathan Wakely ---
Ugh, that's not good - maybe I should revert it then. Or make _M_invariant much
smaller.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110060
--- Comment #4 from Andrew Pinski ---
So the other thing that is going wrong is the addition of the optimizer hints
is causing things like std::vector::size no longer to be inlined. because
the TU size has increased and we start hitting the TU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110067
Sergei Trofimovich changed:
What|Removed |Added
CC||crazylht at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110060
--- Comment #3 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #2)
> Anything I can do in std::vector to make it optimize better?
I don't think in this case there is but I could be wrong.
it has to do with the v.insert call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110060
--- Comment #2 from Jonathan Wakely ---
Anything I can do in std::vector to make it optimize better?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110053
Andrew Pinski changed:
What|Removed |Added
Component|c |tree-optimization
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #32 from Janez Zemva ---
I resolved this issue by porting openlibm over to djgpp (some hacks and typedef
float float_t;, ... were necessary). The fix on the side of gcc might have been
a more thorough analysis of what is available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110060
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110067
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection, wrong-code
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110067
Bug ID: 110067
Summary: [14 Regression] Wrong code on pixman-0.42.2
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #3 from rvalue ---
(In reply to Andrew Pinski from comment #1)
> This also could be a glibc issue.
I tried gcc 12.2.1 and 13.1.1 with exactly the same glibc and binutils
environments, the 12.2.1 version works while 13.1.1 doesn't.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541
--- Comment #12 from Sam James ---
(Vladimir (and anyone else interested): For bugs like this, you're welcome to
use gentoo's testing hardware if desired. Just email me an SSH key.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541
Eric Botcazou changed:
What|Removed |Added
Attachment #54880|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541
--- Comment #10 from Eric Botcazou ---
> Sorry, I can not reproduce it on gcc-11, gcc-12, and master using -O1
> -mcpu=niagara4 -fpic -c a-sha512.i.
You need a properly configured cross-compiler, which means that you need to
build and install
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110065
Andrew Pinski changed:
What|Removed |Added
Known to fail||11.3.0, 12.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108703
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110065
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88552
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed|2018-12-19 00:00:00 |2023-5-31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109247
--- Comment #16 from Jason Merrill ---
(In reply to Jason Merrill from comment #15)
> Discussion in CWG led to this more specific rule that only affects the
> copy/move special member functions, and so doesn't affect the 84849
> testcases:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541
--- Comment #9 from Vladimir Makarov ---
(In reply to Eric Botcazou from comment #7)
> The problem is that LRA assigns a floating-point register to the PIC
> pseudo-register (pic_offset_table_rtx) and the SPARC back-end is not
> prepared for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #2 from Andreas Schwab ---
I cannot reproduce that with glibc 2.37 and binutils 2.40 on openSUSE. I've
also tried with -profile which links against -lc_p, no issue either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84849
Jason Merrill changed:
What|Removed |Added
Summary|Ambiguous resolution of |[DR1228] Ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
Andrew Pinski changed:
What|Removed |Added
Target||riscv64-unknown-linux-gnu
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93019
--- Comment #4 from Andrew Pinski ---
(In reply to Richard Biener from comment #1)
> I think this is known for the driver and we're too lazy to fix
For the driver, it is not much a deal but since JIT uses the driver code also,
it becomes an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93019
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-05-31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
Bug ID: 110066
Summary: [RISC-V] Segment fault if compiled with -static -pg
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93019
Andrew Pinski changed:
What|Removed |Added
CC||eliaz.pitavy at obspm dot fr
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110063
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #30 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:49f59826c66bcaa3531429381b4aed944c332e5b
commit r14-1454-g49f59826c66bcaa3531429381b4aed944c332e5b
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109921
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:a239a35075ffd8b34f1db72c22998a625ff962b5
commit r14-1451-ga239a35075ffd8b34f1db72c22998a625ff962b5
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60027
Jason Merrill changed:
What|Removed |Added
CC||dmatthews at utexas dot edu
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109864
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948
--- Comment #17 from Mikael Morin ---
(In reply to anlauf from comment #16)
> (In reply to Paul Thomas from comment #15)
> > Created attachment 55225 [details]
> > Fix for this PR
> >
> > The attached patch substantially tidies up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109247
Jason Merrill changed:
What|Removed |Added
Attachment #54739|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983
--- Comment #16 from Sam James ---
(In reply to Richard Biener from comment #9)
> My suggestion is to not enable -fipa-pta if you hit such issue or in general
> if you don't know it pays off with a good runtime performance boost.
Many thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948
--- Comment #16 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #15)
> Created attachment 55225 [details]
> Fix for this PR
>
> The attached patch substantially tidies up parse_associate and fixes:
LGTM!
I was close
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110052
--- Comment #4 from Bernhard Reutner-Fischer ---
(In reply to Bernhard Reutner-Fischer from comment #3)
> Note that in this particular case myrealloc() is static, maybe i should have
> omitted the noipa attribute for it was only meant to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110065
Bug ID: 110065
Summary: auto in template argument causes ICE, also
accepts-invalid
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110052
--- Comment #3 from Bernhard Reutner-Fischer ---
Note that in this particular case myrealloc() is static, maybe i should have
omitted the noipa attribute for it was only meant to simplify analysis and
there is no such attribute in the original
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
--- Comment #12 from Nikolas Klauser ---
(In reply to Jonathan Wakely from comment #10)
> Using always_inline on everything is simply wrong: GCC will refuse to inline
> some functions and the user gets an error that they cannot avoid. There's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109930
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
--- Comment #11 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #10)
> Do you want to be able to change these functions in
> ABI-incompatible ways between major revisions of the library?
Sorry, that was unclear, I meant to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109812
--- Comment #14 from Martin Jambor ---
(In reply to Jan Hubicka from comment #13)
> The only difference between slp vectorization is:
>
> - # _68 = PHI <_5(3)>
> - # _67 = PHI <_11(3)>
> - # _66 = PHI <_16(3)>
> - .r = _68;
> - .g = _67;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
Jonathan Wakely changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #10 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99195
--- Comment #19 from CVS Commits ---
The master branch has been updated by Kyrylo Tkachov :
https://gcc.gnu.org/g:d0c064c3eabc75cf83df296ebcd1db19b4a68851
commit r14-1448-gd0c064c3eabc75cf83df296ebcd1db19b4a68851
Author: Kyrylo Tkachov
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99195
--- Comment #18 from CVS Commits ---
The master branch has been updated by Kyrylo Tkachov :
https://gcc.gnu.org/g:547d3bce0c02dbcbb6f62d9469a71eedf17bd688
commit r14-1447-g547d3bce0c02dbcbb6f62d9469a71eedf17bd688
Author: Kyrylo Tkachov
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109812
Jan Hubicka changed:
What|Removed |Added
CC||rguenther at suse dot de
See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92707
Frank Heckenbach changed:
What|Removed |Added
CC||f.heckenb...@fh-soft.de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110064
Bug ID: 110064
Summary: spurious missing initializer for member for anonymous
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106271
--- Comment #5 from Thomas Schwinge ---
With the latter hunk applied (plus manual 'rm gcc/s-mlib gcc/multilib.h' to
regenerate the latter file), I find that this apparently does only address the
'--disable-multilib' case, but not my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
--- Comment #9 from Louis Dionne ---
(In reply to Andrew Pinski from comment #3)
> I am getting a feeling this attribute is well defined enough.
>
> Is it really just supposed to block explicit instantiation of templates?
> Is there a decent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110050
--- Comment #3 from Christophe Lyon ---
So we have a different behavior in
libstdc++-v3/include/experimental/bits/simd_detail.h:
#if defined __ARM_NEON && (__ARM_ARCH >= 8 || defined __aarch64__)
#define _GLIBCXX_SIMD_HAVE_NEON_A32 1
#else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106271
Thomas Schwinge changed:
What|Removed |Added
CC||doko at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34040
--- Comment #18 from Georg-Johann Lay ---
(In reply to Francois-Xavier Coudert from comment #11)
> As far as I can say, the targets with this problem are: avr, bfin, h8300,
> picochip and sh (for some subtargets of sh).
>
> On avr, bfin, h8300
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110050
--- Comment #2 from Christophe Lyon ---
Just noticed that the test passes if GCC is configured --with-arch=armv7-a, but
fails when forcing -march=armv8-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106271
Thomas Schwinge changed:
What|Removed |Added
CC||tschwinge at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061
Wilco changed:
What|Removed |Added
Resolution|DUPLICATE |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061
--- Comment #6 from Andrew Pinski ---
bug 70814 comment #3 explains why this should not be done. As I mentioned it
can be improved for armv8.4-a maybe using an ifunc but it cannot be done for
before that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814
--- Comment #13 from Andrew Pinski ---
*** Bug 110061 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772
--- Comment #10 from Jakub Jelinek ---
And the reason for the helper functions is C++11 which would not like
temporaries in constexpr functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061
Wilco changed:
What|Removed |Added
Last reconfirmed||2023-05-31
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772
--- Comment #9 from Jakub Jelinek ---
Sorry, 0x1.0p-1016 * 0x1.0p-1016 * 0x1.0p-1016 obviously should have been
0x1.0p+1016 * 0x1.0p+1016 * 0x1.0p+1016, I tested it on a testcase where I used
different names etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110059
--- Comment #4 from Jakub Jelinek ---
I'd like to point out that doing performance testing for GCC 10 at this point
isn't a very good idea, GCC 10 is going out of support within a month or two,
and while some important wrong-code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772
--- Comment #8 from Jakub Jelinek ---
Dunno.
I think you can add support even without any compiler changes, at least if
_GLIBCXX_DOUBLE_IS_IEEE_BINARY64:
#ifdef __STRICT_ANSI__
static _GLIBCXX_CONSTEXPR __float128
min()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110063
--- Comment #1 from Eliaz Pitavy ---
Adding ctx.set_bool_option(GCC_JIT_BOOL_OPTION_SELFCHECK_GC, 1);
reduces the memory leak to 733302 bytes leaked in 5589 allocations.
Adding ctx.set_bool_use_external_driver(1);
reduces the memory leak to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110059
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110044
--- Comment #6 from Iain Sandoe ---
I'm going to test the following (which will take some time since the hardware
is needed for testing releases too).
The test for AGGREGATE_TYPE_P() could actually be changed to
RECORD_OR_UNION_TYPE_P () -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110055
--- Comment #2 from Sprite ---
Note that the error is raised only on the second and subsequent variables, the
first variable works fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110039
Christophe Lyon changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110039
--- Comment #2 from CVS Commits ---
The master branch has been updated by Christophe Lyon :
https://gcc.gnu.org/g:070d651c6db37c3658be0a5274f44265045428e6
commit r14-1437-g070d651c6db37c3658be0a5274f44265045428e6
Author: Christophe Lyon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659
Andrew Pinski changed:
What|Removed |Added
Summary|Suboptimal 128 bit atomics |Suboptimal 128 bit atomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814
Andrew Pinski changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110063
Bug ID: 110063
Summary: Leaks in gcc driver accumulate when calling
gcc_jit_context_compile
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
1 - 100 of 158 matches
Mail list logo
