https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109138
Bug ID: 109138
Summary: wrong code at -O1 and above on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109086
--- Comment #10 from liwei at loongson dot cn ---
(In reply to Richard Biener from comment #4)
> (In reply to liwei from comment #3)
> > Thank you for your quick reply!
> >
> > The final call of the expand_simple_binop function returns part of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109117
--- Comment #5 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:a9ae16db8cbb2c0ec8e8384ac38ce618f9af1e3a
commit r13-6680-ga9ae16db8cbb2c0ec8e8384ac38ce618f9af1e3a
Author: Hu, Lin1
Date: Mon Mar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64587
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109086
--- Comment #9 from Xi Ruoyao ---
(In reply to Richard Biener from comment #4)
> > Maybe the expand_binop function does not consider the case of dependency
> > with `target` when generating rtx for the case of promote MODE_INT mode, and
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109086
--- Comment #8 from liwei at loongson dot cn ---
(In reply to Xi Ruoyao from comment #7)
> Things are already wrong in 255r:
>
> (jump_insn 17 16 42 4 (set (pc)
> (if_then_else (ne (reg:DI 90)
> (const_int 0 [0]))
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109086
--- Comment #7 from Xi Ruoyao ---
Things are already wrong in 255r:
(jump_insn 17 16 42 4 (set (pc)
(if_then_else (ne (reg:DI 90)
(const_int 0 [0]))
(label_ref 20)
(pc))) "t.c":4:23 discrim 1 -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109086
--- Comment #6 from Xi Ruoyao ---
(In reply to Xi Ruoyao from comment #5)
> Definitely not a __builtin_strlen expansion issue. Things start to go wrong
> in 318r.bbro pass. In 317r.rtl.dce:
>
> note 42 17 18 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109092
JuzheZhong changed:
What|Removed |Added
CC||juzhe.zhong at rivai dot ai
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
--- Comment #7 from Andrew Pinski ---
(In reply to Sam James from comment #6)
> (In reply to Andrew Pinski from comment #5)
> > The inline-asm inside get_cabac_inline_x86 needs 7 registers (6 + ecx is
> > used as a clobber). So obviously it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
--- Comment #6 from Sam James ---
(In reply to Andrew Pinski from comment #5)
> The inline-asm inside get_cabac_inline_x86 needs 7 registers (6 + ecx is
> used as a clobber). So obviously it will be really bad on 32bit x86.
Ah, thanks, I get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
--- Comment #4 from Andrew Pinski ---
Note I think get_cabac_inline_x86 is just broken inline-asm ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
--- Comment #2 from Sam James ---
(I suspect ffmpeg's build system does some
buffering/synchronisation/suppression of output until a job is complete which
is why it looks like a hang with no output at all, while running it manually
gets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
--- Comment #1 from Sam James ---
Created attachment 54667
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54667=edit
h264_cabac.i
With the attached h264_cebac.i:
- gcc-11 -m32 -c h264_cabac.i -O3 -march=znver1 # works
- gcc-12 -m32 -c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
Bug ID: 109137
Summary: [12/13 regression] Compiling ffmpeg with -m32 on
x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c
since r12-9086-g489c81db7d4f75
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96830
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109111
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96830
--- Comment #13 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:cd5baeb4489b6a953abbc7f02fea457fd9ed2f83
commit r13-6677-gcd5baeb4489b6a953abbc7f02fea457fd9ed2f83
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96830
--- Comment #12 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:ec62dc95c4f8776c9f4eff2a9a06f9aef6a2d98a
commit r13-6676-gec62dc95c4f8776c9f4eff2a9a06f9aef6a2d98a
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109111
--- Comment #3 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:578f633ddabd62b41beed635697c95ee2aaa39c0
commit r13-6675-g578f633ddabd62b41beed635697c95ee2aaa39c0
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135
--- Comment #5 from Steve Kargl ---
On Tue, Mar 14, 2023 at 10:36:27PM +, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135
>
> --- Comment #3 from Steve Kargl ---
> On Tue, Mar 14, 2023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532
--- Comment #24 from Kohei Takahashi ---
(In reply to Marek Polacek from comment #23)
> (In reply to Kohei Takahashi from comment #21)
> > (In reply to Marek Polacek from comment #18)
> > > (In reply to Barnabás Pőcze from comment #17)
> > > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135
--- Comment #4 from Steve Kargl ---
On Tue, Mar 14, 2023 at 10:36:27PM +, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135
>
> --- Comment #3 from Steve Kargl ---
> On Tue, Mar 14, 2023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109136
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135
--- Comment #3 from Steve Kargl ---
On Tue, Mar 14, 2023 at 10:25:53PM +, pinskia at gcc dot gnu.org wrote:
>
> --- Comment #1 from Andrew Pinski ---
> This is not a testsuite issue but rather the issue is the lto code is calling
> make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109136
Andrew Pinski changed:
What|Removed |Added
Summary|[concepts] initializer_list |initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106238
Jason Merrill changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135
--- Comment #2 from Andrew Pinski ---
lto-wrapper.cc use MAKE env if it exists:
char **make_argv = buildargv (getenv ("MAKE"));
if (make_argv)
{
for (unsigned argc = 0; make_argv[argc]; argc++)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109136
Bug ID: 109136
Summary: [concepts] initializer_list constructor constraint
should require static_cast for explicit conversion
operator
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135
Andrew Pinski changed:
What|Removed |Added
Component|testsuite |driver
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109135
Bug ID: 109135
Summary: Wrong make utility called with LTO testsuite
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109134
Bug ID: 109134
Summary: UBSan signed integer overflow check missing
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108468
Jason Merrill changed:
What|Removed |Added
Summary|[11/12/13 Regression] ICE |[11/12 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108468
--- Comment #2 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:9e44a9932c11f028269f3aa7e3031e703d151b0b
commit r13-6674-g9e44a9932c11f028269f3aa7e3031e703d151b0b
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97484
Abderraouf Bousri changed:
What|Removed |Added
CC||Abderraouf.bousri at g dot
enp.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109133
Bug ID: 109133
Summary: Error: operands mismatch -- statement `movec
%d0,%cacr' ignored
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109093
--- Comment #17 from H.J. Lu ---
Created attachment 54666
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54666=edit
A patch
Change ix86_find_max_used_stack_alignment to find alignments of all stack slot
accesses.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106238
--- Comment #7 from Romain Geissler ---
Another case in real life code base (in this case Boost):
https://github.com/boostorg/algorithm/pull/113
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109093
--- Comment #16 from Jakub Jelinek ---
I don't see where ix86_find_max_used_stack_alignment would walk over local vars
and for TREE_USED ones take their alignment into account. Is that done
somewhere else?
If yes, it would be nice to know
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108468
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109132
--- Comment #4 from Martin Uecker ---
Seems you are right. Thanks!
I get it for gcc-10 but not gcc-12 with -mfma on x86.
Apparently, WG14 made a change at some point to allow this. But GCC does not
implement the pragma to turn it off...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109108
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109132
--- Comment #3 from Andrew Pinski ---
Note you get the same results on x86_64 with -mfma too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109065
--- Comment #5 from Jason Merrill ---
Created attachment 54665
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54665=edit
first try
This fixes the PR, but breaks the modules tests that the earlier patch fixed.
I guess we need a different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109065
--- Comment #4 from Jason Merrill ---
The problem is that r11-5825 assumes that if a type is dependent, its
TYPE_MAIN_VARIANT and TYPE_CANONICAL are also dependent, which is not
universally true: DataAlias is dependent, so that any errors from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109132
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> ubuntu@ubuntu:~\# ~/upstream-gcc/bin/gcc t.c -O2 -ffp-contract=off
> ubuntu@ubuntu:~\# ./a.out
> 0x1.2eab1ep-2 0x0p+0
> ubuntu@ubuntu:~\# ~/upstream-gcc/bin/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109132
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109132
Bug ID: 109132
Summary: Apple M1 floating point bug when optimizing
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109093
--- Comment #15 from H.J. Lu ---
The crash went away after r13-6661-gbd6e566e9dc543 which removed variables only
used with .DEFERRED_INIT. If variables are used, they will be captured by
ix86_find_max_used_stack_alignment. Is there a testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109108
--- Comment #3 from CVS Commits ---
The releases/gcc-11 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:bd109dee471aa83f2397a6b56d074583c48475c7
commit r11-10575-gbd109dee471aa83f2397a6b56d074583c48475c7
Author: Iain Buclaw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109125
--- Comment #3 from CVS Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:19c5dfc29d83101e415590e778b99e7c37d9b730
commit r13-6671-g19c5dfc29d83101e415590e778b99e7c37d9b730
Author: Gaius Mulley
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58331
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109131
Bug ID: 109131
Summary: -Wanalyzer-deref-before-check false positive seen in
git's builtin/show-ref.c
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109093
--- Comment #14 from Jakub Jelinek ---
I assume if calls are present this is no longer a problem (so say hiding
accesses from
taking of address through some function call or doing accesses in the call is
safe).
But, one could e.g. use inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109108
--- Comment #2 from CVS Commits ---
The releases/gcc-12 branch has been updated by Iain Buclaw
:
https://gcc.gnu.org/g:0dcfd68b2a8369b647650bb68ff612cad3b33ac9
commit r12-9252-g0dcfd68b2a8369b647650bb68ff612cad3b33ac9
Author: Iain Buclaw
has the same logic:
#include
void f(std::set& a)
{
std::set b;
// b.swap(a); // Ok and has same effect
a.swap(b); // KO
}
Compiled on x86_64 with -O2 -Werror=dangling-pointer:
In file included from
/opt/compiler-explorer/gcc-trunk-20230314/include/c++/13.0.1/se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107310
Jason Merrill changed:
What|Removed |Added
Summary|[12/13 Regression] |[12 Regression] "warning:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109093
--- Comment #13 from Jakub Jelinek ---
(In reply to H.J. Lu from comment #12)
> 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])
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107310
--- Comment #5 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:71b33f8fb8daa6a7a359f322b24365d9016438fc
commit r13-6670-g71b33f8fb8daa6a7a359f322b24365d9016438fc
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109092
--- Comment #5 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #2)
> (In reply to Andrew Pinski from comment #1)
>
> > The issue is register_operand accepts subreg but then REGNO is checked on
> > it.
> > That is obviously wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109109
--- Comment #20 from Martin Liška ---
(In reply to Jakub Jelinek from comment #18)
> Hopefully fixed (the testcase is, but can't verify mariadb).
Thank you for the fix, I'm going to verify the package build.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109109
--- Comment #19 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:42630fadbe248717859d61c0244c821c32b4e52c
commit r13-6669-g42630fadbe248717859d61c0244c821c32b4e52c
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109109
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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
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
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=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=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:
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:
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=109125
Gaius Mulley changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
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=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=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=109125
--- Comment #1 from Gaius Mulley ---
Created attachment 54662
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54662=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 #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=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=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 #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;
>
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
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=109096
--- Comment #5 from Jakub Jelinek ---
Fixed on the trunk so far.
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=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:
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:
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:
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://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=edit
gcc13-pr109109.patch
Untested fix.
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
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=109122
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
---
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
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=109129
Richard Biener changed:
What|Removed |Added
Keywords||testsuite-fail
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109129
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
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:
---
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=109109
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
1 - 100 of 165 matches
Mail list logo
