[Bug target/99660] [11 Regression] vxworksae/mils cross build failure, missing VX_CPU_PREFIX

2021-03-19 Thread hainque at gcc dot gnu.org via Gcc-bugs
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

2021-03-19 Thread hainque at gcc dot gnu.org via Gcc-bugs
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

2018-02-13 Thread hainque at gcc dot gnu.org
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=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

2017-12-08 Thread hainque at gcc dot gnu.org
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=gcc=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

2017-11-30 Thread hainque at gcc dot gnu.org
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 (_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

2017-11-29 Thread hainque at gcc dot gnu.org
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=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

2017-08-07 Thread hainque at gcc dot gnu.org
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

2017-08-07 Thread hainque at gcc dot gnu.org
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=gcc=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

2017-08-07 Thread hainque at gcc dot gnu.org
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

2017-06-15 Thread hainque at gcc dot gnu.org
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") = &
   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

2016-10-26 Thread hainque at gcc dot gnu.org
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

2016-10-26 Thread hainque at gcc dot gnu.org
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=edit
bandaid patch we're currently using

[Bug target/77687] New: frame access after release without redzone on powerpc

2016-09-22 Thread hainque at gcc dot gnu.org
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=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") = &
   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

2012-05-07 Thread hainque at gcc dot gnu.org
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