https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #24 from Richard Biener ---
(In reply to chenglulu from comment #23)
> (In reply to GCC Commits from comment #22)
> > The master branch has been updated by Jerry DeLisle :
> >
> > https://gcc.gnu.org/g:93adf88cc6744aa2c732b765e1e3b9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #25 from Richard Biener ---
(t_initf) Read in prof_inparm namelist from: drv_in
(shr_sys_abort) ERROR: (T_INITF) :: namelist read returns an error condition
for prof_inparm
(shr_sys_abort) WARNING: calling mpi_abort() and stopping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114629
Pierre-Emmanuel Patry changed:
What|Removed |Added
CC||pierre-emmanuel.patry@embec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114621
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #26 from Richard Biener ---
Created attachment 57895
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57895&action=edit
drv_in input file
This is the complete input file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #27 from Richard Biener ---
And find_group_name does
ios = 0
do while (ios <= 0)
read(unit, '(a)', iostat=ios, end=102) inrec
...
inrec2 = to_lower(adjustl(inrec))
! check for leading '&'
if (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113288
Hongtao Liu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114619
Richard Biener changed:
What|Removed |Added
Keywords||ice-checking,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114621
Jakub Jelinek changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66862
Hongtao Liu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114622
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114624
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #28 from Tobias Burnus ---
Created attachment 57896
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57896&action=edit
Testcase
It seems as if 'tabs' cause problems, e.g. for:
profile_single_file= .true.
where the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114623
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114627
Richard Biener changed:
What|Removed |Added
Summary|[14 Regression] undefined |undefined behavior in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114629
--- Comment #3 from Richard Biener ---
is that part of the language standard? I don't think we have to copy rustc
easter eggs - in fact I'd report this as a bug to them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114633
Bug ID: 114633
Summary: [14 Regression] A cross to rx fails to build in
libstdc++
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114633
Richard Biener changed:
What|Removed |Added
Target||rx-elf
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
--- Comment #18 from Nicolas Boulenguez ---
Created attachment 57897
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57897&action=edit
rewrite commit 3/8 so that Duration'Size may be 32
Would version 4 of commit 3/8 be OK? It only modifies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112868
--- Comment #10 from Sam James ---
No problems reported yet and we have several people testing on ppc w/ gcc 14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114634
Bug ID: 114634
Summary: Crash Issue Encountered in GCC Compilation of Template
Code with Aligned Attribute
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114634
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-04-08
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #72 from Sam James ---
It's up to RMs of course but FWIW, the critical part of this for me is fixed
now and it could be a P2 now if desired.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #29 from rguenther at suse dot de ---
On Mon, 8 Apr 2024, burnus at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
>
> --- Comment #28 from Tobias Burnus ---
> Created attachment 57896
> --> https:/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114624
--- Comment #4 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:97d5cd8740384dbce5a83080916388f80d8976dd
commit r14-9829-g97d5cd8740384dbce5a83080916388f80d8976dd
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
Richard Biener changed:
What|Removed |Added
Priority|P1 |P2
--- Comment #73 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114624
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114501
Sam James changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #8 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114629
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #4 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
--- Comment #22 from Richard Biener ---
Note we're using -Wl,--stack,12582912 when linking the GCC executables, I
wonder
if the reporter can verify the segfaulting executables have the correct stack
size set?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114604
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114501
Richard Biener changed:
What|Removed |Added
Version|14.0|13.2.0
Priority|P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
--- Comment #23 from Douglas Boffey ---
(In reply to Richard Biener from comment #22)
> Note we're using -Wl,--stack,12582912 when linking the GCC executables, I
> wonder
> if the reporter can verify the segfaulting executables have the correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531
Rama Malladi changed:
What|Removed |Added
CC||rvmallad at amazon dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
--- Comment #24 from rguenther at suse dot de ---
On Mon, 8 Apr 2024, douglas.boffey at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
>
> --- Comment #23 from Douglas Boffey ---
> (In reply to Richard Biener from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
Bug ID: 114635
Summary: OpenMP reductions fail dependency analysis
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84568
--- Comment #16 from Jonathan Wakely ---
It's a shame the fix happened after the inferior shared_ptr implementation was
frozen into libstdc++ though :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #30 from Tobias Burnus ---
(In reply to rguent...@suse.de from comment #29)
> Might be for \r\n line endings?
New lines are handled slightly differently – and \f and \v don't seem to be
handled at all.
Comparing the result with ifo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53341
--- Comment #3 from Jonathan Wakely ---
Bisections indicates it was fixed by this commit:
commit ead84f73b0a0f39ea39aa0329b6da83e4a9e6e02 [r0-116315-gead84f73b0a0f3]
Author: Jan Hubicka
Date: Fri Apr 20 15:09:11 2012
lto-symtab.c (lto_cgr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114633
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114636
Bug ID: 114636
Summary: Actual does not match formal in generic instantiation
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114637
Bug ID: 114637
Summary: Problems when compiling with both undefined and
address sanitizer
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114615
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #2 from Jonath
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114615
--- Comment #3 from Jonathan Wakely ---
The dumb part is that __n here comes from wcslen(__s2), so the compiler is able
to track that __s2 is only two bytes, but not capable of tracking that __n ==
0.
Specifically, __n is (__s2 + wcslen(__s2))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
Vladimir Terzi changed:
What|Removed |Added
CC||vterzi1996 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114633
--- Comment #2 from Richard Biener ---
That makes the build succeed!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114623
--- Comment #6 from Jakub Jelinek ---
(In reply to g.peterhoff from comment #4)
> That is precisely the design error of C/C++/etc. There should be no
> float/double/long double/__float128/etc, but *only* floatN_t.
If you don't want to use float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114623
--- Comment #7 from Jakub Jelinek ---
Created attachment 57900
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57900&action=edit
gcc14-pr114623.patch
Anyway, here is an untested patch to use soft-fp implementation for sqrtq for
the positiv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114637
--- Comment #1 from teodor_spaeren at riseup dot net ---
Just to clearify here, the error only occurs when
`-fsanitize=undefined,address` are used together. Either alone works just fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #1 from Richard Biener ---
Note even -fopenmp-simd would likely fail if you remove the #if _OPENMP check.
-fopenmp-simd doesn't define _OPENMP, only -fopenmp does.
It seems to work on x86_64 but we get a "scalar" epilog somehow.
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114638
Bug ID: 114638
Summary: Hang and Memory Consumption Increase during
Compilation with Recursive Template Instantiation
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113986
Wilco changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
Richard Biener changed:
What|Removed |Added
Keywords||openmp
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639
Bug ID: 114639
Summary: [riscv] ICE in create_pre_exit, at
mode-switching.cc:451
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #4 from Jakub Jelinek ---
The OpenMP safelen clause argument is a scalar integer, so using poly_int for
something that must be an int doesn't make sense.
Though, the above testcase actually doesn't use safelen clause, so safelen is
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
--- Comment #25 from Douglas Boffey ---
(In reply to rguent...@suse.de from comment #24)
> dumpbin /headers executable.exe
...
C0 size of stack reserve
1000 size of stack commit
...
Hope this helps.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #5 from Jakub Jelinek ---
(In reply to Richard Biener from comment #3)
> As for the dependence analysis itself - the issue is that the D.5606[_33]
> style accesses have no access functions - I'm not sure how they evolve,
> but I see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114638
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
--- Comment #26 from rguenther at suse dot de ---
On Mon, 8 Apr 2024, douglas.boffey at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
>
> --- Comment #25 from Douglas Boffey ---
> (In reply to rguent...@suse.de fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.4
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114640
Bug ID: 114640
Summary: ICE on 'elsif' with complex function call
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
Richard Biener changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #28 from R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114640
--- Comment #1 from simon at pushface dot org ---
It turns out that the error does not occur if I change
if First_Term = Invalid_Node_Access then
-- Empty or all virtual
return Invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114061
Victor Do Nascimento changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |victorldn at gcc dot
gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114630
Patrick Palka changed:
What|Removed |Added
Last reconfirmed||2024-04-08
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114628
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114628
--- Comment #3 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #1)
> Note we get 2 difference ICEs depending on if `#if ` is 1 or 0.
> It seems like it would be useful if some more torture tests for _BitInt were
> included so `-g`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114605
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:d5d84487dec06186fd9246b505f44ef68a66d6a2
commit r14-9834-gd5d84487dec06186fd9246b505f44ef68a66d6a2
Author: Jakub Jelinek
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114605
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #6 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #4)
> Now, with SVE/RISCV vectors the actual vectorization factor is a poly_int
> rather than constant. One possibility would be to use VLA arrays in those
> cases,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114588
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114641
Bug ID: 114641
Summary: sh: fdpic optimization of function address breaks
pointer equality
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
--- Comment #7 from rguenther at suse dot de ---
> Am 08.04.2024 um 16:55 schrieb tnfchris at gcc dot gnu.org
> :
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635
>
> --- Comment #6 from Tamar Christina ---
> (In reply to Jakub Jelin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114642
Bug ID: 114642
Summary: new test case gcc.dg/debug/btf/btf-datasec-3.c from
r14-6195-gb8cf266f4ca4ff fails for 32 bits
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114637
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Statu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
Xi Ruoyao changed:
What|Removed |Added
CC||teodor_spaeren at riseup dot
net
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108007
--- Comment #23 from GCC Commits ---
The releases/gcc-13 branch has been updated by Martin Jambor
:
https://gcc.gnu.org/g:40ddc0b05a47f999b24f20c1becb79004995731b
commit r13-8594-g40ddc0b05a47f999b24f20c1becb79004995731b
Author: Martin Jambor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113757
--- Comment #11 from GCC Commits ---
The releases/gcc-13 branch has been updated by Martin Jambor
:
https://gcc.gnu.org/g:40ddc0b05a47f999b24f20c1becb79004995731b
commit r13-8594-g40ddc0b05a47f999b24f20c1becb79004995731b
Author: Martin Jambor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112616
--- Comment #9 from GCC Commits ---
The releases/gcc-13 branch has been updated by Martin Jambor
:
https://gcc.gnu.org/g:40ddc0b05a47f999b24f20c1becb79004995731b
commit r13-8594-g40ddc0b05a47f999b24f20c1becb79004995731b
Author: Martin Jambor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114607
--- Comment #1 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:2c1c2485a4b1aca746ac693041e51ea6da5c64ca
commit r14-9836-g2c1c2485a4b1aca746ac693041e51ea6da5c64ca
Author: Richard Sandiford
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114607
--- Comment #2 from Richard Sandiford ---
Fixed on trunk. I'll backport in a few weeks if there's no fallout.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113006
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114519
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:feb6a2d3569095706170c9400e93add27a66e034
commit r14-9839-gfeb6a2d3569095706170c9400e93add27a66e034
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #74 from GCC Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:1162861439fd3c4b30fc3ccd49462e47e876f04a
commit r14-9840-g1162861439fd3c4b30fc3ccd49462e47e876f04a
Author: Martin Jambor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #25 from GCC Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:1e3312a25a7b34d6e3f549273e1674c7114e4408
commit r14-9841-g1e3312a25a7b34d6e3f549273e1674c7114e4408
Author: Martin Jambor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #26 from Martin Jambor ---
This should be fixed on master, I'll backport the fix in a few weeks to at
least gcc-13 where it was reported.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
Jakub Jelinek changed:
What|Removed |Added
Summary|[13/14 Regression] LTO |[13 Regression] LTO
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #75 from Martin Jambor ---
The above fixes the testcase from comment #58. I am not sure if any other
testcases discussed here remain unresolved. I am also not sure to what extent
we want to that patch of mine, I guess I'll re-visit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114643
Bug ID: 114643
Summary: Call to a template function emitted but without the
code for the template function itself
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114643
--- Comment #1 from Andrew Pinski ---
This is a devirtualization issue ...
Let me find the dup.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114643
Andrew Pinski changed:
What|Removed |Added
Depends on||62051
--- Comment #2 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114621
--- Comment #4 from Jakub Jelinek ---
char a;
__thread char b[0x8L];
int
foo (void)
{
return b[0x7L];
}
ICEs similarly with -O0 -fpie.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114621
--- Comment #5 from Jakub Jelinek ---
While for the local exec we happily use something like
movq%fs:0, %rax
movabsq $b@tpoff+34359738367, %rdx
addq%rdx, %rax
movzbl (%rax), %eax
we normally use instructi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114639
--- Comment #2 from Andrew Pinski ---
/* If we didn't see a full return value copy, verify that there
is a plausible reason for this. If some, but not all of the
return register is likely spilled, we ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548
--- Comment #10 from qinzhao at gcc dot gnu.org ---
Clang has accept this extension:
https://github.com/llvm/llvm-project/pull/84428
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77882
Nick Desaulniers changed:
What|Removed |Added
CC||ndesaulniers at google dot com
--- Co
1 - 100 of 237 matches
Mail list logo