https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113455
--- Comment #6 from Joseph S. Myers ---
-frounding-math is only relevant for arithmetic that occurs as-if at runtime in
the abstract machine. Conversion of constants to their type (or a type with
excess range and precision as indicated by DEC_EV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113792
--- Comment #2 from dave.anglin at bell dot net ---
On 2024-02-07 2:43 a.m., redi at gcc dot gnu.org wrote:
> Using #include definitely won't work, that would just create a cycle between
> the libstdc++ versions of stdlib.h and cstdlib, at least
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113817
Bug ID: 113817
Summary: ice in move_early_exit_stmts
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113817
Sam James changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113731
Sam James changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment #13 f
-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-8869-20240207154951-g8636c538b68-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240207 (experimental) (GCC)
extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240207 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113818
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-02-07
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113819
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113415
--- Comment #5 from Andrew Pinski ---
*** Bug 113819 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113792
--- Comment #3 from Jonathan Wakely ---
(In reply to John David Anglin from comment #0)
> stdlib.h is fixed on this target. The #include_next pulled stdlib.h
> from /usr/include instead of ./prev-gcc/include-fixed/stdlib.h.
Why did that happen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113792
--- Comment #4 from Jonathan Wakely ---
And we have the same pattern in include/c_global/cmath and
include/bits/std_abs.h so I'm also very reluctant to change just one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113792
--- Comment #5 from Jonathan Wakely ---
https://gcc.gnu.org/pipermail/gcc-patches/2016-January/439448.html described
the reason for the current approach.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
--- Comment #9 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #5)
> Created attachment 56905 [details]
> testcase which shows libc++ and libstdc++ difference
>
> with libstdc++, both GCC and clang reject this.
> with libc++, c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
--- Comment #10 from Peter Kasting ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Andrew Pinski from comment #5)
> > Created attachment 56905 [details]
> > testcase which shows libc++ and libstdc++ difference
> >
> > with libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
--- Comment #11 from Jonathan Wakely ---
(In reply to Peter Kasting from comment #8)
> There's currently no simple and blessed route for consumers to convert
> raw-or-fancy-pointer input types to raw pointers.
I disagree, std::to_address does e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113793
--- Comment #2 from anlauf at gcc dot gnu.org ---
Created attachment 57354
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57354&action=edit
Tentative partial patch
This appears to fix the malloc size for character arrays, but not for
alloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
--- Comment #12 from Jonathan Wakely ---
(In reply to Peter Kasting from comment #10)
> When Jose reported this issue in Chromium I pushed back on fixing on our
> side because I thought libstdc++ had the same issue. But this is a distinct
> issu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205
--- Comment #6 from Sérgio Basto ---
and any workaround to build mlt on x86_64 ,exist ?
I tried disable lto, hardening and also disable strict symbols (-Wl,-z,defs )
and still not build neither in koji nor in my machine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113799
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #2)
> Reproduced with all versions I have here (14.0, 13.2, 12.3, 11.4 and 10.5).
... but passes with -fno-range-check ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113820
Bug ID: 113820
Summary: [14 Regression] libdruntime fails to build on
arm-linux-gnueabi (armv5t)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113776
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205
--- Comment #7 from Jakub Jelinek ---
-fno-tree-slp-vectorize, either on the command line for the affected
compilation unit or __attribute__((optimize ("no-tree-slp-vectorize"))) on the
problematic routine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205
--- Comment #7 from Jakub Jelinek ---
-fno-tree-slp-vectorize, either on the command line for the affected
compilation unit or __attribute__((optimize ("no-tree-slp-vectorize"))) on the
problematic routine.
--- Comment #8 from Andrew Pinski --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113820
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
Andrew Pinski changed:
What|Removed |Added
CC||doko at gcc dot gnu.org
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111462
seurer at gcc dot gnu.org changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113085
--- Comment #5 from seurer at gcc dot gnu.org ---
I should note that pinned-2 also fails on powerpc64 LE.
make -k check-target-libgomp RUNTESTFLAGS="c.exp=libgomp.c/alloc-pinned-*"
FAIL: libgomp.c/alloc-pinned-1.c execution test
FAIL: libgomp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074
--- Comment #13 from Jonathan Wakely ---
It looks like libc++ did it for this reason:
[libc++] Fix a hard error in `contiguous_iterator`.
Evaluating `contiguous_iterator` on an iterator that satisfies all the
constraints except the `to_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113799
--- Comment #4 from anlauf at gcc dot gnu.org ---
It's the simplification of minval:
program p
implicit none
real, parameter :: inf = real(z'7F80')
real, parameter :: someInf(*) = [inf, 0.]
print *, minval(-someInf)
end
pr113799.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113799
--- Comment #5 from anlauf at gcc dot gnu.org ---
Even worse: it's the unary minus:
print *, -someInf
pr113799.f90:5:19:
5 | print *, -someInf
| 1
Error: Arithmetic overflow at (1)
free(): invalid pointer
f951:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #14 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113821
Bug ID: 113821
Summary: Missed optimization for final classes: expensive check
for result of dynamic cast
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113821
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Severity|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113821
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164
Andrew Pinski changed:
What|Removed |Added
CC||janschultke at googlemail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113764
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #37 from Hongtao Liu ---
(In reply to Richard Biener from comment #36)
> For example with AVX512VL and the following, using -O -fgimple -mavx512vl
> we get simply
>
> notl%esi
> orl %esi, %edi
> cmpb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111059
--- Comment #8 from GCC Commits ---
The master branch has been updated by Joseph Myers :
https://gcc.gnu.org/g:bfd72bb44eca83b0db2b0bab895f27a8a44247a2
commit r14-8874-gbfd72bb44eca83b0db2b0bab895f27a8a44247a2
Author: Joseph Myers
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111911
--- Comment #9 from GCC Commits ---
The master branch has been updated by Joseph Myers :
https://gcc.gnu.org/g:bfd72bb44eca83b0db2b0bab895f27a8a44247a2
commit r14-8874-gbfd72bb44eca83b0db2b0bab895f27a8a44247a2
Author: Joseph Myers
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113776
--- Comment #4 from GCC Commits ---
The master branch has been updated by Joseph Myers :
https://gcc.gnu.org/g:bfd72bb44eca83b0db2b0bab895f27a8a44247a2
commit r14-8874-gbfd72bb44eca83b0db2b0bab895f27a8a44247a2
Author: Joseph Myers
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113776
Joseph S. Myers changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #38 from Hongtao Liu ---
> I think we should also mask off the upper bits of variable mask?
>
> notl%esi
> orl %esi, %edi
> notl%edi
> andl$15, %edi
> je .L3
with -mbmi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113772
--- Comment #14 from Matthias Klose ---
the proposed patch also fixes the arm-linux-gnueabi build (armv5t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113715
--- Comment #3 from Huaqi ---
(In reply to Andrew Pinski from comment #2)
> Yes this is where shrink wrapping incorrects incorrectly with
> riscv_zcmp_can_use_popretz optimization. Basically popretz should be
> disabled for shrink wrapped functi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113822
Bug ID: 113822
Summary: aarch64_evpc_reencode could/should use
new_shrunk_vector instead of manually doing it
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Ke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #39 from Hongtao Liu ---
> > the question is whether that matches the semantics of GIMPLE (the padding
> > is inverted, too), whether it invokes undefined behavior (don't do it - it
> > seems for people using intrinsics that's what i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113808
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113776
--- Comment #6 from Sam James ---
Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113797
--- Comment #1 from Andrew Pinski ---
static integer(kind=8) slen.1;
inside
void check (integer(kind=4) & restrict i)
pstr.2 = 0B;
slen.1 = 0;
concat_f (&pstr.2, &slen.1, &"0123456 "[1]{lb: 1 sz: 1}, D.4331, 8);
That is it used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113797
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113797
--- Comment #3 from martin ---
Thanks for the patch, it does the job. But if I compile with
"gfortran-14 -fopenmp -Wuninitialized"
then I obtain
20 | out = concat_f('0123456 ', some()) // ' abc'
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113797
--- Comment #4 from Andrew Pinski ---
(In reply to martin from comment #3)
> typedef character(kind=1) struct
> character(kind=1)[1:slen.1][1:slen.1];
> pstr.2 = 0B;
> slen.1 = 0;
Maybe the order here. slen.1 should be set to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113766
--- Comment #3 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:9ec08782b45869b33fec2a8772c25118221208e3
commit r14-8875-g9ec08782b45869b33fec2a8772c25118221208e3
Author: Pan Li
Date: Wed Feb 7 16:34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #40 from Jakub Jelinek ---
For unsigned _BitInt(4) or unsigned _BitInt(2) we mask it whenever loading from
memory or function argument or whatever other ABI specific spot (and also when
storing because that is how RTL expects it; bec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583
--- Comment #15 from JuzheZhong ---
(In reply to rguent...@suse.de from comment #14)
> On Wed, 7 Feb 2024, juzhe.zhong at rivai dot ai wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583
> >
> > --- Comment #13 from JuzheZhong --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583
--- Comment #16 from JuzheZhong ---
The FMA is generated in widening_mul PASS:
Before widening_mul (fab1):
_5 = 3.33314829616256247390992939472198486328125e-1 - _4;
_6 = _5 * 1.22998223643160599749535322189331054687
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583
--- Comment #14 from rguenther at suse dot de ---
On Wed, 7 Feb 2024, juzhe.zhong at rivai dot ai wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583
>
> --- Comment #13 from JuzheZhong ---
> Ok. I found the optimized tree:
>
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #7 from Richard Biener ---
(In reply to Tamar Christina from comment #6)
> The reason for the miscompile popping up is this change from the previous
> patch
>
> diff --git a/gcc/tree-vect-data-refs.cc b/gcc/tree-vect-data-refs.cc
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113753
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:d755a82079d61783eb0a573b0c74024d29359e4c
commit r14-8835-gd755a82079d61783eb0a573b0c74024d29359e4c
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
Richard Biener changed:
What|Removed |Added
Target||aarch64
--- Comment #10 from Richard B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #11 from Richard Biener ---
Btw, there's related IPA modref wrong-code issues where IPA and late summaries
are merged incorrectly (also receiving no attention)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113790
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113796
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=113753
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113731
--- Comment #8 from Matthias Klose ---
the proposed patch doesn't fix the amdgcn-amdhsa bootstrap.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113731
--- Comment #9 from Tamar Christina ---
(In reply to Matthias Klose from comment #8)
> the proposed patch doesn't fix the amdgcn-amdhsa bootstrap.
So what is the error with the patch? The output can't be the same as the
function was removed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #8 from Richard Biener ---
(In reply to Tamar Christina from comment #6)
> The reason for the miscompile popping up is this change from the previous
> patch
>
> diff --git a/gcc/tree-vect-data-refs.cc b/gcc/tree-vect-data-refs.cc
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #9 from Richard Biener ---
Another bug in the dependence checking code is
if (dr_may_alias_p (dr_ref, dr_read, loop_nest))
which will end up using TBAA - dr_may_alias_p doesn't think you are ever
going to move store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113748
--- Comment #2 from Jason Liam ---
(In reply to Andrew Pinski from comment #1)
> >This should be valid because `friend class C;` befriend a global class named
> >`C`.
>
>
> Hmm, see PR 21498 ...
This is ill-formed as explained
here:https://s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #10 from Tamar Christina ---
(In reply to Richard Biener from comment #9)
> Another bug in the dependence checking code is
>
> if (dr_may_alias_p (dr_ref, dr_read, loop_nest))
>
> which will end up using TBAA - dr_m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21498
Jason Liam changed:
What|Removed |Added
CC||jlame646 at gmail dot com
--- Comment #16 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113760
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113797
Bug ID: 113797
Summary: Deferred length character concatenation in openmp
region has wrong length
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113798
Bug ID: 113798
Summary: [C++26] P2662R3 - Pack indexing
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113788
--- Comment #7 from Jonathan Wakely ---
"broken with structured binding" doesn't seem accurate. It works fine, there
were just some ill-formed cases that should have given errors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113799
Bug ID: 113799
Summary: gfc_replace_expr: double free detected ?
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113800
Bug ID: 113800
Summary: [C++26] P2308R1 - Template parameter initialization
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113756
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:29998cc8a21b3a52f706275923166cd1f95d0555
commit r14-8837-g29998cc8a21b3a52f706275923166cd1f95d0555
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113756
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113731
--- Comment #10 from Tobias Burnus ---
(In reply to Tamar Christina from comment #9)
> (In reply to Matthias Klose from comment #8)
> > the proposed patch doesn't fix the amdgcn-amdhsa bootstrap.
>
> So what is the error with the patch? The out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |4.8.0
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87744
--- Comment #12 from Lewis Fox ---
(In reply to Jonathan Wakely from comment #2)
My original comment about libc++ was in reference to the LLVM bugzilla report
#27839: https://bugs.llvm.org/show_bug.cgi?id=27839
It looks like the issue you disco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113801
Bug ID: 113801
Summary: Missed optimization of loop invariant elimination
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583
--- Comment #17 from rguenther at suse dot de ---
On Wed, 7 Feb 2024, juzhe.zhong at rivai dot ai wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583
>
> --- Comment #16 from JuzheZhong ---
> The FMA is generated in widening_mul PASS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111478
--- Comment #8 from Saurabh Jha ---
Hi Richard,
Are you also planning to backport it to gcc-12?
Regards,
Saurabh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113802
Bug ID: 113802
Summary: gcc rejects auto f(this auto self...) { }
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87744
--- Comment #13 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #11)
> Though, if it is common enough, one could try to optimize the __ll[0] == 0
> && __xx[0] == 0 case, one can do then either 32x32->64 or 64x64->64
> multiplicat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
--- Comment #28 from GCC Commits ---
The releases/gcc-13 branch has been updated by Alex Coplan
:
https://gcc.gnu.org/g:2bd8264a131ee1215d3bc6181722f9d30f5569c3
commit r13-8293-g2bd8264a131ee1215d3bc6181722f9d30f5569c3
Author: Alex Coplan
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
Alex Coplan changed:
What|Removed |Added
Summary|[12/13 Regression] |[12 Regression] darktable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111478
--- Comment #9 from Richard Biener ---
(In reply to Saurabh Jha from comment #8)
> Hi Richard,
>
> Are you also planning to backport it to gcc-12?
Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113803
Bug ID: 113803
Summary: libgcc unwinder stops at calls to null function
pointer on some targets
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87744
--- Comment #14 from Jonathan Wakely ---
(In reply to Lewis Fox from comment #12)
> (In reply to Jonathan Wakely from comment #2)
>
> My original comment about libc++ was in reference to the LLVM bugzilla
> report #27839: https://bugs.llvm.org/s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113801
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #32 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:194d0956ef5992d4e453bde3eb5772dc077f610c
commit r14-8838-g194d0956ef5992d4e453bde3eb5772dc077f610c
Author: Tamar Christina
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113731
--- Comment #11 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:8f6ed71d8fff3c3c6249651a72aee084e31ffb9e
commit r14-8839-g8f6ed71d8fff3c3c6249651a72aee084e31ffb9e
Author: Tamar Christina
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113750
--- Comment #7 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:5c3ba60024fedc6b3d374ebb071bcf5b3e27cd62
commit r14-8840-g5c3ba60024fedc6b3d374ebb071bcf5b3e27cd62
Author: Tamar Christina
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113731
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113750
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113799
Mikael Morin changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
1 - 100 of 169 matches
Mail list logo
