https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115157
--- Comment #4 from Richard Earnshaw ---
The tests in the last patch fail on arm-eabi. The tests assume that
sizeof(enum) == sizeof(int), which is not true if -fshort-enum is the default.
+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115086
--- Comment #2 from Richard Earnshaw ---
And perhaps more importantly the mov can even be hoisted outside of a loop.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115083
--- Comment #5 from Richard Earnshaw ---
Please give the port developers time to finish working on the port. Only the
initial patches have been pushed so far and there is plenty of work left to do.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115058
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115058
Richard Earnshaw changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #34 from Richard Earnshaw ---
To be honest, I'm more concerned that we aren't eliminating a lot of these
copies during the gimple optimization phase. The memcpy is really a type
punning step (that's strictly ISO C compliant, rather
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #31 from Richard Earnshaw ---
While that does seem to fix the bug, it's at the cost of 6 additional stores in
the problematic test that are redundant other than changing the alias set view.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #29 from Richard Earnshaw ---
Sorry, I was looking at the wrong pair of insns. The earlier store to that
location was insn 111.
111: [r212:SI (1 MEM[(struct Vec128 *)_179]+0 S4 A64)] = {r0:SI..r3:SI}
It appears that the problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #27 from Richard Earnshaw ---
(In reply to Richard Earnshaw from comment #26)
> (In reply to Richard Biener from comment #25)
> > I think it's more interesting why
> >
> > * 119: [r216:SI (2 MEM[(struct Vec128 *)_179]+0 S4 A64)] =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #26 from Richard Earnshaw ---
(In reply to Richard Biener from comment #25)
> I think it's more interesting why
>
> * 119: [r216:SI (2 MEM[(struct Vec128 *)_179]+0 S4 A64)] =
> {r0:SI..r3:SI}
>
> isn't considered as dependence?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #23 from Richard Earnshaw ---
#0 ptr_deref_may_alias_decl_p (ptr=0x75e0c678, decl=0x75dff000)
at /home/rearnsha/gnusrc/gcc-cross/gcc-13/gcc/tree-ssa-alias.cc:295
#1 0x01768173 in indirect_ref_may_alias_decl_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #22 from Richard Earnshaw ---
(Previous analysis is based on gcc-13 branch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
Richard Earnshaw changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #20 from Richard Earnshaw ---
Created attachment 57928
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57928=edit
fully preprocessed testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #19 from Richard Earnshaw ---
This is another problem with (I suspect) incorrect aliasing information. If I
compile with -fno-strict-aliasing, I get
88: f4432a1fvst1.8 {d18-d19}, [r3 :64] // {>E} SP+96/16
8c:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114338
--- Comment #1 from Richard Earnshaw ---
Why would that be better? On a machine that does not lack registers, there's
more instruction-level parallelism in
(set (tmp) (-1))
(set (tmp) (ashift (tmp) (count)))
(and (x) (x) (tmp))
What's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114307
--- Comment #2 from Richard Earnshaw ---
Note that it's clear from the .syntax markers that this is inline assembler
that's the source of the invalid instructions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114307
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2024-03-11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113428
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113542
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113428
--- Comment #6 from Richard Earnshaw ---
Patch here: https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647294.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100523
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110775
--- Comment #3 from Richard Earnshaw ---
Perhaps we could use
#define abort __builtin_trap
?
A quick check seems to suggest this will work ok.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113428
--- Comment #4 from Richard Earnshaw ---
/* { dg-warning {cast to pointer from integer of different size} "" { target
*-*-* } .-2 } */
I'm guessing it's this that's causing the problem because int and int* are the
same size on 32-bit targets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113428
--- Comment #3 from Richard Earnshaw ---
The referenced patch added the test that is failing. How is that a regression?
Or are you suggesting that the test works without the rest of the patch
applied?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113510
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113510
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=113611
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337
Richard Earnshaw changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114136
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114143
--- Comment #5 from Richard Earnshaw ---
(In reply to Richard Earnshaw from comment #4)
> You're going to need --with-multilib=aprofile,rmprofile if you want the full
> set of multilibs. But beware it builds a *lot* of them.
Sorry, I mean
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114143
--- Comment #4 from Richard Earnshaw ---
You're going to need --with-multilib=aprofile,rmprofile if you want the full
set of multilibs. But beware it builds a *lot* of them.
We don't enable this by default because it conflicts with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114143
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2024-02-28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114136
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114136
Bug ID: 114136
Summary: wrong code for c23 fully anonymous arg lists on arm
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108120
Richard Earnshaw changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108120
Richard Earnshaw changed:
What|Removed |Added
Summary|[11/12/13 Regression] ICE: |[11/12 Regression] ICE: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108120
Richard Earnshaw changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13 Regression] ICE:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107270
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2024-02-22
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113780
Richard Earnshaw changed:
What|Removed |Added
CC||keithp at keithp dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113795
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108933
Richard Earnshaw changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113542
Richard Earnshaw changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113510
--- Comment #6 from Richard Earnshaw ---
(In reply to Andrew Pinski from comment #5)
> Yes the peephole2 in thumb1.md looks wrong:
> ```
> ;; Reloading and elimination of the frame pointer can
> ;; sometimes cause this optimization to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113542
Richard Earnshaw changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113278
--- Comment #1 from Richard Earnshaw ---
newlib certainly implements fileno():
$ nm libc.a|grep fileno
libc_a-fileno.o:
T fileno
U fileno
libc_a-fileno_u.o:
T fileno_unlocked
U fileno
So perhaps the issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113257
--- Comment #4 from Richard Earnshaw ---
I'm not sure. My understanding was that -march=native started by looking up
the CPU ID first and then using the internal mapping of that CPU to the
architecture (which can't work if we don't recognize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113257
--- Comment #2 from Richard Earnshaw ---
For -mcpu=native, the manual says:
Additionally on native AArch64 GNU/Linux systems the value
@samp{native} tunes performance to the host system. This option has no effect
if the compiler is unable to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #61 from Richard Earnshaw ---
Then I don't understand what you're trying to say in c57.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #59 from Richard Earnshaw ---
Memcpy must never write beyond the end of the specified buffer, even if reading
it is safe. That wouldn't be thread safe.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #56 from Richard Earnshaw ---
I've never heard of a memcpy implementation that corrupts data if called with
memcpy (p, p, n). (The problems come from partial overlaps where the direction
of the copy may matter).
Has anybody
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #28 from Richard Earnshaw ---
(In reply to David Binderman from comment #5)
> No idea. I know the gcc project is over 30 years old and it is not
> feasible for me to download the entire history, it is too large.
>
> I have the last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #27 from Richard Earnshaw ---
> ==9933==by 0x151D554: search_line_fast (lex.cc:872)
This is the entry code; so the issue is with the initial alignment code (unless
the buffer is smaller than 16 bytes, when we might get both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #26 from Richard Earnshaw ---
I think it's more likely that this is at the start of the buffer rather than
the end, and related to rounding the address down to a 16-byte alignment. But
it could also occur at the end of the buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #24 from Richard Earnshaw ---
(In reply to David Binderman from comment #22)
> Is the optimization still worthwhile some 12 years later ?
Almost certainly. Vector operations have become much better than they were at
the time the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #21 from Richard Earnshaw ---
FTR it was this patch that added this code. So 2012!
commit e75b54a2d932929a9b2e940c5aad1ef33a86c008
Author: Richard Earnshaw
Date: Thu Mar 22 17:54:55 2012 +
* lex.c (search_line_fast):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
Richard Earnshaw changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113030
--- Comment #4 from Richard Earnshaw ---
Yes, that looks sensible. Can you post it please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112334
--- Comment #1 from Richard Earnshaw ---
This might be a side issue, but:
@defbuiltin{{void} __builtin_return (void *@var{result})}
This built-in function returns the value described by @var{result} from
the containing function. You should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109166
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096
--- Comment #8 from Richard Earnshaw ---
(In reply to Thomas Koenig from comment #7)
> Would it make sense to document this somewhere? Or did I just miss it? :-)
Possibly, but I've no idea where. It's too target-specific to put under the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97807
--- Comment #4 from Richard Earnshaw ---
I can reproduce this, but only with -mfloat-abi=soft.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096
--- Comment #6 from Richard Earnshaw ---
For completeness.
The AArch64 ABI lists 4 alternatives with respect to having a frame chain. When
-fomit-frame-pointer is used, GCC implements this one:
- It may require the frame pointer to address a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |WONTFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
--- Comment #16 from Richard Earnshaw ---
(In reply to Mark Brown from comment #15)
> The kernel module loader simply does not insert veneers at present, and
> there were some implementation concerns IIRC.
That's not a good reason to weaken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
--- Comment #14 from Richard Earnshaw ---
(In reply to Mark Brown from comment #13)
> The kernel hasn't got any problem with BTI as far as I am aware - when built
> with clang we run the kernel with BTI enabled since clang does just insert a
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110908
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2023-08-07
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110901
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2023-08-07
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796
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=110796
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2023-07-26
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796
--- Comment #9 from Richard Earnshaw ---
proc add_options_for_ieee { flags } {
if { [istarget alpha*-*-*]
|| [istarget sh*-*-*] } {
return "$flags -mieee"
}
if { [istarget rx-*-*] } {
return "$flags -mnofpu"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110796
--- Comment #6 from Richard Earnshaw ---
Is the exception status supposed to be in a defined state when the test runs?
Shouldn't there be a call to feclearexcept (FE_ALL_EXCEPT) at the start of the
test?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772
Bug 86772 depends on bug 86793, which changed state.
Bug 86793 Summary: mips port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86793
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86793
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99312
--- Comment #8 from Richard Earnshaw ---
Applies to both AArch64 and Arm back-ends.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99312
Richard Earnshaw changed:
What|Removed |Added
CC||Vedant.VijayYevale@infineon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109415
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109415
--- Comment #8 from Richard Earnshaw ---
The __ARM_ARCH_...__ macros turned out to be a very bad design decision. Each
new architecture needs a new macro that older compilers (and software) will not
know about. The ACLE approach is far more
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=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
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
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
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
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=108515
Richard Earnshaw changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #13 from Richard
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=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
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=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
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2023-01-18
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108019
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107621
--- Comment #1 from Richard Earnshaw ---
I don't see that when using Firefox, so perhaps it is a browser issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107208
--- Comment #4 from Richard Earnshaw ---
(In reply to vfdff from comment #3)
> it seems releted to targetm.calls.function_value called by assign_parms, who
> return different behaviour for MODE_COMPLEX_FLOAT and MODE_COMPLEX_INT. With
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071
--- Comment #10 from Richard Earnshaw ---
That sounds broadly sensible. One optimization might be to check if the
exception trapping is already enabled, then you can skip the read/set/restore
dance entirely in that case. That might be more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071
--- Comment #8 from Richard Earnshaw ---
(In reply to Francois-Xavier Coudert from comment #7)
> @Richard The test in gfortran.dg/ieee/modes_1.f90 is not doing that. It is
> checking that the floating-point modes (rounding mode, underflow mode,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071
--- Comment #6 from Richard Earnshaw ---
Whilst the patch is probably fine and a better way of doing this, it won't fix
the test failure. I think your problem is that you're assuming that an
exception will cause a trap in hardware. That's not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032
--- Comment #8 from Richard Earnshaw ---
Perhaps something is changing the decision on the use of the frame pointer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2022-09-27
1 - 100 of 317 matches
Mail list logo
