https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114348
--- Comment #1 from Andrew Pinski ---
It comes from emitting a fatal error:
case DK_FATAL:
if (m_abort_on_error)
real_abort ();
finish ();
fnotice (stderr, "compilation terminated.\n");
exit (FATAL_EXIT_CODE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89645
Paul Thomas changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
Bug 87477 depends on bug 89645, which changed state.
Bug 89645 Summary: No IMPLICIT type error with: ASSOCIATE( X => function() )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89645
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99065
--- Comment #4 from Paul Thomas ---
This mega-patch, on the scale of the importance of the problem, was required
because of gfortran's one pass parsing. It might be a temporary fix because I
am contemplating how an initial pass of contained proce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114280
Paul Thomas changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
Bug 87477 depends on bug 114280, which changed state.
Bug 114280 Summary: ASSOCIATE fails with inquiry references when selector
function not yet parsed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114280
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141
Paul Thomas changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114348
--- Comment #2 from Tobias Specht ---
>From my understanding, the idea of the `-fdiagnostics-format=sarif-stderr`
option is, that the SARIF file will be printed to stderr and only the SARIF
file, so that one can take the stderr output and parse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114349
Bug ID: 114349
Summary: [14 regression] ICE when building qtwebengine
(cxx_eval_call_expression, at cp/constexpr.cc:3027)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114349
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114345
--- Comment #3 from Tamar Christina ---
(In reply to Andrew Pinski from comment #2)
> Oh VN does have some knowledge of MASK_STORE and LEN_STORE. Just not
> LOAD_LANES .
>
>
> See PR 106365 for MASK_STORE and LEN_STORE implementation. Shouldn'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #13 from Aldy Hernandez ---
I think y'all have it all figured out. Basically,
operator_cast::op1_range() is solving num_5 in the equation:
[111,111] = (short int) num_5
Where lhs is:
(gdb) p debug(lhs)
[irange] short int [111, 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114350
Bug ID: 114350
Summary: missing support for SVE widening floating point
conversion
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #14 from Jakub Jelinek ---
(In reply to Aldy Hernandez from comment #13)
> And yes Jakub, as you have noticed, BIT_IOR_EXPR, BIT_XOR_EXPR, and likely
> other operators may need to be tweaked to take bitmasks into account. I
> wouldn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114350
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #15 from Jakub Jelinek ---
Oh, and maybe if you want for performance reasons to avoid computing
irange_bitmask unless necessary, in cases like where irange_bitmask wasn't set
before verify if it is really different from the bitmask i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114338
--- Comment #5 from Richard Biener ---
For canonicalization the BIT_AND variants might be preferable since they
possibly combine with other logical ops. Also more constant operands
when the number of operations is the same might be preferable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113466
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:90b9872311ccb24685ba33b6ba6f374d50f03874
commit r14-9490-g90b9872311ccb24685ba33b6ba6f374d50f03874
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114351
Bug ID: 114351
Summary: RISC-V: ICE when __attribute__((target("arch=+v")) and
build with rv64gc -O3
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114352
Bug ID: 114352
Summary: RISC-V: ICE when __attribute__((target("arch=+v")) and
build with rv64gc -O3
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114343
Richard Biener changed:
What|Removed |Added
Known to work||13.2.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114349
--- Comment #1 from Sam James ---
ice-on-invalid reduction:
```
struct integral_constant {
} template using __bool_constant integral_constant;
template
, typename, typename > using ExtractOrT integral_constant;
template using GetPropagateOnCo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114345
--- Comment #4 from Richard Biener ---
Well, the shuffling in .LOAD_LANES will be a bit awkward to do, but sure. We
basically lack "constant folding" of .LOAD_LANES and similarly of course
we can't see through .STORE_LANES of a constant when la
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114343
--- Comment #3 from GCC Commits ---
The releases/gcc-13 branch has been updated by Torbjorn Svensson
:
https://gcc.gnu.org/g:c471d29affba0d98d5cc6ab044b53f009f35324b
commit r13-8440-gc471d29affba0d98d5cc6ab044b53f009f35324b
Author: Torbjörn SV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114352
--- Comment #1 from Li Pan ---
Test GCC version:
riscv64-unknown-elf-gcc (GCC) 14.0.1 20240315 (experimental)
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114345
--- Comment #5 from Tamar Christina ---
(In reply to Richard Biener from comment #4)
> Well, the shuffling in .LOAD_LANES will be a bit awkward to do, but sure. We
> basically lack "constant folding" of .LOAD_LANES and similarly of course
> we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113466
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114343
Torbjorn SVENSSON changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114338
--- Comment #6 from Kang-Che Sung ---
(In reply to Richard Biener from comment #5)
> For canonicalization the BIT_AND variants might be preferable since they
> possibly combine with other logical ops. Also more constant operands
> when the numb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114346
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114341
--- Comment #3 from Kang-Che Sung ---
I missed one case that is more obvious:
(1 << __builtin_ctz(y)) == (y & -y)
Multiplication is not needed in this case, and thus (1 << __builtin_ctz(y)) can
simplify to (y & -y). (I didn't think of a reason
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114345
--- Comment #6 from rguenther at suse dot de ---
On Fri, 15 Mar 2024, tnfchris at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114345
>
> --- Comment #5 from Tamar Christina ---
> (In reply to Richard Biener from comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #26 from Filip Kastl ---
Yes, the "before" is r14-5075-gc05f748218a0d5.
I just tried to take the gcda data and use them to compile mcf on another
machine. I also ran into
output.c:87:1: error: corrupted profile info: number o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114341
--- Comment #4 from Andrew Pinski ---
(In reply to Kang-Che Sung from comment #3)
> I missed one case that is more obvious:
> (1 << __builtin_ctz(y)) == (y & -y)
>
> Multiplication is not needed in this case, and thus (1 << __builtin_ctz(y))
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114347
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114351
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114352
--- Comment #2 from Richard Biener ---
*** Bug 114351 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114332
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:0319f265eddd17c32cb037b71489d9882a6eb00d
commit r14-9492-g0319f265eddd17c32cb037b71489d9882a6eb00d
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114332
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731
--- Comment #19 from Dimitar Yordanov ---
I've rerun related tests and they look OK with the latest patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113430
--- Comment #11 from Dimitrij Mijoski ---
(In reply to Sam James from comment #10)
> I don't plan on pursuing it myself, leaving it to someone else, as I can't
> reproduce on my main workstation and I don't want to faff w/ kernel config.
You sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
Bug 85316 depends on bug 114009, which changed state.
Bug 114009 Summary: [11/12/13/14 Regression] Missed optimization: (!a) * a => 0
when a=(a/2)*2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114009
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114009
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #27 from Robin Dapp ---
Can you try it with a simpler (non SPEC) test? Maybe there is still something
weird happening with SPEC's scripting.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113430
--- Comment #12 from Xi Ruoyao ---
(In reply to Dimitrij Mijoski from comment #8)
> This bug manifested at large on Github Actions CI/CI system in the last few
> days most likely because Ubuntu's kernel also got updated to use 32 random
> bits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114339
--- Comment #16 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:ab2da8fb67b1aa0557a16b62689a888730dba610
commit r14-9494-gab2da8fb67b1aa0557a16b62689a888730dba610
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114160
Christoph Müllner changed:
What|Removed |Added
CC||christophm30 at gmail dot com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114339
Jakub Jelinek changed:
What|Removed |Added
Summary|[13/14 regression] Tor |[13 regression] Tor
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #28 from Filip Kastl ---
Created attachment 57710
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57710&action=edit
gcda data for himeno
I've tried sharing non-SPEC gcda data between machines. I used this benchmark
https://ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #29 from Robin Dapp ---
Yes, that also appears to work here. There was no lto involved this time?
Now we need to figure out what's different with SPEC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114323
--- Comment #4 from Alex Coplan ---
I think the problem is that the arm backend incorrectly sets the const
attribute on this builtin, but it can't be const because it reads memory (it
should be pure instead):
sizes-gimplified unsi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108843
--- Comment #5 from David Binderman ---
Created attachment 57711
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57711&action=edit
C source code
Another test case.
foundBugs $ (ulimit -t 60; time ~/gcc/results/bin/gcc -c -w -O3 bug1023.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114323
--- Comment #5 from Christophe Lyon ---
Exactly. I have a (one-line) patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114353
Bug ID: 114353
Summary: ICE when passing LTO object files compiled for
x86_64-pc-linux-gnu to x86_64-w64-mingw32-gcc
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114349
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114349
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2024-03-15
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114286
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114320
--- Comment #2 from Nathaniel Shead ---
Sorry about that. I've not been able to work out what configure flags I need to
pass to cause this to error in the first place (I don't normally develop for
powerpc and the machine I'm using doesn't seem t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114349
--- Comment #4 from Jakub Jelinek ---
Reduced testcase:
using A = struct {};
template class, typename, typename>
using B = A;
template
using C = typename T::D;
struct E {
using D = B;
};
template constexpr bool foo (A) { return false; }
tem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114353
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Last reco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111864
--- Comment #3 from Aldy Hernandez ---
(In reply to Jeffrey A. Law from comment #2)
> It almost looks like a costing issue. The threaders find opportunities to
> thread all the incoming edges in the key block to the path which avoids the
> call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107337
Alfred Agrell changed:
What|Removed |Added
CC||blubban at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113431
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112709
Jakub Jelinek changed:
What|Removed |Added
Summary|[13/14 Regression] address |[13 Regression] address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100285
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110710
--- Comment #11 from peter0x44 at disroot dot org ---
.I did some digging into why lto-wrapper.cc is emitting these commands
It seems that they are not essential.
/* If we are not preserving the ltrans input files then
truncate them as soon a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114334
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114303
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113727
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #20 from Jeffrey A. Law ---
Go right ahead. I'm mostly trying to get things in the right broad buckets.
So if you've got additional information, please add it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112710
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112703
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114354
Bug ID: 114354
Summary: std::shared_ptr constructor constraints are checked
too late
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114354
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113431
--- Comment #21 from Richard Biener ---
(In reply to Jakub Jelinek from comment #20)
> Though, trying that in a cross to arm, with -march=armv9-a
> -munaligned-access it matches (in that case I believe vect_hw_misalign
> should be true), but it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113431
--- Comment #22 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:ffd47fb63ddc024db847daa07f8ae27fffdfcb28
commit r14-9497-gffd47fb63ddc024db847daa07f8ae27fffdfcb28
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113431
Jakub Jelinek changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108866
peter0x44 at disroot dot org changed:
What|Removed |Added
CC||peter0x44 at disroot dot o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396
--- Comment #12 from Richard Biener ---
The second testcase behaves the same with -O0, -O2 and -O3 on x86_64-linux for
me (and with trunk and GCC 13.2.1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396
--- Comment #13 from David Binderman ---
I had another look at the original source code and got this with
recent gcc trunk:
foundBugs $ ~/gcc/results/bin/gcc -w bug998.c && ./a.out
checksum = 77A231E6
foundBugs $ ~/gcc/results/bin/gcc -w -O2 b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396
--- Comment #14 from Jakub Jelinek ---
/* -O3 optimizations. */
{ OPT_LEVELS_3_PLUS, OPT_fgcse_after_reload, NULL, 1 },
{ OPT_LEVELS_3_PLUS, OPT_fipa_cp_clone, NULL, 1 },
{ OPT_LEVELS_3_PLUS, OPT_floop_interchange, NULL, 1 },
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114347
--- Comment #4 from Joseph S. Myers ---
I think it's correct that conversions (explicit or implicit) from a value with
excess precision convert only once; they don't first remove excess range and
precision and then convert to the target type.
T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114355
Bug ID: 114355
Summary: Segfault passing missing optional dummy of bind(c)
subroutine to optional assumed-rank dummy
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114355
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396
--- Comment #15 from David Binderman ---
(In reply to Jakub Jelinek from comment #14)
> So, that is -O2 -fgcse-after-reload -fipa-cp-clone -floop-interchange
> -floop-unroll-and-jam -fpeel-loops -fpredictive-commoning -fsplit-loops
> -fsplit-pat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396
--- Comment #16 from David Binderman ---
(In reply to David Binderman from comment #15)
> So it looks like one or more of the --param flags is to blame.
foundBugs $ ~/gcc/results/bin/gcc -w -O2 bug998.c && ./a.out
checksum = 77A231E6
foundBugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108866
--- Comment #8 from Pali Rohár ---
Thank you for input, as you already figured out there is lot of work for this.
And I think I'm not skilled enough to implement everything properly, so I would
have to let this to gcc developers. I will answer q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114356
Bug ID: 114356
Summary: std::shared_ptr constructor constraints give poor
diagnostics
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111571
--- Comment #4 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6r0gbwf7l@virgil.suse.cz/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114327
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:a6dab195f7041671166b9aa6a37e0db4236c829d
commit r14-9498-ga6dab195f7041671166b9aa6a37e0db4236c829d
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114327
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114329
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Eve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89567
--- Comment #7 from Eyal Rozenberg ---
(In reply to Andrew Pinski from comment #6)
> I am think this can be closed as fixed ...
Well, my example no longer generates two loads. However
> IPA-SRA does handle this if the function is static.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89567
--- Comment #8 from Andrew Pinski ---
For the non-static case, IPA-SRA has:
```
Summary for node int foo2(two_ints)/0:
Returns value
Descriptor for parameter 0:
param_size_limit: 8, size_reached: 4
* Access to unit offset: 0, unit siz
1 - 100 of 157 matches
Mail list logo
