https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994
--- Comment #18 from Jakub Jelinek ---
It is a fundamental assumption that the FDE/CIE chain is zero terminated, after
all, all the registration APIs (__register_frame_table,
__register_frame_info_table, __register_frame_info_table_bases) take j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109093
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-reduction |
--- Comment #11 from Jakub Jelinek --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109109
--- Comment #10 from Martin Liška ---
Btw. the backtrace leading to the problematic function:
trxundo.ii:0(trx_undo_free_page(trx_rseg_t*, bool, unsigned int, unsigned int,
mtr_t*, dberr_t*) [clone .constprop.0] [clone .isra.0])[0x5691bf33]
??:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109109
--- Comment #11 from Martin Liška ---
(In reply to Jakub Jelinek from comment #9)
> Weird, at least on the current trunk when reverting all 4 i386.md hunks vs.
> all but the 3_3 one I see differences in both
> _Z22trx_undo_get_first_recRK11fil_s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109031
Roger Sayle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109087
--- Comment #13 from Richard Biener ---
(In reply to Jakub Jelinek from comment #12)
> As for the .DEFERRED_INIT not being DSEd when it isn't used, cvise reduced
> testcase is e.g.
>
> int a;
> int foo (void);
> int bar (void);
>
> void
> baz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109113
Richard Biener changed:
What|Removed |Added
Keywords||accepts-invalid
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106896
--- Comment #12 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:5159a1f1e91e03d4b82808a0062697318232543f
commit r13-6652-g5159a1f1e91e03d4b82808a0062697318232543f
Author: Jan Hubicka
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109087
--- Comment #14 from Jakub Jelinek ---
I didn't mean for GCC 13, we need to fix the actual backend bug regardless and
so a DSE improvement can't be considered a fix... ;)
Just the DSE thing happens very often with -ftrivial-auto-var-init=.
I won
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106896
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109115
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:72b52751c60abb327c73716259485d04b8eabe4f
commit r13-6653-g72b52751c60abb327c73716259485d04b8eabe4f
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109115
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109119
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-03-14
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107762
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109121
Bug ID: 109121
Summary: m68k/coldfire: multilib: arithmetic functions missing
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109087
--- Comment #15 from rguenther at suse dot de ---
On Tue, 14 Mar 2023, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109087
>
> --- Comment #14 from Jakub Jelinek ---
> I didn't mean for GCC 13, we need to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109109
--- Comment #12 from Martin Liška ---
So the problem happens here:
static
uint32_t
trx_undo_free_page(
trx_rseg_t* rseg,
bool in_history,
uint32_t hdr_page_no,
uint32_t page_no,
mtr_t* mtr,
dberr_t* err)
{
do { if (__builtin_expect(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109104
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108429
--- Comment #8 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jan Hubicka
:
https://gcc.gnu.org/g:27e02e9fc388d7dc86ec10bedc6b8f13ec94725a
commit r12-9251-g27e02e9fc388d7dc86ec10bedc6b8f13ec94725a
Author: Jan Hubicka
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109104
--- Comment #2 from JuzheZhong ---
(In reply to Roger Sayle from comment #1)
> Not exactly my area of expertise, but adding
>
> if (!can_create_pseudo_p ())
> return false;
>
> at the start of legitimize_move on line 262 of riscv-v.cc sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109109
--- Comment #13 from Jakub Jelinek ---
(In reply to Martin Liška from comment #12)
> So the problem happens here:
>
> static
> uint32_t
> trx_undo_free_page(
>
> trx_rseg_t* rseg,
> bool in_history,
>
> uint32_t hdr_page_no,
> uint32_t pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109121
--- Comment #1 from Andreas Schwab ---
That looks more a bug in the software you are building. It appears to be using
a custom link command that fails to link against libgcc. The errors about the
incompatible architecture are due to invalid mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109121
--- Comment #2 from Angelo Dureghello ---
Hi Andreas,
thanks a lot.
Will recheck all the flags.-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109122
Bug ID: 109122
Summary: std::ranges::find segfaults with gcc (trunk but not
12.2) on godbolt
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109117
--- Comment #4 from lin1.hu at intel dot com ---
(In reply to lin1.hu from comment #2)
> Created attachment 54659 [details]
> 0001-i386-Add-missing-OPTION_MASK_ISA_AVX512VL-in-i386-bu.patch
Regtested on x86_64-pc-linux-gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
Thomas Schwinge changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Summary|[GCN offloadin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109011
--- Comment #18 from Hongtao.liu ---
(In reply to Jakub Jelinek from comment #16)
> Created attachment 54590 [details]
> gcc13-pr109011-2.patch
>
> Here is what I have right now, totally untested and will need further work
> so that the two pat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
--- Comment #2 from Thomas Schwinge ---
With my recent commit r13-6590-gf8332e52a498df480f72303de32ad0751ad899fe "Use
'GOMP_MAP_VARS_TARGET' for OpenACC compute constructs [PR90596]", the frequency
of those FAILs has increased to (almost) always
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93030
Thomas Schwinge changed:
What|Removed |Added
Last reconfirmed|2021-07-27 00:00:00 |2023-3-14
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107762
--- Comment #3 from Eric Botcazou ---
Indeed this pessimizes on s390 because it has insv instructions. It's too late
to properly sort this out so I'm going to revert the change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109123
Bug ID: 109123
Summary: Bogus warning: pointer used after 'realloc'
-Wuse-after-free
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109124
Bug ID: 109124
Summary: 'libgomp.oacc-c-c++-common/data-2-lib.c',
'libgomp.oacc-c-c++-common/data-2.c' GCN offloading
execution test FAILs
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109123
Manuel López-Ibáñez changed:
What|Removed |Added
Summary|Bogus warning: pointer used |Bogus warning: pointer used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109123
--- Comment #2 from Manuel López-Ibáñez ---
This is probably the same underlying issue as PR 106119 and PR 104215, but
unlike those, this testcase is heavily reduced without any header files (and it
could be reduced further I believe).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85270
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
--- Comment #24 from CVS Commits ---
The master branch has been updated by Andre Simoes Dias Vieira
:
https://gcc.gnu.org/g:b109964ddb421cf481828a2f3465751a2bd6a8f6
commit r13-6654-gb109964ddb421cf481828a2f3465751a2bd6a8f6
Author: Andre Vieira
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109123
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109123
--- Comment #4 from Manuel López-Ibáñez ---
This case is a bit different from other Wuse-after-free false positives:
* there is no path through which the warning is true
* the warning says "is used" not "may be used"
* there is no easy workarou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109123
--- Comment #5 from Manuel López-Ibáñez ---
> GCC has sunk part of the old_size computation (not the loads but the
> subtraction) to after the realloc but before the use of old_size.
Is this code motion valid? Is there any point in the middle-e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109125
Bug ID: 109125
Summary: [13 regression] SIGBUS in m2pim_ldtoa_ldtoa
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109125
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109109
--- Comment #14 from Martin Liška ---
Btw. the problematic instruction that assembly the page_id_t:
# /tmp/trxundo.ii:181919: if (__builtin_expect(!undo_block, (0))) {
addl$48, %esp #,
# /tmp/trxundo.ii:181915: buf_block_t*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109122
--- Comment #1 from Jonathan Wakely ---
As requested when creating a bug, please read https://gcc.gnu.org/bugs/ which
says to provide the testcase, not a URL to somewhere else.
#include
#include
#include
#include
#include
namespace rng =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109122
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109123
--- Comment #6 from Manuel López-Ibáñez ---
(In reply to Manuel López-Ibáñez from comment #5)
> Is this code motion valid? Is there any point in the middle-end that checks
> the validity of the pointer beyond a free/realloc?
>
> If there is a p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109118
--- Comment #1 from CVS Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:0e0c18f60af51f3afd210a2929b853dd02abe996
commit r13-6655-g0e0c18f60af51f3afd210a2929b853dd02abe996
Author: Tamar Christina
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109118
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109126
Bug ID: 109126
Summary: [DR2387] Linkage of const-qualified variable template
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62196
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:abb958ada1e4d195f31740659cd8af8bebce7bfd
commit r13-6656-gabb958ada1e4d195f31740659cd8af8bebce7bfd
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107762
--- Comment #4 from CVS Commits ---
The master branch has been updated by Eric Botcazou :
https://gcc.gnu.org/g:8b6c38ef6a7a8cc1f7cc2ff86a686e07ceab1641
commit r13-6659-g8b6c38ef6a7a8cc1f7cc2ff86a686e07ceab1641
Author: Eric Botcazou
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
--- Comment #26 from CVS Commits ---
The master branch has been updated by Eric Botcazou :
https://gcc.gnu.org/g:67839c562779081936cb79ebca156ef43d70f65f
commit r13-6660-g67839c562779081936cb79ebca156ef43d70f65f
Author: Eric Botcazou
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107762
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109127
Bug ID: 109127
Summary: More advanced constexpr value compile time evaluation
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109109
--- Comment #15 from Jakub Jelinek ---
I think I have finally a self-contained reproducer, -m32 -O2:
struct S { char pad[44]; unsigned int id; };
__attribute__((noipa, regparm (2))) unsigned long long
foo (struct S *p, unsigned int q)
{
retur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109109
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107762
--- Comment #6 from Jakub Jelinek ---
So perhaps make it dependent on targetm.have_insv () or
targetm.have_insv () && get_traditional_extraction_insn (insn, type, mode,
targetm.code_for_insv, 0, 3)
o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107762
--- Comment #7 from Eric Botcazou ---
> So perhaps make it dependent on targetm.have_insv () or
> targetm.have_insv () && get_traditional_extraction_insn (insn, type, mode,
> targetm.code_for_insv, 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109128
Bug ID: 109128
Summary: [Offload][OpenMP][OpenACC] Static linking with unused
offload function will lead to mismatch number of
offload fn/symbols
Product: gcc
Ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109123
--- Comment #7 from Richard Biener ---
(In reply to Manuel López-Ibáñez from comment #6)
> (In reply to Manuel López-Ibáñez from comment #5)
> > Is this code motion valid? Is there any point in the middle-end that checks
> > the validity of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109128
Thomas Schwinge changed:
What|Removed |Added
Last reconfirmed||2023-03-14
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109123
--- Comment #8 from Manuel López-Ibáñez ---
(In reply to Richard Biener from comment #7)
> Warning for "escapes" (the store is an escape point) is also sensible I
> think.
Would it be possible to make this distinction at the point of warning?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109128
--- Comment #2 from Tobias Burnus ---
(In reply to Thomas Schwinge from comment #1)
> See also "Allow the accelerator to have more offloaded functions than the
> host".
Which was:
- if (num_target_entries != num_funcs + num_vars)
+ if (num_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106570
Martin Liška changed:
What|Removed |Added
Keywords|needs-bisection |
--- Comment #5 from Martin Liška ---
(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106828
Xi Ruoyao changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109109
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=109129
Bug ID: 109129
Summary: [13 regression] g++.dg/cpp2a/concepts-lambda3.C in
unresolved after r13-6594-ga915c29a7d63cc
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109107
--- Comment #3 from Marek Polacek ---
A similar problem:
#define INT_MIN (-__INT_MAX__ - 1)
int a = INT_MIN;
const int b = 676540;
int
main ()
{
int c = a - 1 + (int) (short) b;
return c;
}
for which I think we need:
--- a/gcc/fold-const.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109129
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109129
Richard Biener changed:
What|Removed |Added
Keywords||testsuite-fail
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109121
--- Comment #3 from Andrew Pinski ---
This seems like a bug in uboot ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62196
--- Comment #4 from Jonathan Wakely ---
I've added some additional precondition checks to . If you compile
the original testcase with -D_GLIBCXX_ASSERTIONS it will abort at runtime now:
$ ./a.out
abcdefghijklmnopqrstuvwxyz
/home/jwakely/gcc/13/i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109122
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109122
--- Comment #3 from Marek Polacek ---
Ah, looks like we're trying to print a name of a TYPE_PTRMEMFUNC_P, but it
doesn't have one; build_ptrmemfunc_type has:
11025 /* Zap out the name so that the back end will give us the debugging
11026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109086
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #5 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109109
--- Comment #17 from Jakub Jelinek ---
Created attachment 54661
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54661&action=edit
gcc13-pr109109.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109120
--- Comment #1 from David Malcolm ---
Thanks for filing this bug. Seems to affect GCC 11 onwards, as GCC 10 didn't
support the 2nd argument to __attribute__((malloc)):
Trunk: https://godbolt.org/z/MbWezaxrz
GCC 12.2: https://godbolt.org/z/v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109096
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:c35cf160a0ed81570cff6600dba465cf95fa80fa
commit r13-6663-gc35cf160a0ed81570cff6600dba465cf95fa80fa
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109129
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:7f22d1c83e74c41116300bebac2e4c492c90b03d
commit r13-6664-g7f22d1c83e74c41116300bebac2e4c492c90b03d
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108972
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:7f22d1c83e74c41116300bebac2e4c492c90b03d
commit r13-6664-g7f22d1c83e74c41116300bebac2e4c492c90b03d
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109129
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109096
--- Comment #5 from Jakub Jelinek ---
Fixed on the trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109093
--- Comment #12 from H.J. Lu ---
ix86_find_max_used_stack_alignment fails to detect that
(insn 281 152 282 34 (set (mem/c:V16QI (reg/f:DI 2 cx [144]) [0 MEM
[(void *)_109]+0 S16 A128])
(reg:V16QI 21 xmm1 [orig:156 MEM [(void *)_109] ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109120
--- Comment #2 from David Malcolm ---
Looks like the attribute was added to iconv_open in glibc in this commit:
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=260a430dd841072020c4dae91468322e619e7330
Unfortunately, as currently written
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109120
--- Comment #3 from David Malcolm ---
(In reply to David Malcolm from comment #2)
> Looks like the attribute was added to iconv_open in glibc in this commit:
>
> https://sourceware.org/git/?p=glibc.git;a=commitdiff;
> h=260a430dd841072020c4dae9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107310
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=109120
--- Comment #4 from David Malcolm ---
...and thus presumably glibc 2.36 onwards uses the attribute on iconv_open.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109120
--- Comment #5 from David Malcolm ---
Potentially could be worked around from the gcc side by adding a known_function
implementation for iconv_{open,close}.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109125
--- Comment #1 from Gaius Mulley ---
Created attachment 54662
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54662&action=edit
Proposed fix
Thanks for the bug report - here is a proposed patch for ldtoa, dtoa and also
termios all of which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109120
--- Comment #6 from David Malcolm ---
Note to self: there's a usage example in the glibc manual here:
https://www.gnu.org/software/libc/manual/html_node/iconv-Examples.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109130
Bug ID: 109130
Summary: 464.h264ref regressed by 6.5% on a Neoverse-N1 CPU
with PGO, LTO, -Ofast and -march=native
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994
--- Comment #19 from Tom Stellard ---
Thanks, Jakub. It looks like this is in fact an LLVM bug. I've posted a patch
here that fixes my test case: https://reviews.llvm.org/D146067
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109125
Gaius Mulley changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109125
Gaius Mulley changed:
What|Removed |Added
Attachment #54662|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107925
--- Comment #8 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:68ba253bda74d6c6e77726d98184a6faee5e7337
commit r13--g68ba253bda74d6c6e77726d98184a6faee5e7337
Author: Martin Jambor
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107925
--- Comment #9 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:1526ecd739fc6a13329abdcbdbf7c2df57c22177
commit r13-6667-g1526ecd739fc6a13329abdcbdbf7c2df57c22177
Author: Martin Jambor
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107925
--- Comment #10 from Martin Jambor ---
Fixed on trunk so far, I plan to backport it to GCC 12 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109092
--- Comment #4 from Jeffrey A. Law ---
Also note there's an unsafe REGNO in peephole.md as well. Slightly different in
form, but still unprotected and thus for well crafted inputs could probably
cause an ICE or incorrect codegen (in a non-checki
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109108
--- Comment #1 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:423d34f61c43e400f0d5b837fe93c83963b2ecdd
commit r13-6668-g423d34f61c43e400f0d5b837fe93c83963b2ecdd
Author: Iain Buclaw
Date: Tue M
1 - 100 of 166 matches
Mail list logo