Re: Anyone else run ACATS on ARM?

[Laurent GUERBY]

On Mon, 2009-08-17 at 12:00 +0200, Mikael Pettersson wrote:
> - The patch includes a change to eliminate pointless use of exceptions
>   in xsinfo.adb. That was needed for 4.3 and does no harm in 4.4, but I
>   have not checked if 4.4 actually needs it.

This patch is still needed when you use your 4.4.1 binary to bootstrap
trunk, otherwise stage1 xsinfo fails.

Laurent

Re: Failure building current 4.5 snapshot on Cygwin

[Angelo Graziosi]

Eric Niebler wrote:

I am running into the same problem (cannnot build latest snapshot on cygwin). I 
have built and installed the latest binutils from head (see attached config.log 
for details). But still the build fails. Any help?


This is strange! Recent snapshots (4.3, 4.4, 4.5) build OB both on 
Cygwin-1.5 and 1.7. In 1.5 I have build the same binutils of 1.7.


I configure with:

${source_dir}/configure --prefix="${prefix_dir}" \
--exec-prefix="${eprefix_dir}" \
--sysconfdir="${sysconf_dir}" \
--libdir="${lib_dir}" \
--libexecdir="${libexec_dir}" \
--mandir="${man_dir}" \
--infodir="${info_dir}" \
--program-suffix="${suffix}" \
--enable-bootstrap \
--enable-checking=release \
--enable-decimal-float=bid \
--enable-languages=c,c++,fortran \
--enable-libgomp \
--enable-libssp \
--enable-nls \
--enable-threads=posix \
--enable-version-specific-runtime-libs \
--disable-fixed-point \
--disable-libmudflap \
--disable-shared \
--disable-sjlj-exceptions \
--disable-win32-registry \
--with-arch=i686 \
--with-dwarf2 \
--with-system-zlib \
--with-tune=generic \
--without-included-gettext \
--without-x || return 1


Cheers,
   Angelo.

Re: Failure building current 4.5 snapshot on Cygwin

[Eric Niebler]

Angelo Graziosi wrote:

Eric Niebler wrote:
I am running into the same problem (cannnot build latest snapshot on 
cygwin). I have built and installed the latest binutils from head (see 
attached config.log for details). But still the build fails. Any help?


This is strange! Recent snapshots (4.3, 4.4, 4.5) build OB both on 
Cygwin-1.5 and 1.7. In 1.5 I have build the same binutils of 1.7.


I configure with:



I tried again without --disable-bootstrap. The build still fails, but in 
a different place:


checking for i686-pc-cygwin-gcc...  /home/ericne/objdir/./prev-gcc/xgcc 
-B/home/ericne/objdir/./prev
-gcc/ -B/usr/local/gcc-4.5-20090813/i686-pc-cygwin/bin/ 
-B/usr/local/gcc-4.5-20090813/i686-pc-cygwin
/bin/ -B/usr/local/gcc-4.5-20090813/i686-pc-cygwin/lib/ -isystem 
/usr/local/gcc-4.5-20090813/i686-pc
-cygwin/include -isystem 
/usr/local/gcc-4.5-20090813/i686-pc-cygwin/sys-include

checking for C compiler default output file name... a.exe
checking whether the C compiler works... configure: error: in 
`/home/ericne/objdir/intl':

configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
make[2]: *** [configure-stage2-intl] Error 1
make[2]: Leaving directory `/home/ericne/objdir'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/ericne/objdir'
make: *** [all] Error 2

I've attached objdir/intl/config.log.

--
Eric Niebler
BoostPro Computing
http://www.boostpro.com
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.59.  Invocation command line was

  $ /home/ericne/gcc-4.5-20090813/intl/configure --cache-file=./config.cache 
--prefix=/usr/local/gcc-4.5-20090813 --enable-languages=c,c++ 
--program-transform-name=s,y,y, --build=i686-pc-cygwin --host=i686-pc-cygwin 
--target=i686-pc-cygwin --srcdir=../../gcc-4.5-20090813/intl 
--with-build-libsubdir=. --enable-werror-always

## - ##
## Platform. ##
## - ##

hostname = ericne-xps
uname -m = i686
uname -r = 1.5.25(0.156/4/2)
uname -s = CYGWIN_NT-6.0
uname -v = 2008-06-12 19:34

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch  = i686
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
hostinfo   = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /home/ericne/objdir/i686-pc-cygwin/libstdc++-v3/.libs
PATH: /home/ericne/objdir/i686-pc-cygwin/libssp/.libs
PATH: /home/ericne/objdir/./gcc/shlib
PATH: /home/ericne/objdir/./prev-gcc/shlib
PATH: /home/ericne/objdir/i686-pc-cygwin/libstdc++-v3/.libs
PATH: /home/ericne/objdir/i686-pc-cygwin/libssp/.libs
PATH: /home/ericne/objdir/./gcc/shlib
PATH: /home/ericne/objdir/./prev-gcc/shlib
PATH: /usr/local/binutils-2.19.51/bin/
PATH: /usr/local/binutils-2.19.1/bin/
PATH: /usr/local/bin
PATH: /usr/bin
PATH: /bin
PATH: /usr/X11R6/bin
PATH: /cygdrive/c/Python26/
PATH: /cygdrive/c/Perl/site/bin
PATH: /cygdrive/c/Perl/bin
PATH: /cygdrive/c/Program Files/CodeSynthesis XSD 3.2/bin/
PATH: /cygdrive/c/Program Files/CollabNet Subversion Client
PATH: /cygdrive/c/Windows/system32
PATH: /cygdrive/c/Windows
PATH: /cygdrive/c/Windows/System32/Wbem
PATH: /cygdrive/c/Program Files/Perforce/
PATH: /cygdrive/c/boost/org/trunk/tools/jam/src/bin.cygwinx86
PATH: /cygdrive/c/Program Files/Common Files/Roxio Shared/9.0/DLLShared/
PATH: /cygdrive/c/Program Files/Microsoft SQL Server/80/Tools/Binn/
PATH: /cygdrive/c/Program Files/Microsoft SQL Server/90/Tools/binn/
PATH: /cygdrive/c/Program Files/Microsoft SQL Server/90/DTS/Binn/
PATH: /cygdrive/c/Program Files/Xoreax/IncrediBuild
PATH: /cygdrive/c/Program Files/Common Files/Roxio Shared/DLLShared/


## --- ##
## Core tests. ##
## --- ##

configure:1229: creating cache ./config.cache
configure:1338: checking whether make sets $(MAKE)
configure:1358: result: yes
configure:1406: checking for a BSD-compatible install
configure:1472: result: /usr/bin/install -c
configure:1497: checking whether NLS is requested
configure:1506: result: yes
configure:1544: checking for msgfmt
configure:1578: result: no
configure:1584: checking for gmsgfmt
configure:1615: result: :
configure:1654: checking for xgettext
configure:1688: result: no
configure:1725: checking for msgmerge
configure:1758: result: no
configure:1798: checking for i686-pc-cygwin-gcc
configure:1824: result:  /home/ericne/objdir/./prev-gcc/xgcc 
-B/home/ericne/objdir/./prev-gcc/ 
-B/usr/local/gcc-4.5-20090813/i686-pc-cygwin/bin/ 
-B/usr/local/gcc-4.5-20090813/i686-pc-cygwin/bin/ 
-B/usr/local/gcc-4.5-20090813/i686-pc-cygwin/lib/ -isystem 
/usr/local/gcc-4.5-20090813/i686-pc-cygwin/include -isystem 
/usr/local/gcc-4.5-20090813/i686-pc-cygwin/sys-include   
configure:2108: checking for C compiler version
configure:2111:  /home/ericne/objdir/./prev-gcc/xgcc 
-B/home/ericne/obj

Re: Failure building current 4.5 snapshot on Cygwin

[Tim Prince]

Eric Niebler wrote:

Angelo Graziosi wrote:

Eric Niebler wrote:
I am running into the same problem (cannnot build latest snapshot on 
cygwin). I have built and installed the latest binutils from head 
(see attached config.log for details). But still the build fails. Any 
help?


This is strange! Recent snapshots (4.3, 4.4, 4.5) build OB both on 
Cygwin-1.5 and 1.7. In 1.5 I have build the same binutils of 1.7.






I've attached objdir/intl/config.log.

It says you have triggered cross compilation mode, without complete 
setup.  Also, it says you are building in a directory below your source 
code directory, which I always used to do myself, but stopped on account 
of the number of times I've seen this criticized.
The only new build-blocking problem I've run into in the last month is 
the unsupported autoconf test, which has a #FIXME comment.  I had to 
comment it out.

Re: Failure building current 4.5 snapshot on Cygwin

[Eric Niebler]

Tim Prince wrote:

Eric Niebler wrote:

Angelo Graziosi wrote:

Eric Niebler wrote:
I am running into the same problem (cannnot build latest snapshot on 
cygwin). I have built and installed the latest binutils from head 
(see attached config.log for details). But still the build fails. 
Any help?


This is strange! Recent snapshots (4.3, 4.4, 4.5) build OB both on 
Cygwin-1.5 and 1.7. In 1.5 I have build the same binutils of 1.7.




I've attached objdir/intl/config.log.


It says you have triggered cross compilation mode, without complete 
setup.  


I haven't. I'm building a native gcc on cygwin as I always have. Been 
doing this for years.


Also, it says you are building in a directory below your source 
code directory, which I always used to do myself, but stopped on account 
of the number of times I've seen this criticized.


I'm not. Where does it say that? The source code is at 
~/gcc-4.5-20090813 and the object dir (where I'm building) is ~/objdir.


--
Eric Niebler
BoostPro Computing
http://www.boostpro.com

Re: MELT tutorial on the wiki

[Ralf Wildenhues]

Hello,

* Dave Korn wrote on Sat, Aug 01, 2009 at 08:41:10AM CEST:
> Tom Tromey wrote:
> 
> > I looked into this a little.  It looks like the PPL checks don't work
> > properly in the case where PPL is a system library.  I guess I need
> > --with-ppl=/usr ... I will try that later.
> 
>   Were you using a --prefix?  The PPL checks (by design I think) only look for
> PPL in your prefix.

Just by the way, while it superficially sounds intuitive, I find this a
slightly problematic "feature".  For example when you're cross-compiling,
intending to do a DESTDIR install, and what you pass as --prefix is
inhabited by $build system files and libraries and so on.

My two cents.

Cheers,
Ralf

Re: Failure building current 4.5 snapshot on Cygwin

[Eric Niebler]

Eric Niebler wrote:

Seiji Kachi wrote:

Kai Tietz wrote:

No, this bug appeared on all windows pe-coff targets. A fix for this
is already checked in yesterday on binutils. Could you try it with the
current binutils head version?

Cheers,
Kai


I solved this failure with binutils-2.19.51.


I am running into the same problem (cannnot build latest snapshot on 
cygwin). I have built and installed the latest binutils from head (see 
attached config.log for details). But still the build fails. Any help?


I eventually fixed my problem. This bit from config.log raised my 
suspicions:


configure:7233: checking for ar
configure:7249: found /usr/local/binutils-2.19.51/bin//ar
configure:7259: result: ar
configure:7368: checking for as
configure:7384: found /usr/local/binutils-2.19.51/bin//as
configure:7394: result: as
configure:7503: checking for dlltool
configure:7519: found /usr/local/binutils-2.19.51/bin//dlltool
configure:7529: result: dlltool
configure:7561: checking for ld
configure:7587: result: 
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld.exe


I can't say why ld.exe is found at /usr/i686-pc-cygwin/bin/ld.exe (it's 
not even in my PATH) or even how it got there. There are also copies of 
ar.exe and friends in the same directory, but for some reason, they're 
not getting picked up. Seems mysterious.


After nuking /usr/i686-pc-cygwin/bin (so that the binutils-2.19.51 
version of ld.exe would get picked instead), the build completed 
successfully. I can now build and run executables under cygwin with gcc-4.5.


I still don't know who is at fault for my original problem.

--
Eric Niebler
BoostPro Computing
http://www.boostpro.com

Re: Anyone else run ACATS on ARM?

[Ludovic Brenta]

Mikael Pettersson  writes:
> On Wed, 12 Aug 2009 23:08:00 +0200, Matthias Klose  wrote:
>>is there any arm-linx-gnueabi gnat binary that could be used to bootstrap an 
>>initial gnat-4.4 package for debian?
>
> Yes, see .

Mikael, thanks for this outstanding work! Matthias has now added your
patch to Debian and I'm about to upload gnat-4.4 with it. However I
cannot help but notice that the new file you introduced,
system-linux-armeb.ads, has the GPLv2 or later with special exception
(aka "GNAT-Modified GPL") boilerplate in it.  I suggest that a future
version of this patch migrate to GPLv3 or later with the run-time
exception.

-- 
Ludovic Brenta.

Re: Compiling the GNU ada compiler on a new platform

[Andris Pavenis]

22.08.2009 02:16, Joe Buck kirjoitti:

On Fri, Aug 21, 2009 at 03:40:57PM -0700, Paul Smedley wrote:

I'm wanting to update the GNU ADA compiler for OS/2... I'm currently
building GCC 4.3.x and 4.4.x on OS/2 (C/C++/fortran) but for ADA
configure complains about not finding gnat.  The problem is that the
only gnat compiled for OS/2 was years ago using a different toolchain
so it's not suitable.

I assume that at some point in time, ada didn't depend on an existing
gnat, so if I could find that version, I could compile a version of
gnat to get me started?? Otherwise it's a bit chicken and egg :(


The alternative solution is to build gnat as a cross-compiler, so it
runs on (say) GNU/Linux and produces gnat code for OS/2.  I haven't
done that for gnat, only for other languages, but perhaps someone can
advise you on how to set that up.  Then you can use the cross-compiler
to build a native compiler.


I tried for some last versions cross-native build for DJGPP under Linux.
Not much success for Ada.

About native build:

If there was some port sometimes long ago, then one could do all in several
steps: build for example gcc-3.something including Ada using existing port,
after that move to some newer version. I do not thing that there will be
many steps required.

For DJGPP I initially used used some port I found somewhere when built
first version which included Ada support.

Also:

when building Linux-to-DJGPP cross-compiler (C, C++, Fortran, Objective C,
Objective C++, Ada) I had to bootstrap at first native compiler for Linux
(C and Ada only) or otherwise I have got problems building libada with
native system compiler under Linux.

Andris

Re: Anyone else run ACATS on ARM?

[Mikael Pettersson]

Ludovic Brenta writes:
 > Mikael Pettersson  writes:
 > > On Wed, 12 Aug 2009 23:08:00 +0200, Matthias Klose  wrote:
 > >>is there any arm-linx-gnueabi gnat binary that could be used to bootstrap 
 > >>an 
 > >>initial gnat-4.4 package for debian?
 > >
 > > Yes, see .
 > 
 > Mikael, thanks for this outstanding work! Matthias has now added your
 > patch to Debian and I'm about to upload gnat-4.4 with it. However I
 > cannot help but notice that the new file you introduced,
 > system-linux-armeb.ads, has the GPLv2 or later with special exception
 > (aka "GNAT-Modified GPL") boilerplate in it.  I suggest that a future
 > version of this patch migrate to GPLv3 or later with the run-time
 > exception.

The system-linux-arme{l,b}.ads files have the GPLv2 boilerplate because
they were initially written for gcc-4.3, starting out as clones of the
gcc-4.3 system-linux-ppc.ads file. I just forgot to update the boilerplate
when forward-porting the patch to gcc-4.4. I've now uploaded an incremental
patch to update the boilerplate to match gcc-4.4, so it now mentions GPLv3
instead.

/Mikael

OpenMP 3.0 Task implementation

[Qihang Huang]

Hi,

I am currently reading the libgomp source code, hoping to understand
how gcc schedule tasks and how pthread pool is used in a nested
parallel region.

On the manual section, there are implementation ABI for PARALLEL,
SINGLE, etc constructs. But for some reason, I don't find the same
info for TASK construct. I would like to know how gcc transform the
code when encounter a TASK construct in OpenMP 3.0. I am looking for
information details like this (for example,
http://gcc.gnu.org/onlinedocs/gcc-4.4.1/libgomp/Implementing-PARALLEL-construct.html#Implementing-PARALLEL-construct).
Could someone help me out? Many thanks.



Cheers,
Tim

gcc-4.3-20090823 is now available

[gccadmin]

Snapshot gcc-4.3-20090823 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090823/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch 
revision 151039

You'll find:

gcc-4.3-20090823.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.3-20090823.tar.bz2 C front end and core compiler

gcc-ada-4.3-20090823.tar.bz2  Ada front end and runtime

gcc-fortran-4.3-20090823.tar.bz2  Fortran front end and runtime

gcc-g++-4.3-20090823.tar.bz2  C++ front end and runtime

gcc-java-4.3-20090823.tar.bz2 Java front end and runtime

gcc-objc-4.3-20090823.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.3-20090823.tar.bz2The GCC testsuite

Diffs from 4.3-20090816 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.3
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

GCC Status Report (2009-08-23)

[Mark Mitchell]

Status
==

The trunk is in Stage 1.  As previously stated, we expect that Stage 1
will last through at least the end of August.

In my opinion, the single hardest issue we face with respect to 4.5 is
how to handle the VTA branch.  I've consulted with various people who
have a lot of experience with GCC and the opinions on this work seem
to be quite mixed.  I've looked at the branch myself and can't seem to
form a firm opinion.  The problem it's setting out to solve is
definitely important, but the scope of this particular solution
frightens me.  On the other hand, I can't see a viable better
solution.  So, I'd be very interested in further comments on this
topic.  Feel free to send those to me privately, if you would like to
provide a confidential opinion.

On the quality front, the level of P1 issues has been holding steady
for some time.  Most of the P1 issues are issues around core
optimization technology.  The number of P2 bugs seems to be increasing
slightly.

Quality Data


Priority  # Change from Last Report
--- ---
P1   16   0
P2  104 + 7
P30 - 4
--- ---
Total   120 + 3

Previous Report
===

http://gcc.gnu.org/ml/gcc/2009-07/msg00607.html

The next report for 4.5.0 will be sent by Richard.

--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: Function argument passing

[Mohamed Shafi]

2009/7/16 Richard Henderson :
> On 07/13/2009 07:35 AM, Mohamed Shafi wrote:
>>
>> So i made both TARGET_STRICT_ARGUMENT_NAMING and
>> PRETEND_OUTGOING_VARARGS_NAMED to return false. Is this correct?
>
> Yes.
>
>> How to make the varargs argument to be promoted to 32bits when the
>> normal argument don't require promotion as mentioned in point (1) ?
>
> There is no way at present.  You'll have to extend the promote_function_args
> hook to accept a "bool named" parameter.
>
>> 4. A long long return value is returned in R6 and R7, R6 containing
>> the most significant  long word and R7 containing the least
>> significant long word, regardless of the endianess mode.
>> Solution: Used TARGET_RETURN_IN_MSB to return true when the mode is
>> little endian
>
> I don't believe this is correct.  RETURN_IN_MSB is supposed to be handling
> the case where the data to be returned is smaller than the register in which
> it is returned -- e.g. a 3 byte structure returned in a 32-bit register.  I
> believe you should be using...
>
>> 5. If the first argument is a long long , it is passed in R6 and R7,
>> R6 containing the most significant long word and R7 containing the
>> least significant long word, regardless of the endianess mode.
>> For return value, i have done as mentioned in (4) but I am not sure
>> how to control the argument passing so that R6 contains the msw and R7
>> contains lsw, regardless of the endianess mode.
>
> For both return values and arguments, we support a PARALLEL which allows the
> target to indicate where each piece of the value is located.  It's also true
> that the generated rtl is more complicated, so you'd want to avoid this
> solution in big-endian mode, when it isn't needed.
>
> So here you would do
>
> if (WORDS_BIG_ENDIAN)
>  return gen_rtx_REG (DImode, 6);
> else
>  {
>    rtx r6, r7, par;
>
>    r7 = gen_rtx_REG (SImode, 7);
>    r7 = gen_rtx_EXPR_LIST (SImode, r7, GEN_INT (0));
>    r6 = gen_rtx_REG (SImode, 6);
>    r6 = gen_rtx_EXPR_LIST (SImode, r6, GEN_INT (4));
>    par = gen_rtx_PARALLEL (DImode, gen_rtvec (2, r7, r6)));
>    return par;
>  }
>
> See the docs for FUNCTION_ARG for details.
>

I am getting the following error when i make a function call.

(call_insn 18 17 19 3 1.c:29 (set (parallel:DI [
(expr_list:REG_UNUSED (reg:SI 7 d7)
(const_int 0 [0x0]))
(expr_list:REG_UNUSED (reg:SI 6 d6)
(const_int 4 [0x4]))
])
(call:SI (mem:SI (symbol_ref:SI ("dd1") [flags 0x41]
) [0 S4 A8])
(const_int 8 [0x8]))) -1 (nil)
(expr_list:REG_DEP_TRUE (use (reg:SI 7 d7))
(expr_list:REG_DEP_TRUE (use (reg:SI 6 d6))
(nil

How do i write a pattern for this?
Another question is in LITTLE ENDIAN mode for the return value will
the compiler know that values are actually stored the other way.. in
big endian format? And generate the code accordingly for the rest of
the program?

Regards,
Shafi