https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109341
Bug ID: 109341
Summary: [13 Regression] ICE in merge, at
ipa-modref-tree.cc:176
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109342
Bug ID: 109342
Summary: [13 Regression] Wrong code with -O2
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109343
Bug ID: 109343
Summary: invalid if conversion optimization for aarch64
Product: gcc
Version: rust/master
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109303
--- Comment #6 from Jakub Jelinek ---
Ok. It is yours then, for testcase perhaps:
--- gcc/testsuite/gcc.dg/pr109303.c.jj 2023-03-29 18:42:31.068144102 +0200
+++ gcc/testsuite/gcc.dg/pr109303.c 2023-03-29 18:42:18.328330526 +0200
@@ -0,0 +1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109341
Richard Biener changed:
What|Removed |Added
Known to work||11.3.1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109342
Richard Biener changed:
What|Removed |Added
Keywords||needs-bisection
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109303
--- Comment #7 from Jakub Jelinek ---
BTW, I think I got that offset >= (HOST_WIDE_INT) UINT_MAX * BITS_PER_UNIT
wrong last time, if offset is equal to that, it is still representable (as
UINT_MAX).
So perhaps either offset > (HOST_WIDE_INT) UIN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109343
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109278
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:ee6ae8cb4793041590b479346433ed786a86985d
commit r13-6941-gee6ae8cb4793041590b479346433ed786a86985d
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109278
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109339
Richard Biener changed:
What|Removed |Added
Component|tree-optimization |libstdc++
--- Comment #2 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109342
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Keyw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109341
Martin Liška changed:
What|Removed |Added
Keywords|needs-bisection |
Summary|[12/13 Regression] I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109339
--- Comment #3 from Richard Biener ---
Other than that in principle maybe_warn_pass_by_reference could be enhanced
by realizing a (sub-)object is passed both as const reference and
non-const reference as in this case, but it would be still an od
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109339
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109342
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109344
Bug ID: 109344
Summary: feraiseexcept produces incorrect code when
optimizations are enabled
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107409
Martin Liška changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 107409, which changed state.
Bug 107409 Summary: Perf loss ~5% on 519.lbm_r SPEC cpu2017 benchmark with
r10-5090-ga9a4edf0e71bba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107409
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109328
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109328
--- Comment #5 from Marc Poulhiès ---
Thanks for the very quick fix (I'm the one who hit this issue)!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109242
--- Comment #6 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:82e8d1685a1e5fac4880e987ed9684248378bce2
commit r12-9369-g82e8d1685a1e5fac4880e987ed9684248378bce2
Author: Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109242
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108999
Lehua Ding changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Hi,
I found a bug in the result of std::vsnprintf(), here is the test app that can
reproduce it.
I tested with g++ 11.2 and 12.2 and both have the bug, and this issue does not
happen with visual c++.
#include
#include
#include
#include
int Sprintf(std::string& s, const char* pszFormat, ..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107087
--- Comment #7 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #4)
> Comment 0 comes from 22_locale/money_put/cons/3.cc
>
> make check RUNTESTFLAGS="conformance.exp=22_locale/money_put/cons/3.cc
> --target_board=unix/-m32"
>
On Thu, Mar 30, 2023 at 08:29:45AM +, Qiang Ren via Gcc-bugs wrote:
> I found a bug in the result of std::vsnprintf(), here is the test app that
> can reproduce it.
> I tested with g++ 11.2 and 12.2 and both have the bug, and this issue does
> not happen with visual c++.
gcc-bugs is not the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107943
--- Comment #7 from Richard Biener ---
Samples: 193K of event 'cycles', Event count (approx.): 206254655627
Overhead Samples Command Shared Object Symbol
12.11% 23476 cc1 cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109344
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109341
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103559
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #8 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103559
--- Comment #9 from Jakub Jelinek ---
isless (NAN, 0.0) should be false, no, so NAN shouldn't errno = EDOM for glibc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103559
--- Comment #10 from Xi Ruoyao ---
(In reply to Jakub Jelinek from comment #9)
> isless (NAN, 0.0) should be false, no, so NAN shouldn't errno = EDOM for
> glibc.
Oh, I misunderstood your question.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2023-03-30
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107943
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2022-12-01 00:00:00 |2023-3-30
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109342
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:1d0ba4467dd9cad11eb9ff547442e3ce6292b892
commit r13-6942-g1d0ba4467dd9cad11eb9ff547442e3ce6292b892
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109342
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103035
Bug 103035 depends on bug 109342, which changed state.
Bug 109342 Summary: [13 Regression] Wrong code with -O2 since
r13-5348-gc29d85359add80
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109342
What|Removed |A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109344
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109341
Jan Hubicka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #25 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:04b0a7b1a6d9e0f3782888f1ebf187c26690038b
commit r13-6943-g04b0a7b1a6d9e0f3782888f1ebf187c26690038b
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 107561, which changed state.
Bug 107561 Summary: [13 Regression] g++.dg/pr71488.C and
[g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow
problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1075
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109344
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108887
--- Comment #9 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:a23b33a1bdeff7bc2289d9ebb7cb7b7ec0a605f5
commit r13-6944-ga23b33a1bdeff7bc2289d9ebb7cb7b7ec0a605f5
Author: Jason Merrill
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107897
--- Comment #7 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:a23b33a1bdeff7bc2289d9ebb7cb7b7ec0a605f5
commit r13-6944-ga23b33a1bdeff7bc2289d9ebb7cb7b7ec0a605f5
Author: Jason Merrill
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834
--- Comment #5 from Jonathan Wakely ---
c++tools/Makefile.in has:
mostlyclean::
rm -f $(MAPPER.O)
clean::
rm -f g++-mapper-server$(exeext)
distclean::
rm -f config.log config.status config.h
Should distclean have cle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834
--- Comment #6 from Jonathan Wakely ---
Also, after 'make clean' you can no longer do 'make all'
c++tools$ make clean all
# --enable-maintainer-mode to rebuild
/home/jwakely/src/gcc/gcc/c++tools/configure, or make MAINTAINER=touch
# --enable-ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103559
--- Comment #11 from Jakub Jelinek ---
Actually, I was just misreading the tree dumps, we use hw insn for x u>= 0.0,
which
is UNGE_EXPR, so it is true if x is NAN or GE_EXPR, or as described in the
tree-call-cdce.cc comment:
y = sqrt (x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834
--- Comment #7 from Segher Boessenkool ---
Thank you for looking at this!
(In reply to Jonathan Wakely from comment #5)
> c++tools/Makefile.in has:
>
> mostlyclean::
> rm -f $(MAPPER.O)
>
> clean::
> rm -f g++-mapper-server$(exeex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834
--- Comment #8 from Segher Boessenkool ---
(In reply to Jonathan Wakely from comment #6)
> Also, after 'make clean' you can no longer do 'make all'
Of course you cannot. Where do you see this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834
--- Comment #9 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #8)
> (In reply to Jonathan Wakely from comment #6)
> > Also, after 'make clean' you can no longer do 'make all'
>
> Of course you cannot. Where do you see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91645
--- Comment #11 from Jakub Jelinek ---
(In reply to Aldy Hernandez from comment #9)
> It looks like what we want for this test is actually !isgreaterequal() not
> isless(), since we want to exclude the possibility of a NAN. Like this:
>
> float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834
--- Comment #10 from Jonathan Wakely ---
This seems like an improvement ...
--- a/c++tools/Makefile.in
+++ b/c++tools/Makefile.in
@@ -22,6 +22,7 @@ libexecdir := @libexecdir@
target_noncanonical := @target_noncanonical@
gcc_version := $(shel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834
--- Comment #11 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #10)
> @@ -22,6 +22,7 @@ libexecdir := @libexecdir@
> target_noncanonical := @target_noncanonical@
> gcc_version := $(shell @get_gcc_base_ver@ $(srcdir)/../gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109104
Martin Liška changed:
What|Removed |Added
Keywords|needs-bisection |
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108887
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107897
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834
--- Comment #12 from Jonathan Wakely ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614893.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109344
--- Comment #4 from albin ---
Thanks for the info. If it was fixed three years ago how come it is still seen
when using gcc (trunk) on Compiler Explorer? Is Compiler Explorer using an
obsolete glibc?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109344
--- Comment #5 from Xi Ruoyao ---
(In reply to albin from comment #4)
> Thanks for the info. If it was fixed three years ago how come it is still
> seen when using gcc (trunk) on Compiler Explorer? Is Compiler Explorer using
> an obsolete glibc?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109345
Bug ID: 109345
Summary: class(*) variable that is a string array is not
handled correctly
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109343
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81958
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #8 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91645
--- Comment #12 from Jakub Jelinek ---
WIP which still doesn't work:
--- gcc/value-query.cc.jj 2023-03-23 15:25:47.069740988 +0100
+++ gcc/value-query.cc 2023-03-30 14:56:58.809298424 +0200
@@ -230,9 +230,11 @@ range_query::get_tree_range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563
Richard Biener changed:
What|Removed |Added
CC||amacleod at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91645
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
--- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #25 from Jakub Jelinek ---
> Anyway, as I said for the second version, it would be nice to also try
> subvariants:
> // relayout_decl (DECL_RESULT (new_fndecl));
> for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109104
Kito Cheng changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
--- Comment #29 from Jakub Jelinek ---
So aggregate_value_p has some side-effects other than return value then? Ugh.
Anyway, my patch intention has been to avoid the relayouts.
So, just calling aggregate_value_p there or perhaps instead later w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105221
--- Comment #6 from Jason Merrill ---
Reduced:
void (*p)(int) = [](auto) noexcept {};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105221
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109128
--- Comment #3 from Tobias Burnus ---
My initial thought was to handle it via lto1. This works well if all relevant
files are compiled with "-flto" as then the callers of the offload functions,
the offload functions themselves are available, per
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
--- Comment #21 from Jan Hubicka ---
Zen 1-3 changes were intentional in the original tuning patch (it is also
briefly mentioned in the commit message). By allowing 256 bit AVX moves
instead of 64bit integer moves (or 128bit) we can move bigger
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
--- Comment #22 from Jakub Jelinek ---
Sure. The point was to avoid regressions on the release branch because of so
big changes for the tunings which were supported before already.
So we might want both the LRA changes and perhaps zen1-3 revers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105644
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
--- Comment #30 from Jakub Jelinek ---
So, if I add the
--- a/gcc/tree-inline.cc
+++ b/gcc/tree-inline.cc
@@ -2787,6 +2787,7 @@ initialize_cfun (tree new_fndecl, tree callee_fndecl,
profile_count count)
/* Get clean struct function. */
pu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109327
Andrew Pinski changed:
What|Removed |Added
Summary|ICE on valid code at -O1|[13 Regression] ICE on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109303
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96464
Patrick Palka changed:
What|Removed |Added
See Also|https://gcc.gnu.org/bugzill |
|a/show_bug.cgi?id=10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109338
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
See Also|https://gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109337
Patrick Palka changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102419
Patrick Palka changed:
What|Removed |Added
CC||cjdb.ns at gmail dot com
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970
--- Comment #15 from Martin Uecker ---
Thanks.
I still wonder whether the original example should be added to the test suite?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109323
--- Comment #2 from Enrico Maria De Angelis ---
Created attachment 54790
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54790&action=edit
Attachment for report 109323
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109346
Bug ID: 109346
Summary: RFE add DW_AT_location to DW_TAG_subprogram
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84075
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |10.5
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109323
--- Comment #3 from Enrico Maria De Angelis ---
However, I'm not entirely sure (not anymore now that I've read the standard
more carefully) that not having any of those two memebrs is an error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
--- Comment #31 from Jakub Jelinek ---
If the important side-effect is allocation of some GC memory, then perhaps
(assuming you also see just 5 initialize_cfun calls with 2xint, TFmode float,
uint and bool) testing hack might be:
--- a/gcc/tree-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #41 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:429a7a88438cc80e7c58d9f63d44838089899b12
commit r13-6945-g429a7a88438cc80e7c58d9f63d44838089899b12
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109068
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109279
--- Comment #14 from Vineet Gupta ---
(In reply to Andrew Pinski from comment #12)
> Here is something to look into:
> #define const1 0x0101010101010101ULL
> #define const0 const1
> unsigned long long f(unsigned long long occ, const unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109347
Bug ID: 109347
Summary: [lra] Spill failure for architecture without CC
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109348
Bug ID: 109348
Summary: Pointer initialization fails for target with
references
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109347
--- Comment #1 from Piggy NL ---
Created attachment 54792
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54792&action=edit
Reproduce for mips64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322
--- Comment #9 from Steve Kargl ---
On Wed, Mar 29, 2023 at 07:42:08PM +, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322
>
> --- Comment #3 from Steve Kargl ---
> On Wed, Mar 29, 2023 a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84779
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC|anlauf at gmx dot de |anlauf at gcc dot
gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109128
--- Comment #4 from Tobias Burnus ---
Minor observations (unrelated to this bug but should be fixed. separately or
together):
- '@' file in lto-wrapper.cc's compile_offload_image's fork_execute call is
always the same. (Matters if there is more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109348
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
1 - 100 of 136 matches
Mail list logo
