[PATCH] ada: Do not capture global variables from elaboration code

Prevent GNAT from capturing library-level global variables in elaboration
code since it is clearly unsafe and may lead to incorrect code generation.

Regtested and i686-pc-linux-gnu.

    gcc/ada/
	PR ada/34287
	* sem_util.adb (Safe_To_Capture_Value): Do not capture values
	of variables declared in a library-level package.

    gcc/testsuite/gnat.dg/
	PR ada/34287
	* check_elaboration_code.adb: New test.

	* bug_elaboration_code.ads, bug_elaboration_code.adb: New support
	files.
---
 gcc/ada/sem_util.adb                             |   11 +++++++++++
 gcc/testsuite/gnat.dg/bug_elaboration_code.adb   |   12 ++++++++++++
 gcc/testsuite/gnat.dg/bug_elaboration_code.ads   |    8 ++++++++
 gcc/testsuite/gnat.dg/check_elaboration_code.adb |    9 +++++++++
 4 files changed, 40 insertions(+), 0 deletions(-)
 create mode 100644 gcc/testsuite/gnat.dg/bug_elaboration_code.adb
 create mode 100644 gcc/testsuite/gnat.dg/bug_elaboration_code.ads
 create mode 100644 gcc/testsuite/gnat.dg/check_elaboration_code.adb

diff --git a/gcc/ada/sem_util.adb b/gcc/ada/sem_util.adb
index a6c35d3..8dd4576 100644
--- a/gcc/ada/sem_util.adb
+++ b/gcc/ada/sem_util.adb

Re: Link tests after GCC_NO_EXECUTABLES

Rask Ingemann Lambertsen <rask <at> sygehus.dk> writes:
> On Fri, Nov 30, 2007 at 10:25:34AM -0800, Mark Mitchell wrote:
>> Rask Ingemann Lambertsen wrote:
>> 
>> >>>    I have a feeling it would be more robust to simulate the link tests
>> >>> inside the autoconf/libtool macros themselves as opposed to explicitly
>> >>> avoiding them in each and every configure.{ac,in}. Supply an option
>> >>> --simulate-link-tests=file_with_results with the default being no and be
>> >>> happy.
>
>> The advantage to the current setup is that you get a
>> loud failure, and have to go actually work out the right answer.
>
>    That's the --cache-file option, except for clobbering the file. I'll see
> if I can arrange for the toplevel Makefile to copy a pre-made config.cache
> into target library build directories just before running configure. That
> ought to deal with all AC_FUNC(S) macros. That leaves just symbol versioning
> and AC_LIBTOOL_DLOPEN, which is manageble.

I've lost track of whether we're still talking about what to do for 4.3,
or whether we're talking about future directions.  So: are we considering
this for 4.3, or for 4.4+?

Richard

Re: Link tests after GCC_NO_EXECUTABLES

Mark Mitchell <mark <at> codesourcery.com> writes:
> Richard Sandiford wrote:
>> 2006-04-18  DJ Delorie  <dj <at> redhat.com>
>> 
>> 	* configure.in (m32c): Build libstdc++-v3.  Pass flags to
>> 	reference libgloss so that libssp can be built in a combined
>> 	tree.
>> 	* configure: Regenerate.
>
>> Mark, DJ?  Do you agree it's OK to drop that hunk?
>
> I'm not quite sure if you're asking for agreement to leave it in our
> sourcebase, or to remove it therefrom, so, unambiguously:

Yeah, sorry about that.  And...

> I would prefer to revert DJ's change, for the same reason as the other
> changes under discussion, so that we're consistent across architectures.

...I was indeed asking whether I could remove that hunk from the source,
rather than restoring it to its original position.

Anyway, given that there have been objections to the patch generally,
I realise that the pre-approval is void.

Richard

Re: Link tests after GCC_NO_EXECUTABLES

On Sat, Dec 01, 2007 at 09:48:20AM +0000, Richard Sandiford wrote:
> Rask Ingemann Lambertsen <rask <at> sygehus.dk> writes:
> >
> >    That's the --cache-file option, except for clobbering the file. I'll see
> > if I can arrange for the toplevel Makefile to copy a pre-made config.cache
> > into target library build directories just before running configure. That
> > ought to deal with all AC_FUNC(S) macros. That leaves just symbol versioning
> > and AC_LIBTOOL_DLOPEN, which is manageble.
> 
> I've lost track of whether we're still talking about what to do for 4.3,
> or whether we're talking about future directions.  So: are we considering
> this for 4.3, or for 4.4+?

   I'll post a patch to implement the --cache-file trick just as soon as I
figure out why the $with_newlib variable is lost sometime before configuring
libgfortran, because it seems to basicly work apart from that. Then we can
decide for 4.3 or 4.4.

--

-- 
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

Re: Link tests after GCC_NO_EXECUTABLES

On Sat, Dec 01, 2007 at 12:52:52PM +0100, Rask Ingemann Lambertsen wrote:
> 
>    I'll post a patch to implement the --cache-file trick just as soon as I
> figure out why the $with_newlib variable is lost sometime before configuring
> libgfortran, because it seems to basicly work apart from that. Then we can
> decide for 4.3 or 4.4.

   Correction: $with_newlib seems to be completely unavailable in the toplevel
Makefile(.tpl). Any ideas?

--

-- 
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

Re: [Patch] libffi: Fixes for MIPS n32 ABI.

David mentioned privately that the Java maintainers wanted a target
maintainer to look at this.  TBH, I don't think much of this is
target-specific, but:

David Daney <ddaney <at> avtrex.com> writes:
> The initial patches for mips64/n32 ABI support passed the libffi
> testsuite, however the java_raw_api support that is used by libjava
> still contained several problems.  This patch attempts to correct them. 
> With the patch applied we now have zero failures in the libjava
> testsuite (down from around 30).
>
> The problem was that libffi and libjava's interpreter use different
> union definitions to describe stack elements.  In the case of
> mips64/n32, these unions had different sizes (8 vs. 4 bytes).  This
> caused most interpreter method calls to fail.

...you're talking about ffi_raw vs. _Jv_word, right?  As far as
reviewing the patch goes, I'll sign off on the former being 8 bytes
and the latter being 4, if that helps.

Naively, rather than have an n32-specific definition of ffi_raw,
I'd have thought that we'd want some new target-controllable macro
that causes ffi_raw to be defined in the same way as _Jv_Word.
It sounds like this issue could affect other 64-bit targets
with an ILP32 ABI.

I don't really know much about the subtleties of the ffi_raw_*
vs. ffi_java_raw_* APIs though.  What does ffi_raw correspond to
when using the ffi_raw_* API (rather than the ffi_java_raw_* API)
on a !FFI_NATIVE_RAW_API target?  Is there any significance to the

Re: [PATCH] Fix includes of sparseset.*

On Wed, Nov 28, 2007 at 10:44:12AM -0700, Tom Tromey wrote:
>>>>>> "Bernhard" == Bernhard Fischer <rep.dot.nop <at> gmail.com> writes:
>
>Bernhard> 	* sparseset.h: Include config.h before system.h
>Bernhard> 	* sparseset.c: Remove inclusion of libiberty.h
>
>I think it is a bit odd to include config.h from a header.
>
>Instead, I think as a rule every .c file should include config.h as
>the first header.

Updated patch attached. Bootstrapped and regtested on i386-linux-gnu
without any new regression. Ok for trunk?

gcc/ChangeLog:
2007-11-27  Bernhard Fischer  <>

        * sparseset.c: Include config.h and system.h before sparseset.h.
        * sparseset.h: Remove inclusion of system.h.

thanks,

Re: Link tests after GCC_NO_EXECUTABLES

Rask Ingemann Lambertsen <rask <at> sygehus.dk> writes:

> On Sat, Dec 01, 2007 at 12:52:52PM +0100, Rask Ingemann Lambertsen wrote:
>> 
>>    I'll post a patch to implement the --cache-file trick just as soon as I
>> figure out why the $with_newlib variable is lost sometime before configuring
>> libgfortran, because it seems to basicly work apart from that. Then we can
>> decide for 4.3 or 4.4.
>
>    Correction: $with_newlib seems to be completely unavailable in the toplevel
> Makefile(.tpl). Any ideas?

Only variables subject to AC_SUBST are available in the generated
Makefile.  There is extra_host_args which includes --with-newlib, but
this is only passed to configure scripts in host directories (via
host_configargs), not target directories.

Andreas.

--

-- 
Andreas Schwab, SuSE Labs, schwab <at> suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[PATCH] ada: Initialize OUT access type parameters of an entry call

Regtested on i686-pc-linux-gnu.

    gcc/ada/
	PR ada/21489
	* exp_ch9.adb (Build_Simple_Entry_Call): Initialize OUT access type
	parameters of an entry call.

    gcc/testsuite/
	PR ada/21489
	* gnat.dg/rm_6_4_1_13.adb: New test.
---
 gcc/ada/exp_ch9.adb                   |    7 ++-
 gcc/testsuite/gnat.dg/rm_6_4_1_13.adb |   90 +++++++++++++++++++++++++++++++++
 2 files changed, 95 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gnat.dg/rm_6_4_1_13.adb

diff --git a/gcc/ada/exp_ch9.adb b/gcc/ada/exp_ch9.adb
index 87fbc12..ed3f242 100644
--- a/gcc/ada/exp_ch9.adb
+++ b/gcc/ada/exp_ch9.adb
 <at>  <at>  -3023,9 +3023,12  <at>  <at>  package body Exp_Ch9 is

                   --  We have to make an assignment statement separate for the
                   --  case of limited type. We cannot assign it unless the
-                  --  Assignment_OK flag is set first.
+                  --  Assignment_OK flag is set first. OUT access type
+                  --  parameters are also initialized per RM 6.4.1 (13).

-                  if Ekind (Formal) /= E_Out_Parameter then
+                  if Ekind (Formal) /= E_Out_Parameter

[v3] Minor tweak to get_temporary_buffer

Hi,

tested x86_64-linux, committed to mainline.

Paolo.

//////////////////

2007-12-01  Paolo Carlini  <pcarlini <at> suse.de>

	* include/bits/stl_tempbuf.h (__get_temporary_buffer): Fold
	in get_temporary_buffer.

Index: include/bits/stl_tempbuf.h
===================================================================
--- include/bits/stl_tempbuf.h	(revision 130556)
+++ include/bits/stl_tempbuf.h	(working copy)
 <at>  <at>  -69,14 +69,25  <at>  <at> 
 _GLIBCXX_BEGIN_NAMESPACE(std)

   /**
-   *   <at> if maint
-   *  This is a helper function.  The unused second parameter exists to
-   *  permit the real get_temporary_buffer to use template parameter deduction.
-   *   <at> endif
+   *   <at> brief Allocates a temporary buffer.
+   *   <at> param  len  The number of objects of type Tp.
+   *   <at> return See full description.