https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86418
Eric Gallager changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #6
On 10/14/23 17:32, Roger Sayle wrote:
This patch improves the initial RTL expanded for double word shifts
on architectures with conditional moves, so that later passes don't
need to clean-up unnecessary and/or unused instructions.
Consider the general case, x << y, which is expanded well
RVVM2x2QI should be rvvm2qi instead of rvvmq1i.
gcc/ChangeLog:
* config/riscv/vector-iterators.md: Fix vsingle incorrect attribute for
RVVM2x2QI.
---
gcc/config/riscv/vector-iterators.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111492
JuzheZhong changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111821
--- Comment #2 from Andrew Pinski ---
Note smaller #s decrease the memory usage and compiles faster but still uses a
lot of memory.
Going from 0x100 to 0x200:
expand : 0.60 (100%) 0.06 (100%) 0.70 (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111821
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111821
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85152
Maciej W. Rozycki changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111821
Bug ID: 111821
Summary: GCC: 14: continue to consume memory until OOM
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #22 from Jerry DeLisle ---
Sorry for delays. I am back looking at this.
My take on the table 13.2 for the case: EN0.0E0
No matter what the E for the exponent must be shown.
If the exponent is 0 then a plus sign must be shown.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111820
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111820
--- Comment #1 from Andrew Pinski ---
Looks to be the vectorizer:
#0 0x012d1fe5 in wide_int_storage::operator= (x=..., this=) at /home/apinski/src/upstream-gcc-git/gcc/gcc/wide-int.h:1221
#1 generic_wide_int::operator= (this=) at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111820
Bug ID: 111820
Summary: GCC: 14: hangs with a simple while loop
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
Andrew Pinski changed:
What|Removed |Added
CC||141242068 at smail dot
nju.edu.cn
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111819
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111818
Andrew Pinski changed:
What|Removed |Added
Known to work||4.9.1
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111819
Bug ID: 111819
Summary: GCC: 14: internal compiler error: in fold_offsetof, at
c-family/c-common.cc:6877
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111818
Bug ID: 111818
Summary: GCC: 14: internal compiler error: tree check: expected
tree that contains 'decl common' structure, have
'integer_cst' in tree_could_trap_p, at tree-eh.cc:2733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111815
Maciej W. Rozycki changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111756
--- Comment #2 from Gaius Mulley ---
Created attachment 56114
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56114=edit
Proposed patch implementing the dependency options for gm2/cc1gm2
This proposed patch implements -M, -MM, -MF, -MT,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111817
Bug ID: 111817
Summary: GCC: 14: internal compiler error: in expand_asm_stmt,
at cfgexpand.cc:3389
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111816
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-invalid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111816
Bug ID: 111816
Summary: GCC: 14: internal compiler error: Segmentation fault
at c_parser_parse_gimple_body
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101364
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101285
Andrew Pinski changed:
What|Removed |Added
Keywords||patch
URL|
This is a simple error recovery issue when c_safe_arg_type_equiv_p
was added in r8-5312-gc65e18d3331aa999. The issue is that after
an error, an argument type (of a function type) might turn
into an error mark node and c_safe_arg_type_equiv_p was not ready
for that. So this just adds a check for
When checking to see if we have a function declaration has a conflict due to
promotations, there is no test to see if the type was an error mark and then
calls
c_type_promotes_to. c_type_promotes_to is not ready for error_mark and causes an
ICE.
This adds a check for error before the call of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111709
John David Anglin changed:
What|Removed |Added
CC||aldyh at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #105 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #104)
> I've been thinking about something. I suspect that this patch could take
> work away from other patches. I'm sorry, I don't know how to express myself
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111815
Bug ID: 111815
Summary: VAX: ICE in 'print_operand_address' while building
'elf_zstd_decompress' from libbacktrace/elf.c
Product: gcc
Version: 14.0
Status: UNCONFIRMED
This patch improves the initial RTL expanded for double word shifts
on architectures with conditional moves, so that later passes don't
need to clean-up unnecessary and/or unused instructions.
Consider the general case, x << y, which is expanded well as:
t1 = y & 32;
t2 = 0;
On 10/14/23 16:14, Roger Sayle wrote:
This patch is my proposed solution to PR rtl-optimization/91865.
Normally RTX simplification canonicalizes a ZERO_EXTEND of a ZERO_EXTEND
to a single ZERO_EXTEND, but as shown in this PR it is possible for
combine's make_compound_operation to
On 10/14/23 13:51, Tobias Burnus wrote:
@@ -5003,6 +5001,17 @@ The variable @env{GCC_ACC_NOTIFY} is used for diagnostic
purposes.
@node ACC_DEVICE_TYPE
@section @code{ACC_DEVICE_TYPE}
@table @asis
+@item @emph{Description}:
+Control the default device type to use when executing compute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
Gaius Mulley changed:
What|Removed |Added
CC||gaius at gcc dot gnu.org
--- Comment
Snapshot gcc-13-20231014 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/13-20231014/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
This patch is my proposed solution to PR rtl-optimization/91865.
Normally RTX simplification canonicalizes a ZERO_EXTEND of a ZERO_EXTEND
to a single ZERO_EXTEND, but as shown in this PR it is possible for
combine's make_compound_operation to unintentionally generate a
non-canonical ZERO_EXTEND
On Sat, Oct 14, 2023 at 03:46:52PM -0600, Sandra Loosemore wrote:
> On 10/14/23 13:43, Tobias Burnus wrote:
> > When browsing libgomp doc, I came across
> > https://gcc.gnu.org/onlinedocs/libgomp/Enabling-OpenMP.html>> First, I
> > found especially the Fortran part difficult to read. Secondly,
> >
On 10/14/23 13:43, Tobias Burnus wrote:
When browsing libgomp doc, I came across
https://gcc.gnu.org/onlinedocs/libgomp/Enabling-OpenMP.html>>
First, I found especially the Fortran part difficult to read. Secondly,
it missed the C++ attribute syntax. And I also missed a reference to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101364
--- Comment #3 from Andrew Pinski ---
Created attachment 56112
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56112=edit
Patch which I am testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111814
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111814
--- Comment #3 from Andrew Pinski ---
Something like:
```
diff --git a/gcc/config/sh/sh.cc b/gcc/config/sh/sh.cc
index 294faf7c0c3..18fa2129388 100644
--- a/gcc/config/sh/sh.cc
+++ b/gcc/config/sh/sh.cc
@@ -980,6 +980,10 @@ sh_option_override
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111814
--- Comment #2 from Bruno Haible ---
Created attachment 56111
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56111=edit
test case for long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111814
--- Comment #1 from Bruno Haible ---
Created attachment 56110
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56110=edit
test case for double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111814
Bug ID: 111814
Summary: on sh4, __builtin_nan* returns signalling NaNs instead
of quiet NaNs and vice versa
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101364
--- Comment #2 from Andrew Pinski ---
Reduced testcase:
```
void fruit();
void fruit(
int b[x],
short c)
{}
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101285
--- Comment #5 from Andrew Pinski ---
Created attachment 56108
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56108=edit
Patch which I am testing
On 10/12/23 10:37, Tobias Burnus wrote:
@@ -3133,15 +3134,25 @@ variable can be set to one of three values -
@code{MANDATORY}, @code{DISABLED}
or @code{DEFAULT}.
If set to @code{MANDATORY}, the program will terminate with an error if
-the offload device is not present or is not supported.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104351
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |14.0
Resolution|---
I was recently suggesting someone to use ACC_DEVICE_TYPE; I did not point to the
documentation it only contains the title:
https://gcc.gnu.org/onlinedocs/libgomp/ACC_005fDEVICE_005fTYPE.html
Admittedly, there is also "Reference:" pointing to the OpenACC specification,
but the latter just
When browsing libgomp doc, I came across
https://gcc.gnu.org/onlinedocs/libgomp/Enabling-OpenMP.html
First, I found especially the Fortran part difficult to read. Secondly,
it missed the C++ attribute syntax. And I also missed a reference to
-fopenmp-simd.
The attached patch tries to improve
I wonder why I missed the following – but it now works :-/
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111813
Bug ID: 111813
Summary: Inconsistent limit in Ada.Calendar.Formatting
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
On 10/12/23 04:53, Tobias Burnus wrote:
libgomp.texi: Note to 'Memory allocation' sect and missing mem-memory routines
This commit completes the documentation of the OpenMP memory-management
routines, except for the unimplemented TR11 additions. It also makes clear
in the 'Memory allocation'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111812
--- Comment #3 from Jakub Jelinek ---
r14-4332-ge40f3301019a521b11bfcc25aeb1388e6da1ca2f should have fixed this exact
issue, but I think for gcc 4.8.5 there is another poly_int related issue that
currently prevents builds with such system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111812
seurer at gcc dot gnu.org changed:
What|Removed |Added
Host||powerpc64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111812
--- Comment #1 from Andrew Pinski ---
See thread starting at
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632008.html
We might decide to push the host version requirement ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111812
Bug ID: 111812
Summary: [14 regression] Can't build with gcc 4.8.5
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808
--- Comment #3 from Jakub Jelinek ---
Excess precision changes behavior in lots of significant ways, and I don't
really see how we could warn for this, there are different kinds of excess
precision, the i386 one of promoting float/double to
with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
```
GCC version:
```
gcc
(Compiler-Explorer-Build-gcc-300d7d3a8f4b53d045ce43f1ed4e10301781c786-binutils-2.40)
14.0.0 20231014 (experimental)
Copyright (C) 2023 Free Software Foundation, Inc.
This is free softwar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808
--- Comment #2 from Martin Uecker ---
On i386 1. / 3. is computed with higher precision than double and then the
initializer changes the value which is a contraint violation in C23. But
whether this happens or not depends on the architecture,
On 10/14/23 09:49, Andrew Pinski via Gcc wrote:
On Fri, Oct 13, 2023 at 10:16 PM Hanke Zhang via Gcc wrote:
Hi, I'm working on optimizing if-conversion for my own business
recently. I got a problem here.
I tried to optimize it in such a case, for example, when a conditional
statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111810
Bug ID: 111810
Summary: GCC-14 segfault: error: expected declaration or
statement at end of input
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111809
--- Comment #1 from wierton <141242068 at smail dot nju.edu.cn> ---
Full stack backtrace:
: In function 'bar':
:8:1: error: SSA name '' with version 3 has no definition
8 | }
| ^
At top level:
cc1: internal compiler error: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111809
Bug ID: 111809
Summary: GCC-14: internal error, internal compiler error: in
release_function_body, at cgraph.cc:1805
Product: gcc
Version: 14.0
Status: UNCONFIRMED
On Fri, Oct 13, 2023 at 10:16 PM Hanke Zhang via Gcc wrote:
>
> Hi, I'm working on optimizing if-conversion for my own business
> recently. I got a problem here.
>
> I tried to optimize it in such a case, for example, when a conditional
> statement block has only if statement and no else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111789
--- Comment #4 from Andrew Pinski ---
*** Bug 111804 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111804
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111805
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111805
--- Comment #1 from Andrew Pinski ---
The clang assembly you posted does not match the source you posted ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111806
--- Comment #2 from Andrew Pinski ---
The difference is -O2 duplicates the return which might speed up things.
This happens during bb reorder due to estimates of the bb counts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111807
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111807
Andrew Pinski changed:
What|Removed |Added
Component|c |tree-optimization
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #104 from Alexander Klepikov
---
(In reply to Oleg Endo from comment #103)
> Sorry, I've been busy with other things. I think your patch is OK, but I
> wanted to test it in more detail before committing it.
Oh, it's OK. By the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808
Bug ID: 111808
Summary: [C23] constexpr
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111807
--- Comment #3 from David Binderman ---
Second test case:
int func_40_l_118;
struct S0 {
signed f1 : 1;
};
void func_40() {
struct S0 l_103[16];
*l_103 = l_103[15];
l_103[15].f1 &_40_l_118;
}
On 10/13/23 18:15, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
In C++23, since P2448, a constexpr function F that calls a non-constexpr
function N is OK as long as we don't actually call F in a constexpr
context. So instead of giving an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111708
--- Comment #8 from Martin Uecker ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632999.html
Bootstrapped and regression tested on x86_64.
c: error for function with external and internal linkage [PR111708]
Declaring a function with both external and internal linkage
in the same TU is translation-time UB. Add an error for this
case as already done for objects.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Hi,
The internal error in analyzer turned out to be caused by a subtly
invalid tree representation of STRING_CSTs in the D front-end, fixed by
including the terminating NULL as part of the TREE_STRING_POINTER.
When adding a first analyzer test for D, it flagged up another subtle
mismatch in one
Hi,
This is a small refactoring ahead of the next merge from upstream, where
a few more front-end routines will stop doing the file handling
themselves.
Bootstrapped and regression tested on x86_64-linux-gnu/-m32, committed
to mainline.
Regards,
Iain.
---
gcc/d/ChangeLog:
* d-lang.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537
--- Comment #11 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:578afbc751d122b55196a23fe75a17e1b4e9bd0c
commit r14-4639-g578afbc751d122b55196a23fe75a17e1b4e9bd0c
Author: Iain Buclaw
Date: Sat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111807
David Binderman changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111807
--- Comment #1 from David Binderman ---
Reduced C code seems to be:
struct S0 {
unsigned f2 : 7
} func_40() {
struct S0 l_4827[10];
l_4827[5] = l_4827[9];
0 || l_4827[9].f2;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111807
Bug ID: 111807
Summary: ice in verify_sra_access_forest with -O1
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
> Am 14.10.2023 um 11:50 schrieb Jakub Jelinek :
>
> Hi!
>
>> On Sat, Oct 14, 2023 at 10:41:28AM +0200, Richard Biener wrote:
>> Can we somehow abstract this common pattern?
>
> So like this? With room for the future tweaks like printing decimal
> instead of hex numbers by print_dec*,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109227
Lev changed:
What|Removed |Added
CC||lr.soft.now at gmail dot com
--- Comment #6 from
Hi!
On Sat, Oct 14, 2023 at 10:41:28AM +0200, Richard Biener wrote:
> Can we somehow abstract this common pattern?
So like this? With room for the future tweaks like printing decimal
instead of hex numbers by print_dec*, where we'd only need to adjust
the inlines. The XALLOCAVEC call is left
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36312
sarvel changed:
What|Removed |Added
CC||sarvelgcc at outlook dot com
--- Comment #23
> Am 14.10.2023 um 10:21 schrieb Jakub Jelinek :
>
> Hi!
>
> As mentioned in the PR, my estimations on needed buffer size for wide_int
> and especially widest_int printing were incorrect, I've used get_len ()
> in the estimations, but that is true only for !wi::neg_p (x) values.
> Under the
On Sat, 14 Oct 2023, 00:33 Benjamin Brock, wrote:
> This is my first time submitting a patch, so my apologies if I'm
> submitting incorrectly or missing something.
>
Thanks for contributing!
I don't think this patch counts as legally significant, but if you
contribute again in future you
Hi!
As mentioned in the PR, my estimations on needed buffer size for wide_int
and especially widest_int printing were incorrect, I've used get_len ()
in the estimations, but that is true only for !wi::neg_p (x) values.
Under the hood, we have 3 ways to print numbers.
print_decs which if
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #113 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:cb0119242317c2a6f3127b4acff6aadbfd1dfbc4
commit r14-4635-gcb0119242317c2a6f3127b4acff6aadbfd1dfbc4
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98533
Roman Zhuykov changed:
What|Removed |Added
CC||zhroma at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111806
--- Comment #1 from AK ---
It seems like we could 'sink' the 4 common instructions (of .L2) at -O3
L2:
add rsp, 48
xor eax, eax
pop rbx
ret
Or is it due to some kind of tail duplication?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111806
Bug ID: 111806
Summary: g++ generates better code for variant at
-Os compared to -O3
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
97 matches
Mail list logo
