https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99271
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99551
--- Comment #1 from Richard Earnshaw ---
probably one of the if-conversion passes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99724
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2021-03-23
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773
--- Comment #1 from Richard Earnshaw ---
-march=armv8.1-m.main+mve -mfloat-abi=hard should use the VFP registers for
passing any FP arguments so the build attribute for Tag_ABI_VFP_args should be
set to show that.
It's true that soft-float routi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773
--- Comment #4 from Richard Earnshaw ---
(In reply to Christophe Lyon from comment #3)
> I tried changing TARGET_HARD_FLOAT_SUB in arm.h to:
> #define TARGET_HARD_FLOAT_SUB (arm_float_abi != ARM_FLOAT_ABI_SOFT\
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99836
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98776
Richard Earnshaw changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99890
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100067
Bug ID: 100067
Summary: Unexpected warning for -mcpu=neoverse-n1 when
configured with --with-fpu
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100067
Richard Earnshaw changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100067
--- Comment #4 from Richard Earnshaw ---
(In reply to Christophe Lyon from comment #3)
> Unfortunately this is causing many regressions in the GCC testsuite.
Sigh! I'm not entirely surprised. I suspect most of this is testisms, though.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84547
--- Comment #2 from Richard Earnshaw ---
(In reply to Andrew Pinski from comment #1)
> Yes int128 (or rather double wide register) shifts are not optimized that
> well. They are not used by many people even. I wonder if there is a way to
> use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95816
--- Comment #2 from Richard Earnshaw ---
(In reply to Andrew Pinski from comment #1)
> Confirmed, I wonder if x16 and x17 should not be considered as temps alive
> across all jumps in aarch64 really; not just jumps between hot and cold
> sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95816
--- Comment #3 from Richard Earnshaw ---
The best thing to do for now is to disable hot/cold partitioning, as we do on
Arm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100214
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2021-04-23
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100216
Richard Earnshaw changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97534
--- Comment #5 from Richard Earnshaw ---
No, I don't think it's related to that, in fact, I think this is just a latent
bug that's been in the code for a long time.
At one point we have a 32-bit signed integer containing INT_MIN, which is
intern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97534
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95908
--- Comment #1 from Richard Earnshaw ---
I'm sure the code we generate doesn't match your expectations. What's more, I
don't think it's really practical to meet them.
To do so would require emitting a mask operation after practically every
ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94993
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98759
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98681
--- Comment #5 from Richard Earnshaw ---
Patch looks generally sensible, but I think all the INTVALs in that expression
should be converted to UINTVAL. The mask, in particular, is unsigned and it is
weird that one moment we're using a unsigned v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2021-01-29
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99271
Bug ID: 99271
Summary: [10/11 regression] Wrong code for Arm-v8-m.main CMSE
calling __gnu_cmse_nonsecure_call
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Key
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99271
Richard Earnshaw changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99271
Richard Earnshaw changed:
What|Removed |Added
Summary|[10/11 regression] Wrong|[10 regression] Wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100236
Richard Earnshaw changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100236
--- Comment #4 from Richard Earnshaw ---
Fixed on master so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100311
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100311
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 100311, which changed state.
Bug 100311 Summary: UB in sel-sched.c:init_regs_for_mode with
-march=armv8-m.base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100311
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100412
Bug ID: 100412
Summary: [11/12 regression] PASS & FAIL for same test
aarch64-qemu: gcc.dg/Wvla-parameter-[23].c pr?
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63521
Richard Earnshaw changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|jiwang at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209
Richard Earnshaw changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|sameerad at gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100412
--- Comment #2 from Richard Earnshaw ---
The test name comes from the file name, the 'test for warnings' and the line
number. Since both warnings are on the same line, that would require some
major hackery (unless that can be encoded in the dg-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100432
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100563
--- Comment #2 from Richard Earnshaw ---
Er, wow, I'm surprised this hasn't come up before.
The problem is that the cstore_cc pattern in arm.md has no predicates on the
operands and no constraints on the modes of those operands and yet it then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100563
Richard Earnshaw changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99908
--- Comment #7 from Richard Earnshaw ---
(In reply to Hongtao.liu from comment #6)
> Should be fixed in trunk.
The original report was about arm. None of your changes are outside of the x86
backend, so no, this is not fixed for the original rep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99908
--- Comment #8 from Richard Earnshaw ---
Never mind, the original reference to arm was not the 'arm cpu', my mistake.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100563
Richard Earnshaw changed:
What|Removed |Added
Summary|[10/11/12 Regression] arm: |[10/11 Regression] arm: ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100563
Richard Earnshaw changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100713
Bug ID: 100713
Summary: g++.dg/cpp1y/lambda-generic-90842.C has ambiguous pass
and fail
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100713
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100767
Bug ID: 100767
Summary: arm: ice when inlining at -flto with different cpu and
arch settings
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100767
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100767
--- Comment #1 from Richard Earnshaw ---
The problem is that we call arm_configure_build_target() with
arm_configure_build_target (&caller_target, caller_opts, &global_options_set,
false);
But that doesn't make sense in reality - global_opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100767
--- Comment #3 from Richard Earnshaw ---
fixed on master so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100767
--- Comment #5 from Richard Earnshaw ---
Also fixed for gcc-11. Will consider backporting further, but patches
no-longer apply cleanly on gcc-10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95650
--- Comment #6 from Richard Earnshaw ---
AArch32 is able to produce the optimal sequence because the ABI specifies
caller widening of parameters. For safety reasons AArch64 takes the opposite
approach and requires the callee to narrow arguments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84467
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #66 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #68 from Richard Earnshaw ---
(In reply to Christophe Lyon from comment #67)
> According to gcc-testresults, we still see:
> FAIL: gcc.dg/ira-shrinkwrap-prep-1.c scan-rtl-dump pro_and_epilogue
> "Performing shrink-wrapping"
> FAIL: gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108442
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2023-01-18
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108442
--- Comment #3 from Richard Earnshaw ---
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587296.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108442
--- Comment #5 from Richard Earnshaw ---
Fixed on master. While this is not a regression, we should consider a
backport.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103100
--- Comment #14 from Richard Earnshaw ---
(In reply to Richard Biener from comment #13)
> (In reply to Andrew Pinski from comment #10)
> > Updated patch submitted:
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589254.html
>
> I thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108515
--- Comment #10 from Richard Earnshaw ---
Almost certainly this is related to the need for a copyreloc and presumably the
linker has not created one for some reason. So I suspect this is most likely a
binutils issue rather than a compiler one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108515
Richard Earnshaw changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #13 from Richard E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108515
Richard Earnshaw changed:
What|Removed |Added
Resolution|FIXED |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
--- Comment #2 from Richard Earnshaw ---
If the testcase is built with -march=armv8.1-m.main+mve.fp then the useless
stack adjustments go away. I think that's because V4SFmode is not a supported
vector mode for integer MVE - see arm_vector_mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
--- Comment #3 from Richard Earnshaw ---
Given that the hard-float ABI essentially requires V4SF as a type, it might be
better to consider this mode supported unconditionally in this case, and
although that might make the compiler try some point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103100
--- Comment #19 from Richard Earnshaw ---
(In reply to Andrew Pinski from comment #18)
> I should say that testcase happens at `-Os -mstrict-align`, at `-O2
> -mstrict-align` it works.
Because for -Os we don't forcibly align arrays - see
AARCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108470
--- Comment #3 from Richard Earnshaw ---
The manual entry for this says "This attribute is supported mainly for the
purpose
of testing the compiler." which suggests a lack of long-term commitment to the
option. Perhaps it would be better to rem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108943
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104614
Bug ID: 104614
Summary: "Undocumented" option flag ignored with --help=target
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104614
--- Comment #1 from Richard Earnshaw ---
Note the manual says for 'Undocumented'
@item Undocumented
The option is deliberately missing documentation and should not
be included in the @option{--help} output.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104614
--- Comment #2 from Richard Earnshaw ---
This case is also wrong:
mhard-float
Target RejectNegative Alias(mfloat-abi=, hard) Undocumented
produces:
-mhard-floatSame as -mfloat-abi=hard.
Which, while not inaccurate, means th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664
--- Comment #28 from Richard Earnshaw ---
I think the 'echo -n' problem can be solved by changing the one instance of
that operation (in ask()) to
printf "%s" "$question [$default]? "
But I don't have the machines that are problematic to test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664
--- Comment #29 from Richard Earnshaw ---
Suggested patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591455.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664
--- Comment #36 from Richard Earnshaw ---
Can this be closed now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105090
--- Comment #1 from Richard Earnshaw ---
This was fallout from some changes made internally in the compiler in around
the gcc-10 timeframe, but it really just exposed a more general problem with
the failure to detect opportunities to use bitfiel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105090
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2022-03-29
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104414
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100106
--- Comment #8 from Richard Earnshaw ---
(In reply to CVS Commits from comment #7)
> The releases/gcc-11 branch has been updated by Richard Biener
> :
>
> https://gcc.gnu.org/g:5155015ce57dc133e006f87fdf0237a5f259bebd
>
Just to note that on m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68605
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68605
--- Comment #5 from Richard Earnshaw ---
If you look at the examples I cite you'll find they rarely, if ever, change
because of changes to GCC. This interface has been stable for year.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68605
--- Comment #6 from Richard Earnshaw ---
That should have said 'years'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104144
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101755
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101755
Richard Earnshaw changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105090
Richard Earnshaw changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rearnsha at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102516
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #4 from Richard Earn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104010
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #6 from Richard Earn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104010
--- Comment #7 from Richard Earnshaw ---
Options to reproduce on arm-none-eabi:
-O3 -mcpu=cortex-a9 -mfpu=neon-fp16 -mfloat-abi=hard -o - vect.c -S
-fdump-tree-all-details
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
Richard Earnshaw changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed|2022-07-04 00:00:00 |2022-07-22
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #33 from Richard Earnshaw ---
I suspect there is still a question, though, as to whether it is safe in
general for two objects with non-conflicting alias sets to share a stack slot.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #35 from Richard Earnshaw ---
> There's no union involved here though but a memcpy used in BitCast.
Agreed, but by creating a shared stack slot, the compiler is effectively
creating a union of its own, and I think that needs to be ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #37 from Richard Earnshaw ---
(In reply to rguent...@suse.de from comment #36)
> Note that the only thing we have to do is fix points-to info, the TBAA
> info should be correct and OK even when objects share location, so there's
> n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #40 from Richard Earnshaw ---
reload_cse_noop_set_p is the function that decides the store is redundant. For
this parallel case it's being called once for each set, but all the cases
return true, so the store insn gets removed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #42 from Richard Earnshaw ---
That would be unfortunate, it removes a lot of pointless loads in this case;
and even the store it removes ought to be safe, if it weren't for the corrupted
alias info that results (the values /are/ the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #45 from Richard Earnshaw ---
The problem with changing rtx_equal_for_cselib_1 is that it is essentially
commutative in its operands - it doesn't disambiguate with x substituting for y
or vice-versa, so we cannot tell if an operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106442
--- Comment #6 from Richard Earnshaw ---
possibly a dup of pr101723. Please try gcc-11.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106442
--- Comment #8 from Richard Earnshaw ---
(In reply to sherry.zhang2 from comment #7)
> (In reply to Richard Earnshaw from comment #6)
> > possibly a dup of pr101723. Please try gcc-11.3
>
> The latest version I can get is 11.2
> https://develo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #47 from Richard Earnshaw ---
Created attachment 53361
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53361&action=edit
Possible patch
A slightly more thorough attempt to avoid the problem by detecting when the
alias sets are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #48 from Richard Earnshaw ---
Improved version posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598993.html
1 - 100 of 399 matches
Mail list logo
