https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #19 from Gavin Howard ---
Understood.
If I had to guess, and this is a *wild* guess, it's because I'm putting a
pointer to a function in the allocation.
As far as I can tell, this is still allowed, per the docs:
> Attribute `mallo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #17 from Gavin Howard ---
> These links are dead. That's why we want references to a standalone testcase
> given (lines in it or functions and so on)...
Fair enough, but in my defense, it's been two years. I was pretty sure this had
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
--- Comment #15 from Maxim Egorushkin ---
(In reply to Maxim Egorushkin from comment #14)
> (In reply to Andrew Pinski from comment #6)
>
> > It happens more often with vector instructions/registers due to the
> > different "modes" of the regis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108680
--- Comment #9 from Jerry DeLisle ---
We can have only one default integer otherwise its not a default. Our default
integer is KIND=4
The RANGE of KIND=4 integer is 9, so we exceed the requirement for at least a
decimal range of 5. RANGE is def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119003
--- Comment #1 from Richard Biener ---
The comment is before the respective workers (walk_aliased_vdefs_1 for
example), copy-pasting leads to divergence so I tend to omit the duplication
...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119006
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950
Richard Biener changed:
What|Removed |Added
Status|RESOLVED|NEW
Component|target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118994
--- Comment #6 from Hongtao Liu ---
(In reply to John Platts from comment #5)
> GCC also fails to optimize (a | b) - ((a ^ b) >> 1) down to a single SSE2
> PAVGB/PAVGW, NEON/SVE2 SRHADD/URHADD, AltiVec
> vavgsb/vavgsh/vavgsw/vavgub/vavguh/vavguw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118780
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.4
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118780
--- Comment #5 from GCC Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:1283b9f946eea07573be5ba0e0785c9e9279b3be
commit r13-9390-g1283b9f946eea07573be5ba0e0785c9e9279b3be
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118780
--- Comment #4 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:09cc01ca00a140c110c02e4ba297da4718f105e8
commit r14-11341-g09cc01ca00a140c110c02e4ba297da4718f105e8
Author: Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950
--- Comment #11 from Robin Dapp ---
I figured this particular problem on RISC-V won't be fixed on GCC 14 because we
don't have the zeroing of masked elements there. But you're referring to
backporting just this patch, right?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #16 from Sam James ---
(In reply to Gavin Howard from comment #0)
> [1]:
> https://git.yzena.com/Yzena/Yc/src/commit/
> 6afdc86bd2c17f98b2f9e97e79e37fdf8c6b7708/src/alloc/stackpool.c#L441
>
> [2]:
> https://git.yzena.com/Yzena/Yc/sr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #18 from Sam James ---
That's exactly where I saw it ;)
I go over bugs marked as needs-reduction/wrong-code/needs-bisection often, but
this bug wasn't marked as those, so I didn't see it. WAITING means we need the
reporter to give u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118994
--- Comment #5 from John Platts ---
GCC also fails to optimize (a | b) - ((a ^ b) >> 1) down to a single SSE2
PAVGB/PAVGW, NEON/SVE2 SRHADD/URHADD, AltiVec
vavgsb/vavgsh/vavgsw/vavgub/vavguh/vavguw instruction where supported on the
target, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111008
Andrew Pinski changed:
What|Removed |Added
CC||terryinzaghi at 163 dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119008
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
--- Comment #16 from Maxim Egorushkin ---
(In reply to Maxim Egorushkin from comment #14)
> (In reply to Andrew Pinski from comment #6)
>
> > It happens more often with vector instructions/registers due to the
> > different "modes" of the regis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119008
Bug ID: 119008
Summary: for token(>): compiler can NOT distinguish
close-template-block(>) from operator(>):
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118991
--- Comment #2 from Andreas Schwab ---
There are more occurrences of this problem:
#: config/pru/pru-pragma.cc:61
msgid "% index %"
#: config/pru/pru-pragma.cc:64
msgid "redefinition of %
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119008
--- Comment #2 from terryinzaghi ---
x86-64 gcc 14.2
-std=c++23 -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119008
--- Comment #3 from terryinzaghi ---
(In reply to Andrew Pinski from comment #1)
> Dup. The problem is GCC thinks > ends the template argument even though it
> is still inside a lambda definition.
>
> *** This bug has been marked as a duplicate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118949
Vineet Gupta changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119003
Bug ID: 119003
Summary: walk_aliased_vdefs and others are missing a comment in
the front of it descriping what it does
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118976
--- Comment #12 from Luke Robison ---
Tamar,
I'm happy to test as many flags as you can think of, just send them my way.
See below for detailed results, but I see that -fdisable-tree-cunroll does not
fix the problem, and I suspect that -march=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119005
Alejandro Colomar changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #2 from Alejandro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119005
--- Comment #3 from Alejandro Colomar ---
Hmmm, thinking twice, I guess it is not a false positive. I can rewrite to
something similar, which avoids the overflow, and avoids the diagnostic:
alx@debian:~/tmp$ cat foo.c
#include
int
f(void)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119005
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #4 from Andrew Pins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119002
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114088
--- Comment #5 from Thiago Macieira ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Xi Ruoyao from comment #2)
> > But __builtin_strlen *does* get optimized when the input is a string
> > literal.
>
> But so does strlen, becaus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119004
Bug ID: 119004
Summary: Inconsistent set of flags to trigger -Wstrict-overflow
diagnostics
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118949
--- Comment #7 from Vineet Gupta ---
I can confirm that it is happening due to following hunk from
r15-5943-gdc0dea98c96e02
bool
ssa_is_replaceable_p (gimple *stmt)
{
if (!is_gimple_assign (stmt))
#if 0
&& (!(call = dyn_cast (stmt))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119005
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119002
--- Comment #3 from Jakub Jelinek ---
Perhaps without looking at the setter, it could:
/* See whether the operands might be unordered. */
if (HONOR_NANS (GET_MODE (XEXP (op0, 0
all = 15;
else if (!flag_finite_math_only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119005
Bug ID: 119005
Summary: -Wstrict-overflow=3 false positive with static
variable
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116686
--- Comment #8 from Edwin Lu ---
(In reply to Robin Dapp from comment #7)
> Hmm, I don't fully understand. We're actually building with zvl256b right,
> zvl1024b is first and thus gets overridden? But with zvl256b and QEMU
> vlen=256 I'm not s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108680
--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #7)
> From the 2023 standard I find:
>
> "The keyword INTEGER with no kind-selector specifies type integer with
> default kind; the kind type parameter val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118947
--- Comment #5 from Andrew Pinski ---
Created attachment 60578
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60578&action=edit
Patch which I am testing for the aliasing improvement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118595
--- Comment #2 from Robin Dapp ---
Hmm I'm not seeing those locally with -march=rv64gcv_zvl256b at least. Which
exact options were used to run the test suite? Or have those fails disappeared
in the meanwhile?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118949
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119007
Jin Ma changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |majin at gcc dot gnu.org
Ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119007
Bug ID: 119007
Summary: RISC-V: The optimization ignored the side effects of
the rounding mode, resulting in incorrect results for
rvv
Product: gcc
Version: 15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
--- Comment #14 from Maxim Egorushkin ---
(In reply to Andrew Pinski from comment #6)
> It happens more often with vector instructions/registers due to the
> different "modes" of the registers that it can hold (subregs).
That's right, my empir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119006
Sam James changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13/14/15 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119006
Bug ID: 119006
Summary: IPA ICF and LTO cause strcmp condition to be omitted
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118991
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119006
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119006
--- Comment #2 from Jeff Snyder ---
Further simplified:
template struct FixedString {
bool operator==(const char* rhs_) const { return rhs_ and not
__builtin_strcmp(_str, rhs_); }
bool operator!=(const char* rhs_) const { return !(*this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119006
--- Comment #3 from Andrew Pinski ---
Your source does not work either:
FixedString(const char* str_) { *this = str_; }
Is an infinite loop.
It should be:
FixedString(const char* str_) { __builtin_strcpy (this->_str, str_); }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119006
--- Comment #4 from Andrew Pinski ---
Created attachment 60579
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60579&action=edit
Runtime testcase
Fails with `-O2 -g0 -fwhole-program` but works without -fwhole-program. So no
need for LTO.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119006
Andrew Pinski changed:
What|Removed |Added
Attachment #60579|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119006
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.5
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992
--- Comment #9 from Hongtao Liu ---
(In reply to H.J. Lu from comment #8)
> (In reply to Richard Biener from comment #7)
>
> >
> > >else if (targetm.small_register_classes_for_mode_p (GET_MODE (x)))
> > > record = false;
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119006
--- Comment #7 from Sam James ---
Bisecting.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118944
--- Comment #3 from waffl3x ---
(In reply to Patrick Palka from comment #1)
> Confirmed. This bug also affects ordinary static member functions:
>
Nice, good find.
(In reply to Patrick Palka from comment #2)
> > As far as I know, these functi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89967
--- Comment #6 from Andrew Pinski ---
So the main thing that needs to be handled is:
```
# .MEM_144 = VDEF <.MEM_143>
g2b = D.23244;
# VUSE <.MEM_144>
_29 = g1b.val[0];
g1v_73 = VIEW_CONVERT_EXPR(_29);
# VUSE <.MEM_144>
_30 = g1b.va
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
--- Comment #13 from Maxim Egorushkin ---
(In reply to Andrew Pinski from comment #11)
> Let me try again:
>
> So we have:
> __v4di v4 = ymm0
> __v2di tmp = _mm256_extracti128_si256(v4, 1); // vextracti128
> __v2di tmp1 = _mm256_castsi256_si128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19831
--- Comment #24 from Andrew Pinski ---
(In reply to Marc Glisse from comment #16)
> Some more transformations for the list:
>
> p = malloc (n);
> memcpy (p, q, m);
> free (q);
>
> ==>
>
> p = realloc (q, n);
>
> it isn't equivalent, in partic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #13 from Sam James ---
(In reply to Sam James from comment #12)
> I suspect this is abuse of __attribute__((malloc)).
y_stackpool_malloc returns a value derived from input `p`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #12 from Sam James ---
I suspect this is abuse of __attribute__((malloc)).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #11 from Sam James ---
It still aborts with -O1 -fno-strict-aliasing (just to be sure, though -O1
shouldn't need it). It passes with -O1 -fno-tree-pta.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
Sam James changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #14 from Sam James ---
Hm, dropping the attribute everywhere doesn't help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99829
Sam James changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
--- Comment #15 from Andrew Pinski ---
void*
y_realloc(void* ptr, y_usize size) __attribute__((malloc));
Yes that should NOT be malloc.
I wonder if removing malloc from y_realloc fixes the issue.
NOTE realloc is not marked as malloc.
See th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115347
--- Comment #9 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:2456fd2c73df1839f645f36b09d3b33aea1883d3
commit r14-11327-g2456fd2c73df1839f645f36b09d3b33aea1883d3
Author: Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112859
--- Comment #9 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:a3871eead4540b3a746b877408088d41ce12c846
commit r14-11328-ga3871eead4540b3a746b877408088d41ce12c846
Author: Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052
--- Comment #17 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:c886bd9ab21429a11bea393b5a6e7438a1d924ef
commit r14-11329-gc886bd9ab21429a11bea393b5a6e7438a1d924ef
Author: Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115494
--- Comment #17 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:95c98c5368aedf2a482bf551cd2573c1961a6823
commit r14-11330-g95c98c5368aedf2a482bf551cd2573c1961a6823
Author: Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112859
--- Comment #8 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:2456fd2c73df1839f645f36b09d3b33aea1883d3
commit r14-11327-g2456fd2c73df1839f645f36b09d3b33aea1883d3
Author: Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118662
--- Comment #18 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:7c36056ede3a7e0eed8c95b4080b3f4ce6be12b1
commit r14-11333-g7c36056ede3a7e0eed8c95b4080b3f4ce6be12b1
Author: Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116906
--- Comment #8 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:fbecb7df9742ade5513d901ca03e9a6c082915e5
commit r14-11331-gfbecb7df9742ade5513d901ca03e9a6c082915e5
Author: Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117424
--- Comment #15 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:a42b180b4b46417b0e8b2d548f34aeec7826abd0
commit r14-11332-ga42b180b4b46417b0e8b2d548f34aeec7826abd0
Author: Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118996
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115494
Richard Biener changed:
What|Removed |Added
Known to fail||14.2.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118662
Richard Biener changed:
What|Removed |Added
Known to fail||14.2.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117023
--- Comment #8 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:206cb6c10589bef4afc90f4df993fc3bdb031e27
commit r15-7682-g206cb6c10589bef4afc90f4df993fc3bdb031e27
Author: Jakub Jelinek
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117023
--- Comment #9 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:0d590d21586edbb9c62ce3db92794d93faf7ed34
commit r15-7683-g0d590d21586edbb9c62ce3db92794d93faf7ed34
Author: Jakub Jelinek
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112426
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90424
--- Comment #10 from Richard Biener ---
(In reply to Andrew Pinski from comment #9)
> Hmm, we get:
> BIT_INSERT_EXPR ;
>
> Since r_5 is unintialized, can't we just do:
> {_1, 0}
>
> ?
Yes. Though I always get nervous when replacing a UNDEF wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100697
Andrew Pinski changed:
What|Removed |Added
CC||acoplan at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #41 from Xi Ruoyao ---
So fixed? Or should we reject the code if it uses init_priority(99) and
-fvtable-verify at the same time?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118993
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:27ebd2a55cd373542977b21631b6b0919e703733
commit r15-7684-g27ebd2a55cd373542977b21631b6b0919e703733
Author: Jakub Jelinek
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118151
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=118973
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118975
--- Comment #7 from Richard Biener ---
(In reply to Andrew Pinski from comment #4)
> #ifndef LINK_COMMAND_SPEC
> #define LINK_COMMAND_SPEC "\
> %{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
> %(linker) " \
> LINK_PLUGIN_SPEC \
>"%{flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118975
--- Comment #8 from Andrew Pinski ---
(In reply to Richard Biener from comment #7).
>
> A more explicit set of u* options to pass through might be better.
Except i am not sure if will work as the option is '-u arg'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118976
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118988
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118976
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=118989
Andrew Pinski changed:
What|Removed |Added
Keywords||documentation
Component|other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992
--- Comment #7 from Richard Biener ---
(In reply to H.J. Lu from comment #6)
> This works for x86-64:
>
> diff --git a/gcc/cse.cc b/gcc/cse.cc
> index 70d5caac4ca..786624cd890 100644
> --- a/gcc/cse.cc
> +++ b/gcc/cse.cc
> @@ -2287,6 +2287,10 @
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118994
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118994
Uroš Bizjak changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992
--- Comment #8 from H.J. Lu ---
(In reply to Richard Biener from comment #7)
>
> >else if (targetm.small_register_classes_for_mode_p (GET_MODE (x)))
> > record = false;
> >else if (targetm.class_likely_spilled_p (REGNO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981
--- Comment #42 from Jonathan Wakely ---
The bootstrap regression in the library is fixed, but there's still a problem
with the compiler that makes -fvtable-verify=std incompatible with
init_priority(99).
Either we should fix that so it works,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118973
--- Comment #5 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:9e4c57f7a69d7060612c83867ecff61a719b97af
commit r15-7685-g9e4c57f7a69d7060612c83867ecff61a719b97af
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118973
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118923
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
1 - 100 of 155 matches
Mail list logo
