https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114876
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2024-04-29
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859
--- Comment #12 from Jakub Jelinek ---
There is still time, probably until Tuesday morning, so if it is committed say
by Monday to trunk, it can be cherry-picked then. I'd prefer to see the whole
patch before acking it for 14.1, possibly even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #15 from Jakub Jelinek ---
https://developer.arm.com/documentation/101028/0012/14--M-profile-Vector-Extension--MVE--intrinsics
suggests that it is a UB if all the bits for a single element aren't the same
(i.e. false is all 0s, true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859
--- Comment #10 from Jakub Jelinek ---
Ah, the following shows what is happening and shows similar IL changes in the
*.optimized dump:
module m1
type amg_d_base_solver_type
contains
procedure, pass(sv) :: free => amg_d_base_solver_free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859
--- Comment #9 from Jakub Jelinek ---
I see there roughly
module m1
type amg_d_base_solver_type
contains
procedure, pass(sv) :: apply_v => amg_d_base_solver_apply_vect
procedure, pass(sv) :: apply_a => amg_d_base_solver_apply
end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #13 from Jakub Jelinek ---
(In reply to Christophe Lyon from comment #12)
> (In reply to Jakub Jelinek from comment #11)
> > So, tried this under the debugger. All VALID_MVE_PRED_MODE modes have the
> > same size, 2 bytes, so I'd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859
--- Comment #8 from Jakub Jelinek ---
The upstream sources are:
https://github.com/sfilippone/amg4psblas/archive/refs/tags/v1.1.2.tar.gz
https://github.com/sfilippone/psblas3/archive/refs/tags/v3.8.1-2.tar.gz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859
--- Comment #7 from Jakub Jelinek ---
Created attachment 58047
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58047=edit
pr114859-1.tar.xz
Another module.
Unfortunately, the last module is too large for the 1M limit.
It can be grabbed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859
--- Comment #6 from Jakub Jelinek ---
Created attachment 58046
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58046=edit
pr114859.tar.xz
Testcase + one module.
I was using
./f951 -quiet -I . amg_d_hierarchy_bld.f90 -m64 -march=x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859
--- Comment #4 from Jakub Jelinek ---
LTO doesn't seem to make a difference. And without LTO bisection points at
openmpi-build/amgprec/impl/amg_d_hierarchy_bld.o
when this is compiled with r14-9704 even when all other sources are compiled
with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #11 from Jakub Jelinek ---
So, tried this under the debugger. All VALID_MVE_PRED_MODE modes have the same
size, 2 bytes, so I'd go with
else if (VALID_MVE_PRED_MODE (mode))
{
/* unsigned short arguments to functions get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #10 from Jakub Jelinek ---
(mode == HImode || mode == V16BImode) could be GET_MODE_SIZE (mode) == 2 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #9 from Jakub Jelinek ---
(In reply to Christophe Lyon from comment #7)
> This fails because down the call chain from lowpart_subreg, we reach
> gcc_unreachable in rtx_vector_builder::find_cached_value because m_mode ==
> V4BImode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #6 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #5)
> So (completely untested):
> --- gcc/config/arm/arm-mve-builtins.cc.jj 2024-03-19 09:51:05.203631194
> +0100
> +++ gcc/config/arm/arm-mve-builtins.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #5 from Jakub Jelinek ---
Guess the primary question is why there is the gen_lowpart call at all.
Is it that normally the mode of x is already right due to the prototypes of the
builtins, with the exception that gcc likes to promote
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #4 from Jakub Jelinek ---
(In reply to Christophe Lyon from comment #3)
> lowpart_subreg does not work either.
>
> If we put the predicates in a variable in the testcase, then in
> function_expander::add_input_operand() x is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114456
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113867
Jakub Jelinek changed:
What|Removed |Added
Priority|P1 |P2
--- Comment #6 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724
Jakub Jelinek changed:
What|Removed |Added
Priority|P1 |P2
--- Comment #10 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859
--- Comment #3 from Jakub Jelinek ---
Oh, and start by disabling LTO and see if it makes a difference.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859
--- Comment #2 from Jakub Jelinek ---
If it is Fortran FE, then the possible commits might be
r14-9893 r14-9874 r14-9873 r14-9753 r14-9752 r14-9720 r14-9719 r14-9712
Anyway, best would be to try to compile the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114861
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114858
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12/13/14 regression]|[11/12/13/14 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Target Milestone|14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111284
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114825
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114738
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114828
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114825
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114834
Bug ID: 114834
Summary: nontstring attribute vs. references
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114825
--- Comment #3 from Jakub Jelinek ---
Yes, and the reason for that is that while in
subroutine pr114825(b)
type t
real, allocatable :: m(:)
end type t
type(t), allocatable, target :: b(:)
type(t), pointer :: d
!$omp parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114825
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472
--- Comment #42 from Jakub Jelinek ---
(In reply to Дилян Палаузов from comment #40)
> Or when is gcc-bootstrap true and target-libbacktrace-bootstrap false?
Whenever --enable-bootstrap (explicitly or by default) and libbacktrace isn't
needed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472
--- Comment #41 from Jakub Jelinek ---
Fixed for 13.3 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114572
--- Comment #6 from Jakub Jelinek ---
Fixed for 13.3 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114533
--- Comment #14 from Jakub Jelinek ---
Fixed for 13.3 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114552
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114580
--- Comment #5 from Jakub Jelinek ---
Fixed for 13.3 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12/13 Regression] |[11/12 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12/13 regression] Stack |[11/12 regression] Stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114687
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114634
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12/13 Regression] Crash |[11/12 Regression] Crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114691
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12/13 Regression] Bogus |[11/12 Regression] Bogus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114743
--- Comment #5 from Jakub Jelinek ---
Fixed for 13.3 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753
--- Comment #11 from Jakub Jelinek ---
Fixed for 13.3 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114768
--- Comment #11 from Jakub Jelinek ---
Fixed for 13.3 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114780
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114784
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
--- Comment #10 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #8)
> So, given the known ia32 register starvation, can't we split that first
> alternative to
> =,r,o with "nox64" isa and =,r,ro with "x64" isa?
Better make it a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
--- Comment #8 from Jakub Jelinek ---
(In reply to Uroš Bizjak from comment #7)
> (define_insn_and_split "*andn3_doubleword_bmi"
> [(set (match_operand: 0 "register_operand" "=,r,r")
> (and:
> (not: (match_operand: 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
Bug 40883 depends on bug 66928, which changed state.
Bug 66928 Summary: Typos in translatable strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66928
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66928
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114808
--- Comment #3 from Jakub Jelinek ---
Oops, I'm blind.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114808
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |14.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114804
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787
Jakub Jelinek changed:
What|Removed |Added
Priority|P2 |P1
--- Comment #12 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114643
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114799
--- Comment #5 from Jakub Jelinek ---
_10 is created during pattern recognition:
patt_10 = (unsigned short) y.0_1;
#0 vect_convert_input (vinfo=0x3a883e0, stmt_info=0x3be5410,
type=, unprom=0x7fffcc80, vectype=, subtype=optab_default)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114784
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787
--- Comment #11 from Jakub Jelinek ---
Seems it is {,likely_}max_loop_iterations_int on the for (; i < 1; i++) loop
which matters (aka loop 3). Given the i = 0 right before it (guess csmith-ism,
don't see why it couldn't be in the for init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787
--- Comment #9 from Jakub Jelinek ---
It is the
if (dump_file && (dump_flags & TDF_DETAILS)
&& max_loop_iterations_int (loop) >= 0)
{
fprintf (dump_file,
"Loop %d iterates at most %i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787
--- Comment #8 from Jakub Jelinek ---
Seems it is -fdump-tree-profile_estimate-details that changes the code
generation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787
Jakub Jelinek changed:
What|Removed |Added
Priority|P1 |P2
Keywords|needs-bisection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114788
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2024-04-22
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114790
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |11.5
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114792
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114793
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114796
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114799
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-bisection |
Summary|[14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787
Jakub Jelinek changed:
What|Removed |Added
Version|unknown |14.0
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114780
--- Comment #3 from Jakub Jelinek ---
Fixed for 14.1 so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114783
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114784
--- Comment #4 from Jakub Jelinek ---
Guess DECL_UNINLINABLE, maybe DECL_PRESERVE_P, TREE_USED, maybe
DECL_USER_ALIGN/DECL_ALIGN, maybe DECL_WEAK, maybe
DECL_NO_INSTRUMENT_FUNCTION_ENTRY_EXIT, DECL_NO_LIMIT_STACK.
TREE_READONLY, DECL_PURE_P,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114784
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #3 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114784
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114783
--- Comment #3 from Jakub Jelinek ---
Created attachment 57991
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57991=edit
gcc14-pr114783.patch
Full untested patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114783
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114783
--- Comment #2 from Jakub Jelinek ---
@@ -16831,7 +16882,7 @@ (define_insn "*avx2_eq3"
[(set (match_operand:VI_256 0 "register_operand" "=x")
(eq:VI_256
(match_operand:VI_256 1 "nonimmediate_operand" "%x")
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114783
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114772
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114780
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779
--- Comment #5 from Jakub Jelinek ---
It isn't about side-effects. It is about it having pointer type.
If you change your testcase to
uintptr_t psfr_int = (uintptr_t) psfr;
if (! __builtin_constant_p (psfr_int))
then it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779
--- Comment #3 from Jakub Jelinek ---
But in that case the POINTER_TYPE_P case doesn't trigger, because it is
INTEGER_CST and
so
/* If we know this is a constant, emit the constant of one. */
if (CONSTANT_CLASS_P (arg)
|| (TREE_CODE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114779
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #32 from Jakub Jelinek ---
Ah, but get_alias_set has quite special handling of pointers, it finds the
ultimately pointed type and uses TYPE_MAIN_VARIANT for it, so it actually
ignores TYPE_CANONICAL of the pointer type itself for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #31 from Jakub Jelinek ---
I've tried to construct a wrong-code testcase, but so far haven't been
successful.
In e.g.
struct S { int s; } s;
struct T { long l; } t;
const struct S *
foo (const struct S **p, const struct T **q)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114709
Jakub Jelinek changed:
What|Removed |Added
Summary|[12/13/14 Regression] |[12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114769
Jakub Jelinek changed:
What|Removed |Added
Summary|[14 Regression] Suspicious |[14 Regression] Suspicious
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114768
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114762
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114773
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
1 - 100 of 10458 matches
Mail list logo
