https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
--- Comment #14 from CVS Commits ---
The releases/gcc-13 branch has been updated by Matthias Kretz
:
https://gcc.gnu.org/g:0f9f9c0f79a1a2a1cd6abd86b84dedbd0d263a42
commit r13-7372-g0f9f9c0f79a1a2a1cd6abd86b84dedbd0d263a42
Author: Matthias Kret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
--- Comment #15 from CVS Commits ---
The releases/gcc-13 branch has been updated by Matthias Kretz
:
https://gcc.gnu.org/g:a51ed14784df49eeceea1813b1d458516031bf52
commit r13-7373-ga51ed14784df49eeceea1813b1d458516031bf52
Author: Matthias Kret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
--- Comment #16 from CVS Commits ---
The releases/gcc-13 branch has been updated by Matthias Kretz
:
https://gcc.gnu.org/g:dad9abd7daa1d977e79af7ac76c17c91464aca08
commit r13-7375-gdad9abd7daa1d977e79af7ac76c17c91464aca08
Author: Matthias Kret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109949
--- Comment #11 from CVS Commits ---
The releases/gcc-13 branch has been updated by Matthias Kretz
:
https://gcc.gnu.org/g:0ed75609477ce9e83f8ebc32a7fa0f86380ad22f
commit r13-7374-g0ed75609477ce9e83f8ebc32a7fa0f86380ad22f
Author: Matthias Kret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030
--- Comment #19 from CVS Commits ---
The releases/gcc-11 branch has been updated by Matthias Kretz
:
https://gcc.gnu.org/g:2da5976cf683d84a1857bfa34c5c3d0d661fffbd
commit r11-10811-g2da5976cf683d84a1857bfa34c5c3d0d661fffbd
Author: Matthias Kre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030
--- Comment #21 from CVS Commits ---
The releases/gcc-11 branch has been updated by Matthias Kretz
:
https://gcc.gnu.org/g:0911926f37cf41313c26e1e9d89424d64af972c9
commit r11-10815-g0911926f37cf41313c26e1e9d89424d64af972c9
Author: Matthias Kre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030
--- Comment #20 from CVS Commits ---
The releases/gcc-11 branch has been updated by Matthias Kretz
:
https://gcc.gnu.org/g:a2a953d11e80ac4b351bbaa4a8fa4e6b76de317c
commit r11-10812-ga2a953d11e80ac4b351bbaa4a8fa4e6b76de317c
Author: Matthias Kre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108856
--- Comment #4 from CVS Commits ---
The releases/gcc-11 branch has been updated by Matthias Kretz
:
https://gcc.gnu.org/g:740824717405a30d9ee01c65aac8839926d2
commit r11-10814-g740824717405a30d9ee01c65aac8839926d2
Author: Matthias Kret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
--- Comment #18 from CVS Commits ---
The releases/gcc-11 branch has been updated by Matthias Kretz
:
https://gcc.gnu.org/g:ad27280442d7979cf9da03d59268919fecfd12f4
commit r11-10822-gad27280442d7979cf9da03d59268919fecfd12f4
Author: Matthias Kre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
--- Comment #17 from CVS Commits ---
The releases/gcc-11 branch has been updated by Matthias Kretz
:
https://gcc.gnu.org/g:f2299a4b2769941cd995e3a0530ff243153fcea2
commit r11-10821-gf2299a4b2769941cd995e3a0530ff243153fcea2
Author: Matthias Kre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109949
--- Comment #12 from CVS Commits ---
The releases/gcc-11 branch has been updated by Matthias Kretz
:
https://gcc.gnu.org/g:0860e7d46f7fa4e1bcd373feee3bc673d4260b8b
commit r11-10823-g0860e7d46f7fa4e1bcd373feee3bc673d4260b8b
Author: Matthias Kre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
--- Comment #19 from CVS Commits ---
The releases/gcc-11 branch has been updated by Matthias Kretz
:
https://gcc.gnu.org/g:7e289c12ce0da962ef258c992f7c52710198e3a6
commit r11-10824-g7e289c12ce0da962ef258c992f7c52710198e3a6
Author: Matthias Kre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109949
Matthias Kretz (Vir) changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109261
Matthias Kretz (Vir) changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108856
Matthias Kretz (Vir) changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030
Matthias Kretz (Vir) changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109962
Bug ID: 109962
Summary: gcc/gimple-range-cache.h:140:17: warning: private
field 'm_estimate' is not used
[-Wunused-private-field]
Product: gcc
Version: unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109963
Bug ID: 109963
Summary: ABI: unexpected layout ordering of `this` pointer in
lambda capture
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
--- Comment #19 from rguenther at suse dot de ---
On Wed, 24 May 2023, userm57 at yahoo dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
>
> --- Comment #18 from Stan Johnson ---
> $ git clone git://gcc.gnu.org/git/gcc.git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109950
Richard Biener changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109951
Richard Biener changed:
What|Removed |Added
Version|unknown |14.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
--- Comment #20 from Sam James ---
When I looked at it, I think I got it to apply to 13 with no hassle and it
seemed to work okay, but I didn't test it that hard.
It's a considerable win so even if not backported upstream, if you think it's
saf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954
Richard Biener changed:
What|Removed |Added
Keywords||documentation
--- Comment #9 from Rich
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
--- Comment #21 from rguenther at suse dot de ---
On Thu, 25 May 2023, sjames at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927
>
> --- Comment #20 from Sam James ---
> When I looked at it, I think I got it to ap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #11 from Richard Biener ---
(In reply to Alexander Monakov from comment #8)
> (In reply to jos...@codesourcery.com from comment #6)
> > For the standard, dynamically allocated case, you should only need to
> > allocate enough memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109957
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-05-25
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109958
--- Comment #2 from Richard Biener ---
so is that invalid code?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109959
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109960
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109950
--- Comment #4 from LIU Hao ---
Given the fact that GCC is already able to warn about out-of-range indexes for
an array, why wouldn't it be possible to infer that `*(data + next)` is always
an element of `data`?
If the result of `data + next` (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109947
--- Comment #6 from Jonathan Wakely ---
(In reply to Martin Seemann from comment #5)
> Thanks for the clarification! Now I am convinced that it is not a bug in
> libstdc++ (although I still doubt that the side-effects were intended when
> the co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109174
--- Comment #2 from CVS Commits ---
The master branch has been updated by Haochen Jiang :
https://gcc.gnu.org/g:4a84a2db2ad7cc57c1674849f845c42ed4ad12ab
commit r14-1234-g4a84a2db2ad7cc57c1674849f845c42ed4ad12ab
Author: Hu, Lin1
Date: Tue Ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109173
--- Comment #7 from CVS Commits ---
The master branch has been updated by Haochen Jiang :
https://gcc.gnu.org/g:4a84a2db2ad7cc57c1674849f845c42ed4ad12ab
commit r14-1234-g4a84a2db2ad7cc57c1674849f845c42ed4ad12ab
Author: Hu, Lin1
Date: Tue Ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109921
--- Comment #2 from Andreas Ziegler ---
Apart from a small typo
-+ if (rec.ec == errc{})
++ if (res.ec == errc{})
this fixes the build error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100711
--- Comment #10 from jbeulich at suse dot com ---
(In reply to Hongtao.liu from comment #9)
> We don't have single instruction for V8HI/V16QImode broadcast without AVX2,
> that's why the first splitter only have VI48_128.
Does this matter? The s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109963
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100711
--- Comment #11 from Hongtao.liu ---
(In reply to jbeulich from comment #10)
> (In reply to Hongtao.liu from comment #9)
> > We don't have single instruction for V8HI/V16QImode broadcast without AVX2,
> > that's why the first splitter only have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109173
--- Comment #8 from Hongtao.liu ---
Fixed for GCC14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109174
--- Comment #3 from Hongtao.liu ---
Fixed for GCC14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109922
--- Comment #4 from Jonathan Wakely ---
(In reply to Jiang An from comment #2)
> The requirements was removed by N0958
> (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/1996/N0958.pdf), and
> then setfill and its friends are only required t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109955
--- Comment #3 from Richard Biener ---
FAIL: gcc.dg/vect/pr109011-3.c -flto -ffat-lto-objects scan-tree-dump-times
optimized " = .POPCOUNT (vect" 3
show that when pattern recognition detects
t.c:5:21: note: vec_recog_ctz_ffs_pattern: de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188
--- Comment #7 from Georg-Johann Lay ---
On branch releases/gcc-5.4.0, the wrong code is since r226119, which is a
backport of r225918.
Doesn't look like this caused the current PR; maybe that change just unmasked a
bug in postreload that's eve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109922
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |14.0
--- Comment #5 from Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103960
Avi Kivity changed:
What|Removed |Added
CC||avi at scylladb dot com
--- Comment #4 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103960
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109958
--- Comment #3 from Ed Catmur ---
B::f is a static member function so yes, it's valid. A class member access
expression naming a static member function is an lvalue designating that
function, and it shouldn't make any difference that the functio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109964
Bug ID: 109964
Summary: auto-vectorization of shift ignores integral
promotions
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Keywords: wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103960
--- Comment #6 from Avi Kivity ---
Ah! thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109955
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:f97572c2aeddc71b01686993b978895e55890ab6
commit r14-1238-gf97572c2aeddc71b01686993b978895e55890ab6
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109955
--- Comment #5 from Richard Biener ---
The remaining FAILs are all because of define_insn_and_split no longer working
I think. I wonder if these combinations can be handled in generic code
somehow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109965
Bug ID: 109965
Summary: rename 'Modules' to 'Categories' in tree-view of
doxygen-generated libstdc++ documentation
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109964
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-05-25
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109964
Richard Biener changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109964
--- Comment #3 from Richard Biener ---
So the bug in the vectorizer is that it does
t.ii:14:5: note: can narrow to signed:16 without loss of precision: _31 = 1
>> _30;
t.ii:14:5: note: only the low 16 bits of _30 are significant
while that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791
--- Comment #14 from Richard Biener ---
So one issue with the unfolding of PHIs is that for example
gcc.dg/warn-sprintf-no-nul.c has
const char a2[][3] = {
"", "1", "12", "123", "123\000"
};
and for
# str_1 = PHI <&a2[2], &a2[3]>
we can d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791
Richard Biener changed:
What|Removed |Added
Attachment #55047|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791
Richard Biener changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109966
Bug ID: 109966
Summary: [13.1 Regression] ICE in implify_var_or_parm_decl, à
gimplify.cc:3058
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109966
Richard Biener changed:
What|Removed |Added
Known to work||12.3.0
Summary|[13.1 Regres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109800
--- Comment #1 from CVS Commits ---
The master branch has been updated by Alex Coplan :
https://gcc.gnu.org/g:f5298d9969b4fa34ff3aecd54b9630e22b2984a5
commit r14-1239-gf5298d9969b4fa34ff3aecd54b9630e22b2984a5
Author: Alex Coplan
Date: Thu M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109964
--- Comment #4 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #3)
> So the bug in the vectorizer is that it does
>
> t.ii:14:5: note: can narrow to signed:16 without loss of precision: _31 =
> 1 >> _30;
> t.ii:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105541
Patrick Palka changed:
What|Removed |Added
CC||egor.pugin at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103212
Patrick Palka changed:
What|Removed |Added
Status|NEW |RESOLVED
Keywords|needs-bisec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109965
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-05-25
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109801
Richard Biener changed:
What|Removed |Added
Resolution|--- |INVALID
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 109801, which changed state.
Bug 109801 Summary: -Wmaybe-uninitialized warning with -O1 on move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109801
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99195
--- Comment #17 from CVS Commits ---
The master branch has been updated by Kyrylo Tkachov :
https://gcc.gnu.org/g:560bb845321f5ad039a318a081b0e88d9900f5cb
commit r14-1241-g560bb845321f5ad039a318a081b0e88d9900f5cb
Author: Kyrylo Tkachov
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109967
Bug ID: 109967
Summary: Wrong code at -O2 on x86_64-linux-gnu
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109966
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
K
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109965
--- Comment #2 from Saifi Khan ---
Yes, you are right.
Doxygen has 'Modules' hard-coded everywhere in the code as they have used the
word as an organizing principle.
It starts with enum Kind defined in LayoutNavEntry
https://raw.githubuserco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109965
--- Comment #3 from Saifi Khan ---
Trying the 'custom' layout approach that you suggested.
The file modified is
/opt/gcc/src/libstdc++-v3/doc/doxygen/DoxygenLayout.xml
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791
--- Comment #16 from Andrew Pinski ---
(In reply to Richard Biener from comment #15)
> Created attachment 55155 [details]
> patch unfolding such PHIs
>
> Updated PHI unfolding patch. Tests fine besides mentioned diagnostic
> regressions.
I wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109965
--- Comment #4 from Jonathan Wakely ---
(In reply to Saifi Khan from comment #2)
> Short of re-compiling the doxygen code with string literal changed to
> "Components" i can't seem to find any other way.
Well if nothing else works, we can just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109947
Jonathan Wakely changed:
What|Removed |Added
Status|RESOLVED|SUSPENDED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811
AK changed:
What|Removed |Added
CC||hiraditya at msn dot com
--- Comment #4 from AK -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109968
Bug ID: 109968
Summary: False Warning stringop-overread when -O2 and
-fsanitize=address used
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109966
--- Comment #3 from Marek Polacek ---
// PR c++/109966
struct M;
template struct __array_traits {
typedef M _Type[_Nm];
};
template struct array {
typename __array_traits<_Nm>::_Type _M_elems;
};
struct basic_string_view {
basic_string_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109968
--- Comment #1 from Andrew Pinski ---
From
https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Instrumentation-Options.html#index-fsanitize_003daddress
:
Note that sanitizers tend to increase the rate of false positive warnings, most
notably those aro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811
--- Comment #5 from Andrew Pinski ---
(In reply to AK from comment #4)
> On AArch64 (typically mobile platforms) app developers typically would
> enable frame pointers by default because it helps with crash reporting.
s/AArch64 (typically mobil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811
--- Comment #6 from Jakub Jelinek ---
I think aarch64 defaults to -fno-omit-frame-pointer anyway.
/* Disable fomit-frame-pointer by default. */
{ OPT_LEVELS_ALL, OPT_fomit_frame_pointer, NULL, 0 },
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811
--- Comment #7 from Florian Weimer ---
(In reply to Jakub Jelinek from comment #6)
> I think aarch64 defaults to -fno-omit-frame-pointer anyway.
> /* Disable fomit-frame-pointer by default. */
> { OPT_LEVELS_ALL, OPT_fomit_frame_pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #12 from Martin Uecker ---
The C standard says "However, when a . (or -> ) operator has a left operand
that is (a pointer to) a structure with a flexible array member and the right
operand names that member, it behaves as if that me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109933
--- Comment #10 from Rory Bolt ---
Tested and verified on little endian too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109968
Andrew Pinski changed:
What|Removed |Added
Summary|False Warning |False Warning
|string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109968
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Reduced testcase without -fsanitize=address:
Sorry missed one undefined type.
Here is the corrected reduced testcase:
```
extern int write1 (int __fd, const voi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82931
--- Comment #5 from CVS Commits ---
The master branch has been updated by Georg-Johann Lay :
https://gcc.gnu.org/g:ff0a6900700636ac4c7f40b88490a20d19a68db3
commit r14-1244-gff0a6900700636ac4c7f40b88490a20d19a68db3
Author: Georg-Johann Lay
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104350
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103794
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811
--- Comment #8 from AK ---
Should we enable frame-pointers by default for RISCV64 as well?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811
--- Comment #9 from Jakub Jelinek ---
Why?
It should be enabled by default only if it is effectively mandated by the ABI
and/or doesn't affect performance at all (and is actually useful in functions
that don't need it like functions with alloca/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82931
--- Comment #6 from CVS Commits ---
The releases/gcc-13 branch has been updated by Georg-Johann Lay
:
https://gcc.gnu.org/g:a499ab08d18eff4ca9c079cafaee0708d2bcbf20
commit r13-7377-ga499ab08d18eff4ca9c079cafaee0708d2bcbf20
Author: Georg-Johann
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104327
--- Comment #11 from CVS Commits ---
The master branch has been updated by Georg-Johann Lay :
https://gcc.gnu.org/g:66cc0cb0f44f17049f61af6755043999c4fa5a24
commit r14-1245-g66cc0cb0f44f17049f61af6755043999c4fa5a24
Author: Georg-Johann Lay
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109969
Bug ID: 109969
Summary: Linking large project causes an ICE
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104327
--- Comment #12 from CVS Commits ---
The releases/gcc-13 branch has been updated by Georg-Johann Lay
:
https://gcc.gnu.org/g:6506590e70e57ed8d7fb68ab9443e31c31208fb0
commit r13-7378-g6506590e70e57ed8d7fb68ab9443e31c31208fb0
Author: Georg-Johan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82931
--- Comment #7 from CVS Commits ---
The releases/gcc-12 branch has been updated by Georg-Johann Lay
:
https://gcc.gnu.org/g:4d39f68b891ed2ac7aca5ef24119f50976b84c22
commit r12-9654-g4d39f68b891ed2ac7aca5ef24119f50976b84c22
Author: Georg-Johann
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104327
--- Comment #13 from CVS Commits ---
The releases/gcc-12 branch has been updated by Georg-Johann Lay
:
https://gcc.gnu.org/g:0537c71aa7ef88c4ffe754cf7af81e346273b079
commit r12-9655-g0537c71aa7ef88c4ffe754cf7af81e346273b079
Author: Georg-Johan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109969
Gaius Mulley changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #39 from Alexander Klepikov
---
> The tst insn is mainly formed by the combine pass, which relies on certain
> insn patterns and combinations thereof. See also sh.md, around line 530.
I'm sorry, but .md lang is too complicated for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82931
Georg-Johann Lay changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
1 - 100 of 169 matches
Mail list logo
