https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628
Richard Biener changed:
What|Removed |Added
Target Milestone|14.3|14.4
--- Comment #13 from Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120237
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120237
Bug ID: 120237
Summary: /pub/gcc/infrastructure/ +
contrib/download_prerequisites: Update MPFR for C23 /
Fortran 2023 functions
Product: gcc
Version: 16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105404
--- Comment #17 from Iain Sandoe ---
(In reply to Joel Sherrill from comment #16)
> Over at RTEMS.org, we have a report from a Mac user that the gcc zlib needs
> updating or patched to build there. We are seeing this with GCC 13 but the
> versio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105404
Joel Sherrill changed:
What|Removed |Added
CC||joel at gcc dot gnu.org
--- Comment #16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117635
pietro changed:
What|Removed |Added
CC||pietro at gcc dot gnu.org
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105404
--- Comment #14 from Sam James ---
https://forge.sourceware.org/sjames/gcc/commits/branch/sam-zlib
Which we can do on the Darwin "vendor" branches, but not on the upstream
release branches.
>From that perspective, using the --with-system-zlib workaround with Xcode 16
and then supporting an update to 1.3.1 for GCC-16 would have my vote.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105404
mcccs at gmx dot com changed:
What|Removed |Added
CC||mcccs at gmx dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119676
Bug ID: 119676
Summary: [OpenMP] Move constant/kind/type documentation from
gfortran to libgomp.texi + update/add C/C++
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118921
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118921
--- Comment #2 from Andrew Pinski ---
So `#pragma GCC target` was fixed but `#pragma GCC option` was not. See PR
87299. Looks like it might be an easy fix ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118921
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2025-02-18
Status|UNCONFIR
11 20:36:17 2025 +0800
LoongArch: After setting the compilation options, update the predefined
macros.
PR target/118828
gcc/ChangeLog:
* config/loongarch/loongarch-c.cc (loongarch_pragma_target_parse):
Update the predefined macros.
gcc/testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118828
--- Comment #1 from chenglulu ---
(In reply to Xi Ruoyao from comment #0)
> Test case:
>
> /* { dg-do preprocess } */
> /* { dg-options "-mno-lasx" } */
>
> #ifdef __loongarch_asx
> #error LASX shouldn't be available here
> #endif
>
> #pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118828
Bug ID: 118828
Summary: LoongArch: #pragma GCC target should update
__loongarch_asx and similar macros
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40162
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|rguenth at gcc d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117635
--- Comment #1 from Sam James ---
I suggest that we just use up to 0859f8431242d5adff21420b9cab538d2af527b5 in
libffi.git rather than 3.4.6 to avoid having to reapply backports.
(I backported many of the commits between 3.4.6 and
0859f8431242d5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110254
Surya Kumari Jangala changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|14.2|14.3
--- Comment #12 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115531
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115531
--- Comment #6 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:0c5c0c959c2e592b84739f19ca771fa69eb8dfee
commit r15-2192-g0c5c0c959c2e592b84739f19ca771fa69eb8dfee
Author: Tamar Christina
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115531
--- Comment #5 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:af792f0226e479b165a49de5e8f9e1d16a4b26c0
commit r15-2191-gaf792f0226e479b165a49de5e8f9e1d16a4b26c0
Author: Tamar Christina
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114924
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115531
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115531
--- Comment #4 from Richard Biener ---
AVX512 produces
.L3:
vmovdqu8(%rsi), %zmm9{%k1}
kshiftrq$32, %k1, %k5
kshiftrq$48, %k1, %k4
movl%r9d, %eax
vmovdqu32 128(%rcx), %zm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115531
--- Comment #3 from Tamar Christina ---
(In reply to Andrew Pinski from comment #1)
> I suspect PR 20999 would fix this ...
> but we have to be careful since without masked stores, you could still
> vectorize this unlike the transformed version.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115531
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> Maybe ifcvt can produce a masked store version if this pattern ...
Maybe add another argument to .MASK_STORE to say it was originally
unconditional store? Or so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115531
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115531
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-06-18
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115531
Bug ID: 115531
Summary: vectorizer generates inefficient code for masked
conditional update loops
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords
Date: Fri May 3 09:23:59 2024 +0100
cfgrtl: Fix MEM_EXPR update in duplicate_insn_chain [PR114924]
The PR shows that when cfgrtl.cc:duplicate_insn_chain attempts to
update the MR_DEPENDENCE_CLIQUE information for a MEM_EXPR we can end up
accidentally dropping (e.g.) an ARRAY_REF
Date: Fri May 3 09:23:59 2024 +0100
cfgrtl: Fix MEM_EXPR update in duplicate_insn_chain [PR114924]
The PR shows that when cfgrtl.cc:duplicate_insn_chain attempts to
update the MR_DEPENDENCE_CLIQUE information for a MEM_EXPR we can end up
accidentally dropping (e.g.) an ARRAY_REF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628
Richard Biener changed:
What|Removed |Added
Target Milestone|14.0|14.2
--- Comment #11 from Richard Bien
Date: Fri May 3 09:23:59 2024 +0100
cfgrtl: Fix MEM_EXPR update in duplicate_insn_chain [PR114924]
The PR shows that when cfgrtl.cc:duplicate_insn_chain attempts to
update the MR_DEPENDENCE_CLIQUE information for a MEM_EXPR we can end up
accidentally dropping (e.g.) an ARRAY_REF
May 3 09:23:59 2024 +0100
cfgrtl: Fix MEM_EXPR update in duplicate_insn_chain [PR114924]
The PR shows that when cfgrtl.cc:duplicate_insn_chain attempts to
update the MR_DEPENDENCE_CLIQUE information for a MEM_EXPR we can end up
accidentally dropping (e.g.) an ARRAY_REF from the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114924
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.5
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114924
Alex Coplan changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot
gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114924
Bug ID: 114924
Summary: [11/12/13/14/15 Regression] Wrong update of MEM_EXPR
by RTL loop unrolling since r11-2963-gd6a05b494b4b71
Product: gcc
Version: 14.0
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78926
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114496
--- Comment #3 from Eric Gallager ---
Maybe the update could be just to clarify the "EnabledBy" rules for the
warning? i.e., something like "-Wsign-conversion is only and will only ever be
enabled by -Wconversion in C, and we wil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114496
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-03-27
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114496
--- Comment #1 from Andrew Pinski ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114496
Bug ID: 114496
Summary: Documentation: "Non-Bugs" page should update/mention
something about -Wsign-conversion
Product: gcc
Version: 13.2.0
Status: U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
the linked comment
3, which still needs to be comitted), the former is "[PATCH 0/5] OpenMP:
Array-shaping operator and strided/rectangular 'target update' support",
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629422.html
* Consider also to use a library function for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #21 from H. Peter Anvin ---
I think this could be a really useful performance improvement in general. The
Linux exception and syscall paths have a fair number of tail calls on the
primary path, and this would make it possible to avoi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #20 from H.J. Lu ---
In Linux kernel 6.7.0 on x86-64, do_exit is changed from
do_exit:
endbr64
call
push %r15
push %r14
push %r13
push %r12
mov%rdi,%r12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #19 from H. Peter Anvin ---
I'm away for the long weekend, but I'll try it out on Tuesday.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #18 from H.J. Lu ---
(In reply to H.J. Lu from comment #17)
> Please try users/hjl/pr113312/gcc-13 branch:
>
> https://gitlab.com/x86-gcc/gcc/-/tree/users/hjl/pr113312/gcc-
> 13?ref_type=heads
>
> It supports no_callee_saved_regist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #17 from H.J. Lu ---
Please try users/hjl/pr113312/gcc-13 branch:
https://gitlab.com/x86-gcc/gcc/-/tree/users/hjl/pr113312/gcc-13?ref_type=heads
It supports no_callee_saved_registers attribute. It should also avoid saving
registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #16 from H.J. Lu ---
I updated users/hjl/pr113312/master branch to handle function pointers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #15 from H. Peter Anvin ---
That should be fine for this use case, obviously.
I should add the following: the reason the assembly stub isn't a problem for
FRED whereas it is a bit of a nuisance for IDT-style delivery is that with
FR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #14 from H.J. Lu ---
Here is a branch for __attribute__((no_callee_saved_registers)):
https://gitlab.com/x86-gcc/gcc/-/commits/users/hjl/pr113312/master
Calling a function with __attribute__((no_callee_saved_registers))
doesn't wor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #13 from H. Peter Anvin ---
No, it will not. Most OSes flows will want to merge the kernel and user flows
at some point for some handlers, so it isn't clear that that makes sense.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #10 from H. Peter Anvin ---
Right, is there such an attribute (that's what I'm asking for in bug 103503)?
All I see in the gcc documentation is no_calle*R*_saved_registers, which,
again, is the exact opposite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #9 from H.J. Lu ---
(In reply to H.J. Lu from comment #8)
> (In reply to H.J. Lu from comment #7)
> > (In reply to H. Peter Anvin from comment #6)
> > > Of course. That's not what we want in the Linux kernel specifically,
> > > thou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #8 from H.J. Lu ---
(In reply to H.J. Lu from comment #7)
> (In reply to H. Peter Anvin from comment #6)
> > Of course. That's not what we want in the Linux kernel specifically, though.
> > It's really up to the OS.
>
> no_callee_sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #7 from H.J. Lu ---
(In reply to H. Peter Anvin from comment #6)
> Of course. That's not what we want in the Linux kernel specifically, though.
> It's really up to the OS.
no_callee_saved_registers attribute is sufficient. One can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #6 from H. Peter Anvin ---
Of course. That's not what we want in the Linux kernel specifically, though.
It's really up to the OS.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #5 from H.J. Lu ---
(In reply to H. Peter Anvin from comment #3)
> Created attachment 57032 [details]
> FRED assembly entry stub (example, slightly modified from the Linux kernel)
Can you do
asm_fred_entry_\type:
endbr64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #4 from H. Peter Anvin ---
(In reply to H.J. Lu from comment #2)
> (In reply to H. Peter Anvin from comment #1)
> > This is actually a specific use case of the feature requested in bug 103503.
>
> This covers #1. Should FRED handle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #3 from H. Peter Anvin ---
Created attachment 57032
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57032&action=edit
FRED assembly entry stub (example, slightly modified from the Linux kernel)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2024-01-11
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #1 from H. Peter Anvin ---
This is actually a specific use case of the feature requested in bug 103503.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
Bug ID: 113312
Summary: Update __attribute__((interrupt)) for Intel FRED
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113213
Bug ID: 113213
Summary: [OpenMP] Update omp_target_is_present /
omp_target_is_accessible handling for NULL
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111661
--- Comment #4 from Thomas Schwinge ---
Created attachment 56608
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56608&action=edit
'pr111661.c'
Before getting the Fortran case to work, let's indeed first look into some
conceptually corresp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110813
--- Comment #3 from Tobias Burnus ---
Julian's patch for this:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630996.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111661
--- Comment #3 from Patrick Bégou ---
Hi Tobias,
thanks for this information.
- yes removing the "finalize" make this small test case working. In my
mind it should only remove the allocated attribute from the GPU with
setting the count to zer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111661
--- Comment #2 from Tobias Burnus ---
@Patrick: It seems to work fine without "finalize".
Can you check whether the big program then works for you?
Usually, one should be able to do proper ref counting such that a
'finalize' -> force setting r
data delete(tab%val) finalize
deallocate(tab%val)
allocate(tab%val(n,m))
tab%dim1=n
tab%dim2=m
!$acc update device(tab)
!$acc enter data create(tab%val)
Unfortunatly, as soon as the user defined type contains more that one
allocatable attribute and only one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111547
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: Tue Sep 26 10:07:26 2023 +0200
invoke.texi: Update -fopenmp and -fopenmp-simd for omp::decl and loop
semantic
gcc/ChangeLog:
PR middle-end/111547
* doc/invoke.texi (-fopenmp): Mention C++11 [[omp::decl(...)]]
syntax.
(-fopenmp-simd): Likewise. Clarify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111547
Bug ID: 111547
Summary: [OpenMP] -fopenmp omp::decl update missing
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628
--- Comment #10 from Hans-Peter Nilsson ---
(In reply to Hans-Peter Nilsson from comment #9)
> (In reply to Jan Hubicka from comment #8)
> > patch posted
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628231.html
>
> Yay! I stand re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628
--- Comment #9 from Hans-Peter Nilsson ---
(In reply to Jan Hubicka from comment #8)
> patch posted
> https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628231.html
Yay! I stand ready to revert my ugly cover-up.
I'll even give the posted pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628
--- Comment #8 from Jan Hubicka ---
patch posted
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628231.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628
--- Comment #7 from Hans-Peter Nilsson ---
(In reply to Hans-Peter Nilsson from comment #5)
> Not seeing any action for this regression for three weeks, for tracking
> purposes I'm considering xfailing this test-case for cris-* after another
> w
BLE, VISITED)
;;pred: 2 [34.0% (guessed)] count:365072224 (estimated locally, freq
0.3400) (FALSE_VALUE,EXECUTABLE)
return;
So it combines two conditionals together but does not update the
outgoing probabilitis of the conditional.
On x86-64 we have already in cfg dump:
_1 = x != 20
Jangala
Date: Mon Aug 14 09:34:56 2023 -0500
ira: update allocated_hardreg_p[] in improve_allocation() [PR110254]
The improve_allocation() routine does not update the
allocated_hardreg_p[] array after an allocno is assigned a register.
If the register chosen in improve_allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110813
--- Comment #2 from Tobias Burnus ---
CUDA for memcpy2d/memcpy3d (quote from plugin-nvptx.c):
/* TODO: Consider using CU_MEMORYTYPE_UNIFIED if supported. */
Or is this unreachable due to omp_target_memcpy_check's NULL
setting of the devi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110813
--- Comment #1 from Tobias Burnus ---
Consider also to use a library function for *inter*-device copy if the device
type or the function pointer is the same.
(If unsupported, the function can still return "-1" to skip to the fallback
code.)
Fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110813
Bug ID: 110813
Summary: [OpenMP] omp_target_memcpy_rect (+ strided 'target
update'): Improve GCN performance and contiguous
subranges
Product: gcc
Ver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628
--- Comment #4 from seurer at gcc dot gnu.org ---
Created attachment 55563
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55563&action=edit
All the intermediate files in a .tar.gz
Here are all the files zipped up.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628
--- Comment #3 from Jan Hubicka ---
> -fdump-tree-all-blocks-details produced more than 100 dump files. Which
> one(s)
> do you want?
Can you just zip them an attach all?
Thank you!
Honza
/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/tree-ssa/update-threading.c
-fdiagnostics-plain-output -O2 -S -o update-threading.s
-fdump-tree-all-blocks-details
seurer@ltcden2-lp1:~/gcc/git/build/gcc-test$ ls update-threading.*
update-threading.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628
--- Comment #1 from Jan Hubicka ---
The testcase was, for many years, not checking what it was intended to since
Invalid sums are now output only with ...-details-blocks dumps and not by
default.
It passes for me. Can you please attach -fdump-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628
Richard Biener changed:
What|Removed |Added
Keywords||testsuite-fail
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628
Bug ID: 110628
Summary: [14 regression] gcc.dg/tree-ssa/update-threading.c
fails after r14-2383-g768f00e3e84123
Product: gcc
Version: 14.0
Status: UNCONFIRMED
represents a register pair or larger, you'll need to update multiple
allocated_hardreg_p[] entries.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110254
--- Comment #1 from Segher Boessenkool ---
Off topic / pet peeve: it's not an array of functions, so it should not be
called
something_p .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110254
Bug ID: 110254
Summary: improve_allocation() routine does not update
allocated_hardreg_p[] array
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110178
Thomas Schwinge changed:
What|Removed |Added
Target|powerpc64le-linux-gnu |
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110178
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110178
Bug ID: 110178
Summary: [14 regression] gfortran.dg/gomp/target-update-1.f90
fails after r14-1579-g4ede915d5dde93
Product: gcc
Version: 14.0
Status: UNCONFIRMED
1 - 100 of 788 matches
Mail list logo
