Re: bootstrap broken on ppc-linux

[Nathan Sidwell]

Zack Weinberg wrote:



This is close to obvious and should fix bootstrap, but I am hesitant
to call anything about vec.h obvious.  Nathan cc:ed.


The vec patch looks ok.  I see there's a duplicated line,
+  VEC_BASE (*vec_)->num = size_;  \
+  VEC_BASE (*vec_)->num = size_;  \

but that's from copying an existing problem.  I can fix that later.

nathan
--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Re: bootstrap failure for Ada gcc 4.1 Revision 110108 on

[Rainer Emrich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

John David Anglin schrieb:
>>> gnat1: out of memory allocating 19028192 bytes after a total of 92324 bytes
>>> gmake[2]: *** [ada/ada.o] Error 1
> 
> My guess is that this is a problem with the bootstrap compiler.  There
> is a known issue with all 3.3 releases that require compiling stage 1
> with -O1.  I think there's also a problem with the 4.0 releases.  See
> for example http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24822.  3.4.4
> and 3.4.5 seem to be ok based on my testing.   The above error is likely
> a garbage collection problem.
> 
> Dave

I tried bootstrapping the latest 4.0 revesion without luck.

It's my first try for the 4.1 series. I used gcc-3.4.5 as bootstrap compiler as
Dave recommended.

- --
Rainer Emrich
TECOSIM GmbH
Im Eichsfeld 3
65428 Rüsselsheim

Phone: +49(0)6142/8272 12
Mobile: +49(0)163/56 949 20
Fax.:   +49(0)6142/8272 49
Web: www.tecosim.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD1e8y3s6elE6CYeURAvTJAKCoZho1SbBG0aO38O0oD8F4q1KqHACgqEKK
oBtm7NWTql+q3sFAZuIVHbc=
=zAU6
-END PGP SIGNATURE-

Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?

[Arnaud Charlet]

> I'm not sure we'd be willing to trade minimal dependencies for "future binary 
> compatibility", but I see your point.  I'll let Arnaud decide.

Well if you ask me, I'd rather not put anything special for Darwin.
Failing that, I'd rather see a very minimal change.

Having systematically a dependency on libgcc_s in the world I live in
is simply a pain, no matter how you put it, so that's really my least
preferred option.

Also as others said, caring about forward compatibility on Darwin when
we see that Darwin is handled in such a weird way and keep changing things
seems a very dubious argument at best.

So if we want to switch to constructive mode, I do not really see a
minimal patch to solve this unless the gcc driver can be changed.

Otherwise, we could modify systematically the binder/linker to always
call gcc with either -static-libgcc or -shared-libgcc when linking, depending
on whether shared libs are used. Or we could make this capability optional
and enabled with a flag in link.c named e.g. "__gnat_force_libgcc_switch"

In any case, we're talking about non trivial amount of work.

Maybe Vincent (cc:ed) would have some other suggestions on the possible
approaches ? (see http://gcc.gnu.org/ml/gcc/2006-01/msg00616.html for
earlier discussions on this subject).

Arno

Re: Mainline bootstrap failure (revision 110017)

[Zdenek Dvorak]

Hello,

> On Fri, 20 Jan 2006, Zdenek Dvorak wrote:
> > I propose the following workaround instead, that also restores
> > bootstrap.  It changes the way loop-iv uses df to more conservative one,
> > that does not seem to cause problems.
> 
> That's what I like to see... options.  Yes, this is OK for mainline,
> please hold off on the reversion (or if necessary reapply with this
> change).

OK to revert this workaround now?  Mainline now passes bootstrap &
regtesting on i686 without it.

Zdenek

* loop-iv.c (iv_analysis_loop_init): Use df analysis in a more
efficient way.

Index: loop-iv.c
===
*** loop-iv.c   (revision 110143)
--- loop-iv.c   (working copy)
*** iv_analysis_loop_init (struct loop *loop
*** 250,260 
current_loop = loop;
  
/* Clear the information from the analysis of the previous loop.  */
!   if (!first_time)
! iv_analysis_done ();
!   df = df_init (DF_HARD_REGS | DF_EQUIV_NOTES);
!   df_chain_add_problem (df, DF_UD_CHAIN);
!   bivs = htab_create (10, biv_hash, biv_eq, free);
  
for (i = 0; i < loop->num_nodes; i++)
  {
--- 250,263 
current_loop = loop;
  
/* Clear the information from the analysis of the previous loop.  */
!   if (first_time)
! {
!   df = df_init (DF_HARD_REGS | DF_EQUIV_NOTES);
!   df_chain_add_problem (df, DF_UD_CHAIN);
!   bivs = htab_create (10, biv_hash, biv_eq, free);
! }
!   else
! clear_iv_info ();
  
for (i = 0; i < loop->num_nodes; i++)
  {

Regarding gcc Makefile.in

[Ashit Kumar]

Hi,
I am a newbie for GCC internals.Actually i want to build the GCC (say it
compile the GCC).Now during this i want to study the build process of it.
Can you please guide me how can i step ahead and can you give me an idea
that how can i read through the Makefile.in which seems to be quite
complicated,or is there any way through which we can make it an easy one.
Thanks and regards
Ashit


-
question = ( to ) ? be : !be;
-
Ashit Kumar
VIth semester
Department Of Computer Science
University Of Pune
Hello:-09850324089

Re: Mainline bootstrap failure (revision 110017)

[Paolo Bonzini]

OK to revert this workaround now?  Mainline now passes bootstrap &
regtesting on i686 without it.


You can approve reversion of your own patches.  svnwrite.html says that 
"no outside approval is needed to revert a patch that you checked in."


Paolo

Re: bootstrap failure for Ada gcc 4.1 Revision 110108 on

[Rainer Emrich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

John David Anglin schrieb:
>>> gnat1: out of memory allocating 19028192 bytes after a total of 92324 bytes
>>> gmake[2]: *** [ada/ada.o] Error 1
> 
> My guess is that this is a problem with the bootstrap compiler.  There
> is a known issue with all 3.3 releases that require compiling stage 1
> with -O1.  I think there's also a problem with the 4.0 releases.  See
> for example http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24822.  3.4.4
> and 3.4.5 seem to be ok based on my testing.   The above error is likely
> a garbage collection problem.
> 
> Dave

I found the cause for the bootstrap failure.

Normally I pass "-mpa-risc-2-0" to the boostrap compiler. This produces
PA-RISC2.0 optimized executables. As you can see:

file gcc
gcc:PA-RISC2.0 shared executable dynamically linked -not stripped

This option prevents a successful bootstrap of ada in this case. I wonder why.

Rainer

- --
Rainer Emrich
TECOSIM GmbH
Im Eichsfeld 3
65428 Rüsselsheim

Phone: +49(0)6142/8272 12
Mobile: +49(0)163/56 949 20
Fax.:   +49(0)6142/8272 49
Web: www.tecosim.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD1gfA3s6elE6CYeURAs2gAKCJl/AVK73ZzWEJoDOEUYcGo/D+9QCgjp/I
URadvB06+rsiTMhW9j7PLCo=
=JBMn
-END PGP SIGNATURE-

Unable to access archives on gcc-patches

[pranav bhandarkar]

Hi,
I was having trouble with building gcc and found that the problem i
was having had been reported earlier and a patch to fix that had been
submitted in feb 2004.
However when i try to access the mailing list archives i am able to
reach the index page for feb 2004. the link to which is given as:

 http://gcc.gnu.org/ml/gcc-patches/2004-02/

However the patch that i am looking for is not accessible. the link to
the patch is

http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00826.html

Just to check, i tried accessing other patches from the index link but
could not access most of them.
Can anybody please help me out.
Thanks in advance,
Pranav
--
"So far as I am able to judge, nothing has been left undone,
 either by man or nature, to make India the most extraordinary
country that the sun visits on his rounds. Nothing seems to
have been forgotten, nothing overlooked."
Mark Twain

Re: Mainline bootstrap failure (revision 110017)

[Kenneth Zadeck]

Zdenek Dvorak wrote:

Hello,

  

On Fri, 20 Jan 2006, Zdenek Dvorak wrote:


I propose the following workaround instead, that also restores
bootstrap.  It changes the way loop-iv uses df to more conservative one,
that does not seem to cause problems.
  

That's what I like to see... options.  Yes, this is OK for mainline,
please hold off on the reversion (or if necessary reapply with this
change).



OK to revert this workaround now?  Mainline now passes bootstrap &
regtesting on i686 without it.

  
I tested my code before and after your revert and it passed.  As far as 
I am concerned, put it back.



Zdenek

* loop-iv.c (iv_analysis_loop_init): Use df analysis in a more
efficient way.

Index: loop-iv.c
===
*** loop-iv.c   (revision 110143)
--- loop-iv.c   (working copy)
*** iv_analysis_loop_init (struct loop *loop
*** 250,260 
current_loop = loop;
  
/* Clear the information from the analysis of the previous loop.  */

!   if (!first_time)
! iv_analysis_done ();
!   df = df_init (DF_HARD_REGS | DF_EQUIV_NOTES);
!   df_chain_add_problem (df, DF_UD_CHAIN);
!   bivs = htab_create (10, biv_hash, biv_eq, free);
  
for (i = 0; i < loop->num_nodes; i++)

  {
--- 250,263 
current_loop = loop;
  
/* Clear the information from the analysis of the previous loop.  */

!   if (first_time)
! {
!   df = df_init (DF_HARD_REGS | DF_EQUIV_NOTES);
!   df_chain_add_problem (df, DF_UD_CHAIN);
!   bivs = htab_create (10, biv_hash, biv_eq, free);
! }
!   else
! clear_iv_info ();
  
for (i = 0; i < loop->num_nodes; i++)

  {
  

Re: Unable to access archives on gcc-patches

[Ranjit Mathew]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

pranav bhandarkar wrote:
> 
> However the patch that i am looking for is not accessible. the link to
> the patch is
> 
> http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00826.html

Note that you can also use Gmane (news.gmane.org) for
accessing archives of many a mailing list. In this particular
case, I think the message you're looking for is this:

  http://article.gmane.org/gmane.comp.gcc.patches/54904

HTH,
Ranjit.

- --
Ranjit Mathew  Email: rmathew AT gmail DOT com

Bangalore, INDIA.Web: http://rmathew.com/


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD1h4qYb1hx2wRS48RAkz8AJ91nTIZIj5Dr3mAKK/+THws+D1sMQCfa+Lf
l8G2snSbRkEhy+ESymmC4Y8=
=wQK7
-END PGP SIGNATURE-

Re: Regarding gcc Makefile.in

[Saurabh Verma]

hi ashit,

On Tue, 2006-01-24 at 15:39 +0530, Ashit Kumar wrote:
> I am a newbie for GCC internals.Actually i want to build the GCC (say it
> compile the GCC).Now during this i want to study the build process of it.
a good starting point could be building gcc natively and looking at the
build logs, to understand how make runs through the source tree during
the build, i.e. 

builddir/> $GCCSRCDIR/configure
builddir/> make 2>&1 |tee make.log

And look at the make.log file to see how the build proceeds.


HTH
regards
saurabh

Re: [RFC/RFT] PR/25890 and PR/25905

[Roger Sayle]

On Mon, 23 Jan 2006, Paolo Bonzini wrote:
> 2006-01-23  Paolo Bonzini  <[EMAIL PROTECTED]>
>
>   PR rtl-optimization/25890
>   PR rtl-optimization/25905
>   * combine.c (expand_compound_operation, expand_field_assignment):
>   Fail if the bitfield's final position is out of bounds.

This is OK for mainline.  Though we'd also do well to fix some of
the underlying code that's causing this suspicious RTL.

Thanks,

Roger
--

Re: Mainline bootstrap failure (revision 110017)

[Ian Lance Taylor]

Zdenek Dvorak <[EMAIL PROTECTED]> writes:

> OK to revert this workaround now?  Mainline now passes bootstrap &
> regtesting on i686 without it.
> 
> Zdenek
> 
>   * loop-iv.c (iv_analysis_loop_init): Use df analysis in a more
>   efficient way.

This is OK.

Thanks.

Ian

Re: bootstrap failure for Ada gcc 4.1 Revision 110108 on

[John David Anglin]

> I tried bootstrapping the latest 4.0 revesion without luck.

Suggest that you submit a GCC PR including the precise failure point,
configure command, and preprocessed source if applicable.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

Re: bootstrap failure for Ada gcc 4.1 Revision 110108 on

[Rainer Emrich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

John David Anglin schrieb:
>> I tried bootstrapping the latest 4.0 revesion without luck.
> 
> Suggest that you submit a GCC PR including the precise failure point,
> configure command, and preprocessed source if applicable.
> 
> Dave

Perhaps I have to be more precise. Bootstrapping ada failed!
Eventually it's the same problem as for 4.1. I will try without passing
- -mpa-risc-2-0 to the booststrap compiler. But that's still curious to me.

Rainer

- --
Rainer Emrich
TECOSIM GmbH
Im Eichsfeld 3
65428 Rüsselsheim

Phone: +49(0)6142/8272 12
Mobile: +49(0)163/56 949 20
Fax.:   +49(0)6142/8272 49
Web: www.tecosim.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD1kIC3s6elE6CYeURAu69AKDNwliWZqcLNGW7Z1cp9PEIpGDZeACgjwXO
PPFPaCkmPq/lxGZq/KQe+Ik=
=SGBh
-END PGP SIGNATURE-

Re: bootstrap failure for Ada gcc 4.1 Revision 110108 on

[John David Anglin]

> I found the cause for the bootstrap failure.
> 
> Normally I pass "-mpa-risc-2-0" to the boostrap compiler. This produces
> PA-RISC2.0 optimized executables. As you can see:
> 
> file gcc
> gcc:PA-RISC2.0 shared executable dynamically linked -not stripped
> 
> This option prevents a successful bootstrap of ada in this case. I wonder why.

Bootstrapping ada on hpux requires -mdisable-indexing.  The above
suggests that we might be generating a PA 2.0 indexed instruction.
For the most part, PA 2.0 code generation is tested by hppa64 builds.
That said, I did try a number of months ago to build a hppa64 version
of gnat but I hit a number of problems that I didn't have time to
resolve at the time.

Did "-mpa-risc-2-0" work with your 3.4.5 build?

Would you please file a PR.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

Re: bootstrap failure for Ada gcc 4.1 Revision 110108 on

[Rainer Emrich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

John David Anglin schrieb:
>> I found the cause for the bootstrap failure.
>>
>> Normally I pass "-mpa-risc-2-0" to the boostrap compiler. This produces
>> PA-RISC2.0 optimized executables. As you can see:
>>
>> file gcc
>> gcc:PA-RISC2.0 shared executable dynamically linked -not stripped
>>
>> This option prevents a successful bootstrap of ada in this case. I wonder 
>> why.
> 
> Bootstrapping ada on hpux requires -mdisable-indexing.  The above
> suggests that we might be generating a PA 2.0 indexed instruction.
> For the most part, PA 2.0 code generation is tested by hppa64 builds.
> That said, I did try a number of months ago to build a hppa64 version
> of gnat but I hit a number of problems that I didn't have time to
> resolve at the time.
> 
> Did "-mpa-risc-2-0" work with your 3.4.5 build?
> 
> Would you please file a PR.
> 
> Dave

The "-mpa-risc-2-0" switch worked for 3.3.6 and 3.4.5:

file gcc-3.3.6/lib/gcc-lib/hppa2.0w-hp-hpux11.00/3.3.6/gnat1
gnat1:  PA-RISC2.0 shared executable dynamically linked -not stripped

file gcc-3.4.5/libexec/gcc/hppa2.0w-hp-hpux11.00/3.4.5/gnat1
gnat1:  PA-RISC2.0 shared executable dynamically linked -not stripped

I have to leave the office now. I will investigate further tomorrow.

Rainer


- --
Rainer Emrich
TECOSIM GmbH
Im Eichsfeld 3
65428 Rüsselsheim

Phone: +49(0)6142/8272 12
Mobile: +49(0)163/56 949 20
Fax.:   +49(0)6142/8272 49
Web: www.tecosim.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD1kuP3s6elE6CYeURAlADAJ9oQ1EOYX817bf8Pipuw8xu4U7JoQCeOthr
+ENscjCg5L5hc/dxetBvhiA=
=tB3o
-END PGP SIGNATURE-

Re: bootstrap failure for Ada gcc 4.1 Revision 110108 on

[John David Anglin]

> Perhaps I have to be more precise. Bootstrapping ada failed!

That's not enough!   In order for someone else to duplicate the failure
and investigate the problem, you need to provide the log of what happened,
your configure command, etc.  For example, I would have never guessed that
you were using "-mpa-risc-2-0".  See http://gcc.gnu.org/bugs.html.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

Re: insv vs one-bit fields

[Richard Henderson]

On Mon, Jan 23, 2006 at 10:29:20PM -0500, DJ Delorie wrote:
> Ok, I can't really read ia64 assembler.  Before:

Close enough.  Thanks for testing.


r~

x86-64 linux, gomp ICE in trunk

[tbp]

Hello,

I wanted to play a bit with OpenMP after fighting a (long) while to
get a 4.2 snapshot compiled on my debian64 box... alas...

fresh svn checkout, multilib disabled because it's a no go on my box.
# /usr/local/gomp/bin/g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr/local/gomp
--enable-languages=c++ --enable-threads=posix --with-system-zlib
--enable-__cxa_atexit --disable-multilib --enable-bootstrap --with-gcc
--with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 4.2.0 20060124 (experimental)

testcase:
int toto() {
int a=0;
#pragma omp single
{
for (int i=0; i<10; ++i)
a += i;
}
return a;
}
int main() { return toto(); }

/usr/local/gomp/bin/g++ -fopenmp main.cc -o omp
main.cc: In function 'int toto()':
main.cc:5: internal compiler error: in cp_parser_pragma, at cp/parser.c:17629
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

Command line options or the precise omp pragma used don't really
matter, i get a crash on any "valid" omp directive; gcc-4.2-20060121
is ICE happy the same way.

As a side note while trying to get the compiler built with some debug
info, i've hit a case where it couldn't libgomp.spec once installed (a
--disable-shared configuration).

If there's a workaround that would make my day :)

Re: insv vs one-bit fields

[DJ Delorie]

> Close enough.  Thanks for testing.

Ok to apply then?

sh-rtems still broken on head

[Joel Sherrill]

This appears to be different from the previous failure.

make[2]: Nothing to be done for `all'.
make[2]: Leaving directory 
`/home/joel/gcc-work/head/b-sh-rtems4.7/libdecnumber'

make[2]: Entering directory `/home/joel/gcc-work/head/b-sh-rtems4.7/gcc'
build/genextract ../../gcc/gcc/config/sh/sh.md \
 insn-conditions.md > tmp-extract.c
*** glibc detected *** double free or corruption (fasttop): 0x0873f4c8 ***
/bin/sh: line 1:  7371 Aborted build/genextract 
../../gcc/gcc/config/sh/sh.md insn-conditions.md >tmp-extract.c


Here is the gdb backtrace.(


gdb) run ../../gcc/gcc/config/sh/sh.md insn-conditions.md > tmp-extract.c
Starting program: 
/home/joel/gcc-work/head/b-sh-rtems4.7/gcc/build/genextract 
../../gcc/gcc/config/sh/sh.md insn-conditions.md > tmp-extract.c

Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0x137000
*** glibc detected *** double free or corruption (fasttop): 0x08cda4c8 ***

Program received signal SIGABRT, Aborted.
0x00137402 in __kernel_vsyscall ()
(gdb) bt
#0  0x00137402 in __kernel_vsyscall ()
During symbol reading, Incomplete CFI data; unspecified registers at 
0x00137400.
During symbol reading, Incomplete CFI data; unspecified registers at 
0x00137400.
During symbol reading, Incomplete CFI data; unspecified registers at 
0x00137400.
During symbol reading, Incomplete CFI data; unspecified registers at 
0x00137400.
During symbol reading, Incomplete CFI data; unspecified registers at 
0x00137400.
During symbol reading, Incomplete CFI data; unspecified registers at 
0x00137400.
During symbol reading, Incomplete CFI data; unspecified registers at 
0x00137400.
During symbol reading, Incomplete CFI data; unspecified registers at 
0x00137400.

#1  0x006f17d5 in raise () from /lib/tls/libc.so.6
#2  0x006f3149 in abort () from /lib/tls/libc.so.6
#3  0x0072540a in __libc_message () from /lib/tls/libc.so.6
#4  0x0072bb3f in _int_free () from /lib/tls/libc.so.6
#5  0x0072d461 in _int_realloc () from /lib/tls/libc.so.6
#6  0x0072e656 in realloc () from /lib/tls/libc.so.6
#7  0x08050fd3 in xrealloc (oldmem=0x8cda4c8, size=8327156)
   at ../../../gcc/libiberty/xmalloc.c:179
During symbol reading, Incomplete CFI data; unspecified registers at 
0x08050fb7.
During symbol reading, Incomplete CFI data; unspecified registers at 
0x08050fb7.
During symbol reading, Incomplete CFI data; unspecified registers at 
0x08050fb7.
During symbol reading, Incomplete CFI data; unspecified registers at 
0x08050fb7.
During symbol reading, Incomplete CFI data; unspecified registers at 
0x08050fb7.
During symbol reading, Incomplete CFI data; unspecified registers at 
0x08050fb7.

#8  0x0804fae5 in vec_heap_o_reserve (vec=Variable "vec" is not available.
) at ../../gcc/gcc/vec.c:138
During symbol reading, Incomplete CFI data; unspecified registers at 
0x0804fa75.
During symbol reading, Incomplete CFI data; unspecified registers at 
0x0804fa75.
During symbol reading, Incomplete CFI data; unspecified registers at 
0x0804fa75.
During symbol reading, Incomplete CFI data; unspecified registers at 
0x0804fa75.

#9  0x0804fb88 in vec_heap_p_reserve (vec=0x8cda4c8, reserve=1)
   at ../../gcc/gcc/vec.c:121
During symbol reading, Incomplete CFI data; unspecified registers at 
0x0804fb63.
During symbol reading, Incomplete CFI data; unspecified registers at 
0x0804fb63.
#10 0x08048fcb in VEC_safe_set_locstr (v=0x8cda4c8, ix=12, str=0x8d8d6d0 
"g0")

   at ../../gcc/gcc/genextract.c:77
#11 0x0804937f in walk_rtx (x=0x8cf0788, acc=0xbfb7e510)
   at ../../gcc/gcc/genextract.c:238
#12 0x0804917c in walk_rtx (x=0x8cf0778, acc=0xbfb7e510)
   at ../../gcc/gcc/genextract.c:286
#13 0x080497ed in main (argc=Cannot access memory at address 0x1cd5
) at ../../gcc/gcc/genextract.c:113

Re: sh-rtems still broken on head

[Andrew Pinski]

> 
> 
> This appears to be different from the previous failure.
> 
> make[2]: Nothing to be done for `all'.
> make[2]: Leaving directory 
> `/home/joel/gcc-work/head/b-sh-rtems4.7/libdecnumber'
> make[2]: Entering directory `/home/joel/gcc-work/head/b-sh-rtems4.7/gcc'
> build/genextract ../../gcc/gcc/config/sh/sh.md \
>   insn-conditions.md > tmp-extract.c
> *** glibc detected *** double free or corruption (fasttop): 0x0873f4c8 ***
> /bin/sh: line 1:  7371 Aborted build/genextract 
> ../../gcc/gcc/config/sh/sh.md insn-conditions.md >tmp-extract.c
> 
> Here is the gdb backtrace.(

Can you try after the following two patches:
2006-01-24  Zack Weinberg  <[EMAIL PROTECTED]>

* genautomata.c (process_state_for_insn_equiv_partition):
Use xcalloc for insn_arcs_array.
* vec.h (DEF_VEC_ALLOC_FUNC_I): New set of templates.
(DEF_VEC_ALLOC_I): Use it, not DEF_VEC_ALLOC_FUNC_P.

2006-01-24  Richard Henderson  <[EMAIL PROTECTED]>

* genextract.c (VEC_safe_set_locstr): Take VEC by reference;
update all callers.


I think those will fix your issue.

Thanks,
Andrew Pinski

Re: sh-rtems still broken on head

[Joel Sherrill]

Andrew Pinski wrote:

   


Can you try after the following two patches:
 


Thanks.  It sure it hard to keep up around here. :)

That did it for the sh.  Ignoring the precise svn revision, either 
yesterday

or today, I managed to build and install the following on the head:

arm-rtems4.7: C C++ Ada
avr-rtems4.7:
h8300-rtems4.7  : C C++
i386-rtems4.7   : C C++ Ada
m68k-rtems4.7   : C C++ Ada
mips64-rtems4.7 : C C++ Ada
mips-rtems4.7   : C C++ Ada
powerpc-rtems4.7: C C++ Ada
sh-rtems4.7 : C C++ Ada
sparc-rtems4.7  : C C++ Ada

The avr fails with this:

../../../../../../gcc/newlib/libc/misc/init.c
../../../../../../gcc/newlib/libc/misc/init.c: In function 
'__libc_fini_array':
../../../../../../gcc/newlib/libc/misc/init.c:59: error: unable to find 
a register to spill in class 'BASE_POINTER_REGS'

../../../../../../gcc/newlib/libc/misc/init.c:59: error: this is the insn:
(insn 64 31 32 4 ../../../../../../gcc/newlib/libc/misc/init.c:56 (set 
(mem/c:HI (plus:HI (reg/f:HI 28 r28)

   (const_int 1 [0x1])) [5 S2 A8])
   (reg:HI 24 r24)) 12 {*movhi} (nil)
   (nil))
../../../../../../gcc/newlib/libc/misc/init.c:59: internal compiler 
error: in spill_failure, at reload1.c:1910


Does this look like another case of PR19636 to you with the line number
in reload1.c changing due to code differences since the report was filed?



2006-01-24  Zack Weinberg  <[EMAIL PROTECTED]>

   * genautomata.c (process_state_for_insn_equiv_partition):
   Use xcalloc for insn_arcs_array.
   * vec.h (DEF_VEC_ALLOC_FUNC_I): New set of templates.
   (DEF_VEC_ALLOC_I): Use it, not DEF_VEC_ALLOC_FUNC_P.

2006-01-24  Richard Henderson  <[EMAIL PROTECTED]>

   * genextract.c (VEC_safe_set_locstr): Take VEC by reference;
   update all callers.


I think those will fix your issue.

Thanks,
Andrew Pinski
 

bootstrap broken on solaris8

[Andreas Tobler]

Hello

I can't hide :)

I get the following bootstrap break on solaris 8:

cc1: warnings being treated as errors
insn-automata.c: In function 'internal_insn_latency':
insn-automata.c:1969: warning: implicit declaration of function 
'store_data_bypass_p'

gmake[3]: *** [insn-automata.o] Error 1

The svn version is 110178 and the arch is a sunfire-240.

I guess it has to do with Zack's recent mods.

Thanks,
Andreas

gcc-3.4-20060124 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 3.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-3_4-branch 
revision 110183

You'll find:

gcc-3.4-20060124.tar.bz2  Complete GCC (includes all of below)

gcc-core-3.4-20060124.tar.bz2 C front end and core compiler

gcc-ada-3.4-20060124.tar.bz2  Ada front end and runtime

gcc-g++-3.4-20060124.tar.bz2  C++ front end and runtime

gcc-g77-3.4-20060124.tar.bz2  Fortran 77 front end and runtime

gcc-java-3.4-20060124.tar.bz2 Java front end and runtime

gcc-objc-3.4-20060124.tar.bz2 Objective-C front end and runtime

gcc-testsuite-3.4-20060124.tar.bz2The GCC testsuite

Diffs from 3.4-20060117 are available in the diffs/ subdirectory.

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

Re: [patch] Merge cfo-branch, RTL sequence abstraction (part 1)

[Joern RENNECKE]

===
--- gcc/cfgcleanup.c(revision 108405)
+++ gcc/cfgcleanup.c(working copy)
@@ -1151,11 +1151,43 @@
  return false;
  }

-  /* We don't need to match the rest of edges as above checks should be enough
- to ensure that they are equivalent.  */
+  /* The same checks as in try_crossjump_to_edge. It is required for RTL
+ version of sequence abstraction.  */
+  FOR_EACH_EDGE (e1, ei, bb2->succs)
+{
+  edge e2;
+  edge_iterator ei;
+  basic_block d1 = e1->dest;
+
+  if (FORWARDER_BLOCK_P (d1))
+d1 = EDGE_SUCC (d1, 0)->dest;
+
+  FOR_EACH_EDGE (e2, ei, bb1->succs)
+{
+  basic_block d2 = e2->dest;
+  if (FORWARDER_BLOCK_P (d2))
+d2 = EDGE_SUCC (d2, 0)->dest;
+  if (d1 == d2)
+break;
+}
+
+  if (!e2)
+return false;
+}
+
  return true;
}

These are not 'The same checks as in try_crossjump_to_edge.
try_crossjump_to_edge will crash on a mismatch.
This way of matching of equivalent edges cost quadratic time in the number
of edges, and you just doubled that cost.  This is likely to slow down
compilation of the output of parser generators
If the edges tend to appear in like order, keeping a pointer to the last
find makes sense.
Otherwise, quadratic time cost could be avoided by sorting the edges first.
This might be conditional on the number of edges to avoid slowdown or
simple cases.
If the edges are sorted by pointer, the sort should be used only for the
matching, but not actually affect the edge lists (as otherwise we get
memory-allocation dependent compiler behaviour).
Using extra memory can be avoided by sorting the edges by something
pointer-independent, like destination basic block index, and using
mergesort on the edge chains themselves.

Sorting edges in place and keeping a pointer to the last match can also be
combined to avoid unnecessary sorting without the need for a basic block
flag: The node lists are first compared assuming they are sorted; if this
doesn't give an instant match for a successor, this one successor is
searched linearily.  If that fails, the match fails; if it succeeds, the
two lists - or only the uncompared parts - are sorted, and the sorted list
compared.  (Refinements are possible where usually only one lists needs
sorting if the other list is already sorted, and the comparison picked up
where it was before the re-sort.)

It should be possible to encapsulate this matching with an iterator macro,
to be used like:

edge_match_iterator emi;

FOR_EACH_EDGE_MATCH (e1, e2, emi, bb1, bb2, succs);
if (emi.mismatch)
 return false;

or in try_crossjump_to_
edge:
edge_match_iterator emi;

FOR_EACH_EDGE_MATCH (s, s2, emi, redirect_to, src1, succs)
 {
   s->count += s2->count;
   ...
 }
gcc_assert (!emi.mismatch)




If the exact edge matching is implemented sufficiently fast, there is also
no point in counting various types and matching selected edges first.

+  /* Avoid deleting preseve label when redirecting ABNORMAL edeges.  */
Typo: preseve

Re: insv vs one-bit fields

[Richard Henderson]

On Tue, Jan 24, 2006 at 12:56:51PM -0500, DJ Delorie wrote:
> Ok to apply then?

Yes.


r~

Re: x86-64 linux, gomp ICE in trunk

[Richard Henderson]

On Tue, Jan 24, 2006 at 05:22:12PM +0100, tbp wrote:
> /usr/local/gomp/bin/g++ -fopenmp main.cc -o omp

c++ gomp is not merged to mainline.


r~

Re: insv vs one-bit fields

[DJ Delorie]

Thanks.  Done!

Re: bootstrap broken on solaris8

[Andreas Tobler]

Andreas Tobler wrote:

Hello

I can't hide :)

I get the following bootstrap break on solaris 8:

cc1: warnings being treated as errors
insn-automata.c: In function 'internal_insn_latency':
insn-automata.c:1969: warning: implicit declaration of function 
'store_data_bypass_p'

gmake[3]: *** [insn-automata.o] Error 1

The svn version is 110178 and the arch is a sunfire-240.

I guess it has to do with Zack's recent mods.


Hm, adding "insn-config.h" and "recog.h" to insn-automata.c makes it 
compile. Try now to do it the right way via genautomata.c


Is this correct, Zack?

Index: genautomata.c
===
--- genautomata.c   (revision 110178)
+++ genautomata.c   (working copy)
@@ -9255,7 +9255,9 @@
"#include \"coretypes.h\"\n"
"#include \"tm.h\"\n"
"#include \"rtl.h\"\n"
-   "#include \"insn-attr.h\"\n");
+   "#include \"insn-attr.h\"\n"
+   "#include \"insn-config.h\"\n"
+   "#include \"recog.h\"\n");

   if (VEC_length (decl_t, decls) > 0)
 {

Thanks,
Andreas

Re: Calls to malloc during an exception

[Geoffrey Keating]

This is



The difficulty is thread-safety.  If we had some reliable way of allocating
memory whenever a new thread was created on platforms that don't have TLS,
it would be easy to fix.

Re: Calls to malloc during an exception

[Paolo Carlini]

Geoffrey Keating wrote:

This is


  
Still, can you have a look to the last messages in the audit trail, in 
particulat #6-8? I'm under the impression that the problem is already 
fixed for targets using TLS.


Paolo.

Re: x86-64 linux, gomp ICE in trunk

[tbp]

On 1/25/06, Richard Henderson <[EMAIL PROTECTED]> wrote:
> c++ gomp is not merged to mainline.
Indeed, that makes up for a solid reason not to work.

Should i hold my breath?

Re: x86-64 linux, gomp ICE in trunk

[Diego Novillo]

tbp wrote:
> On 1/25/06, Richard Henderson <[EMAIL PROTECTED]> wrote:
>   
>> c++ gomp is not merged to mainline.
>> 
> Indeed, that makes up for a solid reason not to work.
>
> Should i hold my breath?
>   
A couple more weeks, or you can try the gomp branch.

Re: x86-64 linux, gomp ICE in trunk

[tbp]

On 1/25/06, Diego Novillo <[EMAIL PROTECTED]> wrote:
> A couple more weeks, or you can try the gomp branch.
Thanks, will do.
Hopefully i won't fall for the ICE trick that easily next time.

Re: x86-64 linux, gomp ICE in trunk

[Diego Novillo]

tbp wrote:
> Hopefully i won't fall for the ICE trick that easily next time.
>   
Well, the compiler still shouldn't ICE.  I'll send a fix shortly.

Re: bootstrap broken on solaris8

[Zack Weinberg]

On Wed, Jan 25, 2006 at 12:17:00AM +0100, Andreas Tobler wrote:
> Andreas Tobler wrote:
> >I get the following bootstrap break on solaris 8:
> >
> >cc1: warnings being treated as errors
> >insn-automata.c: In function 'internal_insn_latency':
> >insn-automata.c:1969: warning: implicit declaration of function 
> >'store_data_bypass_p'
[...]
> Hm, adding "insn-config.h" and "recog.h" to insn-automata.c makes it 
> compile. Try now to do it the right way via genautomata.c
> 
> Is this correct, Zack?

Oh, probably.  insn-attrtab.c sees those headers, after all.  Don't forget
to update the dependency list for insn-automata.o in Makefile.in.

zw

Bootstrap failure on sparc*-sun-solaris2.10

[Kaveh R. Ghazi]

I'm getting the following new bootstrap failure on both
sparc-sun-solaris2.10 and sparc64-sun-solaris2.10 when using cc for
stage1:

 > cc -xildoff -xarch=v9 -c   -g -DIN_GCC -DHAVE_CONFIG_H
 >   -DGENERATOR_FILE -I. -Ibuild -I../../egcc-SVN20060124/gcc
 >   -I../../egcc-SVN20060124/gcc/build
 >   --I../../egcc-SVN20060124/gcc/../include -I./../intl
 >   --I../../egcc-SVN20060124/gcc/../libcpp/include
 >   --I/caip/u12/kishgcc/gcc-testing/_gmp64/include
 >   --I../../egcc-SVN20060124/gcc/../libdecnumber -I../libdecnumber -o
 >   -build/gencondmd.o build/gencondmd.c
 > "build/gencondmd.c", line 1943: warning: syntax error:  empty initializer
 > "build/gencondmd.c", line 1943: warning: null dimension: insn_conditions
 > "build/gencondmd.c", line 1951: warning: null dimension: sizeof()
 > cc -xildoff -xarch=v9 -g -DIN_GCC -DHAVE_CONFIG_H -DGENERATOR_FILE -o
 > build/gencondmd \ build/gencondmd.o
 > ../build-sparc64-sun-solaris2.10/libiberty/libiberty.a
 > Undefined   first referenced
 >  symbol in file
 > vec_heap_p_reserve  build/gencondmd.o
 > bitmap_zero_bitsbuild/gencondmd.o
 > vec_gc_p_reservebuild/gencondmd.o
 > vec_gc_o_reservebuild/gencondmd.o
 > ggc_freebuild/gencondmd.o
 > fancy_abort build/gencondmd.o
 > ld: fatal: Symbol referencing errors. No output written to build/gencondmd

At least some of this (e.g. bitmap_zero_bits) is due to uses in static
inline functions where "inline" gets defined to nothing for !GCC and
therefore the function is not eliminated.  I made some progress by
linking with:

build/vec.o build/ggc-none.o $(BUILD_ERRORS)

however I still had a reference to bitmap_zero_bits and I don't see
that a "build" copy of bitmap.o is ever built.  I don't like this
solution anyway because it isn't supposedly necessary to link in the
extra objects during stage2 where we have GCC and inline gets turned
on again.

I'm also not feeling comfy given the warnings about null dimensions
above.

--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: Bootstrap failure on sparc*-sun-solaris2.10

[Andrew Pinski]

On Jan 24, 2006, at 10:29 PM, Kaveh R. Ghazi wrote:


I'm getting the following new bootstrap failure on both
sparc-sun-solaris2.10 and sparc64-sun-solaris2.10 when using cc for
stage1:
At least some of this (e.g. bitmap_zero_bits) is due to uses in static
inline functions where "inline" gets defined to nothing for !GCC and
therefore the function is not eliminated.  I made some progress by
linking with:

build/vec.o build/ggc-none.o $(BUILD_ERRORS)


Not this issue again :(.

I thought I fixed it the last time it came up.

-- Pinski

Re: Bootstrap failure on sparc*-sun-solaris2.10

[Kaveh R. Ghazi]

 > Not this issue again :(.
 > I thought I fixed it the last time it came up.
 > -- Pinski

URL?

--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: Bootstrap failure on sparc*-sun-solaris2.10

[Andrew Pinski]

On Jan 24, 2006, at 10:41 PM, Kaveh R. Ghazi wrote:




Not this issue again :(.
I thought I fixed it the last time it came up.
-- Pinski


URL?



Maybe I did not fix it but it was a problem in the past.

This was PR 18058 for 4.0.0.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18058

-- Pinski

Re: Bootstrap failure on sparc*-sun-solaris2.10

[Zack Weinberg]

On Tue, Jan 24, 2006 at 10:29:08PM -0500, Kaveh R. Ghazi wrote:
> I'm getting the following new bootstrap failure on both
> sparc-sun-solaris2.10 and sparc64-sun-solaris2.10 when using cc for
> stage1:
> 
>  > "build/gencondmd.c", line 1943: warning: syntax error:  empty initializer
>  > "build/gencondmd.c", line 1943: warning: null dimension: insn_conditions
>  > "build/gencondmd.c", line 1951: warning: null dimension: sizeof()
>  > cc -xildoff -xarch=v9 -g -DIN_GCC -DHAVE_CONFIG_H -DGENERATOR_FILE -o
>  > build/gencondmd \ build/gencondmd.o
>  > ../build-sparc64-sun-solaris2.10/libiberty/libiberty.a
>  > Undefined   first referenced
>  >  symbol in file
>  > vec_heap_p_reserve  build/gencondmd.o
>  > bitmap_zero_bitsbuild/gencondmd.o
>  > vec_gc_p_reservebuild/gencondmd.o
>  > vec_gc_o_reservebuild/gencondmd.o
>  > ggc_freebuild/gencondmd.o
>  > fancy_abort build/gencondmd.o

I'm not entirely understanding why this breaks now when insn-conditions.o
was fine, but a potential big-hammer fix is to put
#if GCC_VERSION >= 3001 ... #endif around most of the includes, like in the
appended patch.  Would you please try it?

zw

* genconditions.c (write_header): In generated code, #if
out all headers and fake declarations, except bconfig.h
and system.h, when not compiling with GCC >= 3.0.1.
(write_conditions): Tweak commentary in generated code.

==
--- genconditions.c (revision 110239)
+++ genconditions.c (local)
@@ -52,9 +52,14 @@ write_header (void)
machine description file.  */\n\
 \n\
 #include \"bconfig.h\"\n\
-#include \"insn-constants.h\"\n");
+#include \"system.h\"\n");
 
   puts ("\
+/* It is necessary, but not entirely safe, to include the headers below\n\
+   in a generator program.  As a defensive measure, don't do so when the\n\
+   table isn't going to have anything in it.  */\n\
+#if GCC_VERSION >= 3001\n\
+\n\
 /* Do not allow checking to confuse the issue.  */\n\
 #undef ENABLE_CHECKING\n\
 #undef ENABLE_TREE_CHECKING\n\
@@ -64,9 +69,9 @@ write_header (void)
 #undef ENABLE_GC_ALWAYS_COLLECT\n");
 
   puts ("\
-#include \"system.h\"\n\
 #include \"coretypes.h\"\n\
 #include \"tm.h\"\n\
+#include \"insn-constants.h\"\n\
 #include \"rtl.h\"\n\
 #include \"tm_p.h\"\n\
 #include \"function.h\"\n");
@@ -97,7 +102,9 @@ write_header (void)
 /* Dummy external declarations.  */\n\
 extern rtx insn;\n\
 extern rtx ins1;\n\
-extern rtx operands[];\n");
+extern rtx operands[];\n\
+\n\
+#endif /* gcc >= 3.0.1 */\n");
 }
 
 /* Write out one entry in the conditions table, using the data pointed
@@ -142,18 +149,18 @@ write_conditions (void)
   puts ("\
 /* This table lists each condition found in the machine description.\n\
Each condition is mapped to its truth value (0 or 1), or -1 if that\n\
-   cannot be calculated at compile time. */\n\
-\n\
-static const struct c_test insn_conditions[] = {\n \
-/* If we don't have __builtin_constant_p, or it's not acceptable in array\n\
+   cannot be calculated at compile time.\n\
+   If we don't have __builtin_constant_p, or it's not acceptable in array\n\
initializers, fall back to assuming that all conditions potentially\n\
vary at run time.  It works in 3.0.1 and later; 3.0 only when not\n\
optimizing.  */\n\
-#if GCC_VERSION >= 3001");
+\n\
+static const struct c_test insn_conditions[] = {\n\
+#if GCC_VERSION >= 3001\n");
 
   traverse_c_tests (write_one_condition, 0);
 
-  puts ("#endif\n};\n");
+  puts ("\n#endif /* gcc >= 3.0.1 */\n};\n");
 }
 
 /* Emit code which will convert the C-format table to a

Re: Bootstrap failure on sparc*-sun-solaris2.10

[Kaveh R. Ghazi]

 > I'm not entirely understanding why this breaks now when
 > insn-conditions.o was fine, but a potential big-hammer fix is to put
 > #if GCC_VERSION >= 3001 ... #endif around most of the includes, like
 > in the appended patch.  Would you please try it?
 > zw
 > 
 >  * genconditions.c (write_header): In generated code, #if
 >  out all headers and fake declarations, except bconfig.h
 >  and system.h, when not compiling with GCC >= 3.0.1.
 >  (write_conditions): Tweak commentary in generated code.

Okay, now I get:

   cc -c -g -DIN_GCC -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild
 -I../../egcc-SVN20060124/gcc -I../../egcc-SVN20060124/gcc/build
 -I../../egcc-SVN20060124/gcc/../include
 -I../../egcc-SVN20060124/gcc/../libcpp/include
 -I../../egcc-SVN20060124/gcc/../libdecnumber -I../libdecnumber -o
 build/gencondmd.o build/gencondmd.c
   "build/gencondmd.c", line 60: incomplete struct/union/enum c_test: 
insn_conditions
   "build/gencondmd.c", line 1952: warning: syntax error:  empty initializer
   "build/gencondmd.c", line 1952: cannot recover from previous errors
   cc: acomp failed for build/gencondmd.c
   make[3]: *** [build/gencondmd.o] Error 2
   
(I'm going to sleep, so I won't be able to test anything more until
tomorrow.)

--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: x86-64 linux, gomp ICE in trunk

[tbp]

On 1/25/06, Diego Novillo <[EMAIL PROTECTED]> wrote:
> Well, the compiler still shouldn't ICE.  I'll send a fix shortly.
I know i've exhausted my pseudo-ICE quota for the day, but i have
another candidate knocking at the door with insistence:
src/raytrace_packet.cpp: In member function 'void rt::raytracer_t::prender()':
src/raytrace_packet.cpp:1411: internal compiler error: Segmentation fault
Please submit a full bug report

# /usr/local/gomp/bin/g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr/local/gomp
--enable-languages=c++ --enable-threads=posix --with-system-zlib
--enable-__cxa_atexit --disable-multilib --enable-bootstrap --with-gcc
--with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 4.2.0-gomp-20050608-branch 20060119 (experimental) (merged 20060119)

While i'm sure i'm terribly wrong one way or another, i'd apreciate
some pointers.

Re: bootstrap broken on solaris8

[Andreas Tobler]

Zack Weinberg wrote:

On Wed, Jan 25, 2006 at 12:17:00AM +0100, Andreas Tobler wrote:

Andreas Tobler wrote:

I get the following bootstrap break on solaris 8:

cc1: warnings being treated as errors
insn-automata.c: In function 'internal_insn_latency':
insn-automata.c:1969: warning: implicit declaration of function 
'store_data_bypass_p'

[...]
Hm, adding "insn-config.h" and "recog.h" to insn-automata.c makes it 
compile. Try now to do it the right way via genautomata.c


Is this correct, Zack?


Oh, probably.  insn-attrtab.c sees those headers, after all.  Don't forget
to update the dependency list for insn-automata.o in Makefile.in.


Yeah, in the test now.

I'll send a patch later today.

Thanks,
Andreas

Re: Problem with gfortran or did I messsed up GMP installation?

[Aleksandar Milivojevic]

Eric Botcazou wrote:

So, the question is, did I broke something by attempting to have both
32-bit and 64-bit GMP library installed simultaniously?  Did I miss
anything needed to have both 32-bit and 64-bit GMP available on the
system?


Do not install both 32-bit and 64-bit GMP, you only need one of them:
sparc-sun-solaris2.* compiler -> 32-bit GMP
sparc64-sun-solaris2.* compiler -> 64-bit GMP.


OK, so I reinstalled GMP.  Now I have only 32-bit GMP on the system. 
Stock gmp.h file.  Recompiled gcc (4.0.2), target sparc-sun-solaris2.9. 
 Got exactly same thing.  When I compile simple looping hello world 
program (source in my first post), it exits right away.  When I use 
-m64, it works OK (loops forever printing "hello world").


Now, the interesting part.  I also built gcc 4.0.2 on 
sparc-sun-solaris2.6.  If I compile the "hello world" program on it 
(obviously it will be 32-bit), it runs just fine (prints hello world in 
endless loop).  If I copy the executable to Solaris 2.9 system and run 
it, it exits immediately.


Hmph...  Interesting...  Looks like the problem is in libgfortran?

Should I file bug on bugzilla?

Re: Patch: Boehm GC 6.6 merge

[Ranjit Mathew]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bryce McKinlay wrote:
> This patch merges the GC 6.6 sources into the libgcj trunk. Two patches 
[...]

This little bit in "boehm-gc/include/private/gcconfig.h" (line 306):
- - 8< -
> +# else
> +#if defined(__i386__)
> +#  define I386
>   --> Not really supported, but at least we recognize it.
> +#endif
- - 8< -
causes a bootstrap failure for me on i686-pc-linux-gnu.
Note that the "Not really" bit is not inside a comment.

Thanks,
Ranjit.

- --
Ranjit Mathew  Email: rmathew AT gmail DOT com

Bangalore, INDIA.Web: http://rmathew.com/


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD1xSEYb1hx2wRS48RAlI1AJ9mo12R3N/nB7XhAcxdixECUHKFrACeLdkG
WEVT000tFOAJIUc4Fst15fA=
=+Ryg
-END PGP SIGNATURE-

Re: Problem with gfortran or did I messsed up GMP installation?

[Eric Botcazou]

> Now, the interesting part.  I also built gcc 4.0.2 on
> sparc-sun-solaris2.6.  If I compile the "hello world" program on it
> (obviously it will be 32-bit), it runs just fine (prints hello world in
> endless loop).  If I copy the executable to Solaris 2.9 system and run
> it, it exits immediately.

Please make sure every bit of the hacked GMP has been wiped out on Solaris 9.

> Hmph...  Interesting...  Looks like the problem is in libgfortran?

I don't know of any such problem with libgfortran on SPARC/Solaris.

> Should I file bug on bugzilla?

Sure, if you can reproduce it after cleaning up the Solaris 9 machine.

-- 
Eric Botcazou

Re: bootstrap broken on solaris8

[Andreas Tobler]

Zack Weinberg wrote:

On Wed, Jan 25, 2006 at 12:17:00AM +0100, Andreas Tobler wrote:

Andreas Tobler wrote:

I get the following bootstrap break on solaris 8:

cc1: warnings being treated as errors
insn-automata.c: In function 'internal_insn_latency':
insn-automata.c:1969: warning: implicit declaration of function 
'store_data_bypass_p'

[...]
Hm, adding "insn-config.h" and "recog.h" to insn-automata.c makes it 
compile. Try now to do it the right way via genautomata.c


Is this correct, Zack?


Oh, probably.  insn-attrtab.c sees those headers, after all.


Well, just for my understanding, insn-attrtab.c is generated by 
genattrtab which has these includes. insn-automata.c instead is 
generated by genautomata, which lacks these includes. So I think it 
should be right to add these includes.


Andreas

P.S, patch in testing.

Re: bootstrap broken on solaris8

[Andreas Tobler]

Andreas Tobler wrote:

Zack Weinberg wrote:

On Wed, Jan 25, 2006 at 12:17:00AM +0100, Andreas Tobler wrote:

Andreas Tobler wrote:

I get the following bootstrap break on solaris 8:

cc1: warnings being treated as errors
insn-automata.c: In function 'internal_insn_latency':
insn-automata.c:1969: warning: implicit declaration of function 
'store_data_bypass_p'

[...]
Hm, adding "insn-config.h" and "recog.h" to insn-automata.c makes it 
compile. Try now to do it the right way via genautomata.c


Is this correct, Zack?


Oh, probably.  insn-attrtab.c sees those headers, after all.  Don't 
forget

to update the dependency list for insn-automata.o in Makefile.in.


Yeah, in the test now.

I'll send a patch later today.


Ok, here the patch, tested with bootstrap on sparc-solaris8.

Ok for main?

Andreas

2006-01-25  Andreas Tobler  <[EMAIL PROTECTED]>

* genautomata.c (main): Add insn-config.h and recog.h to the
include list.
* Makefile.in (insn-automata.o): Adjust dependencies for the above
includes.
Index: Makefile.in
===
--- Makefile.in (revision 110205)
+++ Makefile.in (working copy)
@@ -2640,7 +2640,7 @@
   $(TM_H) $(RTL_H) $(REGS_H) real.h output.h $(INSN_ATTR_H)\
   insn-config.h toplev.h $(RECOG_H) $(TM_P_H) $(FLAGS_H)
 insn-automata.o : insn-automata.c $(CONFIG_H) $(SYSTEM_H) coretypes.h  \
-  $(TM_H) $(RTL_H) $(INSN_ATTR_H)
+  $(TM_H) $(RTL_H) $(INSN_ATTR_H) insn-config.h $(RECOG_H)
 insn-emit.o : insn-emit.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H)  \
   $(RTL_H) $(EXPR_H) real.h output.h insn-config.h $(OPTABS_H) \
   reload.h $(RECOG_H) toplev.h $(FUNCTION_H) $(FLAGS_H) hard-reg-set.h \
Index: genautomata.c
===
--- genautomata.c   (revision 110205)
+++ genautomata.c   (working copy)
@@ -9255,7 +9255,9 @@
"#include \"coretypes.h\"\n"
"#include \"tm.h\"\n"
"#include \"rtl.h\"\n"
-   "#include \"insn-attr.h\"\n");
+   "#include \"insn-attr.h\"\n"
+   "#include \"insn-config.h\"\n"
+   "#include \"recog.h\"\n");
 
   if (VEC_length (decl_t, decls) > 0)
 {