Re: [Ada] Anyone else run ACATS on ARM?

[Mikael Pettersson]

Mikael Pettersson writes:
 > Laurent GUERBY writes:
 >  > On Sat, 2009-08-22 at 23:33 +0200, Laurent GUERBY wrote:
 >  > > On Mon, 2009-08-17 at 12:00 +0200, Mikael Pettersson wrote:
 >  > > > On Wed, 12 Aug 2009 23:08:00 +0200, Matthias Klose  
 > wrote:
 >  > > > >On 12.08.2009 23:07, Martin Guy wrote:
 >  > > > >> On 8/12/09, Joel Sherrill  wrote:
 >  > > > >>>   So any ACATS results from any other ARM target would be
 >  > > > >>>   appreciated.
 >  > > > >>
 >  > > > >> I looked into gnat-arm for the new Debian port and the conclusion 
 > was
 >  > > > >> that it has never been bootstrapped onto ARM. The closest I have 
 > seen
 >  > > > >> is Adacore's GNATPro x86->xscale cross-compiler hosted on Windows 
 > and
 >  > > > >> targetting Nucleus OS (gak!)
 >  > > > >>
 >  > > > >> The community feeling was that it would "just go" given a prodigal
 >  > > > >> burst of cross-compiling, but I never got achieved sufficiently 
 > high
 >  > > > >> blood pressure to try it...
 >  > > > >
 >  > > > >is there any arm-linx-gnueabi gnat binary that could be used to 
 > bootstrap an 
 >  > > > >initial gnat-4.4 package for debian?
 >  > > >  > 
 >  > > >  >Matthias
 >  > > > 
 >  > > > Yes, see .
 >  > > 
 >  > > Nice work!
 >  > > 
 >  > > Looks like Ada exception propagation (setjmp/longjmp based) is broken at
 >  > > least in some cases (see below), that might explain the high number of
 >  > > ACATS failure.
 >  > > 
 >  > > My understanding is that
 >  > > 
 >  > >   EH_MECHANISM=-gcc
 >  > > 
 >  > > is not correct for sjlj exceptions so I removed this line from the patch
 >  > > and I'm currently testing with trunk.
 >  > 
 >  > With this change plus the gcc/ada/gcc-interface/targtyps.c one
 >  > I get very good native arm ACATS and gnat.dg results:
 > 
 > Thanks Laurent. I've extracted an incremental diff for the Makefile
 > and targtyps.c changes and applied it to my gcc-4.4.1 version. When
 > it has finished its rebuild I'll see if this lets me eliminate the
 > xsinfo.adb exception handling workaround.

It did, so exceptions do seem to be working now. I've uploaded an
updated bootstrap compiler for armel and two new patches. The patch
kit now is:

gcc-4.4.1-arm-eabi-ada-1.patch: initial patch
gcc-4.4.1-arm-eabi-ada-2.patch: update copyright and licence text
gcc-4.4.1-arm-eabi-ada-3.patch: make SJLJ exceptions work, fix a warning
gcc-4.4.1-arm-eabi-ada-4.patch: revert xsinfo.adb dont-use-exceptions kludge

For those with a compiler based on the initial patch only, apply patches
2 and 3 first, rebuild, then apply patch 4.

/Mikael

Re: [gcc-in-cxx] replacing qsort with std::sort

[Richard Henderson]

On 08/29/2009 03:49 PM, Pedro Lamarão wrote:

2009/8/29 Magnus Fromreide:


Why the changes to gcc/system.h where you unpoision malloc and realloc?
Why the changes to libcpp/system.h where you unpoision malloc, realloc,
calloc and strdup?


Including  requires them for some reason.
I haven't really looked into it.


You should simply include  in system.h before
the poisoning.


r~

Re: [gcc-in-cxx] replacing qsort with std::sort

[Pedro Lamarão]

2009/8/31 Richard Henderson :

> On 08/29/2009 03:49 PM, Pedro Lamarão wrote:
>>
>> 2009/8/29 Magnus Fromreide:
>>>
>>> Why the changes to gcc/system.h where you unpoision malloc and realloc?
>>> Why the changes to libcpp/system.h where you unpoision malloc, realloc,
>>> calloc and strdup?
>>
>> Including  requires them for some reason.
>> I haven't really looked into it.
>
> You should simply include  in system.h before
> the poisoning.

Oh. Right. :-)

For the record, this is the error message I get:

In file included from
/usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/bits/stl_algo.h:60,
 from
/usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/algorithm:62,
 from ../../libcpp/pch.c:26:
/usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/cstdlib:78:8:
error: attempt to use poisoned "calloc"
/usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/cstdlib:85:8:
error: attempt to use poisoned "malloc"
/usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/cstdlib:91:8:
error: attempt to use poisoned "realloc"
/usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/cstdlib:112:11:
error: attempt to use poisoned "calloc"
/usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/cstdlib:119:11:
error: attempt to use poisoned "malloc"
/usr/lib/gcc/i586-redhat-linux/4.4.1/../../../../include/c++/4.4.1/cstdlib:127:11:
error: attempt to use poisoned "realloc"

I'll try to include cstdlib in system.h to see if that's enough.

--
 P.

Re: Checking for -rdynamic flag in gcc/configure

[Ian Lance Taylor]

"Joseph S. Myers"  writes:

> On Fri, 28 Aug 2009, Ian Lance Taylor wrote:
>
>> Link a small program with -rdynamic, one which defines a globally
>> visible function which is not called.  Run objdump -T and see if you can
>> see that symbol in the output.
>> 
>> If you follow this path you must do the in_tree_ld/ld_ver dance so that
>> cross-compilers continue to work.
>
> This is testing properties of the *host* linker (build-x-host in the 
> Canadian cross case), so in-tree tools (which will be built as 
> host-x-target) are irrelevant, and you can always assume that the host 
> tools are already installed (of course you need to make sure you use the 
> correct objdump, not that for build or target).

Ah, you're quite right, sorry.

Ian

Re: Help ! Frozen by a comment in gcc/c-common.h!

[Ian Lance Taylor]

l...@dm.botik.ru (Alexey I. Adamovich) writes:

> Forgot RID_LAST_MODIFIER
>
> On Sat, Aug 29, 2009 at 08:29:21PM +0400, Alexei I. Adamovich wrote:
>> So for the sake of those who will develop C-derived front ends, should
>> we change the comment like below:
>> > /* Reserved identifiers.  This is the union of all the keywords for C,
>> >C++, and Objective-C.  In the past, in earlier GCC versions all the
>> >type modifiers had to be in one block at the beginning, because
>> >they were used as mask bits.  There were 27 type modifiers; so if
>> >anybody added many more the mask mechanism would have to be
>> >redesigned.  Now it doesn't matter, since corresponding mask
>> >machinery gone */
>
> Should the last lines be re-written as follows:
>>redesigned.  Now it doesn't matter, since corresponding mask
>>machinery gone.  But anyway when adding any type modifier it's
>>better to follow the old rule and to get sure that
>>RID_LAST_MODIFIER is defined and handled correctly also */
> [?]

I think we should drop the reference to previous gcc versions and the
old scheme.  I don't think it helps in understanding the code.

It's still necessary to set RID_LAST_MODIFIER correctly as
declspecs_add_type uses it.

Ian

Re: [gcc-in-cxx] replacing qsort with std::sort

[Richard Henderson]

On 08/31/2009 08:26 AM, Pedro Lamarão wrote:

I'll try to include cstdlib in system.h to see if that's enough.


Note the existing

#ifdef HAVE_STDLIB_H
# include 
#endif

You may wish to convert this to

#ifdef __cplusplus
# include 
#elif defined(HAVE_STDLIB_H)
# include 
#endif

and similarly for all of the other C headers
that the C++ standard wraps.


r~

Re: [gcc-in-cxx] replacing qsort with std::sort

[Richard Guenther]

On Mon, Aug 31, 2009 at 6:07 PM, Richard Henderson wrote:
> On 08/31/2009 08:26 AM, Pedro Lamarão wrote:
>>
>> I'll try to include cstdlib in system.h to see if that's enough.
>
> Note the existing
>
> #ifdef HAVE_STDLIB_H
> # include 
> #endif
>
> You may wish to convert this to
>
> #ifdef __cplusplus
> # include 
> #elif defined(HAVE_STDLIB_H)
> # include 
> #endif
>
> and similarly for all of the other C headers
> that the C++ standard wraps.

In which case you'd need a strathegic using namespace std; somewhere.

Richard.

Re: [gcc-in-cxx] replacing qsort with std::sort

[Richard Henderson]

On 08/31/2009 09:09 AM, Richard Guenther wrote:

In which case you'd need a strathegic using namespace std; somewhere.


system.h?  :-)


r~

Re: [gcc-in-cxx] replacing qsort with std::sort

[Pedro Lamarão]

2009/8/28 Pedro Lamarão :

> I have not yet made complete size and execution speed measurements, though.
> I've run the test suite and there are some failures; I think many of
> them are not regressions when compared with a pure build with C++.

Comparing trunk -r151160  and  trunk -t151160 --enable-build-with-cxx
+ patches, these are the sizes of xgcc and g++ before strip:

[psi...@joana obj]$ ls -lh gcc/xgcc gcc/g++
-rwxrwxr-x. 1 psilva psilva 481K Ago 31 12:58 gcc/g++
-rwxrwxr-x. 1 psilva psilva 477K Ago 31 12:58 gcc/xgcc

[psi...@joana obj]$ ls -lh ../../std_sort/obj/gcc/xgcc
../../std_sort/obj/gcc/g++
-rwxrwxr-x. 1 psilva psilva 491K Ago 31 12:33 ../../std_sort/obj/gcc/g++
-rwxrwxr-x. 1 psilva psilva 487K Ago 31 12:33 ../../std_sort/obj/gcc/xgcc

and after strip:

[psi...@joana obj]$ ls -lh gcc/xgcc gcc/g++
-rwxrwxr-x. 1 psilva psilva 221K Ago 31 13:08 gcc/g++
-rwxrwxr-x. 1 psilva psilva 218K Ago 31 13:08 gcc/xgcc

[psi...@joana obj]$ ls -lh ../../std_sort/obj/gcc/xgcc
../../std_sort/obj/gcc/g++
-rwxrwxr-x. 1 psilva psilva 219K Ago 31 13:08 ../../std_sort/obj/gcc/g++
-rwxrwxr-x. 1 psilva psilva 216K Ago 31 13:08 ../../std_sort/obj/gcc/xgcc

Both configurations are basically like this:

[psi...@joana obj]$ gcc/xgcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/opt/gcc-in-cxx
--disable-bootstrap --enable-checking --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20090828 (experimental) (GCC)

--
 P.

Re: letter to GCC Steering Committee, Streamnovation Ltd.

[Ian Lance Taylor]

Adam Rak  writes:

> We are a forming company (StreamNovation Ltd.) from Hungary, and we
> would like to ask your attitude about our plans. We are intending to
> implement a plugin for GCC 4.5 which makes it possible to utilize the
> GPU (graphics processing unit) semi-automatically (later
> fully-automatically). We are planning to implement it as a free
> software according to GPL, but we would also like to sell it in a box,
> and get paid for personal support, guarantee and education.
>
> The basic idea is to make the GPU kind of OpenMP (Open
> Multi-Processing is an application programming interface (API) that
> supports multi-platform shared memory multiprocessing programming in
> C, C++). The GCC user marks the loop, and GCC creates a heterogeneous
> binary code which runs the kernel on GPU, generated from the original
> source code. We expect huge attention for this field in the next few
> years. We think our plugin is in harmony with the GCC development
> mission statement.
>
> We are ready to follow any of your instructions according to GPL,
> source code publicity, and legal compatibility with GPU manufacturers'
> software.

I am not a member of the gcc steering committee.

That said, this is a question better directed to the Free Software
Foundation.  The FSF holds the copyright for gcc and they wrote the
license.  The license text is, of course, readily available, so you
could also consult legal advice in your own country.

The rule for gcc plugins are described at

http://www.fsf.org/licensing/licenses/gcc-exception.html


My personal opinion as an individual contributor to gcc: I don't know
precisely what you mean by "sell it in a box."  You are permitted to
sell any GPL program in a box, provided you include source code (or an
offer to get source code) and provided you permit purchasers of the box
to redistribute the code themselves.  The GPL also always permits you to
"get paid for personal support, guarantee and education."


You may it useful to read the GPL FAQ published by the Free Software
Foundation:

http://www.fsf.org/licensing/licenses/gpl-faq.html

Ian

Re: Help ! Frozen by a comment in gcc/c-common.h!

[Alexey I. Adamovich]

Hi!

On Mon, Aug 31, 2009 at 08:44:24AM -0700, Ian Lance Taylor wrote:
> I think we should drop the reference to previous gcc versions and the
> old scheme.  I don't think it helps in understanding the code.
> 
> It's still necessary to set RID_LAST_MODIFIER correctly as
> declspecs_add_type uses it.

Perfect. Thanks, Ian.

Sincerely,

  Alexei I. Adamovich

Re: ARM wmmx instructions from gcc ?

[Danny Backx]

On Sun, 2009-08-30 at 21:39 +0100, Dave Korn wrote:
> Danny Backx wrote:
> > Hi,
> > 
> > Does anyone know how well gcc-4.4 works with ARM and wmmx instructions ?
> > 
> > I'm working on cegcc. It currently says :
> > pavilion: {86} arm-mingw32ce-gcc -mcpu=iwmmxt t.c
> > t.c:1: error: iwmmxt requires an AAPCS compatible ABI for proper
> > operation
> > pavilion: {87} 
> > 
> > It's clear to me where in the source this message is generated.
> > 
> > It is not clear whether this is caused by errors in my port, or whether
> > gcc has some other problem with this.
> 
>   You should mention that long double alignment macro that the guy on the
> cegcc list thought it was connected with.  ARM_DOUBLEWORD_ALIGN.  If I was
> following that discussion correctly, the ABI requires it, and you have it
> #defined to zero to fix the problem you were getting with float double
> function argument passing, but maybe what this means is that it there's some
> more fundamental problem in the ABI-related MD macros, that fixing it this way
> ended up just papering over.

I (naively) kept my message simple, hoping to get a reaction like :
- I use this all the time in gcc-4.4 so the issue must be in your port
or
- nobody's been using that stuff for ages, it's almost certainly broken.

I guess life is not as simple as that :-)

You already extended my message with a great summary, so I'm finding it
hard to add sensible stuff to it.

Here are two references to why ARM_DOUBLEWORD_ALIGN was added there :
- the commit message
http://sourceforge.net/mailarchive/message.php?msg_name=E1Itn8S-0001xI-Nu%40sc8-pr-svn3.sourceforge.net
- the explanation
http://sourceforge.net/mailarchive/message.php?msg_name=473F27A8.1060805%40portugalmail.pt

The end result of all that was this code in gcc/config/arm/wince-pe.h :
#undef  DEFAULT_STRUCTURE_SIZE_BOUNDARY
#define DEFAULT_STRUCTURE_SIZE_BOUNDARY 8

#undef ARM_DOUBLEWORD_ALIGN
#define ARM_DOUBLEWORD_ALIGN 0
#undef BIGGEST_ALIGNMENT
#define BIGGEST_ALIGNMENT 64

So, question time again : could this be in my port, or a more
fundamental issue as Dave hints ?

How can I find out ?

BTW the message on the cegcc list that started all this :
http://sourceforge.net/mailarchive/forum.php?thread_name=21121251665810%
40webmail35.yandex.ru&forum_name=cegcc-devel

Danny
-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

toplevel configure hits sed program length limit on HP-UX

[Ralf Wildenhues]

While still working to prove Bob wrong on the fixincludes sed issues,
I found out that current toplevel config.status hits the program length
limit of HP-UX 11.11 sed:

$ ./config.status
config.status: creating Makefile
sed: There are too many commands for the 
s&@abs_builddir@&/home/rwild/gcc/build-hppa2.0w-hp-hpux11.11&;t t function.

This is due to the large number of commands added to $extrasub in
configure.ac (around 80 in this case); the limit is (autoconf.info):

|   HP-UX sed has a limit of 99
| commands (not counting `:' commands) and 48 labels, which can not
| be circumvented by using more than one script file.  [...]

It seems to be possible for now to work around it by hacking Autoconf's
status.m4 to omit the 't t' commands:

$ diff -C 2 config.status config.status1
*** config.status   Mon Aug 31 18:41:02 2009
--- config.status   Mon Aug 31 18:40:49 2009
***
*** 1079,1093 
  :t
  /@[a-zA-Z_][a-zA-Z_0-9]*@/!b
! s|@configure_input@|$ac_sed_conf_input|;t t
! s&@top_builddir@&$ac_top_builddir_sub&;t t
! s&@top_build_prefix@&$ac_top_build_prefix&;t t
! s&@srcdir@&$ac_srcdir&;t t
! s&@abs_srcdir@&$ac_abs_srcdir&;t t
! s&@top_srcdir@&$ac_top_srcdir&;t t
! s&@abs_top_srcdir@&$ac_abs_top_srcdir&;t t
! s&@builddir@&$ac_builddir&;t t
! s&@abs_builddir@&$ac_abs_builddir&;t t
! s&@abs_top_builddir@&$ac_abs_top_builddir&;t t
! s&@INSTALL@&$ac_INSTALL&;t t
  $ac_datarootdir_hack
  "
--- 1079,1093 
  :t
  /@[a-zA-Z_][a-zA-Z_0-9]*@/!b
! s|@configure_input@|$ac_sed_conf_input|
! s&@top_builddir@&$ac_top_builddir_sub&
! s&@top_build_prefix@&$ac_top_build_prefix&
! s&@srcdir@&$ac_srcdir&
! s&@abs_srcdir@&$ac_abs_srcdir&
! s&@top_srcdir@&$ac_top_srcdir&
! s&@abs_top_srcdir@&$ac_abs_top_srcdir&
! s&@builddir@&$ac_builddir&
! s&@abs_builddir@&$ac_abs_builddir&
! s&@abs_top_builddir@&$ac_abs_top_builddir&
! s&@INSTALL@&$ac_INSTALL&
  $ac_datarootdir_hack
  "


but in the long run (or short, if you add another couple of directories)
we might have to either
- require a better sed,
- split the script in two inside Autoconf (if $extrasub is nonempty),
- allow for extra sed scripts here.

Should I write a patch for omitting the 't t'?

Cheers,
Ralf

--enable-languages=c --enable-build-with-cxx

[Ralf Wildenhues]

Currently, --enable-languages=c --enable-build-with-cxx fails because
neither the C++ compiler nor libstdc++-v3 are built in Stage 1, but in
Stage 2, CXX is set to .../prev-gcc/g++ and other variables are set
accordingly.  Is this combination supposed to work?

If yes, is it supposed to only build the C++ compiler and associated
library in Stage 1 but not in later stages?

If no (to the first question), then shouldn't configure fail early?

(This is related to PR bootstrap/40950, but only in that it causes a
similarly-looking failure, AFAICS.)

Thanks,
Ralf

Re: toplevel configure hits sed program length limit on HP-UX

[Paolo Bonzini]

On 08/31/2009 08:54 PM, Ralf Wildenhues wrote:

While still working to prove Bob wrong on the fixincludes sed issues,


Bob?


- require a better sed,
- split the script in two inside Autoconf (if $extrasub is nonempty),
- allow for extra sed scripts here.


Like a new variable $ac_presub, that is executed as

  sed "$ac_presub" | sed "$extrasub; other config.status substitutions"

?  I think this is what I like the most.  Does the following plan make 
sense to you as Autoconf maintainer? (CCing autoc...@gnu.org).


The patch should be easy, so we can get ac_presub in 2.65 and upgrade 
GCC from 2.64 to 2.65 as soon as it gets out.  The rationale is that 
anyway 2.65 is going to have only minor bug fixes besides the two Erlang 
patches, some of them too invasive to place them in override.m4.


Regatding the timing of Autoconf 2.65 the DJGPP issue is pending, but it 
can probably be fixed only in DJGPP rather than in autoconf, so it 
wouldn't prevent releasing Autoconf 2.65 (in fact, having the 
possibility to mention it in the release notes would be a reason to 
release 2.65 sooner).


Paolo

Bit fields

[Jean Christophe Beyler]

Dear all,

I am currently working on handling bit-fields on my port and am having
difficulties understanding why GCC is having problems with what I
wrote in.

Following what mips did:

(define_expand "extzv"
  [(set (match_operand 0 "register_operand")
(zero_extract (match_operand 1 "nonimmediate_operand")
  (match_operand 2 "immediate_operand")
  (match_operand 3 "immediate_operand")))]
  "!TARGET_MIPS16"
{
  ...
})

(define_insn "extzv"
  [(set (match_operand:GPR 0 "register_operand" "=d")
(zero_extract:GPR (match_operand:GPR 1 "register_operand" "d")
  (match_operand:SI 2 "immediate_operand" "I")
  (match_operand:SI 3 "immediate_operand" "I")))]
  "mips_use_ins_ext_p (operands[1], INTVAL (operands[2]),INTVAL (operands[3]))"
  "ext\t%0,%1,%3,%2"
  [(set_attr "type" "arith")
   (set_attr "mode" "")])

I did:

(define_insn "extzv"
   [(set (match_operand 0 "register_operand" "")
 (zero_extract (match_operand 1 "register_operand" "")
   (match_operand 2 "const_int_operand" "")
   (match_operand 3 "const_int_operand" "")))]
 ""
 "")

(define_insn "extzvdi2"
   [(set (match_operand:DI 0 "register_operand" "=r")
 (zero_extract:DI (match_operand:DI 1 "register_operand" "r")
   (match_operand:DI 2 "const_int_operand" "L")
   (match_operand:DI 3 "const_int_operand" "L")))]
 "check_extract (DImode, DImode, operands[2], operands[2])"
 "extr\\t%0,%1,%3,%2";
 [(set_attr "type" "arith")
  (set_attr "mode" "DI")
  (set_attr "length"   "1")])

For the moment, I haven't put anything in my expand because I don't
know if anything is necessary yet. I was first looking at if GCC was
generating the right code on simple examples.

But I get this message:
struct4.c: In function 'goo':
struct4.c:32: internal compiler error: in simplify_subreg, at
simplify-rtx.c:4923

Does anybody know how can I solve this issue ?
Thanks again for all your help,
Jean Christophe Beyler

Re: --enable-languages=c --enable-build-with-cxx

[Ian Lance Taylor]

Ralf Wildenhues  writes:

> Currently, --enable-languages=c --enable-build-with-cxx fails because
> neither the C++ compiler nor libstdc++-v3 are built in Stage 1, but in
> Stage 2, CXX is set to .../prev-gcc/g++ and other variables are set
> accordingly.  Is this combination supposed to work?

It would be nice if it worked.  It's kind of an odd thing to do, though,
so it's OK if it fails.

> If yes, is it supposed to only build the C++ compiler and associated
> library in Stage 1 but not in later stages?

It can only work if it builds the C++ compiler in every stage except the
final one.

> If no (to the first question), then shouldn't configure fail early?

Yes, I think it should either work or fail early.

Ian

Re: Bit fields

[Ian Lance Taylor]

Jean Christophe Beyler  writes:

> But I get this message:
> struct4.c: In function 'goo':
> struct4.c:32: internal compiler error: in simplify_subreg, at
> simplify-rtx.c:4923
>
> Does anybody know how can I solve this issue ?

You need to start by looking at line 4923 of simplify-rtx.c to see what
the failure is.  We don't know, since we don't have your source and you
didn't mention which version of gcc you are using.

I don't see anything obviously wrong in your example, but there were
many omitted details which could have caused this problem.

Ian

Re: toplevel configure hits sed program length limit on HP-UX

[Ralf Wildenhues]

* Paolo Bonzini wrote on Mon, Aug 31, 2009 at 09:06:20PM CEST:
> On 08/31/2009 08:54 PM, Ralf Wildenhues wrote:
> >While still working to prove Bob wrong on the fixincludes sed issues,
> 
> Bob?

Bruce; sorry about that, Bruce!

> >- require a better sed,
> >- split the script in two inside Autoconf (if $extrasub is nonempty),
> >- allow for extra sed scripts here.
> 
> Like a new variable $ac_presub, that is executed as
> 
>   sed "$ac_presub" | sed "$extrasub; other config.status substitutions"
> 
> ?  I think this is what I like the most.

Yes, but it is still not extensible.  What if GCC needs three or more
scripts in the future?  Autoconf cannot split scripts, they might be
intertwined, or they might come from different third-party macros.
Granted, this whole concept is a bit flawed, and too low-level.

In fact, I think this API shouldn't be even more encouraged.  It doesn't
really fix things in an elegant way, and it doesn't help for other
pending issues in the GCC tree (such as the multilib fixups that aren't
applied in all cases; report coming up).

> Does the following plan
> make sense to you as Autoconf maintainer? (CCing autoc...@gnu.org).

Well maybe, but I'm not sure whether we want another rush, nor why we
need to decide this alongside with the extrasub issue.  override.m4
is also about relaxing release order requirements, no?

Cheers,
Ralf

Re: toplevel configure hits sed program length limit on HP-UX

[Jeff Law]

On 08/31/09 12:54, Ralf Wildenhues wrote:

While still working to prove Bob wrong on the fixincludes sed issues,
I found out that current toplevel config.status hits the program length
limit of HP-UX 11.11 sed:

$ ./config.status
config.status: creating Makefile
sed: There are too many commands for the 
s&@abs_builddir@&/home/rwild/gcc/build-hppa2.0w-hp-hpux11.11&;t t function.

This is due to the large number of commands added to $extrasub in
configure.ac (around 80 in this case); the limit is (autoconf.info):
   
It's been the case for eons that various configury bits have blown out 
the hpux-sed.  I vaguely recall hacks in Cygnus's trees to split big sed 
scripts into smaller pieces -- but with  my hpux machines gathering 
layers of dust, I haven't kept a copy of the script.

jeff

Re: toplevel configure hits sed program length limit on HP-UX

[Paolo Bonzini]

In fact, I think this API shouldn't be even more encouraged.  It doesn't
really fix things in an elegant way, and it doesn't help for other
pending issues in the GCC tree (such as the multilib fixups that aren't
applied in all cases; report coming up).


I agree.  However, I did not have any alternative idea when I started 
using extrasub, and do not have one now. :-(



Well maybe, but I'm not sure whether we want another rush, nor why we
need to decide this alongside with the extrasub issue.  override.m4
is also about relaxing release order requirements, no?


Yes, though I'd rather not put anything more than 15-20 lines long in 
override.m4.


Paolo

Re: Bit fields

[Jean Christophe Beyler]

Sorry, you are correct. That line is the :
  gcc_assert (outermode != VOIDmode);
of the simplify_subreg function.

However, I've played around with it and saw that I made a mistake when
writing up this question, I simplified what I had put in my MD file,
and actually made a mistake. I apologize.

If I replace this :
(define_insn "extzv"
  [(set (match_operand 0 "register_operand" "")
(zero_extract (match_operand 1 "register_operand" "")
  (match_operand 2 "const_int_operand" "")
  (match_operand 3 "const_int_operand" "")))]
 ""
 "")

into :
(define_expand "extzv"
  [(set (match_operand 0 "register_operand" "")
(zero_extract (match_operand 1 "register_operand" "")
  (match_operand 2 "const_int_operand" "")
  (match_operand 3 "const_int_operand" "")))]
 ""
 "")

I do not get any errors. I don't know if it's handled but it seems to
no longer have issues anymore.

However, if I consider this code:
typedef struct stest {
uint64_t a:1;
uint64_t b:1;
}STest;

void
goo (STest *t, uint64_t *a, uint64_t *b)
{
*a = t->a;
}

At the expand phase, I see:

(insn 9 8 10 3 struct4.c:24 (set (subreg:DI (reg:QI 76) 0)
(zero_extract:DI (reg:DI 75)
(const_int 1 [0x1])
(const_int 0 [0x0]))) -1 (nil))

(insn 10 9 11 3 struct4.c:24 (set (reg:DI 77)
(zero_extend:DI (reg:QI 76))) -1 (nil))

Is there anything I can do to remove that zero_extend?

Thanks,
Jc

Re: toplevel configure hits sed program length limit on HP-UX

[Ralf Wildenhues]

Hello Jeff,

* Jeff Law wrote on Mon, Aug 31, 2009 at 10:00:57PM CEST:
> On 08/31/09 12:54, Ralf Wildenhues wrote:
> >I found out that current toplevel config.status hits the program length
> >limit of HP-UX 11.11 sed:

> >This is due to the large number of commands added to $extrasub in
> >configure.ac (around 80 in this case); the limit is (autoconf.info):
> It's been the case for eons that various configury bits have blown
> out the hpux-sed.

Configury bits of GCC and src projects, or of Autoconf or other
Autoconf-using projects?

>  I vaguely recall hacks in Cygnus's trees to split
> big sed scripts into smaller pieces -- but with  my hpux machines
> gathering layers of dust, I haven't kept a copy of the script.

Autoconf used to use sed for the bulk of the substitutions (it uses awk
now, which allows for better complexity), and it used to split its sed
scripts into chunks fit for HP-UX sed.

Cheers,
Ralf

Re: Bit fields

[Richard Henderson]

On 08/31/2009 01:07 PM, Jean Christophe Beyler wrote:

If I replace this :
(define_insn "extzv"
   [(set (match_operand 0 "register_operand" "")
 (zero_extract (match_operand 1 "register_operand" "")
   (match_operand 2 "const_int_operand" "")
   (match_operand 3 "const_int_operand" "")))]
  ""
  "")


Well, I can tell you that an insn pattern with no modes
on the non-immediate operands will definitely cause problems.


(insn 9 8 10 3 struct4.c:24 (set (subreg:DI (reg:QI 76) 0)
 (zero_extract:DI (reg:DI 75)
 (const_int 1 [0x1])
 (const_int 0 [0x0]))) -1 (nil))

(insn 10 9 11 3 struct4.c:24 (set (reg:DI 77)
 (zero_extend:DI (reg:QI 76))) -1 (nil))

Is there anything I can do to remove that zero_extend?


You could try either using a predicate that disallows
a subreg, or by having your expander rewrite things into

  (set (reg:DI new-scratch))
   (zero_extract:DI ...))
  (set (reg:QI 76 (subreg:QI (reg:DI new scratch)))

and relying on subsequent passes to clean that up.


r~

Re: toplevel configure hits sed program length limit on HP-UX

[Ralf Wildenhues]

* Paolo Bonzini wrote on Mon, Aug 31, 2009 at 10:00:01PM CEST:
> >In fact, I think this API shouldn't be even more encouraged.  It doesn't
> >really fix things in an elegant way, and it doesn't help for other
> >pending issues in the GCC tree (such as the multilib fixups that aren't
> >applied in all cases; report coming up).
> 
> I agree.  However, I did not have any alternative idea when I
> started using extrasub, and do not have one now. :-(

Just use
  AC_CONFIG_COMMANDS([Makefile], [commands to fix up Makefile])

and do whatever $extrasub did yourself in those commands.

Re: Bit fields

[Jean Christophe Beyler]

On Mon, Aug 31, 2009 at 4:36 PM, Richard Henderson wrote:
> On 08/31/2009 01:07 PM, Jean Christophe Beyler wrote:
>>
>> If I replace this :
>> (define_insn "extzv"
>>   [(set (match_operand 0 "register_operand" "")
>>         (zero_extract (match_operand 1 "register_operand" "")
>>                       (match_operand 2 "const_int_operand" "")
>>                       (match_operand 3 "const_int_operand" "")))]
>>  ""
>>  "")
>
> Well, I can tell you that an insn pattern with no modes
> on the non-immediate operands will definitely cause problems.

Yes that was a mistake on my part, I wanted a define_expand instead.

>> (insn 9 8 10 3 struct4.c:24 (set (subreg:DI (reg:QI 76) 0)
>>         (zero_extract:DI (reg:DI 75)
>>             (const_int 1 [0x1])
>>             (const_int 0 [0x0]))) -1 (nil))
>>
>> (insn 10 9 11 3 struct4.c:24 (set (reg:DI 77)
>>         (zero_extend:DI (reg:QI 76))) -1 (nil))
>>
>> Is there anything I can do to remove that zero_extend?
>
> You could try either using a predicate that disallows
> a subreg, or by having your expander rewrite things into
>
>  (set (reg:DI new-scratch))
>       (zero_extract:DI ...))
>  (set (reg:QI 76 (subreg:QI (reg:DI new scratch)))
>
> and relying on subsequent passes to clean that up.

I am going to try this but shouldn't it be :

(set (reg:QI new-scratch))
  (zero_extract:DI ...))
(set (reg:DI 76 (subreg:DI (reg:QI new scratch)))

?


I did this:
if (GET_CODE (operands[0]) != REG)
{
rtx tmp = gen_reg_rtx (DImode);
emit_insn (gen_extzvdi2 (tmp, operands[1], operands[2], operands[3]));
emit_move_insn (operands[0], tmp);
DONE;
}

Which generates in my case :
(insn 9 8 10 3 struct4.c:33 (set (reg:DI 77)
(zero_extract (reg:DI 75)
(const_int 1 [0x1])
(const_int 0 [0x0]))) -1 (nil))

(insn 10 9 11 3 struct4.c:33 (set (subreg:DI (reg:QI 76) 0)
(reg:DI 77)) -1 (nil))

(insn 11 10 12 3 struct4.c:33 (set (reg:DI 78)
(zero_extend:DI (reg:QI 76))) -1 (nil))

As we can see, I still have that zero_extend but maybe it can be
simplified afterwards. I don't know because, now, it fails at the same
place in :

struct4.c:35: internal compiler error: in simplify_subreg, at
simplify-rtx.c:4923
-> This line is the second assert of function simplify_subreg :
gcc_assert (outermode != VOIDmode);

The outermode is VoidMode and the op given to the function is the following :
(ashift:DI (mem/s:DI (reg/v/f:DI 72 [ t ]) [0 S8 A64])
(const_int -1 [0x]))

I don't know where this ashift is from since it doesn't appear in any
of the previous passes.

Any ideas?

As always, thanks,
Jc

multilib and Makefile regeneration

[Ralf Wildenhues]

Hello,

the current multilibs support code is a bit racy, in a few ways.  The
following might be a bit technical, but I'm trying to gauge where to go
from here, even if this is not fixed right away.

gcc/config/multi.m4 provides AM_ENABLE_MULTILIB which allows to specify
the Makefile which is to be multilibbed.  The macro adds another config
command (through obsolete AC_CONFIG_COMMANDS) to config.status.
Autoconf names the command tag 'default-N' with N the index of
additional commands (that usually comes out as 1 or 2).  Now, that means

  ./config.status

or
  ./config.status some/Makefile default-N

run in some target library build directory, will update some/Makefile
properly (including the multilib adjustments), but
  ./config.status some/Makefile

will not (and that latter command can be triggered by 'make' when
$srcdir/some/Makefile.in is newer than some/Makefile).  There are a few
more interesting data points:

The AC_CONFIG_FILES API allows to associate with an output file
(some/Makefile) additional commands (e.g., precisely those multilib
commands).  However, it is not possible to amend to these commands, or
specify AC_CONFIG_FILES(some/file, , additional-commands) twice.  So
while we could make AM_ENABLE_MULTILIB call AC_CONFIG_FILES for the
top Makefile of the library directory, that would require the libraries
to all remove that Makefile from their own AC_CONFIG_FILES list
(and prevent them from using any other extra commands they might want
to use).

It would be nice to have an API that would either

1) allow us to add 'default-N' to the automake rule for regenerating the
Makefile (there's the am__depfiles_maybe hack already, but that's an
internal automake detail) (this would be an Automake task),

2) allow us to add additional commands to an AC_CONFIG_ instance
later (this would be an Autoconf task, and it could allow us to
eliminate am__depfiles_maybe in the future),

3) or simply add to multi.m4 an API to provide a macro that itself
instantiated
AC_CONFIG_FILES(some/Makefile,,
multi-lib-commands plus more-user-commands)

for example through
AM_MULTILIB_FILES(some/Makefile, [inputs], [more-user-commands])

The easiest for now would be (3), the coolest, most difficult and
probably most dangerous one would be (2).  Something like
  AC_CONFIG_FILES_COMMANDS(some/Makefile, more-user-commands,
   [more-init-cmds])

but then the order of issuing this and the respective
  AC_CONFIG_FILES(some/Makefile)

would be significant.  I don't see any way to avoid this.

Cheers,
Ralf

Re: Bit fields

[Richard Henderson]

On 08/31/2009 02:07 PM, Jean Christophe Beyler wrote:

I am going to try this but shouldn't it be :

(set (reg:QI new-scratch))
   (zero_extract:DI ...))


No.


Any ideas?


Nope.  You'll have to debug it.


r~

Re: toplevel configure hits sed program length limit on HP-UX

[Paolo Bonzini]

On 08/31/2009 10:41 PM, Ralf Wildenhues wrote:

* Paolo Bonzini wrote on Mon, Aug 31, 2009 at 10:00:01PM CEST:

In fact, I think this API shouldn't be even more encouraged.  It doesn't
really fix things in an elegant way, and it doesn't help for other
pending issues in the GCC tree (such as the multilib fixups that aren't
applied in all cases; report coming up).


I agree.  However, I did not have any alternative idea when I
started using extrasub, and do not have one now. :-(


Just use
   AC_CONFIG_COMMANDS([Makefile], [commands to fix up Makefile])

and do whatever $extrasub did yourself in those commands.


If you do want to fix HP-UX sed, this indeed seems like a better plan.

Paolo

Re: multilib and Makefile regeneration

[Paolo Bonzini]

On 08/31/2009 11:11 PM, Ralf Wildenhues wrote:

The easiest for now would be (3), the coolest, most difficult and
probably most dangerous one would be (2).  Something like
   AC_CONFIG_FILES_COMMANDS(some/Makefile, more-user-commands,
[more-init-cmds])

but then the order of issuing this and the respective
   AC_CONFIG_FILES(some/Makefile)

would be significant.  I don't see any way to avoid this.


You could specify that AC_CONFIG_FILES comes first, and *_COMMANDS 
occurrences come later in the order that appears in the source (and do 
nothing unless the corresponding AC_CONFIG_FILES exists).


The simplest implementation would amount to two m4_append (actually one 
m4_append plus one _AC_CONFIG_COMMANDS_INIT) in 
AC_CONFIG_FILES_COMMANDS, and an m4_ifdef in _AC_CONFIG_REGISTER_DEST.


Paolo

Re: --enable-languages=c --enable-build-with-cxx

[Joseph S. Myers]

On Mon, 31 Aug 2009, Ralf Wildenhues wrote:

> Currently, --enable-languages=c --enable-build-with-cxx fails because
> neither the C++ compiler nor libstdc++-v3 are built in Stage 1, but in
> Stage 2, CXX is set to .../prev-gcc/g++ and other variables are set
> accordingly.  Is this combination supposed to work?
> 
> If yes, is it supposed to only build the C++ compiler and associated
> library in Stage 1 but not in later stages?
> 
> If no (to the first question), then shouldn't configure fail early?

It seems to me to be a perfectly valid configuration for building a cross 
compiler or an non-bootstrapped native toolchain; it's only in the 
bootstrap case that it doesn't make sense.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: asm goto vs simulate_block

[Richard Henderson]

My guess, witjout seeing the testcase.
In ccp_initialize we have:

  for (i = gsi_start_bb (bb); !gsi_end_p (i); gsi_next (&i))
{
  gimple stmt = gsi_stmt (i);
  bool is_varying = surely_varying_stmt_p (stmt);

  if (is_varying)
{
  tree def;
  ssa_op_iter iter;

  /* If the statement will not produce a constant, mark
 all its outputs VARYING.  */
  FOR_EACH_SSA_TREE_OPERAND (def, stmt, iter, SSA_OP_ALL_DEFS)
set_value_varying (def);
}
  prop_set_simulate_again (stmt, !is_varying);

This code looks clearly broken if the statement is control altering
(like your asm), since it will cause us to never simulate it and add
the outgoing edges (since the outgoing edges are only added in
simulate_stmt).


Your guess is absolutely correct.  We already correctly
handle this case in init_copy_prop, but do not in two
other places.

And I just ran into this with my exception rewrite too,
which has an EH_DISPATCH control statement with multiple
normal edges plus a fallthru.  The only thing "weird"
about this statement is that it has multiple normal edges
and nothing currently visible in the program that determines
which edge will be taken.

The following patch appears to work for both.  I'll commit
it after a bootstrap and test cycle completes.


r~
* tree-ssa-ccp.c (ccp_initialize): Make sure to simulate 
stmt_ends_pp_p statements at least once.
* tree-vrp.c (vrp_initialize): Likewise.

diff --git a/gcc/tree-ssa-ccp.c b/gcc/tree-ssa-ccp.c
index b359d4c..949c4b5 100644
--- a/gcc/tree-ssa-ccp.c
+++ b/gcc/tree-ssa-ccp.c
@@ -650,7 +650,15 @@ ccp_initialize (void)
   for (i = gsi_start_bb (bb); !gsi_end_p (i); gsi_next (&i))
 {
  gimple stmt = gsi_stmt (i);
- bool is_varying = surely_varying_stmt_p (stmt);
+ bool is_varying;
+
+ /* If the statement is a control insn, then we do not
+want to avoid simulating the statement once.  Failure
+to do so means that those edges will never get added.  */
+ if (stmt_ends_bb_p (stmt))
+   is_varying = false;
+ else
+   is_varying = surely_varying_stmt_p (stmt);
 
  if (is_varying)
{
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index 5379b75..7e8a952 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -5317,7 +5317,12 @@ vrp_initialize (void)
 {
  gimple stmt = gsi_stmt (si);
 
- if (!stmt_interesting_for_vrp (stmt))
+ /* If the statement is a control insn, then we do not
+want to avoid simulating the statement once.  Failure
+to do so means that those edges will never get added.  */
+ if (stmt_ends_bb_p (stmt))
+   prop_set_simulate_again (stmt, true);
+ else if (!stmt_interesting_for_vrp (stmt))
{
  ssa_op_iter i;
  tree def;
@@ -5326,9 +5331,7 @@ vrp_initialize (void)
  prop_set_simulate_again (stmt, false);
}
  else
-   {
- prop_set_simulate_again (stmt, true);
-   }
+   prop_set_simulate_again (stmt, true);
}
 }
 }

Call for testers: MPC 0.7 prerelease tarball

[Kaveh R. GHAZI]

Hello,

A prerelease tarball of the upcoming MPC 0.7 is available here:
http://www.multiprecision.org/mpc/download/mpc-0.7-dev.tar.gz

Please help test it for portability and bugs by downloading and compiling
it on systems you have access to.  I'd like a report to contain your
target triplet and the versions of your compiler, GMP and MPFR used when
building MPC.  Also please include your results from "make check".  You
can report your results here in this thread or on the MPC mailing list:
http://lists.gforge.inria.fr/mailman/listinfo/mpc-discuss

Note I encourage reports of all platforms on which GCC bootstraps, but I'm
especially interested in the GCC primary and secondary list from our
release criteria listed here: http://gcc.gnu.org/gcc-4.5/criteria.html

As previously discussed, MPC will become a mandatory library for building
GCC prior to the 4.5 release, so your help in ensuring a smooth transition
is greatly appreciated.

Thanks,
--Kaveh
--
Kaveh R. Ghazi

Re: Bit fields

[Jean Christophe Beyler]

On Mon, Aug 31, 2009 at 5:27 PM, Richard Henderson wrote:
> On 08/31/2009 02:07 PM, Jean Christophe Beyler wrote:
>>
>> I am going to try this but shouldn't it be :
>>
>> (set (reg:QI new-scratch))
>>       (zero_extract:DI ...))
>
> No.

Ok, I think I understand why not:

>> (insn 9 8 10 3 struct4.c:24 (set (subreg:DI (reg:QI 76) 0)
>> (zero_extract:DI (reg:DI 75)
>> (const_int 1 [0x1])
>> (const_int 0 [0x0]))) -1 (nil))

Is basically saying :

(set (reg:DI new-scratch)
(zero_extract:DI (reg:DI 75)
(const_int 1 [0x1])
(const_int 0 [0x0]))) -1 (nil))

and then apply the subreg:

(set (reg:QI 76) (subreg:QI (reg:DI new-scratch)))

which is what you were saying. I was reading the subreg the other way around.

>
>> Any ideas?
>
> Nope.  You'll have to debug it.
>

Ok, is it normal to see a ashift with a negative value though or is
this already sign of a (potentially) different problem?

Thanks again and sorry about the random questions,
Jc