https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112963
--- Comment #14 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:fdce86c9f07eb4f95ba438491c2b151e94be7ef2
commit r14-6451-gfdce86c9f07eb4f95ba438491c2b151e94be7ef2
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112963
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112847
Thomas Schwinge changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112704
Thomas Schwinge changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112955
Thomas Schwinge changed:
What|Removed |Added
CC||danglin at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100942
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
on=edit
Reproducer: to be gnatchopped
On running the code at [1], the gnat 13.2 compiler raises an error
about invalid prefix, which looks okay.
But the gnat trunk compiler causes a "Gnat Bug Detected", as seen
at [2].
Part of the message:
14.0.0 20231212 (experimental)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929
--- Comment #19 from Li Pan ---
(In reply to Robin Dapp from comment #7)
> Here
>
> 0x105c6 vse8.v v8,(a5)
>
> is where we overwrite m. The vl is 128 but the preceding vsetvl gets a4 =
> 46912504507016 as AVL which seems already borken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112962
Uroš Bizjak changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
Last re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #20 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
Bug ID: 112980
Summary: 64-bit powerpc ELFv2 does not allow nops to be
generated before function global entry point
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112962
--- Comment #2 from Jakub Jelinek ---
Started with r14-1145-g1ede03e2d0437ea9c2f7453fcbe263505b4e0def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112962
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112962
--- Comment #4 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #3)
> I was thinking whether it wouldn't be better to expand x86 const or pure
> builtins when lhs is ignored to nothing in the expanders.
Yes, this could be a better s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112962
--- Comment #5 from Jakub Jelinek ---
With -O1 or higher there is some DCE which will remove them (unless disabled),
but the above ICE is with -O0...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112918
--- Comment #11 from Richard Biener ---
The original testcase fails with the same pattern btw., alternating between
register classes / alternatives.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112962
--- Comment #6 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #3)
> I was thinking whether it wouldn't be better to expand x86 const or pure
> builtins when lhs is ignored to nothing in the expanders.
Something like this?
--cut h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112962
--- Comment #7 from Jakub Jelinek ---
On the other side, maybe we want some of the diagnostics that is only done at
expansion time (argument xyz must be such and such immediate). Though, at -O2
it isn't diagnosed anyway because it is DCEd.
Anyw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112981
Bug ID: 112981
Summary: [13/14 Regression] Big compile time and run time
regression in libasan with
g:f732bf6a603721f61102a08ad2d023c7c2670870
Product: gcc
Versi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112962
--- Comment #8 from Jakub Jelinek ---
Of course, yet another option is:
--- gcc/config/i386/i386.cc 2023-12-12 08:54:39.821148670 +0100
+++ gcc/config/i386/i386.cc 2023-12-12 11:07:03.795286363 +0100
@@ -19377,7 +19377,10 @@ ix86_gimple_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112962
--- Comment #9 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #8)
> Of course, yet another option is:
This goes out of my (limited) area of expertise, so if my proposed (trivial)
patch is papering over some other issue, I'll happi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112981
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112981
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112962
Uroš Bizjak changed:
What|Removed |Added
Assignee|ubizjak at gmail dot com |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93259
--- Comment #7 from m.cencora at gmail dot com ---
This seems to be fixed in gcc 12.3 and gcc 13+
Can we close this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112982
Bug ID: 112982
Summary: Missing optimization: fold max(b, a + 1) to b when a <
b
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Keyw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112983
Bug ID: 112983
Summary: gcc.cc: do_spec_1, ICE if missing '}' for %x{...}
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606
--- Comment #28 from Georg-Johann Lay ---
(In reply to Richard Biener from comment #25)
> I wonder if it would be possible to set the appropriate address-space when
> parsing the "progmem" attribute in the target?
No, that's not possible. You ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112962
--- Comment #11 from Jakub Jelinek ---
Sure. But we need to find out first what builtins might actually throw.
Perhaps with -fnon-call-exceptions those which read/store (vector loads/stores,
masked loads/stores, scatters/gathers?) memory can?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112984
Bug ID: 112984
Summary: Compiling program with -Wpedantic shows warning in
libraries
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112981
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112984
Gaius Mulley changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112891
--- Comment #6 from GCC Commits ---
The releases/gcc-13 branch has been updated by hongtao Liu
:
https://gcc.gnu.org/g:d3e140ac549a2117e82dac51f2e739b20f9c7941
commit r13-8149-gd3e140ac549a2117e82dac51f2e739b20f9c7941
Author: liuhongt
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112891
--- Comment #7 from GCC Commits ---
The releases/gcc-12 branch has been updated by hongtao Liu
:
https://gcc.gnu.org/g:2dc102c030093ab2abb69f6d991c6a43bf6f0201
commit r12-10037-g2dc102c030093ab2abb69f6d991c6a43bf6f0201
Author: liuhongt
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112891
--- Comment #8 from GCC Commits ---
The releases/gcc-11 branch has been updated by hongtao Liu
:
https://gcc.gnu.org/g:172b7ad97c46594d44aeb73dce03daff5f575cfb
commit r11-11135-g172b7ad97c46594d44aeb73dce03daff5f575cfb
Author: liuhongt
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112891
Hongtao Liu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112962
--- Comment #12 from Hongtao Liu ---
(In reply to Jakub Jelinek from comment #8)
> Of course, yet another option is:
> --- gcc/config/i386/i386.cc 2023-12-12 08:54:39.821148670 +0100
> +++ gcc/config/i386/i386.cc 2023-12-12 11:07:03.79528636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112962
--- Comment #13 from Hongtao Liu ---
> I prefer this solution, that's what we did for blendvps case.
> I don't know either, just follow what we did before (with false) when
> folding builtins.
I mean when I was working on
r14-1145-g1ede03e2d043
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107723
--- Comment #5 from GCC Commits ---
The master branch has been updated by Xi Ruoyao :
https://gcc.gnu.org/g:99182ea09f10beca8445396cbab491899536f5c3
commit r14-6455-g99182ea09f10beca8445396cbab491899536f5c3
Author: Xi Ruoyao
Date: Fri Nov 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112946
Gaius Mulley changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112962
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112962
--- Comment #15 from Jakub Jelinek ---
Created attachment 56864
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56864&action=edit
gcc14-pr112962-2.patch
And another one for nothrow/leaf. I'm too lazy to figure out the exact details
for -f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112956
--- Comment #1 from Jakub Jelinek ---
The above patch breaks a lot of tests though.
+FAIL: c-c++-common/cpp/eof-1.c -Wc++-compat (test for excess errors)
+FAIL: c-c++-common/cpp/eof-1.c -Wc++-compat unterminated macro (test for
errors, line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112985
Bug ID: 112985
Summary: LOGICAL_OP_NON_SHORT_CIRCUIT unconditionally execute
comparison even if it's very expensive
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86131
--- Comment #3 from Christophe Leroy ---
(In reply to Andrew Pinski from comment #2)
> The cost has been 2 since the day -mcpu=860 was added back in 1996
> (r0-10828).
Right, which means that a single left shift performs better than a multiply b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112971
--- Comment #2 from Robin Dapp ---
It doesn't look like the same issue to me. The other bug is related to TImode
handling in combination with mask registers. I will also have a look at this
one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112956
--- Comment #2 from Jakub Jelinek ---
--- libcpp/lex.cc.jj2023-12-11 12:39:23.353442196 +0100
+++ libcpp/lex.cc 2023-12-12 13:15:07.154019695 +0100
@@ -3809,7 +3809,7 @@ _cpp_get_fresh_line (cpp_reader *pfile)
cpp_token *
_cpp_lex_di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112986
Bug ID: 112986
Summary: s390x gcc O2, O3: Incorrect logic operation in <
comparison with the same values
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112961
--- Comment #4 from Richard Biener ---
So in this case VN doesn't "fix" it because
Value numbering stmt = _29 = MAX_EXPR <_16, prephitmp_18>;
Setting value number of _29 to _29 (changed)
Making available beyond BB3 _29 for value _29
Value numbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112985
--- Comment #1 from chenglulu ---
(In reply to Xi Ruoyao from comment #0)
> /* { dg-do compile } */
> /* { dg-options "-O2 -ffast-math -fdump-tree-gimple" } */
>
> int
> short_circuit (float *a)
> {
> float t1x = a[0];
> float t2x = a[1];
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112985
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #2 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112971
--- Comment #3 from Robin Dapp ---
In match.pd we do something like this:
;; Function e (e, funcdef_no=0, decl_uid=2751, cgraph_uid=1, symbol_order=4)
Pass statistics of "forwprop":
Matching expression match.pd:2771, gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112985
--- Comment #3 from Richard Biener ---
Btw, ideally you'd vectorize these compares ;) (there's a missed-optimization
bug for this I think)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112971
--- Comment #4 from JuzheZhong ---
Maybe try to remove this ?
/* (X & Y) == X becomes (X & ~Y) == 0. */
(simplify
(cmp:c (bit_and:c @0 @1) @0)
(cmp (bit_and @0 (bit_not! @1)) { build_zero_cst (TREE_TYPE (@0)); }))
(simplify
(cmp:c (co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112971
--- Comment #5 from Robin Dapp ---
Yes that's what I just tried. No infinite loop anymore then. But that's not a
new simplification and looks reasonable so there must be something special for
our backend.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112704
--- Comment #3 from David Malcolm ---
Aha! Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112961
--- Comment #5 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:878cb5acf0c499702ffd315e273f55e8bd0970b8
commit r14-6457-g878cb5acf0c499702ffd315e273f55e8bd0970b8
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112961
Richard Biener changed:
What|Removed |Added
Known to work||14.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606
--- Comment #29 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:eee13a3730bd1d7aa7b40687b1ee49c17d95159f
commit r14-6458-geee13a3730bd1d7aa7b40687b1ee49c17d95159f
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112736
--- Comment #4 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:6d0b0806eb638447c3184c59d996c2f178553d45
commit r14-6459-g6d0b0806eb638447c3184c59d996c2f178553d45
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112736
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606
--- Comment #31 from Jan Hubicka ---
This is Maritn's code, but I agree that equals_wpa should reject pairs with
"dangerous" attributes on them (ideally we should hash them).
I think we could add test for same attributes to equals_wpa and eventu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112968
Jakub Jelinek changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112984
--- Comment #2 from Gaius Mulley ---
Created attachment 56865
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56865&action=edit
Proposed fix
Here is a proposed fix - all libraries can be compiled with -Wpedantic (apart
from two which have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110625
--- Comment #22 from Tamar Christina ---
Bisected the remaining regression to:
dd86a5a69cbda40cf76388a65d3317c91cb2b501 is the first bad commit
commit dd86a5a69cbda40cf76388a65d3317c91cb2b501
Author: Richard Biener
Date: Thu Jun 22 11:40:46
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93259
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Resolu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112822
--- Comment #9 from Martin Jambor ---
Thank you, I have proposed the patch on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640356.html
If it is approved, I'd also like you to add the testcase to the testsuite as a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112987
Bug ID: 112987
Summary: [14 Regression][aarch64] ICE in
aarch64_do_track_speculation, at
config/aarch64/aarch64-speculation.cc:214 since
r14-5886-g426fddcbdad674
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112982
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112971
--- Comment #6 from Andrew Pinski ---
Looks like `{ 0, ... } & { -9, -8, -7, ... }` is not simplifying down to just
`{ 0, ...}`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112971
--- Comment #7 from Andrew Pinski ---
Can you modify:
```
/* x & 0 -> 0 */
(simplify
(bit_and @0 integer_zerop@1)
@1)
```
to
```
/* x & 0 -> 0 */
(simplify
(bit_and:c @0 integer_zerop@1)
@1)
```
That in theory should not matter but I don'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112940
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
-checking
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231212 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112988
Bug ID: 112988
Summary: [14] RISC-V vector: Variadic function call causes
runtime failure
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112971
--- Comment #8 from Robin Dapp ---
Yes, can confirm that this helps.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112971
--- Comment #9 from Andrew Pinski ---
The real fix will be to const_binop .
Right now const_binop only handles a few cases for VLA's VECTOR_CST and it
seems like it really only handles +, -, and sometimes * and sometimes left shit
.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112971
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112971
--- Comment #11 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #9)
> The real fix will be to const_binop .
> Right now const_binop only handles a few cases for VLA's VECTOR_CST and it
> seems like it really only handles +, -, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101631
Patrick Palka changed:
What|Removed |Added
CC||m.cencora at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98637
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Resolu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112986
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112987
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112982
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-12-12
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112978
Xi Ruoyao changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112984
--- Comment #3 from GCC Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:01cca857aa3e86a750f5df77ca6c36c0739f10f0
commit r14-6465-g01cca857aa3e86a750f5df77ca6c36c0739f10f0
Author: Gaius Mulley
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112984
Gaius Mulley changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112989
Bug ID: 112989
Summary: GC ICE with C++, `#include ` and
`-fsanitize=address`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: GC, ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112822
--- Comment #10 from GCC Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:cd7d0b4cf789264cd75ab7df5df232dc58061ed7
commit r14-6466-gcd7d0b4cf789264cd75ab7df5df232dc58061ed7
Author: Martin Jambor
Date:
ter/configure
--prefix=/home/mjires/built/master --target=s390x-linux-gnu --disable-bootstrap
--enable-languages=c,c++ --disable-multilib --disable-libsanitizer
--enable-checking
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231212 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112655
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112989
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112989
--- Comment #2 from Andrew Pinski ---
#1 0x012eeda4 in gt_ggc_mx_lang_tree_node (x_p=0xf6bd4900) at
./gt-cp-tree.h:108
108xlimit = ((union lang_tree_node *) c_tree_chain_next
(&(*xlimit).generic));
(gdb) up
#2 0x024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112990
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112989
--- Comment #3 from Andrew Pinski ---
```
Breakpoint 1, ggc_free (p=0xf6bd4900) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/ggc-page.cc:1612
1612 if (in_gc)
(gdb) bt
#0 ggc_free (p=0xf6bd4900) at
/home/ubuntu/src/upstream-gcc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110199
--- Comment #3 from Andrew Macleod ---
(In reply to Andrew Pinski from comment #2)
> I Kinda see how to implement this by creating
> operator_min::fold_range/operator_max::fold_range but I am still new on
> using these interfaces so I am not 100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112965
--- Comment #2 from David Malcolm ---
In c-parser.cc's consider_macro:
1843pretty_printer pp;
1844pp_string (&pp, (const char *) tok.val.str.text);
1845pp_newline (&pp);
1846cpp_push_buffer (parse_in,
1847
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112989
--- Comment #4 from Andrew Pinski ---
```
simulate_builtin_function_decl (location=255050, name=0x48b5200
"svmla_za64_vg4x1", type=0xf6b1cb70, function_code=31409, library_name=0x0,
attrs=0xf6bced80) at
/home/ubuntu/src/upstream-gcc-aarc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112965
--- Comment #3 from David Malcolm ---
A workaround might be to pad pp's buffer with trailing zero bytes up to a
multiple of 16.
1 - 100 of 150 matches
Mail list logo
