https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116900
Bug ID: 116900
Summary: False Positive Use After Free Warning
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116900
--- Comment #2 from alpha.and.omega.programmer ---
Created attachment 59232
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59232&action=edit
gcc -v -save-temps .i file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116900
--- Comment #1 from alpha.and.omega.programmer ---
Created attachment 59231
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59231&action=edit
gcc -v
Output of gcc -v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116898
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116785
--- Comment #14 from kugan at gcc dot gnu.org ---
(In reply to Richard Biener from comment #13)
> Did it help?
Thanks for the quick Fix. This commit brings back most of the regression.
Please note that the current trunk seems to be broken for un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116898
--- Comment #1 from Andrew Pinski ---
Interesting it does NOT ICE for aarch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116885
--- Comment #20 from Jonathan Wakely ---
(In reply to Jaroslav Fojtík from comment #0)
> jara@cfarm421:~/mintest$ make
> gcc -I./ -Wall -g -O2 -c struct.c -o struct.o
> gcc -I./ -Wall -g -O2 -c mintest.c -o mintest.o
> gcc -lm -o mintest str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116899
--- Comment #1 from Andrew Pinski ---
Created attachment 59229
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59229&action=edit
testcase that fails everywhere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116899
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116887
--- Comment #10 from chenglulu ---
(In reply to Xi Ruoyao from comment #8)
> (In reply to chenglulu from comment #7)
> It seems like a previous attempt to fix PR 52999: r186919. But it was then
> reverted and changed to TARGET_SECTION_TYPE_FLAG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116896
--- Comment #4 from Jakub Jelinek ---
I think it wouldn't be that hard to change optimize_spaceship to also handle
integer comparisons, just change that !SCALAR_FLOAT_TYPE_P (TREE_TYPE (arg1))
to that || INTEGRAL_TYPE_P (TREE_TYPE (arg1)) and ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116896
--- Comment #6 from Jakub Jelinek ---
Though, that setg %cl without xorl %ecx, %ecx first is unlikely to perform
well, the clearing would be needed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116896
--- Comment #5 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #4)
> I think it wouldn't be that hard to change optimize_spaceship to also handle
> integer comparisons, just change that !SCALAR_FLOAT_TYPE_P (TREE_TYPE
> (arg1)) to t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116896
--- Comment #7 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #6)
> Though, that setg %cl without xorl %ecx, %ecx first is unlikely to perform
> well, the clearing would be needed.
No, because subb (sbbb) opreates on bytes and no z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116896
--- Comment #8 from Jakub Jelinek ---
Though, maybe the integral SPACESHIP pattern matching wouldn't help. Even for
std::partial_ordering
w4 (float const& lhs, float const& rhs) {
return lhs <=> rhs;
}
we pattern recognize it into
_11 = .SP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116887
--- Comment #11 from Florian Weimer ---
I'm surprised that you can load from .data.rel.ro using la.local. Isn't it
possible for RELRO data (which is writable at first, so separate from code)
very far away from any text section? I'm going by the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
Christophe Lyon changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
--- Comment #14 from andi at firstfloor dot org ---
The test relies on the
gcc/testsuite/lib/target-supports.exp:check_effective_target_tail_call
probe matching what the test does. Perhaps the way you are passing options
doesn't pass them to th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116877
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116888
--- Comment #2 from Jonathan Wakely ---
I think this is "ill-formed; no diagnostic required".
Instantiating Test1 does not instantiate Helper or the partial
specialization Helper, so the invalid template argument is not needed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116887
--- Comment #8 from Xi Ruoyao ---
(In reply to chenglulu from comment #7)
> I trimmed the test case and found that the error was caused by the following
> statement:
>
> ;; basic block 8, loop depth 1
> ;;pred: 7
> if (l_7 == &_rt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116887
Xi Ruoyao changed:
What|Removed |Added
Known to fail||13.3.1, 14.2.0, 15.0
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116896
--- Comment #2 from Andrew Pinski ---
aarch64 code gen:
-UMANUAL:
```
_Z3watRKiS0_:
ldr w3, [x0]
mov w2, 1
ldr w0, [x1]
cmp w3, w0
csinv w0, w2, wzr, ge
cselw0, w0, wzr, ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116887
--- Comment #9 from Xi Ruoyao ---
In https://gcc.gnu.org/pipermail/gcc-patches/2012-April/338779.html:
> Putting function labels (plabels) in the constant pool results
> in a section flag conflict compiling rtld.c. Other targets don't
> do thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116896
--- Comment #3 from Jakub Jelinek ---
Note, we have a pattern matcher for floating point spaceship (that has without
-ffast-math 4 cases), but not for integer. And the code we emit for lhs <=>
rhs matches
what we emit for
if (lhs == rhs) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81265
--- Comment #4 from GCC Commits ---
The master branch has been updated by Andre Vehreschild :
https://gcc.gnu.org/g:bac95615b50d4a012c448cba080c106702184e3a
commit r15-3958-gbac95615b50d4a012c448cba080c106702184e3a
Author: Andre Vehreschild
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116896
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116887
--- Comment #6 from chenglulu ---
Created attachment 59228
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59228&action=edit
Cropped test cases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81265
Andre Vehreschild changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700
Bug 83700 depends on bug 81265, which changed state.
Bug 81265 Summary: allocatable coarrays in submodule subroutines wrongly
identified as unallocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81265
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51815
Andre Vehreschild changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116887
--- Comment #7 from chenglulu ---
I trimmed the test case and found that the error was caused by the following
statement:
;; basic block 8, loop depth 1
;;pred: 7
if (l_7 == &_rtld_globalD.3739._dl_rtld_mapD.3732)
goto ; [INV]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #351 from John Paul Adrian Glaubitz ---
(In reply to Kazumoto Kojima from comment #344)
> Created attachment 59219 [details]
> a patch for c#339
>
> This adds checks if the address register of the memory displacement is
> general or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116887
--- Comment #12 from Xi Ruoyao ---
(In reply to chenglulu from comment #10)
> (In reply to Xi Ruoyao from comment #8)
> > (In reply to chenglulu from comment #7)
> > It seems like a previous attempt to fix PR 52999: r186919. But it was then
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116887
--- Comment #13 from Xi Ruoyao ---
(In reply to Florian Weimer from comment #11)
> I'm surprised that you can load from .data.rel.ro using la.local. Isn't it
> possible for RELRO data (which is writable at first, so separate from code)
> very fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #352 from John Paul Adrian Glaubitz ---
Since I'm unable to build WebKit with -O2 due to memory constraints, I'm
building with -O1 now. This unfortunately triggered another ICE which does not
show with -O2:
/usr/bin/g++-15 -DBUILDING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116901
Bug ID: 116901
Summary: pr110625_4.c fails on aarch64 since
r15-3794-g2c04f175de4f39
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116902
--- Comment #2 from Richard Biener ---
Testcase w/o header:
template
inline const _Tp&
min(const _Tp& __a, const _Tp& __b)
{
if (__b < __a)
return __b;
return __a;
}
unsigned a;
void i(long b, char c[][4], long d[][4]) {
for (char e;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116904
Bug ID: 116904
Summary: RISC-V: address calculation not hoisted from loop
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116898
--- Comment #5 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 59236 [details]
> gcc15-pr116898.patch
>
> So like this? Will test tonight.
perfect. consider it pre-pproved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59660
--- Comment #18 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #17)
> I have a phiopt change which allows us now to optimize this in phiopt2 (and
> get the tail call in tailr2).
phiprop should do it instead of phiopt ...
df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20240930 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116904
--- Comment #1 from Andrey Khorokhorin ---
`-fpic` flag solves the problem, but it seems like a workaround, but not a
solution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116903
--- Comment #1 from Jonathan Wakely ---
I think that's a valid ECMAScript regular expression.
Try alert(RegExp("a{0}}").test("}")); in your browser console.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116899
--- Comment #5 from Jakub Jelinek ---
Even if create (n) didn't work (which would be good to debug), the
x.safe_grow_cleared (n); x.truncate (0); can be just done more efficiently with
x.reserve (n);
Anyway, the more important question is if ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116890
--- Comment #2 from Andrew Pinski ---
Here is another example:
```
int g(bool a, bool b, int c)
{
int x;
if (c) x = a | b;
else x = 1;
return x;
}
int g1(bool a, bool b, int c)
{
bool x;
if (c) x = a | b;
else x = 1;
return x;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
--- Comment #16 from andi at firstfloor dot org ---
On Mon, Sep 30, 2024 at 03:05:11PM +, clyon at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
>
> --- Comment #15 from Christophe Lyon ---
> (In reply to andi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116583
--- Comment #6 from Richard Sandiford ---
Sorry for the slow response (here and in general). Been having to
spend my time on other things recently :(
I agree that this case is regular enough to handle for VLA, but it
seems to me like a separat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116080
--- Comment #15 from Christophe Lyon ---
(In reply to andi from comment #14)
> The test relies on the
>
> gcc/testsuite/lib/target-supports.exp:check_effective_target_tail_call
Are you sure?
musttail7.c has:
/* { dg-do compile { target { mustta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116611
--- Comment #6 from Robin Dapp ---
Hmm, the RTL follows the gimple code pretty well and those
vect_array.27[0] = vect__2.17_71;
become subreg-subreg moves.
vect_array.27 is only dead after the v10 use.
How should it ideally work? Could we r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116896
--- Comment #10 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > I think it wouldn't be that hard to change optimize_spaceship to also handle
> > integer comparisons, just change th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116899
--- Comment #6 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #5)
> Even if create (n) didn't work (which would be good to debug), the
> x.safe_grow_cleared (n); x.truncate (0); can be just done more efficiently
> with x.reserve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116896
--- Comment #11 from Jakub Jelinek ---
I'll try to tweak the .SPACESHIP discovery, so that it will also check for the
common case where the .SPACESHIP result is solely used in comparisons leading
to -1, 0, 1, 2
(or -1, 0, 1) PHI and in that case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116792
--- Comment #6 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:3286b6724ec1d005436dffa5228516db88e754b9
commit r15-3972-g3286b6724ec1d005436dffa5228516db88e754b9
Author: David Malcolm
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613
--- Comment #8 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:3d3d20ccd8365970f34002bfe0a632f2868bc95b
commit r15-3974-g3d3d20ccd8365970f34002bfe0a632f2868bc95b
Author: David Malcolm
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613
--- Comment #10 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:be02253af810348be689cfa6f235af96c8cc5802
commit r15-3976-gbe02253af810348be689cfa6f235af96c8cc5802
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613
--- Comment #11 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:e7a8fbe2fed83b5ce6e2bdb6fd66d9bf47f74db7
commit r15-3977-ge7a8fbe2fed83b5ce6e2bdb6fd66d9bf47f74db7
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613
--- Comment #12 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:9c14f9a9c19957d9a45a7df97701bad475c80eea
commit r15-3978-g9c14f9a9c19957d9a45a7df97701bad475c80eea
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116611
--- Comment #8 from Robin Dapp ---
(In reply to Richard Biener from comment #7)
> (In reply to Robin Dapp from comment #6)
> > Hmm, the RTL follows the gimple code pretty well and those
> >vect_array.27[0] = vect__2.17_71;
> > become subreg-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116898
--- Comment #4 from Jakub Jelinek ---
Created attachment 59236
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59236&action=edit
gcc15-pr116898.patch
So like this? Will test tonight.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #355 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #352)
> I will try to figured out what optimization flag triggered the ICE. Also, I
> will provide the preprocessed source in the next comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116897
Patrick Palka changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113563
Patrick Palka changed:
What|Removed |Added
CC||djnz00 at gmail dot com
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116785
Richard Biener changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115236
Bug 115236 depends on bug 116785, which changed state.
Bug 116785 Summary: [15 Regression] RAJAPerf REDUCE_SUM regresses with
r15-792-gf0a02467bbc35a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116785
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116879
Richard Biener changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116879
--- Comment #3 from Richard Biener ---
I'll note it is loop distribution that leaves around the forwarder which
CFG cleanup is not able to remove (because it has a PHI, pass_merge_phi would).
We might want to enhance CFG cleanup to handle the ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116583
--- Comment #7 from Richard Sandiford ---
...actually, they probably don't need to bijective. I suppose
[0, 0] for two-lane SLP is handled too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116900
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #3 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
--- Comment #33 from Tamar Christina ---
Many Thanks Mikael!
I see the functions being inlined now!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116609
Richard Biener changed:
What|Removed |Added
Blocks|116578 |53947
--- Comment #3 from Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #353 from John Paul Adrian Glaubitz ---
Created attachment 59235
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59235&action=edit
Preprocessed source from from comment #352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116896
--- Comment #9 from Jakub Jelinek ---
So, I think this boils down on which one from
int
foo (int x, int y)
{
if (x < y)
return -1;
else if (x > y)
return 1;
else
return 0;
}
int
bar (int x, int y)
{
if (x == y)
return 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7
Andrew Pinski changed:
What|Removed |Added
Depends on||59660
--- Comment #6 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116906
Bug ID: 116906
Summary: floating point exception under -O2 optimization
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116899
--- Comment #8 from Jakub Jelinek ---
I've gathered some statistics using:
--- gcc/gimple-range-cache.h.jj 2024-07-02 15:07:55.231913151 +0200
+++ gcc/gimple-range-cache.h2024-09-30 19:03:35.848466925 +0200
@@ -141,6 +141,7 @@ private:
bo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116899
--- Comment #9 from Jakub Jelinek ---
Created attachment 59238
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59238&action=edit
gcc15-pr116899.patch
Untested fix in patch form.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107775
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107775
--- Comment #4 from Andrew Pinski ---
MEM[(v2df *)&v] = reg.0_1;
v[0] = b_5(D);
_2 = MEM[(v2df *)&v];
Maybe that could be converted into:
MEM[(v2df *)&v] = reg.0_1;
BIT_FIELD_REF = b_2(D);
_2 = MEM[(v2df *)&v];
BIT_INSERT_EXPR ..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #361 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #360)
>
> I think that it's an issue for call insns not for normal insns. As reported
> in c#276, LRA handles call insns specially, and it seems to be an argument
> a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116895
Hans-Peter Nilsson changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #362 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #361)
> Do you know if there's any particular reason why sfunc on SH can't be done
> via regular call insn path? I can imagine it was originally done to
> optimize the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113261
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-10-01
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116098
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 115373, which changed state.
Bug 115373 Summary: [15 Regression] RISCV slp-cond-2-big-array.c slp-cond-2.c
scan-tree-dump fails since r15-859-geaaa4b88038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115373
Wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116578
Bug 116578 depends on bug 115373, which changed state.
Bug 115373 Summary: [15 Regression] RISCV slp-cond-2-big-array.c slp-cond-2.c
scan-tree-dump fails since r15-859-geaaa4b88038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115373
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116903
Bug ID: 116903
Summary: c++ regex accepts } and ] as a literal character.
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116902
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116817
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #354 from Oleg Endo ---
Kaz, I just spotted one LRA related thing on the ML
https://gcc.gnu.org/pipermail/gcc-regression/2024-August/080509.html
https://github.com/gcc-mirror/gcc/commit/3c67a0fa1dd39a3378deb854a7fef0ff7fe38004
Could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116899
--- Comment #3 from Jakub Jelinek ---
Similarly to the other BB, enable_ranger -> gimple_ranger -> ranger_cache does
1000 m_workback.create (0);
1001 m_workback.safe_grow_cleared (last_basic_block_for_fn (cfun));
1002 m_workback.t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116900
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112543
Xi Ruoyao changed:
What|Removed |Added
CC||alpha.and.omega.programmer@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #356 from Andrew Pinski ---
(In reply to John Paul Adrian Glaubitz from comment #355)
> (In reply to John Paul Adrian Glaubitz from comment #352)
> > I will try to figured out what optimization flag triggered the ICE. Also, I
> > will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116899
--- Comment #7 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #6)
> (In reply to Jakub Jelinek from comment #5)
> > Even if create (n) didn't work (which would be good to debug), the
> > x.safe_grow_cleared (n); x.truncate (0);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116913
--- Comment #1 from Sam James ---
https://dev.gentoo.org/~sam/bugs/gcc/ff-cxx-116913/Unified_cpp_widget3.ii.xz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116913
Bug ID: 116913
Summary: [15 regression] ICE when building firefox-130.0.1
(tree check: expected var_decl or function_decl or
field_decl or type_decl or concept_decl or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116913
--- Comment #2 from Sam James ---
g++ -c ./Unified_cpp_widget3.ii -fno-exceptions is enough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116907
--- Comment #6 from Sam James ---
Created attachment 59243
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59243&action=edit
reduced.ii
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116907
--- Comment #7 from Sam James ---
Under gdb, I get:
```
during IPA pass: modref
/tmp/b.ii:81:3: internal compiler error: tree code ‘ggc_freed’ is not supported
in LTO streams
81 | }};
| ^
0x56f4ef9c internal_error(char const*, ...
1 - 100 of 210 matches
Mail list logo
