Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

[Matthias Klose]

Paolo Carlini schrieb:
> Matthias Klose wrote:
>> Paolo Carlini schrieb:
>>   
>>> Paolo Carlini wrote:
>>> 
 Ok, thanks. Then, I think I'll implement this, for now. Seems in any
 case conservative to have a link type test identical to the one used in
 libgomp and libgfortran and a fall back to the .s file (as currently used).
   
   
>>> I committed the below to mainline. Assuming no issues are noticed with
>>> it, I mean to apply it to 4_4-branch too in a few days.
>>> 
>> with this patch applied to the 4.4 branch, the tests now succeed as expected 
>> on
>> the 4_4-branch on {armeabi,hppa,sparc}-linux.
>>   
> Good. I have now backported the patch to 4_4-branch too. Please double
> check that the regression tests are also fine, thanks in advance.

Jakub pointed out on irc that sparc-linux (32bit, v8) doesn't have the atomic
support functions. Building a 32bit v9 compiler as part of a biarch build is
currently not supported (64bit and v9 are tightly coupled).

No regressions on hppa-linux.

On arm-linux-gnueabi there are regressions of the form

/usr/bin/ld: ./atomic-1.exe: hidden symbol `__sync_val_compare_and_swap_4' in
/home/doko/gcc/4.4/gcc-4.4-4.4.0/build/gcc/libgcc.a(linux-atomic.o) is
referenced by DSO
/usr/bin/ld: final link failed: Nonrepresentable section on output

in the libgomp, libstdc++ and g++ testsuites. Linking the shared libstdc++ with
both -lgcc_s and -lgcc does fix these (testsuites currently running), however
I'm not sure how to do this properly, as libtool removes any `-lgcc' argument.

  Matthias

Re: Problems with in-tree host libraries (gmp, ppl, etc)

[Roberto Bagnara]

Kaveh R. GHAZI wrote:

On Sat, 2 May 2009, Anthony Green wrote:


The top level configury suggests that you can simply drop gmp, ppl, etc
into the top level source dir and they will get configured and used.
Does this really work?


It is supposed to.  I haven't worked on or tested the ppl machinery so I
don't know what shape it is in.



Index: Makefile.def
===
--- Makefile.def(revision 146995)
+++ Makefile.def(working copy)
@@ -60,7 +60,7 @@
 host_modules= { module= gawk; };
 host_modules= { module= gettext; };
 host_modules= { module= gmp; lib_path=.libs; bootstrap=true;
-   extra_configure_flags='--disable-shared';
+   extra_configure_flags='--disable-shared --enable-cxx';
no_install= true;
host="none-${host_vendor}-${host_os}";
target="none-${host_vendor}-${host_os}"; };



I would only pass in this flag if ppl is being used.  Look at what I did
with extra_mpfr_configure_flags in the top level directory.  You can use a
similar mechanism to have a flag passed in to the gmp build conditionally.



Even then, the ppl configury isn't detecting the gmp we just built.  It
seems as though we should install gmp in a local temporary install tree
and point ppl at that.  See below for a trace of the ppl configury as it
attempts to detect an in-tree gmp (after applying the patch above).
AG


I don't know if ppl was ever setup to detect/use an in-tree gmp.  It would
need to be able to specify --with-gmp-build= or something equivalent to
get the header and library from a build tree rather than an install tree.
They're laid out slightly differently.


The PPL configure script offers the following options:

  --with-libgmp-prefix[=DIR]  search for libgmp in DIR/include and DIR/lib
  --without-libgmp-prefix don't search for libgmp in includedir and libdir
  --with-libgmpxx-prefix[=DIR]  search for libgmpxx in DIR/include and DIR/lib
  --without-libgmpxx-prefix don't search for libgmpxx in includedir and 
libdir

If the C and the C++ interface of GMP have been installed in the same places,
specifying --with-libgmp-prefix[=DIR] is enough.

If you think that being able to use a non-installed GMP build tree is important,
we can add an option to that effect.

--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagn...@cs.unipr.it

Re: Fwd: gcc instruction scheduling makes things worse?

[Alex Turjan]

> For data dependency cases,  I do some jobs in
> the adjust_cost target hook.
Normally the scheduling takes into account the instruction latencies which you 
have specified: for load 2, for mul 4 and for alu 1.
Why do you need to adjust the sched costs? Did you try simply without adjusting 
the costs?

> I  read  THE GNU INSTRUCTION SCHEDULER written by 
> Michael D. Tiemann,
This is old work. Meanwhile there is a new scheduler based on finite state 
machines. You can read in "The finite state automaton based pipeline hazard 
recognizer and instruction scheduler in GCC" by Vladimir Makarov.



  

Re: [Announcement] Creating lightweight IPO branch

[Richard Guenther]

On Tue, May 5, 2009 at 7:56 PM, Xinliang David Li  wrote:
> On Tue, May 5, 2009 at 2:47 AM, Richard Guenther
>  wrote:
>> On Tue, May 5, 2009 at 7:00 AM, Xinliang David Li  wrote:
>>> Hi, I am going to create a gcc branch for the functionality of
>>> lightweight IPO. The description of the project and current status can
>>> be found in http://gcc.gnu.org/wiki/LightweightIpo.  Some highlights:
>>>
>>> 1) If you already use FDO in your build, you also get IPO almost for free;
>>> 2) It is an IPO solution  practical to very large real world C++ 
>>> applications;
>>> 3) Performance potential is very large (though I've seen case
>>> increased compiler freedom can lead to performance degradation due to
>>> over-optimization (inliner, unroller etc) -- but this is a different
>>> matter).
>>>
>>> If the idea is generally accepted, I will prepare a series of patches
>>> and submit them to gcc trunk.
>>
>> I was hoping that with LTO we can get rid of -combine, as its type/decl
>> merging is fragile in many cases.  Does this somehow conflict with
>> LIPO?
>
> LIPO does not depend on existing type/decl merging functionality --
> though it does leverage the parser driver code -- mainly extending the
> filescope push/pop thingy, so mostly there is no conflict.
>
>  From what I understand is that you are merging TUs in the
>> frontend (like -combine) - did you consider merging TUs with the
>> LTO infrastructure, but in memory?
>
> In LIPO, TU merging does not happen in frontend (the document may
> sound a little confusing) -- the modules are parsed independently and
> merged/linked after parsing. Diego and I talked about the possibilty
> of using LTO to do this -- but that requires significant driver
> change.

I see - so the modules are parsed and transformed to gimple (or generic?)
and then merged.  But then LTO and LIPO (could) share decl and type
merging code at least, no?

Thanks,
Richard.

Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

[Paolo Carlini]

Matthias Klose wrote:
> On arm-linux-gnueabi there are regressions of the form
>
> /usr/bin/ld: ./atomic-1.exe: hidden symbol `__sync_val_compare_and_swap_4' in
> /home/doko/gcc/4.4/gcc-4.4-4.4.0/build/gcc/libgcc.a(linux-atomic.o) is
> referenced by DSO
> /usr/bin/ld: final link failed: Nonrepresentable section on output
>
> in the libgomp, libstdc++ and g++ testsuites. Linking the shared libstdc++ 
> with
> both -lgcc_s and -lgcc does fix these (testsuites currently running), however
> I'm not sure how to do this properly, as libtool removes any `-lgcc' argument.
>   
I see, looks like the problem warned about by Joseph is biting us. For
the time being I reverted the patch both from mainline and the branch.
Please make sure it gets fixed properly and then let's reconsider the
libstdc++ patch, for mainline at least.

Thanks,
Paolo.

Re: opaque vector types?

[Paolo Bonzini]

DJ Delorie wrote:
> Andrew Pinski  writes:
>> You could do what the rs6000 back-end does for the altivec builtins
>> and resolve them while the parser is run (the SPU back-end does the
>> same thing too).  Yes there are opaque vector types, you just use
>> build_opaque_vector_type instead of build_vector_type.
> 
> Thanks, I'll look at those.  Any way to prototype such functions in C ?

If the opaque vector type is exported as say __v4si_opaque__ that would
be simply

extern __v4si_opaque__ my_and (__v4si_opaque__, __v4si_opaque__);

Opaque vector types are not available via attributes, but that could be
easily added.

Paolo

Multilib for ARM in thumb2 mode

[Samuel Tardieu]

Right now, to be able to compile a mutilib-enabled ARM-targeted compiler
supporting thumb2, one has to uncomment some code in
gcc/config/arm/t-arm-elf. Given that thumb2 processors are more and more
used (such as microcontrollers based on the Cortex-M3), wouldn't it make
sense to unconditionnaly compile the thumb2 version of the library in
4.5.0 and 4.4.1?

If people don't want it, could we add an option to enable thumb2 at
configure time?

  Sam
-- 
Samuel Tardieu -- s...@rfc1149.net -- http://www.rfc1149.net/

Re: Problems with in-tree host libraries (gmp, ppl, etc)

[Paolo Bonzini]

> If the C and the C++ interface of GMP have been installed in the same
> places,
> specifying --with-libgmp-prefix[=DIR] is enough.
> 
> If you think that being able to use a non-installed GMP build tree is
> important, we can add an option to that effect.

Yes, that would help.  mpfr is using --with-gmp-build as the option name.

Paolo

scheduling question

[Alex Turjan]

Hi,
During scheduling Im confronted with the fact that an instruction is moved
from the ready list to queued with the cost 2, while according to my
expectations the insn should have been moved to queued with cost 1.

Did anybody experience similar problem? 

In case an insn is ready but can bot be schedled in the current
cycle, is it correct (i.e. the generated code is correct) to move the insn
to the queue list with cost 1 ?; no matter what it the value >=1
returned by state_transition.

It seams to me that moving from the ready to queue list with cost >=1 is 
an optimization for compilation time.
 



  

Re: GCC 4.4.1 Status Report (2009-05-05)

[Jack Howarth]

On Tue, May 05, 2009 at 09:35:58PM -0700, Mark Mitchell wrote:
> 
> Status
> ==
> 
> GCC 4.4.0 was released into the wild approximately two weeks ago, and
> so far few serious defects have been reported.  That's great!  There
> are, however, a copule of open P1s and a bevy of P2s -- most of which
> also apply to 4.5.  So, there are good opportunities to help both 4.4
> and 4.5.
> 
> The 4.4 branch is open under the usual release branch rules.
> 
> We are aiming for a 4.4.1 release around June 21st.
> 
> Quality Data
> 
> 
> Priority# Change from Last Report
>   --- ---
> P1  2 +  2
> P2 80 +  5
> P3  0 -  9
>   --- ---
> Total  82 -  2
> 
> Previous Report
> ===
> 
> http://gcc.gnu.org/ml/gcc/2009-04/msg00564.html
> 
> The next report for 4.4.0 will be sent by Richard.
> 
> --
> Mark Mitchell
> CodeSourcery
> m...@codesourcery.com
> (650) 331-3385 x713
> 

Mark,
   Shouldn't PR3 be higher than a P3 since it puts the compiler
in an infinite loop and is a regression from gcc 4.3.x?
  Jack

Bootstrap broken by ppl/cloog config problem: finds non-system/non-standard "/include" dir

[Dave Korn]

  A quick head's-up, in case anyone else runs into this or is working on it:

  Yesterday I installed the new ppl and cloog packages from my distro
(Cygwin), and today GCC doesn't bootstrap.  This is triggered by an unusual
environment on my build machine, but I think it definitely exposes something
wrong in the configury changes related.

  The 'unusual environment' on my machine is that I have a "/include" dir,
full of header files with the standard names, some of which are bogus enough
to trigger compiler warnings:

/gnu/gcc/obj7ppl/./prev-gcc/xgcc -B/gnu/gcc/obj7ppl/./prev-gcc/
-B/opt/gcc-tools/i686-pc-cygwin/bin/ -c  -g -O2 -DIN_GCC   -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-fno-common  -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/gnu/gcc/gcc/gcc
-I/gnu/gcc/gcc/gcc/build -I/gnu/gcc/gcc/gcc/../include
-I/gnu/gcc/gcc/gcc/../libcpp/include -I/usr/include -I/usr/include
-I/gnu/gcc/gcc/gcc/../libdecnumber -I/gnu/gcc/gcc/gcc/../libdecnumber/dpd
-I../libdecnumber -I/include  -I/include -DCLOOG_PPL_BACKEND   -o
build/genmodes.o /gnu/gcc/gcc/gcc/genmodes.c
cc1: warnings being treated as errors
In file included from /gnu/gcc/gcc/gcc/system.h:41,
 from /gnu/gcc/gcc/gcc/genmodes.c:22:
/include/stdio.h:615: error: no previous prototype for '__sgetc_r'
make[3]: *** [build/genmodes.o] Error 1
make[3]: Leaving directory `/gnu/gcc/obj7ppl/gcc'
make[2]: *** [all-stage2-gcc] Error 2


  However, I think the details aren't relevant.  "/include" is not a standard
location on my target, and should not have been searched.  It is outside
$prefix, and one level above /usr, where --with-gmp and --with-mpfr point; I
cannot see any reason why it should even be considered speculatively.

$ /gnu/gcc/gcc/configure  '--prefix=/opt/gcc-tools'  '-v' '--with-gmp=/usr'
'--with-mpfr=/usr' '--enable-bootstrap'
'--enable-version-specific-runtime-libs' '--with-slibdir=/usr/bin'
'--libexecdir=/usr/lib' '--enable-static' '--enable-shared'
'--enable-shared-libgcc' '--disable-__cxa_atexit' '--with-gnu-ld' '--with
-gnu-as' '--with-dwarf2' '--disable-sjlj-exceptions' '--disable-symvers'
'--enable-libjava' '--enable-interpreter' '--program-suffix=-4'
'--enable-libgomp' '--enable-libssp' '--disable-libada'
'--enable-threads=posix' '--with-arch=i686' '--with-tune=generic' 'CC=gcc-4'
'CXX=g++-4' 'CC_FOR_TARGET=gcc-4' 'CXX_FOR_TARGET=g++-4'
'--with-ecj-jar=/usr/share/java/ecj.jar' 'LD=/opt/gcc-tools/bin/ld.exe'
'LD_FOR_TARGET=/opt/gcc-tools/bin/ld.exe' 'AS=/opt/gcc-tools/bin/as.exe'
'AS_FOR_TARGET=/opt/gcc-tools/bin/as.exe' '--disable-win32-registry'
'--enable-libgcj-debug' '--enable-languages=c,c++,java,fortran' 2>&1 | tee
conf.log


  As I said, this didn't happen the day before when I configured similarly but
without cloog and ppl libs present in /usr/lib, so I reckon it must be
triggered by related configury.  I'll do some more digging and find out why it
happens; so far I've just verified that "-I/include" was not present on
command-lines in the previous bootstrap and only appeared in the new failing
build.

  I'm about to start looking through the config logs; if anyone knows anything
or has any ideas about this, please share!


cheers,
  DaveK

Re: Bootstrap broken by ppl/cloog config problem: finds non-system/non-standard "/include" dir

[Andreas Schwab]

Dave Korn  writes:

>   I'm about to start looking through the config logs; if anyone knows anything
> or has any ideas about this, please share!

The problem is here in toplevel configure.ac:

case $with_ppl in 
  no)
ppllibs=
;;
  *)
ppllibs="-L$with_ppl/lib -lppl_c -lppl -lgmpxx $with_host_libstdcxx"
pplinc="-I$with_ppl/include $pplinc"
LIBS="$ppllibs $LIBS"
;;
esac

If --with-ppl was not given then $with_ppl is empty.
 
Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Bootstrap broken by ppl/cloog config problem: finds non-system/non-standard "/include" dir

[Dave Korn]

Andreas Schwab wrote:
> Dave Korn  writes:
> 
>>   I'm about to start looking through the config logs; if anyone knows 
>> anything
>> or has any ideas about this, please share!
> 
> The problem is here in toplevel configure.ac:
> 
> case $with_ppl in 
>   no)
> ppllibs=
> ;;
>   *)
> ppllibs="-L$with_ppl/lib -lppl_c -lppl -lgmpxx $with_host_libstdcxx"
> pplinc="-I$with_ppl/include $pplinc"
> LIBS="$ppllibs $LIBS"
> ;;
> esac
> 
> If --with-ppl was not given then $with_ppl is empty.


  Heh, I was just about to post that, only I was looking at $clooginc rather
than $pplinc!  The same problem exists for both; I'm pretty sure we should
fall back on $prefix if the --with option is empty.

  Unless you're already on it, I'll post a patch shortly.

cheers,
  DaveK

Re: Bootstrap broken by ppl/cloog config problem: finds non-system/non-standard "/include" dir

[Tim Prince]

Dave Korn wrote:

> 
>   Heh, I was just about to post that, only I was looking at $clooginc rather
> than $pplinc!  The same problem exists for both; I'm pretty sure we should
> fall back on $prefix if the --with option is empty.
> 

When I bootstrapped gcc 4.5 on cygwin yesterday, configure recognized the
newly installed ppl, but not the cloog.  The bootstrap completed
successfully, and I'm not looking a gift horse in the mouth.

Re: Bootstrap broken by ppl/cloog config problem: finds non-system/non-standard "/include" dir

[Dave Korn]

Tim Prince wrote:
> Dave Korn wrote:
> 
>>   Heh, I was just about to post that, only I was looking at $clooginc rather
>> than $pplinc!  The same problem exists for both; I'm pretty sure we should
>> fall back on $prefix if the --with option is empty.
>>
> 
> When I bootstrapped gcc 4.5 on cygwin yesterday, configure recognized the
> newly installed ppl, but not the cloog.  The bootstrap completed
> successfully, and I'm not looking a gift horse in the mouth.

  You don't have a bogus /include dir, but I bet you'll find -I/include in 
PPLINC.

  It would be interesting to know why it didn't spot cloog.  What's in your
top-level $objdir/config.log?

  BTW, looking at the logic by which all this gets set, I think we're going to
have to take care not to break the in-tree build stuff - which is also subject
of an ongoing thread.  Let me just referesh my memory of what they're 
discussing.

cheers,
  DaveK

Re: GCC 4.5.0 Status Report (2009-05-05)

[Richard Earnshaw]

On Tue, 2009-05-05 at 09:25 -0700, Mark Mitchell wrote:
> Clearly, we have had a significant jump in P1 issues due to the major
> changes made to the compiler middle-end.  Let's drive that number
> down -- otherwise it will be hard for other people to get their
> improvements contributed.

> The slush that I requested last week has been lifted.  However, I have
> asked for relative calm until the cond-optab branch has been merged to
> mainline, which will hopefully occur on Friday, May 8th.

As of this morning (UK), native bootstrap on ARM is still broken.

R.

Re: GCC 4.5.0 Status Report (2009-05-05)

[Mark Mitchell]

Richard Earnshaw wrote:

>> The slush that I requested last week has been lifted.  However, I have
>> asked for relative calm until the cond-optab branch has been merged to
>> mainline, which will hopefully occur on Friday, May 8th.
> 
> As of this morning (UK), native bootstrap on ARM is still broken.

Is this PR 39978?

Thanks,

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

What precisely is the status of ppl/cloog anyway?

[Dave Korn]

  Sorry to have to ask a dumb question, but it's not clear to me and I'm not
having a lot of luck searching recent list posts:

  Are cloog and ppl now mandatory requirements for building gcc, or are they
still optional extras?

cheers,
  DaveK

RE: GCC 4.5.0 Status Report (2009-05-05)

[Ramana Radhakrishnan]

On Wed, May 6, 2009 at 4:10 PM, Mark Mitchell  wrote:
> Richard Earnshaw wrote:
>
>>> The slush that I requested last week has been lifted.  However, I have
>>> asked for relative calm until the cond-optab branch has been merged to
>>> mainline, which will hopefully occur on Friday, May 8th.
>>
>> As of this morning (UK), native bootstrap on ARM is still broken.
>
> Is this PR 39978?

I see what's been reported at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40031#c2 on gcc55 which appears
to be the same crash as what Julian's been seeing with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929#c12.


Ramana

> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Mark Mitchell
> Sent: 06 May 2009 16:10
> To: Richard Earnshaw
> Cc: gcc@gcc.gnu.org
> Subject: Re: GCC 4.5.0 Status Report (2009-05-05)
> 
> Richard Earnshaw wrote:
> 
> >> The slush that I requested last week has been lifted.  However, I
> have
> >> asked for relative calm until the cond-optab branch has been merged
> to
> >> mainline, which will hopefully occur on Friday, May 8th.
> >
> > As of this morning (UK), native bootstrap on ARM is still broken.
> 
> Is this PR 39978?
> 
> Thanks,
> 
> --
> Mark Mitchell
> CodeSourcery
> m...@codesourcery.com
> (650) 331-3385 x713

Re: GCC 4.4.1 Status Report (2009-05-05)

[Mark Mitchell]

Jack Howarth wrote:

>Shouldn't PR3 be higher than a P3 since it puts the compiler
> in an infinite loop and is a regression from gcc 4.3.x?

P3 means "nobody has reviewed it yet".  You filed it after I did my
issue review yesterday.

I've now upgraded it to P1.

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

Re: What precisely is the status of ppl/cloog anyway?

[Paolo Bonzini]

Dave Korn wrote:
>   Sorry to have to ask a dumb question, but it's not clear to me and I'm not
> having a lot of luck searching recent list posts:
> 
>   Are cloog and ppl now mandatory requirements for building gcc, or are they
> still optional extras?

Optional.

Paolo

RE: GCC 4.5.0 Status Report (2009-05-05)

[Michael Matz]

Hi,

On Wed, 6 May 2009, Ramana Radhakrishnan wrote:

> >>> The slush that I requested last week has been lifted.  However, I 
> >>> have asked for relative calm until the cond-optab branch has been 
> >>> merged to mainline, which will hopefully occur on Friday, May 8th.
> >>
> >> As of this morning (UK), native bootstrap on ARM is still broken.
> >
> > Is this PR 39978?
> 
> I see what's been reported at
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40031#c2 on gcc55 which appears
> to be the same crash as what Julian's been seeing with
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929#c12.

As written by Andrew Pinski already, you'll need a different method of 
emitting the load of the PIC register.  The ARM backend tries to emit that 
load as soon as it sees the PIC register being used (which is a slightly 
odd method as it magically emits instructions at a place unrelated to the 
instruction that currently are supposed to be emitted).

With expand from SSA this happens earlier than before, in fact so early 
that you don't have any basic block in RTL yet.  All are still in gimple 
form.  That's why the emission of RTL insns after the function entry is 
not going to work.  That's only possible if everything is transformed 
already.

The easiest solution would be to just make a note that you need the PIC 
register and then, when expanding the prologue emit the necessary 
instructions.  IMO that makes sense as PIC register setup usually is 
something the prologue does, like all the other register setups necessary.

So, in require_pic_register, do everything as before, except move the 
block emitting the load:
  start_sequence ();
  arm_load_pic_register (0UL);
  seq = get_insns ();
  end_sequence ();

into the prologue generator.


Ciao,
Michael.

RE: GCC 4.5.0 Status Report (2009-05-05)

[Richard Earnshaw]

On Wed, 2009-05-06 at 17:44 +0200, Michael Matz wrote:
> Hi,
> 
> On Wed, 6 May 2009, Ramana Radhakrishnan wrote:
> 
> > >>> The slush that I requested last week has been lifted.  However, I 
> > >>> have asked for relative calm until the cond-optab branch has been 
> > >>> merged to mainline, which will hopefully occur on Friday, May 8th.
> > >>
> > >> As of this morning (UK), native bootstrap on ARM is still broken.
> > >
> > > Is this PR 39978?
> > 
> > I see what's been reported at
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40031#c2 on gcc55 which appears
> > to be the same crash as what Julian's been seeing with
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929#c12.
> 
> As written by Andrew Pinski already, you'll need a different method of 
> emitting the load of the PIC register.  The ARM backend tries to emit that 
> load as soon as it sees the PIC register being used (which is a slightly 
> odd method as it magically emits instructions at a place unrelated to the 
> instruction that currently are supposed to be emitted).
> 
> With expand from SSA this happens earlier than before, in fact so early 
> that you don't have any basic block in RTL yet.  All are still in gimple 
> form.  That's why the emission of RTL insns after the function entry is 
> not going to work.  That's only possible if everything is transformed 
> already.
> 
> The easiest solution would be to just make a note that you need the PIC 
> register and then, when expanding the prologue emit the necessary 
> instructions.  IMO that makes sense as PIC register setup usually is 
> something the prologue does, like all the other register setups necessary.
> 

That won't work because the PIC register on ARM is a pseudo, so
generating it during prologue generation is too late.  It needs to exist
before data flow analysis starts on the RTL.

R.
-- 
Richard Earnshaw Email: richard.earns...@arm.com
Engineering Manager  Phone: +44 1223 400569 (Direct + VoiceMail)
OpenSource Tools Switchboard: +44 1223 400400
ARM Ltd  Fax: +44 1223 400410
110 Fulbourn Rd  Web: http://www.arm.com/
Cambridge, UK. CB1 9NJ

Re: GCC 4.5.0 Status Report (2009-05-05)

[Richard Guenther]

On Wed, May 6, 2009 at 5:46 PM, Richard Earnshaw  wrote:
> On Wed, 2009-05-06 at 17:44 +0200, Michael Matz wrote:
>> Hi,
>>
>> On Wed, 6 May 2009, Ramana Radhakrishnan wrote:
>>
>> > >>> The slush that I requested last week has been lifted.  However, I
>> > >>> have asked for relative calm until the cond-optab branch has been
>> > >>> merged to mainline, which will hopefully occur on Friday, May 8th.
>> > >>
>> > >> As of this morning (UK), native bootstrap on ARM is still broken.
>> > >
>> > > Is this PR 39978?
>> >
>> > I see what's been reported at
>> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40031#c2 on gcc55 which appears
>> > to be the same crash as what Julian's been seeing with
>> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929#c12.
>>
>> As written by Andrew Pinski already, you'll need a different method of
>> emitting the load of the PIC register.  The ARM backend tries to emit that
>> load as soon as it sees the PIC register being used (which is a slightly
>> odd method as it magically emits instructions at a place unrelated to the
>> instruction that currently are supposed to be emitted).
>>
>> With expand from SSA this happens earlier than before, in fact so early
>> that you don't have any basic block in RTL yet.  All are still in gimple
>> form.  That's why the emission of RTL insns after the function entry is
>> not going to work.  That's only possible if everything is transformed
>> already.
>>
>> The easiest solution would be to just make a note that you need the PIC
>> register and then, when expanding the prologue emit the necessary
>> instructions.  IMO that makes sense as PIC register setup usually is
>> something the prologue does, like all the other register setups necessary.
>>
>
> That won't work because the PIC register on ARM is a pseudo, so
> generating it during prologue generation is too late.  It needs to exist
> before data flow analysis starts on the RTL.

So you can generate it unconditionally and let DCE remove it if it turns
out not necessary?

Richard.

Re: GCC 4.5.0 Status Report (2009-05-05)

[Richard Earnshaw]

On Wed, 2009-05-06 at 17:49 +0200, Richard Guenther wrote:
> On Wed, May 6, 2009 at 5:46 PM, Richard Earnshaw  wrote:

> > That won't work because the PIC register on ARM is a pseudo, so
> > generating it during prologue generation is too late.  It needs to exist
> > before data flow analysis starts on the RTL.
> 
> So you can generate it unconditionally and let DCE remove it if it turns
> out not necessary?

Sorry, is that a question about the ARM back end as it worked before all
these changes went in, or how I might solve the problem now.  If the
latter, then generate what, where and when?

R.

Re: Bootstrap broken by ppl/cloog config problem: finds non-system/non-standard "/include" dir

[Tim Prince]

Dave Korn wrote:
> Tim Prince wrote:
>> Dave Korn wrote:
>>
>>>   Heh, I was just about to post that, only I was looking at $clooginc rather
>>> than $pplinc!  The same problem exists for both; I'm pretty sure we should
>>> fall back on $prefix if the --with option is empty.
>>>
>> When I bootstrapped gcc 4.5 on cygwin yesterday, configure recognized the
>> newly installed ppl, but not the cloog.  The bootstrap completed
>> successfully, and I'm not looking a gift horse in the mouth.
> 
>   You don't have a bogus /include dir, but I bet you'll find -I/include in 
> PPLINC.
> 
>   It would be interesting to know why it didn't spot cloog.  What's in your
> top-level $objdir/config.log?
> 

#include 

no such file
-I/include was set by configure.  As you say, there is something bogus here.

setup menu shows cloog installed in development category, but I can't find
any such include file.  Does this mean the cygwin distribution of cloog is
broken?

[JAVA,libtool] Big libjava is biiiig.

[Dave Korn]

Hi,

  As I'm sure everyone concerned is aware, libgcj is currently a bit of a
monolith.  Wighing in at 93M for a static archive, 73M for a shared library
(win32), it exports 82720 symbols.  Which is unfortunately 17184 more than the
system limit (64k) for a Windows DLL.

  The idea of breaking libjava up into smaller sublibraries has been mooted at
least a couple of times before (e.g. [*], [**]), but it's always raised issues
relating to backward compatibility.

  On windows we have no such back-compat issues to worry about; libjava has
not worked as a DLL in who-knows-how-long-if-ever.  I envisage that we could
very easily break it up into a bunch of separate (but presumably quite
inter-dependent) DLLs, and as a convenience we could provide a 'top-level'
libjava import library[***] that merged all the import libraries for the
individual DLLs.

  So I'm currently experimenting with a patch that adds a new option
"--enable-libgcj-sublibs" in libjava/configure.ac.  I may need to add a
dummy-link-and-relink stage to get the interdependencies working right, or I
might have to hack something in libtool, but the basic approach of adding a
bunch of extra libtool declarations based on $(filter)ing the full list of
dependencies from the complete libgcj_la_LIBADD definition seemed a reasonable
way to go:

+if BUILD_SUBLIBS
+libgcj_gnu_la_LIBADD = $(filter gnu/%.lo,$(libgcj_la_LIBADD)) -L$(here)/.libs
libgcj.la
+libgcj_java_la_LIBADD = $(filter java/%.lo,$(libgcj_la_LIBADD))
-L$(here)/.libs libgcj.la
+libgcj_javax_la_LIBADD = $(filter javax/%.lo,$(libgcj_la_LIBADD))
-L$(here)/.libs libgcj.la
+libgcj_misc_la_LIBADD = $(filter-out gnu/%.lo java/%.lo
javax/%.lo,$(libgcj_la_LIBADD)) -L$(here)/.libs libgcj.la
+endif

  Questions:

1)  Would this be a reasonable approach, specifically i) in adding a configure
option to cause sublibraries to be built, and ii) in using gmake's $(filter)
construct to crudely subdivide the libraries like this?

2)  Given that there's a bit of a logjam upstream, and not likely to be
another libtool release betwen now and the end of stage1, would it be
acceptable (in general) to hack on our in-tree libtool first and send patches
upstream second (thus still avoiding any potential future merge lossage)?


cheers,
  DaveK
-- 
[*]   - http://gcc.gnu.org/ml/gcc/2005-04/threads.html#01450
[**]  - http://gcc.gnu.org/ml/java-patches/2005-q1/threads.html#00225
[***] - For those not familiar, when windows executables import symbols from
DLLs, they do so by statically linking against a so-named 'import library'
that contains .data section stubs that build the structures that constitute
the final exe's table of imports as understood by the runtime loader.

RE: GCC 4.5.0 Status Report (2009-05-05)

[Michael Matz]

Hi,

On Wed, 6 May 2009, Richard Earnshaw wrote:

> > The easiest solution would be to just make a note that you need the 
> > PIC register and then, when expanding the prologue emit the necessary 
> > instructions.  IMO that makes sense as PIC register setup usually is 
> > something the prologue does, like all the other register setups 
> > necessary.
> 
> That won't work because the PIC register on ARM is a pseudo, so 
> generating it during prologue generation is too late.  It needs to exist 
> before data flow analysis starts on the RTL.

That's fine.  You can generate the pseudo, just not emit the code to load 
it until prologue generation starts.  Dataflow analysis starts only after 
everything is expanded to RTL anyway.  I'll try to cobble up a patch to 
show what I mean, but obviously I'm not very fluent with the ARM backend.


Ciao,
Michael.

RE: GCC 4.5.0 Status Report (2009-05-05)

[Richard Earnshaw]

On Wed, 2009-05-06 at 17:55 +0200, Michael Matz wrote:
> Hi,
> 
> On Wed, 6 May 2009, Richard Earnshaw wrote:
> 
> > > The easiest solution would be to just make a note that you need the 
> > > PIC register and then, when expanding the prologue emit the necessary 
> > > instructions.  IMO that makes sense as PIC register setup usually is 
> > > something the prologue does, like all the other register setups 
> > > necessary.
> > 
> > That won't work because the PIC register on ARM is a pseudo, so 
> > generating it during prologue generation is too late.  It needs to exist 
> > before data flow analysis starts on the RTL.
> 
> That's fine.  You can generate the pseudo, just not emit the code to load 
> it until prologue generation starts.  Dataflow analysis starts only after 
> everything is expanded to RTL anyway.  I'll try to cobble up a patch to 
> show what I mean, but obviously I'm not very fluent with the ARM backend.

Sorry, I'm confused.  Prologue generation happens after register
allocation (it can't be otherwise since we don't know which registers
have to be saved).  The PIC register has to appear as being live at the
start of the function so that the uses of it don't appear to be magic.

R.

Re: [JAVA,libtool] Big libjava is biiiig.

[Dave Korn]

[ Boh!  I allowed my emailer to autocomplete the address and misdirected this
to the -patches list.  Apologies for the reposting to gcc@, but it'll break
the threading if I just send a forward to j...@. ]


Hi,

  As I'm sure everyone concerned is aware, libgcj is currently a bit of a
monolith.  Wighing in at 93M for a static archive, 73M for a shared library
(win32), it exports 82720 symbols.  Which is unfortunately 17184 more than the
system limit (64k) for a Windows DLL.

  The idea of breaking libjava up into smaller sublibraries has been mooted at
least a couple of times before (e.g. [*], [**]), but it's always raised issues
relating to backward compatibility.

  On windows we have no such back-compat issues to worry about; libjava has
not worked as a DLL in who-knows-how-long-if-ever.  I envisage that we could
very easily break it up into a bunch of separate (but presumably quite
inter-dependent) DLLs, and as a convenience we could provide a 'top-level'
libjava import library[***] that merged all the import libraries for the
individual DLLs.

  So I'm currently experimenting with a patch that adds a new option
"--enable-libgcj-sublibs" in libjava/configure.ac.  I may need to add a
dummy-link-and-relink stage to get the interdependencies working right, or I
might have to hack something in libtool, but the basic approach of adding a
bunch of extra libtool declarations based on $(filter)ing the full list of
dependencies from the complete libgcj_la_LIBADD definition seemed a reasonable
way to go:

+if BUILD_SUBLIBS
+libgcj_gnu_la_LIBADD = $(filter gnu/%.lo,$(libgcj_la_LIBADD)) -L$(here)/.libs
libgcj.la
+libgcj_java_la_LIBADD = $(filter java/%.lo,$(libgcj_la_LIBADD))
-L$(here)/.libs libgcj.la
+libgcj_javax_la_LIBADD = $(filter javax/%.lo,$(libgcj_la_LIBADD))
-L$(here)/.libs libgcj.la
+libgcj_misc_la_LIBADD = $(filter-out gnu/%.lo java/%.lo
javax/%.lo,$(libgcj_la_LIBADD)) -L$(here)/.libs libgcj.la
+endif

  Questions:

1)  Would this be a reasonable approach, specifically i) in adding a configure
option to cause sublibraries to be built, and ii) in using gmake's $(filter)
construct to crudely subdivide the libraries like this?

2)  Given that there's a bit of a logjam upstream, and not likely to be
another libtool release betwen now and the end of stage1, would it be
acceptable (in general) to hack on our in-tree libtool first and send patches
upstream second (thus still avoiding any potential future merge lossage)?


cheers,
  DaveK
-- 
[*]   - http://gcc.gnu.org/ml/gcc/2005-04/threads.html#01450
[**]  - http://gcc.gnu.org/ml/java-patches/2005-q1/threads.html#00225
[***] - For those not familiar, when windows executables import symbols from
DLLs, they do so by statically linking against a so-named 'import library'
that contains .data section stubs that build the structures that constitute
the final exe's table of imports as understood by the runtime loader.

Re: Bootstrap broken by ppl/cloog config problem: finds non-system/non-standard "/include" dir

[Dave Korn]

Tim Prince wrote:

> 
> #include 
> 
> no such file
> -I/include was set by configure.  As you say, there is something bogus here.
> 
> setup menu shows cloog installed in development category, but I can't find
> any such include file.  Does this mean the cygwin distribution of cloog is
> broken?

  Did you make sure to get the -devel packages as well as the libs?  That's
the usual cause of this kind of problem.  I highly recommend the new version
of setup.exe that has a package-list search box :-)

cheers,
  DaveK

Re: What precisely is the status of ppl/cloog anyway?

[Dave Korn]

Paolo Bonzini wrote:
> Dave Korn wrote:
>>   Sorry to have to ask a dumb question, but it's not clear to me and I'm not
>> having a lot of luck searching recent list posts:
>>
>>   Are cloog and ppl now mandatory requirements for building gcc, or are they
>> still optional extras?
> 
> Optional.
> 
> Paolo

  Ah, so if there's no --with specified, and no in-tree version, we can't just
fall back on defaulting to $prefix, we need to actually do a proper search to
see if there's a cloog/ppl install there and decide whether to build it or
not.  Hmm, the version check will need to be skipped in that case.

  Or if no --with-cloog option is given, should the default be to assume
--with-cloog=no, rather than try and guess?

[ All said here also applies to --with-ppl pro rata. ]

cheers,

Setting ARM PIC register (Was: RE: GCC 4.5.0 Status Report (2009-05-05))

[Joern Rennecke]

Michael Matz wrote:
The easiest solution would be to just make a note that you need the  
PIC register and then, when expanding the prologue emit the  
necessary instructions.  IMO that makes sense as PIC register setup  
usually is something the prologue does, like all the other register  
setups necessary.


Richard Earnshaw:

That won't work because the PIC register on ARM is a pseudo, so
generating it during prologue generation is too late.  It needs to exist
before data flow analysis starts on the RTL.


How about emitting a set at each place the PIC register is needed,
and making sure that gcse will will common these sets where
appropriate?

Re: Setting ARM PIC register (Was: RE: GCC 4.5.0 Status Report (2009-05-05))

[Richard Earnshaw]

On Wed, 2009-05-06 at 12:03 -0400, Joern Rennecke wrote:
> Michael Matz wrote:
> >> The easiest solution would be to just make a note that you need the  
> >> PIC register and then, when expanding the prologue emit the  
> >> necessary instructions.  IMO that makes sense as PIC register setup  
> >> usually is something the prologue does, like all the other register  
> >> setups necessary.
> 
> Richard Earnshaw:
> > That won't work because the PIC register on ARM is a pseudo, so
> > generating it during prologue generation is too late.  It needs to exist
> > before data flow analysis starts on the RTL.
> 
> How about emitting a set at each place the PIC register is needed,
> and making sure that gcse will will common these sets where
> appropriate?

I'd rather not.  -O0 code is bad enough already; and this just makes
more work for the compiler.

R.

Re: Setting ARM PIC register (Was: RE: GCC 4.5.0 Status Report (2009-05-05))

[Mark Mitchell]

Richard Earnshaw wrote:

 The easiest solution would be to just make a note that you need the  
 PIC register and then, when expanding the prologue emit the  
 necessary instructions.  IMO that makes sense as PIC register setup  
 usually is something the prologue does, like all the other register  
 setups necessary.

>> How about emitting a set at each place the PIC register is needed,
>> and making sure that gcse will will common these sets where
>> appropriate?

> I'd rather not.  -O0 code is bad enough already; and this just makes
> more work for the compiler.

I agree.

What was the underlying fundamental change here that made the ARM
strategy stop working?

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

Re: Setting ARM PIC register (Was: RE: GCC 4.5.0 Status Report (2009-05-05))

[Michael Matz]

Hi,

On Wed, 6 May 2009, Joern Rennecke wrote:

> Richard Earnshaw:
> >That won't work because the PIC register on ARM is a pseudo, so
> >generating it during prologue generation is too late.  It needs to exist
> >before data flow analysis starts on the RTL.
> 
> How about emitting a set at each place the PIC register is needed,
> and making sure that gcse will will common these sets where
> appropriate?

Seems overly twisted to me.  Richard: no I was confused, you indeed can't 
wait until prologue emission, sorry.  Hmm, so we need some place to either 
remember the instruction sequence until expansion is done (or at least 
expansion of the basic blocks started) or alternatively a call into the 
targets when expansion is done.

I'm leaning towards the former.  Sorry I wasn't considering the problem 
careful enough and thought the solution was obvious when it wasn't :-)


Ciao,
Michael.

Re: [JAVA,libtool] Big libjava is biiiig.

[Ralf Wildenhues]

Hello Dave,

* Dave Korn wrote on Wed, May 06, 2009 at 06:09:05PM CEST:
> 
>   So I'm currently experimenting with a patch that adds a new option
> "--enable-libgcj-sublibs" in libjava/configure.ac.  I may need to add a
> dummy-link-and-relink stage to get the interdependencies working right, or I
> might have to hack something in libtool, but the basic approach of adding a
> bunch of extra libtool declarations based on $(filter)ing the full list of
> dependencies from the complete libgcj_la_LIBADD definition seemed a reasonable
> way to go:
> 
> +if BUILD_SUBLIBS
> +libgcj_gnu_la_LIBADD = $(filter gnu/%.lo,$(libgcj_la_LIBADD)) -L$(here)/.libs
> libgcj.la
> +libgcj_java_la_LIBADD = $(filter java/%.lo,$(libgcj_la_LIBADD))
> -L$(here)/.libs libgcj.la
> +libgcj_javax_la_LIBADD = $(filter javax/%.lo,$(libgcj_la_LIBADD))
> -L$(here)/.libs libgcj.la
> +libgcj_misc_la_LIBADD = $(filter-out gnu/%.lo java/%.lo
> javax/%.lo,$(libgcj_la_LIBADD)) -L$(here)/.libs libgcj.la
> +endif

I don't yet see why you would need any kind of libtool hacking.

I also don't see why the GCC tree *ever* uses -L$(something)/.libs in
directories where libtool is used.  Just specify in-tree library
dependencies as 'libgcj.la' and automake and libtool will do The Right
Thing.  You adding an explicit -L.libs can only lead to installed .la
files retaining paths to build tree locations.

> 1)  Would this be a reasonable approach, specifically i) in adding a configure
> option to cause sublibraries to be built, and ii) in using gmake's $(filter)
> construct to crudely subdivide the libraries like this?

You are aware of the fact that it is part of the ABI in which of the
linked DLLs a given symbol was found, and any shuffling of that later
will break that ABI?

You also have to ensure that the sub libraries are self-contained, or at
least their interdependencies form a directed non-cyclic graph (or you
will need very ugly hacks on w32).

> 2)  Given that there's a bit of a logjam upstream, and not likely to be
> another libtool release betwen now and the end of stage1,

What makes you think so?  There is a backlog of some patches, but that
doesn't mean
- important patches won't go in,
- GCC can't update to a newer unreleased Libtool version; it has done
  this several times, and it does not require the GCC developers to
  upgrade their build tools.

> would it be
> acceptable (in general) to hack on our in-tree libtool first and send patches
> upstream second (thus still avoiding any potential future merge lossage)?

I don't see a reason for that in your message.  Do you have other
reasons for suggesting this?

Cheers,
Ralf

Issues with testsuite on constant pointer arithmetics

[Stelian Pop]

Hi all,

I'm reaching the final stages of my port of gcc to a custom microcontroller
and at this point real world examples seem to work, I only have a few dozen
tests of the testsuite which give me trouble.

All those tests involve arithmetics on pointers (or labels), and I'm not
sure if the tests show a real problem in my port or if the tests are not
relevant given the specifics of my microcontroller (size of pointers not
being a "long", "int" not being a natural register etc).

Before going further, a bit of background: this microcontroller is special
in that it can be configured to work in 4 different modes: 8 bit "wide",
16 bit, 16 bit "wide" and 32 bits.

The code below speaks for itself:

#define BITS_PER_UNIT   8
#define UNITS_PER_WORD  (TARGET_8W ? 1 : (TARGET_16 || TARGET_16W) ? 2 
: 4)
#define SHORT_TYPE_SIZE 16
#define INT_TYPE_SIZE   16
#define LONG_TYPE_SIZE  32
#define LONG_LONG_TYPE_SIZE 64
#define FLOAT_TYPE_SIZE 32
#define DOUBLE_TYPE_SIZE64
#define LONG_DOUBLE_TYPE_SIZE   64
#define SIZE_TYPE   "unsigned int"
#define PTRDIFF_TYPE_SIZE   ((TARGET_8W || TARGET_16) ? "int" : "long int")
#define Pmode   ((TARGET_8W || TARGET_16) ? HImode : SImode)
#define POINTER_SIZE((TARGET_8W || TARGET_16) ? 16 : 32)

Now, back to my problems: the following tests fail with
"error: initializer element is not constant":

on TARGET_8W and TARGET_16:
920928-1.c:
1 struct{int c;}v;
2 static long i=((char*)&(v.c)-(char*)&v)
930326-1.c:
1 struct
2 {
3   char a, b, f[3];
4 } s;
5
6 long i = s.f-&s.b;
labels-3.c:
 9 int foo (int a)
10 {
11   static const short ar[] = { &&l1 - &&l1, &&l2 - &&l1 };
12   void *p = &&l1 + ar[a];
13   goto *p;
14  l1:
15   return 1;
16  l2:
17   return 2;
18 }

on TARGET_16W and TARGET_32: 2004-1.c:
1 extern void _text;
2 static __SIZE_TYPE__ x = (__SIZE_TYPE__) &_text - 0x1000L - 1;

Are those tests expected to fail on my port or is that something I've
obviously done wrong ?

Thanks.

Stelian.
-- 
Stelian Pop 

Re: Setting ARM PIC register (Was: RE: GCC 4.5.0 Status Report (2009-05-05))

[Paolo Bonzini]

Michael Matz wrote:
> Hi,
> 
> On Wed, 6 May 2009, Joern Rennecke wrote:
> 
>> Richard Earnshaw:
>>> That won't work because the PIC register on ARM is a pseudo, so
>>> generating it during prologue generation is too late.  It needs to exist
>>> before data flow analysis starts on the RTL.
>> How about emitting a set at each place the PIC register is needed,
>> and making sure that gcse will will common these sets where
>> appropriate?
> 
> Seems overly twisted to me.  Richard: no I was confused, you indeed can't 
> wait until prologue emission, sorry.  Hmm, so we need some place to either 
> remember the instruction sequence until expansion is done (or at least 
> expansion of the basic blocks started) or alternatively a call into the 
> targets when expansion is done.
> 
> I'm leaning towards the former.  Sorry I wasn't considering the problem 
> careful enough and thought the solution was obvious when it wasn't :-)

Looks like something like this could be useful to avoid code
duplications in the backends:

void
emit_insn_at_top (rtx insn)
{
  rtx scan;

  gcc_assert (current_ir_type () != IR_RTL_CFGLAYOUT);
  push_topmost_sequence ();
  scan = get_insns ();
  while (NEXT_INSN (scan) && !INSN_P (NEXT_INSN (scan)))
scan = NEXT_INSN (scan);

  emit_insn_after (insn, scan);
  pop_topmost_sequence ();
}

mips16_gp_pseudo_reg () in config/mips/mips.c is already using something
like that.

Paolo

Re: Setting ARM PIC register (Was: RE: GCC 4.5.0 Status Report (2009-05-05))

[Michael Matz]

Hi,

On Wed, 6 May 2009, Mark Mitchell wrote:

> >> How about emitting a set at each place the PIC register is needed, 
> >> and making sure that gcse will will common these sets where 
> >> appropriate?
> 
> > I'd rather not.  -O0 code is bad enough already; and this just makes 
> > more work for the compiler.
> 
> I agree.
> 
> What was the underlying fundamental change here that made the ARM 
> strategy stop working?

expansion of PHI nodes has to take place when the tree hooks are still 
active.  While those are active the basic blocks can't yet be expanded 
from GIMPLE to RTL (and more generally you can't emit RTL instructions 
into what later becomes the normal RTL insn stream).  But expansion of PHI 
nodes geneates RTL move instructions, which can trigger the need of PIC 
registers.  So that load can't be emitted where it currently is tried to 
emit (namely entry_of_function(), which points to a basic block that 
still is in GIMPLE form at this time).

I'll have to make a new place for such instructions that can be used for 
storing away instructions for the start of function until they can be 
emitted into the normal insn stream.


Ciao,
Michael.

Re: [JAVA,libtool] Big libjava is biiiig.

[David Daney]

Ralf Wildenhues wrote:

Hello Dave,

* Dave Korn wrote on Wed, May 06, 2009 at 06:09:05PM CEST:

[...]

1)  Would this be a reasonable approach, specifically i) in adding a configure
option to cause sublibraries to be built, and ii) in using gmake's $(filter)
construct to crudely subdivide the libraries like this?


You are aware of the fact that it is part of the ABI in which of the
linked DLLs a given symbol was found, and any shuffling of that later
will break that ABI?

You also have to ensure that the sub libraries are self-contained, or at
least their interdependencies form a directed non-cyclic graph (or you
will need very ugly hacks on w32).



Unfortunately it may not be a simple task to find a suitably large set 
of packages that satisfy this 'directed non-cyclic graph' criterion.


I might suggest looking at grouping a bunch of various protocol handlers 
together that are all accessed via mechanisms like the URLConnection, 
and the various crypto implementations.



David Daney

Re: Setting ARM PIC register (Was: RE: GCC 4.5.0 Status Report (2009-05-05))

[Michael Matz]

Hi,

On Wed, 6 May 2009, Paolo Bonzini wrote:

> Looks like something like this could be useful to avoid code 
> duplications in the backends:
> 
> void
> emit_insn_at_top (rtx insn)
> {
>   rtx scan;
> 
>   gcc_assert (current_ir_type () != IR_RTL_CFGLAYOUT);
>   push_topmost_sequence ();
>   scan = get_insns ();
>   while (NEXT_INSN (scan) && !INSN_P (NEXT_INSN (scan)))
> scan = NEXT_INSN (scan);
> 
>   emit_insn_after (insn, scan);
>   pop_topmost_sequence ();
> }
> 
> mips16_gp_pseudo_reg () in config/mips/mips.c is already using something
> like that.

Or like alpha:

  insert_insn_on_edge (seq, single_succ_edge (ENTRY_BLOCK_PTR));

That's not for the PIC load, but should work okay as expand from SSA 
commits instructions on edges later.  That actually seems even nicer IMO, 
if it works...


Ciao,
Michael.

Re: [JAVA,libtool] Big libjava is biiiig.

[Richard Guenther]

On Wed, May 6, 2009 at 6:26 PM, David Daney  wrote:
> Ralf Wildenhues wrote:
>>
>> Hello Dave,
>>
>> * Dave Korn wrote on Wed, May 06, 2009 at 06:09:05PM CEST:
>
> [...]
>>>
>>> 1)  Would this be a reasonable approach, specifically i) in adding a
>>> configure
>>> option to cause sublibraries to be built, and ii) in using gmake's
>>> $(filter)
>>> construct to crudely subdivide the libraries like this?
>>
>> You are aware of the fact that it is part of the ABI in which of the
>> linked DLLs a given symbol was found, and any shuffling of that later
>> will break that ABI?
>>
>> You also have to ensure that the sub libraries are self-contained, or at
>> least their interdependencies form a directed non-cyclic graph (or you
>> will need very ugly hacks on w32).
>>
>
> Unfortunately it may not be a simple task to find a suitably large set of
> packages that satisfy this 'directed non-cyclic graph' criterion.
>
> I might suggest looking at grouping a bunch of various protocol handlers
> together that are all accessed via mechanisms like the URLConnection, and
> the various crypto implementations.

Is it not that maybe most of the exported symbols are not necessary and can
be made hidden?

Richard.

Re: Setting ARM PIC register (Was: RE: GCC 4.5.0 Status Report (2009-05-05))

[Richard Earnshaw]

On Wed, 2009-05-06 at 18:29 +0200, Michael Matz wrote:
> Hi,
> 
> On Wed, 6 May 2009, Paolo Bonzini wrote:
> 
> > Looks like something like this could be useful to avoid code 
> > duplications in the backends:
> > 
> > void
> > emit_insn_at_top (rtx insn)
> > {
> >   rtx scan;
> > 
> >   gcc_assert (current_ir_type () != IR_RTL_CFGLAYOUT);
> >   push_topmost_sequence ();
> >   scan = get_insns ();
> >   while (NEXT_INSN (scan) && !INSN_P (NEXT_INSN (scan)))
> > scan = NEXT_INSN (scan);
> > 
> >   emit_insn_after (insn, scan);
> >   pop_topmost_sequence ();
> > }
> > 
> > mips16_gp_pseudo_reg () in config/mips/mips.c is already using something
> > like that.
> 
> Or like alpha:
> 
>   insert_insn_on_edge (seq, single_succ_edge (ENTRY_BLOCK_PTR));
> 
> That's not for the PIC load, but should work okay as expand from SSA 
> commits instructions on edges later.  That actually seems even nicer IMO, 
> if it works...

There's already emit_insn_at_entry in cfgrtl.c.  Would that work?

R.

Re: [JAVA,libtool] Big libjava is biiiig.

[Andrew Haley]

Dave Korn wrote:

> 1)  Would this be a reasonable approach, specifically i) in adding a configure
> option to cause sublibraries to be built, and ii) in using gmake's $(filter)
> construct to crudely subdivide the libraries like this?

At program startup the first library would be loaded, it would load
the next, and so on.  There are a few parts of libgcj that are truly
independent, but I suspect that you'd always load almost all of it.
So, you'd have longer startup time for loading all those files.


With regard to GNU libc platforms:

You'd no longer be able to make so much use of fast calls between
functions in the same library; you'd have to go via the PLT.

Also, dl_iterate_phdr() is used a great deal (for finding exception
regions, garbage collection, etc.) and it linearly scans the libraries
that are loaded.  So, the more libraries you have loaded, the slower
it goes.

Now, I don't know how much of these characteristics are shared by
Windows, but I imagine some of them are.

So, I suspect your best bet would be to split libgcj into core and
non-core libraries and not slice much more thinly than that.  I can
advise you what is core and what isn't.

Andrew.

Re: [JAVA,libtool] Big libjava is biiiig.

[Andrew Haley]

Richard Guenther wrote:

> Is it not that maybe most of the exported symbols are not necessary and can
> be made hidden?

We already did that.  This is the number of symbols in the public API.

Andrew.

Re: Setting ARM PIC register (Was: RE: GCC 4.5.0 Status Report (2009-05-05))

[Michael Matz]

Hi,

On Wed, 6 May 2009, Richard Earnshaw wrote:

> > Or like alpha:
> > 
> >   insert_insn_on_edge (seq, single_succ_edge (ENTRY_BLOCK_PTR));
> > 
> > That's not for the PIC load, but should work okay as expand from SSA 
> > commits instructions on edges later.  That actually seems even nicer 
> > IMO, if it works...
> 
> There's already emit_insn_at_entry in cfgrtl.c.  Would that work?

Unfortunately not.  That one also wants to immediately commit the just 
inserted instructions, which doesn't work during the transition phase from 
GIMPLE to RTL.  But just queuing them should be fine.


Ciao,
Michael.

Re: [JAVA,libtool] Big libjava is biiiig.

[Dave Korn]

Andrew Haley wrote:
> Dave Korn wrote:
> 
>> 1)  Would this be a reasonable approach, specifically i) in adding a 
>> configure
>> option to cause sublibraries to be built, and ii) in using gmake's $(filter)
>> construct to crudely subdivide the libraries like this?
> 
> At program startup the first library would be loaded, it would load
> the next, and so on.  There are a few parts of libgcj that are truly
> independent, but I suspect that you'd always load almost all of it.
> So, you'd have longer startup time for loading all those files.

  Compared to a single DLL that is unusably malformed because it exceeds
system limits, that's still an improvement :)

> With regard to GNU libc platforms:
> 
> You'd no longer be able to make so much use of fast calls between
> functions in the same library; you'd have to go via the PLT.
> 
> Also, dl_iterate_phdr() is used a great deal (for finding exception
> regions, garbage collection, etc.) and it linearly scans the libraries
> that are loaded.  So, the more libraries you have loaded, the slower
> it goes.
> 
> Now, I don't know how much of these characteristics are shared by
> Windows, but I imagine some of them are.

  Yes, the inter-library calls would have to be dllimports and go through
stubs (one extra indirect branch).  I don't know how dl_iterate_phdr works on
win32 but I imagine that it's also linear in the number of libs.

> So, I suspect your best bet would be to split libgcj into core and
> non-core libraries and not slice much more thinly than that.  I can
> advise you what is core and what isn't.

  Please do, I'll happily try that approach since it might significantly
simplify my inter-dependences problems.

cheers,
  DaveK

Re: [JAVA,libtool] Big libjava is biiiig.

[Dave Korn]

Ralf Wildenhues wrote:
> Hello Dave,

  Hiya Ralf,

> I don't yet see why you would need any kind of libtool hacking.

  Because of this:

> You also have to ensure that the sub libraries are self-contained, or at
> least their interdependencies form a directed non-cyclic graph (or you
> will need very ugly hacks on w32).

  I fully expect there to be cyclic interdependencies, which I could resolve
by building import libs first with dlltool.  I'm not sure yet whether to do
this in libtool, but it occurred to me as one possibility.  Another approach
would have been to do it in the Makefile, by first building the sub-DLLs all
linked against the monolithic libjava DLL, then rebuilding them all but this
time linking against their own import libs generated in the previous step; it
occurred to me that even this might need a little help from libtool.

> I also don't see why the GCC tree *ever* uses -L$(something)/.libs in
> directories where libtool is used.  Just specify in-tree library
> dependencies as 'libgcj.la' and automake and libtool will do The Right
> Thing.  You adding an explicit -L.libs can only lead to installed .la
> files retaining paths to build tree locations.

  Right, I'll try it; I have no idea why it's like that, I just cut and pasted
existing examples without fully understanding.  The comment on the bit I cut
and pasted reads:

## We don't explicitly link in the libraries we need; libgcj.la brings
## in all dependencies.  We need the -L so that gcj can find libgcj
## with `-lgcj', but it must come first, otherwise the -L flags
## brought in from libgcj.la would cause the install directories to be
## searched before the build-tree ones, and we'd get errors because of
## different libraries with the same SONAME from picky linkers such as
## Solaris'.  FIXME: should be _libs on some systems.
jv_convert_LDADD = -L$(here)/.libs libgcj.la

>> 1)  Would this be a reasonable approach, specifically i) in adding a 
>> configure
>> option to cause sublibraries to be built, and ii) in using gmake's $(filter)
>> construct to crudely subdivide the libraries like this?
> 
> You are aware of the fact that it is part of the ABI in which of the
> linked DLLs a given symbol was found, and any shuffling of that later
> will break that ABI?

  Yep.  I guess I didn't think that the top-level hierarchy might be
rearranged, or objects moved from one part of the sub-tree to another; is that
likely?

>> 2)  Given that there's a bit of a logjam upstream, and not likely to be
>> another libtool release betwen now and the end of stage1,
> 
> What makes you think so?  There is a backlog of some patches, but that
> doesn't mean
> - important patches won't go in,

  Oh, great.  I didn't want to /rely/ on being able to draw on your time when
you've already got a lot to deal with, but in combination with this ...

> - GCC can't update to a newer unreleased Libtool version; it has done
>   this several times, and it does not require the GCC developers to
>   upgrade their build tools.

  (which I didn't know this was standard practice) that makes it seem far more
possible to do things the right way round.

> I don't see a reason for that in your message.  Do you have other
> reasons for suggesting this?

  Nope, I was only planning ahead against the contingency of it either not
being practicable or convenient upstream, or there being subtle problems that
transpire with doing an entire libtool update/merge.

cheers,
  DaveK

Re: Setting ARM PIC register (Was: RE: GCC 4.5.0 Status Report (2009-05-05))

[Michael Matz]

Hi,

On Wed, 6 May 2009, Michael Matz wrote:

> > There's already emit_insn_at_entry in cfgrtl.c.  Would that work?
> 
> Unfortunately not.  That one also wants to immediately commit the just 
> inserted instructions, which doesn't work during the transition phase 
> from GIMPLE to RTL.  But just queuing them should be fine.

I.e. like so.  It fixes the testcase and to my untrained eye the output 
looks correct (at least there seems to be loads from something .PIC 
related :) ).  But better testing would be appreciated.


Ciao,
Michael.
-- 
Index: config/arm/arm.c
===
--- config/arm/arm.c(revision 147187)
+++ config/arm/arm.c(working copy)
@@ -3596,7 +3596,7 @@ require_pic_register (void)
 
  seq = get_insns ();
  end_sequence ();
- emit_insn_after (seq, entry_of_function ());
+ insert_insn_on_edge (seq, single_succ_edge (ENTRY_BLOCK_PTR));
}
}
 }

Re: [JAVA,libtool] Big libjava is biiiig.

[Dave Korn]

Bryce McKinlay wrote:

> If you're going to go to all this trouble, why not consider making libgcj
> compilable with the BC-ABI. 

  Well, in my case, because I have no idea what that involves or implies.  I
was hoping to find a solution that I can get in during this current stage1 and
it not be the only thing I spend all of stage1 doing.

  From your disclaimer, it sounds like this might be a slightly longer-term
project?

cheers,
  DaveK

Re: [JAVA,libtool] Big libjava is biiiig.

[Andrew Haley]

Dave Korn wrote:
> Andrew Haley wrote:
>> Dave Korn wrote:
>>
>>> 1)  Would this be a reasonable approach, specifically i) in adding a 
>>> configure
>>> option to cause sublibraries to be built, and ii) in using gmake's $(filter)
>>> construct to crudely subdivide the libraries like this?
>> At program startup the first library would be loaded, it would load
>> the next, and so on.  There are a few parts of libgcj that are truly
>> independent, but I suspect that you'd always load almost all of it.
>> So, you'd have longer startup time for loading all those files.
> 
>   Compared to a single DLL that is unusably malformed because it exceeds
> system limits, that's still an improvement :)
> 
>> With regard to GNU libc platforms:
>>
>> You'd no longer be able to make so much use of fast calls between
>> functions in the same library; you'd have to go via the PLT.
>>
>> Also, dl_iterate_phdr() is used a great deal (for finding exception
>> regions, garbage collection, etc.) and it linearly scans the libraries
>> that are loaded.  So, the more libraries you have loaded, the slower
>> it goes.
>>
>> Now, I don't know how much of these characteristics are shared by
>> Windows, but I imagine some of them are.
> 
>   Yes, the inter-library calls would have to be dllimports and go through
> stubs (one extra indirect branch).  I don't know how dl_iterate_phdr works on
> win32 but I imagine that it's also linear in the number of libs.
> 
>> So, I suspect your best bet would be to split libgcj into core and
>> non-core libraries and not slice much more thinly than that.  I can
>> advise you what is core and what isn't.
> 
>   Please do, I'll happily try that approach since it might significantly
> simplify my inter-dependences problems.

Here's a starter list of non-core packages:

gnu/CORBA
gnu/classpath/management
gnu/java/awt/dnd/peer/gtk
gnu/java/awt/dnd/peer/gtk
gnu/java/awt/peer/gtk
gnu/java/awt/peer/qt
gnu/java/awt/peer/x
gnu/java/beans
gnu/java/lang/managementheaders
gnu/java/math
gnu/java/util/prefs/gconf
gnu/java/util/prefs/gconf
gnu/javax/management
gnu/javax/rmi
gnu/javax/sound/midi
gnu/javax/sound/sampled/gstreamer) ignore
gnu/xml/aelfred2
gnu/xml/dom
gnu/xml/libxmlj
gnu/xml/pipeline
gnu/xml/stream
gnu/xml/transform
gnu/xml/util
gnu/xml/validation
gnu/xml/xpath
java/lang/management
javax/imageio
javax/rmi
javax/xml
org/omg/CORBA
org/omg/CORBA_2_3
org/omg/CosNaming
org/omg/Dynamic
org/omg/DynamicAny
org/omg/IOP
org/omg/Messaging
org/omg/PortableInterceptor
org/omg/PortableServer
org/omg/SendingContext
org/omg/stub
org/relaxng
org/w3c
org/xml

Andrew.

archives broken?

[Paolo Bonzini]

It looks like a bunch of missing from
http://gcc.gnu.org/ml/gcc-patches/2004-02/ are missing.  Anybody knows
what could be the cause?

Paolo

[PATCH] Fix bootstrap when no --with-ppl/--with-cloog [was Re: What precisely is the status of ppl/cloog anyway?]

[Dave Korn]

Dave Korn wrote:
> Paolo Bonzini wrote:
>> Dave Korn wrote:
>>>   Sorry to have to ask a dumb question, but it's not clear to me and I'm not
>>> having a lot of luck searching recent list posts:
>>>
>>>   Are cloog and ppl now mandatory requirements for building gcc, or are they
>>> still optional extras?
>> Optional.

>   Or if no --with-cloog option is given, should the default be to assume
> --with-cloog=no, rather than try and guess?

  Given that they are optional, I think this option made sense; they shouldn't
even come into play unless the user explicitly asks for them.

> [ All said here also applies to --with-ppl pro rata. ]

  So I'm currently testing the attached.

ChangeLog

* configure.ac ($with_ppl):  Default to no if not supplied.
($with_cloog):  Likewise.

  Assuming it passes bootstrap, ok for HEAD?

cheers,
  DaveK

Index: configure.ac
===
--- configure.ac	(revision 147098)
+++ configure.ac	(working copy)
@@ -1344,7 +1344,7 @@
 AC_ARG_WITH(ppl_lib, [  --with-ppl-lib=PATH Specify the directory for the installed PPL library])
 
 case $with_ppl in 
-  no)
+  no|"")
 ppllibs=
 ;;
   *)
@@ -1399,7 +1399,7 @@
 AC_ARG_WITH(cloog_lib, [  --with-cloog-lib=PATH   Specify the directory for the installed CLooG library])
 
 case $with_cloog in 
-  no)
+  no|"")
 clooglibs=
 clooginc=
 ;;

Re: archives broken?

[Dave Korn]

Paolo Bonzini wrote:
> It looks like a bunch of missing from
> http://gcc.gnu.org/ml/gcc-patches/2004-02/ are missing.  Anybody knows
> what could be the cause?
> 
> Paolo
> 

  When was the great sourceware.org drive crash?

cheers,
  DaveK

Re: archives broken?

[Manuel López-Ibáñez]

2009/5/6 Paolo Bonzini :
> It looks like a bunch of missing from
> http://gcc.gnu.org/ml/gcc-patches/2004-02/ are missing.  Anybody knows
> what could be the cause?

Relevant PRs 20336, 20588, 3119.

Cheers,

Manuel.

Re: archives broken?

[Andrew Haley]

Manuel López-Ibáñez wrote:
> 2009/5/6 Paolo Bonzini :
>> It looks like a bunch of missing from
>> http://gcc.gnu.org/ml/gcc-patches/2004-02/ are missing.  Anybody knows
>> what could be the cause?
> 
> Relevant PRs 20336, 20588, 3119.

I'm pretty sure I have a complete set of the messages.

Andrew.

Re: Setting ARM PIC register (Was: RE: GCC 4.5.0 Status Report (2009-05-05))

[Eric Botcazou]

> I.e. like so.  It fixes the testcase and to my untrained eye the output
> looks correct (at least there seems to be loads from something .PIC
> related :) ).  But better testing would be appreciated.

A comment explaining who will call commit_edge_insertions like in the Alpha 
case would be nice I think.

-- 
Eric Botcazou

Re: [RFC] Get rid of awkward semantics for subtypes

[Richard Guenther]

On Fri, Apr 10, 2009 at 12:03 AM, Eric Botcazou  wrote:
> Hi,
>
> we're almost ready to get rid of the awkward semantics that is implemented in
> the middle-end and the optimizers for subtypes (INTEGER_TYPEs with a non-null
> TREE_TYPE); this should overall simplify things, make the support for invalid
> values in Ada more robust and expose more optimization opportunities.
>
> Patches have already been written and tested (I've attached the non-gigi part
> we currently use, preparatory patches are required for gigi first).  All the
> subtypes are given maximal bounds for their precision, except for TYPE_DOMAIN
> of array types like in C, and thus become first class citizens.  This makes
> it possible to eliminate code in gigi, the gimplifier, the loop optimizer,
> the VRP pass, etc. needed to specifically support their special semantics.
>
> This in turn means that the gimplification will eliminate most of the casts
> between subtypes and base types, making the optimizers more effective.  The
> exception will be the VRP pass, most notably when checks are off in Ada, so
> we'll need to be able to drive VRP differently from gigi.
>
> Comments/suggestions welcome.
>
>
>        * fold-const.c (fold_truth_not_expr) : Do not strip
>        it if the destination type is boolean.
>        * tree-chrec.c (avoid_arithmetics_in_type_p): Delete.
>        (convert_affine_scev): Remove call to above function.
>        (chrec_convert_aggressive): Likewise.
>        * tree-scalar-evolution.c (follow_ssa_edge_expr) :
>        Propagate the type of the first operand.
>        (follow_ssa_edge_in_rhs) : Likewise
>        * tree-ssa.c (useless_type_conversion_p_1): Do not specifically return
>        false for conversions involving subtypes.
>        * tree-vrp.c (vrp_val_max): Do not get to the base type.
>        (vrp_val_min): Likewise.
>        (needs_overflow_infinity): Do not special-case subtypes.
>        (extract_range_from_unary_expr): Do not use the base types.

What is missing to go forward with this plan?  I am hitting type consistency
problems again while trying to fix PR3 ... :/

Richard.

Re: [RFC] Get rid of awkward semantics for subtypes

[Eric Botcazou]

> What is missing to go forward with this plan?

Almost nothing, but I'm benchmarking the change and I'm seeing degradation in 
some cases because move IVs are exposed and so are -fivopts' warts.

> I am hitting type consistency problems again while trying to fix PR3 ...

Ideally this should be independent.

-- 
Eric Botcazou

Re: [RFC] Get rid of awkward semantics for subtypes

[Richard Guenther]

On Wed, May 6, 2009 at 9:04 PM, Eric Botcazou  wrote:
>> What is missing to go forward with this plan?
>
> Almost nothing, but I'm benchmarking the change and I'm seeing degradation in
> some cases because move IVs are exposed and so are -fivopts' warts.
>
>> I am hitting type consistency problems again while trying to fix PR3 ...
>
> Ideally this should be independent.

Yes.  But we have invalid IL before PRE (arithmetic in subtypes) and PRE manages
to expose this fact in a way that type checking complains ... :/  I
have now tested
4 variants of the obvious fix and all fail one way or the other
because of this issue.
For 4.4 it's easier because type checking won't notice it there ;)

Richard.

Re: Issues with testsuite on constant pointer arithmetics

[Ian Lance Taylor]

Stelian Pop  writes:

> on TARGET_8W and TARGET_16:
> 920928-1.c:
>   1 struct{int c;}v;
>   2 static long i=((char*)&(v.c)-(char*)&v)
> 930326-1.c:
>   1 struct
>   2 {
>   3   char a, b, f[3];
>   4 } s;
>   5
>   6 long i = s.f-&s.b;
> labels-3.c:
>9 int foo (int a)
>   10 {
>   11   static const short ar[] = { &&l1 - &&l1, &&l2 - &&l1 };
>   12   void *p = &&l1 + ar[a];
>   13   goto *p;
>   14  l1:
>   15   return 1;
>   16  l2:
>   17   return 2;
>   18 }
>
> on TARGET_16W and TARGET_32: 2004-1.c:
>   1 extern void _text;
>   2 static __SIZE_TYPE__ x = (__SIZE_TYPE__) &_text - 0x1000L - 1;
>
> Are those tests expected to fail on my port or is that something I've
> obviously done wrong ?

I don't see any particular reason that these tests should fail.  I
hasten to add that these tests are not very important and it is unlikely
that a failure to pass these tests will affect any actual program.

You didn't mention which version of gcc you are based on.  Do you have
these patches?  If not, that may be your problem.

2008-09-04  Ian Lance Taylor  

* varasm.c (narrowing_initializer_constant_valid_p): New
static function.
(initializer_constant_valid_p): Call it.

2008-09-19  Ian Lance Taylor  

* varasm.c (narrowing_initializer_constant_valid_p): Return
NULL_TREE if ENDTYPE is not an integer.


Even if you do have those patches, that code is where I would start
looking.  Your initializers are constant, but something in that area
thinks that they are not constant.

Ian

Re: archives broken?

[Joseph S. Myers]

On Wed, 6 May 2009, Andrew Haley wrote:

> Manuel López-Ibáñez wrote:
> > 2009/5/6 Paolo Bonzini :
> >> It looks like a bunch of missing from
> >> http://gcc.gnu.org/ml/gcc-patches/2004-02/ are missing.  Anybody knows
> >> what could be the cause?
> > 
> > Relevant PRs 20336, 20588, 3119.
> 
> I'm pretty sure I have a complete set of the messages.

The conclusion in the overseers discussion referenced in 20588 was that 
the files are present in the txt/ forms and what's needed is for someone 
with the right access to create/modify and run the right script to 
regenerate them.

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

Re: archives broken?

[Ian Lance Taylor]

Andrew Haley  writes:

> Manuel López-Ibáñez wrote:
>> 2009/5/6 Paolo Bonzini :
>>> It looks like a bunch of missing from
>>> http://gcc.gnu.org/ml/gcc-patches/2004-02/ are missing.  Anybody knows
>>> what could be the cause?
>> 
>> Relevant PRs 20336, 20588, 3119.
>
> I'm pretty sure I have a complete set of the messages.

I believe that we have a complete set of messages too.  Fixing the web
pages takes somebody with the time and energy to figure out what is
required.  The mailing list archives are built using mhonarc.  Any
volunteers?

Ian

Re: [RFC] Get rid of awkward semantics for subtypes

[Richard Guenther]

On Wed, May 6, 2009 at 9:17 PM, Richard Guenther
 wrote:
> On Wed, May 6, 2009 at 9:04 PM, Eric Botcazou  wrote:
>>> What is missing to go forward with this plan?
>>
>> Almost nothing, but I'm benchmarking the change and I'm seeing degradation in
>> some cases because move IVs are exposed and so are -fivopts' warts.
>>
>>> I am hitting type consistency problems again while trying to fix PR3 ...
>>
>> Ideally this should be independent.
>
> Yes.  But we have invalid IL before PRE (arithmetic in subtypes) and PRE 
> manages
> to expose this fact in a way that type checking complains ... :/  I
> have now tested
> 4 variants of the obvious fix and all fail one way or the other
> because of this issue.
> For 4.4 it's easier because type checking won't notice it there ;)

I wonder for example about

 
unit size 
align 32 symtab 1993070176 alias set -1 canonical type
0x2b1d76cbe540 precision 32 min  max 
pointer_to_this >
sizes-gimplified asm_written public visited SI size  unit size 
align 32 symtab 2001622336 alias set 0 canonical type
0x2b1d770a3300 precision 32 min  max  RM size

chain >

it seems the base type here is exactly the same as the subtype?

In the particular case IVOPTs is creating arithmetic in that type.  Or
maybe fold.

Richard.

Re: Issues with testsuite on constant pointer arithmetics

[Stelian Pop]

On Wed, May 06, 2009 at 12:19:55PM -0700, Ian Lance Taylor wrote:

> Stelian Pop  writes:
> 
> > on TARGET_8W and TARGET_16:
> > 920928-1.c:
> > 1 struct{int c;}v;
> > 2 static long i=((char*)&(v.c)-(char*)&v)
> > 930326-1.c:
> > 1 struct
> > 2 {
> > 3   char a, b, f[3];
> > 4 } s;
> > 5
> > 6 long i = s.f-&s.b;
> > labels-3.c:
> >  9 int foo (int a)
> > 10 {
> > 11   static const short ar[] = { &&l1 - &&l1, &&l2 - &&l1 };
> > 12   void *p = &&l1 + ar[a];
> > 13   goto *p;
> > 14  l1:
> > 15   return 1;
> > 16  l2:
> > 17   return 2;
> > 18 }
> >
> > on TARGET_16W and TARGET_32: 2004-1.c:
> > 1 extern void _text;
> > 2 static __SIZE_TYPE__ x = (__SIZE_TYPE__) &_text - 0x1000L - 1;
> >
> > Are those tests expected to fail on my port or is that something I've
> > obviously done wrong ?
> 
> I don't see any particular reason that these tests should fail.  I
> hasten to add that these tests are not very important and it is unlikely
> that a failure to pass these tests will affect any actual program.
> 
> You didn't mention which version of gcc you are based on.  Do you have
> these patches?  If not, that may be your problem.

Sorry, fergot to say that I was using gcc 4.3.3, so yes, the patches
you mention are already in.

> Even if you do have those patches, that code is where I would start
> looking.  Your initializers are constant, but something in that area
> thinks that they are not constant.

I did spent a few hours looking but haven't had much luck.

I tried tracing this one:
> > 6 long i = s.f-&s.b;
and noticed that the pointers gets casted to 'long' (so they become integers
and no longer pointers) before the actual substraction is made.

Of course, replacing the 'long' with 'int' (on the incriminated targets,
where the real size of the pointer is 16 bit, the size of an 'int') makes
the code compile as a charm.

Stelian.
-- 
Stelian Pop 

Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

[Ralf Wildenhues]

* Matthias Klose wrote on Wed, May 06, 2009 at 09:44:07AM CEST:
> On arm-linux-gnueabi there are regressions of the form
> 
> /usr/bin/ld: ./atomic-1.exe: hidden symbol `__sync_val_compare_and_swap_4' in
> /home/doko/gcc/4.4/gcc-4.4-4.4.0/build/gcc/libgcc.a(linux-atomic.o) is
> referenced by DSO
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> 
> in the libgomp, libstdc++ and g++ testsuites. Linking the shared libstdc++ 
> with
> both -lgcc_s and -lgcc does fix these (testsuites currently running), however
> I'm not sure how to do this properly, as libtool removes any `-lgcc' argument.

In order to be able to anayze this (and either confirm or refute a
possible libtool bug), I would like to see the './libtool --mode=link'
command that fails, plus all of its output with --debug added as first
argument; further the output of
  ./libtool --tag=TAG --config

with TAG replaced by the tag used for the link.

Thanks,
Ralf

Re: Issues with testsuite on constant pointer arithmetics

[Ian Lance Taylor]

Stelian Pop  writes:

> I did spent a few hours looking but haven't had much luck.
>
> I tried tracing this one:
>> >6 long i = s.f-&s.b;
> and noticed that the pointers gets casted to 'long' (so they become integers
> and no longer pointers) before the actual substraction is made.
>
> Of course, replacing the 'long' with 'int' (on the incriminated targets,
> where the real size of the pointer is 16 bit, the size of an 'int') makes
> the code compile as a charm.

I took a quick look at a similar case for x86, and the key step seems to
be a call to ptr_difference_const.  It converts the difference of two
ADDR_EXPRs to a constant.

Ian

[graphite] Weekly phone call notes

[Tobias Grosser]

Hi folks, hi graphities,

here you are with the latest notes from our graphite phone call.

It is also available on the wiki:

http://gcc.gnu.org/wiki/Graphite_Phone_Call/2009_05_06

All the best

Tobi


Attendees: Sebastian, Tobias, Christophe, Albert, Li, Jan, Razya,
Konrad, Antoniu 

  * Sebastian: 
  * Working on IVstack removal, 
  * Several other patches like "remove strcmp". (Will be
committed as soon as possible) 
  * in clast-to-gimple: 
  * There is a problem finding the type of induction
variables and upper bound expressions, as cloog
does not carry information about them. 
  * We will try "unsigned long long" and
have to insert casts. (This might
trigger problems in the vectorizer and
might be slow. Maybe we can optimize the
size of the iv later.) Before: Used we
used the type of the old IV. But with
strip mining there is no 1 to 1 relation
in between ivs, so there is not always a
type. Other idea: infer types from upper
and lower bound expressions. But does
not seem to work either. This blocks the
work on removal IVSTACK. 
  * Removal of IVStack: Blocked by types. But
already triggers some bugs. 
  * Reductions: Blocking by IVSTack. 
  * Li: 
  * Mark loops as parallel with -fgraphite-force-parallel
(committed). 
  * Trigger autopar with loop->can_be_parallel (committed). 

  * Started testsuite for graphite_autopar (sent for review
to gcc-patches). 
  * 
  * Autopar fails in graphite branch on this line; 

red = reduction_phi (reduction_list, reduc_phi);
  if (red == NULL)
  {
if (dump_file && (dump_flags & TDF_DETAILS))
  fprintf (dump_file,
   "  FAILED: it is not a part of reduction.\n");
return false;
  }


  * Tobias: 
  * Fix bugs to enable data reference building (Now only
gfortran.dg/transpose_conjg_1.f90 fails). 
  * Bootstrapped dependency testing. Worked except one test
case (gfortran.dg/cray_pointers_2.f90). 
  * Working on his paper about the polyhedral part of
graphite to attract more research in this area. 
  * 
  * Jan: 
  * Got gcc summit paper accepted. Will be about the design
of Graphite: IR, components of the Graphite
infrastructure, testsuite, example, internals,
integration with external prototyping tools (POCC). We
should have some discussions about who describes what in
graphite, as Tobias also has a paper accepted. 
  * Worked on the translation of PCP to Polyhedral
representation. 

Re: [graphite] Weekly phone call notes

[Richard Guenther]

On Wed, May 6, 2009 at 11:15 PM, Tobias Grosser
 wrote:
> Hi folks, hi graphities,
>
> here you are with the latest notes from our graphite phone call.
>
> It is also available on the wiki:
>
> http://gcc.gnu.org/wiki/Graphite_Phone_Call/2009_05_06
>
> All the best
>
> Tobi
>
>
> Attendees: Sebastian, Tobias, Christophe, Albert, Li, Jan, Razya,
> Konrad, Antoniu
>
>      * Sebastian:
>              * Working on IVstack removal,
>              * Several other patches like "remove strcmp". (Will be
>                committed as soon as possible)
>              * in clast-to-gimple:
>                      * There is a problem finding the type of induction
>                        variables and upper bound expressions, as cloog
>                        does not carry information about them.
>                              * We will try "unsigned long long" and
>                                have to insert casts. (This might
>                                trigger problems in the vectorizer and
>                                might be slow. Maybe we can optimize the
>                                size of the iv later.) Before: Used we
>                                used the type of the old IV. But with
>                                strip mining there is no 1 to 1 relation
>                                in between ivs, so there is not always a
>                                type. Other idea: infer types from upper
>                                and lower bound expressions. But does
>                                not seem to work either. This blocks the
>                                work on removal IVSTACK.

If the induction variables are only used to iterate over the domain then
deriving them from upper and lower bounds (well - if you can constrain
them) should be the right thing to do.  In that context, when the IVs
are then only used to index into arrays or used as offsets for pointers
then using sizetype instead of unsigned long long would be a better
default choice.

Are there known constraints on the IV use?  Like that operations on them
never overflow?

Richard.

>                      * Removal of IVStack: Blocked by types. But
>                        already triggers some bugs.
>                      * Reductions: Blocking by IVSTack.
>      * Li:
>              * Mark loops as parallel with -fgraphite-force-parallel
>                (committed).
>              * Trigger autopar with loop->can_be_parallel (committed).
>
>              * Started testsuite for graphite_autopar (sent for review
>                to gcc-patches).
>              *
>              * Autopar fails in graphite branch on this line;
> 
> red = reduction_phi (reduction_list, reduc_phi);
>      if (red == NULL)
>      {
>        if (dump_file && (dump_flags & TDF_DETAILS))
>          fprintf (dump_file,
>                   "  FAILED: it is not a part of reduction.\n");
>        return false;
>      }
> 
>
>      * Tobias:
>              * Fix bugs to enable data reference building (Now only
>                gfortran.dg/transpose_conjg_1.f90 fails).
>              * Bootstrapped dependency testing. Worked except one test
>                case (gfortran.dg/cray_pointers_2.f90).
>              * Working on his paper about the polyhedral part of
>                graphite to attract more research in this area.
>              *
>      * Jan:
>              * Got gcc summit paper accepted. Will be about the design
>                of Graphite: IR, components of the Graphite
>                infrastructure, testsuite, example, internals,
>                integration with external prototyping tools (POCC). We
>                should have some discussions about who describes what in
>                graphite, as Tobias also has a paper accepted.
>              * Worked on the translation of PCP to Polyhedral
>                representation.
>
>

Re: Issues with testsuite on constant pointer arithmetics

[Stelian Pop]

On Wed, May 06, 2009 at 01:23:57PM -0700, Ian Lance Taylor wrote:

> Stelian Pop  writes:
> 
> > I did spent a few hours looking but haven't had much luck.
> >
> > I tried tracing this one:
> >> >  6 long i = s.f-&s.b;
> > and noticed that the pointers gets casted to 'long' (so they become integers
> > and no longer pointers) before the actual substraction is made.
> >
> > Of course, replacing the 'long' with 'int' (on the incriminated targets,
> > where the real size of the pointer is 16 bit, the size of an 'int') makes
> > the code compile as a charm.
> 
> I took a quick look at a similar case for x86, and the key step seems to
> be a call to ptr_difference_const.  It converts the difference of two
> ADDR_EXPRs to a constant.

in my case ptr_difference_const doesn't get called at all, because
the operands are no longer ADDR_EXPRs:

(gdb) p debug_tree(op0)
 
unit size 
align 8 symtab 0 alias set -1 canonical type 0xb7c9d3a8 precision 32 min
 max 
pointer_to_this >
constant invariant
arg 0 
unit size 
align 8 symtab 0 alias set -1 canonical type 0xb7c9d2d8 precision 16
min  max 
pointer_to_this >
constant invariant
arg 0 
constant invariant
arg 0 
arg 0  arg 1 

(gdb) p debug_tree(op1)
 
unit size 
align 8 symtab 0 alias set -1 canonical type 0xb7c9d3a8 precision 32 min
 max 
pointer_to_this >
constant invariant
arg 0 
unit size 
align 8 symtab 0 alias set -1 canonical type 0xb7c9d2d8 precision 16
min  max 
pointer_to_this >
constant invariant
arg 0 
constant invariant
arg 0 
arg 0  arg 1 

-- 
Stelian Pop 

Re: [RFC] Get rid of awkward semantics for subtypes

[Eric Botcazou]

> I wonder for example about
>
>   type  asm_written public visited SI
> size 
> unit size 
> align 32 symtab 1993070176 alias set -1 canonical type
> 0x2b1d76cbe540 precision 32 min  -2147483648> max 
> pointer_to_this >
> sizes-gimplified asm_written public visited SI size  0x2b1d76cb0a20 32> unit size 
> align 32 symtab 2001622336 alias set 0 canonical type
> 0x2b1d770a3300 precision 32 min  -2147483648> max  RM size
> 
> chain >
>
> it seems the base type here is exactly the same as the subtype?

Yes, don't be too surprised, gigi even creates extra subtypes (not present in 
the language) to work around its own quirks. :-)

> In the particular case IVOPTs is creating arithmetic in that type.  Or
> maybe fold.

Yes, IVOPTs does that.  I needed this patchlet

*** generic_type_for (tree type)
*** 1978,1983 
--- 1978,1990 
if (POINTER_TYPE_P (type))
  return ptr_type_node;
  
+   /* Return the appropriate type to do unsigned arithmetics.  */
+   if (TREE_CODE (type) == INTEGER_TYPE && TREE_TYPE (type))
+ type = TREE_TYPE (type);
+ 
+   if (TREE_CODE (type) != INTEGER_TYPE)
+ return lang_hooks.types.type_for_size (TYPE_PRECISION (type), 1);
+ 
if (TYPE_UNSIGNED (type))
  return type;

when I was experimenting with another approach to the subtype problem.
  
-- 
Eric Botcazou

Re: archives broken?

[Dave Korn]

Ian Lance Taylor wrote:
> Andrew Haley  writes:
> 
>> Manuel López-Ibáñez wrote:
>>> 2009/5/6 Paolo Bonzini :
 It looks like a bunch of missing from
 http://gcc.gnu.org/ml/gcc-patches/2004-02/ are missing.  Anybody knows
 what could be the cause?
>>> Relevant PRs 20336, 20588, 3119.
>> I'm pretty sure I have a complete set of the messages.
> 
> I believe that we have a complete set of messages too.  Fixing the web
> pages takes somebody with the time and energy to figure out what is
> required.  The mailing list archives are built using mhonarc.  Any
> volunteers?

  I could have a rummage.  I have a little experience with mhonarc, having
installed and maintained some in-house mailing list archives in my last job.
I never had to rebuild an index, but I recall reading that it's fairly
straightforward to feed it emails in mbox format and get it to rebuild the
indices (which hopefully should all line-up as they were before rather than
result in any message numbers shifting about).

cheers,
  DaveK

Re: archives broken?

[Joseph S. Myers]

On Wed, 6 May 2009, Dave Korn wrote:

> Ian Lance Taylor wrote:
> > Andrew Haley  writes:
> > 
> >> Manuel López-Ibáñez wrote:
> >>> 2009/5/6 Paolo Bonzini :
>  It looks like a bunch of missing from
>  http://gcc.gnu.org/ml/gcc-patches/2004-02/ are missing.  Anybody knows
>  what could be the cause?
> >>> Relevant PRs 20336, 20588, 3119.
> >> I'm pretty sure I have a complete set of the messages.
> > 
> > I believe that we have a complete set of messages too.  Fixing the web
> > pages takes somebody with the time and energy to figure out what is
> > required.  The mailing list archives are built using mhonarc.  Any
> > volunteers?
> 
>   I could have a rummage.  I have a little experience with mhonarc, having
> installed and maintained some in-house mailing list archives in my last job.
> I never had to rebuild an index, but I recall reading that it's fairly
> straightforward to feed it emails in mbox format and get it to rebuild the
> indices (which hopefully should all line-up as they were before rather than
> result in any message numbers shifting about).

I really recommend adapting Jason's script to regenerate from the .txt 
versions and keep the message numbers the same; mboxes or qmail archives 
will almost certainly get some of the numbers slightly different.

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

Re: archives broken?

[Dave Korn]

Joseph S. Myers wrote:
> On Wed, 6 May 2009, Dave Korn wrote:

>>   I could have a rummage.  I have a little experience with mhonarc, having
>> installed and maintained some in-house mailing list archives in my last job.
>> I never had to rebuild an index, but I recall reading that it's fairly
>> straightforward to feed it emails in mbox format and get it to rebuild the
>> indices (which hopefully should all line-up as they were before rather than
>> result in any message numbers shifting about).
> 
> I really recommend adapting Jason's script to regenerate from the .txt 
> versions and keep the message numbers the same; mboxes or qmail archives 
> will almost certainly get some of the numbers slightly different.

  I see that MHonARc >= 2.6 supports this:

http://www.mhonarc.org/MHonArc/doc/resources/reconvert.html

which I think also does what we want, without any worries about changing
message numbers or over-feeding it creating dups.  I'm just reading the script
to see if it does other important stuff besides.

cheers,
  DaveK

Re: Issues with testsuite on constant pointer arithmetics

[Ian Lance Taylor]

Stelian Pop  writes:

>> I took a quick look at a similar case for x86, and the key step seems to
>> be a call to ptr_difference_const.  It converts the difference of two
>> ADDR_EXPRs to a constant.
>
> in my case ptr_difference_const doesn't get called at all, because
> the operands are no longer ADDR_EXPRs:

They are still ADDR_EXPRs where it counts on x86, as the code strips nop
conversions.  In your case the conversion from HImode to SImode seems to
be defeating that.

There is something strange in your trees.  Why did it convert the
pointers to "long int"?  Why did it not simply convert them to "int"?
The fact that they are going to be assigned to a "long int" variable
should not have caused them to convert to "long int".

Oh, I see it comes from PTRDIFF_TYPE, which defaults to "long int".  Try
doing #define PTRDIFF_TYPE "int" in your CPU.h file.

Ian

Avoiding REG+OFF memory accesses

[Iceman]

Sorry for such trivial question, but is there any macro that can be used to 
avoig GCC to generate
REG+OFF memory accesses?
So basically to force GCC to break:

(mem (plus (reg const_int)))

into

(set regtmp (plus (reg const_int)))
(set (mem regtmp) reg)

This w/out writing custom RTL.
Can you please Cc me, since I am not subscribed. Thank you.

   James


  

Re: archives broken?

[Joseph S. Myers]

On Wed, 6 May 2009, Dave Korn wrote:

>   I see that MHonARc >= 2.6 supports this:
> 
> http://www.mhonarc.org/MHonArc/doc/resources/reconvert.html
> 
> which I think also does what we want, without any worries about changing
> message numbers or over-feeding it creating dups.  I'm just reading the script
> to see if it does other important stuff besides.

Given that the directory is corrupted, I wouldn't trust a reconvert script 
to find the database in a suitable state.  Use 
infra/ml-archiving/ml-regen-from-txtfiles.sh, as referenced in 
, unless it 
proves impossible to make it work.

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

Re: archives broken?

[Dave Korn]

Joseph S. Myers wrote:
> On Wed, 6 May 2009, Dave Korn wrote:

> Given that the directory is corrupted, I wouldn't trust a reconvert script 
> to find the database in a suitable state.  Use 
> infra/ml-archiving/ml-regen-from-txtfiles.sh, as referenced in 
> , unless it 
> proves impossible to make it work.

  That apparently requires to be run su mailarch, which is beyond my privs,
but I think I could usefully write a script to generate not-archived files for
the missing stuff with which to feed it.

cheers,
  DaveK

Re: Issues with testsuite on constant pointer arithmetics

[Stelian Pop]

On Wed, May 06, 2009 at 03:42:47PM -0700, Ian Lance Taylor wrote:

> Stelian Pop  writes:
> 
> There is something strange in your trees.  Why did it convert the
> pointers to "long int"?  Why did it not simply convert them to "int"?
> The fact that they are going to be assigned to a "long int" variable
> should not have caused them to convert to "long int".
> 
> Oh, I see it comes from PTRDIFF_TYPE, which defaults to "long int".  Try
> doing #define PTRDIFF_TYPE "int" in your CPU.h file.

Of course, and I thought I did:

On Wed, May 06, 2009 at 06:15:40PM +0200, Stelian Pop wrote:
> #define PTRDIFF_TYPE_SIZE   ((TARGET_8W || TARGET_16) ? "int" : "long 
> int")

... except that there's a typo in there.

Once corrected, all things are back to normal. Thanks, and sorry for the
noise.

Now, where's that brown paper bag...

Stelian.
-- 
Stelian Pop 

Re: Bootstrap broken by ppl/cloog config problem: finds non-system/non-standard "/include" dir

[Tim Prince]

Dave Korn wrote:

Tim Prince wrote:

  

#include 

no such file
-I/include was set by configure.  As you say, there is something bogus here.

setup menu shows cloog installed in development category, but I can't find
any such include file.  Does this mean the cygwin distribution of cloog is
broken?



  Did you make sure to get the -devel packages as well as the libs?  That's
the usual cause of this kind of problem.  I highly recommend the new version
of setup.exe that has a package-list search box :-)

cheers,
  DaveK
  
OK, I see there is a libcloog-devel in addition to the cloog Dev 
selection, guess that will fix it for cygwin.


I tried to build cloog for IA64 linux as well, gave up on include file 
parsing errors.

Re: Avoiding REG+OFF memory accesses

[Ian Lance Taylor]

Iceman  writes:

> Sorry for such trivial question, but is there any macro that can be used to 
> avoig GCC to generate
> REG+OFF memory accesses?
> So basically to force GCC to break:
>
> (mem (plus (reg const_int)))
>
> into
>
> (set regtmp (plus (reg const_int)))
> (set (mem regtmp) reg)
>
> This w/out writing custom RTL.

Assuming this is a private port, this should happen more or less
automatically if GO_IF_LEGITIMATE_ADDRESS rejects register plus offset
addressing.

If that is not what you are looking for, I think you need to provide
some more context.

Ian