https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110035
--- Comment #12 from Pontakorn Prasertsuk ---
I notice that GCC also does not optimize this case:
https://godbolt.org/z/7oGqjqqz4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110035
--- Comment #11 from Pontakorn Prasertsuk ---
(In reply to rguent...@suse.de from comment #10)
> On Mon, 5 Jun 2023, ptk.prasertsuk at gmail dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110035
> >
> > --- Comment #9 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110135
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109689
--- Comment #6 from Andrew Pinski ---
*** Bug 110135 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109689
Andrew Pinski changed:
What|Removed |Added
CC||19373742 at buaa dot edu.cn
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110123
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110135
--- Comment #1 from CTC <19373742 at buaa dot edu.cn> ---
Created attachment 55266
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55266=edit
The compiler output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110135
Bug ID: 110135
Summary: ICE in check_loop_closed_ssa_def, at
tree-ssa-loop-manip.cc:647
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541
--- Comment #17 from Sam James ---
Thank you Vladimir! I appreciate the time both of you are spending on
alternative platforms for bugs like these.
Also, Vladimir, if you want to continue to use the machine after this, if you
ever have an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110120
Hans-Peter Nilsson changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110134
--- Comment #3 from Andrew Pinski ---
r6-1814-g66e1cacf608045 caused GCC 6 to stop doing both.
Because they were considered redundant with the patterns added by:
r6-1113-g534bd33b61d08e
Which was mostly true.
I think forwprop was working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110120
--- Comment #9 from CVS Commits ---
The master branch has been updated by Hans-Peter Nilsson :
https://gcc.gnu.org/g:9677cc7496ffe44c5b483658ce30361519576537
commit r14-1559-g9677cc7496ffe44c5b483658ce30361519576537
Author: Hans-Peter Nilsson
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110134
--- Comment #2 from Andrew Pinski ---
That is:
```
/* -A CMP -B -> B CMP A. */
(for cmp (tcc_comparison)
scmp (swapped_tcc_comparison)
(simplify
(cmp (negate @0) (negate @1))
(if (FLOAT_TYPE_P (TREE_TYPE (@0))
||
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110134
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92407
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=110134
Bug ID: 110134
Summary: [10/11/12/13/14 Regression] (-unsigned1) != CST is not
optimized to unsigned1 != CST at the gimple level
Product: gcc
Version: 14.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110122
--- Comment #3 from waffl3x ---
Very cool, thanks, since your test case seems to cause problems in GCC 11 and
GCC 12 does that mean the bug goes deeper than I thought?
(In reply to Patrick Palka from comment #2)
> It seems only the first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110123
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110123
--- Comment #2 from Andrew Pinski ---
Reducing ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110133
--- Comment #2 from Jonathan Wakely ---
I've also considered using strerror_l (with newlocale and uselocale), so that
the strings are not affected by the current locale.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110133
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-06-05
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110120
Hans-Peter Nilsson changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110130
Andrew Pinski changed:
What|Removed |Added
Depends on||106622
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110120
Hans-Peter Nilsson changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hp at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110129
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> >Did I miss anything here? Thanks!
>
> Yes clang is incorrect in removing the infinite loop.
>
> See bug 94392 comment #3
The loop around via goto is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110129
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110131
--- Comment #3 from Andrew Pinski ---
So the biggest issue here is:
Global Exported: _37 = [irange] unsigned int [0, 0][3, 32768][4294934529, +INF]
Not folded
Folding statement: _21 = _37 <= 2;
_21 not being folded into _21 = _37 == 0
That is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110133
Bug ID: 110133
Summary: System error message should ideally use strerror_r
over strerror
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110132
--- Comment #1 from Alex Coplan ---
I should add, I believe (but haven't confirmed for sure) that the only reason
we don't see these warnings when including "arm_acle.h" is the warning
suppression that is done by the FE when parsing system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110132
Bug ID: 110132
Summary: aarch64: Bogus -Wbuiltin-declaration-mismatch with
ls64 builtins
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
--- Comment #83 from Andrew Pinski ---
(In reply to Carlos Galvez from comment #82)
> Hi,
>
> This bug is still present in GCC 11.3.0. My use case is using large
> std::arrays. NOTE: the problem immediately goes away if the arrays are not
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #26 from Thomas Neumann ---
(In reply to Florian Weimer from comment #23)
>
> u is the original read pointer as far as I can see. So it looks like it
> should look like this:
>
> diff --git a/libgcc/unwind-dw2-fde-dip.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #25 from Carlos Galvez ---
Perhaps this is a stupid comment, but isn't "ob.s.b.encoding" uninitialized?
/* inside find_fde_tail */
struct object ob;
...
ob.pc_begin = NULL;
ob.tbase = NULL;
ob.dbase = (void *) dbase;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #24 from Florian Weimer ---
(With the missing ; added, of course.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #23 from Florian Weimer ---
(In reply to Thomas Neumann from comment #21)
> It must be something more complex. value is small here (more precisely: 1888
> in the crashes later), which is not a valid pointer address. We probably
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #22 from Carlos Galvez ---
Indeed it's an uninitialized read according to valgrind:
==15475== Use of uninitialised value of size 8
==15475==at 0x1E81C2E9: base_from_object (unwind-dw2-fde.c:319)
==15475==by 0x1E81C2E9:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110064
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110084
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110114
Marek Polacek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106486
--- Comment #5 from H. Peter Anvin ---
Yes, exactly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541
--- Comment #16 from Vladimir Makarov ---
Sam, thank you for your help. I've reproduced the problem on your machine.
The fix most probably will be ready this week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105863
--- Comment #4 from H. Peter Anvin ---
So I'm updating this to be C23 #embed, since that is a bit more general than
the typical incbin (at least conceptually it operates on the preprocessor
syntactic level; it does not of course preclude a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104577
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110102
--- Comment #6 from Arthur O'Dwyer ---
(In reply to Jason Merrill from comment #5)
> (In reply to Arthur O'Dwyer from comment #4)
> > My first, reduced, example, where `std::list v = {1,2,3}` is accepted for
> > move-only type `A`, is 100% a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110131
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> _33 = (intD.6) _13;
> # RANGE [irange] unsigned int [2, 32767][4294934528, +INF]
> _29 = (unsigned int) _13;
> # RANGE [irange] unsigned int [0, 0][3,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110131
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110102
Jason Merrill changed:
What|Removed |Added
Target Milestone|13.2|---
--- Comment #5 from Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110131
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110131
Bug ID: 110131
Summary: [13/14 Regression] Missed Dead Code Elimination when
using __builtin_unreachable since
r12-6924-gc2b610e7c6c
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110127
Patrick Palka changed:
What|Removed |Added
Last reconfirmed||2023-06-05
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #21 from Thomas Neumann ---
It must be something more complex. value is small here (more precisely: 1888 in
the crashes later), which is not a valid pointer address. We probably have to
add this to some base pointer? But it is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110129
--- Comment #2 from Haoxin Tu ---
(In reply to Andrew Pinski from comment #1)
Oops, my bad. Thank you for pointing this out. I didn't notice the front-end is
C++ in GodBolt.
I have another similar case, can you take a look, please?
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110130
Bug ID: 110130
Summary: the rust demangling trap in long hangs , causing
binutils/nm hangs for a long time to be killed.
Product: gcc
Version: rust/master
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110128
--- Comment #1 from jwjagersma at gmail dot com ---
Additionally, the following example does not produce any -Wattributes warnings
at all, but the attributes are still not copied:
template
struct check_num
{
static void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110129
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
ut
(hang)
$gcc-10.1 -w -O2 test.c ;./a.out
b1b 1
$gcc-9.5 -w -O1 test.c ;./a.out
(hang)
$gcc-9.5 -w -O2 test.c ;./a.out
b1b 1
GCC version:
Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/g++
COLLECT_LTO_WRAPPER=/opt/compiler-explorer/gcc-trunk-20230605/bin/../libexec/gcc/x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110128
Bug ID: 110128
Summary: copy attribute does not copy from template
specializations
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110124
--- Comment #4 from Andrew Pinski ---
So basically more code for the C++20 case causes the less inlining into main.
Overall this is not an bug really because GCC treats main as known to be called
only once and anything main calls is not always
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109967
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110124
--- Comment #3 from Andrew Pinski ---
The reason for the C++20 and C++17 difference is because std::tie creates a
std::tuple and for C++20 has a spaceship operator<=> (instead of operator<) and
that causes needing to another another function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110124
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110124
--- Comment #1 from Andrew Pinski ---
Created attachment 55263
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55263=edit
original testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110106
Marek Polacek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #19 from Thomas Neumann ---
Hm, then I don't know how we end up with the non-regular table content. The
code checks for hdr->fde_count_enc != DW_EH_PE_omit, and that is false in the
executable that you provided.
But regardless of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #18 from Carlos Galvez ---
Thanks for the investigation! To clarify: my last reproducible example does not
use gold, instead it uses the default GNU ld version 2.38.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #17 from Thomas Neumann ---
The bug was introduced by gcc commit e724b04. It avoids calls to
read_encoded_value_with_base for performance reasons, but unfortunately this
causes the variable eh_frame to be uninitialized if the fast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
Thomas Neumann changed:
What|Removed |Added
CC||fweimer at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
--- Comment #20 from Thomas Schwinge ---
(In reply to Iain Sandoe from comment #19)
> (In reply to Thomas Schwinge from comment #18)
> > r14-1490-g04abe1944d30eb18a2060cfcd9695d085f7b4752 "Support parallel
> > testing in libgomp: fallback Perl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110127
Bug ID: 110127
Summary: -fimplicit-constexpr leads to extremely slow and
memory intensive compilation
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110122
--- Comment #2 from Patrick Palka ---
It seems only the first testcase exhibits a 13 regression, we never accepted
the second testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110122
Patrick Palka changed:
What|Removed |Added
Last reconfirmed||2023-06-05
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99274
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-06-05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99242
Jonathan Wakely changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #15 from Carlos Galvez ---
Created attachment 55261
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55261=edit
Reproducible example nvinfer
Attaching (hopefully) reproducible example as a tarball, containing:
- download.sh:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103499
--- Comment #6 from Mark Millard ---
(In reply to Jonathan Wakely from comment #5)
The relationship I was thinking of was that, without this
being fixed, the full set of header units for the standard
library probably could not be completed: a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
--- Comment #15 from Paweł Bylica ---
For what it's worth, clang's __builtin_addc is implemented in frontend only as
a pair of __builtin_add_overflow. The commit from 11 year ago does not explain
why they were added.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110126
Bug ID: 110126
Summary: Variables are reported as unused when only referenced
by ASM statements
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110125
Bug ID: 110125
Summary: Variables are reported as uninitialized when only set
inside WITH statement
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110124
Bug ID: 110124
Summary: Not inlining comparison operator when using std::tie
with -std=c++20
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110055
--- Comment #8 from Sprite ---
(In reply to Richard Biener from comment #7)
> The clobber is built by gimplify_target_expr and TARGET_EXPR_SLOT is changed
> in place to the static variable.
>
> Does the following fix the RISC-V issue?
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109967
Davin McCall changed:
What|Removed |Added
CC||davmac at davmac dot org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #14 from Thomas Neumann ---
I cannot reproduce the problem, but admittedly I used a newer Ubuntu version. I
tried compiling it with gcc 7.5.0, linking it with gold 1.16, and using the gcc
version you specified (07c52d1eec9) for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110123
--- Comment #1 from CTC <19373742 at buaa dot edu.cn> ---
Created attachment 55260
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55260=edit
the compiler output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110123
Bug ID: 110123
Summary: ICE in check_loop_closed_ssa_def, at
tree-ssa-loop-manip.cc:647
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110122
Bug ID: 110122
Summary: using an aggregate with a member variable with a user
defined copy constructor in a class NTTP causes
capture and use of the `this` pointer in a generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110092
--- Comment #5 from Piotr Nycz ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Piotr Nycz from comment #0)
> > So, probably it is doable to add warning like: "bist/shared_ptr.h is an
> > internal header file, included by other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31584
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |4.3.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103499
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-06-05
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #62 from Jakub Jelinek ---
What the patch including incremental one currently does is:
1) small _BitInt (on x86-64 N <= 64) - the BITINT_TYPEs are kept as is in the
IL
and expanded, they always have non-BLKmode (QI/HI/SI/DI) and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #61 from rguenther at suse dot de ---
On Mon, 5 Jun 2023, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
>
> --- Comment #60 from Jakub Jelinek ---
> (In reply to Richard Biener from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110035
--- Comment #10 from rguenther at suse dot de ---
On Mon, 5 Jun 2023, ptk.prasertsuk at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110035
>
> --- Comment #9 from Pontakorn Prasertsuk ---
> (In reply to Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110035
--- Comment #9 from Pontakorn Prasertsuk ---
(In reply to Richard Biener from comment #8)
> (In reply to Pontakorn Prasertsuk from comment #7)
> > For the LLVM IR code of the snippet I provided, Clang's alias analysis can
> > prove that `new`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #60 from Jakub Jelinek ---
(In reply to Richard Biener from comment #59)
> Oh, so BITINT_TYPE is INTEGRAL_TYPE_P but not INTEGER_TYPE (I think we
> don't have any BLKmode integer types?).
Yes. Some BITINT_TYPEs have BLKmode.
> I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #59 from Richard Biener ---
(In reply to Jakub Jelinek from comment #58)
> (In reply to Richard Biener from comment #57)
> > (In reply to Jakub Jelinek from comment #56)
> > > Created attachment 55244 [details]
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #58 from Jakub Jelinek ---
(In reply to Richard Biener from comment #57)
> (In reply to Jakub Jelinek from comment #56)
> > Created attachment 55244 [details]
> > gcc14-bitint-wip-inc.patch
> >
> > Incremental patch on top of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2021-08-22 00:00:00 |2023-6-5
--- Comment #29 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
Richard Biener changed:
What|Removed |Added
CC||tneumann at users dot
sourceforge.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863
Bug 89863 depends on bug 79364, which changed state.
Bug 79364 Summary: some variadic functions with an empty struct miscompiled
with C++ (at least for x64 targets)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79364
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79364
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |8.0
Status|UNCONFIRMED
1 - 100 of 121 matches
Mail list logo
