[PATCH] Support cfi pseudo for debugging on UI_DWARF2 target

[Tristan Gingold]

Hi,

this patch fixes a thinko in dwarf2out_do_cfi_asm: some targets 
(x86_64-windows) so support cfi psuedo for debug info, but not dwarf2 
exception cfi.


No regressions on x86_64-linux-gnu.

Ok to commit ?

2017-07-28  gingold  

* dwarf2out.c (dwarf2out_do_cfi_startproc): Return early if
there is a target-specific exception mechanism.

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 250563)
+++ gcc/dwarf2out.c (working copy)
@@ -958,10 +958,18 @@
 {
   int enc;
   rtx ref;
-  rtx personality = get_personality_function (current_function_decl);

   fprintf (asm_out_file, "\t.cfi_startproc\n");

+  /* Do not emit cfi pseudos for exceptions if DWARF2 mechanism is not 
used.

+ On most machine, cfi pseudos are also used for DWARF2 debug info, but
+ those for exceptions are supposed to be only used for DWARF2
+ mechanism.  */
+  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);

[PATCH] Add -nolibc option

[Tristan Gingold]

Hello,

this patch adds a new option -nolibc to supress -lc in the link command.
This refines -nostdlib/-nostartfiles/nodefaultlibs, so that it is 
possible to link with libgcc but without libc.


Our main use case is for embedded targets when we use the GNAT compiler 
without an installed libc.  Of course, in that case the gnat library has 
to provide its own memcpy/memset/memmove/memcmp if needed.


No regressions on x86_64-linux-gnu.
Ok to commit ?

Tristan.

2017-07-27  gingold  

* common.opt (nolibc): New option.
* doc/invoke.texi (Link Options): Document it.
* gcc.c (LINK_GCC_C_SEQUENCE_SPEC): Consider nolibc.
* config/arm/unknown-elf.h (LINK_GCC_C_SEQUENCE_SPEC): Likewise.

Index: gcc/common.opt
===
--- gcc/common.opt  (revision 250563)
+++ gcc/common.opt  (working copy)
@@ -2956,6 +2956,10 @@
 nostdlib
 Driver

+nolibc
+Driver
+Do not link with libc
+
 o
 Common Driver Joined Separate Var(asm_file_name) 
MissingArgError(missing filename after %qs)

 -o Place output into .
Index: gcc/config/arm/unknown-elf.h
===
--- gcc/config/arm/unknown-elf.h(revision 250563)
+++ gcc/config/arm/unknown-elf.h(working copy)
@@ -91,6 +91,6 @@
 /* The libgcc udivmod functions may throw exceptions.  If newlib is
configured to support long longs in I/O, then printf will depend on
udivmoddi4, which will depend on the exception unwind routines,
-   which will depend on abort, which is defined in libc.  */
+   which will depend on abort, which is defined in libc.  */
 #undef LINK_GCC_C_SEQUENCE_SPEC
-#define LINK_GCC_C_SEQUENCE_SPEC "--start-group %G %L --end-group"
+#define LINK_GCC_C_SEQUENCE_SPEC "--start-group %G %{!nolibc:%L} 
--end-group"

Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 250563)
+++ gcc/doc/invoke.texi (working copy)
@@ -495,8 +495,8 @@
 @item Linker Options
 @xref{Link Options,,Options for Linking}.
 @gccoptlist{@var{object-file-name}  -fuse-ld=@var{linker} 
-l@var{library} @gol

--nostartfiles  -nodefaultlibs  -nostdlib  -pie  -pthread  -rdynamic @gol
--s  -static  -static-libgcc  -static-libstdc++ @gol
+-nostartfiles  -nodefaultlibs  -nostdlib  -nolibc  -pie  -pthread @gol
+-rdynamic  -s  -static  -static-libgcc  -static-libstdc++ @gol
 -static-libasan  -static-libtsan  -static-liblsan  -static-libubsan @gol
 -static-libmpx  -static-libmpxwrappers @gol
 -shared  -shared-libgcc  -symbolic @gol
@@ -11760,6 +11760,12 @@
 constructors are called; @pxref{Collect2,,@code{collect2}, gccint,
 GNU Compiler Collection (GCC) Internals}.)

+@item -nolibc
+@opindex nolibc
+Do not use the standard C library when linking, but still link with
+start files and @file{libgcc.a}.  This is useful mainly on bare-board
+targets in the case there is no C library available.
+
 @item -pie
 @opindex pie
 Produce a position independent executable on targets that support it.
Index: gcc/gcc.c
===
--- gcc/gcc.c   (revision 250563)
+++ gcc/gcc.c   (working copy)
@@ -863,7 +863,7 @@
-lgcc and -lc order specially, yet not require them to override all
of LINK_COMMAND_SPEC.  */
 #ifndef LINK_GCC_C_SEQUENCE_SPEC
-#define LINK_GCC_C_SEQUENCE_SPEC "%G %L %G"
+#define LINK_GCC_C_SEQUENCE_SPEC "%G %{!nolibc:%L %G}"
 #endif

 #ifndef LINK_SSP_SPEC

Re: [Ada] Set Always_Compatible_Rep to False everywhere

[Tristan Gingold]

> On 16 Oct 2016, at 21:40, Eric Botcazou  wrote:
> 
>> Can this be refactored to avoid having to duplicate the whole file for
>> every target?
> 
> I'm not sure, maybe entries could be omitted if they match the default though.

Some files could be easily merged (like what was done for ppc and ppc-64).  For 
example:

$ diff system-linux-x86*
8c8
< -- (GNU-Linux/x86 Version)  --
---
> --   (GNU-Linux/x86-64 Version) --
72,73c72,73
Word_Size: constant := Standard'Word_Size;
>Memory_Size  : constant := 2 ** Word_Size;


Tristan.

[Patch] sync top level configure with binutils-gdb

[Tristan Gingold]

This patch was pushed on binutils-gdb repo, so I also commit it on gcc.

Tristan.


2015-11-20  Tristan Gingold  <ging...@adacore.com>

Sync with binutils-gdb:
2015-11-20  Tristan Gingold  <ging...@adacore.com>

* configure.ac: Add aarch64-*-darwin* and arm-*-darwin*.
* configure: Regenerate.

Index: configure
===
--- configure   (revision 230657)
+++ configure   (working copy)
@@ -3686,6 +3686,14 @@
 case "${target}" in
   *-*-chorusos)
 ;;
+  aarch64-*-darwin*)
+noconfigdirs="$noconfigdirs ld gas gdb gprof"
+noconfigdirs="$noconfigdirs sim target-rda"
+;;
+  arm-*-darwin*)
+noconfigdirs="$noconfigdirs ld gas gdb gprof"
+noconfigdirs="$noconfigdirs sim target-rda"
+;;
   powerpc-*-darwin*)
 noconfigdirs="$noconfigdirs ld gas gdb gprof"
 noconfigdirs="$noconfigdirs sim target-rda"
Index: configure.ac
===
--- configure.ac(revision 230657)
+++ configure.ac(working copy)
@@ -1023,6 +1023,14 @@
 case "${target}" in
   *-*-chorusos)
 ;;
+  aarch64-*-darwin*)
+noconfigdirs="$noconfigdirs ld gas gdb gprof"
+noconfigdirs="$noconfigdirs sim target-rda"
+;;
+  arm-*-darwin*)
+noconfigdirs="$noconfigdirs ld gas gdb gprof"
+noconfigdirs="$noconfigdirs sim target-rda"
+;;
   powerpc-*-darwin*)
 noconfigdirs="$noconfigdirs ld gas gdb gprof"
 noconfigdirs="$noconfigdirs sim target-rda"

Re: [Patch]: libbacktrace - add support of PE/COFF

[Tristan Gingold]

 On 28 May 2015, at 17:14, Ian Lance Taylor i...@google.com wrote:
 
 On Thu, May 28, 2015 at 5:01 AM, Tristan Gingold ging...@adacore.com wrote:
 
 On 28 May 2015, at 02:26, Ian Lance Taylor i...@google.com wrote:
 
 The #include windows.h will break cross-compilers.  It's not OK for
 trunk until that is fixed.
 
 I am confused by this comment, for two reasons:
 
 - I don’t see how that would break cross-compilers.  Cross compilers
 hosted on windows are not impacted by this include when the library is
 used for the tools.  When then backtrace library is used for the target,
 pecoff is not used unless the target is windows.
 So I don’t see a case where the include breaks cross-compilers.
 
 The way you have written the code, I'm fairly sure that it will be
 compiled for an i386-coff target.

And the only coff target supported is djgpp, right ?

 - If the case exists, I don’t see how to implement backtrace within
 shared libraries: I need a windows specific function to get the list
 of DLL.
 
 I would be OK with a #include windows.h that is conditional on
 something that indicates that the host (from the point of view of
 libbacktrace) really is Windows.

Is it ok to test if the _WIN32 macro is defined (like in libiberty) ?

 The new version of the patch is OK.

Thanks, now committed.

Tristan.

Re: [Patch V2]: libbacktrace - add support of PE/COFF

[Tristan Gingold]

Hello,

 #define BACKTRACE_SUPPORTS_THREADS @BACKTRACE_SUPPORTS_THREADS@
 +
 +/* BACKTRACE_SUPPORTS_DATA will be #defined'd as 1 if the backtrace library
 +   also handles data symbols, 0 if not.  */
 +
 +#define BACKTRACE_SUPPORTS_DATA @BACKTRACE_SUPPORTS_DATA@
 
 End users are expected to read and understand this file, so I think
 this comment is too obscure.  I suggest:
 
 BACKTRACE_SUPPORTS_DATA will be #define'd as 1 if backtrace_syminfo
 will work for variables.  It will always work for functions.

The comment is now replaced by your wording.

 I would have thought you could distinguish relevant symbols using the
 storage class and type.  But perhaps not.

Not that easily, unfortunately.  Section names also appear like data
symbols, and furthermore linker script symbol made btest failing.
But we could revisit this issue later.

 diff --git a/libbacktrace/filetype.awk b/libbacktrace/filetype.awk
 index 0a656f7..37099ad 100644
 --- a/libbacktrace/filetype.awk
 +++ b/libbacktrace/filetype.awk
 @@ -1,3 +1,4 @@
 # An awk script to determine the type of a file.
 /\177ELF\001/ { if (NR == 1) { print elf32; exit } }
 /\177ELF\002/ { if (NR == 1) { print elf64; exit } }
 +/\114\001/{ if (NR == 1) { print pecoff; exit } }
 
 That works for 32-bit, but I think not for 64-bit.  For 64-bit I would
 expect \144\206.

Fixed.

 +#include windows.h
 
 Where is windows.h going to come from when building a
 cross-compiler?  I think this needs to be removed.  I see that you
 define the structs yourself, as you should, so why do you need
 windows.h?

Indeed, windows.h is not needed, so I have removed it.

 +/* Read a potentially unaligned 2 byte word at P, using native endianness.  
 */
 
 Is there really ever a case where a 2 byte word might be misaligned?

Good remark.  I have changed the comment.

 +/* Return true iff SYM is a defined symbol for a function.  Data symbols
 +   are discarded because they aren't easily identified.  */
 +
 +static int
 +coff_is_symbol (const b_coff_internal_symbol *isym)
 +{
 +  return isym-type == 0x20  isym-sec  0;
 +}
 
 Is this really right?  This seems to test for DT_FCN set, but won't a
 function returning, say, int, have type 0x24 (DT_FCN  N_TBSHFT) | T_INT?

According to MS doc, only 0x20 or 0x00 is used.  But I have changed the doc
for clarity.

 Also, the name isn't right--this is coff_is_function_symbol.

Changed.

 
 +  if (coff_expand_symbol (isym, asym, sects_num, strtab, strtab_size) 
  0)
 +   {
 + error_callback (data, invalid coff symbol, 0);
 + return 0;
 +   }
 
 That's not a very useful error message--can you be more specific?

It is now more specific (although such error should never happen).

 +  /* Allocate memory for symbols are strings.  */
 
 Comment looks wrong--omit are”?

Yes.

Here is the new version of the patch.

Regards,
Tristan.

libbacktrace/
2015-05-21  Tristan Gingold  ging...@adacore.com

* pecoff.c: New file.
* Makefile.am (FORMAT_FILES): Add pecoff.c and dependencies.
* Makefile.in: Regenerate.
* filetype.awk: Detect pecoff.
* configure.ac: Define BACKTRACE_SUPPORTS_DATA on elf platforms.
Add pecoff.
* btest.c (test5): Test enabled only if BACKTRACE_SUPPORTS_DATA is
true.
* backtrace-supported.h.in (BACKTRACE_SUPPORTS_DATA): Define.
* configure: Regenerate.
* pecoff.c: New file.

commit fe0f364bf5836dea2aacb6d963c782d12c4d5561
Author: Tristan Gingold ging...@adacore.com
Date:   Thu May 21 14:29:44 2015 +0200

Add support for PE/COFF to libbacktrace.

diff --git a/libbacktrace/ChangeLog b/libbacktrace/ChangeLog
index c6604d9..139521a 100644
--- a/libbacktrace/ChangeLog
+++ b/libbacktrace/ChangeLog
@@ -1,3 +1,17 @@
+2015-05-21  Tristan Gingold  ging...@adacore.com
+
+   * pecoff.c: New file.
+   * Makefile.am (FORMAT_FILES): Add pecoff.c and dependencies.
+   * Makefile.in: Regenerate.
+   * filetype.awk: Detect pecoff.
+   * configure.ac: Define BACKTRACE_SUPPORTS_DATA on elf platforms.
+   Add pecoff.
+   * btest.c (test5): Test enabled only if BACKTRACE_SUPPORTS_DATA is
+   true.
+   * backtrace-supported.h.in (BACKTRACE_SUPPORTS_DATA): Define.
+   * configure: Regenerate.
+   * pecoff.c: New file.
+
 2015-05-13  Michael Haubenwallner  michael.haubenwall...@ssi-schaefer.com
 
* Makefile.in: Regenerated with automake-1.11.6.
diff --git a/libbacktrace/Makefile.am b/libbacktrace/Makefile.am
index a93b82a..c5f0dcb 100644
--- a/libbacktrace/Makefile.am
+++ b/libbacktrace/Makefile.am
@@ -56,6 +56,7 @@ BACKTRACE_FILES = \
 
 FORMAT_FILES = \
elf.c \
+   pecoff.c \
unknown.c
 
 VIEW_FILES = \
@@ -124,6 +125,7 @@ fileline.lo: config.h backtrace.h internal.h
 mmap.lo: config.h backtrace.h internal.h
 mmapio.lo: config.h backtrace.h internal.h
 nounwind.lo: config.h internal.h
+pecoff.lo: config.h backtrace.h internal.h
 posix.lo: config.h backtrace.h internal.h

Re: [Patch]: libbacktrace - add support of PE/COFF

[Tristan Gingold]

 On 27 May 2015, at 15:36, Jeff Law l...@redhat.com wrote:

 +static int
 +coff_is_symbol (const b_coff_internal_symbol *isym)
 +{
 +  return isym-type == 0x20  isym-sec  0;
 +}
 You probably want const or enum so that you can have a symbolic name rather 
 than 0x20 here.  It also seems like the name ought to better indicate it's 
 testing for function symbols.

Yes, this is now changed.

 It's a given  that you know COFF specifics better than I ever did, so I'm 
 comfortable assuming you got the COFF specifics right.
 
 The overall structure of elf.c  coff.c is the same with code templates that 
 are very similar, except they work on different underlying types.  Presumably 
 there wasn't a good way to factor any of the generic looking bits out?  And 
 no, I'm not requesting you rewrite all this in BFD :-)

The dummy callback could indeed be easily shared.  For the remaining, that’s 
not so simple given the types.  Maybe we can create a ‘C class’ for symbol 
infos.

Tristan.

Re: [Patch]: libbacktrace - add support of PE/COFF

[Tristan Gingold]

 On 28 May 2015, at 02:26, Ian Lance Taylor i...@google.com wrote:

 The #include windows.h will break cross-compilers.  It's not OK for
 trunk until that is fixed.

I am confused by this comment, for two reasons:

- I don’t see how that would break cross-compilers.  Cross compilers
 hosted on windows are not impacted by this include when the library is
 used for the tools.  When then backtrace library is used for the target,
 pecoff is not used unless the target is windows.
 So I don’t see a case where the include breaks cross-compilers.

- If the case exists, I don’t see how to implement backtrace within
 shared libraries: I need a windows specific function to get the list
 of DLL.

Tristan.

[Patch]: libbacktrace - add support of PE/COFF

[Tristan Gingold]

Hello,

this patch adds basic support to libbacktrace for PE32 and PE32+ (Windows and 
Windows64 object formats).
Support is ‘basic’ because neither DLL nor PIE (if that exists) are handled.  
Furthermore, there is no windows versions of mmapio.c and mmap.c
Finally, I have disabled the support of data symbols for PE because I wasn’t 
able to pass ‘make check’ with that: symbol ‘_global’ is at the same address as 
a symbol defined by the linker and I haven’t found any way to discard the 
latter.  As I think data symbol support isn’t a required feature, I have 
preferred to disable that feature on PE.

The new file, pecoff.c, mostly follows the structure of elf.c

Tested on both windows and windows64.
No regression on Gnu/Linux x86.

Tristan.


2015-05-21  Tristan Gingold  ging...@adacore.com

* pecoff.c: New file.
* Makefile.am (FORMAT_FILES): Add pecoff.c and dependencies.
* Makefile.in: Regenerate.
* filetype.awk: Detect pecoff.
* configure.ac: Define BACKTRACE_SUPPORTS_DATA on elf platforms.
Add pecoff.
* btest.c (test5): Test enabled only if BACKTRACE_SUPPORTS_DATA is
true.
* backtrace-supported.h.in (BACKTRACE_SUPPORTS_DATA): Define.
* configure: Regenerate.
* pecoff.c: New file.


commit ac17f650356728fc07121c71213401e1e159df2f
Author: Tristan Gingold ging...@adacore.com
Date:   Thu May 21 14:29:44 2015 +0200

Add support for PE/COFF to libbacktrace.

diff --git a/libbacktrace/ChangeLog b/libbacktrace/ChangeLog
index c6604d9..139521a 100644
--- a/libbacktrace/ChangeLog
+++ b/libbacktrace/ChangeLog
@@ -1,3 +1,17 @@
+2015-05-21  Tristan Gingold  ging...@adacore.com
+
+   * pecoff.c: New file.
+   * Makefile.am (FORMAT_FILES): Add pecoff.c and dependencies.
+   * Makefile.in: Regenerate.
+   * filetype.awk: Detect pecoff.
+   * configure.ac: Define BACKTRACE_SUPPORTS_DATA on elf platforms.
+   Add pecoff.
+   * btest.c (test5): Test enabled only if BACKTRACE_SUPPORTS_DATA is
+   true.
+   * backtrace-supported.h.in (BACKTRACE_SUPPORTS_DATA): Define.
+   * configure: Regenerate.
+   * pecoff.c: New file.
+
 2015-05-13  Michael Haubenwallner  michael.haubenwall...@ssi-schaefer.com
 
* Makefile.in: Regenerated with automake-1.11.6.
diff --git a/libbacktrace/Makefile.am b/libbacktrace/Makefile.am
index a93b82a..c5f0dcb 100644
--- a/libbacktrace/Makefile.am
+++ b/libbacktrace/Makefile.am
@@ -56,6 +56,7 @@ BACKTRACE_FILES = \
 
 FORMAT_FILES = \
elf.c \
+   pecoff.c \
unknown.c
 
 VIEW_FILES = \
@@ -124,6 +125,7 @@ fileline.lo: config.h backtrace.h internal.h
 mmap.lo: config.h backtrace.h internal.h
 mmapio.lo: config.h backtrace.h internal.h
 nounwind.lo: config.h internal.h
+pecoff.lo: config.h backtrace.h internal.h
 posix.lo: config.h backtrace.h internal.h
 print.lo: config.h backtrace.h internal.h
 read.lo: config.h backtrace.h internal.h
diff --git a/libbacktrace/Makefile.in b/libbacktrace/Makefile.in
index a949f29..b434d76e 100644
--- a/libbacktrace/Makefile.in
+++ b/libbacktrace/Makefile.in
@@ -299,6 +299,7 @@ BACKTRACE_FILES = \
 
 FORMAT_FILES = \
elf.c \
+   pecoff.c \
unknown.c
 
 VIEW_FILES = \
@@ -753,6 +754,7 @@ fileline.lo: config.h backtrace.h internal.h
 mmap.lo: config.h backtrace.h internal.h
 mmapio.lo: config.h backtrace.h internal.h
 nounwind.lo: config.h internal.h
+pecoff.lo: config.h backtrace.h internal.h
 posix.lo: config.h backtrace.h internal.h
 print.lo: config.h backtrace.h internal.h
 read.lo: config.h backtrace.h internal.h
diff --git a/libbacktrace/backtrace-supported.h.in 
b/libbacktrace/backtrace-supported.h.in
index 5115ce1..4574635 100644
--- a/libbacktrace/backtrace-supported.h.in
+++ b/libbacktrace/backtrace-supported.h.in
@@ -59,3 +59,8 @@ POSSIBILITY OF SUCH DAMAGE.  */
as 0.  */
 
 #define BACKTRACE_SUPPORTS_THREADS @BACKTRACE_SUPPORTS_THREADS@
+
+/* BACKTRACE_SUPPORTS_DATA will be #defined'd as 1 if the backtrace library
+   also handles data symbols, 0 if not.  */
+
+#define BACKTRACE_SUPPORTS_DATA @BACKTRACE_SUPPORTS_DATA@
diff --git a/libbacktrace/btest.c b/libbacktrace/btest.c
index 9424a92..9821e34 100644
--- a/libbacktrace/btest.c
+++ b/libbacktrace/btest.c
@@ -616,6 +616,8 @@ f33 (int f1line, int f2line)
   return failures;
 }
 
+#if BACKTRACE_SUPPORTS_DATA
+
 int global = 1;
 
 static int
@@ -684,6 +686,8 @@ test5 (void)
   return failures;
 }
 
+#endif /* BACKTRACE_SUPPORTS_DATA  */
+
 static void
 error_callback_create (void *data ATTRIBUTE_UNUSED, const char *msg,
   int errnum)
@@ -708,8 +712,10 @@ main (int argc ATTRIBUTE_UNUSED, char **argv)
   test2 ();
   test3 ();
   test4 ();
+#if BACKTRACE_SUPPORTS_DATA
   test5 ();
 #endif
+#endif
 
   exit (failures ? EXIT_FAILURE : EXIT_SUCCESS);
 }
diff --git a/libbacktrace/configure b/libbacktrace/configure
index fa81659..19418c9 100755
--- a/libbacktrace/configure
+++ b/libbacktrace/configure

Re: [rs6000] Fix compare debug failure on AIX

[Tristan Gingold]

 On 04 May 2015, at 02:32, David Edelsohn dje@gmail.com wrote:
 
 On Sat, May 2, 2015 at 6:04 AM, Eric Botcazou ebotca...@adacore.com wrote:
 Why should GCC unnecessarily create stack frames to avoid
 compare-debug testcase failures?
 
 I'm not sure I understand the question... compare-debug failures are failures
 (-g is not supposed to change the generated code and this XCOFF-specific bug
 was reported to us) so they need to be fixed.
 
 From there on, as Alan said, there are 2 cases: either AIX needs a frame for
 debugging or it doesn't.  If the latter, then the lines can simply be 
 deleted.
 If the former, we have to draw a line somewhere; Alan suggests always 
 creating
 a frame while I suggest creating it only at -O0 and -Og.
 
 I believe that AIX does need a frame for debugging.  I don't remember
 the exact reason off hand.
 
 I'm sorry that XCOFF debugging changes the generated code (only in the
 sense of allocating a frame), but that is a system dependency.  It's
 been this way for over 20 years.  I see no reason to produce worse
 code at -O0 when not debugging simply to make testcases happier.
 
 By the way, I'm still waiting for the DWARF debugging patches from
 Adacore compatible with AIX as and ld.  DWARF debugging would not
 require pushing a frame, and would resolve the failure when testing
 with DWARF.  The patch would be adjusted to only push a frame when
 writing XCOFF debugging.

Sorry but we don’t have these patches.  We have a tiny patch to generate
Dwarf debug infos on XCOFF platforms but that requires GNU as and ld.

Tristan.

Re: [Ada] Fix bootstrapping on darwin9/10 (PR ada/64349)

[Tristan Gingold]

 #elif ! (defined (__vxworks))
 
 ^^ __vxworks will not be defined by anything other than a vxworks 
 compiler, I'd assume (it is certainly not defined by Darwin toolchains)
 
  extern char **environ;
  return environ;
 
 vvv so I don't see how this case will ever be exercised.
 #elif defined (__APPLE__)  !defined (__arm__)
  return *_NSGetEnviron ();
 #else
  return environ;
 #endif
 }

Ehh, you're right.  They must be swapped.  I missed the '!' in the vxworks 
case, and that wasn't detected by our build.

Tristan.

Re: ping: [RFA] Add --with-libz-prefix option in config/zlib.m4

[Tristan Gingold]

 On 21 Jan 2015, at 08:47, Joel Brobecker brobec...@adacore.com wrote:
 
 Thank you! :)

What is the rational for having --with-zlib but --with-libz-prefix
(ie zlib vs libz) ?  Looks not very consistent.

Tristan.

 
 On Wed, Jan 07, 2015 at 06:45:48PM +0400, Joel Brobecker wrote:
 Hello,
 
 This patch enhances config/zlib.m4 to introduce an extra option
 --with-libz-prefix which allows us to provide the location of
 the zlib library we want to use during the build.
 
 config/ChangeLog:
 
* zlib.m4 (AM_ZLIB): Add --with-libz-prefix option support.
 
 I didn't see any file in the GCC project that uses this macro,
 so for the GCC repository, the change to zlib.m4 is it. But
 I am also attaching to this email a copy of the patch that
 will be applied to the binutils-gdb.git repository, with all
 configury using this macro being re-generated - mostly for info,
 also as a heads-up to both binutils and GDB.
 
 This was tested by regenerating all autoconf/automake files in
 the binutils-gdb project, and rebuilding GDB, using the following
 combinations:
 
  --with-zlib (system zlib used)
  --with-libz-prefix=/zlib/prefix (specific zlib linked in)
  --with-zlib --with-libz-prefix=/zlib/prefix (specific zlib linked in)
 
  --without-zlib (zlib support turned off)
  --without-zlib --with-zlib-prefix (zlib support turned off)
 
  --with-zlib (no system zlib available, configure fails with expected error)
  --with-zlib --with-libz-prefix=/invalid/zlib/prefix
  (no system zlib, configure fails with same error)

Re: [Ada] Fix bootstrapping on darwin9/10 (PR ada/64349).

[Tristan Gingold]

 On 09 Jan 2015, at 00:42, Iain Sandoe i...@codesourcery.com wrote:
 
 
 On 8 Jan 2015, at 13:52, Tristan Gingold wrote:
 
 
 On 08 Jan 2015, at 13:49, Iain Sandoe i...@codesourcery.com wrote:
 
 Hi Tristan,
 
 On 7 Jan 2015, at 10:15, Arnaud Charlet wrote:
 
 Use _NSGetEnviron to get environment.
 
 Tested on x86_64-pc-linux-gnu, committed on trunk
 
 2015-01-07  Tristan Gingold  ging...@adacore.com
 
PR ada/64349
* env.c (__gnat_environ): Adjust for darwin9/darwin10.
 
 difs.txt
 
 So my original patch assumed that, while it was not legal to use environ 
 from a shlib, it is legal to use _NSGetEnviron () from an application ...
 
 .. and, OK fine, I see the point about ! defined (__arm__) .. but a few 
 other comments.
 
 ISTM that there's a partial implementation to distinguish between IN_RTS 
 and application?
 
 Yes you're right.  The added code should have been added after the #endif 
 for IN_RTS.
 
 How about this?
 It uses the interface where needed, avoids it for main exes and gets rid of 
 the negative conditional (which IMO makes the code a little more readable).
 
 Iain
 
 P.S. this is not Darwin9/10 - specific the only reason it doesn't fail on 
 Darwin = 11 is because they default to -undefined dynamic_lookup .. and so 
 find the symbol from the exe.

Sorry for the late answer.  We did something slightly different: always 
#include crt_externs.h on no-arm Darwin.

Tristan.

Re: [Ada] Fix bootstrapping on darwin9/10 (PR ada/64349).

[Tristan Gingold]

 On 08 Jan 2015, at 13:49, Iain Sandoe i...@codesourcery.com wrote:
 
 Hi Tristan,
 
 On 7 Jan 2015, at 10:15, Arnaud Charlet wrote:
 
 Use _NSGetEnviron to get environment.
 
 Tested on x86_64-pc-linux-gnu, committed on trunk
 
 2015-01-07  Tristan Gingold  ging...@adacore.com
 
  PR ada/64349
  * env.c (__gnat_environ): Adjust for darwin9/darwin10.
 
 difs.txt
 
 So my original patch assumed that, while it was not legal to use environ from 
 a shlib, it is legal to use _NSGetEnviron () from an application ...
 
 .. and, OK fine, I see the point about ! defined (__arm__) .. but a few other 
 comments.
 
 ISTM that there's a partial implementation to distinguish between IN_RTS and 
 application?

Yes you're right.  The added code should have been added after the #endif for 
IN_RTS.

I will fix that.  Current code should compile, possibly with warnings.

Tristan.

Re: [RFA] Add --with-libz-prefix option in config/zlib.m4

[Tristan Gingold]

 On 07 Jan 2015, at 15:45, Joel Brobecker brobec...@adacore.com wrote:
 
 Hello,
 
 This patch enhances config/zlib.m4 to introduce an extra option
 --with-libz-prefix which allows us to provide the location of
 the zlib library we want to use during the build.

I prefer the gcc way to provide external library:

--with-zlib - system zlib used
--with-zlib=pathname - zlib from pathname is used

I have never needed different include and lib paths, but
this is supported by gcc.

(Furthermore, I think that --with-zlib vs --with-libz-prefix is confusing).

Cf:

--with-gmp=pathname
--with-gmp-include=pathname
--with-gmp-lib=pathname
--with-mpfr=pathname
--with-mpfr-include=pathname
--with-mpfr-lib=pathname
--with-mpc=pathname
--with-mpc-include=pathname
--with-mpc-lib=pathname
If you want to build GCC but do not have the GMP library, the MPFR library 
and/or the MPC library installed in a standard location and do not have their 
sources present in the GCC source tree then you can explicitly specify the 
directory where they are installed (‘--with-gmp=gmpinstalldir’, 
‘--with-mpfr=mpfrinstalldir’, ‘--with-mpc=mpcinstalldir’). The 
--with-gmp=gmpinstalldir option is shorthand for 
--with-gmp-lib=gmpinstalldir/lib and --with-gmp-include=gmpinstalldir/include. 
Likewise the --with-mpfr=mpfrinstalldir option is shorthand for 
--with-mpfr-lib=mpfrinstalldir/lib and 
--with-mpfr-include=mpfrinstalldir/include, also the --with-mpc=mpcinstalldir 
option is shorthand for --with-mpc-lib=mpcinstalldir/lib and 
--with-mpc-include=mpcinstalldir/include. If these shorthand assumptions are 
not correct, you can use the explicit include and lib options directly. You 
might also need to ensure the shared libraries can be found by the dynamic 
linker when building and using GCC, for example by setting the runtime shared 
library path variable (LD_LIBRARY_PATH on GNU/Linux and Solaris systems).
These flags are applicable to the host platform only. When building a cross 
compiler, they will not be used to configure target libraries. 

Re: Document __builtin_*_overflow

[Tristan Gingold]

 On 12 Nov 2014, at 14:13, Jakub Jelinek ja...@redhat.com wrote:
 +  size_t sz;
 +  if (__builtin_mul_overflow (x, y, amp;sz)

Missing right parenthesis ?

[committed]: change my email address

[Tristan Gingold]

I will commit the following change in MAINTAINERS.

Tristan.

2014-10-29  Tristan Gingold  ging...@adacore.com

* MAINTAINERS: Change my email address.


--- MAINTAINERS (revision 216822)
+++ MAINTAINERS (working copy)
@@ -136,7 +136,7 @@
 RTEMS PortsJoel Sherrill   j...@oarcorp.com
 RTEMS PortsRalf Corsepius  ralf.corsep...@rtems.org
 VMSDouglas Ruppdouglas.b.r...@gmail.com
-VMSTristan Gingold ging...@adacore.com
+VMSTristan Gingold tging...@free.fr
 VxWorks ports  Nathan Sidwell  nat...@codesourcery.com
 windows, cygwin, mingw Kai Tietz   kti...@redhat.com

Re: [RFC] Add aarch64 support for ada

[Tristan Gingold]

On 16 Apr 2014, at 17:36, Richard Henderson r...@redhat.com wrote:

 On 04/16/2014 12:39 AM, Eric Botcazou wrote:
 The primary bit of rfc here is the hunk that applies to ada/types.h
 with respect to Fat_Pointer.  Given that the Ada type, as defined in
 s-stratt.ads, does not include alignment, I can't imagine why the C
 type should have it.
 
 See gcc-interface/utils.c:finish_fat_pointer_type.
 
 Ah hah.
 
  /* Make sure we can put it into a register.  */
  if (STRICT_ALIGNMENT)
TYPE_ALIGN (record_type) = MIN (BIGGEST_ALIGNMENT, 2 * POINTER_SIZE);
 
 AArch64 is not a STRICT_ALIGNMENT target, thus the mismatch.

As the align attribute in types.h is for the host, couldn't a configure test 
solve
this issue ?

 If we were to make this alignment unconditional, would it be better to drop 
 the
 code from here in finish_fat_pointer_type and instead record that in the Ada
 source, as we do with the C source?
 
 I presume
 
  for Fat_Pointer'Alignment use System.Address'Size * 2;
 
 or some such incantation would do that...

One of the most common Fat_Pointer is for strings, which aren't declared in any
source and is very commonly used.

OTOH, I think this optimization mostly targets sparc.

Tristan.

Re: [RFC] Add aarch64 support for ada

[Tristan Gingold]

On 17 Apr 2014, at 16:50, Richard Henderson r...@redhat.com wrote:

 On 04/17/2014 02:00 AM, Tristan Gingold wrote:
 
 On 16 Apr 2014, at 17:36, Richard Henderson r...@redhat.com wrote:
 
 On 04/16/2014 12:39 AM, Eric Botcazou wrote:
 The primary bit of rfc here is the hunk that applies to ada/types.h
 with respect to Fat_Pointer.  Given that the Ada type, as defined in
 s-stratt.ads, does not include alignment, I can't imagine why the C
 type should have it.
 
 See gcc-interface/utils.c:finish_fat_pointer_type.
 
 Ah hah.
 
 /* Make sure we can put it into a register.  */
 if (STRICT_ALIGNMENT)
   TYPE_ALIGN (record_type) = MIN (BIGGEST_ALIGNMENT, 2 * POINTER_SIZE);
 
 AArch64 is not a STRICT_ALIGNMENT target, thus the mismatch.
 
 As the align attribute in types.h is for the host, couldn't a configure test 
 solve
 this issue ?
 
 I doubt it.  I'm not sure what kind of configure test you could write that
 would determine the setting of STRICT_ALIGNMENT, since even non-strict-align
 targets prefer to align data for performance reasons.  Be careful that the 
 test
 couldn't be an execution test, lest you break host != build.

What about this compile-time check:

package Fatptralign is
   type String_Acc is access String;
   type Integer_acc is access Integer;

   pragma Compile_Time_Error
(String_Acc'Alignment = 1 * Integer_Acc'Alignment,
 Fat pointer are simply aligned);

   pragma Compile_Time_Error
(String_Acc'Alignment = 2 * Integer_Acc'Alignment,
 Fat pointer are doubly aligned);
end Fatptralign;


 One of the most common Fat_Pointer is for strings, which aren't declared in 
 any
 source and is very commonly used.
 
 OTOH, I think this optimization mostly targets sparc.
 
 Indeed, 32-bit sparc wants 64-bit alignment for its ldd/std instructions.
 
 Perhaps the better optimization (supposing it's really worth keeping)

That's a true question (worth keeping).  I think this also affects powerpc (as
an important target)

Eric ?

 is to
 DECL_ALIGN the static strings, rather than align the type?

[ Ada strings (and more generally Ada unconstrained array and Ada accesses to
  unconstrained arrays) are represented in GNAT by a fat pointer, ie a structure
  containing a pointer to the bounds and a pointer to the data.
  We are talking about the alignment of that structure. ]

 Presumably Ada strings are as with C string literals -- symbols private to the
 compilation unit which are normally passed by value.  Thus functions within 
 the
 compilation unit would see the extra alignment of the data and be able to use
 ldd to load the pair.  On the receiving end being able to use std would remain
 a matter of luck.

I think this will dismiss most of the gain.  Fat pointers can be heavily used in
some applications, and be present in structures.  Gain with only private symbols
might be tiny.

Tristan.

Re: [PATCH]: Fix use of __builtin_eh_pointer in EH_ELSE

[Tristan Gingold]

On Sep 24, 2013, at 8:51 PM, Richard Henderson r...@redhat.com wrote:

 On 09/03/2013 07:08 AM, Tristan Gingold wrote:
 Hi,
 
 The field state-ehp_region wasn't updated before lowering constructs in the 
 eh
 path of EH_ELSE.  As a consequence, __builtin_eh_pointer is lowered to 0 (or
 possibly to a wrong region number) in this path.
 
 The only user of EH_ELSE looks to be trans-mem.c:lower_transaction, and the
 consequence of that is a memory leak.
 
 Furthermore, according to calls.c:flags_from_decl_or_type, the 
 transaction_pure
 attribute must be set on the function type, not on the function declaration.
 Hence the change to declare __builtin_eh_pointer.
 (I don't understand the guard condition to set the attribute for it in 
 tree.c.
 Why is 'builtin_decl_explicit_p (BUILT_IN_TM_LOAD_1)' needed in addition to
 flag_tm ?)
 
 Clearly these are totally unrelated and should not be in the same patch.

This wasn't clear to me, as I got 'unsafe function call __builtin_eh_pointer in
atomic transaction' before fixing the transaction_pure.

So here is the 'transaction_pure' part.
No check-host regressions on x86_64-linux-gnu.

Ok for trunk ?

Tristan.

2013-09-03  Tristan Gingold  ging...@adacore.com

* tree.c (set_call_expr_flags): Reject ECF_TM_PURE.
(build_common_builtin_nodes): Set transaction_pure
attribute on __builtin_eh_pointer function type (and not on
its declaration).

diff --git a/gcc/tree.c b/gcc/tree.c
index f0ee309..e4be24d 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -9817,9 +9817,11 @@ set_call_expr_flags (tree decl, int flags)
   if (flags  ECF_LEAF)
 DECL_ATTRIBUTES (decl) = tree_cons (get_identifier (leaf),
NULL, DECL_ATTRIBUTES (decl));
-  if ((flags  ECF_TM_PURE)  flag_tm)
-DECL_ATTRIBUTES (decl) = tree_cons (get_identifier (transaction_pure),
-   NULL, DECL_ATTRIBUTES (decl));
+
+  /* The transaction_pure attribute must be set on the function type, not
+ on the declaration.  */
+  gcc_assert (!(flags  ECF_TM_PURE));
+
   /* Looping const or pure is implied by noreturn.
  There is currently no way to declare looping const or looping pure alone. 
 */
   gcc_assert (!(flags  ECF_LOOPING_CONST_OR_PURE)
@@ -10018,8 +10020,9 @@ build_common_builtin_nodes (void)
integer_type_node, NULL_TREE);
   ecf_flags = ECF_PURE | ECF_NOTHROW | ECF_LEAF;
   /* Only use TM_PURE if we we have TM language support.  */
-  if (builtin_decl_explicit_p (BUILT_IN_TM_LOAD_1))
-ecf_flags |= ECF_TM_PURE;
+  if (flag_tm  builtin_decl_explicit_p (BUILT_IN_TM_LOAD_1))
+TYPE_ATTRIBUTES (ftype) = tree_cons (get_identifier (transaction_pure),
+NULL, TYPE_ATTRIBUTES (ftype));
   local_define_builtin (__builtin_eh_pointer, ftype, BUILT_IN_EH_POINTER,
__builtin_eh_pointer, ecf_flags);
 

Ping: [PATCH]: Fix use of __builtin_eh_pointer in EH_ELSE

[Tristan Gingold]

Any comment/review on this patch ?

On Sep 3, 2013, at 4:08 PM, Tristan Gingold ging...@adacore.com wrote:

 Hi,
 
 The field state-ehp_region wasn't updated before lowering constructs in the 
 eh
 path of EH_ELSE.  As a consequence, __builtin_eh_pointer is lowered to 0 (or
 possibly to a wrong region number) in this path.
 
 The only user of EH_ELSE looks to be trans-mem.c:lower_transaction, and the
 consequence of that is a memory leak.
 
 Furthermore, according to calls.c:flags_from_decl_or_type, the 
 transaction_pure
 attribute must be set on the function type, not on the function declaration.
 Hence the change to declare __builtin_eh_pointer.
 (I don't understand the guard condition to set the attribute for it in tree.c.
 Why is 'builtin_decl_explicit_p (BUILT_IN_TM_LOAD_1)' needed in addition to
 flag_tm ?)
 
 No regressions (check-host) on x86-64 GNU/Linux.
 
 Ok for trunk ?
 
 Tristan.
 
 2013-09-03  Tristan Gingold  ging...@adacore.com
 
   * tree.c (set_call_expr_flags): Reject ECF_TM_PURE.
   (build_common_builtin_nodes): Set transaction_pure
   attribute on __builtin_eh_pointer function type (and not on
   its declaration).
   * tree-eh.c (lower_try_finally_nofallthru): Set and revert
   ehp_region before callinf lower_eh_constructs_1.
   (lower_try_finally_onedest): Likewise.
   (lower_try_finally_copy): Likewise.
   (lower_try_finally_switch): Likewise.
 
 testsuite/
 2013-09-03  Tristan Gingold  ging...@adacore.com
 
   * gcc.dg/tm/except.c: New testcase.
 
 
 diff --git a/gcc/testsuite/gcc.dg/tm/except.c 
 b/gcc/testsuite/gcc.dg/tm/except.c
 new file mode 100644
 index 000..ed84bb3
 --- /dev/null
 +++ b/gcc/testsuite/gcc.dg/tm/except.c
 @@ -0,0 +1,36 @@
 +/* { dg-do compile } */
 +/* { dg-options -fgnu-tm -O1 -fexceptions -fdump-tree-optimized } */
 +
 +typedef struct node {
 +  int val;
 +  struct node *next;
 +} node_t;
 +
 +node_t *head;
 +
 +__attribute__((transaction_safe))
 +node_t *new_node(int val, node_t *next);
 +
 +int add(int val)
 +{
 +  int result;
 +  node_t *prev, *next;
 +
 +  __transaction_atomic {
 +prev = head;
 +next = prev-next;
 +while (next-val  val) {
 +  prev = next;
 +  next = prev-next;
 +}
 +result = (next-val != val);
 +if (result) {
 +  prev-next = new_node(val, next);
 +}
 +  }
 +  return result;
 +}
 +
 +/* { dg-final { scan-tree-dump-not ITM_commitTransactionEH \\(0B\\) 
 optimized } } */
 +
 +/* { dg-final { cleanup-tree-dump optimized } } */
 diff --git a/gcc/tree-eh.c b/gcc/tree-eh.c
 index 6ffbd26..86ee77e 100644
 --- a/gcc/tree-eh.c
 +++ b/gcc/tree-eh.c
 @@ -1093,8 +1093,12 @@ lower_try_finally_nofallthru (struct leh_state *state,
 
   if (tf-may_throw)
   {
 +   eh_region prev_ehp_region = state-ehp_region;
 +
 finally = gimple_eh_else_e_body (eh_else);
 +   state-ehp_region = tf-region;
 lower_eh_constructs_1 (state, finally);
 +   state-ehp_region = prev_ehp_region;
 
 emit_post_landing_pad (eh_seq, tf-region);
 gimple_seq_add_seq (eh_seq, finally);
 @@ -1129,6 +1133,7 @@ lower_try_finally_onedest (struct leh_state *state, 
 struct leh_tf_state *tf)
   gimple_stmt_iterator gsi;
   tree finally_label;
   location_t loc = gimple_location (tf-try_finally_expr);
 +  eh_region prev_ehp_region = state-ehp_region;
 
   finally = gimple_try_cleanup (tf-top_p);
   tf-top_p_seq = gimple_try_eval (tf-top_p);
 @@ -1140,12 +1145,16 @@ lower_try_finally_onedest (struct leh_state *state, 
 struct leh_tf_state *tf)
   if (x)
 {
   if (tf-may_throw)
 - finally = gimple_eh_else_e_body (x);
 + {
 +   state-ehp_region = tf-region;
 +   finally = gimple_eh_else_e_body (x);
 + }
   else
   finally = gimple_eh_else_n_body (x);
 }
 
   lower_eh_constructs_1 (state, finally);
 +  state-ehp_region = prev_ehp_region;
 
   for (gsi = gsi_start (finally); !gsi_end_p (gsi); gsi_next (gsi))
 {
 @@ -1255,13 +1264,19 @@ lower_try_finally_copy (struct leh_state *state, 
 struct leh_tf_state *tf)
 
   if (tf-may_throw)
 {
 +  eh_region prev_ehp_region = state-ehp_region;
 +
   /* We don't need to copy the EH path of EH_ELSE,
since it is only emitted once.  */
   if (eh_else)
 - seq = gimple_eh_else_e_body (eh_else);
 + {
 +   seq = gimple_eh_else_e_body (eh_else);
 +   state-ehp_region = tf-region;
 + }
   else
   seq = lower_try_finally_dup_block (finally, state, tf_loc);
   lower_eh_constructs_1 (state, seq);
 +  state-ehp_region = prev_ehp_region;
 
   emit_post_landing_pad (eh_seq, tf-region);
   gimple_seq_add_seq (eh_seq, seq);
 @@ -1432,8 +1447,12 @@ lower_try_finally_switch (struct leh_state *state, 
 struct leh_tf_state *tf)
 {
   if (tf-may_throw)
   {
 +   eh_region prev_ehp_region = state-ehp_region;
 +
 +   state-ehp_region = tf-region;
 finally = gimple_eh_else_e_body (eh_else

[PATCH]: Fix use of __builtin_eh_pointer in EH_ELSE

[Tristan Gingold]

Hi,

The field state-ehp_region wasn't updated before lowering constructs in the eh
path of EH_ELSE.  As a consequence, __builtin_eh_pointer is lowered to 0 (or
possibly to a wrong region number) in this path.

The only user of EH_ELSE looks to be trans-mem.c:lower_transaction, and the
consequence of that is a memory leak.

Furthermore, according to calls.c:flags_from_decl_or_type, the 
transaction_pure
attribute must be set on the function type, not on the function declaration.
Hence the change to declare __builtin_eh_pointer.
(I don't understand the guard condition to set the attribute for it in tree.c.
 Why is 'builtin_decl_explicit_p (BUILT_IN_TM_LOAD_1)' needed in addition to
 flag_tm ?)

No regressions (check-host) on x86-64 GNU/Linux.

Ok for trunk ?

Tristan.

2013-09-03  Tristan Gingold  ging...@adacore.com

* tree.c (set_call_expr_flags): Reject ECF_TM_PURE.
(build_common_builtin_nodes): Set transaction_pure
attribute on __builtin_eh_pointer function type (and not on
its declaration).
* tree-eh.c (lower_try_finally_nofallthru): Set and revert
ehp_region before callinf lower_eh_constructs_1.
(lower_try_finally_onedest): Likewise.
(lower_try_finally_copy): Likewise.
(lower_try_finally_switch): Likewise.

testsuite/
2013-09-03  Tristan Gingold  ging...@adacore.com

* gcc.dg/tm/except.c: New testcase.


diff --git a/gcc/testsuite/gcc.dg/tm/except.c b/gcc/testsuite/gcc.dg/tm/except.c
new file mode 100644
index 000..ed84bb3
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tm/except.c
@@ -0,0 +1,36 @@
+/* { dg-do compile } */
+/* { dg-options -fgnu-tm -O1 -fexceptions -fdump-tree-optimized } */
+
+typedef struct node {
+  int val;
+  struct node *next;
+} node_t;
+
+node_t *head;
+
+__attribute__((transaction_safe))
+node_t *new_node(int val, node_t *next);
+
+int add(int val)
+{
+  int result;
+  node_t *prev, *next;
+
+  __transaction_atomic {
+prev = head;
+next = prev-next;
+while (next-val  val) {
+  prev = next;
+  next = prev-next;
+}
+result = (next-val != val);
+if (result) {
+  prev-next = new_node(val, next);
+}
+  }
+  return result;
+}
+
+/* { dg-final { scan-tree-dump-not ITM_commitTransactionEH \\(0B\\) 
optimized } } */
+
+/* { dg-final { cleanup-tree-dump optimized } } */
diff --git a/gcc/tree-eh.c b/gcc/tree-eh.c
index 6ffbd26..86ee77e 100644
--- a/gcc/tree-eh.c
+++ b/gcc/tree-eh.c
@@ -1093,8 +1093,12 @@ lower_try_finally_nofallthru (struct leh_state *state,
 
   if (tf-may_throw)
{
+ eh_region prev_ehp_region = state-ehp_region;
+
  finally = gimple_eh_else_e_body (eh_else);
+ state-ehp_region = tf-region;
  lower_eh_constructs_1 (state, finally);
+ state-ehp_region = prev_ehp_region;
 
  emit_post_landing_pad (eh_seq, tf-region);
  gimple_seq_add_seq (eh_seq, finally);
@@ -1129,6 +1133,7 @@ lower_try_finally_onedest (struct leh_state *state, 
struct leh_tf_state *tf)
   gimple_stmt_iterator gsi;
   tree finally_label;
   location_t loc = gimple_location (tf-try_finally_expr);
+  eh_region prev_ehp_region = state-ehp_region;
 
   finally = gimple_try_cleanup (tf-top_p);
   tf-top_p_seq = gimple_try_eval (tf-top_p);
@@ -1140,12 +1145,16 @@ lower_try_finally_onedest (struct leh_state *state, 
struct leh_tf_state *tf)
   if (x)
 {
   if (tf-may_throw)
-   finally = gimple_eh_else_e_body (x);
+   {
+ state-ehp_region = tf-region;
+ finally = gimple_eh_else_e_body (x);
+   }
   else
finally = gimple_eh_else_n_body (x);
 }
 
   lower_eh_constructs_1 (state, finally);
+  state-ehp_region = prev_ehp_region;
 
   for (gsi = gsi_start (finally); !gsi_end_p (gsi); gsi_next (gsi))
 {
@@ -1255,13 +1264,19 @@ lower_try_finally_copy (struct leh_state *state, struct 
leh_tf_state *tf)
 
   if (tf-may_throw)
 {
+  eh_region prev_ehp_region = state-ehp_region;
+
   /* We don't need to copy the EH path of EH_ELSE,
 since it is only emitted once.  */
   if (eh_else)
-   seq = gimple_eh_else_e_body (eh_else);
+   {
+ seq = gimple_eh_else_e_body (eh_else);
+ state-ehp_region = tf-region;
+   }
   else
seq = lower_try_finally_dup_block (finally, state, tf_loc);
   lower_eh_constructs_1 (state, seq);
+  state-ehp_region = prev_ehp_region;
 
   emit_post_landing_pad (eh_seq, tf-region);
   gimple_seq_add_seq (eh_seq, seq);
@@ -1432,8 +1447,12 @@ lower_try_finally_switch (struct leh_state *state, 
struct leh_tf_state *tf)
 {
   if (tf-may_throw)
{
+ eh_region prev_ehp_region = state-ehp_region;
+
+ state-ehp_region = tf-region;
  finally = gimple_eh_else_e_body (eh_else);
  lower_eh_constructs_1 (state, finally);
+ state-ehp_region = prev_ehp_region;
 
  emit_post_landing_pad (eh_seq, tf-region);
  gimple_seq_add_seq (eh_seq

[VMS] Update libiberty/makefile.vms

[Tristan Gingold]

Add dwarfnames.obj, needed to build binutils on VMS hosts.

Committed on both gcc and src trunks.

Tristan.

libiberty/
2013-07-09  Tristan Gingold  ging...@adacore.com

* makefile.vms (OBJS): Add dwarfnames.obj

Index: makefile.vms
===
--- makefile.vms(revision 200810)
+++ makefile.vms(working copy)
@@ -13,7 +13,8 @@
 concat.obj,getruntime.obj,getpagesize.obj,getpwd.obj,xstrerror.obj,\
 xmemdup.obj,xstrdup.obj,xatexit.obj,choose-temp.obj,fnmatch.obj,\
 objalloc.obj,safe-ctype.obj,hashtab.obj,lbasename.obj,argv.obj,\
-lrealpath.obj,make-temp-file.obj,stpcpy.obj,unlink-if-ordinary.obj
+lrealpath.obj,make-temp-file.obj,stpcpy.obj,unlink-if-ordinary.obj,\
+dwarfnames.obj
 
 ifeq ($(CC),gcc)
 CFLAGS=/include=([],[-.include])

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[Tristan Gingold]

On Feb 14, 2013, at 12:26 PM, Steven Bosscher wrote:

 On Wed, Feb 13, 2013 at 10:33 PM, David Edelsohn wrote:
 The AIX system supports DWARF debugging, but GCC does not generate it
 on AIX and GDB does not consume it on AIX.
 
 Is there a description for what has to be done in GCC to enable DWARF
 with AIX as/ld? E.g. is it required to support the .dwsect pseudo?
 Is there already a plan from someone to make GCC produce DWARF on
 AIX7?

Yes, you need to support the .dwsect pseudo (which is basically a dedicated
pseudo like .section, but also includes section length).

But note that .dwsect only allows a subset of all dwarf sections.

 AFAICT, for gcc+gas it should already work with binutils that include
 the AdaCore patch for DWARF support. But this has apparently not been
 tested with AIX ld, and there are AdaCore local patches pending.
 http://sourceware.org/ml/binutils/2011-04/msg00250.html
 http://www.sourceware.org/ml/gdb/2013-01/msg00030.html

Yes.

Tristan.

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

[Tristan Gingold]

On Feb 14, 2013, at 3:47 PM, Steven Bosscher wrote:

 On Thu, Feb 14, 2013 at 2:21 PM, Tristan Gingold wrote:
 Is there a description for what has to be done in GCC to enable DWARF
 with AIX as/ld? E.g. is it required to support the .dwsect pseudo?
 Is there already a plan from someone to make GCC produce DWARF on
 AIX7?
 
 Yes, you need to support the .dwsect pseudo (which is basically a dedicated
 pseudo like .section, but also includes section length).
 
 AFAIU your binutils patches support DWARF sections with .section
 instead of .dwsect, right?

Right.

 What is the difficulty with implementing .dwsect for GCC?

Shouldn't be very hard, as it is mostly a matter of not emitting section length.

Tristan.

Re: [Patch/RFC] SEH exceptions for Win64

[Tristan Gingold]

Gerald,

it is ok ?

Tristan.

On Jul 19, 2012, at 12:15 PM, Tristan Gingold wrote:

 
 On Jul 19, 2012, at 11:37 AM, Pedro Alves wrote:
 
 On 07/19/2012 08:30 AM, Tristan Gingold wrote:
 
 No regression on i386 GNU/Linux.
 Committed.
 
 Nice.  Is this NEWS / docs --or wherever release notes are written-- worthy?
 
 Something like this, borrowed from your own words:
 
 On Win64, the compiler now emits SEH unwind info.  GCC exceptions now 
 propagate
 through any code, including code produced by MSVC.
 
 To clarify, GCC emits SEH unwind info since 4.7, so I propose slightly 
 modified words:
 
 Index: htdocs/gcc-4.8/changes.html
 ===
 RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v
 retrieving revision 1.6
 diff -c -r1.6 changes.html
 *** htdocs/gcc-4.8/changes.html   17 Jul 2012 19:47:31 -  1.6
 --- htdocs/gcc-4.8/changes.html   19 Jul 2012 10:15:13 -
 ***
 *** 86,91 
 --- 86,97 
  libraries.  This includes the system libraries and startup modules./li
/ul
 
 +   ul
 + liOn x86_64-mingw32, exceptions propagate through any code,
 + including code produced by MSVC (the GCC runtime now uses SEH on
 + this target)/li
 +   /ul
 + 
  !--
  h2Documentation improvements/h2
  --
 

Re: [Patch/RFC] SEH exceptions for Win64

[Tristan Gingold]

On Jul 19, 2012, at 6:54 PM, Eric Botcazou wrote:

 I did a manual build and testing for x86_64-pc-mingw32 and I will run a
 full bootstrap and regression run on GNU/Linux.
 
 Tristan.
 
 libstdc++-v3/
  * libsupc++/eh_personality.cc (__gxx_personality_seh0): New function.
  Adjust for SEH.
  * config/abi/pre/gnu.ver: Add __gxx_personality_seh0.
 
 libobjc/
  * exception.c (__gnu_objc_personality_seh0): New function.
 
 libjava/
  * libgcj.ver: Add __gcj_personality_seh0.
  * exception.cc (__gcj_personality_seh0): New function.
  Adjust for SEH.
 
 libgcc/
  * unwind-seh.c: New file.
  * unwind-generic.h: Include windows.h for SEH.
  (_Unwind_Exception): Use 6 private fields for SEH.
  (_GCC_specific_handler): Declare.
  * unwind-c.c (__gcc_personality_seh0): New function.
  Adjust for SEH.
  * config/i386/libgcc-cygming.ver: New file.
  * config/i386/t-seh-eh: New file.
  * config.host (x86_64-*-mingw*): Default to seh.
 
 gcc/
  * opts.c (finish_options): Handle UI_SEH.
  * expr.c (build_personality_function): Handle UI_SEH.
  * dwarf2out.c (dwarf2out_begin_prologue): Handle UI_SEH.
  * coretypes.h (unwind_info_type): Add UI_SEH.
  * config/i386/winnt.c (i386_pe_seh_emit_except_personality):
  New function.
  (i386_pe_seh_init_sections): Likewise.
  * config/i386/cygming.h (TARGET_ASM_EMIT_EXCEPT_PERSONALITY): Define.
  (TARGET_ASM_INIT_SECTIONS): Define.
  * common/config/i386/i386-common.c (TARGET_EXCEPT_UNWIND_INFO): Define.
  (i386_except_unwind_info): New function.
 
 Don't we need something in ada/ as well?  PR ada/54028 reports a build 
 failure.

I think Arnaud already committed the ada stuff.

It looks like (to me) that the build occurred before I committed the above 
patch.

Tristan.

Re: [Patch/RFC] SEH exceptions for Win64

[Tristan Gingold]

On Jul 17, 2012, at 2:53 PM, Kai Tietz wrote:

 2012/7/17 Richard Henderson r...@redhat.com:
 On 07/17/2012 12:35 AM, Tristan Gingold wrote:
 So, the first element of ExceptionInformation will be exc.
 
 Should I add a comment ?
 
 Ah right.  Definitely.
 
 Otherwise I don't see anything else in the way.  Kai?
 
 
 r~
 
 No, I don't have any objections.  I just tested the patch myself with
 full regression-test.

Thank you for running the full regression-test.

 So patch is ok.

No regression on i386 GNU/Linux.
Committed.

Tristan.

Re: [Patch/RFC] SEH exceptions for Win64

[Tristan Gingold]

On Jul 19, 2012, at 11:37 AM, Pedro Alves wrote:

 On 07/19/2012 08:30 AM, Tristan Gingold wrote:
 
 No regression on i386 GNU/Linux.
 Committed.
 
 Nice.  Is this NEWS / docs --or wherever release notes are written-- worthy?
 
 Something like this, borrowed from your own words:
 
 On Win64, the compiler now emits SEH unwind info.  GCC exceptions now 
 propagate
 through any code, including code produced by MSVC.

To clarify, GCC emits SEH unwind info since 4.7, so I propose slightly modified 
words:

Index: htdocs/gcc-4.8/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v
retrieving revision 1.6
diff -c -r1.6 changes.html
*** htdocs/gcc-4.8/changes.html 17 Jul 2012 19:47:31 -  1.6
--- htdocs/gcc-4.8/changes.html 19 Jul 2012 10:15:13 -
***
*** 86,91 
--- 86,97 
  libraries.  This includes the system libraries and startup modules./li
/ul
  
+   ul
+ liOn x86_64-mingw32, exceptions propagate through any code,
+ including code produced by MSVC (the GCC runtime now uses SEH on
+ this target)/li
+   /ul
+ 
  !--
  h2Documentation improvements/h2
  --

Re: [Patch/RFC] SEH exceptions for Win64

[Tristan Gingold]

On Jul 16, 2012, at 6:28 PM, Richard Henderson wrote:

 On 07/13/2012 07:13 AM, Tristan Gingold wrote:
 +_Unwind_RaiseException (struct _Unwind_Exception *exc)
 +{
 +  memset (exc-private_, 0, sizeof (exc-private_));
 +
 +  RaiseException (STATUS_GCC_THROW, 0, 1, (ULONG_PTR *)exc);
 
 We almost certainly didn't want pointer-to-pointer...

I was about to say that this is an obvious typo, but no, this code is correct 
AFAIK.

The declaration of RaiseException is:

void
 WINAPI RaiseException(
  __in  DWORD dwExceptionCode,
  __in  DWORD dwExceptionFlags,
  __in  DWORD nNumberOfArguments,
  __in  const ULONG_PTR *lpArguments
);

That is, the last argument is an array of arguments to be copied into the 
exception record.
In our case, the start of the array is exc, and its length is 1.

So, the first element of ExceptionInformation will be exc.

Should I add a comment ?

Tristan.

Re: [Ada] Ease interface with builtins that returns void *

[Tristan Gingold]

On Jul 16, 2012, at 3:16 PM, Duncan Sands wrote:

 Hi Arnaud,
 
 The natural way to import a builtin that returns void * is to use
 System.Address in Ada, which is in fact an integral type.
 
 how about doing this for formal arguments too and not just the return type?

Formal arguments were already handled.

Tristan.

 This would improve optimization by LLVM of calls to standard library functions
 since the optimizers bail out when they see an int parameter where normally
 there would be a void* (or other pointer type).
 
 Ciao, Duncan.
 
 
 Addressed by this patch, which makes it possible to e.g. compile:
 
 with System;
 procedure Btins1 is
 
function Frame_Address (Level : Integer) return System.Address;
pragma Import (Intrinsic, Frame_Address, __builtin_frame_address);
 
Ptr : System.Address;
pragma Volatile (Ptr);
 begin
Ptr := Frame_Address (0);
 end;
 
 Tested on x86_64-pc-linux-gnu, committed on trunk
 
 2012-07-16  Tristan Gingold  ging...@adacore.com
 
  * gcc-interface/decl.c (intrin_return_compatible_p): Map Address to
  void *.
 
 
 

Re: [Ada] Ease interface with builtins that returns void *

[Tristan Gingold]

On Jul 16, 2012, at 3:24 PM, Duncan Sands wrote:

 Hi Tristan,
 
 On 16/07/12 15:17, Tristan Gingold wrote:
 
 On Jul 16, 2012, at 3:16 PM, Duncan Sands wrote:
 
 Hi Arnaud,
 
 The natural way to import a builtin that returns void * is to use
 System.Address in Ada, which is in fact an integral type.
 
 how about doing this for formal arguments too and not just the return type?
 
 Formal arguments were already handled.
 
 indeed, for two years already.  Is there any reason not to do this for all
 functions, rather than just limiting it to builtins?

I don't understand what do you mean.  We need to do this implicit conversion 
for builtins because they are known by the compiler.  Which other functions 
(that aren't builtins) are you referring to ?

Tristan.

Re: [Ada] Ease interface with builtins that returns void *

[Tristan Gingold]

On Jul 16, 2012, at 3:58 PM, Duncan Sands wrote:

 Hi Tristan,
 
 indeed, for two years already.  Is there any reason not to do this for all
 functions, rather than just limiting it to builtins?
 
 I don't understand what do you mean.  We need to do this implicit conversion 
 for builtins because they are known by the compiler.  Which other functions 
 (that aren't builtins) are you referring to ?
 
 all of them!  First off, the LLVM optimizers do a better job if an argument 
 of a
 user defined function that is really a pointer is declared as such, rather 
 than
 declared as an integer then cast to a pointer before being used.  I don't know
 if the GCC optimizers are sensitive to this too.  Also, the LLVM optimizers
 recognize some standard library functions that the gcc optimizers do not, but
 fail to recognize them when called from Ada because they have the wrong
 prototype: an integer rather than a pointer argument.  Finally I would argue
 that as System.Address is really a pointer, playing pretty much exactly the
 same role as void* in C, it is more philosophically correct to express it as a
 void*.  That said, it should probably just be declared as a pointer in the
 System package rather than doing all this mucking around in the gcc interface.

Ah, what you want is the use of 'void *' for System.Address.
We didn't choose that because the semantic of System.Address (which includes 
arithmetic on the whole address space) doesn't match the void * one.

But, you can try to implement this scheme by modifying the runtime.  I don't 
know if this is a small work or not.

Tristan.

Re: [Ada] Ease interface with builtins that returns void *

[Tristan Gingold]

On Jul 16, 2012, at 4:36 PM, Duncan Sands wrote:

 Hi Tristan,
 
 Ah, what you want is the use of 'void *' for System.Address.
 We didn't choose that because the semantic of System.Address (which includes 
 arithmetic on the whole address space) doesn't match the void * one.
 
 void* arithmetic of this kind exists, it's a gcc extension to C :)

The issue is not void * vs char *, but the fact that the C standard has 
restriction on pointer arithmetic.

 But, you can try to implement this scheme by modifying the runtime.  I don't 
 know if this is a small work or not.
 
 It crashes the front-end, so it's not trivial.

:-)

Re: [Ada] Ease interface with builtins that returns void *

[Tristan Gingold]

On Jul 16, 2012, at 5:16 PM, Duncan Sands wrote:

 PS: That said, I have to admit that using void* for builtins does cover the
 most important cases.

Agreed.  But I still think that these are two very different issues:

* Doing implicit conversion to void * for builtins is just a convenient way for 
interfacing with builtins.

* Using void * for System.Address shouldn't have any immediate advantage for 
users, but would be a better match for the representation.

Tristan.

[Patch/RFC] SEH exceptions for Win64

[Tristan Gingold]

Hi,

this is a rebase of RTH's patch posted a few years ago.  It is almost 
unchanged, except that there is no SEH specific unwind.h header (there are 3 
#if/#endif part in unwind-generic.h) and a minor cleanup in unwind-seh.c 
(indentation, unused variables).

This patch allows to propagate GCC exceptions through any code (including code 
produced by msvc), but to my knowledge propagation of msvc exceptions through 
gcc code doesn't work (because we cancel the exception to run cleanups).

We have tested it heavily in our infrastructure and found no issues in that 
part.  We had to write a specific personality routine for Ada to handle stack 
checking and access violation in user code; but as far as I know this is not 
needed by c++.

I did a manual build and testing for x86_64-pc-mingw32 and I will run a full 
bootstrap and regression run on GNU/Linux.

Tristan.

libstdc++-v3/
* libsupc++/eh_personality.cc (__gxx_personality_seh0): New function.
Adjust for SEH.
* config/abi/pre/gnu.ver: Add __gxx_personality_seh0.

libobjc/
* exception.c (__gnu_objc_personality_seh0): New function.

libjava/
* libgcj.ver: Add __gcj_personality_seh0.
* exception.cc (__gcj_personality_seh0): New function.
Adjust for SEH.

libgcc/
* unwind-seh.c: New file.
* unwind-generic.h: Include windows.h for SEH.
(_Unwind_Exception): Use 6 private fields for SEH.
(_GCC_specific_handler): Declare.
* unwind-c.c (__gcc_personality_seh0): New function.
Adjust for SEH.
* config/i386/libgcc-cygming.ver: New file.
* config/i386/t-seh-eh: New file.
* config.host (x86_64-*-mingw*): Default to seh.

gcc/
* opts.c (finish_options): Handle UI_SEH.
* expr.c (build_personality_function): Handle UI_SEH.
* dwarf2out.c (dwarf2out_begin_prologue): Handle UI_SEH.
* coretypes.h (unwind_info_type): Add UI_SEH.
* config/i386/winnt.c (i386_pe_seh_emit_except_personality):
New function.
(i386_pe_seh_init_sections): Likewise.
* config/i386/cygming.h (TARGET_ASM_EMIT_EXCEPT_PERSONALITY): Define.
(TARGET_ASM_INIT_SECTIONS): Define.
* common/config/i386/i386-common.c (TARGET_EXCEPT_UNWIND_INFO): Define.
(i386_except_unwind_info): New function.

diff --git a/gcc/common/config/i386/i386-common.c 
b/gcc/common/config/i386/i386-common.c
index 70b7eb7..1fe04a6 100644
--- a/gcc/common/config/i386/i386-common.c
+++ b/gcc/common/config/i386/i386-common.c
@@ -667,6 +667,30 @@ ix86_supports_split_stack (bool report ATTRIBUTE_UNUSED,
   return ret;
 }
 
+/* Implement TARGET_EXCEPT_UNWIND_INFO.  */
+
+static enum unwind_info_type
+i386_except_unwind_info (struct gcc_options *opts)
+{
+  /* Honor the --enable-sjlj-exceptions configure switch.  */
+#ifdef CONFIG_SJLJ_EXCEPTIONS
+  if (CONFIG_SJLJ_EXCEPTIONS)
+return UI_SJLJ;
+#endif
+
+  /* On windows 64, prefer SEH exceptions over anything else.  */
+  if (TARGET_64BIT  DEFAULT_ABI == MS_ABI  opts-x_flag_unwind_tables)
+return UI_SEH;
+
+  if (DWARF2_UNWIND_INFO)
+return UI_DWARF2;
+
+  return UI_SJLJ;
+}
+
+#undef  TARGET_EXCEPT_UNWIND_INFO
+#define TARGET_EXCEPT_UNWIND_INFO  i386_except_unwind_info
+
 #undef TARGET_DEFAULT_TARGET_FLAGS
 #define TARGET_DEFAULT_TARGET_FLAGS\
   (TARGET_DEFAULT  \
diff --git a/gcc/config/i386/cygming.h b/gcc/config/i386/cygming.h
index b5f89c4..8455a67 100644
--- a/gcc/config/i386/cygming.h
+++ b/gcc/config/i386/cygming.h
@@ -48,6 +48,10 @@ along with GCC; see the file COPYING3.  If not see
 #define TARGET_ASM_UNWIND_EMIT_BEFORE_INSN  false
 #undef  TARGET_ASM_FUNCTION_END_PROLOGUE
 #define TARGET_ASM_FUNCTION_END_PROLOGUE  i386_pe_seh_end_prologue
+#undef  TARGET_ASM_EMIT_EXCEPT_PERSONALITY
+#define TARGET_ASM_EMIT_EXCEPT_PERSONALITY i386_pe_seh_emit_except_personality
+#undef  TARGET_ASM_INIT_SECTIONS
+#define TARGET_ASM_INIT_SECTIONS  i386_pe_seh_init_sections
 #define SUBTARGET_ASM_UNWIND_INIT  i386_pe_seh_init
 
 #undef DEFAULT_ABI
diff --git a/gcc/config/i386/i386-protos.h b/gcc/config/i386/i386-protos.h
index fe733b0..49e6bbd 100644
--- a/gcc/config/i386/i386-protos.h
+++ b/gcc/config/i386/i386-protos.h
@@ -258,6 +258,8 @@ extern tree i386_pe_mangle_assembler_name (const char *);
 extern void i386_pe_seh_init (FILE *);
 extern void i386_pe_seh_end_prologue (FILE *);
 extern void i386_pe_seh_unwind_emit (FILE *, rtx);
+extern void i386_pe_seh_emit_except_personality (rtx);
+extern void i386_pe_seh_init_sections (void);
 
 /* In winnt-cxx.c and winnt-stubs.c  */
 extern void i386_pe_adjust_class_at_definition (tree);
diff --git a/gcc/config/i386/winnt.c b/gcc/config/i386/winnt.c
index 5b71ccb..17ee137 100644
--- a/gcc/config/i386/winnt.c
+++ b/gcc/config/i386/winnt.c
@@ -1143,6 +1143,48 @@ i386_pe_seh_unwind_emit (FILE *asm_out_file, rtx insn)
  found:
   seh_frame_related_expr (asm_out_file, seh, pat);
 }
+
+void

Re: [PATCH] Move Graphite from using PPL over to ISL

[Tristan Gingold]

On Jul 4, 2012, at 8:31 PM, Magnus Fromreide wrote:

 Hello.
 
 Ever since the ISL patch went in my builds have failed.

Which ISL patch ?

 I am building with local copies of all the libraries, so I have added
 gmp, mpfr, mpc, isl and cloog from ftp://gcc.gnu.org/pub/gcc/infrastructure
 to my source directory.

I am not familiar with this build (I usually build gmp/mpfr/... once and 
install them).
But it looks like isl doesn't see the gmp includes.  But according to 
$(srcdir)/Makefile.in,
gmp is configured with --with-gmp-include.  Was isl correctly configured in 
your case ?

Tristan.

 
 The command sequence I use is
 
 svn co svn://gcc.gnu.org/svn/gcc/trunk
 cd trunk
 ./contrib/download_prerequisites
 wget ftp://gcc.gnu.org/pub/gcc/infrastructure/cloog-0.17.0.tar.gz 
 ftp://gcc.gnu.org/pub/gcc/infrastructure/isl-0.10.tar.bz2
 tar xjf isl-0.10.tar.bz2
 tar xzf cloog-0.17.0.tar.gz
 ln -s cloog-0.17.0 cloog
 ln -s isl-0.10 isl
 cd ..
 mkdir build
 cd build
 ../trunk/configure
 make V=1
 
 and the error message I get is
 
 make[5]: Entering directory `/home/maf/src/gcc/build/isl'
 /bin/sh ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H  -I. 
 -I../../trunk/isl -I../../trunk/isl/include -Iinclude/  -I. -I../../trunk/isl 
 -I../../trunk/isl/include -Iinclude/  -g -fkeep-inline-functions -MT 
 libisl_la-isl_lp_no_piplib.lo -MD -MP -MF 
 .deps/libisl_la-isl_lp_no_piplib.Tpo -c -o libisl_la-isl_lp_no_piplib.lo 
 `test -f 'isl_lp_no_piplib.c' || echo '../../trunk/isl/'`isl_lp_no_piplib.c
 libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../trunk/isl 
 -I../../trunk/isl/include -Iinclude/ -I. -I../../trunk/isl 
 -I../../trunk/isl/include -Iinclude/ -g -fkeep-inline-functions -MT 
 libisl_la-isl_lp_no_piplib.lo -MD -MP -MF 
 .deps/libisl_la-isl_lp_no_piplib.Tpo -c ../../trunk/isl/isl_lp_no_piplib.c -o 
 libisl_la-isl_lp_no_piplib.o
 In file included from ../../trunk/isl/include/isl/lp.h:13:0,
 from ../../trunk/isl/isl_lp_piplib.h:13,
 from ../../trunk/isl/isl_lp_no_piplib.c:10:
 ../../trunk/isl/include/isl/int.h:15:17: fatal error: gmp.h: No such file or 
 directory
 compilation terminated.
 make[5]: *** [libisl_la-isl_lp_no_piplib.lo] Error 1
 make[5]: Leaving directory `/home/maf/src/gcc/build/isl'
 Making all in doc
 make[5]: Entering directory `/home/maf/src/gcc/build/isl/doc'
 make[5]: Nothing to be done for `all'.
 make[5]: Leaving directory `/home/maf/src/gcc/build/isl/doc'
 make[4]: *** [all-recursive] Error 1
 make[4]: Leaving directory `/home/maf/src/gcc/build/isl'
 make[3]: *** [all] Error 2
 make[3]: Leaving directory `/home/maf/src/gcc/build/isl'
 make[2]: *** [all-stage1-isl] Error 2
 make[2]: Leaving directory `/home/maf/src/gcc/build'
 make[1]: *** [stage1-bubble] Error 2
 make[1]: Leaving directory `/home/maf/src/gcc/build'
 make: *** [all] Error 2
 
 but 'ls gmp/gmp.h' shows that the file is there.
 
 Please note that my machine lack the gmp-devel package, so there is no
 /usr/include/gmp.h.
 
 Adding that package makes the build succeed, but that sounds ridiculous as
 there is a local copy.
 
 /MF

Re: [PATCH] Move Graphite from using PPL over to ISL

[Tristan Gingold]

On Jul 2, 2012, at 1:43 PM, Richard Guenther wrote:

 On Thu, 28 Jun 2012, Diego Novillo wrote:
 
 On 12-06-27 11:06 , Richard Guenther wrote:
 
 2012-06-27  Richard Guenther  rguent...@suse.de
 Michael Matz  m...@suse.de
 Tobias Grosser tob...@grosser.es
 Sebastian Pop seb...@gmail.com
 
 config/
 * cloog.m4: Set up to work against ISL only.
 * isl.m4: New file.

Shouldn't ENABLE_IS_CHECK be automatically set to no when building a cross 
canadian ?

Re: [PATCH] Move Graphite from using PPL over to ISL

[Tristan Gingold]

On Jul 4, 2012, at 10:58 AM, Richard Guenther wrote:

 On Wed, 4 Jul 2012, Tristan Gingold wrote:
 
 
 On Jul 2, 2012, at 1:43 PM, Richard Guenther wrote:
 
 On Thu, 28 Jun 2012, Diego Novillo wrote:
 
 On 12-06-27 11:06 , Richard Guenther wrote:
 
 2012-06-27  Richard Guenther  rguent...@suse.de
   Michael Matz  m...@suse.de
   Tobias Grosser tob...@grosser.es
   Sebastian Pop seb...@gmail.com
 
   config/
   * cloog.m4: Set up to work against ISL only.
   * isl.m4: New file.
 
 Shouldn't ENABLE_IS_CHECK be automatically set to no when building a cross 
 canadian ?
 
 Probably yes, as it is a runtime test.  Thus at any time when host != 
 build.  Care to post a patch?  You probably know best what the canonical
 way to check this is.

Something like that ?

Tested by building a cross and a canadian for ia64-hp-openvms.

Tristan.

2012-07-04  Tristan Gingold  ging...@adacore.com

* configure: Regenerate.

config/
2012-07-04  Tristan Gingold  ging...@adacore.com

* isl.m4 (ISL_CHECK_VERSION): Set to yes if cross-compiling.
Fix comments.

diff --git a/config/isl.m4 b/config/isl.m4
index 152d422..831ac26 100644
--- a/config/isl.m4
+++ b/config/isl.m4
@@ -103,7 +103,7 @@ AC_DEFUN([ISL_REQUESTED],
 
 # _ISL_CHECK_CT_PROG(MAJOR, MINOR)
 # 
-# Helper for verifying CLooG's compile time version.
+# Helper for verifying ISL compile time version.
 m4_define([_ISL_CHECK_CT_PROG],[AC_LANG_PROGRAM(
   [#include isl/version.h
[gcc_cv_isl=yes],
-   [gcc_cv_isl=no])])
+   [gcc_cv_isl=no],
+   [gcc_cv_isl=yes])])
 
 CFLAGS=$_isl_saved_CFLAGS
 LDFLAGS=$_isl_saved_LDFLAGS

Re: [PATCH] Move Graphite from using PPL over to ISL

[Tristan Gingold]

On Jul 4, 2012, at 12:32 PM, Richard Guenther wrote:

 On Wed, 4 Jul 2012, Tristan Gingold wrote:
 
 
 On Jul 4, 2012, at 10:58 AM, Richard Guenther wrote:
 
 On Wed, 4 Jul 2012, Tristan Gingold wrote:
 
 
 On Jul 2, 2012, at 1:43 PM, Richard Guenther wrote:
 
 On Thu, 28 Jun 2012, Diego Novillo wrote:
 
 On 12-06-27 11:06 , Richard Guenther wrote:
 
 2012-06-27  Richard Guenther  rguent...@suse.de
 Michael Matz  m...@suse.de
 Tobias Grosser tob...@grosser.es
 Sebastian Pop seb...@gmail.com
 
 config/
 * cloog.m4: Set up to work against ISL only.
 * isl.m4: New file.
 
 Shouldn't ENABLE_IS_CHECK be automatically set to no when building a cross 
 canadian ?
 
 Probably yes, as it is a runtime test.  Thus at any time when host != 
 build.  Care to post a patch?  You probably know best what the canonical
 way to check this is.
 
 Something like that ?
 
 Tested by building a cross and a canadian for ia64-hp-openvms.
 
 Seems to be an incremental patch ontop of the real patch?

No, what does make you think so ?

That's an incremental patch on top of many VMS specific unrelated patches, but 
this is the real patch: building a cross compiler fails without it.

Tristan.

Re: [Patch-v2] Adjustments for Windows x64 SEH

[Tristan Gingold]

On Jun 22, 2012, at 5:04 PM, Richard Henderson wrote:

 On 06/21/2012 12:48 AM, Tristan Gingold wrote:
 2012-06-18  Tristan Gingold  ging...@adacore.com
 
  * config/i386/winnt.c (i386_pe_seh_end_prologue): Move code to ...
  (seh_cfa_adjust_cfa): ... that function.
  (seh_emit_stackalloc): Do not emit out of range values.
  * config/i386/i386.md: Delete unused UNSPEC_REG_SAVE,
  UNSPEC_DEF_CFA constants.
  * config/i386/i386.h (SEH_MAX_FRAME_SIZE): Define.
  * config/i386/i386.c (ix86_frame_pointer_required): Required
  for very large frames on SEH target.
  (ix86_compute_frame_layout): Save area is before frame pointer
  on SEH target.  Handle very large frames.
  (ix86_expand_prologue): Likewise.
 
 Ok.

I propose to backport it to the gcc 4.7 branch, as it fixes two issues: 
incorrect unwind info emitted and support of setjmp.
Is it Ok ?

Tristan.

Re: [Patch] Adjustments for Windows x64 SEH

[Tristan Gingold]

On Jun 18, 2012, at 4:28 PM, Kai Tietz wrote:

 Hello Tristan,
 
 patch works for me, too. Just one nit about the patch.
 
 2012/6/18 Tristan Gingold ging...@adacore.com:
 @@ -8558,6 +8558,11 @@ ix86_frame_pointer_required (void)
   if (TARGET_32BIT_MS_ABI  cfun-calls_setjmp)
 return true;
 
 +  /* Win64 SEH, very large frames need a frame-pointer as maximum stack
 + allocation is 4GB (add a safety guard for saved registers).  */
 +  if (TARGET_64BIT_MS_ABI  get_frame_size () + 4096  SEH_MAX_FRAME_SIZE)
 +return true;
 Where does this magic 4096 comes from?  Is it intended to be the
 page-size, or is it meant to be the maximum stack-frame consumed by
 prologue?  I would suggest to use here instead:
 +  if (TARGET_64BIT_MS_ABI  get_frame_size ()  (SEH_MAX_FRAME_SIZE - 4096))
 +return true;
 
 Additional a testcase for big-stackframe would be interesting.  You
 won't need to make here a execution test, a assembler-scan would be
 enough.

I suppose this is checked by large-frame.c.  But it requires lp64; what is the 
correct writing to enable this test only on 64bit mode ?

Tristan.

Re: [patch] Only define JMP_BUF_SIZE in backends that also define DONT_USE_BUILTIN_SETJMP

[Tristan Gingold]

On Jun 25, 2012, at 10:26 AM, Steven Bosscher wrote:

 On Mon, Jun 25, 2012 at 9:13 AM, Eric Botcazou ebotca...@libertysurf.fr 
 wrote:
 The PA and SPARC back ends do not define  DONT_USE_BUILTIN_SETJMP, so
 they also do not have to define JMP_BUF_SIZE. So:
 
 * config/sparc/sparc.h (JMP_BUF_SIZE): Do not define.
 * config/pa/pa.h (JMP_BUF_SIZE): Likewise.
 
 OK for trunk?
 
 OK for the SPARC, thanks.
 
 And thanks to you for the ack! :-)
 
  What about the Stormy16 and the picoChip?  It seems
 like a cleanup is possible in this area for them as well.
 
 Right, I didn't look at the details of the uses of
 DONT_USE_BUILTIN_SETJMP and JMP_BUF_SIZE but it looks like the ones in
 picochip and stormy16 are redundant too:
 
 For picochip, this port defines DONT_USE_BUILTIN_SETJMP but in the .c
 file (and after all #includes), so it is never exported and not
 otherwise referenced in picochip.c, hence dead:
 config/picochip/picochip.c:#undef DONT_USE_BUILTIN_SETJMP
 config/picochip/picochip.c:#define DONT_USE_BUILTIN_SETJMP 1
 
 stormy16 only undefines DONT_USE_BUILTIN_SETJMP (which is the default
 anyway) so these two lines are redundant:
 config/stormy16/stormy16.h:#undef  DONT_USE_BUILTIN_SETJMP
 config/stormy16/stormy16.h:#define JMP_BUF_SIZE  8
 
 I will remove those lines with the same commit.
 
 That leaves only rl78 and ia64:
 $ egrep DONT_USE_BUILTIN_SETJMP|JMP_BUF_SIZE config/* config/*/*
 config/ia64/freebsd.h:#define JMP_BUF_SIZE  76
 config/ia64/hpux.h:#define JMP_BUF_SIZE  (8 * 76)
 config/ia64/ia64.h:#define DONT_USE_BUILTIN_SETJMP
 config/ia64/linux.h:#define JMP_BUF_SIZE  76
 config/ia64/vms.h:#define JMP_BUF_SIZE  (8 * 76)
 config/rl78/rl78.h:/*#define DONT_USE_BUILTIN_SETJMP 1*/
 config/rl78/rl78.h:#undef DONT_USE_BUILTIN_SETJMP
 config/rl78/rl78.h:#define JMP_BUF_SIZE (8*3+8)
 
 The ia64 ones have no useful comments. The 76 is a magic number and it
 seems strange to me that the size of JMP_BUF_SIZE depends on the OS
 (linux and freebsd have 76, hpux has 8*76, and vms copied the hpux
 example with the comment: Maybe same as HPUX?  Needs to be
 checked.). And anyway, these macros are only relevant for SJLJ
 exceptions - who uses that on ia64??

FTR, until recently I think it was not possible to use SJLJ on ia64 due to a 
typo.

On hpux, the definition of jmp_buf is:

#   define _JBLEN   320
typedef __float80   jmp_buf[_JBLEN/4];

which looks weird...

Tristan.

Re: [Patch-v2] Adjustments for Windows x64 SEH

[Tristan Gingold]

On Jun 21, 2012, at 8:19 PM, Richard Henderson wrote:

 On 2012-06-21 00:48, Tristan Gingold wrote:
 @@ -9142,9 +9152,12 @@ ix86_compute_frame_layout (struct ix86_frame *frame)
 {
   HOST_WIDE_INT diff;
 
 -  /* If we can leave the frame pointer where it is, do so.  */
 +  /* If we can leave the frame pointer where it is, do so.  Also, 
 returns
 + the establisher frame for __builtin_frame_address (0).  */
   diff = frame-stack_pointer_offset - frame-hard_frame_pointer_offset;
 -  if (diff  240 || (diff  15) != 0)
 +  if (diff = SEH_MAX_FRAME_SIZE
 +   (diff  240 || (diff  15) != 0)
 +   !crtl-accesses_prior_frames)
  {
 
 
 Can't this result in diff  240 for access_prior_frames?
 And is thus non-encodable in the unwind info?

This potential issue can only happen when the frame pointer is used.  However, 
just before in ix86_compute_layout, I added:

  /* On SEH target, registers are pushed just before the frame pointer
 location.  */
  if (TARGET_SEH)
frame-hard_frame_pointer_offset = offset;

And in ix86_expand_prologue:

  if (frame_pointer_needed  !m-fs.fp_valid)
{
  /* Note: ATT enter does NOT have reversed args.  Enter is probably
 slower on all targets.  Also sdb doesn't like it.  */
  insn = emit_insn (gen_push (hard_frame_pointer_rtx));
  RTX_FRAME_RELATED_P (insn) = 1;

  /* Push registers now, before setting the frame pointer on SEH.  */
  if (!int_registers_saved
   TARGET_SEH
   !frame.save_regs_using_mov)
{
  ix86_emit_save_regs ();
  int_registers_saved = true;
  gcc_assert (m-fs.sp_offset == frame.reg_save_offset);
}

  if (m-fs.sp_offset == frame.hard_frame_pointer_offset)
{
  insn = emit_move_insn (hard_frame_pointer_rtx, stack_pointer_rtx);
  RTX_FRAME_RELATED_P (insn) = 1;


So when the frame pointer is set, it is equal to the stack pointer and 
therefore offset is always 0.
(This change is necessary because you cannot push registers once the frame is 
setup.  Otherwise during unwinding they are fetch using %rsp, which cannot be 
correctly computed in presence of alloca/dynamic frames)

FTR (and as you know), the Windows x64 prologue is quite rigid, and should 
follow this pattern:

1) pushes
2a) allocate frame
2b) set frame pointer
4) save regs/xmm

You can swap 2a and 2b.
GCC doesn't mix pushing and saving integer registers, but MS compiler does.

Tristan.

Re: [Patch-v2] Adjustments for Windows x64 SEH

[Tristan Gingold]

On Jun 21, 2012, at 1:57 PM, Václav Zeman wrote:

 On 21 June 2012 09:48, Tristan Gingold wrote:
 Here is the new version.  It is now possible to use __builtin_frame_address 
 (0) to get the current establisher frame thanks to a tiny adjustment.
 
 No regressions on x86_64-linux, and an x86_64-windows native gdb can be 
 built and run.
 
 Tristan.
 [...]
 diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
 index ddb3645..44533e0 100644
 --- a/gcc/config/i386/i386.h
 +++ b/gcc/config/i386/i386.h
 @@ -729,6 +729,18 @@ enum target_cpu_default
  /* Boundary (in *bits*) on which the incoming stack is aligned.  */
  #define INCOMING_STACK_BOUNDARY ix86_incoming_stack_boundary
 
 +/* According to Windows x64 software convention, the maximum stack 
 allocatable
 +   in the prologue is 4G - 8 bytes.  Furthermore, there is a limited set of
 +   instructions allowed to adjust the stack pointer in the epilog, forcing 
 the
 +   use of frame pointer for frames larger than 2 GB.  This theorical limit
 +   is reduced by 256, an over-estimated upper bound for the stack use by the
 +   prologue.
 +   We define only one threshold for both the prolog and the epilog.  When 
 the
 +   frame size is larger than this threshold, we allocate the are to save SSE
 A typo there? s/the are/the area/

Yes, thanks.

 
 +   regs, then save them, and then allocate the remaining.  There is no SEH
 +   unwind info for this later allocation.  */
 +#define SEH_MAX_FRAME_SIZE ((2U  30) - 256)
 [...]
 
 -- 
 VZ

Re: [Patch] Adjustments for Windows x64 SEH

[Tristan Gingold]

On Jun 19, 2012, at 6:47 PM, Richard Henderson wrote:

 On 2012-06-18 05:22, Tristan Gingold wrote:
 +  /* Win64 SEH, very large frames need a frame-pointer as maximum stack
 + allocation is 4GB (add a safety guard for saved registers).  */
 +  if (TARGET_64BIT_MS_ABI  get_frame_size () + 4096  SEH_MAX_FRAME_SIZE)
 +return true;
 
 Elsewhere you say this is an upper bound for stack use by the prologue.
 It's clearly a wild guess.  The maximum stack use is 10*sse + 8*int 
 registers saved, which is a lot less than 4096.
 
 That said, I'm ok with *using* 4096 so long that the comment clearly
 states that it's a large over-estimate.  I do suggest, however, folding
 this into the SEH_MAX_FRAME_SIZE value, and expanding on the comment
 there.  I see no practical difference between 0x8000 and 0x7fffe000
 being the limit.

Here is the new comment.  I have reduced the estimation to 256.

/* According to Windows x64 software convention, the maximum stack allocatable
   in the prologue is 4G - 8 bytes.  Furthermore, there is a limited set of
   instructions allowed to adjust the stack pointer in the epilog, forcing the
   use of frame pointer for frames larger than 2 GB.  This theorical limit
   is reduced by 256, an over-estimated upper bound for the stack use by the
   prologue.
   We define only one threshold for both the prolog and the epilog.  When the
   frame size is larger than this threshold, we allocate the are to save SSE
   regs, then save them, and then allocate the remaining.  There is no SEH
   unwind info for this later allocation.  */
#define SEH_MAX_FRAME_SIZE ((2U  30) - 256)


 
 +/* Output assembly code to get the establisher frame (Windows x64 only).
 +   This corresponds to what will be computed by Windows from Frame Register
 +   and Frame Register Offset fields of the UNWIND_INFO structure.  Since
 +   these values are computed very late (by ix86_expand_prologue), we cannot
 +   express this using only RTL.  */
 +
 +const char *
 +ix86_output_establisher_frame (rtx target)
 +{
 +  if (!frame_pointer_needed)
 +{
 +  /* Note that we have advertized an lea operation.  */
 +  output_asm_insn (lea{q}\t{0(%%rsp), %0|%0, 0[rsp]}, target);
 +}
 +  else
 +{
 +  rtx xops[3];
 +  struct ix86_frame frame;
 +
 +  /* Recompute the frame layout here.  */
 +  ix86_compute_frame_layout (frame);
 +
 +  /* Closely follow how the frame pointer is set in
 + ix86_expand_prologue.  */
 +  xops[0] = target;
 +  xops[1] = hard_frame_pointer_rtx;
 +  if (frame.hard_frame_pointer_offset == frame.reg_save_offset)
 +xops[2] = GEN_INT (0);
 +  else
 +xops[2] = GEN_INT (-(frame.stack_pointer_offset
 + - frame.hard_frame_pointer_offset));
 +  output_asm_insn (lea{q}\t{%a2(%1), %0|%0, %a2[%1]}, xops);
 
 This is what register elimination is for; the value substitution happens
 during reload.
 
 Now, one *could* add a new pseudo-hard-register for this (we support as
 many register eliminations as needed), but before we do that we need to
 decide if we can adjust the soft frame pointer to be the value required.
 If so, you can then rely on the existing __builtin_frame_address.  Which
 is a very attractive sounding solution.  I'm 99% moving the sfp will work.

Thank you for this idea.  I am trying to implement it.

Tristan.

Re: [Patch] Adjustments for Windows x64 SEH

[Tristan Gingold]

On Jun 18, 2012, at 4:28 PM, Kai Tietz wrote:

 Hello Tristan,
 
 patch works for me, too. Just one nit about the patch.
 
 2012/6/18 Tristan Gingold ging...@adacore.com:
 @@ -8558,6 +8558,11 @@ ix86_frame_pointer_required (void)
   if (TARGET_32BIT_MS_ABI  cfun-calls_setjmp)
 return true;
 
 +  /* Win64 SEH, very large frames need a frame-pointer as maximum stack
 + allocation is 4GB (add a safety guard for saved registers).  */
 +  if (TARGET_64BIT_MS_ABI  get_frame_size () + 4096  SEH_MAX_FRAME_SIZE)
 +return true;
 Where does this magic 4096 comes from?  Is it intended to be the
 page-size, or is it meant to be the maximum stack-frame consumed by
 prologue?

It is an upper bound for the maximum stack-frame consumed by prologue.

  I would suggest to use here instead:
 +  if (TARGET_64BIT_MS_ABI  get_frame_size ()  (SEH_MAX_FRAME_SIZE - 4096))
 +return true;
 
 Additional a testcase for big-stackframe would be interesting.  You
 won't need to make here a execution test, a assembler-scan would be
 enough.

I think that a simple build test should make it.

Thanks,
Tristan.

Re: [patch] Remove VMS_TARGET

[Tristan Gingold]

On Jun 18, 2012, at 1:01 PM, Steven Bosscher wrote:

 Hello,
 
 There are exactly 2 references to the target macro VMS_TARGET:
 
 cp/decl.c:#if VMS_TARGET
 config/vax/vax.h:#define VMS_TARGET 0
 
 I'm not sure what the macro is for. GCC seems to support a couple of
 VMS targets, but none of them define VMS_TARGET.
 
 This patch remove the macro. I can't test this because I have no
 access to a VMS machine, but it is pretty obvious that the macro is
 dead code.

The return code conversion is performed by vms-ucrt0.c and indeed this code is 
not used.

Tristan.

[Patch] Adjustments for Windows x64 SEH

[Tristan Gingold]

Hi,

at AdaCore, we are now using native SEH exceptions for Windows x64 based on 
Richard's patch

 http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01966.html

I plan to submit a rebased version of this work soon, but we have found a few 
issues in the port:

* Registers cannot be pushed once the frame pointer is set.  Otherwise the 
unwinder is not able to read the old values.

* There was no protection against very large frame size.  We have a few tests 
declaring huge local array ( 2 GB) for the purpose of testing stack checking.  
Without rework, this created either ICE or gas errors, because unwind info 
cannot handle such large values or because an extra register is needed to save 
or spill a register.  I fixed this issue by allocating a small area just to 
save the registers and then allocating the remaining.  There is no unwind info 
emitted for the second (and large) area, as if it were allocated by alloca.

* In order to implement setjmp/longjmp via RtlUnwindEx, we need to pass to 
setjmp the value of the establish frame address for the current function.  I 
added for this purpose a new builtin (__builtin_establisher_frame).  This was 
manually tested by building and using gdb which uses setjmp/longjmp internally 
for its exception mechanism.

Bootstrapped and regtested on x86_64 GNU/Linux.

Comments are welcome.

Tristan.

2012-06-18  Tristan Gingold  ging...@adacore.com

* doc/extend.texi (X86 Built-in Functions): Document
__builtin_establisher_frame.
* config/i386/winnt.c (i386_pe_seh_end_prologue): Move code to ...
(seh_cfa_adjust_cfa): ... that function.
(seh_emit_stackalloc): Do not emit out of range values.
* config/i386/i386.md: Delete unused UNSPEC_REG_SAVE,
UNSPEC_DEF_CFA constants.
Add UNSPEC_ESTABLISHER_FRAME.
(establisher_frame): Add insn.
* config/i386/i386.h (SEH_MAX_FRAME_SIZE): Define.
* config/i386/i386.c (ix86_frame_pointer_required): Required
for very large frames on SEH target.
(ix86_compute_frame_layout): Save area is before frame pointer
on SEH target.  Handle very large frames.
(ix86_expand_prologue): Likewise.
(enum ix86_builtins): Add IX86_BUILTIN_ESTABLISHER_FRAME.
(ix86_init_builtins): Add __builtin_establisher_frame.
(ix86_expand_builtin): Handle IX86_BUILTIN_ESTABLISHER_FRAME.
(ix86_output_establisher_frame): New function.
* config/i386/i386-protos.h (ix86_output_establisher_frame): Declare.

diff --git a/gcc/config/i386/i386-protos.h b/gcc/config/i386/i386-protos.h
index f300a56..28aa928 100644
--- a/gcc/config/i386/i386-protos.h
+++ b/gcc/config/i386/i386-protos.h
@@ -79,6 +79,7 @@ extern const char *output_fix_trunc (rtx, rtx*, bool);
 extern const char *output_fp_compare (rtx, rtx*, bool, bool);
 extern const char *output_adjust_stack_and_probe (rtx);
 extern const char *output_probe_stack_range (rtx, rtx);
+extern const char *ix86_output_establisher_frame (rtx);
 
 extern void ix86_expand_clear (rtx);
 extern void ix86_expand_move (enum machine_mode, rtx[]);
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index e2f5740..126c0cd 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -8558,6 +8558,11 @@ ix86_frame_pointer_required (void)
   if (TARGET_32BIT_MS_ABI  cfun-calls_setjmp)
 return true;
 
+  /* Win64 SEH, very large frames need a frame-pointer as maximum stack
+ allocation is 4GB (add a safety guard for saved registers).  */
+  if (TARGET_64BIT_MS_ABI  get_frame_size () + 4096  SEH_MAX_FRAME_SIZE)
+return true;
+
   /* In ix86_option_override_internal, TARGET_OMIT_LEAF_FRAME_POINTER
  turns off the frame pointer by default.  Turn it back on now if
  we've not got a leaf function.  */
@@ -9051,6 +9056,11 @@ ix86_compute_frame_layout (struct ix86_frame *frame)
   offset += frame-nregs * UNITS_PER_WORD;
   frame-reg_save_offset = offset;
 
+  /* On SEH target, registers are pushed just before the frame pointer
+ location.  */
+  if (TARGET_SEH)
+frame-hard_frame_pointer_offset = offset;
+
   /* Align and set SSE register save area.  */
   if (frame-nsseregs)
 {
@@ -9144,7 +9154,7 @@ ix86_compute_frame_layout (struct ix86_frame *frame)
 
   /* If we can leave the frame pointer where it is, do so.  */
   diff = frame-stack_pointer_offset - frame-hard_frame_pointer_offset;
-  if (diff  240 || (diff  15) != 0)
+  if (diff = SEH_MAX_FRAME_SIZE  (diff  240 || (diff  15) != 0))
{
  /* Ideally we'd determine what portion of the local stack frame
 (within the constraint of the lowest 240) is most heavily used.
@@ -10146,6 +10156,7 @@ ix86_expand_prologue (void)
   struct ix86_frame frame;
   HOST_WIDE_INT allocate;
   bool int_registers_saved;
+  bool sse_registers_saved;
 
   ix86_finalize_stack_realign_flags ();
 
@@ -10298,6 +10309,9 @@ ix86_expand_prologue (void)
   m-fs.realigned = true

Re: long long availability in host compiler (Re: constant that doesn't fit in 32bits in alpha.c)

[Tristan Gingold]

On Jun 14, 2012, at 11:12 AM, Pedro Alves wrote:

 On 06/13/2012 10:35 PM, Richard Henderson wrote:
 
 On 2012-06-13 02:13, Pedro Alves wrote:
 Related, does gcc forbid long long / ULL ?
 
 
 Normally, yes.  The vmsdbgout.c file seems to use it all over though.
 
 
 And git blame shows:
 
 8d60d2bc (kenner   2001-12-02 14:38:07 +   41) /* Difference in seconds 
 between the VMS Epoch and the Unix Epoch */
 8d60d2bc (kenner   2001-12-02 14:38:07 +   42) static const long long 
 vms_epoch_offset = 3506716800ll;
   ^^
 
 That's my point.  We've been using long long / ll for a while now without
 noticing (I least I hadn't noticed the libdecnumber uses before), and nobody
 seems to have tripped on any host compiler that doesn't support it.  Is it
 justifiable nowadays to not assume it's available?

OTOH, this file is compiled only for alpha-vms target, so I doubt it is 
commonly compiled.

Tristan.

Re: [Ada] Preliminary work to support SEH on Windows 64

[Tristan Gingold]

On Jun 12, 2012, at 5:00 PM, Gabriel Dos Reis wrote:

 On Tue, Jun 12, 2012 at 7:33 AM, Arnaud Charlet char...@adacore.com wrote:
 No functional change.
 
 Tested on x86_64-pc-linux-gnu, committed on trunk
 
 2012-06-12  Tristan Gingold  ging...@adacore.com
 
* a-exexpr-gcc.adb (Unwind_Exception): Add 4 more private fields.
 
 
 Does this mean that GCC will officially support SEH -- which surely is a
 language-independent infrastructure, usable by other front ends?

Richard Henderson has submitted (a few years ago) a patch to add SEH support 
for Windows 64.
We have rebased it and we are testing it for Ada with our tests.

I hope this work will be soon ready and I plan to resubmit the patch (which in 
fact was only
partially committed: only SEH unwinding info generation are currently in GCC).

I haven't tested it with C++ (I think Richard did), but it should work: the 
runtime interface routines to SEH is sane.

Tristan.

Ping: [Patch]: Fix call to end_prologue debug hook

[Tristan Gingold]

Ping for:

On May 15, 2012, at 11:26 AM, Tristan Gingold wrote:

 Hi,
 
 the end_prologue debug hook (only used by dwarf on VMS) is currently called 
 at the NOTE_INSN_FUNCTION_BEG.  This is not what its name implies, neither 
 what the VMS debugger expect and neither what a comment in dwarf2out.c says:
 
  /* Recall that this end-of-prologue indication is *not* the same thing
 as the end_prologue debug hook.  The NOTE_INSN_PROLOGUE_END note,
 to which the hook corresponds, follows the last insn that was 
 emitted by gen_prologue.  What we need is to preceed the first insn
 that had been emitted after NOTE_INSN_FUNCTION_BEG, i.e. the first
 insn that corresponds to something the user wrote.  These may be
 very different locations once scheduling is enabled.  */
 
 This is fixed by this patch.
 
 No regressions on x86_64 GNU/Linux.
 
 Ok for trunk ?
 
 Tristan.
 
 2012-05-15  Tristan Gingold  ging...@adacore.com
 
   * final.c (final_scan_insn): Move call to end_prologue debug hook
   to the NOTE_INSN_PROLOGUE_END.
 
 diff --git a/gcc/final.c b/gcc/final.c
 index 718caf1..6efa06f 100644
 --- a/gcc/final.c
 +++ b/gcc/final.c
 @@ -1961,6 +1961,8 @@ final_scan_insn (rtx insn, FILE *file, int optimize_p 
 ATTR
case NOTE_INSN_PROLOGUE_END:
  targetm.asm_out.function_end_prologue (file);
  profile_after_prologue (file);
 + if (!DECL_IGNORED_P (current_function_decl))
 +   debug_hooks-end_prologue (last_linenum, last_filename);
 
  if ((*seen  (SEEN_EMITTED | SEEN_NOTE)) == SEEN_NOTE)
{
 @@ -1989,8 +1991,6 @@ final_scan_insn (rtx insn, FILE *file, int optimize_p 
 ATTR
 
case NOTE_INSN_FUNCTION_BEG:
  app_disable ();
 - if (!DECL_IGNORED_P (current_function_decl))
 -   debug_hooks-end_prologue (last_linenum, last_filename);
 
  if ((*seen  (SEEN_EMITTED | SEEN_NOTE)) == SEEN_NOTE)
{
 

Ping: [Patch]: Fix ICE by expand_expr_addr_expr_1

[Tristan Gingold]

Ping for:


On May 15, 2012, at 10:59 AM, Tristan Gingold wrote:

 Hi,
 
 I got ICE in plus_constant (after the assertions were added) due to 
 expand_expr_addr_expr_1 during build on ia64/Openvms.
 
 This function is called with TMODE == SImode (32 bit pointers) but EXP 
 designating a variable on the frame (whose register is DImode).
 Hence the ICE.
 
 Fixed by the following patch.
 No regression on x86-64 GNU/Linux.
 
 Ok for trunk ?
 
 Tristan.
 
 2012-05-15  Tristan Gingold  ging...@adacore.com
 
   * expr.c (expand_expr_addr_expr_1): Call
   convert_memory_address_addr_space.
 
 diff --git a/gcc/expr.c b/gcc/expr.c
 index 3edb4a2..1b0ad8d 100644
 --- a/gcc/expr.c
 +++ b/gcc/expr.c
 @@ -7600,6 +7600,7 @@ expand_expr_addr_expr_1 (tree exp, rtx target, enum 
 machin
   TYPE_USER_ALIGN (TREE_TYPE (inner)) = 1;
 }
   result = expand_expr_addr_expr_1 (inner, subtarget, tmode, modifier, as);
 +  result = convert_memory_address_addr_space (tmode, result, as);
 
   if (offset)
 {
 

Re: FYI: 1500+ typos, with suggested fixes

[Tristan Gingold]

On May 29, 2012, at 2:49 PM, Jim Meyering wrote:

 Running the following command spots over 1500 typos, and suggests fixes:
 
  $ git ls-files|misspellings -f -|grep -v '^ERROR:'|perl -pe \
  's/^(.*?)\[(\d+)\]: (\w+) - (.*?)$/sed -i '\''${2}s!$3!$4!'\'' $1/'  k
 
 The misspellings command comes from here:
  http://github.com/lyda/misspell-check
 
 From the list below, I've excluded any that affect ChangeLog or .po files:
 
  $ grep -vE 'ChangeLog|\.po$' k  k2
 
 (Note that these sed commands are just suggestions that do not take
 into account any context, and that some of them have two or more
 alternates, so that applying the sed command as-is would be invalid.
 
 Also note: the line numbers listed below work for me with yesterday's
 up-to-date trunk, but if you want to use these commands, you should rerun
 the commands above so that the line numbers reflect your actual sources.
 )
 
 This is just a heads up.
 I'm not volunteering to make these changes.

Some of them are wrong for Ada:

 sed -i '80s!withing!within!' gcc/ada/a-calend-vms.adb
 sed -i '79s!withing!within!' gcc/ada/a-calend.adb
 sed -i '1488s!withing!within!' gcc/ada/a-calend.adb

withing is the action of 'with' a unit.

 sed -i '41s!STPO!Stop!' gcc/ada/a-dynpri.adb

STPO is the acronym of System.Task_Primitives.Operations


Tristan.

Re: Regenerating fixincludes/configure

[Tristan Gingold]

On May 29, 2012, at 5:27 PM, Thomas Schwinge wrote:

 Hi!
 
 While looking at libatomic's, I noticed that fixincludes' configure can't
 be regenerated without errors.  Here is a patch, in spirit of
 749dea2a0549c126a0e992a6dd8e9b5eb28e1cee.  OK to commit?

Humm, looks like the same as Tobias patch:

http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01465.html

That I commented in:

http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01467.html

Tristan.

Re: [Patch]: Fix very large frame bug on i386

[Tristan Gingold]

On May 22, 2012, at 7:17 PM, Richard Henderson wrote:

 On 05/15/12 02:10, Tristan Gingold wrote:
 2012-05-15  Tristan Gingold  ging...@adacore.com
 
  * config/i386/i386.c (struct ix86_frame): Remove unused frame field.
  (ix86_compute_frame_layout): Fix type of stack_alignment_needed
  and preferred_alignment.
 
 Ok with a test case.  Even if it's a scan-assember sort of test.

Thanks, now committed with the following testcase:

/* { dg-do compile } */
/* { dg-require-effective-target lp64 } */
/* { dg-final { scan-assembler -429496 } } */
extern void dump (int *buf, int a);

void func (int a)
{
  int bigbuf[1  30];
  dump (bigbuf, a);
}


Tristan.

Re: [Patch]: Fix typo in common/config/ia64/ia64-common.c

[Tristan Gingold]

On May 22, 2012, at 7:17 PM, Richard Henderson wrote:

 On 05/15/12 01:52, Tristan Gingold wrote:
 2012-05-14  Tristan Gingold  ging...@adacore.com
 
  * common/config/ia64/ia64-common.c (ia64_except_unwind_info): Fix typo.
 
 Ok.

Thanks, committed.

Tristan.

Re: Fix fixinclude's configure{,.ac}

[Tristan Gingold]

On May 22, 2012, at 11:20 AM, Tobias Burnus wrote:

 Dear all,
 
 an --enable-maintainers-build fails here with:
 
 configure.ac:99: error: possibly undefined macro: gcc_AC_FUNC_MMAP_BLACKLIST
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.
 make[3]: *** [fixincludes/configure] Error 1
 
 Looking at Tristan's commit Rev. 186106 of 2012-04-03, the change gcc_ - 
 GCC_ is missing. It also looks as if the fixinclude/ config files where not 
 regenerated, even though there was a later patch by Tristan which touches 
 fixinclude's config files (Rev. 186759 of 2012-04-24).

Indeed, I failed to notice that fixinclude was using ../gcc/config.m4.

I think it would also make sense to remove '-I ../gcc' from ACLOCAL_AMFLAGS of 
fixincludes/Makefile.in

Thank you for having noticed and fixed this bug,
Tristan.

[ Bruce CC as he is the maintained of fixinclude]

 
 OK for the trunk? (I think it is really obvious.)
 
 Tobias
 fixinclude.diff

Re: [Patch]: Fix very large frame bug on i386

[Tristan Gingold]

Ping for:

On May 15, 2012, at 11:10 AM, Tristan Gingold wrote:

 Hi,
 
 use of 'unsigned int' for i386.c:ix86_compute_frame_layout 
 stack_alignment_needed results in truncation of frame offset in code such as:
 
 offset = (offset + stack_alignment_needed - 1)  -stack_alignment_needed
 
 (as it is -stack_alignment_needed that is converted to HOST_WIDE_INT).
 
 As a consequence, frames larger than 4GB are squeezed.
 
 Also, the frame field of struct ix86_frame is never used.
 
 Bootstrapped and reg-tested on x86_64 GNU/Linux, without regressions.
 
 Ok for trunk ?
 
 Tristan.
 
 2012-05-15  Tristan Gingold  ging...@adacore.com
 
   * config/i386/i386.c (struct ix86_frame): Remove unused frame field.
   (ix86_compute_frame_layout): Fix type of stack_alignment_needed
   and preferred_alignment.
 
 diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
 index ad4739b..353ee53 100644
 --- a/gcc/config/i386/i386.c
 +++ b/gcc/config/i386/i386.c
 @@ -2408,7 +2408,6 @@ struct ix86_frame
   int va_arg_size;
   int red_zone_size;
   int outgoing_arguments_size;
 -  HOST_WIDE_INT frame;
 
   /* The offsets relative to ARG_POINTER.  */
   HOST_WIDE_INT frame_pointer_offset;
 @@ -8937,9 +8936,9 @@ ix86_builtin_setjmp_frame_value (void)
 static void
 ix86_compute_frame_layout (struct ix86_frame *frame)
 {
 -  unsigned int stack_alignment_needed;
 +  unsigned HOST_WIDE_INT stack_alignment_needed;
   HOST_WIDE_INT offset;
 -  unsigned int preferred_alignment;
 +  unsigned HOST_WIDE_INT preferred_alignment;
   HOST_WIDE_INT size = get_frame_size ();
   HOST_WIDE_INT to_allocate;
 
 

Re: Missing guard in ira-color.c ?

[Tristan Gingold]

On May 10, 2012, at 10:41 PM, Vladimir Makarov wrote:

 On 05/10/2012 09:10 AM, Tristan Gingold wrote:
 Hi,
 
 I am getting a segfault in ira-color.c:2945 on the trunk:
 
 Program received signal SIGSEGV, Segmentation fault.
 0x00a79f37 in move_spill_restore () at ../../src/gcc/ira-color.c:2945
 2945   || ira_reg_equiv_const[regno] != NULL_RTX
 (gdb) l
 2940   /* don't do the optimization because it can create
 2941  copies and the reload pass can spill the allocno set
 2942  by copy although the allocno will not get memory
 2943  slot.  */
 2944   || ira_reg_equiv_invariant_p[regno]
 2945   || ira_reg_equiv_const[regno] != NULL_RTX
 2946   || !bitmap_bit_p (loop_node-border_allocnos, ALLOCNO_NUM 
 (a)))
 2947 continue;
 2948   mode = ALLOCNO_MODE (a);
 2949   rclass = ALLOCNO_CLASS (a);
 
 while building gcc (gnatcmd.adb file) for ia64-vms using a cross compiler 
 (target=ia64-vms, host=x86_64-linux).
 
 The reason looks to be an out of bounds access:
 
 (gdb) print regno
 $10 = 18476
 (gdb) print ira_reg_equiv_len
 $11 = 17984
 
 (I suppose this setup is not easy at all to reproduce, but I can provide any 
 files, if necessary).
 Tristan, thanks for reporting this.
 Wild guess, as I don't know IRA at all:  looks like in this file most 
 accesses to ira_reg_equiv_* are guarded.  Is it expected that they aren't at 
 this point ?
 Yes, I guess.  It is possible to have the pseudos which are out of range 
 ira_reg_equiv_const.  It should be hard to reproduce such error because they 
 are generated when we need to break circular dependence (e.g. when hard 
 register 1 should be moved to hard register 2 and hard register 2 to hard 
 register 1).
 
 Your solution is perfectly fine.  So you can commit the patch into the trunk 
 as pre-approved.

Now committed, after reg-testing on GNU/Linux x86_64.

Tristan.

[Patch]: Fix typo in common/config/ia64/ia64-common.c

[Tristan Gingold]

hi,

looks like a typo...

Ok for trunk ?

Tristan.

2012-05-14  Tristan Gingold  ging...@adacore.com

* common/config/ia64/ia64-common.c (ia64_except_unwind_info): Fix typo.

diff --git a/gcc/common/config/ia64/ia64-common.c b/gcc/common/config/ia64/ia64-
index 1168253..79aed6a 100644
--- a/gcc/common/config/ia64/ia64-common.c
+++ b/gcc/common/config/ia64/ia64-common.c
@@ -71,8 +71,8 @@ enum unwind_info_type
 ia64_except_unwind_info (struct gcc_options *opts)
 {
   /* Honor the --enable-sjlj-exceptions configure switch.  */
-#ifdef CONFIG_UNWIND_EXCEPTIONS
-  if (CONFIG_UNWIND_EXCEPTIONS)
+#ifdef CONFIG_SJLJ_EXCEPTIONS
+  if (CONFIG_SJLJ_EXCEPTIONS)
 return UI_SJLJ;
 #endif
 

[PATCH v2]: handle size_t /= ptr size in tree-ssa-strlen.c

[Tristan Gingold]

On May 4, 2012, at 2:34 PM, Richard Guenther wrote:

 On Fri, May 4, 2012 at 2:27 PM, Tristan Gingold ging...@adacore.com wrote:
 Hi,
 
 get_string_length assumes that precision of size_t is the same as precision 
 of a pointer, which isn't always true at least on VMS.
 This patch simply add a conversion in case of mismatch.
 
 Tested on ia64/VMS by cross-bootstrapping.
 Bootstrapped and regtested on i386/GNU Linux.
 
 Ok for trunk ?
 
 Hmm, isn't the issue that size_t precision is not the same precision as
 sizetype?  You probably should use ptrofftype_p (TREE_TYPE (lhs))
 instead of spelling out 'sizetype' here.

So, second submission after bootstrapping and reg-testing on x86-64 GNU/Linux.

Ok for trunk ?

Tristan.

2012-05-04  Tristan Gingold  ging...@adacore.com

   * tree-ssa-strlen.c (get_string_length): Convert lhs if needed.

diff --git a/gcc/tree-ssa-strlen.c b/gcc/tree-ssa-strlen.c
index a37633a..05fd10d 100644
--- a/gcc/tree-ssa-strlen.c
+++ b/gcc/tree-ssa-strlen.c
@@ -427,6 +427,12 @@ get_string_length (strinfo si)
NULL);
  add_referenced_var (lhs_var);
  tem = gimple_call_arg (stmt, 0);
+  if (!ptrofftype_p (TREE_TYPE (lhs)))
+{
+  lhs = convert_to_ptrofftype (lhs);
+  lhs = force_gimple_operand_gsi (gsi, lhs, true, NULL_TREE,
+  true, GSI_SAME_STMT);
+}
  lenstmt
= gimple_build_assign_with_ops (POINTER_PLUS_EXPR,
make_ssa_name (lhs_var, NULL),

[Patch]: Fix ICE by expand_expr_addr_expr_1

[Tristan Gingold]

Hi,

I got ICE in plus_constant (after the assertions were added) due to 
expand_expr_addr_expr_1 during build on ia64/Openvms.

This function is called with TMODE == SImode (32 bit pointers) but EXP 
designating a variable on the frame (whose register is DImode).
Hence the ICE.

Fixed by the following patch.
No regression on x86-64 GNU/Linux.

Ok for trunk ?

Tristan.

2012-05-15  Tristan Gingold  ging...@adacore.com

* expr.c (expand_expr_addr_expr_1): Call
convert_memory_address_addr_space.

diff --git a/gcc/expr.c b/gcc/expr.c
index 3edb4a2..1b0ad8d 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -7600,6 +7600,7 @@ expand_expr_addr_expr_1 (tree exp, rtx target, enum machin
   TYPE_USER_ALIGN (TREE_TYPE (inner)) = 1;
 }
   result = expand_expr_addr_expr_1 (inner, subtarget, tmode, modifier, as);
+  result = convert_memory_address_addr_space (tmode, result, as);
 
   if (offset)
 {

[Patch]: Fix very large frame bug on i386

[Tristan Gingold]

Hi,

use of 'unsigned int' for i386.c:ix86_compute_frame_layout 
stack_alignment_needed results in truncation of frame offset in code such as:

 offset = (offset + stack_alignment_needed - 1)  -stack_alignment_needed

(as it is -stack_alignment_needed that is converted to HOST_WIDE_INT).

As a consequence, frames larger than 4GB are squeezed.

Also, the frame field of struct ix86_frame is never used.

Bootstrapped and reg-tested on x86_64 GNU/Linux, without regressions.

Ok for trunk ?

Tristan.

2012-05-15  Tristan Gingold  ging...@adacore.com

* config/i386/i386.c (struct ix86_frame): Remove unused frame field.
(ix86_compute_frame_layout): Fix type of stack_alignment_needed
and preferred_alignment.

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index ad4739b..353ee53 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -2408,7 +2408,6 @@ struct ix86_frame
   int va_arg_size;
   int red_zone_size;
   int outgoing_arguments_size;
-  HOST_WIDE_INT frame;
 
   /* The offsets relative to ARG_POINTER.  */
   HOST_WIDE_INT frame_pointer_offset;
@@ -8937,9 +8936,9 @@ ix86_builtin_setjmp_frame_value (void)
 static void
 ix86_compute_frame_layout (struct ix86_frame *frame)
 {
-  unsigned int stack_alignment_needed;
+  unsigned HOST_WIDE_INT stack_alignment_needed;
   HOST_WIDE_INT offset;
-  unsigned int preferred_alignment;
+  unsigned HOST_WIDE_INT preferred_alignment;
   HOST_WIDE_INT size = get_frame_size ();
   HOST_WIDE_INT to_allocate;
 

[Patch]: Fix call to end_prologue debug hook

[Tristan Gingold]

Hi,

the end_prologue debug hook (only used by dwarf on VMS) is currently called at 
the NOTE_INSN_FUNCTION_BEG.  This is not what its name implies, neither what 
the VMS debugger expect and neither what a comment in dwarf2out.c says:

  /* Recall that this end-of-prologue indication is *not* the same thing
 as the end_prologue debug hook.  The NOTE_INSN_PROLOGUE_END note,
 to which the hook corresponds, follows the last insn that was 
 emitted by gen_prologue.  What we need is to preceed the first insn
 that had been emitted after NOTE_INSN_FUNCTION_BEG, i.e. the first
 insn that corresponds to something the user wrote.  These may be
 very different locations once scheduling is enabled.  */

This is fixed by this patch.

No regressions on x86_64 GNU/Linux.

Ok for trunk ?

Tristan.

2012-05-15  Tristan Gingold  ging...@adacore.com

* final.c (final_scan_insn): Move call to end_prologue debug hook
to the NOTE_INSN_PROLOGUE_END.

diff --git a/gcc/final.c b/gcc/final.c
index 718caf1..6efa06f 100644
--- a/gcc/final.c
+++ b/gcc/final.c
@@ -1961,6 +1961,8 @@ final_scan_insn (rtx insn, FILE *file, int optimize_p ATTR
case NOTE_INSN_PROLOGUE_END:
  targetm.asm_out.function_end_prologue (file);
  profile_after_prologue (file);
+ if (!DECL_IGNORED_P (current_function_decl))
+   debug_hooks-end_prologue (last_linenum, last_filename);
 
  if ((*seen  (SEEN_EMITTED | SEEN_NOTE)) == SEEN_NOTE)
{
@@ -1989,8 +1991,6 @@ final_scan_insn (rtx insn, FILE *file, int optimize_p ATTR
 
case NOTE_INSN_FUNCTION_BEG:
  app_disable ();
- if (!DECL_IGNORED_P (current_function_decl))
-   debug_hooks-end_prologue (last_linenum, last_filename);
 
  if ((*seen  (SEEN_EMITTED | SEEN_NOTE)) == SEEN_NOTE)
{

Re: [PATCH v2]: handle size_t /= ptr size in tree-ssa-strlen.c

[Tristan Gingold]

On May 15, 2012, at 11:13 AM, Richard Guenther wrote:

 On Tue, May 15, 2012 at 10:55 AM, Tristan Gingold ging...@adacore.com wrote:
 
 On May 4, 2012, at 2:34 PM, Richard Guenther wrote:
 
 On Fri, May 4, 2012 at 2:27 PM, Tristan Gingold ging...@adacore.com wrote:
 Hi,
 
 get_string_length assumes that precision of size_t is the same as 
 precision of a pointer, which isn't always true at least on VMS.
 This patch simply add a conversion in case of mismatch.
 
 Tested on ia64/VMS by cross-bootstrapping.
 Bootstrapped and regtested on i386/GNU Linux.
 
 Ok for trunk ?
 
 Hmm, isn't the issue that size_t precision is not the same precision as
 sizetype?  You probably should use ptrofftype_p (TREE_TYPE (lhs))
 instead of spelling out 'sizetype' here.
 
 So, second submission after bootstrapping and reg-testing on x86-64 
 GNU/Linux.
 
 Ok for trunk ?
 
 Ok.

Thanks, now committed.

Tristan.

 
 Thanks,
 Richard.
 
 Tristan.
 
 2012-05-04  Tristan Gingold  ging...@adacore.com
 
   * tree-ssa-strlen.c (get_string_length): Convert lhs if needed.
 
 diff --git a/gcc/tree-ssa-strlen.c b/gcc/tree-ssa-strlen.c
 index a37633a..05fd10d 100644
 --- a/gcc/tree-ssa-strlen.c
 +++ b/gcc/tree-ssa-strlen.c
 @@ -427,6 +427,12 @@ get_string_length (strinfo si)
NULL);
  add_referenced_var (lhs_var);
  tem = gimple_call_arg (stmt, 0);
 +  if (!ptrofftype_p (TREE_TYPE (lhs)))
 +{
 +  lhs = convert_to_ptrofftype (lhs);
 +  lhs = force_gimple_operand_gsi (gsi, lhs, true, NULL_TREE,
 +  true, GSI_SAME_STMT);
 +}
  lenstmt
= gimple_build_assign_with_ops (POINTER_PLUS_EXPR,
make_ssa_name (lhs_var, NULL),
 

Re: Ping: always supply a mode to plus_constant

[Tristan Gingold]

On May 14, 2012, at 3:23 PM, Richard Sandiford wrote:

 Richard Guenther richard.guent...@gmail.com writes:
 On Sun, May 6, 2012 at 12:23 AM, H.J. Lu hjl.to...@gmail.com wrote:
 On Thu, May 3, 2012 at 11:15 AM, Richard Sandiford
 rdsandif...@googlemail.com wrote:
 Ping for this patch to always supply a mode to plus_constant:
 
http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00892.html
 
 I've done a diff of the changes since the original test revision
 (which was r186448 FWIW) and there's only been one plus_constant-
 related change since then: Alan's rs6000 prologue/epilogue fixes.
 I'd repeat the original testing before committing.
 
 
 This caused:
 
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53249
 
 It also casuses IA64 build to fail for me:
 
 /gcc/spec/sb-terbium-head-64/gcc/gcc/config/ia64/ia64.c: In function
 'ia64_emit_probe_stack_range':
 /gcc/spec/sb-terbium-head-64/gcc/gcc/config/ia64/ia64.c:3279: error:
 incompatible type for argument 1 of 'plus_constant'
 /gcc/spec/sb-terbium-head-64/gcc/gcc/config/ia64/ia64.c:3279: warning:
 passing argument 2 of 'plus_constant' makes pointer from integer
 without a cast
 /gcc/spec/sb-terbium-head-64/gcc/gcc/config/ia64/ia64.c:3279: error:
 too few arguments to function 'plus_constant'
 /gcc/spec/sb-terbium-head-64/gcc/gcc/config/ia64/ia64.c:3330: error:
 incompatible type for argument 1 of 'plus_constant'
 ...
 
 I think this was:
 
 2012-05-10  Eric Botcazou  ebotca...@adacore.com
   Tristan Gingold  ging...@adacore.com
 
   * doc/md.texi (Standard Names): Document probe_stack_address.
   * explow.c (emit_stack_probe): Handle probe_stack_address.
   * config/ia64/ia64.md (UNSPECV_PROBE_STACK_ADDRESS): New constant.
   (UNSPECV_PROBE_STACK_RANGE): Likewise.
   (probe_stack_address): New insn.
   (probe_stack_range): Likewise.
   * config/ia64/ia64.c: Include common/common-target.h.
   (ia64_compute_frame_size): Mark r2 and r3 as used if static stack
   checking is enabled.
   (ia64_emit_probe_stack_range): New function.
   (output_probe_stack_range): Likewise.
   (ia64_expand_prologue): Invoke ia64_emit_probe_stack_range if static
   builtin stack checking is enabled.
   (rtx_needs_barrier) UNSPEC_VOLATILE: Handle UNSPECV_PROBE_STACK_RANGE
   and UNSPECV_PROBE_STACK_ADDRESS.
   (unknown_for_bundling_p): New predicate.
   (group_barrier_needed): Use important_for_bundling_p.
   (ia64_dfa_new_cycle): Use unknown_for_bundling_p.
   (issue_nops_and_insn): Likewise.
   (bundling): Likewise.
   (final_emit_insn_group_barriers): Likewise.
   * config/ia64/ia64-protos.h (output_probe_stack_range): Declare.
   * config/ia64/hpux.h (STACK_CHECK_STATIC_BUILTIN): Define.
   (STACK_CHECK_PROTECT): Likewise.
   * config/ia64/linux.h (STACK_CHECK_STATIC_BUILTIN): Likewise.
 
 which went in a few days after my patch.

The following patch fixes the build (not reg-tested, but looks obvious):

2012-05-14  Tristan Gingold  ging...@adacore.com

* config/ia64/ia64.c (ia64_expand_prologue): Adjust calls to 
plus_constant.

diff --git a/gcc/config/ia64/ia64.c b/gcc/config/ia64/ia64.c
index e10db35..4c6050f 100644
--- a/gcc/config/ia64/ia64.c
+++ b/gcc/config/ia64/ia64.c
@@ -3277,7 +3277,7 @@ ia64_emit_probe_stack_range (HOST_WIDE_INT first, 
HOST_WIDE_INT size, int sol)
 size is at least 4096 - (96 + 2) * 8 = 3312 bytes, which is enough.
 Also compute the address of the last probe for the memory stack
 (which grows towards lower addresses).  */
-  emit_insn (gen_rtx_SET (VOIDmode, r3, plus_constant (r3, 4095)));
+  emit_insn (gen_rtx_SET (VOIDmode, r3, plus_constant (Pmode, r3, 4095)));
   emit_insn (gen_rtx_SET (VOIDmode, r2,
  gen_rtx_PLUS (Pmode, stack_pointer_rtx, r2)));
 
@@ -3329,12 +3329,12 @@ ia64_emit_probe_stack_range (HOST_WIDE_INT first, 
HOST_WIDE_INT size, int sol)
   for (i = 2 * PROBE_INTERVAL; i  size; i += PROBE_INTERVAL)
{
  emit_insn (gen_rtx_SET (VOIDmode, r2,
- plus_constant (r2, -PROBE_INTERVAL)));
+ plus_constant (Pmode, r2, -PROBE_INTERVAL)));
  emit_stack_probe (r2);
}
 
   emit_insn (gen_rtx_SET (VOIDmode, r2,
- plus_constant (r2,
+ plus_constant (Pmode, r2,
 (i - PROBE_INTERVAL) - size)));
   emit_stack_probe (r2);
 }
@@ -3395,7 +3395,8 @@ ia64_emit_probe_stack_range (HOST_WIDE_INT first, 
HOST_WIDE_INT size, int sol)
   if (size != rounded_size)
{
  emit_insn (gen_rtx_SET (VOIDmode, r2,
- plus_constant (r2, rounded_size - size)));
+ plus_constant (Pmode,
+r2, rounded_size - size)));
  emit_stack_probe (r2);
}
 }

Re: Missing guard in ira-color.c ?

[Tristan Gingold]

On May 10, 2012, at 10:41 PM, Vladimir Makarov wrote:

 On 05/10/2012 09:10 AM, Tristan Gingold wrote:
 Hi,
 
 I am getting a segfault in ira-color.c:2945 on the trunk:
 
 Program received signal SIGSEGV, Segmentation fault.
 0x00a79f37 in move_spill_restore () at ../../src/gcc/ira-color.c:2945
 2945   || ira_reg_equiv_const[regno] != NULL_RTX
 (gdb) l
 2940   /* don't do the optimization because it can create
 2941  copies and the reload pass can spill the allocno set
 2942  by copy although the allocno will not get memory
 2943  slot.  */
 2944   || ira_reg_equiv_invariant_p[regno]
 2945   || ira_reg_equiv_const[regno] != NULL_RTX
 2946   || !bitmap_bit_p (loop_node-border_allocnos, ALLOCNO_NUM 
 (a)))
 2947 continue;
 2948   mode = ALLOCNO_MODE (a);
 2949   rclass = ALLOCNO_CLASS (a);
 
 while building gcc (gnatcmd.adb file) for ia64-vms using a cross compiler 
 (target=ia64-vms, host=x86_64-linux).
 
 The reason looks to be an out of bounds access:
 
 (gdb) print regno
 $10 = 18476
 (gdb) print ira_reg_equiv_len
 $11 = 17984
 
 (I suppose this setup is not easy at all to reproduce, but I can provide any 
 files, if necessary).
 Tristan, thanks for reporting this.
 Wild guess, as I don't know IRA at all:  looks like in this file most 
 accesses to ira_reg_equiv_* are guarded.  Is it expected that they aren't at 
 this point ?
 Yes, I guess.  It is possible to have the pseudos which are out of range 
 ira_reg_equiv_const.  It should be hard to reproduce such error because they 
 are generated when we need to break circular dependence (e.g. when hard 
 register 1 should be moved to hard register 2 and hard register 2 to hard 
 register 1).
 
 Your solution is perfectly fine.  So you can commit the patch into the trunk 
 as pre-approved.

Thank you for your prompt answer.  I will commit it after regtesting.

Tristan.

Re: [PATCH libcpp]: Avoid crash in interpret_float_suffix

[Tristan Gingold]

On May 8, 2012, at 5:39 PM, Tom Tromey wrote:

 Tristan == Tristan Gingold ging...@adacore.com writes:
 
 Tristan 2012-05-04  Tristan Gingold  ging...@adacore.com
 Tristan  * expr.c (interpret_float_suffix): Add a guard.
 
 Ok.

Thanks, now committed.

Missing guard in ira-color.c ?

[Tristan Gingold]

Hi,

I am getting a segfault in ira-color.c:2945 on the trunk:

Program received signal SIGSEGV, Segmentation fault.
0x00a79f37 in move_spill_restore () at ../../src/gcc/ira-color.c:2945
2945  || ira_reg_equiv_const[regno] != NULL_RTX
(gdb) l
2940  /* don't do the optimization because it can create
2941 copies and the reload pass can spill the allocno set
2942 by copy although the allocno will not get memory
2943 slot.  */
2944  || ira_reg_equiv_invariant_p[regno]
2945  || ira_reg_equiv_const[regno] != NULL_RTX
2946  || !bitmap_bit_p (loop_node-border_allocnos, ALLOCNO_NUM 
(a)))
2947continue;
2948  mode = ALLOCNO_MODE (a);
2949  rclass = ALLOCNO_CLASS (a);

while building gcc (gnatcmd.adb file) for ia64-vms using a cross compiler 
(target=ia64-vms, host=x86_64-linux).

The reason looks to be an out of bounds access:

(gdb) print regno
$10 = 18476
(gdb) print ira_reg_equiv_len 
$11 = 17984

(I suppose this setup is not easy at all to reproduce, but I can provide any 
files, if necessary).

Wild guess, as I don't know IRA at all:  looks like in this file most accesses 
to ira_reg_equiv_* are guarded.  Is it expected that they aren't at this point ?

[I am currently trying with the following chunk:

--- a/gcc/ira-color.c
+++ b/gcc/ira-color.c
@@ -2941,8 +2941,9 @@ move_spill_restore (void)
 copies and the reload pass can spill the allocno set
 by copy although the allocno will not get memory
 slot.  */
- || ira_reg_equiv_invariant_p[regno]
- || ira_reg_equiv_const[regno] != NULL_RTX
+ || (regno  ira_reg_equiv_len
+  (ira_reg_equiv_invariant_p[regno]
+ || ira_reg_equiv_const[regno] != NULL_RTX))
  || !bitmap_bit_p (loop_node-border_allocnos, ALLOCNO_NUM (a)))
continue;
  mode = ALLOCNO_MODE (a);
]

Thanks for any comment,
Tristan.

[PATCH libcpp]: Avoid crash in interpret_float_suffix

[Tristan Gingold]

Hi,

the function libcpp/expr.c:interpret_float_suffix allows its argument LEN to be 
0, but in this case it tries to read before the buffer S.  It is not a real 
issue, except in case of overflow:  on VMS with 64bit pointers but 32bit 
size_t, the following code:
  s[len-1]
is evaluated as
  s[0x]
which is likely (and does) crash cc1.

To avoid this nasty effect, I just added a guard.

Bootstrapped and regtested on i386/GNU linux.

Ok for trunk ?

Tristan.

libcpp/
2012-05-04  Tristan Gingold  ging...@adacore.com

* expr.c (interpret_float_suffix): Add a guard.

diff --git a/libcpp/expr.c b/libcpp/expr.c
index d56e56a..ca1c3d1 100644
--- a/libcpp/expr.c
+++ b/libcpp/expr.c
@@ -110,12 +110,13 @@ interpret_float_suffix (const uchar *s, size_t len)
 }
 
   /* Recognize a fixed-point suffix.  */
-  switch (s[len-1])
-{
-case 'k': case 'K': flags = CPP_N_ACCUM; break;
-case 'r': case 'R': flags = CPP_N_FRACT; break;
-default: break;
-}
+  if (len != 0)
+switch (s[len-1])
+  {
+  case 'k': case 'K': flags = CPP_N_ACCUM; break;
+  case 'r': case 'R': flags = CPP_N_FRACT; break;
+  default: break;
+  }
 
   /* Continue processing a fixed-point suffix.  The suffix is case
  insensitive except for ll or LL.  Order is significant.  */

[PATCH]: handle size_t /= ptr size in tree-ssa-strlen.c

[Tristan Gingold]

Hi,

get_string_length assumes that precision of size_t is the same as precision of 
a pointer, which isn't always true at least on VMS.
This patch simply add a conversion in case of mismatch.

Tested on ia64/VMS by cross-bootstrapping.
Bootstrapped and regtested on i386/GNU Linux.

Ok for trunk ?

Tristan.

2012-05-04  Tristan Gingold  ging...@adacore.com

* tree-ssa-strlen.c (get_string_length): Convert lhs if needed.

diff --git a/gcc/tree-ssa-strlen.c b/gcc/tree-ssa-strlen.c
index a37633a..bda5ffb 100644
--- a/gcc/tree-ssa-strlen.c
+++ b/gcc/tree-ssa-strlen.c
@@ -427,6 +427,12 @@ get_string_length (strinfo si)
NULL);
  add_referenced_var (lhs_var);
  tem = gimple_call_arg (stmt, 0);
+  if (!useless_type_conversion_p (sizetype, TREE_TYPE (lhs)))
+{
+  lhs = convert_to_ptrofftype (lhs);
+  lhs = force_gimple_operand_gsi (gsi, lhs, true, NULL_TREE,
+  true, GSI_SAME_STMT);
+}
  lenstmt
= gimple_build_assign_with_ops (POINTER_PLUS_EXPR,
make_ssa_name (lhs_var, NULL),

Re: [PATCH]: handle size_t /= ptr size in tree-ssa-strlen.c

[Tristan Gingold]

On May 4, 2012, at 2:34 PM, Richard Guenther wrote:

 On Fri, May 4, 2012 at 2:27 PM, Tristan Gingold ging...@adacore.com wrote:
 Hi,
 
 get_string_length assumes that precision of size_t is the same as precision 
 of a pointer, which isn't always true at least on VMS.
 This patch simply add a conversion in case of mismatch.
 
 Tested on ia64/VMS by cross-bootstrapping.
 Bootstrapped and regtested on i386/GNU Linux.
 
 Ok for trunk ?
 
 Hmm, isn't the issue that size_t precision is not the same precision as
 sizetype?

Yes, that's right.

  You probably should use ptrofftype_p (TREE_TYPE (lhs))
 instead of spelling out 'sizetype' here.

Will try.  Thanks for the hint.

Tristan.

 
 Richard.
 
 Tristan.
 
 2012-05-04  Tristan Gingold  ging...@adacore.com
 
* tree-ssa-strlen.c (get_string_length): Convert lhs if needed.
 
 diff --git a/gcc/tree-ssa-strlen.c b/gcc/tree-ssa-strlen.c
 index a37633a..bda5ffb 100644
 --- a/gcc/tree-ssa-strlen.c
 +++ b/gcc/tree-ssa-strlen.c
 @@ -427,6 +427,12 @@ get_string_length (strinfo si)
NULL);
  add_referenced_var (lhs_var);
  tem = gimple_call_arg (stmt, 0);
 +  if (!useless_type_conversion_p (sizetype, TREE_TYPE (lhs)))
 +{
 +  lhs = convert_to_ptrofftype (lhs);
 +  lhs = force_gimple_operand_gsi (gsi, lhs, true, NULL_TREE,
 +  true, GSI_SAME_STMT);
 +}
  lenstmt
= gimple_build_assign_with_ops (POINTER_PLUS_EXPR,
make_ssa_name (lhs_var, NULL),
 

Re: [patch] For alpha-vms, unset flag_jump_tables if flag_pic is nonzero

[Tristan Gingold]

On May 2, 2012, at 11:45 PM, Richard Henderson wrote:

 On 05/02/2012 12:26 PM, Steven Bosscher wrote:
 * config/alpha/vms.h (SUBTARGET_OVERRIDE_OPTIONS): For pic code,
 unset flag_jump_tables.
 * stmt.c (expand_case): Remove special flag_pic case conditional
 on ASM_OUTPUT_ADDR_DIFF_ELT not being defined.
 
 Ok.
 
 I had a brief look at the vms file format.  It looks to me as if the lack
 of A_O_A_D_E is a defect in gas; it ought to be representable in the object
 file as a difference of two psect+offset addresses.

Agreed.  VMS relocations are much more expressive than standard ELF, so a 
difference should be supported.

Tristan.

Re: [patch] For alpha-vms, unset flag_jump_tables if flag_pic is nonzero

[Tristan Gingold]

On May 2, 2012, at 9:12 PM, Steven Bosscher wrote:

 Hello,
 
 alpha-vms is the only target that does not define
 ASM_OUTPUT_ADDR_DIFF_ELT. That makes the code in stmt.c to handle this
 case alpha-vms specific. But there is a better way to handle this:
 Just mimic -fno-jump-tables if flag_pic is nonzero.
 
 Tested by building a cross-compiler for alpha-dec-vms and verifying
 that flag_jump_tables==0 in expand_case.
 OK for trunk?

-fpic is never used on VMS as the 'calling standard' makes it useless: code
is always position independent.  In the jump table cases, at worst relocations
entries will be generated by the linker for them.

Tristan.

 
 Ciao!
 Steven
 
 
* config/alpha/vms.h (SUBTARGET_OVERRIDE_OPTIONS): For pic code,
unset flag_jump_tables.
* stmt.c (expand_case): Remove special flag_pic case conditional
on ASM_OUTPUT_ADDR_DIFF_ELT not being defined.
 
 Index: config/alpha/vms.h
 ===
 --- config/alpha/vms.h  (revision 187046)
 +++ config/alpha/vms.h  (working copy)
 @@ -257,7 +257,15 @@ typedef struct {int num_args; enum avms_
 #undef ASM_FINAL_SPEC
 
 /* The VMS convention is to always provide minimal debug info
 -   for a traceback unless specifically overridden.  */
 +   for a traceback unless specifically overridden.
 +
 +   Because ASM_OUTPUT_ADDR_DIFF_ELT is not defined for alpha-vms,
 +   jump tables cannot be output for PIC code, because you can't put
 +   an absolute address in a readonly section.  Putting the table in
 +   a writable section is a security hole.  Therefore, we unset the
 +   flag_jump_tables flag, forcing switch statements to be expanded
 +   using decision trees.  There are probably other ways to address
 +   this issue, but using a decision tree is clearly safe.  */
 
 #undef SUBTARGET_OVERRIDE_OPTIONS
 #define SUBTARGET_OVERRIDE_OPTIONS  \
 @@ -268,6 +276,8 @@ do {
   write_symbols = VMS_DEBUG;\
   debug_info_level = DINFO_LEVEL_TERSE; \
 }   \
 +  if (flag_pic == 1)\
 +  flag_jump_tables = 0; \
 } while (0)
 
 #undef LINK_SPEC
 Index: stmt.c
 ===
 --- stmt.c  (revision 187046)
 +++ stmt.c  (working copy)
 @@ -2198,9 +2198,6 @@ expand_case (gimple stmt)
   /* RANGE may be signed, and really large ranges will show up
  as negative numbers.  */
   || compare_tree_int (range, 0)  0
 -#ifndef ASM_OUTPUT_ADDR_DIFF_ELT
 -  || flag_pic
 -#endif
   || !flag_jump_tables
   || TREE_CONSTANT (index_expr)
   /* If neither casesi or tablejump is available, we can

Re: [Fixinclude]: Fix typo and default to twoprocess on VMS

[Tristan Gingold]

On Apr 18, 2012, at 8:23 PM, Bruce Korb wrote:

 Hi,
 
 When I approved a patch in 2008, there was a typo.  I didn't
 notice and it was fixed by removing a formatting element.
 Your patch corrects the error.
 
 Please apply your changes to active branches.  Thank you!
 Regards, Bruce

Thanks, committed on the trunk.

Tristan.

Re: [Fixinclude]: Fix typo and default to twoprocess on VMS

[Tristan Gingold]

On Apr 17, 2012, at 4:21 PM, Bruce Korb wrote:

 Hi Tristan,
 
 On Tue, Apr 17, 2012 at 5:57 AM, Tristan Gingold ging...@adacore.com wrote:
 Hi,
 
 one-process methodology cannot be used on VMS[...]
 But, when twoprocess is selected, gcc emits a warning[...]
 Ok for trunk ?
 
 diff --git a/fixincludes/configure.ac b/fixincludes/configure.ac
 index e7de791..f1fb2ff 100644
 --- a/fixincludes/configure.ac
 +++ b/fixincludes/configure.ac
 @@ -53,7 +53,8 @@ fi],
i?86-*-msdosdjgpp* | \
i?86-*-mingw32* | \
x86_64-*-mingw32* | \
 -   *-*-beos* )
 +   *-*-beos* | \
 +*-*-*vms*)
TARGET=twoprocess
;;
 
 This, definitely.
 
 diff --git a/fixincludes/fixincl.c b/fixincludes/fixincl.c
 index 9f399ab..1133534 100644
 --- a/fixincludes/fixincl.c
 +++ b/fixincludes/fixincl.c
 @@ -829,7 +829,7 @@ fix_with_system (tFixDesc* p_fixd,
   /*
*  Now add the fix number and file names that may be needed
*/
 -  sprintf (pz_scan,  %ld '%s' '%s',  (long) (p_fixd - fixDescList),
 +  sprintf (pz_scan,  %ld '%s' '%s' '%s', (long) (p_fixd - 
 fixDescList),
   pz_fix_file, pz_file_source, pz_temp_file);
 }
   else /* NOT an internal fix: */
 
 This, almost certainly.  I'll take a peek at the source and convince myself of
 this decade old mistake tomorrow  send my grateful thanks and approval then.
 (No access to source today.)

Fine, I stay tuned.

Tristan.

[Fixinclude]: Fix typo and default to twoprocess on VMS

[Tristan Gingold]

Hi,

one-process methodology cannot be used on VMS because fork/pipe/dup2 aren't 
fully supported.  To avoid a build failure, it is therefore better to build 
using two-process methodology.

But, when twoprocess is selected, gcc emits a warning due to a missing 
specifier in printf.  The patch fixes that.

Manually tested on x86_64-darwin by configuring with --enable-twoprocess.

I am pretty sure that fixinclude cannot be used as-is on VMS due to the 
filename convention and missing shell, but at least we can build a cross and a 
native canadian on UNIX.

Ok for trunk ?

Tristan.

fixincludes/
2012-04-17  Tristan Gingold  ging...@adacore.com

* fixincl.c (fix_with_system): Add missing specifier.
* configure.ac: Default to twoprocess on vms.
* configure: Regenerate.

diff --git a/fixincludes/configure.ac b/fixincludes/configure.ac
index e7de791..f1fb2ff 100644
--- a/fixincludes/configure.ac
+++ b/fixincludes/configure.ac
@@ -53,7 +53,8 @@ fi],
i?86-*-msdosdjgpp* | \
i?86-*-mingw32* | \
x86_64-*-mingw32* | \
-   *-*-beos* )
+   *-*-beos* | \
+*-*-*vms*)
TARGET=twoprocess
;;
 
diff --git a/fixincludes/fixincl.c b/fixincludes/fixincl.c
index 9f399ab..1133534 100644
--- a/fixincludes/fixincl.c
+++ b/fixincludes/fixincl.c
@@ -829,7 +829,7 @@ fix_with_system (tFixDesc* p_fixd,
   /*
*  Now add the fix number and file names that may be needed
*/
-  sprintf (pz_scan,  %ld '%s' '%s',  (long) (p_fixd - fixDescList),
+  sprintf (pz_scan,  %ld '%s' '%s' '%s', (long) (p_fixd - fixDescList),
   pz_fix_file, pz_file_source, pz_temp_file);
 }
   else /* NOT an internal fix: */

[Doc] Move paragraph about multiple attributes

[Tristan Gingold]

Hi,

this paragraph is inside the 'i386 type attributes' section, while it isn't 
target specific.

This patch moves it at the end of the attribute list.  Maybe we should remove 
it completely
as there is an 'attribute syntax' section.

Ok for trunk ?

Tristan.

2012-04-11  Tristan Gingold  ging...@adacore.com

* doc/extend.texi (Type Attributes): Move paragraph.

index bb43825..c33ec66 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -5372,6 +5372,10 @@ typeinfo node and exception handling will break.
 
 @end table
 
+To specify multiple attributes, separate them by commas within the
+double parentheses: for example, @samp{__attribute__ ((aligned (16),
+packed))}.
+
 @subsection ARM Type Attributes
 
 On those ARM targets that support @code{dllimport} (such as Symbian
@@ -5427,10 +5431,6 @@ Currently @option{-m[no-]ms-bitfields} is provided for 
the Microsoft Windows X86
 compilers to match the native Microsoft compiler.
 @end table
 
-To specify multiple attributes, separate them by commas within the
-double parentheses: for example, @samp{__attribute__ ((aligned (16),
-packed))}.
-
 @anchor{PowerPC Type Attributes}
 @subsection PowerPC Type Attributes
 

Re: [Doc] Move paragraph about multiple attributes

[Tristan Gingold]

On Apr 11, 2012, at 12:03 PM, Richard Guenther wrote:

 On Wed, Apr 11, 2012 at 11:33 AM, Tristan Gingold ging...@adacore.com wrote:
 Hi,
 
 this paragraph is inside the 'i386 type attributes' section, while it isn't 
 target specific.
 
 This patch moves it at the end of the attribute list.  Maybe we should 
 remove it completely
 as there is an 'attribute syntax' section.
 
 I think it's good to have it repeated here.
 
 Ok for trunk ?
 
 Ok.

Thanks, committed.

Tristan.

 
 Thanks,
 Richard.
 
 Tristan.
 
 2012-04-11  Tristan Gingold  ging...@adacore.com
 
* doc/extend.texi (Type Attributes): Move paragraph.
 
 index bb43825..c33ec66 100644
 --- a/gcc/doc/extend.texi
 +++ b/gcc/doc/extend.texi
 @@ -5372,6 +5372,10 @@ typeinfo node and exception handling will break.
 
  @end table
 
 +To specify multiple attributes, separate them by commas within the
 +double parentheses: for example, @samp{__attribute__ ((aligned (16),
 +packed))}.
 +
  @subsection ARM Type Attributes
 
  On those ARM targets that support @code{dllimport} (such as Symbian
 @@ -5427,10 +5431,6 @@ Currently @option{-m[no-]ms-bitfields} is provided 
 for the Microsoft Windows X86
  compilers to match the native Microsoft compiler.
  @end table
 
 -To specify multiple attributes, separate them by commas within the
 -double parentheses: for example, @samp{__attribute__ ((aligned (16),
 -packed))}.
 -
  @anchor{PowerPC Type Attributes}
  @subsection PowerPC Type Attributes
 
 

Re: intptr fixes for the testsuite

[Tristan Gingold]

On Apr 11, 2012, at 3:55 PM, Bernd Schmidt wrote:

 I'm working on a target where intptr_t and pointers are larger than
 size_t and ptrdiff_t. The testsuite has problems in this area, since we
 often use the latter two types for casting from/to pointers, leading to
 unwanted warnings. In some cases I've checked the corresponding PRs and
 found that the original testcases used something like plain int or long.

Would this target be able to host gcc ?

Tristan.

Re: intptr fixes for the testsuite

[Tristan Gingold]

On Apr 11, 2012, at 4:52 PM, Mike Stump wrote:

 On Apr 11, 2012, at 7:04 AM, Bernd Schmidt wrote:
 On 04/11/2012 04:02 PM, Tristan Gingold wrote:
 
 On Apr 11, 2012, at 3:55 PM, Bernd Schmidt wrote:
 I'm working on a target where intptr_t and pointers are larger than
 size_t and ptrdiff_t. The testsuite has problems in this area, since we
 often use the latter two types for casting from/to pointers, leading to
 unwanted warnings. In some cases I've checked the corresponding PRs and
 found that the original testcases used something like plain int or long.
 
 Would this target be able to host gcc ?
 
 I do not wish to think about this :) It's embedded, so hopefully no one
 will try.
 
 In principle, I'd think any target with enough memory can be made to
 host gcc, with varying amounts of work.
 
 I've hosted gcc on mine, mainly as a code generation correctness check...  
 It's nice having a simulator and enough address bits, you can just plop down 
 yet more memory and presto, everything just works.  The more annoying aspect 
 is having to wire up stat and readdir for sim.  Fork and exec, are more 
 trivial by comparison.  Some gcc ports might not have enough address bits, 
 that might be the only hard requirement that one cannot fudge.

VMS is an host/target where pointers (64 bits) can be larger than size_t and 
ptrdiff_t.
We can run gcc on it, but we also still have a very few patches to submit to 
achieve that!

Tristan.

Re: [Libiberty - V2]: Handle VMS as a LLP64 platform in splay-tree.h

[Tristan Gingold]

On Apr 6, 2012, at 12:26 AM, Ian Lance Taylor wrote:

 Tristan Gingold ging...@adacore.com writes:
 
 gcc/
 2012-04-05  Tristan Gingold  ging...@adacore.com
 
  * gengtype.c (main): Make uintptr_t a known type.
 
 include/
 2012-04-05  Tristan Gingold  ging...@adacore.com
 
  * splay-tree.h: Conditionnaly includes stdint.h and inttypes.h
  (libi_uhostptr_t, libi_shostptr_t): Remove, replaced by uintptr_t.
 
 This is OK.

Thanks, committed.

Tristan.

[Libiberty - V2]: Handle VMS as a LLP64 platform in splay-tree.h

[Tristan Gingold]

On Apr 4, 2012, at 5:07 PM, Ian Lance Taylor wrote:

 Tristan Gingold ging...@adacore.com writes:
 
 Would something like that be acceptable ?
 I have just checked that I can still build gcc with that patch.  If you like 
 this approach I will properly submit a patch.
 
 Thanks.
 
 You should also test that gdb continues to build with this patch.
 
 I guess the question here is portability.  Do we still care about
 portability to systems that have neither inttypes.h nor stdint.h?  I'm
 willing to try this and see if anybody complains.
 
 Ian

Hi,

here is my formal patch submission.  I am not concerned by portability as
configure will define uintptr_t if not found in inttypes.h or stdint.h
(both in libiberty and gcc.  gdb indeed uses stdint.h from gnulib).

Tested by bootstrapping gcc for c,c++ and fortran on x86_64-darwin,
and by building gdb on x86_64-darwin.

Ok for trunk ?

Tristan.

gcc/
2012-04-05  Tristan Gingold  ging...@adacore.com

* gengtype.c (main): Make uintptr_t a known type.

include/
2012-04-05  Tristan Gingold  ging...@adacore.com

* splay-tree.h: Conditionnaly includes stdint.h and inttypes.h
(libi_uhostptr_t, libi_shostptr_t): Remove, replaced by uintptr_t.

diff --git a/gcc/gengtype.c b/gcc/gengtype.c
index 7450eeb..fa45392 100644
--- a/gcc/gengtype.c
+++ b/gcc/gengtype.c
@@ -4976,6 +4976,7 @@ main (int argc, char **argv)
   POS_HERE (do_scalar_typedef (double_int, pos));
   POS_HERE (do_scalar_typedef (uint64_t, pos));
   POS_HERE (do_scalar_typedef (uint8, pos));
+  POS_HERE (do_scalar_typedef (uintptr_t, pos));
   POS_HERE (do_scalar_typedef (jword, pos));
   POS_HERE (do_scalar_typedef (JCF_u2, pos));
   POS_HERE (do_scalar_typedef (void, pos));


diff --git a/include/splay-tree.h b/include/splay-tree.h
index 480b2c4..a26135a 100644
--- a/include/splay-tree.h
+++ b/include/splay-tree.h
@@ -37,18 +37,11 @@ extern C {
 
 #include ansidecl.h
 
-#ifndef _WIN64
-  typedef unsigned long int libi_uhostptr_t;
-  typedef long int libi_shostptr_t;
-#else
-#ifdef __GNUC__
-  __extension__
+#ifdef HAVE_STDINT_H
+#include stdint.h
 #endif
-  typedef unsigned long long libi_uhostptr_t;
-#ifdef __GNUC__
-  __extension__
-#endif
-  typedef long long libi_shostptr_t;
+#ifdef HAVE_INTTYPES_H
+#include inttypes.h
 #endif
 
 #ifndef GTY
@@ -59,8 +52,8 @@ extern C {
these types, if necessary.  These types should be sufficiently wide
that any pointer or scalar can be cast to these types, and then
cast back, without loss of precision.  */
-typedef libi_uhostptr_t splay_tree_key;
-typedef libi_uhostptr_t splay_tree_value;
+typedef uintptr_t splay_tree_key;
+typedef uintptr_t splay_tree_value;
 
 /* Forward declaration for a node in the tree.  */
 typedef struct splay_tree_node_s *splay_tree_node;

Ping [IA-64] Implement static stack checking

[Tristan Gingold]

Hi,

I'd like to ping this patch, as it hasn't been reviewed for 4 weeks.

Tristan.

On Mar 6, 2012, at 11:08 PM, Eric Botcazou wrote:

 This at last implements static stack checking for the IA-64, i.e. stack 
 checking of the static part of the frame, and makes it possible to pass the 
 entire ACATS testsuite.  The peculiarity is the second stack in memory, 
 namely 
 the Backing Store of the Register Stack Engine, that needs to be dealt with.
 
 This also introduces full support for unknown insns in the bundling code 
 (the 
 only other unknown insn, namely set_bsp, didn't need that because it comes 
 always last in a function).
 
 Bootstrapped/regtested on IA-64/Linux (and also tested on IA-64/HP-UX and 
 VMS), 
 OK for the mainline?
 
 
 2012-03-06  Eric Botcazou  ebotca...@adacore.com
Tristan Gingold  ging...@adacore.com
 
   * doc/md.texi (Standard Names): Document probe_stack_address.
   * explow.c (emit_stack_probe): Handle probe_stack_address.
   * config/ia64/ia64.md (UNSPECV_PROBE_STACK_ADDRESS): New constant.
   (UNSPECV_PROBE_STACK_RANGE): Likewise.
   (probe_stack_address): New insn.
   (probe_stack_range): Likewise.
   * config/ia64/ia64.c: Include common/common-target.h.
   (ia64_compute_frame_size): Mark r2 and r3 as used if static stack
   checking is enabled.
   (ia64_emit_probe_stack_range): New function.
   (output_probe_stack_range): Likewise.
   (ia64_expand_prologue): Invoke ia64_emit_probe_stack_range if static
   builtin stack checking is enabled.
   (rtx_needs_barrier) UNSPEC_VOLATILE: Handle UNSPECV_PROBE_STACK_RANGE
   and UNSPECV_PROBE_STACK_ADDRESS.
   (unknown_for_bundling_p): New predicate.
   (group_barrier_needed): Use important_for_bundling_p.
   (ia64_dfa_new_cycle): Use unknown_for_bundling_p.
   (issue_nops_and_insn): Likewise.
   (bundling): Likewise.
   (final_emit_insn_group_barriers): Likewise.
   * config/ia64/ia64-protos.h (output_probe_stack_range): Declare.
   * config/ia64/hpux.h (STACK_CHECK_STATIC_BUILTIN): Define.
   (STACK_CHECK_PROTECT): Likewise.
   * config/ia64/linux.h (STACK_CHECK_STATIC_BUILTIN): Likewise.
 
 
 -- 
 Eric Botcazou
 p2.diff

Ping [IA-64] Work around thinko in 'x' constraint implementation

[Tristan Gingold]

I'd like to ping this patch as it fixed an ICE visible on both ia64 linux and 
ia64 openvms.

Tristan.

On Mar 6, 2012, at 11:07 PM, Eric Botcazou wrote:

 We have a regression on one of the testcases of our internal testsuite on 
 IA-64 
 with a 4.7-based compiler, which is of the form:
 
 test_vec_madd.adb: In function 'Test_Vec_Madd':
 test_vec_madd.adb:160:5: error: could not split insn
 (insn 887 4859 889 16 (set (reg:TI 158 f30 [orig:417 m ] [417])
(mem/c:TI (reg/f:DI 14 r14 [1025]) [0 S16 A128])) /gnu/lib/gcc/ia64-hp-
 openvms/4_7_0/adainclude/g-altcon.adb:277 125 {movti_internal}
 (nil))
 +===GNAT BUG DETECTED==+
 | Pro 7.1.0w (20120221-head) (ia64-hp-openvms) GCC error:  |
 | in final_scan_insn, at final.c:2716  |
 | Error detected around test_vec_madd.adb:160:5|
 
 The compiler aborts during the final pass because it couldn't split the insn.
 The pattern for movti_internal is:
 
 (define_insn_and_split movti_internal
  [(set (match_operand:TI 0 destination_operand =r,   *fm,*x,*f,  Q)
   (match_operand:TI 1 general_operand r*fim,r,  Q, *fOQ,*f))]
  ia64_move_ok (operands[0], operands[1])
  @
   #
   #
   ldfp8 %X0 = %1%P1
   #
   #
  reload_completed  !ia64_load_pair_ok(operands[0], operands[1])
  [(const_int 0)]
 
 The problem is that the operands satisfy ia64_load_pair_ok so the splitter
 cannot be invoked on them.  The root cause is a discrepancy between this
 predicate and how the 'x' constraint is interpreted.  The predicate uses
 FP_REGNO_P to check the destination and this returns true for %f30 (but would
 return false for the immediately following register %f31).  But recog 
 interprets the 'x' constraint as meaning that every hard register in the 
 destination must be in the FP_REGS class; now the mode is TImode so both %f30 
 and %f31 are taken into account and %f31 isn't in the FP_REGS class, so the 
 operand is rejected.
 
 AFAICS the problem dates back to the introduction of the code (r102463), so 
 I'm 
 not sure that we want to rewrite it at this point.  That's why the attached 
 patch is a simple workaround that just avoid ICEing.
 
 Bootstrapped/regtested on IA-64/Linux, OK for the mainline?  Do we also want 
 it 
 for 4.7.1 (I assume that some RA change makes the issue visible in 4.7.x)?
 
 
 2012-03-06  Eric Botcazou  ebotca...@adacore.com
 
   * config/ia64/ia64.c (ia64_load_pair_ok): Return 0 if the second member
   of the destination isn't also a FP_REGS register.
 
 
 -- 
 Eric Botcazou
 p1.diff

Re: [Patch, Fortran]: Fix libgfortran.h error for VMS

[Tristan Gingold]

On Apr 3, 2012, at 5:53 PM, Tobias Burnus wrote:

 
 On 04/03/2012 02:42 PM, Tristan Gingold wrote:
 The simplest path is simply to reverse the include order in libgfortran.h.  
 I know that this is somewhat VMS specific, and I welcome better ideas.
 
 Well, changing the order is not that bad than one has to try hard to  find a 
 better solution. (Unless, it fails on other systems with the new order.)

I cross my fingers!

 Tested by building gfortran for x86_64-darwin and ia64-hp-openvms.
 
 OK. Thanks for the patch.

You're welcome.  This was my latest patch to make gfortran build for VMS.  
AFAIK, this is now the only post F95 fortran compiler available for VMS, 
although I suppose it lacks some DEC extensions specific to VMS.

Tristan.

[Patch]: Fix ICE on VMS when using SImode pointers

[Tristan Gingold]

Hi,

this patch fixes a build time failure on VMS (while compiling Ada RTS file 
i-cstrin.adb) due to the use of short pointers:

i-cstrin.adb: In function 'Interfaces.C.Strings.To_Chars_Ptr':
i-cstrin.adb:236:8: error: unrecognizable insn:
(insn 80 79 81 13 (set (reg:SI 384)
(const_int 4294967288 [0xfff8])) i-cstrin.adb:234 -1
 (nil))
+===GNAT BUG DETECTED==+
| Pro 7.1.0w (20120403-47) (ia64-hp-openvms) GCC error:|
| in extract_insn, at recog.c:2123 |
| Error detected around i-cstrin.adb:236:8 |


Expansion of POINTER_PLUS_EXPR doesn't handle the case of PRECISION(sizetype)  
PRECISION(type), leading to RTL expressions with different modes.

This patch fixes the build issue, tested on ia64-hp-openvms.
Also tested with our internal testsuite.
I haven't run the GCC testsuite on a regular platform, as the condition will 
never trigger.

Ok for trunk ?

Tristan.

2012-04-04  Tristan Gingold  ging...@adacore.com

* expr.c (expand_expr_real_2): Handle larger sizetype in
POINTER_PLUS_EXPR.

--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -7957,6 +7957,9 @@ expand_expr_real_2 (sepops ops, rtx target, enum machine_m
treeop1 = fold_convert_loc (loc, type,
fold_convert_loc (loc, ssizetype,
  treeop1));
+  else if (TYPE_PRECISION (sizetype)  TYPE_PRECISION (type))
+   treeop1 = fold_convert_loc (loc, type, treeop1);
+
 case PLUS_EXPR:
   /* If we are adding a constant, a VAR_DECL that is sp, fp, or ap, and
 something else, make sure we add the register to the constant and
u

Re: [Patch]: Fix ICE on VMS when using SImode pointers

[Tristan Gingold]

On Apr 4, 2012, at 10:18 AM, Richard Guenther wrote:

 On Wed, 4 Apr 2012, Tristan Gingold wrote:
 
 Hi,
 
 this patch fixes a build time failure on VMS (while compiling Ada RTS file 
 i-cstrin.adb) due to the use of short pointers:
 
 i-cstrin.adb: In function 'Interfaces.C.Strings.To_Chars_Ptr':
 i-cstrin.adb:236:8: error: unrecognizable insn:
 (insn 80 79 81 13 (set (reg:SI 384)
(const_int 4294967288 [0xfff8])) i-cstrin.adb:234 -1
 (nil))
 +===GNAT BUG DETECTED==+
 | Pro 7.1.0w (20120403-47) (ia64-hp-openvms) GCC error:|
 | in extract_insn, at recog.c:2123 |
 | Error detected around i-cstrin.adb:236:8 |
 
 
 Expansion of POINTER_PLUS_EXPR doesn't handle the case of 
 PRECISION(sizetype)  PRECISION(type), leading to RTL expressions with 
 different modes.
 
 This patch fixes the build issue, tested on ia64-hp-openvms.
 Also tested with our internal testsuite.
 I haven't run the GCC testsuite on a regular platform, as the condition will 
 never trigger.
 
 Ok for trunk ?
 
 Ok if you add a comment why this is needed.

Thanks, committed with this comment:

  /* If sizetype precision is larger than pointer precision, truncate the
 offset to have matching modes.  */
  else if (TYPE_PRECISION (sizetype)  TYPE_PRECISION (type))
treeop1 = fold_convert_loc (loc, type, treeop1);


Tristan.

[libiberty]: Adjust style in pex-unix.c(to_ptr32)

[Tristan Gingold]

Hi,

I am committing this patch (as obvious) to adjust the style of the VMS specific 
function to_ptr32.

Tested by building for ia64-hp-openvms.

Tristan.

libiberty/
2012-04-04  Tristan Gingold  ging...@adacore.com

* pex-unix.c (to_ptr32): Fix style.

Index: pex-unix.c
===
--- pex-unix.c  (revision 186130)
+++ pex-unix.c  (working copy)
@@ -85,13 +85,15 @@
   int argc;
   __char_ptr_char_ptr32 short_argv;
 
-  for (argc=0; ptr64[argc]; argc++);
+  /* Count number of arguments.  */
+  for (argc = 0; ptr64[argc] != NULL; argc++)
+;
 
   /* Reallocate argv with 32 bit pointers.  */
   short_argv = (__char_ptr_char_ptr32) decc$malloc
 (sizeof (__char_ptr32) * (argc + 1));
 
-  for (argc=0; ptr64[argc]; argc++)
+  for (argc = 0; ptr64[argc] != NULL; argc++)
 short_argv[argc] = (__char_ptr32) decc$strdup (ptr64[argc]);
 
   short_argv[argc] = (__char_ptr32) 0;

[Libiberty]: Handle VMS as a LLP64 platform in splay-tree.h

[Tristan Gingold]

Hi,

unfortunately VMS (when 64bit pointers are used - which is nice for gcc) is 
also an LLP64 platform.
So I need to follow to Win64 way in splay-tree.h.

Tested manually by build (and using) gcc on ia64-hp-openvms.

Ok for trunk ?

Tristan.

include/
2012-04-04  Tristan Gingold  ging...@adacore.com

* splay-tree.h: Use LLP64 definitions of libi_shostptr_t and
libi_hostptr_t for VMS with 64bit pointers.

--- a/include/splay-tree.h
+++ b/include/splay-tree.h
@@ -37,7 +37,8 @@ extern C {
 
 #include ansidecl.h
 
-#ifndef _WIN64
+#if !(defined (_WIN64) \
+  || (defined (__VMS__)  __INITIAL_POINTER_SIZE == 64))
   typedef unsigned long int libi_uhostptr_t;
   typedef long int libi_shostptr_t;
 #else

Re: [Libiberty]: Handle VMS as a LLP64 platform in splay-tree.h

[Tristan Gingold]

On Apr 4, 2012, at 11:26 AM, Pedro Alves wrote:

 On 04/04/2012 09:55 AM, Tristan Gingold wrote:
 
 Hi,
 
 unfortunately VMS (when 64bit pointers are used - which is nice for gcc) is 
 also an LLP64 platform.
 So I need to follow to Win64 way in splay-tree.h.
 
 
 Doesn't VMS gcc define __LP64__/__LLP64__?

Unfortunately no (like mingw if I read config files correctly).

This makes even less sense on VMS where 32bit and 64bit can be used at the same 
time.

  Then we could for example:
 
 #if !(defined (_WIN64) || defined (__LLP64__))
 
 and thus avoid sprinkling __VMS__ checks around.

In fact this is the only place where we need it, so this is under control :-)

Tristan.

 
 
 Tested manually by build (and using) gcc on ia64-hp-openvms.
 
 Ok for trunk ?
 
 Tristan.
 
 include/
 2012-04-04  Tristan Gingold  ging...@adacore.com
 
  * splay-tree.h: Use LLP64 definitions of libi_shostptr_t and
  libi_hostptr_t for VMS with 64bit pointers.
 
 --- a/include/splay-tree.h
 +++ b/include/splay-tree.h
 @@ -37,7 +37,8 @@ extern C {
 
 #include ansidecl.h
 
 -#ifndef _WIN64
 +#if !(defined (_WIN64) \
 +  || (defined (__VMS__)  __INITIAL_POINTER_SIZE == 64))
   typedef unsigned long int libi_uhostptr_t;
   typedef long int libi_shostptr_t;
 #else
 
 
 
 
 -- 
 Pedro Alves

Re: [Libiberty]: Handle VMS as a LLP64 platform in splay-tree.h

[Tristan Gingold]

On Apr 4, 2012, at 3:58 PM, Ian Lance Taylor wrote:

 Tristan Gingold ging...@adacore.com writes:
 
 include/
 2012-04-04  Tristan Gingold  ging...@adacore.com
 
  * splay-tree.h: Use LLP64 definitions of libi_shostptr_t and
  libi_hostptr_t for VMS with 64bit pointers.
 
 I was strongly opposed to adding a _WIN64 define here and this is just
 making it worse.

Understood.

Would something like that be acceptable ?
I have just checked that I can still build gcc with that patch.  If you like 
this approach I will properly submit a patch.

Tristan.

--- a/include/splay-tree.h
+++ b/include/splay-tree.h
@@ -37,18 +37,11 @@ extern C {
 
 #include ansidecl.h
 
-#ifndef _WIN64
-  typedef unsigned long int libi_uhostptr_t;
-  typedef long int libi_shostptr_t;
-#else
-#ifdef __GNUC__
-  __extension__
+#ifdef HAVE_STDINT_H
+#include stdint.h
 #endif
-  typedef unsigned long long libi_uhostptr_t;
-#ifdef __GNUC__
-  __extension__
-#endif
-  typedef long long libi_shostptr_t;
+#ifdef HAVE_INTTYPES_H
+#include inttypes.h
 #endif
 
 #ifndef GTY
@@ -59,8 +52,8 @@ extern C {
these types, if necessary.  These types should be sufficiently wide
that any pointer or scalar can be cast to these types, and then
cast back, without loss of precision.  */
-typedef libi_uhostptr_t splay_tree_key;
-typedef libi_uhostptr_t splay_tree_value;
+typedef uintptr_t splay_tree_key;
+typedef uintptr_t splay_tree_value;
 
 /* Forward declaration for a node in the tree.  */
 typedef struct splay_tree_node_s *splay_tree_node;


index 7450eeb..fa45392 100644
--- a/gcc/gengtype.c
+++ b/gcc/gengtype.c
@@ -4976,6 +4976,7 @@ main (int argc, char **argv)
   POS_HERE (do_scalar_typedef (double_int, pos));
   POS_HERE (do_scalar_typedef (uint64_t, pos));
   POS_HERE (do_scalar_typedef (uint8, pos));
+  POS_HERE (do_scalar_typedef (uintptr_t, pos));
   POS_HERE (do_scalar_typedef (jword, pos));
   POS_HERE (do_scalar_typedef (JCF_u2, pos));
   POS_HERE (do_scalar_typedef (void, pos));

Re: [Libiberty]: Handle VMS as a LLP64 platform in splay-tree.h

[Tristan Gingold]

On Apr 4, 2012, at 5:07 PM, Ian Lance Taylor wrote:

 Tristan Gingold ging...@adacore.com writes:
 
 Would something like that be acceptable ?
 I have just checked that I can still build gcc with that patch.  If you like 
 this approach I will properly submit a patch.
 
 Thanks.
 
 You should also test that gdb continues to build with this patch.

Argh, good point.

 I guess the question here is portability.  Do we still care about
 portability to systems that have neither inttypes.h nor stdint.h?  I'm
 willing to try this and see if anybody complains.

In this case, autoconf defines uintptr_t so I don't think there is an issue 
here.

Tristan.

 
 Ian
 
 
 --- a/include/splay-tree.h
 +++ b/include/splay-tree.h
 @@ -37,18 +37,11 @@ extern C {
 
 #include ansidecl.h
 
 -#ifndef _WIN64
 -  typedef unsigned long int libi_uhostptr_t;
 -  typedef long int libi_shostptr_t;
 -#else
 -#ifdef __GNUC__
 -  __extension__
 +#ifdef HAVE_STDINT_H
 +#include stdint.h
 #endif
 -  typedef unsigned long long libi_uhostptr_t;
 -#ifdef __GNUC__
 -  __extension__
 -#endif
 -  typedef long long libi_shostptr_t;
 +#ifdef HAVE_INTTYPES_H
 +#include inttypes.h
 #endif
 
 #ifndef GTY
 @@ -59,8 +52,8 @@ extern C {
these types, if necessary.  These types should be sufficiently wide
that any pointer or scalar can be cast to these types, and then
cast back, without loss of precision.  */
 -typedef libi_uhostptr_t splay_tree_key;
 -typedef libi_uhostptr_t splay_tree_value;
 +typedef uintptr_t splay_tree_key;
 +typedef uintptr_t splay_tree_value;
 
 /* Forward declaration for a node in the tree.  */
 typedef struct splay_tree_node_s *splay_tree_node;
 
 
 index 7450eeb..fa45392 100644
 --- a/gcc/gengtype.c
 +++ b/gcc/gengtype.c
 @@ -4976,6 +4976,7 @@ main (int argc, char **argv)
   POS_HERE (do_scalar_typedef (double_int, pos));
   POS_HERE (do_scalar_typedef (uint64_t, pos));
   POS_HERE (do_scalar_typedef (uint8, pos));
 +  POS_HERE (do_scalar_typedef (uintptr_t, pos));
   POS_HERE (do_scalar_typedef (jword, pos));
   POS_HERE (do_scalar_typedef (JCF_u2, pos));
   POS_HERE (do_scalar_typedef (void, pos));

[vms/committed]: Handle #pragma __nomember_alignment byte

[Tristan Gingold]

Hi,

this patch handles the 'byte' alignment that appears in standard VMS headers 
when a C++ compiler is used.
It also force the support of parameterless variadic functions to be compatible 
with standard VMS headers.

Committed on trunk after ia64-hp-openvms cross build.

Tristan.

2012-04-03  Tristan Gingold  ging...@adacore.com

* config/vms/vms-c.c (vms_pragma_nomember_alignment): Handle
'byte' alignment.
(vms_c_common_override_options): Allow parameterless variadic
functions.

Index: gcc/config/vms/vms-c.c
===
--- gcc/config/vms/vms-c.c  (revision 186100)
+++ gcc/config/vms/vms-c.c  (working copy)
@@ -120,7 +120,9 @@
   if (arg[0] == '_'  arg[1] == '_')
 arg += 2;
 
-  if (strcmp (arg, word) == 0)
+  if (strcmp (arg, byte) == 0)
+maximum_field_alignment = 1 * BITS_PER_UNIT;
+  else if (strcmp (arg, word) == 0)
 maximum_field_alignment = 2 * BITS_PER_UNIT;
   else if (strcmp (arg, longword) == 0)
 maximum_field_alignment = 4 * BITS_PER_UNIT;
@@ -453,6 +455,9 @@
 void
 vms_c_common_override_options (void)
 {
+  /* Allow variadic functions without parameters (as declared in starlet).  */
+  flag_allow_parameterless_variadic_functions = TRUE;
+
   /* Initialize c_default_pointer_mode.  */
   switch (flag_vms_pointer_size)
 {

[Patch]: use mmap.m4 in gcc/configure

[Tristan Gingold]

Hi,

the gcc_AC_FUNC_MMAP_BLACKLIST function in gcc/acinclude.m4 is exactly the same 
as the GCC_AC_FUNC_MMAP_BLACKLIST function in config/mmap.m4 (except the case 
of the first three letters).  This patch makes gcc/configure.ac uses 
config/mmap.m4 instead of its own version.

Also, I modified config/mmap.m4 to match *vms* instead of vms* like all other 
configuration scripts (because the official name is now openvms).

Tested by building for ia64-hp-openvms and by visual inspection of the 
generated configure (only the *vms* lines changed).

Ok for trunk ?

Tristan.

config/
2012-04-03  Tristan Gingold  ging...@adacore.com

* mmap.m4: Use *vms* instead of vms*.

gcc/
2012-04-03  Tristan Gingold  ging...@adacore.com

* configure.ac: Use GCC_AC_FUNC_MMAP_BLACKLIST instead
of gcc_AC_FUNC_MMAP_BLACKLIST.
* aclocal.m4: Include mmap.m4
* acinclude.m4 (gcc_AC_FUNC_MMAP_BLACKLIST): Remove.
* Makefile.in (aclocal_deps): Add mmap.m4.
* configure: Regenerate.

libitm/
2012-04-03  Tristan Gingold  ging...@adacore.com

* configure: Regenerate.

diff --git a/config/mmap.m4 b/config/mmap.m4
index 39d79af..fba0d9d 100644
--- a/config/mmap.m4
+++ b/config/mmap.m4
@@ -24,7 +24,7 @@ else
# read() to the same fd.  The only system known to have a problem here
# is VMS, where text files have record structure.
case $host_os in
- vms* | ultrix*) 
+ *vms* | ultrix*)
 gcc_cv_func_mmap_file=no ;;
  *)
 gcc_cv_func_mmap_file=yes;;
@@ -42,7 +42,7 @@ else
# Systems known to be in this category are Windows (all variants),
# VMS, and Darwin.
case $host_os in
- vms* | cygwin* | pe | mingw* | darwin* | ultrix* | hpux10* | hpux11.00)
+ *vms* | cygwin* | pe | mingw* | darwin* | ultrix* | hpux10* | hpux11.00)
 gcc_cv_func_mmap_dev_zero=no ;;
  *)
 gcc_cv_func_mmap_dev_zero=yes;;
@@ -74,7 +74,7 @@ else
# above for use of /dev/zero.
# Systems known to be in this category are Windows, VMS, and SCO Unix.
case $host_os in
- vms* | cygwin* | pe | mingw* | sco* | udk* )
+ *vms* | cygwin* | pe | mingw* | sco* | udk* )
 gcc_cv_func_mmap_anon=no ;;
  *)
 gcc_cv_func_mmap_anon=yes;;
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index f5fa0c3..8fd8208 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1650,6 +1650,7 @@ aclocal_deps = \
$(srcdir)/../config/unwind_ipinfo.m4 \
$(srcdir)/../config/warnings.m4 \
$(srcdir)/../config/dfp.m4 \
+   $(srcdir)/../config/mmap.m4 \
$(srcdir)/acinclude.m4
 
 $(srcdir)/configure: @MAINT@ $(srcdir)/configure.ac $(srcdir)/aclocal.m4
diff --git a/gcc/acinclude.m4 b/gcc/acinclude.m4
index 84b828f..c24464b 100644
--- a/gcc/acinclude.m4
+++ b/gcc/acinclude.m4
@@ -221,99 +221,6 @@ test -z $INSTALL_DATA  INSTALL_DATA='${INSTALL} -m 644'
 AC_SUBST(INSTALL_DATA)dnl
 ])
 
-# mmap(2) blacklisting.  Some platforms provide the mmap library routine
-# but don't support all of the features we need from it.
-AC_DEFUN([gcc_AC_FUNC_MMAP_BLACKLIST],
-[
-AC_CHECK_HEADER([sys/mman.h],
-   [gcc_header_sys_mman_h=yes], [gcc_header_sys_mman_h=no])
-AC_CHECK_FUNC([mmap], [gcc_func_mmap=yes], [gcc_func_mmap=no])
-if test $gcc_header_sys_mman_h != yes \
- || test $gcc_func_mmap != yes; then
-   gcc_cv_func_mmap_file=no
-   gcc_cv_func_mmap_dev_zero=no
-   gcc_cv_func_mmap_anon=no
-else
-   AC_CACHE_CHECK([whether read-only mmap of a plain file works], 
-  gcc_cv_func_mmap_file,
-  [# Add a system to this blacklist if 
-   # mmap(0, stat_size, PROT_READ, MAP_PRIVATE, fd, 0) doesn't return a
-   # memory area containing the same data that you'd get if you applied
-   # read() to the same fd.  The only system known to have a problem here
-   # is VMS, where text files have record structure.
-   case $host_os in
- vms* | ultrix*) 
-gcc_cv_func_mmap_file=no ;;
- *)
-gcc_cv_func_mmap_file=yes;;
-   esac])
-   AC_CACHE_CHECK([whether mmap from /dev/zero works],
-  gcc_cv_func_mmap_dev_zero,
-  [# Add a system to this blacklist if it has mmap() but /dev/zero
-   # does not exist, or if mmapping /dev/zero does not give anonymous
-   # zeroed pages with both the following properties:
-   # 1. If you map N consecutive pages in with one call, and then
-   #unmap any subset of those pages, the pages that were not
-   #explicitly unmapped remain accessible.
-   # 2. If you map two adjacent blocks of memory and then unmap them
-   #both at once, they must both go away.
-   # Systems known to be in this category are Windows (all variants),
-   # VMS, and Darwin.
-   case $host_os in
- vms* | cygwin* | pe | mingw* | darwin* | ultrix* | hpux10* | hpux11.00)
-gcc_cv_func_mmap_dev_zero=no ;;
- *)
-gcc_cv_func_mmap_dev_zero=yes;;
-   esac])
-
-   # Unlike /dev/zero, the MAP_ANON(YMOUS) defines can be probed for.
-   AC_CACHE_CHECK([for MAP_ANON(YMOUS

[Patch, Fortran]: Fix libgfortran.h error for VMS

[Tristan Gingold]

Hi,

unfortunately VMS doesn't like to include complex.h after math.h, while the 
reverse is allowed.
The reason is that math.h (unless ANSI_C_SOURCE is defined but that hides many 
math functions) declares cabs/cabsf/cabsl for a structure representing a 
complex number, which is not compatible with the declarations in complex.h

The simplest path is simply to reverse the include order in libgfortran.h.  I 
know that this is somewhat VMS specific, and I welcome better ideas.

Tested by building gfortran for x86_64-darwin and ia64-hp-openvms.

Ok for trunk ?

Tristan.

libgfortran/
2012-04-03  Tristan Gingold  ging...@adacore.com

* libgfortran.h: Include complex.h before math.h

diff --git a/libgfortran/libgfortran.h b/libgfortran/libgfortran.h
index be5f133..ea20e14 100644
--- a/libgfortran/libgfortran.h
+++ b/libgfortran/libgfortran.h
@@ -42,11 +42,19 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
 #include config.h
 
 #include stdio.h
-#include math.h
 #include stddef.h
 #include float.h
 #include stdarg.h
 
+#if HAVE_COMPLEX_H
+/* Must appear before math.h on VMS systems.  */
+# include complex.h
+#else
+#define complex __complex__
+#endif
+
+#include math.h
+
 /* If we're support quad-precision floating-point type, include the
header to our support library.  */
 #ifdef HAVE_FLOAT128
@@ -66,12 +74,6 @@ extern long double __strtold (const char *, char **);
 #define gfc_strtold strtold
 #endif
 
-#if HAVE_COMPLEX_H
-# include complex.h
-#else
-#define complex __complex__
-#endif
-
 #include ../gcc/fortran/libgfortran.h
 
 #include c99_protos.h

Re: [Patch V2] libgfortran: do not assume libm

[Tristan Gingold]

On Mar 30, 2012, at 2:39 PM, Paolo Bonzini wrote:

 Il 30/03/2012 12:22, Tristan Gingold ha scritto:
 
 On Mar 27, 2012, at 10:38 AM, Janne Blomqvist wrote:
 
 On Tue, Mar 27, 2012 at 11:01, Tristan Gingold ging...@adacore.com wrote:
 Hi,
 
 this patch fixes this issue.  Is it OK ?
 
 Ok.
 
 Maybe we should include the AC_DEFINE action within GCC_CHECK_MATH_FUNC.  
 Will try to do that.
 
 That looks like a cleaner solution, yes, and less chance for typos to sneak 
 in.
 
 Hi,
 
 here is the 'cleaner solution': now GCC_CHECK_MATH_FUNC automatically define 
 the HAVE_xxx variable.
 
 The description is now: Define to 1 if you have the `xxx' function.  As a 
 consequence, libgfortran/config.h.in was regenerated (with differences like:
 
 -/* acos is available */
 +/* Define to 1 if you have the `acos' function. */
 #undef HAVE_ACOS
 
 )
 
 Tested by rebuild libgfortran for ia64-hp-openvms and visual inspection of 
 differences.
 
 I have CC: Paolo as he approved the first version of math.m4.
 
 Ok for trunk ?
 
 Yes.

Thanks, committed.

Tristan.

Re: [libiberty] Avoid compiler warnings in stack-limit.c

[Tristan Gingold]

On Mar 30, 2012, at 5:46 PM, Ian Lance Taylor wrote:

 Tristan Gingold ging...@adacore.com writes:
 
 2012-03-30  Tristan Gingold  ging...@adacore.com
 
  * stack-limit.c: Includes ansidecl.h.
  (stack_limit_increase): Add ATTRIBUTE_UNUSED
 
 This is OK.

Thanks, committed.

Tristan.

 
 Thanks.
 
 Ian

Re: [Patch]: ggc-page.c: use uintptr_t instead of size_t

[Tristan Gingold]

On Mar 30, 2012, at 7:44 PM, Richard Henderson wrote:

 On 03/20/2012 05:41 AM, Tristan Gingold wrote:
 2012-03-20  Tristan Gingold  ging...@adacore.com
 
  * ggc-page.c (PAGE_L1_SIZE, PAGE_L2_SIZE, LOOKUP_L1, LOOKUP_L2)
  (ggc_allocated_p, lookup_page_table_entry, set_page_table_entry)
  (alloc_page, init_ggc, clear_marks, struct ggc_pch_data)
  (ggc_pch_this_base): Use uintptr_t instead of size_t.
 
 Ok.

Thanks, committed.

Tristan.