https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85203
--- Comment #3 from Thomas Preud'homme ---
Author: thopre01
Date: Wed Apr 11 09:47:21 2018
New Revision: 259309
URL: https://gcc.gnu.org/viewcvs?rev=259309&root=gcc&view=rev
Log:
[ARM] Fix PR85203: cmse_nonsecure_caller returns wrong result
__b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85261
--- Comment #4 from Thomas Preud'homme ---
Author: thopre01
Date: Wed Apr 11 10:07:25 2018
New Revision: 259310
URL: https://gcc.gnu.org/viewcvs?rev=259310&root=gcc&view=rev
Log:
[ARM] Fix PR85261: ICE with FPSCR setter builtin
Instruction patt
-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: thopre01 at gcc dot gnu.org
Reporter: thopre01 at gcc dot gnu.org
Target Milestone: ---
Target: arm-none-eabi
Hi,
Compiling the following piece of code with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85344
Thomas Preud'homme changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85344
--- Comment #2 from Thomas Preud'homme ---
I have a patch, starting testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85344
--- Comment #3 from Thomas Preud'homme ---
More worrying is that this code compiles without error when it should error
out:
void
foo (void)
{
__asm( "%0" :: "J" ((unsigned char) 0x80));
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85344
Thomas Preud'homme changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #4 from Thom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85344
--- Comment #5 from Thomas Preud'homme ---
(In reply to Thomas Preud'homme from comment #4)
> (In reply to Thomas Preud'homme from comment #3)
> > More worrying is that this code compiles without error when it should error
> > out:
> >
> > void
Severity: normal
Priority: P3
Component: target
Assignee: thopre01 at gcc dot gnu.org
Reporter: thopre01 at gcc dot gnu.org
Target Milestone: ---
Target: arm-linux-gnueabihf
Created attachment 43962
--> https://gcc.gnu.org/bugzi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85434
Thomas Preud'homme changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85434
--- Comment #2 from Thomas Preud'homme ---
(In reply to Thomas Preud'homme from comment #1)
> This is caused by missing stack_protect_set and stack_protect_test pattern
> in ARM backend. It would be nice though if the address could be marked such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85434
--- Comment #3 from Thomas Preud'homme ---
(In reply to Thomas Preud'homme from comment #2)
> (In reply to Thomas Preud'homme from comment #1)
> > This is caused by missing stack_protect_set and stack_protect_test pattern
> > in ARM backend. It w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85261
--- Comment #5 from Thomas Preud'homme ---
Author: thopre01
Date: Wed Apr 18 11:42:10 2018
New Revision: 259465
URL: https://gcc.gnu.org/viewcvs?rev=259465&root=gcc&view=rev
Log:
[ARM] Fix PR85261: ICE with FPSCR setter builtin
Instruction patt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85261
--- Comment #6 from Thomas Preud'homme ---
Author: thopre01
Date: Wed Apr 18 13:17:30 2018
New Revision: 259469
URL: https://gcc.gnu.org/viewcvs?rev=259469&root=gcc&view=rev
Log:
[ARM] Fix PR85261: ICE with FPSCR setter builtin
Instruction patt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85261
Thomas Preud'homme changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85434
--- Comment #5 from Thomas Preud'homme ---
(In reply to Wilco from comment #4)
> Clearly rematerialization isn't working correctly. Immediates and constant
> addresses like this should never be spilled (using MOV/MOVK could increase
> codesize, b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85434
--- Comment #6 from Thomas Preud'homme ---
(In reply to Thomas Preud'homme from comment #3)
>
> My feeling is that the target patterns should also do the address
> computation, ie stack_protect_set and stack_protect_test would take that MEM
> of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85434
--- Comment #7 from Thomas Preud'homme ---
(In reply to Thomas Preud'homme from comment #6)
> (In reply to Thomas Preud'homme from comment #3)
> >
> > My feeling is that the target patterns should also do the address
> > computation, ie stack_pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85434
--- Comment #8 from Thomas Preud'homme ---
(In reply to Thomas Preud'homme from comment #7)
> (In reply to Thomas Preud'homme from comment #6)
> > (In reply to Thomas Preud'homme from comment #3)
> > >
> > > My feeling is that the target pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401
Thomas Preud'homme changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
CC||m...@3am-software.com
Assignee|thopre01 at gcc dot gnu.org|unassigned at gcc dot
gnu.org
Ever confirmed|1 |0
--- Comment #2 from Thomas Preud'homme ---
Actually given where the fault occurs this does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85434
--- Comment #9 from Thomas Preud'homme ---
Managed to reach a state where nothing is spilled on the stack for Thumb-1
either. I want to do 3 more changes before I start full testing:
- put some compiler barrier between address computation and can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69866
Thomas Preud'homme changed:
What|Removed |Added
Known to work||8.1.0
--- Comment #15 from Thomas P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71878
Thomas Preud'homme changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85434
--- Comment #11 from Thomas Preud'homme ---
I've started to work on a new patch according to review feedbacks. I've reached
the stage where I can compile without -fPIC with the stack protect test being
an UNSPEC split after register allocation as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85434
--- Comment #12 from Thomas Preud'homme ---
(In reply to Thomas Preud'homme from comment #11)
> I've started to work on a new patch according to review feedbacks. I've
> reached the stage where I can compile without -fPIC with the stack protect
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85434
--- Comment #13 from Thomas Preud'homme ---
Remains now:
1) add support for PIC access to the guard
2) finish cleanup of the patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85434
--- Comment #14 from Thomas Preud'homme ---
(In reply to Thomas Preud'homme from comment #13)
> Remains now:
>
> 1) add support for PIC access to the guard
> 2) finish cleanup of the patch
Except for a few missing comments, it's all there. I'll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85434
--- Comment #15 from Thomas Preud'homme ---
(In reply to Thomas Preud'homme from comment #14)
> (In reply to Thomas Preud'homme from comment #13)
> > Remains now:
> >
> > 1) add support for PIC access to the guard
> > 2) finish cleanup of the pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85434
Thomas Preud'homme changed:
What|Removed |Added
Alias||CVE-2018-12886
--- Comment #16 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84272
--- Comment #7 from Thomas Preud'homme ---
Hi Jakub,
First of all, thanks for beating me to it. Wanted to look at it but am fighting
strong headache since Wednesday.
Regarding the second patch, I believe it is the right approach but found
anoth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84272
--- Comment #10 from Thomas Preud'homme ---
(In reply to Jakub Jelinek from comment #9)
> Created attachment 43384 [details]
> gcc8-pr84272.patch
>
> So like this? A few additional changes, Florian Weimer suggested using
> preincrement instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85434
--- Comment #17 from Thomas Preud'homme ---
Patch has been posted for review:
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00246.html
01 at gcc dot gnu.org|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69866
--- Comment #16 from Thomas Preud'homme ---
@honza: would you mind backporting to GCC 7? IIRW GCC 6 backport is more
tricky.
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86673
--- Comment #6 from Thomas Preud'homme ---
The following simpler testcase also shows the problem:
void fn1() {
register const int h asm("r2") = 1;
__asm__(".ifnc %0,r2; .err; .endif\n\t"
"bl __put_user_4" :: "r"(h));
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86673
--- Comment #7 from Thomas Preud'homme ---
(In reply to Thomas Preud'homme from comment #6)
> The following simpler testcase also shows the problem:
>
> void fn1() {
> register const int h asm("r2") = 1;
> __asm__(".ifnc %0,r2; .err; .endif\
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86673
--- Comment #8 from Thomas Preud'homme ---
(In reply to Thomas Preud'homme from comment #7)
> (In reply to Thomas Preud'homme from comment #6)
> > The following simpler testcase also shows the problem:
> >
> > void fn1() {
> > register const i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85434
--- Comment #18 from Thomas Preud'homme ---
Author: thopre01
Date: Thu Aug 2 09:07:17 2018
New Revision: 263245
URL: https://gcc.gnu.org/viewcvs?rev=263245&root=gcc&view=rev
Log:
[ARM] Fix PR85434: spilling of stack protector guard's address on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85434
--- Comment #20 from Thomas Preud'homme ---
(In reply to Christophe Lyon from comment #19)
> Created attachment 44489 [details]
> Source file causing ICE on aarch64
>
> With your patch, GCC crashes with target aarch64-none-linux-gnu
> aarch64-no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86834
--- Comment #2 from Thomas Preud'homme ---
Thanks for the detailed report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86834
Thomas Preud'homme changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
ignee|unassigned at gcc dot gnu.org |thopre01 at gcc dot
gnu.org
--- Comment #2 from Thomas Preud'homme ---
Can reproduce.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87374
Thomas Preud'homme changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87374
--- Comment #4 from Thomas Preud'homme ---
My approach was wrong, fundamentally -mslow-flash-data and -mword-relocations
cannot both be in effect since there is then no way to load an address:
- -mslow-flash-data forbids literal pools
- -mword-re
CC||thopre01 at gcc dot gnu.org
--- Comment #2 from Thomas Preud'homme ---
Just hit it again with yesterday's trunk on the compile farm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87156
--- Comment #5 from Thomas Preud'homme ---
(In reply to Paul Hua from comment #4)
> (In reply to Jan Hubicka from comment #3)
> > Does the attached patch fix the bootstrap?
> > Index: cgraphclones.c
> > ===
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79085
--- Comment #8 from Thomas Preud'homme ---
(In reply to Jakub Jelinek from comment #7)
> Created attachment 43668 [details]
> gcc8-pr79085.patch
>
> Untested fix.
That fixes the original testcase for me. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79085
--- Comment #11 from Thomas Preud'homme ---
(In reply to Jakub Jelinek from comment #10)
> Fixed for 8.1+ so far.
Hi Jakub,
Are you planning to do a backport?
Best regards.
Severity: normal
Priority: P3
Component: target
Assignee: thopre01 at gcc dot gnu.org
Reporter: thopre01 at gcc dot gnu.org
Target Milestone: ---
Target: arm-none-eabi
Hi,
The cmse_nonsecure_caller intrinsic for Armv8-M Baseline and Mainline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85203
--- Comment #1 from Thomas Preud'homme ---
Author: thopre01
Date: Wed Apr 4 17:31:46 2018
New Revision: 259097
URL: https://gcc.gnu.org/viewcvs?rev=259097&root=gcc&view=rev
Log:
[ARM] Fix PR85203: cmse_nonsecure_caller returns wrong result
__b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85203
Thomas Preud'homme changed:
What|Removed |Added
Known to work||8.0
Known to fail|8.0
Priority: P3
Component: target
Assignee: thopre01 at gcc dot gnu.org
Reporter: thopre01 at gcc dot gnu.org
Target Milestone: ---
Target: arm-none-eabi
The following code ICES when compiled with -mcpu=cortex-m4 -mfloat-abi=hard
-mfpu=fpv4-sp-d16 on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85261
Thomas Preud'homme changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85261
Thomas Preud'homme changed:
What|Removed |Added
Known to fail||6.4.1, 7.3.1
--- Comment #3 from Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968
--- Comment #6 from Thomas Preud'homme ---
Happens at expand time. Diving in.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968
Thomas Preud'homme changed:
What|Removed |Added
CC||thopre01 at gcc dot gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968
--- Comment #8 from Thomas Preud'homme ---
(In reply to Thomas Preud'homme from comment #7)
> (In reply to Thomas Preud'homme from comment #6)
> > Happens at expand time. Diving in.
>
> There's a giant if in expand_expr_real_1 with the following
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968
--- Comment #9 from Thomas Preud'homme ---
(In reply to Thomas Preud'homme from comment #8)
> (In reply to Thomas Preud'homme from comment #7)
> > (In reply to Thomas Preud'homme from comment #6)
> > > Happens at expand time. Diving in.
> >
> >
irmed||2018-10-09
Assignee|unassigned at gcc dot gnu.org |thopre01 at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #10 from Thomas Preud'homme ---
(In reply to Thomas Preud'homme from comment #8)
> (In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968
--- Comment #12 from Thomas Preud'homme ---
(In reply to Eric Botcazou from comment #11)
> > Therefore unaligned access are handled by extract_bit_field. This in turns
> > call extract_bit_field_1 and later extract_integral_bit_field where things
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968
--- Comment #14 from Thomas Preud'homme ---
(In reply to Eric Botcazou from comment #13)
> > Forgive my naive question as I'm not too familiar with that part of the
> > compiler: why should the get_best_mem_extraction_insn be guarded with
> > rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87374
--- Comment #5 from Thomas Preud'homme ---
Author: thopre01
Date: Wed Oct 31 10:05:54 2018
New Revision: 265662
URL: https://gcc.gnu.org/viewcvs?rev=265662&root=gcc&view=rev
Log:
Fix PR87374: ICE with -mslow-flash-data and -mword-relocations
GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64616
Thomas Preud'homme changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34503
Bug 34503 depends on bug 64616, which changed state.
Bug 64616 Summary: Redundant ldr when accessing var inside and outside a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64616
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87374
Thomas Preud'homme changed:
What|Removed |Added
Known to work||9.0
Known to fail|9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87867
--- Comment #3 from Thomas Preud'homme ---
Author: thopre01
Date: Wed Nov 21 16:50:37 2018
New Revision: 266348
URL: https://gcc.gnu.org/viewcvs?rev=266348&root=gcc&view=rev
Log:
2018-11-21 Mihail Ionescu
gcc/
PR target/87867
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85434
--- Comment #21 from Thomas Preud'homme ---
Author: thopre01
Date: Thu Nov 22 14:46:17 2018
New Revision: 266379
URL: https://gcc.gnu.org/viewcvs?rev=266379&root=gcc&view=rev
Log:
PR85434: Prevent spilling of stack protector guard's address on A
irmed||2018-11-22
CC||thopre01 at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |mihail.ionescu at arm
dot com
Ever confirmed|0 |1
irmed||2018-11-23
CC||thopre01 at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |mihail.ionescu at arm
dot com
Ever confirmed|0 |1
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: thopre01 at gcc dot gnu.org
CC: rguenther at suse dot de
Target Milestone: ---
Target: arm-none-eabi
Created attachment 37537
--> https://gcc.gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69764
Thomas Preud'homme changed:
What|Removed |Added
CC||thopre01 at gcc dot gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69371
Thomas Preud'homme changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68632
Thomas Preud'homme changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69076
Thomas Preud'homme changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69586
--- Comment #2 from Thomas Preud'homme ---
Hi Richard,
Any progress on this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69586
--- Comment #8 from Thomas Preud'homme ---
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196
Thomas Preud'homme changed:
What|Removed |Added
CC||thopre01 at gcc dot gn
CC||thopre01 at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #26 from Thomas Preud'homme ---
Fixed as of r222512
: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: thopre01 at gcc dot gnu.org
Target Milestone: ---
Target: arm-none-eabi
g++.dg/lto/pr69589 fails on trunk for arm-none-eabi target with the following
error:
unrecognized command line option '-rdy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
--- Comment #9 from Thomas Preud'homme ---
(In reply to Richard Biener from comment #7)
> The bswap pass could learn to split this up into two loads and bswaps and
> combine the results with a single shift and or.
I'll add it to the bswap TODO l
: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: thopre01 at gcc dot gnu.org
CC: ramana.radhakrishnan at arm dot com
Target Milestone: ---
Target: arm-none-eabi
gcc.target/arm/pr70496.c fails with the following error when targeting
Cortex-M3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70553
--- Comment #1 from Thomas Preud'homme ---
Author: thopre01
Date: Thu Apr 7 16:19:20 2016
New Revision: 234811
URL: https://gcc.gnu.org/viewcvs?rev=234811&root=gcc&view=rev
Log:
2016-04-07 Thomas Preud'homme
gcc/testsuite/
PR tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70553
--- Comment #3 from Thomas Preud'homme ---
(In reply to Ramana Radhakrishnan from comment #2)
> Fixed then ?
Yes, sorry.
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: thopre01 at gcc dot gnu.org
CC: redi at gcc dot gnu.org
Target Milestone: ---
Target: arm-none-eabi
Hi,
experimental/memory_resource/1.cc test in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71081
--- Comment #3 from Thomas Preud'homme ---
Author: thopre01
Date: Fri May 20 12:36:57 2016
New Revision: 236507
URL: https://gcc.gnu.org/viewcvs?rev=236507&root=gcc&view=rev
Log:
2016-05-20 Thomas Preud'homme
PR libstdc++/71081
* tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71490
Thomas Preud'homme changed:
What|Removed |Added
CC||thopre01 at gcc dot gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71490
--- Comment #3 from Thomas Preud'homme ---
Differences start at sink phase:
@@ -46,17 +56,17 @@ f (int s, int * c)
_2 = a1.0_1 * 4;
_3 = -_2;
x1_14 = c_13(D) + _3;
- a2_15 = s_11(D) * 4;
- a2.1_4 = (unsigned int) a2_15;
- _5 = a2.1_4
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thopre01 at gcc dot gnu.org
Target Milestone: ---
Target: arm-none-eabi
Hi,
The following testcase ICEs on arm-none-eabi targets when compiled for C++14:
** foo.cc **
class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81942
Thomas Preud'homme changed:
What|Removed |Added
Keywords|ice-on-invalid-code |ice-on-valid-code
--- Comment #2 fr
-eabi
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-08-24
CC||thopre01 at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Thomas Preud'homme ---
Same issue on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81942
--- Comment #7 from Thomas Preud'homme ---
Hi Paolo,
Thanks for working on this.
(In reply to Paolo Carlini from comment #6)
> It would be nice if somebody with a fully functional ARM toolchain could
> check whether something like the below at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81942
--- Comment #15 from Thomas Preud'homme ---
(In reply to Jakub Jelinek from comment #14)
> The patch LGTM, but I'll defer the final say to Jason/Nathan.
FYI I tried the patch on arm-none-eabi toolchain and it fixes the bug reported.
Best regard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78269
--- Comment #6 from Thomas Preud'homme ---
(In reply to Paolo Carlini from comment #5)
> Thomas, both trunk and gcc-7-brnanch seem fine to me, I'm tempted to close
> the bug. Can you double check the released 7.1.0 on aarch64?
Hi Paolo,
yes I c
Assignee: unassigned at gcc dot gnu.org
Reporter: thopre01 at gcc dot gnu.org
Target Milestone: ---
Target: arm-none-eabi
Hi,
gcc.dg/tree-ssa/pr81588.c scan-tree-dump-times fails on GCC 7 (but not on
trunk) for Arm Cortex-M0, Cortex-M3 and Cortex-M4 cores. It does work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78269
--- Comment #9 from Thomas Preud'homme ---
(In reply to Paolo Carlini from comment #8)
> Confirmed that 7.1.0 is fine.
It is indeed. As can be seen in my comment #4, this was fixed somewhere before
14th of November 2016, well before GCC 7 releas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78269
--- Comment #10 from Thomas Preud'homme ---
(In reply to Thomas Preud'homme from comment #9)
> (In reply to Paolo Carlini from comment #8)
> > Confirmed that 7.1.0 is fine.
>
> It is indeed. As can be seen in my comment #4, this was fixed somewh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82120
--- Comment #3 from Thomas Preud'homme ---
(In reply to Jakub Jelinek from comment #2)
> This is a total mess. I've copied a boilerplate from other tests that
> require branch cost of 2.
> I guess
> 2017-09-06 Jakub Jelinek
>
> PR test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80352
--- Comment #4 from Thomas Preud'homme ---
(In reply to Vladimir Makarov from comment #1)
> Thomas, it seems from your description the problem really exists. I tried
> to reproduce the problem with the test you provided but I've failed. I used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80352
--- Comment #5 from Thomas Preud'homme ---
FWIW, I've configured GCC with --target=arm-none-eabi --with-cpu=cortex-m7
--with-mode=thumb and then ran make all-gcc. I think it would work equally well
without the cpu and mode given that these are gi
1 - 100 of 431 matches
Mail list logo
