Re: GCC 4.1.1 RC1

[Rainer Emrich]

H. J. Lu schrieb:
> On Fri, May 19, 2006 at 06:00:09PM +0200, Rainer Emrich wrote:
>> Bootstrap failure in gnattools for ia64-unknown-linux-gnu. Complaining on
>> missing libunwind.so.7
>>
> 
> It is
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17464
> 
> 
> H.J.
> 

Is there any workaround?

I'm a little bit confused about this issue, because gcc-4.1.0 was built without
any problems including ada.

Rainer

-- 
Mit freundlichen Grüßen/Best Regards

Dipl.-Ing. Rainer Emrich
Leiter IT/Softwareentwicklung
TECOSIM Technische Simulation 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

www.tecosim.com
best partner for simulation



signature.asc
Description: OpenPGP digital signature

Re: Revert patch for MIPS TImode functions for 4.1.1

[Richard Sandiford]

Roger Sayle <[EMAIL PROTECTED]> writes:
> On Fri, 19 May 2006, Mark Mitchell wrote:
>> I'm evaluating the options.  It would be helpful if someone has time to
>> apply and test Richard's patch on 4.1, as that would let us know whether
>> that option is viable as well.
>
> I've bootstrapped and regression tested a backport of Richard's patch
> against the gcc-4_1-branch on mips-sgi-irix6.5 with no new failures.
> His mainline change also has no testsuite problems on the same machine.
>
> The patch applies cleanly, with the exception of some mklibgcc.in
> hunks, due to the fact that the _floatun* symbols were added to 4.2
> and aren't available in 4.1.x libgcc, and that the LIB2FUNCS_EXCLUDE
> functionality isn't on the branch.  For the record, the final
> mklibgcc.in changes that I tested are attached to this e-mail.

Thanks.  I'll test this same version on mipsisa64-elf and
mips64-linux-gnu.

Richard

Re: SVN: Checksum mismatch problem

[Bruce Korb]

Hi Bob,

On 5/21/06, Bob Proulx <[EMAIL PROTECTED]> wrote:

Bruce Korb wrote:
> Philip Martin wrote:
> >The capital 'I' in 'Is' looks wrong.
> ...
> That's what I wanted:  a nice, simple answer that was short of re-pulling
> the entire repository. [...]

Sometimes I run commands to walk down the filesystem and do things to
the files in them.  With CVS this was never a problem, never a false
hit, because CVS did not keep a pristine copy of the database around.


Except sometimes in the CVS/Base directory.  :)

I do that also, but I am also careful to prune repository
directories (CVS, .svn or SCCS even).  I rather doubt it is my RAM,
BTW.  Perhaps a disk sector, but I'll never know now.  (Were it RAM,
the failure would be random and not just the one file.)  The original
data were rm-ed and replaced with a new pull of the Ada code.


I have no idea if this is possibly the type of thing that happened to
you or not.


In any event, since my GCC work is constrained to fixincludes, I have
no need of recursive mass edits, so I haven't used the technique with
that code.  Especially one that would miscapitalize a sentence.  :)

Thanks - Bruce

Re: Revert patch for MIPS TImode functions for 4.1.1

[Joseph S. Myers]

On Sun, 21 May 2006, Roger Sayle wrote:

> The patch applies cleanly, with the exception of some mklibgcc.in
> hunks, due to the fact that the _floatun* symbols were added to 4.2
> and aren't available in 4.1.x libgcc, and that the LIB2FUNCS_EXCLUDE
> functionality isn't on the branch.  For the record, the final
> mklibgcc.in changes that I tested are attached to this e-mail.

This backport doesn't appear to be of the correct patch version, the final 
patch version used LIB2_SIDITI_CONV_FUNCS instead of 
LIB2LITERAL_CONVERSION_MODES.

The patch (both that on mainline and this backport) includes _floatdidf in 
both the hardcoded lib2funcs list and that generated from lists of modes.  
This means that only one of the _floatdidf entries in the list gets 
deleted if _floatdidf is in LIB1ASMFUNCS, so causing a build error on such 
platforms (e.g. arm-none-linux-gnueabi, once a separate problem building 
mainline glibc with mainline GCC is fixed).

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: GCC 4.1.1 RC1

[H. J. Lu]

On Mon, May 22, 2006 at 09:39:33AM +0200, Rainer Emrich wrote:
> H. J. Lu schrieb:
> > On Fri, May 19, 2006 at 06:00:09PM +0200, Rainer Emrich wrote:
> >> Bootstrap failure in gnattools for ia64-unknown-linux-gnu. Complaining on
> >> missing libunwind.so.7
> >>
> > 
> > It is
> > 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17464
> > 
> > 
> > H.J.
> > 
> 
> Is there any workaround?
> 

It can be fixed if we want to.


H.J.

Re: GCC 4.1.1 RC1 -- bootstrap error sparc-sun-solaris2.8

[Marc W. Mengel]

This is probably very low priority, maybe a release note?

In the dim-and-musty-systems department, using
cc:  Sun WorkShop 6 update 1 C 5.2 2000/09/11

One gets:

cc -c   -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC 
-DHAVE_CONFIG_H -I. -I. -I../../../gcc-4.1.1-20060517/gcc 
-I../../../gcc-4.1.1-20060517/gcc/. 
-I../../../gcc-4.1.1-20060517/gcc/../include -I./../intl 
-I../../../gcc-4.1.1-20060517/gcc/../libcpp/include 
../../../gcc-4.1.1-20060517/gcc/tree-ssa-structalias.c -o 
tree-ssa-structalias.o
"../../../gcc-4.1.1-20060517/gcc/tree-ssa-structalias.c", line 1615: 
warning: end-of-loop code not reached

cc: Fatal error in /opt/SUNWspro/bin/../WS6U1/bin/acomp
Status 138
gmake[3]: *** [tree-ssa-structalias.o] Error 138

Building tree-ssa-structalias.o with an older gcc works fine.  I'll try 
to look at it more this afternoon and see if I can put in a patch.


Marc Mengel <[EMAIL PROTECTED]>

Re: GCC 4.1.1 RC1 -- bootstrap error sparc-sun-solaris2.8

[Andrew Pinski]

On May 22, 2006, at 7:46 AM, Marc W. Mengel wrote:



This is probably very low priority, maybe a release note?


Or maybe report this to Sun instead?

In the dim-and-musty-systems department, using
cc:  Sun WorkShop 6 update 1 C 5.2 2000/09/11

One gets:

cc -c   -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC - 
DHAVE_CONFIG_H -I. -I. -I../../../gcc-4.1.1-20060517/gcc -I../../../ 
gcc-4.1.1-20060517/gcc/. -I../../../gcc-4.1.1-20060517/gcc/../ 
include -I./../intl -I../../../gcc-4.1.1-20060517/gcc/../libcpp/ 
include ../../../gcc-4.1.1-20060517/gcc/tree-ssa-structalias.c -o  
tree-ssa-structalias.o
"../../../gcc-4.1.1-20060517/gcc/tree-ssa-structalias.c", line  
1615: warning: end-of-loop code not reached

cc: Fatal error in /opt/SUNWspro/bin/../WS6U1/bin/acomp
Status 138
gmake[3]: *** [tree-ssa-structalias.o] Error 138

Building tree-ssa-structalias.o with an older gcc works fine.  I'll  
try to look at it more this afternoon and see if I can put in a patch.


-- Pinski

Re: GCC 4.1.1 RC1 -- bootstrap error alpha-dec-osf4.0

[Marc W. Mengel]

This is probably very low priority, maybe a release note?

In the dim-and-musty-systems department, using
Compaq C V6.1-120 on Digital UNIX V4.0G (Rev. 1530)

We get:
cc: Error: 
/tmp/build-gcc-v4_1_1/src/gcc-4.1.1-20060517/libiberty/alloca.c, line 
162: In this declaration, the type of "C_alloca" is not compatible with 
the type of a previous declaration of "C_alloca" at line number 559 in 
file 
/tmp/build-gcc-v4_1_1/src/gcc-4.1.1-20060517/libiberty/../include/libiberty.h. 
(notcompat)

C_alloca (size_t size)
^
gmake[1]: *** [alloca.o] Error 1

So it looks like include/libiberty.h should define it as a PTR also, 
since ansidecl.h declares it differently if you're an old-school C 
compiler...


Marc

Re: GCC 4.1.1 RC1 -- second bootstrap error alpha-dec-osf4.0

[Marc W. Mengel]

This is probably very low priority, maybe a release note?

In the dim-and-musty-systems department, using
Compaq C V6.1-120 on Digital UNIX V4.0G (Rev. 1530)

We get:

c -c -DHAVE_CONFIG_H -g  -I. 
-I/tmp/build-gcc-v4_1_1/src/gcc-4.1.1-20060517/libiberty/../include 
/tmp/build-gcc-v4_1_1/src/gcc-4.1.1-20060517/libiberty/concat.c -o concat.o
cc: Warning: 
/tmp/build-gcc-v4_1_1/src/gcc-4.1.1-20060517/libiberty/concat.c, line 
105: Too few actual parameters in macro call. (toofewactuals)

  VA_OPEN (args, first);
--^
cc: Error: 
/tmp/build-gcc-v4_1_1/src/gcc-4.1.1-20060517/libiberty/concat.c, line 
105: Identifier expected but not found. (idexpected)

  VA_OPEN (args, first);
--^
cc: Warning: 
/tmp/build-gcc-v4_1_1/src/gcc-4.1.1-20060517/libiberty/concat.c, line 
120: Too few actual parameters in macro call. (toofewactuals)

  VA_OPEN (args, first);
--^

Not seeing the bug just yet, something funky with varargs...  Compiles 
with older gcc just fine...


Marc

Re: GCC 4.1.1 RC1 -- second bootstrap error alpha-dec-osf4.0

[Andrew Pinski]

On May 22, 2006, at 8:24 AM, Marc W. Mengel wrote:



This is probably very low priority, maybe a release note?

In the dim-and-musty-systems department, using
Compaq C V6.1-120 on Digital UNIX V4.0G (Rev. 1530)


GCC 4.0.x and above only support compiling with ansi C.

-- Pinski

Re: Revert patch for MIPS TImode functions for 4.1.1

[Richard Sandiford]

"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> The patch (both that on mainline and this backport) includes _floatdidf in 
> both the hardcoded lib2funcs list and that generated from lists of modes.  
> This means that only one of the _floatdidf entries in the list gets 
> deleted if _floatdidf is in LIB1ASMFUNCS, so causing a build error on such 
> platforms (e.g. arm-none-linux-gnueabi, once a separate problem building 
> mainline glibc with mainline GCC is fixed).

Argh!  That was very sloppy of me, sorry.  I've committed the patch below
as obvious after testing on i686-pc-linux-gnu.

Richard


* mklibgcc.in (lib2funcs): Remove _floatdidf from initial assignment.

Index: gcc/mklibgcc.in
===
--- gcc/mklibgcc.in (revision 113979)
+++ gcc/mklibgcc.in (working copy)
@@ -85,7 +85,7 @@ done
 # set to .   is the name of the associated object file
 
 lib2funcs='_muldi3 _negdi2 _lshrdi3 _ashldi3 _ashrdi3
-   _cmpdi2 _ucmpdi2 _floatdidf _clear_cache
+   _cmpdi2 _ucmpdi2 _clear_cache
_enable_execute_stack _trampoline __main _absvsi2 _absvdi2 _addvsi3
_addvdi3 _subvsi3 _subvdi3 _mulvsi3 _mulvdi3 _negvsi2 _negvdi2 _ctors
_ffssi2 _ffsdi2 _clz _clzsi2 _clzdi2 _ctzsi2 _ctzdi2 _popcount_tab

Re: GCC 4.1.1 RC1 -- third bootstrap error alpha-dec-osf4.0

[Marc W. Mengel]

This is probably very low priority, maybe a release note?

In the dim-and-musty-systems department, using

Compaq C V6.1-120 on Digital UNIX V4.0G (Rev. 1530)

We get:
cc -c -DHAVE_CONFIG_H -g  -I. 
-I/tmp/build-gcc-v4_1_1/src/gcc-4.1.1-20060517/libiberty/../include 
/tmp/build-gcc-v4_1_1/src/gcc-4.1.1-20060517/libiberty/hashtab.c -o 
hashtab.o
cc: Error: 
/tmp/build-gcc-v4_1_1/src/gcc-4.1.1-20060517/libiberty/hashtab.c, line 
197: In this declaration, parameter 1 has a different type than 
specified in an earlier declaration of this function. (mismatparam)

hash_pointer (const PTR p)
^
cc: Error: 
/tmp/build-gcc-v4_1_1/src/gcc-4.1.1-20060517/libiberty/hashtab.c, line 
197: In this declaration, the type of "hash_pointer" is not compatible 
with the type of a previous declaration of "hash_pointer" at line number 
71 in file 
/tmp/build-gcc-v4_1_1/src/gcc-4.1.1-20060517/libiberty/hashtab.c. 
(notcompat)

hash_pointer (const PTR p)
^
cc: Error: 
/tmp/build-gcc-v4_1_1/src/gcc-4.1.1-20060517/libiberty/hashtab.c, line 
205: In this declaration, parameter 1 has a different type than 
specified in an earlier declaration of this function. (mismatparam)

eq_pointer (const PTR p1, const PTR p2)
^


It goes on like this for quite a while.  LOTS of inconsisencies of using 
PTR one place and void * in another...


Marc Mengel <[EMAIL PROTECTED]>

Re: Re: GCC 4.1.1 RC1 -- third bootstrap error alpha-dec-osf4.0

[Marc W. Mengel]

So basically on alpha-dec-osf4.0 with Compaq C v6.1-120, I just
had to use an older gcc to build libiberty.  Everything chokes with
PTR==(char *) vs (void *) all over the place...

Marc W. Mengel wrote:



This is probably very low priority, maybe a release note?

In the dim-and-musty-systems department, using

Compaq C V6.1-120 on Digital UNIX V4.0G (Rev. 1530)

We get:
cc -c -DHAVE_CONFIG_H -g  -I. 
-I/tmp/build-gcc-v4_1_1/src/gcc-4.1.1-20060517/libiberty/../include 
/tmp/build-gcc-v4_1_1/src/gcc-4.1.1-20060517/libiberty/hashtab.c -o 
hashtab.o
cc: Error: 
/tmp/build-gcc-v4_1_1/src/gcc-4.1.1-20060517/libiberty/hashtab.c, line 
197: In this declaration, parameter 1 has a different type than 
specified in an earlier declaration of this function. (mismatparam)

hash_pointer (const PTR p)
^
cc: Error: 
/tmp/build-gcc-v4_1_1/src/gcc-4.1.1-20060517/libiberty/hashtab.c, line 
197: In this declaration, the type of "hash_pointer" is not compatible 
with the type of a previous declaration of "hash_pointer" at line number 
71 in file 
/tmp/build-gcc-v4_1_1/src/gcc-4.1.1-20060517/libiberty/hashtab.c. 
(notcompat)

hash_pointer (const PTR p)
^
cc: Error: 
/tmp/build-gcc-v4_1_1/src/gcc-4.1.1-20060517/libiberty/hashtab.c, line 
205: In this declaration, parameter 1 has a different type than 
specified in an earlier declaration of this function. (mismatparam)

eq_pointer (const PTR p1, const PTR p2)
^


It goes on like this for quite a while.  LOTS of inconsisencies of using 
PTR one place and void * in another...


Marc Mengel <[EMAIL PROTECTED]>

Re: Revert patch for MIPS TImode functions for 4.1.1

[Richard Sandiford]

Richard Sandiford <[EMAIL PROTECTED]> writes:
> Roger Sayle <[EMAIL PROTECTED]> writes:
>> On Fri, 19 May 2006, Mark Mitchell wrote:
>>> I'm evaluating the options.  It would be helpful if someone has time to
>>> apply and test Richard's patch on 4.1, as that would let us know whether
>>> that option is viable as well.
>>
>> I've bootstrapped and regression tested a backport of Richard's patch
>> against the gcc-4_1-branch on mips-sgi-irix6.5 with no new failures.
>> His mainline change also has no testsuite problems on the same machine.
>>
>> The patch applies cleanly, with the exception of some mklibgcc.in
>> hunks, due to the fact that the _floatun* symbols were added to 4.2
>> and aren't available in 4.1.x libgcc, and that the LIB2FUNCS_EXCLUDE
>> functionality isn't on the branch.  For the record, the final
>> mklibgcc.in changes that I tested are attached to this e-mail.
>
> Thanks.  I'll test this same version on mipsisa64-elf and
> mips64-linux-gnu.

As Joseph said, that patch used the old makefile variable name, not the
revised LIBGCC2_SIDITI_CONV_FUNCS.  Here's what I ended up testing.
It includes the fix for the duplicate _floatdidf.

Tested against gcc-4_1-branch on mips64-linux-gnu and mipsisa64-elf.
Mark, what do you think?

Richard


PR target/27681
* libgcc2.c (MIN_UNITS_PER_WORD): Move default definition from
libgcc2.h.
(LIBGCC2_UNITS_PER_WORD): Provide default definition, using old
MIN_UNITS_PER_WORD logic from libgcc2.h.  Do nothing if
LIBGCC2_UNITS_PER_WORD > MIN_UNITS_PER_WORD.
* libgcc2.h (MIN_UNITS_PER_WORD): Remove definition from here.
Use LIBGCC2_UNITS_PER_WORD rather than MIN_UNITS_PER_WORD to
determine the size of Wtype, etc.
* mklibgcc.in (LIB2_SIDITI_CONV_FUNCS): New argument.
(swfloatfuncs): New variable.
(dwfloatfuncs): Likewise.
(lib2funcs): Remove floating-point conversion functions from
initial assignment.  Use LIB2_SIDITI_CONV_FUNCS to determine
the set of conversion routines needed.  Allow entries to specify
an object name, filename and word size.  Update users accordingly.
* Makefile.in (libgcc.mk): Pass LIB2_SIDITI_CONV_FUNCS.
* config/mips/t-mips (LIB2_SIDITI_CONV_FUNCS): Define.

Revert:

2006-02-08  Roger Sayle  <[EMAIL PROTECTED]>

PR target/22209
* config/fixtfdi.c: New libgcc source file.
* config/fixunstfdi.c: New source file.
* config/floatditf.c: New source file.
* config/floatunditf.c: New souce file.
* config/mips/t-iris6 (LIB2FUNCS_EXTRA): Include the new source
files above instead of config/mips/_tilib.c.
* config/mips/t-linux64 (LIB2FUNCS_EXTRA): Likewise.

Index: gcc/libgcc2.c
===
--- gcc/libgcc2.c   (revision 113971)
+++ gcc/libgcc2.c   (working copy)
@@ -40,6 +40,23 @@ #define ATTRIBUTE_HIDDEN  __attribute__ 
 #define ATTRIBUTE_HIDDEN
 #endif
 
+#ifndef MIN_UNITS_PER_WORD
+#define MIN_UNITS_PER_WORD UNITS_PER_WORD
+#endif
+
+#ifndef LIBGCC2_UNITS_PER_WORD
+# if MIN_UNITS_PER_WORD > 4
+#  define LIBGCC2_UNITS_PER_WORD 8
+# elif (MIN_UNITS_PER_WORD > 2 \
+|| (MIN_UNITS_PER_WORD > 1 && LONG_LONG_TYPE_SIZE > 32))
+#  define LIBGCC2_UNITS_PER_WORD 4
+# else
+#  define LIBGCC2_UNITS_PER_WORD MIN_UNITS_PER_WORD
+# endif
+#endif
+
+#if LIBGCC2_UNITS_PER_WORD <= MIN_UNITS_PER_WORD
+
 #include "libgcc2.h"
 
 #ifdef DECLARE_LIBRARY_RENAMES
@@ -2010,3 +2027,4 @@ func_ptr __DTOR_LIST__[2] = {0, 0};
 #endif
 #endif /* no INIT_SECTION_ASM_OP and not CTOR_LISTS_DEFINED_EXTERNALLY */
 #endif /* L_ctors */
+#endif /* LIBGCC2_UNITS_PER_WORD <= MIN_UNITS_PER_WORD */
Index: gcc/libgcc2.h
===
--- gcc/libgcc2.h   (revision 113971)
+++ gcc/libgcc2.h   (working copy)
@@ -79,10 +79,6 @@ #define LIBGCC2_HAS_TF_MODE \
   (BITS_PER_UNIT == 8 && LIBGCC2_LONG_DOUBLE_TYPE_SIZE == 128)
 #endif
 
-#ifndef MIN_UNITS_PER_WORD
-#define MIN_UNITS_PER_WORD UNITS_PER_WORD
-#endif
-
 /* In the first part of this file, we are interfacing to calls generated
by the compiler itself.  These calls pass values into these routines
which have very specific modes (rather than very specific types), and
@@ -155,7 +151,7 @@ #define double bogus_type
turns out that no platform would define COMPAT_DIMODE_TRAPPING_ARITHMETIC
if it existed.  */
 
-#if MIN_UNITS_PER_WORD > 4
+#if LIBGCC2_UNITS_PER_WORD == 8
 #define W_TYPE_SIZE (8 * BITS_PER_UNIT)
 #define Wtype  DItype
 #define UWtype UDItype
@@ -166,8 +162,7 @@ #define UDWtype UTItype
 #define __NW(a,b)  __ ## a ## di ## b
 #define __NDW(a,b) __ ## a ## ti ## b
 #define COMPAT_SIMODE_TRAPPING_ARITHMETIC
-#elif MIN_UNITS_PER_WORD > 2 \
-  || (MIN_UNITS_PER_WORD > 1 && LONG_LONG_TYPE_SIZE > 32)
+#elif LIBGCC2_UNITS_PER_WORD == 4
 #define W_TYPE_SIZE (4 * BIT

Re: PATCH: Update src/intl from gcc/intl

[DJ Delorie]

> I hereby request that you add automatic intl/ merging to your script. :-)

Ok :-)

Re: GCC 4.1.1 RC1 -- bootstrap error sparc-sun-solaris2.8

[Eric Botcazou]

> This is probably very low priority, maybe a release note?
>
> In the dim-and-musty-systems department, using
> cc:  Sun WorkShop 6 update 1 C 5.2 2000/09/11

Too old a compiler. :-)

> One gets:
>
> cc -c   -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC
> -DHAVE_CONFIG_H -I. -I. -I../../../gcc-4.1.1-20060517/gcc
> -I../../../gcc-4.1.1-20060517/gcc/.
> -I../../../gcc-4.1.1-20060517/gcc/../include -I./../intl
> -I../../../gcc-4.1.1-20060517/gcc/../libcpp/include
> ../../../gcc-4.1.1-20060517/gcc/tree-ssa-structalias.c -o
> tree-ssa-structalias.o
> "../../../gcc-4.1.1-20060517/gcc/tree-ssa-structalias.c", line 1615:
> warning: end-of-loop code not reached
> cc: Fatal error in /opt/SUNWspro/bin/../WS6U1/bin/acomp
> Status 138
> gmake[3]: *** [tree-ssa-structalias.o] Error 138

What happens if you configure with CC="cc -erroff"?

-- 
Eric Botcazou

Re: Revert patch for MIPS TImode functions for 4.1.1

[Mark Mitchell]

Richard Sandiford wrote:

> Tested against gcc-4_1-branch on mips64-linux-gnu and mipsisa64-elf.
> Mark, what do you think?

I'm a bit torn.  On the one hand, it doesn't look like there is any
other reason to do a 4.1.1 RC2.  So, we could declare that Fortran is
not release-critical, and just release 4.1.1.  On the other hand, it
seems a shame to have a release in which a popular programming language
is so horribly broken on a reasonably popular platform.

You indicated off-line that your biggest concern with the patch was not
its behavior on MIPS, but, rather, that it might break some other
platform.  I agree with that assessment of where the risks lie.

In particular, with code like:

> +if [ "$LIB2_SIDITI_CONV_FUNCS" ]; then
> +  for func in $swfloatfuncs; do
> +sifunc=`echo $func | sed -e 's/XX/si/'`
> +lib2funcs="$lib2funcs $sifunc:$sifunc:4"
> +  done
> +  for func in $dwfloatfuncs; do
> +difunc=`echo $func | sed -e 's/XX/di/'`
> +tifunc=`echo $func | sed -e 's/XX/ti/'`
> +lib2funcs="$lib2funcs $difunc:$difunc:4 $tifunc:$difunc:8"
> +  done
> +else
> +  lib2funcs="$lib2funcs `echo $swfloatfuncs | sed -e 's/XX/si/g'`"
> +  lib2funcs="$lib2funcs `echo $dwfloatfuncs | sed -e 's/XX/di/g'`"
> +fi

which, could, potentially change the libgcc API.

However, I've started at the patch for quite some time, and I don't see
any problems.  And, thus far, there seem to be no problems on mainline.

So, I think we should include this patch.  Please apply, and let me know
when you've done that, so that I can start an RC2 build.

Thanks for working on this difficult issue.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: Wrong link?

[Gerald Pfeifer]

On Mon, 15 May 2006 [EMAIL PROTECTED] wrote:
> The link crossgcc FAQ in the middle of the page:
> "http://gcc.gnu.org/install/build.html"; doesn't seem to link to a page that
> offers the cross-gcc faq. Instead it appears to be a site of a consultant
> trying to sell his services.

How embarrassing.  I'll install the patch below in a minute, since I could
not find a true new master site for this FAQ.

Mark, since it seems we'll have to make another try for GCC 4.1.1, okay to
install this there as well?

Gerald

2006-05-20  Gerald Pfeifer  <[EMAIL PROTECTED]>

* doc/install.texi (Configuration): Remove reference to CrossGCC
FAQ which was hijacked.
(Building): Ditto.

Index: doc/install.texi
===
--- doc/install.texi(revision 113922)
+++ doc/install.texi(working copy)
@@ -1323,8 +1323,6 @@
 Tells GCC not use any target headers from a libc when building a cross
 compiler.  When crossing to GNU/Linux, you need the headers so GCC
 can build the exception handling for libgcc.
-See @uref{http://www.objsw.com/CrossGCC/,,CrossGCC} for more information
-on this option.
 
 @item --with-libs
 @itemx [EMAIL PROTECTED] @var{dir2} @dots{} @var{dirN}''
@@ -1660,10 +1658,6 @@
 
 @section Building a cross compiler
 
-We recommend reading the
[EMAIL PROTECTED]://www.objsw.com/CrossGCC/,,crossgcc FAQ}
-for information about building cross compilers.
-
 When building a cross compiler, it is not generally possible to do a
 3-stage bootstrap of the compiler.  This makes for an interesting problem
 as parts of GCC can only be built with [EMAIL PROTECTED]

Re: Wrong link?

[Joe Buck]

On Mon, May 22, 2006 at 09:11:24PM +0200, Gerald Pfeifer wrote:
> On Mon, 15 May 2006 [EMAIL PROTECTED] wrote:
> > The link crossgcc FAQ in the middle of the page:
> > "http://gcc.gnu.org/install/build.html"; doesn't seem to link to a page that
> > offers the cross-gcc faq. Instead it appears to be a site of a consultant
> > trying to sell his services.
> 
> How embarrassing.  I'll install the patch below in a minute, since I could
> not find a true new master site for this FAQ.

There's a mirror of the old FAQ at

http://vmlinux.org/crash/mirror/www.objsw.com/CrossGCC/

However, it has a 1999 date.  I don't know if there is anything more
recent.

Re: Wrong link?

[Mark Mitchell]

Gerald Pfeifer wrote:

> Mark, since it seems we'll have to make another try for GCC 4.1.1, okay to
> install this there as well?

Yes.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: GCC 4.1.1 RC1

[DJ Delorie]

FYI m32c still doesn't build libssp due to the GCC_NO_EXECUTABLES
thing.  Works OK with it disabled, though, for C and C++.  From whence
will release notes be published?

Re: GCC 4.1.1 RC1

[DJ Delorie]

> From whence will release notes be published?

>From *where* of course.

Re: Revert patch for MIPS TImode functions for 4.1.1

[Martin Michlmayr]

* Mark Mitchell <[EMAIL PROTECTED]> [2006-05-22 11:36]:
> I'm a bit torn.  On the one hand, it doesn't look like there is any
> other reason to do a 4.1.1 RC2.

Did anyone investigate those abi_check failures I (and others) have
seen?  See http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg01058.html

-- 
Martin Michlmayr
[EMAIL PROTECTED]

Re: Revert patch for MIPS TImode functions for 4.1.1

[Mark Mitchell]

Martin Michlmayr wrote:
> * Mark Mitchell <[EMAIL PROTECTED]> [2006-05-22 11:36]:
>> I'm a bit torn.  On the one hand, it doesn't look like there is any
>> other reason to do a 4.1.1 RC2.
> 
> Did anyone investigate those abi_check failures I (and others) have
> seen?  See http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg01058.html

Yes, I asked the libstdc++ list, and Paolo C. says that they result from
using a slightly different configuration from the configuration used to
generate the baseline.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: Revert patch for MIPS TImode functions for 4.1.1

[Paolo Carlini]

Mark Mitchell wrote:


Martin Michlmayr wrote:
 


* Mark Mitchell <[EMAIL PROTECTED]> [2006-05-22 11:36]:
   


I'm a bit torn.  On the one hand, it doesn't look like there is any
other reason to do a 4.1.1 RC2.
 


Did anyone investigate those abi_check failures I (and others) have
seen?  See http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg01058.html
   


Yes, I asked the libstdc++ list, and Paolo C. says that they result from
using a slightly different configuration from the configuration used to
generate the baseline.

By the way, in case of no --enable-clocale= at configure time, a 
possible explanation is missing de_DE localedata, which leads to an 
automatic fall back to the generic locale model:


   http://gcc.gnu.org/onlinedocs/libstdc++/install.html

Indeed, in those testresults I'm seeing ~300 unsupported tests, 
consistent with that situation.


Of course, it would be nice if reporters could double check that on 
those machines gcc4.1.0 behaves the same.


Paolo.

Re: Revert patch for MIPS TImode functions for 4.1.1

[Mark Mitchell]

Mark Mitchell wrote:
> Richard Sandiford wrote:
> 
>> Tested against gcc-4_1-branch on mips64-linux-gnu and mipsisa64-elf.
>> Mark, what do you think?
> 
> I'm a bit torn.  On the one hand, it doesn't look like there is any
> other reason to do a 4.1.1 RC2.  So, we could declare that Fortran is
> not release-critical, and just release 4.1.1.  On the other hand, it
> seems a shame to have a release in which a popular programming language
> is so horribly broken on a reasonably popular platform.

Richard and I had another round of discussion about this patch, and I've
decided to reverse my earlier decision.  Sorry for the back-and-forth!

In contrast to what I suggested above, 4.1.1 RC1 works for Fortran; the
problem is that on soft-float 64-bit MIPS, conversions from
floating-point types to 64-bit integers, and to unsigned 32-bit
integers, are missing in libgcc.  That's a serious problem, but one that
we had in 4.1.0 as well.  And, there is certainly some risk that the
patch will break something; Joseph already caught one mistake.

So, Richard and I have decided to leave well enough alone.  Unless
something else crops up in the next day or two, we'll consider 4.1.1 RC1
good enough, and spin final bits based on that.  Gerald, your
install.texi change is still OK.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: Wrong link?

[Gerald Pfeifer]

On Mon, 22 May 2006, Joe Buck wrote:
>> How embarrassing.  I'll install the patch below in a minute, since I could
>> not find a true new master site for this FAQ.
> There's a mirror of the old FAQ at
> 
> http://vmlinux.org/crash/mirror/www.objsw.com/CrossGCC/
> 
> However, it has a 1999 date.  I don't know if there is anything more
> recent.

Thanks for the pointer.  Given how much our build system has evolved in 
the last seven years, I guess this version is no longer fully applicable, 
and indeed some spot checks quickly found obsolete information, so I
decided to just remove the bogus link for now.

On Mon, 22 May 2006, Mark Mitchell wrote:
>> Mark, since it seems we'll have to make another try for GCC 4.1.1, okay to
>> install this there as well?
> Yes.

Thanks, it's on the 4.1 branch now.

Gerald

vec.h vs build/*.o

[DJ Delorie]

vec.h has a lot of unprotected 'static inline' functions.  With its
inclusion in many build-machine files via rtl.h, this essentially
precludes building on a machine without gcc (and a recent enough one,
at that).  It also requires using optimization for build/*.o, which
complicates debugging (that's how I found this).

Is this intentional?  It was introduced a couple months ago.

LTO Branch

[Mark Mitchell]

After the LTO proposal (http://gcc.gnu.org/projects/lto/lto.pdf) was
posted, a fruitful discussion ensued.  One of the key topics that arose
was the the possibility of using LLVM instead of the TREE-SSA
optimizers.  Things have quieted down on the public lists since then,
but the need for link-time optimization hasn't gone away -- so it's time
to get moving!

We have had some very useful discussions with Chris Lattner and other
folks at Apple. Our conclusion is that LLVM does indeed have a very
clean design and is very promising technology, but that there is still a
lot of technical work to do before LLVM could be incorporated into GCC.
We also fear that wholesale conversion to LLVM would likely be
disruptive, just as introducing TREE-SSA was disruptive. In addition,
the copyright issues around LLVM have not yet been resolved, and there
is no ETA for that resolution.

So, we plan to begin implementation of the LTO proposal. We certainly
intend to borrow from LLVM's design and be informed by its strengths.
When LLVM licensing issues are resolved, GCC may gradually incorporate
bits of LLVM, including generation of LLVM bytecodes for use with the
LLVM JIT.

Some of the design elements of LLVM are clearly attractive, if not
essential, for LTO.  For example, having a serializable IR (as does
LLVM, and as do many other compilers) is a sine qua non.  Complete
expression of the input program in the IR (rather than via langhooks or
global variables) is at least highly desirable, if not essential.

We've now created branches/lto in the GCC repository to start doing LTO
work, beginning with:

1. Writing/reading function bodies to disk.

2. Writing/reading declarative entities (as DWARF3) to/from disk.

3. As Diego has previously outlined, cleaning up our IR, with a focus on
both memory usage and completeness of representation.

Then, we'll work on:

4. Merging entities from distinct translation units.

5. Teaching the driver to re-invoke the compiler at link-time.

This is a big project, and we're looking for help!  We're planning on
working on more detailed designs for the various components, and we'll
be looking for feedback as we go.

--
David Edelsohn
Mark Mitchell
Diego Novillo
Ian Taylor
Kenny Zadeck

Re: LTO Branch

[Andrew Pinski]

> 
> After the LTO proposal (http://gcc.gnu.org/projects/lto/lto.pdf) was
> posted, a fruitful discussion ensued.  One of the key topics that arose
> was the the possibility of using LLVM instead of the TREE-SSA
> optimizers.  Things have quieted down on the public lists since then,
> but the need for link-time optimization hasn't gone away -- so it's time
> to get moving!
> 
> We've now created branches/lto in the GCC repository to start doing LTO
> work, beginning with:

Can you also update svn.html?  Also most likely this should be added to
update_version_svn so the DATE on the branch gets updated.

Thanks,
Andrew Pinski

Re: Revert patch for MIPS TImode functions for 4.1.1

[Martin Michlmayr]

* Paolo Carlini <[EMAIL PROTECTED]> [2006-05-22 22:37]:
> Of course, it would be nice if reporters could double check that on
> those machines gcc4.1.0 behaves the same.

I can confirm that the abi_check failure has gone away now that I have
generated the de_DE locale.

This makes me wonder, though, whether GCC could check whether the
de_DE locale exists on the system and if not skips the abi_check test
since it'll only give misleading results in that case.
-- 
Martin Michlmayr
http://www.cyrius.com/

Re: LTO Branch

[Chris Lattner]

On May 22, 2006, at 4:18 PM, Mark Mitchell wrote:

We have had some very useful discussions with Chris Lattner and other
folks at Apple. Our conclusion is that LLVM does indeed have a very
clean design and is very promising technology, but that there is  
still a
lot of technical work to do before LLVM could be incorporated into  
GCC.


To avoid confusion, allow me to point out that work on LLVM and  
integration with GCC is ongoing and will continue aggressively as  
usual.  We welcome anyone interested and/or willing to contribute to  
try it out and help out.  :)  If you're interested, this list or the  
LLVM mailing lists are great places to discuss this.


I look forward to seeing LTO develop in GCC!

-Chris

http://llvm.org/

Re: Revert patch for MIPS TImode functions for 4.1.1

[Paolo Carlini]

Martin Michlmayr wrote:


* Paolo Carlini <[EMAIL PROTECTED]> [2006-05-22 22:37]:
 


Of course, it would be nice if reporters could double check that on
those machines gcc4.1.0 behaves the same.
   


I can confirm that the abi_check failure has gone away now that I have
generated the de_DE locale.
 


Many thanks.


This makes me wonder, though, whether GCC could check whether the
de_DE locale exists on the system and if not skips the abi_check test
since it'll only give misleading results in that case.
 

I see your point, and indeed we are planning improvements in that area. 
However, believe me, the issue is not that simple because there are 
zillions of different configurations which lead to seemingly 
incompatible symbols, it's not just matter of checking whether the 
locale model is "right"... And of course it's more general than 
abi-check, long term we do not want to rely on de_DE being installed to 
figure out the appropriate locale model.


Thanks,
Paolo.

ofdstream.h and segmentation fault

[holderlin]

Hi, all:

I used an ofdstream.h written by others:

->>>---
#ifndef _OFDSTREAM_H
#define _OFDSTREAM_H

#include 
#include 
#include 

class ofdstream: public std::ofstream
{
private:
   __gnu_cxx::stdio_filebuf< char > m_buf;
   int m_fd;
public:
   ofdstream( int fd, int bufsize = 4096 );
   int fd() const { return( m_fd ); };
};

inline ofdstream::ofdstream( int fd, int bufsize )
#if __GNUC_PREREQ (3,4)
:   m_buf( fd, std::ios_base::out, bufsize )
#else
:   m_buf( fd, std::ios_base::out, true, bufsize )
#endif
{
   //this->init(&m_buf);
   std::basic_ios< char >::rdbuf( & m_buf );
}

#endif // _OFDSTREAM_H

->>>---

And the below is my test a.cpp:

->>>---
#include "fdstream.h"
#include 
#include 
#include 
#include 
#include 
using namespace std;
int
main()
{
   int fd = open("a.log", O_WRONLY|O_CREAT, 0600);
   if (fd < 0) {
   cerr << "open error" << endl;
   exit(1);
   }

   ofdstream ofs(fd);
   ofs << "testtest" << flush;
   close(fd);
   return 0;
}
->>>---

compile and run it:
# g++ -g -o a a.cpp
# ./a
Segmentation fault (core dumped)
#  g++ -v
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2/specs
Configured with: ../gcc-3.2/configure --prefix=/usr --enable-shared
--enable-languages=c,c++ --enable-threads=posix --with-slibdir=/lib
--enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 3.2

The below is backtrace of the core dump:

(gdb) bt
#0  0x40167d46 in free () from /lib/libc.so.6
#1  0x40157de7 in fclose@@GLIBC_2.1 () from /lib/libc.so.6
#2  0x40053ca4 in std::__basic_file::close () from
/usr/lib/libstdc++.so.5
#3  0x4005388f in std::__basic_file::~__basic_file () from
/usr/lib/libstdc++.so.5
#4  0x4008b64f in std::basic_filebuf

::~basic_filebuf () from /usr/lib/libstdc++.so.5

#5  0x08049a5a in ~stdio_filebuf (this=0xb9fc) at
/usr/include/c++/3.2/ext/stdio_filebuf.h:115
#6  0x08049778 in ~ofdstream (this=0xb970) at a.cpp:19
#7  0x0804969d in main () at a.cpp:25


But if I compile  a.cpp with g++ 3.4.4, there is no segmentation fault.

I failed to find and fix the bug.
Is this a bug in libstdc++?




---
Holderlin Zhang
Department of Applied Math., Nankai University

Re: LTO Branch

[Mark Mitchell]

Andrew Pinski wrote:
>> After the LTO proposal (http://gcc.gnu.org/projects/lto/lto.pdf) was
>> posted, a fruitful discussion ensued.  One of the key topics that arose
>> was the the possibility of using LLVM instead of the TREE-SSA
>> optimizers.  Things have quieted down on the public lists since then,
>> but the need for link-time optimization hasn't gone away -- so it's time
>> to get moving!
>>
>> We've now created branches/lto in the GCC repository to start doing LTO
>> work, beginning with:
> 
> Can you also update svn.html? 

Done, thanks.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

rtl_loop_init vs try_redirect_by_replacing_jump vs simple jumps

[DJ Delorie]

I've got a case where an unconditional simple jump is being removed,
yet it doesn't jump to the next insn.  The code in question seems
suspect...

Here we force CLEANUP_CFGLAYOUT true:

void
cfg_layout_initialize (unsigned int flags)
{
  . . .
  cleanup_cfg (CLEANUP_CFGLAYOUT | flags);
}

in cleanup_cfg we have this logic:

  /* If B has a single outgoing edge, but uses a
 non-trivial jump instruction without side-effects, we
 can either delete the jump entirely, or replace it
 with a simple unconditional jump.  */
  if (single_succ_p (b)
  && single_succ (b) != EXIT_BLOCK_PTR
  && onlyjump_p (BB_END (b))
  && !find_reg_note (BB_END (b), REG_CROSSING_JUMP, NULL_RTX)
  && try_redirect_by_replacing_jump (single_succ_edge (b),
 single_succ (b),
 (mode & CLEANUP_CFGLAYOUT) 
!= 0))

It says "non-trivial" but the insn is a simple jump:

(jump_insn 45 44 46 5 (set (pc)
(label_ref:DI 754)))

Note that "mode" of course has CLEANUP_CFGLAYOUT set.  Thus, here in
try_redirect_by_replacing_jump (note that in_cfglayout is set, from
mode above):

  /* See if we can create the fallthru edge.  */
  if (in_cfglayout || can_fallthru (src, target))
{
  if (dump_file)
fprintf (dump_file, "Removing jump %i.\n", INSN_UID (insn));
  fallthru = 1;

  /* Selectively unlink whole insn chain.  */
  if (in_cfglayout)
{
  rtx insn = src->il.rtl->footer;

  delete_insn_chain (kill_from, BB_END (src));

What seems to happen is, we delete the simple jump even if we can't
fallthru, and thus the blocks get rearranged in an incorrect order.

Is there a bug here, or am I misunderstanding how this code works?

Re: SVN: Checksum mismatch problem

[Russ Allbery]

Bruce Korb <[EMAIL PROTECTED]> writes:

> I do that also, but I am also careful to prune repository
> directories (CVS, .svn or SCCS even).  I rather doubt it is my RAM,
> BTW.  Perhaps a disk sector, but I'll never know now.  (Were it RAM,
> the failure would be random and not just the one file.)  The original
> data were rm-ed and replaced with a new pull of the Ada code.

Yup, I've seen change of capitalization of a single letter in files due to
bad disk sectors before, even on relatively modern hardware.  It's a
single bit error, so it's an explainable failure mode.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

fatal error: internal consistency failure on Linux/ia64

[H. J. Lu]

With trunk revision 113999, I got

if [ x"-fpic" != x ]; then \
  /export/build/gnu/gcc/build-ia64-linux/./prev-gcc/xgcc
  -B/export/build/gnu/gcc/build-ia64-linux/./prev-gcc/
  -B/usr/gcc-4.2/ia64-unknown-linux-gnu/bin/ -c -DHAVE_CONFIG_H -g -O2
  -I. -I/net/gnu-13/export/gnu/src/gcc/gcc/libiberty/../include  -W
  -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat
  -fpic /net/gnu-13/export/gnu/src/gcc/gcc/libiberty/fibheap.c -o
  pic/fibheap.o; \
  else true; fi
  /net/gnu-13/export/gnu/src/gcc/gcc/libiberty/fibheap.c: In function
  
âbheap_replace_key_dataâ/net/gnu-13/export/gnu/src/gcc/gcc/libiberty/fibheap.c:233:
  fatal error: internal consistency failure
  compilation terminated.
  make[3]: *** [fibheap.o] Error 1
  make[3]: Leaving directory
  `/export/build/gnu/gcc/build-ia64-linux/libiberty'
  make[2]: *** [all-stage2-libiberty] Error 2
  make[2]: Leaving directory `/export/build/gnu/gcc/build-ia64-linux'
  make[1]: *** [stage2-bubble] Error 2
  make[1]: Leaving directory `/export/build/gnu/gcc/build-ia64-linux'
  make: *** [all] Error 2

on Linux/ia64. The last working revision is 113936. Linux/x86 and
Linux/x86-64 pass the same spot. Has anyone else seen it?


H.J.

Re: fatal error: internal consistency failure on Linux/ia64

[Andrew Pinski]

On May 22, 2006, at 9:36 PM, H. J. Lu wrote:


on Linux/ia64. The last working revision is 113936. Linux/x86 and
Linux/x86-64 pass the same spot. Has anyone else seen it?


Yes for hppa-linux-gnu, PR 27736.

This is most likely caused by:
2006-05-22  Richard Sandiford  <[EMAIL PROTECTED]>

PR rtl-optimization/25514
* combine.c (replaced_rhs_insn): New variable.
(combine_instructions): Set replaced_rhs_insn when trying to  
replace

a SET_SRC with a REG_EQUAL note.
(distribute_notes): Use replaced_rhs_insn when determining  
the live

range of a REG_DEAD register.

-- Pinski

Re: rtl_loop_init vs try_redirect_by_replacing_jump vs simple jumps

[Steven Bosscher]

On 5/23/06, DJ Delorie <[EMAIL PROTECTED]> wrote:

What seems to happen is, we delete the simple jump even if we can't
fallthru, and thus the blocks get rearranged in an incorrect order.

Is there a bug here, or am I misunderstanding how this code works?


You're misunderstanding how this code works.  In cfglayout mode, there
is no "order" in the basic blocks such that
BLOCK_FOR_INSN(NEXT_INSN(BB_END(BB)) ) == BB->next_bb. This means that
you can fall through to other blocks than next_bb.
cfg_layout_finalize should fix this up where necessary when you go
back into cfgrtl mode.

Perhaps  http://gcc.gnu.org/wiki/cfglayout%20mode can help explain
this a bit more.

Gr.
Steven

Re: rtl_loop_init vs try_redirect_by_replacing_jump vs simple jumps

[Steven Bosscher]

On 5/23/06, Steven Bosscher <[EMAIL PROTECTED]> wrote:

On 5/23/06, DJ Delorie <[EMAIL PROTECTED]> wrote:
> What seems to happen is, we delete the simple jump even if we can't
> fallthru, and thus the blocks get rearranged in an incorrect order.
>
> Is there a bug here, or am I misunderstanding how this code works?

You're misunderstanding how this code works.


And, I forgot to say, one of the reasons that this keeps confusing
people is because the rtl dumps in cfglayout mode tend to look
confusing because there is almost no CFG information in them.  I
intend to fix that after finishing fwprop.  In the mean time you can
use brief_dump_cfg and/or hack print_rtl_with_bb to print
predecessors/successors at the start/end of each basic block.

Gr.
Steven