[Bug target/99660] [11 Regression] vxworksae/mils cross build failure, missing VX_CPU_PREFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99660 Olivier Hainque changed: What|Removed |Added Resolution|--- |FIXED Target|i686-wrs-vxworksae |i686-wrs-vxworksae, ||powerpc-wrs-vxworksae, ||powerpc-wrs-vxworksmils Status|ASSIGNED|RESOLVED Summary|[11 Regression] Cross |[11 Regression] |compiler cannot be built: |vxworksae/mils cross build |i686-wrs-vxworksae since|failure, missing |g:9a835ba4c00bc5f183a26a533 |VX_CPU_PREFIX |5f14a2a428a2b78 | --- Comment #5 from Olivier Hainque --- Fixed on mainline.
[Bug target/99660] [11 Regression] Cross compiler cannot be built: i686-wrs-vxworksae since g:9a835ba4c00bc5f183a26a5335f14a2a428a2b78
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99660 Olivier Hainque changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-03-19 Assignee|unassigned at gcc dot gnu.org |hainque at gcc dot gnu.org --- Comment #3 from Olivier Hainque --- Thanks for opening this PR Martin.
[Bug target/63908] [e500v2] "float_bessel"case failed on e500v2 platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63908 --- Comment #11 from Olivier Hainque --- Created attachment 43406 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43406&action=edit cumulative patch used in-house on gcc-4.9 Attached is a cumulative patch of what we have applied in-house on gcc-4.9. Hope this can help. Olivier
[Bug bootstrap/81470] [8 Regression] Bootstrap comparison failures in gcc/ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81470 --- Comment #16 from Olivier Hainque --- Author: hainque Date: Fri Dec 8 09:33:08 2017 New Revision: 255501 URL: https://gcc.gnu.org/viewcvs?rev=255501&root=gcc&view=rev Log: 2017-06-08 Tristan Gingold PR ada/81470 * dwarf2out.c (dwarf2out_do_cfi_startproc): Only emit .cfi_personality or .cfi_lsda if the eh data format is dwarf2. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug bootstrap/81470] [8 Regression] Bootstrap comparison failures in gcc/ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81470 Olivier Hainque changed: What|Removed |Added Attachment #42747|[patch] don't emit |don't emit description|.cfi_personality/.cfi_lsda |.cfi_personality/.cfi_lsda |for !dwarf2 eh |for !dwarf2 eh --- Comment #11 from Olivier Hainque --- Comment on attachment 42747 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42747 don't emit .cfi_personality/.cfi_lsda for !dwarf2 eh >diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c >index 3d619b8..62b5c77 100644 >--- a/gcc/dwarf2out.c >+++ b/gcc/dwarf2out.c >@@ -958,10 +958,16 @@ dwarf2out_do_cfi_startproc (bool second) > { > int enc; > rtx ref; >- rtx personality = get_personality_function (current_function_decl); > > fprintf (asm_out_file, "\t.cfi_startproc\n"); > >+ /* .cfi_personality and .cfi_lsda are only relevant to DWARF2 >+ eh unwinders. */ >+ if (targetm_common.except_unwind_info (&global_options) != UI_DWARF2) >+return; >+ >+ rtx personality = get_personality_function (current_function_decl); >+ > if (personality) > { > enc = ASM_PREFERRED_EH_DATA_FORMAT (/*code=*/2, /*global=*/1);
[Bug bootstrap/81470] [8 Regression] Bootstrap comparison failures in gcc/ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81470 --- Comment #10 from Olivier Hainque --- Created attachment 42747 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42747&action=edit [patch] don't emit .cfi_personality/.cfi_lsda for !dwarf2 eh We had a patch for something of this kind we had observed with local versions of gcc-6. We just recently observed the same failure/correction on gcc-7 and I was about to propose the patch for inclusion. The issue is differences in the generation of some data items between -g and -g2, visible with LDFCM labels in particular. These are somehow related to the emission of .cfi_personality and .cfi_lsda by dwarf2out_do_cfi_startproc which aren't needed for SEH anyway. The proposed patch just prevents the generation of those .cfi notes if the target eh format isn't dwarf2.
[Bug target/81755] Building of cross compiler for powerpc-wrs-vxworksmils is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81755 Olivier Hainque changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Olivier Hainque --- fixed on mainline
[Bug target/81755] Building of cross compiler for powerpc-wrs-vxworksmils is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81755 --- Comment #2 from Olivier Hainque --- Author: hainque Date: Mon Aug 7 20:13:53 2017 New Revision: 250931 URL: https://gcc.gnu.org/viewcvs?rev=250931&root=gcc&view=rev Log: Olivier Hainque PR target/81755 * config/vxworksae.h (VXWORKS_HAVE_TLS): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/config/vxworksae.h
[Bug target/81755] Building of cross compiler for powerpc-wrs-vxworksmils is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81755 Olivier Hainque changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-08-07 Ever confirmed|0 |1 --- Comment #1 from Olivier Hainque --- mine
[Bug target/77687] frame access after release without redzone on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77687 Olivier Hainque changed: What|Removed |Added Last reconfirmed|2017-03-03 00:00:00 |2017-6-15 Known to work|7.0 | Known to fail||7.1.1 --- Comment #6 from Olivier Hainque --- Hi Segher, I'm still seing wrong code out gcc-7 and mainline for the example (sorry): void g(int, char *); const char * dum = "hello"; void f(int x) { char big[20]; start: g(x, big); g(x, big); register void *p asm("r11") = &&start; asm("" : : "r"(p)); asm("" : : :"r28"); asm("" : : :"r29"); asm("" : : :"r30"); } configure --target=powerpc-elf --enable-languages=c --disable-multilib ./cc1 -O2 t.c -o - f: [...] lwz 11,0(1) lwz 0,4(11) mr 1,11 -- hmmm lwz 28,-16(11) mtlr 0 lwz 29,-12(11) -- err lwz 30,-8(11) lwz 31,-4(11) blr .ident "GCC: (GNU) 8.0.0 20170615 (experimental)" Can you please have a look ? Please let me know if there's anything I can do to help. Thanks much in advance!
[Bug target/77687] frame access after release without redzone on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77687 --- Comment #2 from Olivier Hainque --- Thanks for stepping in Segher ! Much appreciated :-) FWIW, I have just attached the bandaid patch we're currently using on our gcc-6 based compilers. It's more brutal than the original suggestion on the referenced thread, which seemed fragile on a couple of accounts. This one is way simpler, both conceptually and implementation-wise, intended to be temporary until we devise a better resolution. I had started on an alternate resolution you suggested. Just didn't have the opportunity to get to finish it. I can post the partial patches if you believe that could be useful. But maybe we'll converge on something else entirely anyway. Olivier
[Bug target/77687] frame access after release without redzone on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77687 --- Comment #1 from Olivier Hainque --- Created attachment 39899 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39899&action=edit bandaid patch we're currently using
[Bug target/77687] New: frame access after release without redzone on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77687 Bug ID: 77687 Summary: frame access after release without redzone on powerpc Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hainque at gcc dot gnu.org CC: segher at kernel dot crashing.org Target Milestone: --- Target: powerpc-elf, powerpc-eabispe Created attachment 39672 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39672&action=edit testcase As discussed with Segher at the GNU cauldron this summer, filing a PR for the problem described and discussed from https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01337.html The problem is still visible on mainline with a cross compiler configured for powerpc-elf, on this artificial case forcing the right combination of internal circumstances: /* t.c */ void g(int, char *); const char * dum = "hello"; void f(int x) { char big[20]; start: g(x, big); g(x, big); register void *p asm("r11") = &&start; asm("" : : "r"(p)); asm("" : : :"r28"); asm("" : : :"r29"); asm("" : : :"r30"); } ./cc1 -O2 t.c -o - -mregnames lwz %r11,0(%r1)# retrieve frame pointer ... mr %r1,%r11# release frame lwz %r29,-12(%r11) # read from frame mtlr %r0 lwz %r30,-8(%r11) # ... lwz %r31,-4(%r11) # ... blr I'll attach the patch we have been using locally as a stop-gap measure. At some point in the thread, from https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00764.html Segher suggested: << I think the best thing to do is add the clobber-of-mem-scratch to the final stack deallocate (as a parallel). I don't see anything else that will work reliably. >> I have the start of a patch for this as well (based on gcc-6). Still missing the definition of the proper insn pattern to recognize the parallel. Olivier
[Bug target/53271] New: powerpc-eabispe build fails with ice on unwind-dw2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53271 Bug #: 53271 Summary: powerpc-eabispe build fails with ice on unwind-dw2.c Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: hain...@gcc.gnu.org Using an up to date trunk on a x86-linux host or alike, assuming cross binutils for powerpc-eabispe available in $prefix. $gccsrcdir/configure --target=powerpc-eabispe --enable-languages=c --disable-libada --prefix=$prefix make CFLAGS="-O0 -g" fails with << In file included from .../libgcc/unwind-dw2.c:1633:0: .../libgcc/unwind.inc: In function â_Unwind_RaiseExceptionâ: .../libgcc/unwind.inc:136:1: internal compiler error: in emit_frame_save, at config/rs6000/rs6000.c:18979 >> Visible using the reproducer below: void install (long offset, void * handler) { volatile int x [4096]; __builtin_eh_return (offset, handler); } ./cc1 ice.c ... ice.c: In function "install": ice.c:6:1: internal compiler error: in emit_frame_save, at config/rs6000/rs6000.c:18979 Presumably a fallout of rev 186797 (from http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01014.html), in particular: (emit_frame_save): Don't handle reg+reg addressing. Olivier