[Bug target/88167] [ARM] Function __builtin_return_address returns invalid address

||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

[Bug target/87883] [ARM] ICE: Segmentation fault in arm_regno_class

||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

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

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=gcc=rev Log: PR85434: Prevent spilling of stack protector guard's address on ARM In

[Bug target/87867] [7 regression] ICE on virtual destructor (-mlong-calls -ffunction-sections) on arm-none-eabi

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=gcc=rev Log: 2018-11-21 Mihail Ionescu gcc/ PR target/87867 Backport

[Bug target/87374] [8/9 Regression] ICE in extract_insn, at recog.c:2305

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

[Bug rtl-optimization/34503] Issues with constant/copy propagation implementation in gcse.c

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

[Bug rtl-optimization/64616] Redundant ldr when accessing var inside and outside a loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64616 Thomas Preud'homme changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug target/87374] [8/9 Regression] ICE in extract_insn, at recog.c:2305

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=gcc=rev Log: Fix PR87374: ICE with -mslow-flash-data and -mword-relocations GCC ICEs

[Bug target/86968] Unaligned big-endian (scalar_storage_order) access on armv7-a yields 4 ldrb instructions rather than ldr+rev

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 > >

[Bug target/86968] Unaligned big-endian (scalar_storage_order) access on armv7-a yields 4 ldrb instructions rather than ldr+rev

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

[Bug target/86968] Unaligned big-endian (scalar_storage_order) access on armv7-a yields 4 ldrb instructions rather than ldr+rev

||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 Thomas Preud'ho

[Bug target/86968] Unaligned big-endian (scalar_storage_order) access on armv7-a yields 4 ldrb instructions rather than ldr+rev

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. > > > >

[Bug target/86968] Unaligned big-endian (scalar_storage_order) access on armv7-a yields 4 ldrb instructions rather than ldr+rev

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

[Bug target/86968] Unaligned big-endian (scalar_storage_order) access on armv7-a yields 4 ldrb instructions rather than ldr+rev

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968 Thomas Preud'homme changed: What|Removed |Added CC||thopre01 at gcc dot gnu.org

[Bug target/86968] Unaligned big-endian (scalar_storage_order) access on armv7-a yields 4 ldrb instructions rather than ldr+rev

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968 --- Comment #6 from Thomas Preud'homme --- Happens at expand time. Diving in.

[Bug target/87156] [9 Regression] ICE building libstdc++ for mips64

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 > >

[Bug target/87156] [9 Regression] ICE building libstdc++ for mips64

||thopre01 at gcc dot gnu.org --- Comment #2 from Thomas Preud'homme --- Just hit it again with yesterday's trunk on the compile farm.

[Bug target/87374] [8/9 Regression] ICE in extract_insn, at recog.c:2305

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 -

[Bug target/87374] [8/9 Regression] ICE in extract_insn, at recog.c:2305

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87374 Thomas Preud'homme changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from

[Bug target/87374] [8/9 Regression] ICE in extract_insn, at recog.c:2305

|unassigned at gcc dot gnu.org |thopre01 at gcc dot gnu.org --- Comment #2 from Thomas Preud'homme --- Can reproduce.

[Bug other/86834] [9 regression] several tests fail with ICE starting with r263245

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86834 Thomas Preud'homme changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|---

[Bug other/86834] [9 regression] several tests fail with ICE starting with r263245

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86834 --- Comment #2 from Thomas Preud'homme --- Thanks for the detailed report.

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

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 >

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

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=gcc=rev Log: [ARM] Fix PR85434: spilling of stack protector guard's address on ARM In

[Bug target/86673] [8/9 regression] inline asm sometimes ignores 'register asm("reg")' declarations

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

[Bug target/86673] [8/9 regression] inline asm sometimes ignores 'register asm("reg")' declarations

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;

[Bug target/86673] [8/9 regression] inline asm sometimes ignores 'register asm("reg")' declarations

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)); }

[Bug lto/69866] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158

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!

[Bug lto/69866] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158

at gcc dot gnu.org|unassigned at gcc dot gnu.org

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

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

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85434 Thomas Preud'homme changed: What|Removed |Added Alias||CVE-2018-12886 --- Comment #16

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

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

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

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.

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

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

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

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

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

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

[Bug rtl-optimization/71878] ICE in cselib_record_set

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71878 Thomas Preud'homme changed: What|Removed |Added Status|NEW |RESOLVED Known to work|

[Bug lto/69866] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158

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

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

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

[Bug target/85401] segfault building code for VAX

||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 seem

[Bug target/85401] segfault building code for VAX

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401 Thomas Preud'homme changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

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

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

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

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

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 >

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

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,

[Bug target/85261] __builtin_arm_set_fpscr ICEs with constant input

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85261 Thomas Preud'homme changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|

[Bug target/85261] __builtin_arm_set_fpscr ICEs with constant input

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=gcc=rev Log: [ARM] Fix PR85261: ICE with FPSCR setter builtin Instruction pattern for

[Bug target/85261] __builtin_arm_set_fpscr ICEs with constant input

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=gcc=rev Log: [ARM] Fix PR85261: ICE with FPSCR setter builtin Instruction pattern for

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

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

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

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

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85434 Thomas Preud'homme changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[Bug target/85434] New: Address of stack protector guard spilled to stack on ARM

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

[Bug middle-end/85344] Constant constraint check sign extends unsigned constant input operands

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

[Bug middle-end/85344] Constant constraint check sign extends unsigned constant input operands

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85344 Thomas Preud'homme changed: What|Removed |Added Keywords||wrong-code --- Comment #4 from

[Bug middle-end/85344] Constant constraint check sign extends unsigned constant input operands

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)); }

[Bug middle-end/85344] Constant constraint check sign extends unsigned constant input operands

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85344 --- Comment #2 from Thomas Preud'homme --- I have a patch, starting testing.

[Bug middle-end/85344] Constant constraint check sign extends unsigned constant input operands

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85344 Thomas Preud'homme changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[Bug middle-end/85344] New: Constant constraint check sign extends unsigned constant input operands

-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

[Bug target/85261] __builtin_arm_set_fpscr ICEs with constant input

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=gcc=rev Log: [ARM] Fix PR85261: ICE with FPSCR setter builtin Instruction pattern for

[Bug target/85203] cmse_nonsecure_caller intrinsic returns incorrect results

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=gcc=rev Log: [ARM] Fix PR85203: cmse_nonsecure_caller returns wrong result

[Bug target/85261] __builtin_arm_set_fpscr ICEs with constant input

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

[Bug target/85261] __builtin_arm_set_fpscr ICEs with constant input

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85261 Thomas Preud'homme changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[Bug target/85261] New: __builtin_arm_set_fpscr ICEs with constant input

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

[Bug target/85203] cmse_nonsecure_caller intrinsic returns incorrect results

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

[Bug target/85203] cmse_nonsecure_caller intrinsic returns incorrect results

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=gcc=rev Log: [ARM] Fix PR85203: cmse_nonsecure_caller returns wrong result

[Bug target/85203] New: cmse_nonsecure_caller intrinsic returns incorrect results

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

[Bug c++/79085] [6/7 Regression] ICE with placement new to unaligned location

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.

[Bug c++/79085] [6/7/8 Regression] ICE with placement new to unaligned location

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!

[Bug target/84272] [8 Regression] AddressSanitizer: heap-use-after-free ../../gcc/config/aarch64/cortex-a57-fma-steering.c:519 in fma_node::get_parity()

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

[Bug target/84272] [8 Regression] AddressSanitizer: heap-use-after-free ../../gcc/config/aarch64/cortex-a57-fma-steering.c:519 in fma_node::get_parity()

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

[Bug c/78768] -Walloca-larger-than and -Wformat-length warnings disabled by -flto

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78768 --- Comment #11 from Thomas Preud'homme --- (In reply to Martin Sebor from comment #10) > The test was changed to link-only (to exercise LTO) in r244385. I think you meant r244537

[Bug tree-optimization/83216] [8 regression] FAIL: gcc.dg/graphite/interchange-3.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83216 --- Comment #6 from Thomas Preud'homme --- (In reply to rguent...@suse.de from comment #5) > On November 29, 2017 4:35:12 PM GMT+01:00, "thopre01 at gcc dot gnu.org" > <gcc-bugzi...@gcc.gnu.org> wrote: > >

[Bug tree-optimization/83216] [8 regression] FAIL: gcc.dg/graphite/interchange-3.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83216 --- Comment #3 from Thomas Preud'homme --- (In reply to Richard Biener from comment #2) > Can't reproduce > > What ISL version are you using? ISL 0.15. Also my apologies but I haven't tried on Arm Cortex-M7 yet actually, typed it in as a

[Bug tree-optimization/83216] New: [8 regression] FAIL: gcc.dg/graphite/interchange-3.c

Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: thopre01 at gcc dot gnu.org Target Milestone: --- Target: arm-none-eabi Hi, The following tests started to fail on arm-none-eabi targets after commit r253809: PASS->FAIL: gcc.dg/graph

[Bug debug/83199] [8 Regression] FAIL: gdb.base/async.exp & gdb.base/skip.exp

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83199 --- Comment #5 from Thomas Preud'homme --- Created attachment 42742 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42742=edit Executable async and skip produced by GCC trunk

[Bug debug/83199] [8 Regression] FAIL: gdb.base/async.exp & gdb.base/skip.exp

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83199 --- Comment #2 from Thomas Preud'homme --- (In reply to Richard Biener from comment #1) > Are we sure this is not gdbs fault? GDB version was fixed when I did my bisect. That said, I don't know what sort of change happened in DWARF so it may

[Bug debug/83199] New: FAIL: gdb.base/async.exp & gdb.base/skip.exp

rmal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: thopre01 at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- Target: arm-none-eabi Hi, The following tests regressed on arm-none-eabi targets a

[Bug lto/69866] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69866 --- Comment #14 from Thomas Preud'homme --- Author: thopre01 Date: Tue Nov 28 15:19:14 2017 New Revision: 255203 URL: https://gcc.gnu.org/viewcvs?rev=255203=gcc=rev Log: Fix ICE in add_symbol_to_partition_1 2017-11-28 Thomas Preud'homme

[Bug c/82817] C frontend errors on SSA name from REG_EXPR

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82817 --- Comment #6 from Thomas Preud'homme --- (In reply to Richard Biener from comment #5) > (In reply to Thomas Preud'homme from comment #4) > > (In reply to rguent...@suse.de from comment #3) > > > On Fri, 3 Nov 2017, thopre01

[Bug c/82817] C frontend errors on SSA name from REG_EXPR

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82817 --- Comment #4 from Thomas Preud'homme --- (In reply to rguent...@suse.de from comment #3) > On Fri, 3 Nov 2017, thopre01 at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82817 > > > > --

[Bug c/82817] C frontend errors on SSA name from REG_EXPR

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82817 --- Comment #2 from Thomas Preud'homme --- (In reply to Richard Biener from comment #1) > The GIMPLE FE also doesn't like that some variable names created by the > middle-end contain '.'. > > I belive it would be good to "fix"

[Bug c/82817] New: C frontend errors on SSA name from REG_EXPR

Assignee: unassigned at gcc dot gnu.org Reporter: thopre01 at gcc dot gnu.org CC: dmalcolm at gcc dot gnu.org Target Milestone: --- Created attachment 42538 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42538=edit unparsable RTL Hi, when parsing a __

[Bug middle-end/82815] New: RTL frontend errors out on const_double

Assignee: unassigned at gcc dot gnu.org Reporter: thopre01 at gcc dot gnu.org CC: dmalcolm at gcc dot gnu.org Target Milestone: --- Created attachment 42537 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42537=edit Testcase showing

[Bug tree-optimization/80155] [7/8 regression] Performance regression with code hoisting enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155 --- Comment #32 from Thomas Preud'homme --- (In reply to rguent...@suse.de from comment #31) > On Wed, 4 Oct 2017, prathamesh3492 at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155 > > > > prathamesh3492 at gcc

[Bug testsuite/82120] FAIL: gcc.dg/tree-ssa/pr81588.c

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

[Bug c++/78269] FAIL: FAIL: g++.dg/cpp1z/noexcept-type11.C and FAIL: g++.dg/cpp1z/noexcept-type9.C

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

[Bug c++/78269] FAIL: FAIL: g++.dg/cpp1z/noexcept-type11.C and FAIL: g++.dg/cpp1z/noexcept-type9.C

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

[Bug testsuite/82120] New: FAIL: gcc.dg/tree-ssa/pr81588.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

[Bug c++/78269] FAIL: FAIL: g++.dg/cpp1z/noexcept-type11.C and FAIL: g++.dg/cpp1z/noexcept-type9.C

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

[Bug c++/81942] ICE on empty constexpr constructor with C++14

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

[Bug c++/81942] ICE on empty constexpr constructor with C++14

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

[Bug target/81909] [nvptx] Missing warning in gcc.dg/pr53037-{2,3}.c

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-none-eabi

[Bug c++/81942] ICE on empty constexpr constructor with C++14

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

[Bug c++/81942] New: ICE on empty constexpr constructor with C++14

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

[Bug tree-optimization/81184] [8 regression] gcc.dg/pr21643.c and gcc.dg/tree-ssa/phi-opt-11.c fail starting with r249450

||thopre01 at gcc dot gnu.org --- Comment #2 from Thomas Preud'homme --- These testcases (gcc.dg/pr21643.c and gcc.dg/tree-ssa/phi-opt-11.c) also started to fail for ARM Cortex-M0, Cortex-M3 and Cortex-M4 arm-none-eabi targets.

[Bug rtl-optimization/81174] bswap not recognized in |= statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81174 --- Comment #3 from Thomas Preud'homme --- (In reply to Jakub Jelinek from comment #2) > Simplified testcase: > static inline unsigned > bar (unsigned x) > { > return ((x & 0x00ff) << 24) | ((x & 0xff00) << 8) >| ((x &

[Bug lto/69866] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69866 --- Comment #13 from Thomas Preud'homme --- Author: thopre01 Date: Wed Jun 21 08:17:56 2017 New Revision: 249437 URL: https://gcc.gnu.org/viewcvs?rev=249437=gcc=rev Log: 2017-06-21 Thomas Preud'homme

[Bug lto/69866] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69866 --- Comment #12 from Thomas Preud'homme --- Author: thopre01 Date: Tue Jun 20 11:19:36 2017 New Revision: 249406 URL: https://gcc.gnu.org/viewcvs?rev=249406=gcc=rev Log: Fix PR69866 2017-06-20 Thomas Preud'homme

[Bug target/71607] [5/6/7/8 Regression] [ARM] ice due to forbidden enabled attribute dependency on instruction operands

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71607 --- Comment #16 from Thomas Preud'homme --- Author: thopre01 Date: Mon Jun 19 15:01:11 2017 New Revision: 249372 URL: https://gcc.gnu.org/viewcvs?rev=249372=gcc=rev Log: PR71607: Fix ICE when loading constant 2017-06-19 Prakhar Bahuguna

[Bug testsuite/78318] FAIL: g++.dg/pr78112.C scan-assembler-times DW_AT_object_pointer 37

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78318 Thomas Preud'homme changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

  1   2   3   4   5   >