https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114895
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114456
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:bd35a92f8d44e91c96e8b6f01805fe4a68acf9eb
commit r15-61-gbd35a92f8d44e91c96e8b6f01805fe4a68acf9eb
Author: Jakub Jelinek
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114895
Bug ID: 114895
Summary: Build failure with !HAVE_WORKING_STAT
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114388
--- Comment #10 from Jiang An ---
Broken down into two smaller examples:
https://godbolt.org/z/YhK7PqE6s
```
#include
#include
int main() {
struct B {
B() {}
virtual ~B() { std::puts("C++11"); }
};
struct C { B b; };
typeid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734
Richard Biener changed:
What|Removed |Added
Known to work||15.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734
--- Comment #12 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:4d3a5618de5a949c61605f545f90e81bc502
commit r15-60-g4d3a5618de5a949c61605f545f90e81bc502
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114874
--- Comment #5 from Paul Thomas ---
(In reply to Paul Thomas from comment #4)
> (In reply to anlauf from comment #3)
> > Adding Paul, hoping that he can tell what changed for SELECT TYPE recently.
>
When c is an array, it compiles and runs fin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105320
--- Comment #4 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:b5f6a56940e70838a07e885de03a92e2bd64674a
commit r15-59-gb5f6a56940e70838a07e885de03a92e2bd64674a
Author: Nathaniel Shead
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114275
--- Comment #6 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:b5f6a56940e70838a07e885de03a92e2bd64674a
commit r15-59-gb5f6a56940e70838a07e885de03a92e2bd64674a
Author: Nathaniel Shead
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114894
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114894
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-04-30
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114894
Bug ID: 114894
Summary: `a == 0 ? 0 : a * b` -> `a * b` likewise for `a & b`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114893
Bug ID: 114893
Summary: -Wanalyzer-null-dereference false positive in Emacs
select_window
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114892
--- Comment #1 from Andrew Pinski ---
I should note I found this while helping a junior engineer and we went looking
for the documentation and it was not there for it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114892
Bug ID: 114892
Summary: folding and others dump options are not documented
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114891
--- Comment #1 from Andrew Pinski ---
So a C++23 library header (generator) is using a C++20 feature
(is_pointer_interconvertible_base_of_v) ...
Especially since GCC 14.1.0 will most likely be released with this header and
14.2.0 won't come out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114891
Bug ID: 114891
Summary: Unconditional use of
std::is_pointer_interconvertible_base_of_v in
makes the header unusable with Clang 18
Product: gcc
Version: 15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114873
--- Comment #5 from Halalaluyafail3 ---
(In reply to Joseph S. Myers from comment #4)
> These are not meant to be valid C (although the relevant requirement isn't a
> Constraint, so a diagnostic isn't required); see the discussion in DR#341.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114889
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |14.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114889
--- Comment #1 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:22b20ac6c6aead2d3f36c413a77dd0b80adfec39
commit r15-57-g22b20ac6c6aead2d3f36c413a77dd0b80adfec39
Author: Patrick Palka
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114888
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114888
--- Comment #8 from GCC Commits ---
The releases/gcc-14 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:3c925ac349b03ae9439c632fb1c042cdc8d78f40
commit r14-10149-g3c925ac349b03ae9439c632fb1c042cdc8d78f40
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114848
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114888
--- Comment #7 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:3900e944b0ac9db77380c5bb8635977dfd3b0691
commit r15-56-g3900e944b0ac9db77380c5bb8635977dfd3b0691
Author: Patrick Palka
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114848
--- Comment #7 from GCC Commits ---
The releases/gcc-13 branch has been updated by LuluCheng
:
https://gcc.gnu.org/g:88f22217521564e1a956e14ac55456caa160e055
commit r13-8661-g88f22217521564e1a956e14ac55456caa160e055
Author: Yang Yujie
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114848
--- Comment #6 from GCC Commits ---
The releases/gcc-12 branch has been updated by LuluCheng
:
https://gcc.gnu.org/g:bb78099d2624b52c781ed6e5d85e43d54c3cda1a
commit r12-10403-gbb78099d2624b52c781ed6e5d85e43d54c3cda1a
Author: Yang Yujie
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114883
--- Comment #10 from Hongtao Liu ---
(In reply to Jakub Jelinek from comment #9)
> Created attachment 58073 [details]
> gcc14-pr114883.patch
>
> Full untested patch.
This will fix 521.wrf_r ICE, and pass runtime validation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114874
Paul Thomas changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114873
--- Comment #4 from Joseph S. Myers ---
These are not meant to be valid C (although the relevant requirement isn't a
Constraint, so a diagnostic isn't required); see the discussion in DR#341.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114869
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=114869
Joseph S. Myers changed:
What|Removed |Added
Last reconfirmed||2024-04-29
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114874
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114874
--- Comment #2 from anlauf at gcc dot gnu.org ---
The dump-fortran-original shows the following difference between 13 and 14:
@@ -58,7 +58,7 @@
code:
ASSIGN p:c 'abc'
- BLOCK
+ SELECT TYPE
symtree: '__tmp_CHARACTER_0_1'|| symbol:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872
--- Comment #7 from Antonio Rojas ---
(In reply to Sam James from comment #5)
> Some ideas:
> * Could you maybe give a reproducer for the runtime crash?
In sage, calling any libgap function in exactly 3 parameters triggers this. For
instance:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #17 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114883
--- Comment #9 from Jakub Jelinek ---
Created attachment 58073
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58073&action=edit
gcc14-pr114883.patch
Full untested patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106813
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106813
--- Comment #3 from GCC Commits ---
The master branch has been updated by Ian Lance Taylor :
https://gcc.gnu.org/g:a05efc8bf5ed329ea7d9b1740c326bdc6b04e37a
commit r15-53-ga05efc8bf5ed329ea7d9b1740c326bdc6b04e37a
Author: Ian Lance Taylor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827
--- Comment #11 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2024-April/060464.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114875
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114883
--- Comment #8 from Jakub Jelinek ---
Just changing the min in the testcase to max results on ICE with IFN_COND_MAX.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114883
--- Comment #7 from Jakub Jelinek ---
Slightly more reduced testcase:
subroutine pr114883(a, b, c, d, e, f, g, h, o)
real(8) :: c(1011), d(1011), e(0:1011)
real(8) :: p, q, f, r, g(1011), h(1011), b, bar
integer :: o(100), a, t, u
p = 0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114883
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #31 from Jakub Jelinek ---
Seems most of the V4BI/V8BImode predicates are in UNSPECs, I think long term
turning them into just using there V16BImode might help.
Keep using V4BI/V8BImode for cases where we know it is all 0 or all 1 bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #30 from Christophe Lyon ---
> ./cc1 -quiet -isystem include/ -march=armv8.1-m.main+mve -mfloat-abi=hard
> pr114801.c -mthumb -O2 -da
Thanks, for some reason -O2 had disappeared from my flags, it does ICE with it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #29 from Jakub Jelinek ---
With
--- a/gcc/config/arm/arm-mve-builtins.cc
+++ b/gcc/config/arm/arm-mve-builtins.cc
@@ -2100,7 +2100,22 @@ function_expander::add_input_operand (insn_code icode,
rtx x)
mode = GET_MODE (x);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #28 from Jakub Jelinek ---
#include
uint32x4_t test_9() {
return vdupq_m_n_u32(vdupq_n_u32(0x), 0, 0x);
}
./cc1 -quiet -isystem include/ -march=armv8.1-m.main+mve -mfloat-abi=hard
pr114801.c -mthumb -O2 -da
during RT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #27 from Christophe Lyon ---
(In reply to Jakub Jelinek from comment #25)
>
> Indeed, it ICEs e.g. during CSE.
> Though, that also means it is just about luck, if something isn't a
> CONST_INT at expansion time but simplified into C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872
--- Comment #6 from Jakub Jelinek ---
I have looked at the IL and I don't see how it could crash that way based on
the -fdump-tree-optimized-lineno dump, neither on branch nor on the trunk.
On the branch, I see
[local count: 462566023]:
[el
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #26 from Christophe Lyon ---
Thanks for testing, my build is still in progress.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872
--- Comment #5 from Sam James ---
Some ideas:
* Could you maybe give a reproducer for the runtime crash?
* Any chance you'd be willing to try bisect element.i with pragmas to
disable/enable optimisation for chunks of it, to find the miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #25 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #24)
> Another short term (14.1 only) possibility would be to force_reg a CONST_INT
> operand into a register if it didn't have all bits the same (and hope
> combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #24 from Jakub Jelinek ---
Another short term (14.1 only) possibility would be to force_reg a CONST_INT
operand into a register if it didn't have all bits the same (and hope combine
or whatever else won't simplify it again), i.e.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114885
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114506
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112397
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114888
--- Comment #6 from Patrick Palka ---
Yeah I think the TREE_TYPE of a compound type should never be null, at least as
far as type dependence is concerned.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036
--- Comment #8 from GCC Commits ---
The releases/gcc-11 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:5feeb2ddc93de85dffd7d52119189cd63bccd40f
commit r11-11405-g5feeb2ddc93de85dffd7d52119189cd63bccd40f
Author: Iain Sandoe
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112397
--- Comment #14 from GCC Commits ---
The releases/gcc-11 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:8c19cb9c6186b65f1858c91d423238a00ffe0c01
commit r11-11403-g8c19cb9c6186b65f1858c91d423238a00ffe0c01
Author: Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034
--- Comment #7 from GCC Commits ---
The releases/gcc-11 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:241e10972c916540a085054a1a858c5b2ce82a5a
commit r11-11406-g241e10972c916540a085054a1a858c5b2ce82a5a
Author: Iain Sandoe
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
--- Comment #13 from GCC Commits ---
The releases/gcc-11 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:729170a45040e96d567be79bda00604a7645a23d
commit r11-11402-g729170a45040e96d567be79bda00604a7645a23d
Author: Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114888
--- Comment #5 from Jakub Jelinek ---
Though, I think both build_pointer_type and build_reference_type would segfault
if it was called on NULL_TREE to_type, and I don't see any spot in the FE that
would create pointer/reference types without tho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114888
--- Comment #4 from Jakub Jelinek ---
(In reply to Patrick Palka from comment #3)
> Seems we're missing a dependence check in the sizeof / sizeof code:
>
> diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
> index e5a52dc2b39..284f6e29e36 100644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #23 from Jakub Jelinek ---
(In reply to Christophe Lyon from comment #22)
> Sure, that's what I'm worried about.
>
> So we can:
> - leave this as-is for gcc-14 (known bug)
>
> - commit what we discussed in #c15 #c16, (with an impro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114888
Patrick Palka changed:
What|Removed |Added
Summary|[14 Regression] ICE when|[14/15 Regression] ICE when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #22 from Christophe Lyon ---
Sure, that's what I'm worried about.
So we can:
- leave this as-is for gcc-14 (known bug)
- commit what we discussed in #c15 #c16, (with an improved testcase as you
mentioned on the list,) thus at least
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111234
Kito Cheng changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111234
--- Comment #5 from GCC Commits ---
The releases/gcc-13 branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:129b64b0c2766d66d97be68a36f7d72685a9d29e
commit r13-8659-g129b64b0c2766d66d97be68a36f7d72685a9d29e
Author: Lehua Ding
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114888
Jakub Jelinek changed:
What|Removed |Added
Summary|ICE when cross compiling|[14 Regression] ICE when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #21 from Jakub Jelinek ---
I mean if you represent it incorrectly, there are very high changes that
simplify-rtx.cc will screw this up, because it certainly doesn't understand
what a MODE_VECTOR_BOOL mode with elements other than 0/1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #20 from Jakub Jelinek ---
Pretending a boolean mode has non-boolean value is invalid RTL (or GIMPLE).
So, the rtx-vector-builder.cc change looks wrong to me.
If you want to handle the predicate elements with element values other tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114890
Wilco changed:
What|Removed |Added
Target Milestone|--- |15.0
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114890
Bug ID: 114890
Summary: [14/15 Regression] Big-endian addp intrinsics reorder
operands
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #19 from Christophe Lyon ---
So basically values such as 0x are not UB and we want to accept them.
I tested:
diff --git a/gcc/rtx-vector-builder.cc b/gcc/rtx-vector-builder.cc
index 9509d9fc453..f89aa717903 100644
--- a/gcc/rtx-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114888
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114889
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114889
Bug ID: 114889
Summary: [modules] ICE in friend_accessible_p with imported
class template specialization befriending class
template
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114887
--- Comment #2 from JuzheZhong ---
I think there is a too conservative analysis here:
note: _1: type = float, start = 1, end = 6
note: _5: type = float, start = 6, end = 8
note: _3: type = float, start = 3, end = 7
note: _4: type = floa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114887
--- Comment #1 from JuzheZhong ---
The "vect" cost model analysis:
https://godbolt.org/z/qbqzon8x1
note: Maximum lmul = 8, At most 40 number of live V_REG at program point 6
for bb 3
It seems that we count one more variable in program point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114849
--- Comment #6 from Manjunath Bhavimani ---
Created attachment 58072
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58072&action=edit
compiler version comparison
Please find attached file where you can find the details for compiler versio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114888
Bug ID: 114888
Summary: ICE when cross compiling binutils
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114849
--- Comment #5 from Manjunath Bhavimani ---
Created attachment 58070
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58070&action=edit
Command to build .asm .o .elf
Please find attached make file for build command
Reading specs from /usr/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #18 from avieira at gcc dot gnu.org ---
Sorry to be clear, the 'here' in the last sentence refers to supporting masks
as 0x to control the writing of the output register as the ISA allows,
rather than interpret 0x and 0x a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
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=114506
--- Comment #5 from GCC Commits ---
The master branch has been updated by Demin Han :
https://gcc.gnu.org/g:ca2f531cc5db4f1020d4329976610356033e0246
commit r15-47-gca2f531cc5db4f1020d4329976610356033e0246
Author: demin.han
Date: Tue Mar 26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114876
--- Comment #4 from Bruno Haible ---
(In reply to Jakub Jelinek from comment #3)
> Given that there are or at least were implementations which
> emitted no characters
Yes, musl libc emits/emitted 0 characters in this case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859
--- Comment #16 from Paul Thomas ---
Hi Jakub,
It's good news that the patch does indeed fix the full problem.
I committed to 15-branch with corrections to the ChangeLogs, as requested by
Mikael. What both of us missed was that I screwed up in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114876
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2024-04-29
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114887
Bug ID: 114887
Summary: RISC-V: expect M8 but M4 generated with dynamic LMUL
for TSVC s319
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114886
--- Comment #1 from Rainer Orth ---
Created attachment 58068
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58068&action=edit
Hack to identify places that reduce timeouts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114886
Bug ID: 114886
Summary: gm2 testsuite arbitrarily reduces timeouts
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859
--- Comment #15 from Jakub Jelinek ---
(In reply to Paul Thomas from comment #14)
> Created attachment 58063 [details]
> Fix for this PR
The patch bootstrapped/regtested on x86_64-linux fine in an rpm build and
amg4psblas-1.1.2 built with it fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114846
--- Comment #5 from Kewen Lin ---
Created attachment 58067
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58067&action=edit
untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113535
--- Comment #1 from Kewen Lin ---
One issue: https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650171.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114883
--- Comment #5 from Hongtao Liu ---
(In reply to Hongtao Liu from comment #4)
> diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
> index a6cf0a5546c..ae6abe00f3e 100644
> --- a/gcc/tree-vect-loop.cc
> +++ b/gcc/tree-vect-loop.cc
> @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114883
--- Comment #4 from Hongtao Liu ---
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index a6cf0a5546c..ae6abe00f3e 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -8505,7 +8505,8 @@ vect_transform_reduction (loop_vec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114885
--- Comment #3 from GCC Commits ---
The releases/gcc-14 branch has been updated by Pan Li :
https://gcc.gnu.org/g:d40073be96ea24c7eace7141c4e0fed50077d2b0
commit r14-10145-gd40073be96ea24c7eace7141c4e0fed50077d2b0
Author: Pan Li
Date: Sat A
1 - 100 of 102 matches
Mail list logo
