[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 (&global_options) != UI_DWARF2)
+return;
+
+  rtx personality = get_personality_function (current_function_decl);
+
   if (personality)
 {
   enc = ASM_PREFERRED_EH_DATA_FORMAT (/*code=*/2, /*global=*/1);

[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  

Sync with binutils-gdb:
2015-11-20  Tristan Gingold  

* 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  wrote:
> 
> On Thu, May 28, 2015 at 5:01 AM, Tristan Gingold  wrote:
>> 
>>> On 28 May 2015, at 02:26, Ian Lance Taylor  wrote:
>> 
>>> The #include  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  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]: libbacktrace - add support of PE/COFF

[Tristan Gingold]

> On 28 May 2015, at 02:26, Ian Lance Taylor  wrote:

> The #include  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.

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

[Tristan Gingold]

> On 27 May 2015, at 15:36, Jeff Law  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 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 
> 
> Where is  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
> ?

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  

* 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 
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  
+
+   * 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  
 
* 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 @@ BACKTRAC

[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  

* 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 
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  
+
+   * 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  
 
* 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
@@ -607,6 +607,7 @@ NATIVE_TRUE
 BACKTRACE_USES_MALLOC
 ALLOC_FILE
 VIEW_FILE
+BACKTRACE_SUPPORTS

Re: [rs6000] Fix compare debug failure on AIX

[Tristan Gingold]

> On 04 May 2015, at 02:32, David Edelsohn  wrote:
> 
> On Sat, May 2, 2015 at 6:04 AM, Eric Botcazou  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  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  wrote:
> 
> 
> On 8 Jan 2015, at 13:52, Tristan Gingold wrote:
> 
>> 
>>> On 08 Jan 2015, at 13:49, Iain Sandoe  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  
>>>> 
>>>>PR ada/64349
>>>>* env.c (__gnat_environ): Adjust for darwin9/darwin10.
>>>> 
>>>> 
>>> 
>>> 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  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  
>> 
>>  PR ada/64349
>>  * env.c (__gnat_environ): Adjust for darwin9/darwin10.
>> 
>> 
> 
> 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  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  wrote:
> +  size_t sz;
> +  if (__builtin_mul_overflow (x, y, &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  

* MAINTAINERS: Change my email address.


--- MAINTAINERS (revision 216822)
+++ MAINTAINERS (working copy)
@@ -136,7 +136,7 @@
 RTEMS PortsJoel Sherrill   
 RTEMS PortsRalf Corsepius  
 VMSDouglas Rupp
-VMSTristan Gingold 
+VMSTristan Gingold 
 VxWorks ports  Nathan Sidwell  
 windows, cygwin, mingw Kai Tietz   

Re: [RFC] Add aarch64 support for ada

[Tristan Gingold]

On 17 Apr 2014, at 16:50, Richard Henderson  wrote:

> On 04/17/2014 02:00 AM, Tristan Gingold wrote:
>> 
>> On 16 Apr 2014, at 17:36, Richard Henderson  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: [RFC] Add aarch64 support for ada

[Tristan Gingold]

On 16 Apr 2014, at 17:36, Richard Henderson  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: [PATCH]: Fix use of __builtin_eh_pointer in EH_ELSE

[Tristan Gingold]

On Sep 24, 2013, at 8:51 PM, Richard Henderson  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  

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

[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  

* 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  

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

[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  

* 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 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] 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/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.
>
> 
> +   
> + On x86_64-mingw32, exceptions propagate through any code,
> + including code produced by MSVC (the GCC runtime now uses SEH on
> + this target)
> +   
> + 
>  
> 

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

  
+   
+ On x86_64-mingw32, exceptions propagate through any code,
+ including code produced by MSVC (the GCC runtime now uses SEH on
+ this target)
+   
+ 
  

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

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 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 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: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  
>> 
>>  * gcc-interface/decl.c (intrin_return_compatible_p): Map Address to
>>  void *.
>> 
> 
> 

[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
+i386_pe_seh_emit_exce

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 4, 2012, at 1:07 PM, Richard Guenther wrote:

> On Wed, 4 Jul 2012, Tristan Gingold wrote:
> 
>> 
>> On Jul 4, 2012, at 12:59 PM, Richard Guenther wrote:
>> 
>>> On Wed, 4 Jul 2012, Tristan Gingold wrote:
>>> 
>>>> 
>>>> 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  
>>>>>>>>>>> Michael Matz  
>>>>>>>>>>> Tobias Grosser 
>>>>>>>>>>> Sebastian Pop 
>>>>>>>>>>> 
>>>>>>>>>>> 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.
>>> 
>>> Well,
>>> 
>>> 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 
>>>   [gcc_cv_isl=yes],
>>> -   [gcc_cv_isl=no])])
>>> +   [gcc_cv_isl=no],
>>> +   [gcc_cv_isl=yes])])
>>> 
>>>CFLAGS=$_isl_saved_CFLAGS
>>>LDFLAGS=$_isl_saved_LDFLAGS
>>> 
>>> Does not apply for me - there seems to be lines missing.  I guess
>>> the 2nd hunk is for
>> 
>> Arggh, indeed it was truncated.  Here is the correct one.
> 
> ;)
> 
> Ok.

Now committed.

Thanks for your quick answer
(and sorry for sending broken patches).

Tristan.

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

[Tristan Gingold]

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

> On Wed, 4 Jul 2012, Tristan Gingold wrote:
> 
>> 
>> 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  
>>>>>>>>>   Michael Matz  
>>>>>>>>>   Tobias Grosser 
>>>>>>>>>   Sebastian Pop 
>>>>>>>>> 
>>>>>>>>>   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.
> 
> Well,
> 
> 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 
>[gcc_cv_isl=yes],
> -   [gcc_cv_isl=no])])
> +   [gcc_cv_isl=no],
> +   [gcc_cv_isl=yes])])
> 
> CFLAGS=$_isl_saved_CFLAGS
> LDFLAGS=$_isl_saved_LDFLAGS
> 
> Does not apply for me - there seems to be lines missing.  I guess
> the 2nd hunk is for

Arggh, indeed it was truncated.  Here is the correct one.

Tristan.

2012-07-04  Tristan Gingold  

* configure: Regenerate.

config/
2012-07-04  Tristan Gingold  

* 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..4f39724 100644
--- a/config/isl.m4
+++ b/config/isl.m4
@@ -84,7 +84,7 @@ AC_DEFUN([ISL_INIT_FLAGS],
 
 # ISL_REQUESTED (ACTION-IF-REQUESTED, ACTION-IF-NOT)
 # 
-# Provide actions for failed CLooG detection.
+# Provide actions for failed ISL detection.
 AC_DEFUN([ISL_REQUESTED],
 [
   AC_REQUIRE([ISL_INIT_FLAGS])
@@ -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 
#include ],
@@ -131,7 +131,8 @@ AC_DEFUN([ISL_CHECK_VERSION],
   [gcc_cv_isl],
   [AC_RUN_IFELSE([_ISL_CHECK_CT_PROG($1,$2)],
[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  
>>>>>>> Michael Matz  
>>>>>>> Tobias Grosser 
>>>>>>> Sebastian Pop 
>>>>>>> 
>>>>>>> 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] 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  
>>>>>   Michael Matz  
>>>>>   Tobias Grosser 
>>>>>   Sebastian Pop 
>>>>> 
>>>>>   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  

* configure: Regenerate.

config/
2012-07-04  Tristan Gingold  

* 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 
[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 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  
>>> Michael Matz  
>>> Tobias Grosser 
>>> Sebastian Pop 
>>> 
>>> 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] 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  
> 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] 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 :
>> @@ -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-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  
>> 
>>  * 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-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: AT&T 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

[Patch-v2] Adjustments for Windows x64 SEH

[Tristan Gingold]

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.

2012-06-18  Tristan Gingold  

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

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index e2f5740..5ef7d01 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.  */
+  if (TARGET_64BIT_MS_ABI && get_frame_size () > 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)
 {
@@ -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)
{
  /* Ideally we'd determine what portion of the local stack frame
 (within the constraint of the lowest 240) is most heavily used.
@@ -10146,6 +10159,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 +10312,9 @@ ix86_expand_prologue (void)
   m->fs.realigned = true;
 }
 
+  int_registers_saved = (frame.nregs == 0);
+  sse_registers_saved = (frame.nsseregs == 0);
+
   if (frame_pointer_needed && !m->fs.fp_valid)
 {
   /* Note: AT&T enter does NOT have reversed args.  Enter is probably
@@ -10305,6 +10322,17 @@ ix86_expand_prologue (void)
   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 target.  */
+  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);
@@ -10317,8 +10345,6 @@ ix86_expand_prologue (void)
}
 }
 
-  int_registers_saved = (frame.nregs == 0);
-
   if (!int_registers_saved)
 {
   /* If saving registers via PUSH, do so now.  */
@@ -10395,6 +10421,27 @@ ix86_expand_prologue (void)
   current_function_static_stack_size = stack_size;
 }
 
+  /* On SEH target with very large frame size, allocate an area to save
+ SSE registers (as the very large allocation won't be described).  */
+  if (TARGET_SEH
+  && frame.stack_pointer_offset > SEH_MAX_FRAME_SIZE
+  && !sse_registers_saved)
+{
+  HOST_WIDE_INT sse_size =
+   frame.sse_reg_save_offset - frame.reg_save_offset;
+
+  gcc_assert (int_registers_saved);
+
+  /* No need to do stack checking as the area will be immediately
+written.  */
+  pro_epilogue_adjust_stack (stack_pointer_rtx, stack_pointer_rtx,
+GEN_INT (-sse_size), -1,
+   

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:
>> +/* 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.

One possibly naive question: the current code to expand __builtin_frame_address 
is:

  /* For a zero count with __builtin_return_address, we don't care what
 frame address we return, because target-specific definitions will
 override us.  Therefore frame pointer elimination is OK, and using
 the soft frame pointer is OK.

 For a nonzero count, or a zero count with __builtin_frame_address,
 we require a stable offset from the current frame pointer to the
 previous one, so we must use the hard frame pointer, and
 we must disable frame pointer elimination.  */
  if (count == 0 && fndecl_code == BUILT_IN_RETURN_ADDRESS)
tem = frame_pointer_rtx;
  else
{
  tem = hard_frame_pointer_rtx;

  /* Tell reload not to eliminate the frame pointer.  */
  crtl->accesses_prior_frames = 1;
}

So whatever we do with the sfp, the builtin will always returns %rbp - which is 
not what we expect.

This however opens two tracks:

1) Implement the __builtin_establisher_frame with frame_pointer_rtx
2) If accesses_prior_frames is set, makes %rbp be the establisher frame.

I will pursue the later.

Tristan.

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

[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  

* 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 ();

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.

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  wrote:
>> No functional change.
>> 
>> Tested on x86_64-pc-linux-gnu, committed on trunk
>> 
>> 2012-06-12  Tristan Gingold  
>> 
>>* 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.

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

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  
> 
>   * 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)
> {
> 

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  
> 
>   * 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]: 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  
>> 
>>  * common/config/ia64/ia64-common.c (ia64_except_unwind_info): Fix typo.
> 
> Ok.

Thanks, committed.

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

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

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

[Tristan Gingold]

Ping for:

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

> hi,
> 
> looks like a typo...
> 
> Ok for trunk ?
> 
> Tristan.
> 
> 2012-05-14  Tristan Gingold  
> 
>   * 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
> 
> 

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  wrote:
>> 
>> On May 4, 2012, at 2:34 PM, Richard Guenther wrote:
>> 
>>> On Fri, May 4, 2012 at 2:27 PM, Tristan Gingold  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  
>> 
>>   * 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 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  

* 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)
{

[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  

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

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

   * 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 typo in common/config/ia64/ia64-common.c

[Tristan Gingold]

hi,

looks like a typo...

Ok for trunk ?

Tristan.

2012-05-14  Tristan Gingold  

* 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
 

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.

Re: Ping: always supply a mode to plus_constant

[Tristan Gingold]

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

> Richard Guenther  writes:
>> On Sun, May 6, 2012 at 12:23 AM, H.J. Lu  wrote:
>>> On Thu, May 3, 2012 at 11:15 AM, Richard Sandiford
>>>  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  
>   Tristan Gingold  
> 
>   * 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) : 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  

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

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.

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  writes:
> 
> Tristan> 2012-05-04  Tristan Gingold  
> Tristan>  * expr.c (interpret_float_suffix): Add a guard.
> 
> Ok.

Thanks, now committed.

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  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  
>> 
>>* 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),
>> 

[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  

* 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),

[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  

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

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

* 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: */

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: 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: [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  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  
>> 
>>* 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
>> 
>> 

[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  

* 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: [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  writes:
> 
>> gcc/
>> 2012-04-05  Tristan Gingold  
>> 
>>  * gengtype.c (main): Make uintptr_t a known type.
>> 
>> include/
>> 2012-04-05  Tristan Gingold  
>> 
>>  * 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  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  

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

include/
2012-04-05  Tristan Gingold  

* 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 
 #endif
-  typedef unsigned long long libi_uhostptr_t;
-#ifdef __GNUC__
-  __extension__
-#endif
-  typedef long long libi_shostptr_t;
+#ifdef HAVE_INTTYPES_H
+#include 
 #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;

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  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 
>> #endif
>> -  typedef unsigned long long libi_uhostptr_t;
>> -#ifdef __GNUC__
>> -  __extension__
>> -#endif
>> -  typedef long long libi_shostptr_t;
>> +#ifdef HAVE_INTTYPES_H
>> +#include 
>> #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 3:58 PM, Ian Lance Taylor wrote:

> Tristan Gingold  writes:
> 
>> include/
>> 2012-04-04  Tristan Gingold  
>> 
>>  * 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 
 #endif
-  typedef unsigned long long libi_uhostptr_t;
-#ifdef __GNUC__
-  __extension__
-#endif
-  typedef long long libi_shostptr_t;
+#ifdef HAVE_INTTYPES_H
+#include 
 #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 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  
>> 
>>  * 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

[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  

* 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

[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  

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

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.

[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  

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

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

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  
>Tristan Gingold  
> 
>   * 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) : 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
> 

[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  

* 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 
-#include 
 #include 
 #include 
 #include 
 
+#if HAVE_COMPLEX_H
+/* Must appear before math.h on VMS systems.  */
+# include 
+#else
+#define complex __complex__
+#endif
+
+#include 
+
 /* 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 
-#else
-#define complex __complex__
-#endif
-
 #include "../gcc/fortran/libgfortran.h"
 
 #include "c99_protos.h"