https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86003
--- Comment #3 from Richard Earnshaw ---
Author: rearnsha
Date: Mon Jun 4 08:46:04 2018
New Revision: 261141
URL: https://gcc.gnu.org/viewcvs?rev=261141&root=gcc&view=rev
Log:
[arm] PR target/86003 build failures with --with-cpu=xsc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86003
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209
--- Comment #9 from Richard Earnshaw ---
(In reply to ktkachov from comment #7)
> The other thing to consider with merging loads is how the result is used.
> In your example if you merge the 16-bit loads into a single 32-bit register
> load you'l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86209
--- Comment #11 from Richard Earnshaw ---
(In reply to sameerad from comment #10)
> > subus:
> >ldr w0, [w0]
> >add w0, w0, w0, lsr #16
> >uxth w0, w0
> >ret
>
> This is interesting way in which load store combining can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91163
--- Comment #6 from Richard Earnshaw ---
Sounds like a dup of PR93069
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91163
--- Comment #7 from Richard Earnshaw ---
Suggest you run the application under "strace -f" to try to identify what is
being duplicated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91163
Richard Earnshaw changed:
What|Removed |Added
Resolution|WONTFIX |INVALID
--- Comment #10 from Richard
ectly, the resolution file says to expect one
file to analyse, but two are passed. It looks like something is interpreting
as an additional file.
Going back another step, we see
/home/rearnsha/scratch/gnu/gcc-install/armv8l/gcc-9.1.0/libexec/gcc/armv8l-unkno
wn-linux-gnueabihf/9.1.0/lto-wrapper -f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #11 from Richard Earnshaw ---
Some pass in the compilation process must create that temporary file with the
options to gcc; but whichever pass this is doesn't appear in the output of "gcc
-v"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #12 from Richard Earnshaw ---
How do I invoke lto-wrapper inside gdb? it seems to pick up some magic options
via the environment...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #20 from Richard Earnshaw ---
Running under gdb I see:
(gdb)
decode_cmdline_option (argv=0x15170c, lang_mask=4095, decoded=0x1506e8)
at /home/rearnsha/gnusrc/gcc/gcc-9.1.0/gcc/opts-common.c:523
...
gdb) p *option
$5 = {opt_text
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #21 from Richard Earnshaw ---
FWIW in the environment:
COLLECT_GCC_OPTIONS = '-B' '.' '-v' '-flto' '-MMD' '-MF' ''
'-mcpu=cortex-a72' '-mfloat-abi=hard' '-mtls-dialect=gnu' '-marm'
'-march=armv8-a+crc+simd'
So is this correct, o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #24 from Richard Earnshaw ---
It would appear that the handling of -MMD is the same on both Arm and X86 - in
both cases it swallows the subsequent -MF option when digested by lto-wrapper.
I'm not sure yet why the two compilers then d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #25 from Richard Earnshaw ---
Created attachment 46608
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46608&action=edit
possible patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #26 from Richard Earnshaw ---
On the basis that COLLECT_GCC_OPTIONS are the options to add if reinvoking gcc,
then that environment variable is really a set of driver options. As such, I
suspect the right fix for this is to add CL_DR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #28 from Richard Earnshaw ---
Not sure. I presumed the LANG_ALL was about handing all language-specific
options, rather than say, just fortran as would be done if gcc were invoked as
g95.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #30 from Richard Earnshaw ---
Makes sense. I'm going to wait now until Joseph gets back and has had a chance
to comment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90883
--- Comment #19 from Richard Earnshaw ---
Surely the real problem is that the expansion doesn't really understand about
the 'don't care' location and that we can therefore put any value in that?
That additional knowledge would allow the earlier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91284
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91297
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91297
Richard Earnshaw changed:
What|Removed |Added
Resolution|WONTFIX |INVALID
--- Comment #3 from Richard E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #4 from Richard Earnshaw ---
R8 is the register used for the address of the return value location when the
result cannot be stored in registers. Are you sure that this isn't a problem
in the caller?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #5 from Richard Earnshaw ---
(In reply to Richard Earnshaw from comment #4)
> R8 is the register used for the address of the return value location when
> the result cannot be stored in registers. Are you sure that this isn't a
> prob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
Richard Earnshaw changed:
What|Removed |Added
Component|target |driver
--- Comment #33 from Richard E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #15 from Richard Earnshaw ---
From looking at the dumps it would appear that one of the STP generating
peepholes might have bailed out, but that some of the changes have not been
undone.
From the pass before, we have:
(insn/f:TI 802
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
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=91386
--- Comment #17 from Richard Earnshaw ---
Created attachment 46686
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46686&action=edit
candidate patch
Could you try this patch please? So far only very lightly tested.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #40 from Richard Earnshaw ---
Author: rearnsha
Date: Wed Aug 7 16:15:35 2019
New Revision: 274176
URL: https://gcc.gnu.org/viewcvs?rev=274176&root=gcc&view=rev
Log:
PR driver/91130 Use CL_DRIVER when handling of COLLECT_GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
Richard Earnshaw changed:
What|Removed |Added
Summary|[9/10 Regression] -MF |[9 Regression] -MF clashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #20 from Richard Earnshaw ---
Author: rearnsha
Date: Fri Aug 9 16:14:59 2019
New Revision: 274238
URL: https://gcc.gnu.org/viewcvs?rev=274238&root=gcc&view=rev
Log:
[aarch64] PR target/91386 Use copy_rtx to avoid modifying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
Richard Earnshaw changed:
What|Removed |Added
Known to fail|10.0|
--- Comment #21 from Richard Earnsha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #23 from Richard Earnshaw ---
Author: rearnsha
Date: Mon Aug 19 16:11:30 2019
New Revision: 274675
URL: https://gcc.gnu.org/viewcvs?rev=274675&root=gcc&view=rev
Log:
[aarch64] PR target/91386 Use copy_rtx to avoid modifying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
-optimization, ra
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
CC: vmakarov at redhat dot com, wdijkstr at arm dot com
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91708
--- Comment #15 from Richard Earnshaw ---
So is this now fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91708
--- Comment #17 from Richard Earnshaw ---
So do we have a testcase that shows the problem on older compilers?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91708
--- Comment #19 from Richard Earnshaw ---
(In reply to Wilco from comment #18)
> (In reply to Richard Earnshaw from comment #17)
> > So do we have a testcase that shows the problem on older compilers?
>
> Yes, the same testcase shows the same in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91776
--- Comment #3 from Richard Earnshaw ---
(In reply to Wilco from comment #1)
> (In reply to yhr-_-yhr from comment #0)
> > I'm doing this test on a Raspberry Pi Model 3B+. The CPU is BCM2835 ARMv7.
>
> I think it's BM2837, ie. Cortex-A53. Or did
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91708
--- Comment #21 from Richard Earnshaw ---
But dropping in a char* will give a more restrictive alias set, so that isn't
wrong, even if it is suboptimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #25 from Richard Earnshaw ---
Well very small loops should be unrolled more than slightly larger ones. So
perhaps if the loop body is only 3 or 4 instructions it should be unrolled four
times but above that perhaps only twice.
Some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83206
--- Comment #19 from Richard Earnshaw ---
-m{cpu,tune,arch}=native are hosted-only flags that mean look-up the
architecture on the machine I'm running on now. They are not supported at all
on cross compilers. This is translated by the driver in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83105
--- Comment #2 from Richard Earnshaw ---
The baseline target CPU for arm linux is ARM10TDMI (armv5t), but that processor
only had VFPv1 and GCC has never supported that. Code generated historically
was incompatible with that target and if you ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83105
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83105
--- Comment #4 from Richard Earnshaw ---
Author: rearnsha
Date: Wed Dec 20 10:30:00 2017
New Revision: 255858
URL: https://gcc.gnu.org/viewcvs?rev=255858&root=gcc&view=rev
Log:
[arm] PR target/83105: Minor change of default CPU for a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83105
--- Comment #5 from Richard Earnshaw ---
Fixed. We now select ARM10E as the default CPU when --with-float={hard,softfp}
is specified.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83462
--- Comment #3 from Richard Earnshaw ---
(In reply to Jakub Jelinek from comment #1)
> Does arm-none-eabi imply -ffreestanding or something similar? The testcase
> certainly completely fails with -ffreestanding on x86_64-linux.
No. But it's no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83514
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83514
--- Comment #2 from Richard Earnshaw ---
> will *always* construct a -march string for the driver
^^
for the compiler proper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83712
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #27 from Richard Earnshaw ---
(In reply to Qing Zhao from comment #23)
> qinzhao@gcc116:~/Bugs/78809/const_cmp$ cat t_p.c
> #include
>
> char array[]= "fishi";
>
> #define NUM 10
> int __attribu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641
--- Comment #18 from Richard Earnshaw ---
(In reply to Arnd Bergmann from comment #14)
> It looks like r255468 broke compilation of a couple of files in the Linux
> kernel,
> which use a top-level statement like
>
> linux/arch/arm/kvm/hyp/banked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84129
Richard Earnshaw changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641
--- Comment #26 from Richard Earnshaw ---
(In reply to Arnd Bergmann from comment #25)
> or to apply more force and add the ".arch" to each inline
> asm individually.
No, that would not be guaranteed to be supported: and you'd be lying to the
c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83370
Richard Earnshaw changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83370
Richard Earnshaw changed:
What|Removed |Added
Target Milestone|--- |6.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518
--- Comment #16 from Richard Earnshaw ---
(In reply to Nick Clifton from comment #13)
> Hi Aldy,
>
>
> > pc: 8ca4, instr: e1c520fc
> > pc: 4, instr: ea00089b
> >
> > I took a peek at the executable being run with "/my-arm-build/objdudump -D
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518
--- Comment #22 from Richard Earnshaw ---
(In reply to Nick Clifton from comment #21)
> Hi Aldy,
>
> >>> instruction. :-( Looking at the code in Handle_Store_Double() in
> >>> sim/arm/armemu.c, I think that the reason is probably because the a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84242
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84241
Richard Earnshaw changed:
What|Removed |Added
CC||jgreenhalgh at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84208
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89101
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
--- Comment #13 from Richard Earnshaw ---
(In reply to Stefan Ring from comment #12)
> Unfortunately my armv5 device has died in the meantime, so I cannot verify
> my original use case. The behavior is indeed different on armv7. It does not
> tra
: wrong-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
CC: bernd.edlinger at hotmail dot de, ebotcazou at gcc dot
gnu.org
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89544
--- Comment #1 from Richard Earnshaw ---
I think things start to go wrong in assign_parm_find_data_types. That calls
promote_function_mode, but that then has no target-specific action when the
type is a RECORD_TYPE, and it never calls the back-e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89544
--- Comment #4 from Richard Earnshaw ---
An alternative way of fixing this might be if the backend could somehow control
DECL_ARG_TYPE for the parameter, to set it to a variant without the additional
alignment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #9 from Richard Earnshaw ---
(In reply to Wilco from comment #8)
> (In reply to Segher Boessenkool from comment #5)
> > The first one just needs an xfail. I don't know if it should be *-*-* there
> > or only arm*-*-* should be added.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Richard Earnshaw changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83033
--- Comment #4 from Richard Earnshaw ---
Author: rearnsha
Date: Mon Apr 8 12:59:24 2019
New Revision: 270207
URL: https://gcc.gnu.org/viewcvs?rev=270207&root=gcc&view=rev
Log:
The fma_forest, fma_root_node and func_fma_steering classe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83033
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863
Bug 89863 depends on bug 83033, which changed state.
Bug 83033 Summary: aarch64/cortex-a57-fma-steering.c: 3 * poor C++ style ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83033
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89794
--- Comment #4 from Richard Earnshaw ---
(In reply to Jakub Jelinek from comment #3)
> Guess with PR89475 fix this will be latent, unless one disables ccp.
> Anyway, to me this looks like a backend bug. The function is leaf, but for
> some stran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89794
Richard Earnshaw changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89794
--- Comment #6 from Richard Earnshaw ---
There seems to be more to this than initially thought. Another insn is in
play.
(insn 12 10 14 2 (set (reg:SI 129)
(bswap:SI (subreg:SI (reg:DI 127 [ i ]) 4))) "/tmp/test3.c":10:7 331
{*arm_rev}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90016
--- Comment #1 from Richard Earnshaw ---
Author: rearnsha
Date: Wed Apr 10 09:51:16 2019
New Revision: 270248
URL: https://gcc.gnu.org/viewcvs?rev=270248&root=gcc&view=rev
Log:
[aarch64] PR90016 - aarch64: reference to undeclared N in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90016
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89146
--- Comment #2 from Richard Earnshaw ---
(In reply to Jakub Jelinek from comment #1)
> I've looked for constraints that include [ijnIJKLMNO] together with [mo] and
> couldn't find any. So, not really sure what note_invalid_constants is
> suppose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #36 from Richard Earnshaw ---
(In reply to Segher Boessenkool from comment #35)
> Peter's patch solves this particular problem, but not the PR unfortunately.
>
> I finally understand Jakub's comment 30. This patch solves the PR (als
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #51 from Richard Earnshaw ---
(In reply to Segher Boessenkool from comment #50)
> The insn is
>
> (insn 7 3 8 2 (parallel [
> (set (reg:CC 100 cc)
> (compare:CC (reg:SI 0 r0 [116])
> (c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90075
--- Comment #4 from Richard Earnshaw ---
(In reply to Ramana Radhakrishnan from comment #3)
> Seems to have been "fixed" by the commit to fix PR87369,
>
> Richard, is this something to backport ? Prima-facie , it appears not and we
> will need a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90075
--- Comment #6 from Richard Earnshaw ---
(In reply to ramana.radhakrish...@arm.com from comment #5)
> For the release branches, I think backporting your patch (and any followups
> , do you remember any ?) should be fine and we should just do it .
Keywords: ra
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
CC: ramana.radhakrishnan at arm dot com, vmakarov at redhat dot
com
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rearnsha at gcc dot gnu.org
Target Milestone: ---
Created attachment 46247
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46247&action=edit
testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90255
Richard Earnshaw changed:
What|Removed |Added
CC||ramana.radhakrishnan at arm
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90255
--- Comment #2 from Richard Earnshaw ---
Command to reproduce
cc1 -fpreprocessed bow.i -quiet -dumpbase bow.i -marm -mcpu=arm7tdmi
-march=armv4t -auxbase-strip test/bow.o -Os -w -version -fno-short-enums
-fgnu89-inline -o bow.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90255
Richard Earnshaw changed:
What|Removed |Added
Keywords||missed-optimization, ra
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90249
--- Comment #3 from Richard Earnshaw ---
(In reply to Segher Boessenkool from comment #2)
> What difference is there on some code of significant size? Do you see
> regressions then?
>
> Of course there are some tiny examples where it now does w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90249
--- Comment #7 from Richard Earnshaw ---
(In reply to Segher Boessenkool from comment #4)
> That is code *size*. Code size is expected to grow a tiny bit, because of
> *better* register allocation.
>
> But we could not do make_more_copies at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90249
--- Comment #8 from Richard Earnshaw ---
(In reply to Richard Earnshaw from comment #7)
> (In reply to Segher Boessenkool from comment #4)
> > That is code *size*. Code size is expected to grow a tiny bit, because of
> > *better* register alloca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37369
--- Comment #4 from Richard Earnshaw ---
Author: rearnsha
Date: Tue Apr 30 09:25:31 2019
New Revision: 270683
URL: https://gcc.gnu.org/viewcvs?rev=270683&root=gcc&view=rev
Log:
PR target/90075 Prefer bsl/bit/bif for copysignf. (backpo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90075
--- Comment #7 from Richard Earnshaw ---
Author: rearnsha
Date: Tue Apr 30 09:25:31 2019
New Revision: 270683
URL: https://gcc.gnu.org/viewcvs?rev=270683&root=gcc&view=rev
Log:
PR target/90075 Prefer bsl/bit/bif for copysignf. (backpo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90075
--- Comment #8 from Richard Earnshaw ---
Author: rearnsha
Date: Tue Apr 30 09:31:04 2019
New Revision: 270684
URL: https://gcc.gnu.org/viewcvs?rev=270684&root=gcc&view=rev
Log:
PR target/90075 Prefer bsl/bit/bif for copysignf. (backpo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37369
--- Comment #5 from Richard Earnshaw ---
Author: rearnsha
Date: Tue Apr 30 09:31:04 2019
New Revision: 270684
URL: https://gcc.gnu.org/viewcvs?rev=270684&root=gcc&view=rev
Log:
PR target/90075 Prefer bsl/bit/bif for copysignf. (backpo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90075
Richard Earnshaw changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89400
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=89400
--- Comment #6 from Richard Earnshaw ---
Author: rearnsha
Date: Fri May 3 13:45:59 2019
New Revision: 270853
URL: https://gcc.gnu.org/viewcvs?rev=270853&root=gcc&view=rev
Log:
[arm] PR target/89400 fix thumb1 unaligned access expansio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89400
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |ASSIGNED
Summary|[7/8/9/10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48429
Richard Earnshaw changed:
What|Removed |Added
Priority|P3 |P4
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88167
--- Comment #1 from Richard Earnshaw ---
Author: rearnsha
Date: Wed May 8 14:36:15 2019
New Revision: 271012
URL: https://gcc.gnu.org/viewcvs?rev=271012&root=gcc&view=rev
Log:
[arm][PR88167] Fix __builtin_return_address returns invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88167
Richard Earnshaw changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|unassigned at gcc dot gnu.org |rearnsha at gcc dot
gnu.org
--- Comment #1 from Richard Earnshaw ---
Mine
401 - 500 of 1817 matches
Mail list logo
