P.S.: Re: CUMULATIVE_ARGS in hooks

[Joern Rennecke]

Quoting Joern Rennecke :


Does that mean you acknowledge that we shouldn't have CUMULATIVE_ARGS
taking hooks in the global target vector?


FWIW, I think the attached patch would be approximately what it takes to
remove the CUMULATIVE_ARGS taking hooks from the global target vector
and put them into a separate vector only to be seen by a select few files.
Not tested yet, though.


Index: targhooks.c
===
--- targhooks.c (revision 166860)
+++ targhooks.c (working copy)
@@ -60,6 +60,7 @@ Software Foundation; either version 3, o
 #include "toplev.h"
 #include "function.h"
 #include "target.h"
+#include "target-internal.h"
 #include "tm_p.h"
 #include "target-def.h"
 #include "ggc.h"
@@ -194,7 +195,7 @@ hook_bool_CUMULATIVE_ARGS_false (CUMULAT
 bool
 default_pretend_outgoing_varargs_named (CUMULATIVE_ARGS *ca ATTRIBUTE_UNUSED)
 {
-  return (targetm.calls.setup_incoming_varargs
+  return (target_internalm.setup_incoming_varargs
  != default_setup_incoming_varargs);
 }
 
Index: c-family/c-opts.c
===
--- c-family/c-opts.c   (revision 166860)
+++ c-family/c-opts.c   (working copy)
@@ -23,6 +23,7 @@ Software Foundation; either version 3, o
 #include "system.h"
 #include "coretypes.h"
 #include "tree.h"
+#include "tm.h"
 #include "c-common.h"
 #include "c-pragma.h"
 #include "flags.h"
Index: java/expr.c
===
--- java/expr.c (revision 166860)
+++ java/expr.c (working copy)
@@ -28,6 +28,7 @@ the Free Software Foundation; either ver
 #include "system.h"
 #include "coretypes.h"
 #include "tree.h"
+#include "tm.h"
 #include "flags.h"
 #include "java-tree.h"
 #include "javaop.h"
Index: target.def
===
--- target.def  (revision 166860)
+++ target.def  (working copy)
@@ -1883,45 +1883,12 @@ HOOK_VECTOR (TARGET_CALLS, calls)
  bool, (const_tree type),
  hook_bool_const_tree_false)
 
-/* Return true if a parameter must be passed by reference.  TYPE may
-   be null if this is a libcall.  CA may be null if this query is
-   from __builtin_va_arg.  */
-DEFHOOK
-(pass_by_reference,
- "",
- bool,
- (CUMULATIVE_ARGS *cum, enum machine_mode mode, const_tree type, bool named),
- hook_bool_CUMULATIVE_ARGS_mode_tree_bool_false)
-
 DEFHOOK
 (expand_builtin_saveregs,
  "",
  rtx, (void),
  default_expand_builtin_saveregs)
 
-/* Returns pretend_argument_size.  */
-DEFHOOK
-(setup_incoming_varargs,
- "",
- void, (CUMULATIVE_ARGS *args_so_far, enum machine_mode mode, tree type,
-   int *pretend_args_size, int second_time),
- default_setup_incoming_varargs)
-
-DEFHOOK
-(strict_argument_naming,
- "",
- bool, (CUMULATIVE_ARGS *ca),
- hook_bool_CUMULATIVE_ARGS_false)
-
-/* Returns true if we should use
-   targetm.calls.setup_incoming_varargs() and/or
-   targetm.calls.strict_argument_naming().  */
-DEFHOOK
-(pretend_outgoing_varargs_named,
- "",
- bool, (CUMULATIVE_ARGS *ca),
- default_pretend_outgoing_varargs_named)
-
 /* Given a complex type T, return true if a parameter of type T
should be passed as two scalars.  */
 DEFHOOK
@@ -1939,58 +1906,6 @@ HOOK_VECTOR (TARGET_CALLS, calls)
  bool, (enum machine_mode mode, const_tree type),
  must_pass_in_stack_var_size_or_pad)
 
-/* Return true if type TYPE, mode MODE, which is passed by reference,
-   should have the object copy generated by the callee rather than
-   the caller.  It is never called for TYPE requiring constructors.  */
-DEFHOOK
-(callee_copies,
- "",
- bool,
- (CUMULATIVE_ARGS *cum, enum machine_mode mode, const_tree type, bool named),
- hook_bool_CUMULATIVE_ARGS_mode_tree_bool_false)
-
-/* Return zero for arguments passed entirely on the stack or entirely
-   in registers.  If passed in both, return the number of bytes passed
-   in registers; the balance is therefore passed on the stack.  */
-DEFHOOK
-(arg_partial_bytes,
- "",
- int, (CUMULATIVE_ARGS *cum, enum machine_mode mode, tree type, bool named),
- hook_int_CUMULATIVE_ARGS_mode_tree_bool_0)
-
-/* Update the state in CA to advance past an argument in the
-   argument list.  The values MODE, TYPE, and NAMED describe that
-   argument.  */
-/* ??? tm.texi still only describes the old macro.  */
-DEFHOOK_UNDOC
-(function_arg_advance,
- "",
- void,
- (CUMULATIVE_ARGS *ca, enum machine_mode mode, const_tree type, bool named),
- default_function_arg_advance)
-
-/* Return zero if the argument described by the state of CA should
-   be placed on a stack, or a hard register in which to store the
-   argument.  The values MODE, TYPE, and NAMED describe that
-   argument.  */
-/* ??? tm.texi still only describes the old macro.  */
-DEFHOOK_UNDOC
-(function_arg,
- "",
- rtx, (CUMULATIVE_ARGS *ca, enum machine_mode mode, const_tree type,
-   bool named),
- default_function_arg)
-
-/* Likewise, but for machines with register windows.  Return the
-   location where the

incompatible GCC 4.4.5 and 4.5.1 libstdc++ ?

[Christophe Lyon]

Hi,

I have just faced a problem where a C++ program (which I get in binary
form - I can't recompile) crashes when it uses libstdc++.so.6 from
GCC-4.5.1, while it works when using libstdc++.so.6 from GCC-4.4.5.

I am using an x86 machine.

Are there any known incompatibilities between these two libraries?
As the major revision hasn't changed I didn't expect any behaviour change.

Thanks,

Christophe.

Re: CUMULATIVE_ARGS in hooks (Was: RFC: semi-automatic hookization)

[Nathan Froyd]

On Tue, Nov 16, 2010 at 10:22:00PM -0500, Joern Rennecke wrote:
> Quoting Nathan Froyd :
> >I am admittedly a C++ newbie; the first thing I thought of was:
> >
> >class gcc::cumulative_args {
> >  virtual void advance (...) = 0;
> >  virtual rtx arg (...) = 0;
> >  virtual rtx incoming_arg (...) { return this->arg (...); };
> >  virtual int arg_partial_bytes (...) = 0;
> >  // ...and so on for many of the hooks that take CUMULATIVE_ARGS *
> >  // possibly with default implementations instead of pure virtual
> >  // functions.
> >};
> 
> Trying to put a target-derived object of that into struct rtl_data would
> be nonsentical.  You might store a pointer, of course.

Yes, of course.  I thought that might have been clear from context.

> Does that mean you acknowledge that we shouldn't have CUMULATIVE_ARGS
> taking hooks in the global target vector?

Maybe?  I think the methods discussed in this thread would be better for
when we do move to C++.  I don't think your original proposal or
anything that sacrifices the type-safety of the current interface is the
way forward.

-Nathan

Re: CUMULATIVE_ARGS in hooks (Was: RFC: semi-automatic hookization)

[Joern Rennecke]

Quoting Nathan Froyd :


On Tue, Nov 16, 2010 at 10:22:00PM -0500, Joern Rennecke wrote:

...

Does that mean you acknowledge that we shouldn't have CUMULATIVE_ARGS
taking hooks in the global target vector?


Maybe?  I think the methods discussed in this thread would be better for
when we do move to C++.  I don't think your original proposal or
anything that sacrifices the type-safety of the current interface is the
way forward.


You can find my original proposal fleshed out here:
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01769.html

I have also made an alternate proposal that keeps type safety, and regains
dependency sanity by moving the CUMULATIVE_ARGS taking hooks out of targetm:
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01810.html

This is conceptually closer to the C++ proposals; the new target_internalm
hook vector serves a similar purpose as a vtable for a cumulative_arg
class object.

Re: incompatible GCC 4.4.5 and 4.5.1 libstdc++ ?

[Ian Lance Taylor]

Christophe Lyon  writes:

> I have just faced a problem where a C++ program (which I get in binary
> form - I can't recompile) crashes when it uses libstdc++.so.6 from
> GCC-4.5.1, while it works when using libstdc++.so.6 from GCC-4.4.5.
>
> I am using an x86 machine.
>
> Are there any known incompatibilities between these two libraries?
> As the major revision hasn't changed I didn't expect any behaviour change.

This question is not appropriate for the mailing list g...@gcc.gnu.org.
It would be appropriate for gcc-h...@gcc.gnu.org.  Please take any
followups to gcc-help.  Thanks.

There are no intentional incompatibilities between these libraries.  If
you build a program with gcc 4.4.5, it should run correctly when using
the libstdc++ from gcc 4.5.1.  Of course there may be a bug.  It's hard
to say anything else without more information.

Ian

Boostrap fails on i386-pc-solaris2.10 - libquadmath error

[Art Haas]

Hi.

My build this morning failed when libquadmath was being built. Things
failed when configuring in the 'amd64' subdirectory - the bits below
are taken from the 'config.log' in that directory:

configure:3040: /export/home/arth/gnu/gcc-1117/./gcc/xgcc 
-B/export/home/arth/gnu/gcc-1117/./gcc/ 
-B/export/home/arth/local/i386-pc-solaris2.10/bin/ 
-B/export/home/arth/local/i386-pc-solaris2.10/lib/ -isystem 
/export/home/arth/local/i386-pc-solaris2.10/include -isystem 
/export/home/arth/local/i386-pc-solaris2.10/sys-include  -m64 -V >&5
xgcc: error: unrecognized option '-V'
xgcc: fatal error: no input files
compilation terminated.
configure:3051: $? = 1
configure:3040: /export/home/arth/gnu/gcc-1117/./gcc/xgcc 
-B/export/home/arth/gnu/gcc-1117/./gcc/ 
-B/export/home/arth/local/i386-pc-solaris2.10/bin/ 
-B/export/home/arth/local/i386-pc-solaris2.10/lib/ -isystem 
/export/home/arth/local/i386-pc-solaris2.10/include -isystem 
/export/home/arth/local/i386-pc-solaris2.10/sys-include  -m64 -qversion >&5
xgcc: error: unrecognized option '-qversion'
xgcc: fatal error: no input files
compilation terminated.
configure:3051: $? = 1
configure:3071: checking for C compiler default output file name
configure:3093: /export/home/arth/gnu/gcc-1117/./gcc/xgcc 
-B/export/home/arth/gnu/gcc-1117/./gcc/ 
-B/export/home/arth/local/i386-pc-solaris2.10/bin/ 
-B/export/home/arth/local/i386-pc-solaris2.10/lib/ -isystem 
/export/home/arth/local/i386-pc-solaris2.10/include -isystem 
/export/home/arth/local/i386-pc-solaris2.10/sys-include  -m64 -g -O2
conftest.c  >&5
configure:3097: $? = 0
configure:3134: result: a.out
configure:3150: checking whether the C compiler works
configure:3159: ./a.out
/home/ahaas/gnu/gcc.git/libquadmath/configure: line 3161: ./a.out: cannot 
execute binary file
configure:3163: $? = 126
configure:3170: error: in 
`/export/home/arth/gnu/gcc-1117/i386-pc-solaris2.10/amd64/libquadmath':
configure:3174: error: cannot run C compiled programs.

I see similar output in the 'config.log' files located in other
subdirectories below 'amd64', but in those file subsquent lines indicate
a test regarding cross-compiling.

The build this morning on the sparc-sun-solaris2.10 machine worked without
problems.

My thanks to everyone working on GCC.

Art Haas

Re: Boostrap fails on i386-pc-solaris2.10 - libquadmath error

[Tobias Burnus]

Art Haas wrote:

My build this morning failed when libquadmath was being built. Things
failed when configuring in the 'amd64' subdirectory - the bits below
are taken from the 'config.log' in that directory:


There are two known problems:

a) libquadmath should - at least for now - only be build by default if 
the --enable-languages encompasses fortran


b) Building with a cross compiler is not supported by the libquadmath 
configure script


They are both the consequence of adding libquadmath and thus Fortran 
REAL(16) support for some of the 32-bit x86/x86-64/ia64 targets. 
However, breaking the build was not intended.


The two issues are tracked as 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46520


Sorry for the breakage; it should be fixed soon.

Tobias

Re: Boostrap fails on i386-pc-solaris2.10 - libquadmath error

[Ralf Wildenhues]

* Tobias Burnus wrote on Wed, Nov 17, 2010 at 08:20:39PM CET:
> b) Building with a cross compiler is not supported by the
> libquadmath configure script

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

You should probably try out GCC_NO_EXECUTABLES in configure.ac
and check with a couple of cross targets to find out whether you need to
override any link checks with cache variables in the cross case.

The symbol versioning test looks like it might qualify.  OTOH libssp
doesn't have cross measures for it either, so I'm not sure.
Also, the test for __float128.  It would be good to use configure cache
variables (matching *_cv_*) for these (so the user can override them).

Cheers,
Ralf

ICE on Cygwin [trunk]

[Angelo Graziosi]

Trying to bootstrap rev. 166873, on Cygwin, configuring with:

/tmp/gcc-4.6-r166873/configure --prefix=/usr/local/gfortran 
--program-suffix=-4.6 --enable-languages=c,c++,fortran 
--enable-checking=release --enable-threads=posix --enable-libgomp 
--disable-bootstrap --disable-libmudflap --disable-shared


I get this ICE:

[...]
make[4]: Entering directory 
`/tmp/gcc-4.6-r166873/Work/i686-pc-cygwin/libgomp'
/bin/sh ./libtool --tag=CC   --mode=compile 
/tmp/gcc-4.6-r166873/Work/./gcc/xgcc -B/tmp/gcc-4.6-r166873/Work/./gcc/ 
-B/usr/local/gfortran/i686-pc-cygwin/bin/ 
-B/usr/local/gfortran/i686-pc-cygwin/lib/ -isystem 
/usr/local/gfortran/i686-pc-cygwin/include -isystem 
/usr/local/gfortran/i686-pc-cygwin/sys-include-DHAVE_CONFIG_H -I. 
-I/tmp/gcc-4.6-r166873/libgomp 
-I/tmp/gcc-4.6-r166873/libgomp/config/posix 
-I/tmp/gcc-4.6-r166873/libgomp  -Wall -Werror -g -O2 -MT barrier.lo -MD 
-MP -MF .deps/barrier.Tpo -c -o barrier.lo 
/tmp/gcc-4.6-r166873/libgomp/barrier.c
libtool: compile:  /tmp/gcc-4.6-r166873/Work/./gcc/xgcc 
-B/tmp/gcc-4.6-r166873/Work/./gcc/ 
-B/usr/local/gfortran/i686-pc-cygwin/bin/ 
-B/usr/local/gfortran/i686-pc-cygwin/lib/ -isystem 
/usr/local/gfortran/i686-pc-cygwin/include -isystem 
/usr/local/gfortran/i686-pc-cygwin/sys-include -DHAVE_CONFIG_H -I. 
-I/tmp/gcc-4.6-r166873/libgomp 
-I/tmp/gcc-4.6-r166873/libgomp/config/posix 
-I/tmp/gcc-4.6-r166873/libgomp -Wall -Werror -g -O2 -MT barrier.lo -MD 
-MP -MF .deps/barrier.Tpo -c /tmp/gcc-4.6-r166873/libgomp/barrier.c -o 
barrier.o
/tmp/gcc-4.6-r166873/libgomp/barrier.c:41:1: internal compiler error: in 
decide_is_variable_needed, at varpool.c:338

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[4]: *** [barrier.lo] Error 1
make[4]: Leaving directory 
`/tmp/gcc-4.6-r166873/Work/i686-pc-cygwin/libgomp'

make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory 
`/tmp/gcc-4.6-r166873/Work/i686-pc-cygwin/libgomp'

make[2]: *** [all] Error 2
make[2]: Leaving directory 
`/tmp/gcc-4.6-r166873/Work/i686-pc-cygwin/libgomp'

make[1]: *** [all-target-libgomp] Error 2
make[1]: Leaving directory `/tmp/gcc-4.6-r166873/Work'
make: *** [all] Error 2

It seems to me unrelated to these changes [*], which I cannot yet test.

Attached is the .i file (bzipped).

Ciao,
Angelo.

---
[*] http://gcc.gnu.org/ml/fortran/2010-11/msg00243.html


barrier.i.bz2
Description: Binary data

Re: ICE on Cygwin [trunk]

[Tobias Burnus]

Why does everyone think that I and Fortran have something to do with it 
if something breaks?* ;-)


The issue is known and a fix, which seemingly works on Darwin, exists.
See: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510

Angelo Graziosi wrote:
/tmp/gcc-4.6-r166873/libgomp/barrier.c:41:1: internal compiler error: 
in decide_is_variable_needed, at varpool.c:338


Tobias

* The PR 46510 was initially filled against Fortran and this report is 
CCed to me. For libquadmath failures, I accept some responsibility.

Re: Boostrap fails on i386-pc-solaris2.10 - libquadmath error

[Rainer Orth]

Ralf Wildenhues  writes:

> * Tobias Burnus wrote on Wed, Nov 17, 2010 at 08:20:39PM CET:
>> b) Building with a cross compiler is not supported by the
>> libquadmath configure script
>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46520
>
> You should probably try out GCC_NO_EXECUTABLES in configure.ac
> and check with a couple of cross targets to find out whether you need to
> override any link checks with cache variables in the cross case.
>
> The symbol versioning test looks like it might qualify.  OTOH libssp
> doesn't have cross measures for it either, so I'm not sure.
> Also, the test for __float128.  It would be good to use configure cache
> variables (matching *_cv_*) for these (so the user can override them).

I'm seeing none of those issues in a i386-pc-solaris2.10 build I've just
fired off, but it still breaks in libquadmath:

* The quadmath.map-sun target didn't use TABs before the commands, but
  blanks, which makes make choke:

make[2]: Entering directory 
`/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/libquadmath'
Makefile:972: *** missing separator (did you mean TAB instead of 8 spaces?).  
Stop.

* The sed command to mangle .la/.lo files into their .a/.o equivalents
  in .libs subdirs doesn't deal correctly with files in subdirs (like
  math, qdtoa).  I've used the one from libjava/Makefile.am which does.

* One cannot -lm to libquadmath_la_LIBADD since that gets passed to nm,
  which doesn't know (and doesn't need to be run) -lm.  Again, as in
  libjava/Makefile.am, I've moved it to libquadmath_la_LDFLAGS instead.

With those changed (the blank-to-TAB part isn't reflected in the diff),
I could build both 32 and 64-bit libquadmath.so.

I won't post a proper patch until it has completed, just a heads-up to
those running into the same failures.

Rainer


--- Makefile~   2010-11-17 20:53:03.037000370 +0100
+++ Makefile2010-11-17 21:01:53.426712881 +0100
@@ -281,8 +281,7 @@ LTLDFLAGS = $(shell $(SHELL) $(top_srcdi
 -no-undefined
 
 toolexeclib_LTLIBRARIES = libquadmath.la
-libquadmath_la_LIBADD = -lm
-libquadmath_la_LDFLAGS = $(LTLDFLAGS) -version-info `grep -v '^\#' 
$(srcdir)/libtool-version` $(version_arg)
+libquadmath_la_LDFLAGS = $(LTLDFLAGS) -version-info `grep -v '^\#' 
$(srcdir)/libtool-version` $(version_arg) -lm
 libquadmath_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS)
 libquadmath_la_DEPENDENCIES = $(version_dep)
 include_HEADERS = quadmath.h quadmath_weak.h
@@ -971,8 +970,7 @@ quadmath.map-sun : $(srcdir)/quadmath.ma
$(libquadmath_la_OBJECTS) $(libquadmath_la_LIBADD)
perl $(top_srcdir)/../contrib/make_sunver.pl \
  $(srcdir)/quadmath.map \
- $(libquadmath_la_OBJECTS:%.lo=.libs/%.o) \
-   `echo $(libquadmath_la_LIBADD) | \
+   `echo $(libquadmath_la_OBJECTS) $(libquadmath_la_LIBADD) | \
sed 's,\([^/]*\)\.l\([ao]\),.libs/\1.\2,g'` \
 > $@ || (rm -f $@ ; exit 1)
 

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Boostrap fails on i386-pc-solaris2.10 - libquadmath error

[Rainer Orth]

Rainer Orth  writes:

> I won't post a proper patch until it has completed, just a heads-up to
> those running into the same failures.

While the build completed with the patch I've posted, fortran testing
for the non-default multilib is completely broken, e.g.

Setting LD_LIBRARY_PATH to 
.:/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/amd64/libgfortran/.libs:/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/amd64/libgfortran/.libs:/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/amd64/libquadmath/.libs:/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/amd64/libquadmath/.libs:/var/gcc/regression/trunk/10-gcc-gas/build/gcc:.:/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/amd64/libgfortran/.libs:/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/amd64/libgfortran/.libs:/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/amd64/libquadmath/.libs:/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/amd64/libquadmath/.libs:/var/gcc/regression/trunk/10-gcc-gas/build/gcc:/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/libstdc++-v3/src/.libs:/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/libssp/.libs:/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/libgomp/.libs:/var/gcc/regression/trunk/10-gcc-gas/build/./gcc:/var/gcc/regression/trunk/10-gcc-gas/build/./prev-gcc
spawn [open ...]
ld.so.1: achar_1.exe: fatal: 
/var/gcc/regression/trunk/10-gcc-gas/build/gcc/libgcc_s.so.1: wrong ELF class: 
ELFCLASS32
FAIL: gfortran.dg/achar_1.f90  -O0  execution test

I've removed the builddir so the problems are easier seen:

.
i386-pc-solaris2.10/amd64/libgfortran/.libs
i386-pc-solaris2.10/amd64/libgfortran/.libs
i386-pc-solaris2.10/amd64/libquadmath/.libs
i386-pc-solaris2.10/amd64/libquadmath/.libs
gcc
.
i386-pc-solaris2.10/amd64/libgfortran/.libs
i386-pc-solaris2.10/amd64/libgfortran/.libs
i386-pc-solaris2.10/amd64/libquadmath/.libs
i386-pc-solaris2.10/amd64/libquadmath/.libs
gcc
i386-pc-solaris2.10/libstdc++-v3/src/.libs
i386-pc-solaris2.10/libssp/.libs
i386-pc-solaris2.10/libgomp/.libs
./gcc
./prev-gcc

The LD_LIBRARY_PATH above is broken in several ways:

* gcc is added instead of gcc/amd64, so the default libgcc_s.so.1
  multilib (32-bit in this case) is tried instead of the correct one.

* /amd64/libquadmath/.libs and /amd64/libgfortran/.libs
  are added four times.

* . is added twice, gcc even three times.

* I've no idea why prev-gcc should be there.

* The .libs directories for libstdc++-v3, libssp and libgomp are added
  for no good reason, and only for the default multilib, which is
  completely wrong.

At the very least, the first issue needs to be fixed since it renders
testresults useless with thousends of errors.  I cannot investigate
further myself since I'm on the way home.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Boostrap fails on i386-pc-solaris2.10 - libquadmath error

[Tobias Burnus]

Rainer Orth wrote:

While the build completed with the patch I've posted, fortran testing
for the non-default multilib is completely broken, e.g.


That's in a way the a duplicate of PR 46516. Or at least the solution is 
similar: Getting rid of libgfortran.spec and fall back (again) to having 
the compiler itself adding the "-lquad". The only difficulty is: Having 
__float128 is not sufficient, one also needs to have some support 
libgcc. Thus, one needs to sort out how this is handled in gcc - and in 
particular in libgcc/config.host and gcc/config.gcc.


Tobias,
who disliked the solution of using libgfortran.spec with all the issues 
it caused.

Re: Discussion about merging Go frontend

[Ian Lance Taylor]

Ralf Wildenhues  writes:

> I casually looked at libgo/{Makefile.am,configure.ac}.

Thanks for the review.


> You don't need to list .c files in the BUILT_SOURCES variable if they
> are also listed in some _SOURCES variable (and are not
> undocumented prerequisites for other targets).  make will know that it
> needs to create these files.  (Omitting BUILT_SOURCES saves a recursive
> make invocation in practice.)

Fixed.


>> if LIBGO_IS_386
>> GOARCH = 386
>> else
>> if LIBGO_IS_X86_64
>> GOARCH = amd64
>> else
>> if LIBGO_IS_ARM
>> GOARCH = arm
>> else
>> GOARCH = unknown
>> endif
>> endif
>> endif
>
> I wouldn't write Automake conditionals deeply nested, it makes for long
> lines and quadratic number of characters in Makefile.in when the number
> of conditionals increases.  But who am I telling that.  ;-)
> You could just AC_SUBST([GOARCH]) and GOOS from configure.ac; but this
> is a really minor stylistic issue.

It's ugly but it puts the value where it is used, rather than splitting
it between configure.ac and Makefile.am.  This makes it easier to
understand what is happening.

If only the person who implemented automake conditionals had added elif.
What a maroon.


> Several %/check targets use 'mkdir -p'.  While that is quite portable
> nowadays, there are still mkdir implementations that are racy when run
> in parallel.  You can use $(MKDIR_P) instead.

Fixed.


> I suppose portability to systems where OBJEXT is .obj is not a question
> at this point.

Not really, but I changed .o to .$(OBJEXT) anyhow.

All patches committed to gccgo branch.  Thanks again for the review.

Ian

Re: Maybe bug in call function to static declaration variable?

[Gilberto Cuba Ricardo]

Hi Axel,

Axel Freyn escribió:

[CUT]

> I simply added debug output before/after each "event"

> My gcc-generated executable says the following at runtime:

> main 1
> type_schema called the 1 time
> type_schema 1
> Contructor called the 1 time
> Constructor sponge_object_schema: 1
> type_schema called the 2 time
> type_schema 1
> terminate called after throwing an instance of 
> '__gnu_cxx::recursive_init_error'
>   what():  std::exception

Well, MSVS2010 returned this result:

main 1
type_schema called the 1 time
type_schema 1
Contructor called the 1 time
Constructor sponge_object_schema: 1
type_schema called the 2 time
type_schema 1
type_schema 2
Constructor sponge_object_schema: 3
type_schema 2
main 2

This is very very strange, because after the second "type_schema 1",
when the execute line of the debug is on line:

static sponge_object_schema result;

it isn't call a "sponge_object_schema" constructor, and then the
program follow the standard execution.

> This seems to me the only "clean" solution to this problem...

> I would really be interested what MSVS is doing to overcome this
> problem? No matter what he does, it IS dangerous (I think...):
> 1) if he outputs "type_schema 2" BEFORE "Constructor
> sponge_object_schema: 3" that would mean that he ignored the constructor
> in "type_schema" before the constructor is finished ==> it would be very
> dangerous to use the static variable "result" there, as its not yet
> completely constructed...

This is that he does!, at least I think, and I don't understand why
you think it's very dangerous.

> 2) if he outputs "type_schema 2" AFTER "Constructor
> sponge_object_schema: 3" that would mean that he ignored the call to
> "type_schema" in the constructor ==> it do not see any possible
> explanation why that would be justified or reasonable ...

It isn't the case.

> (Well, mabye there is some paragraph somewhere in the C++-standard which
> defines this situation as "undefined behaviour"? Then the compiler could
> of course do whatever he wants...)

Maybe it's possible, though, I searched in the working draft of
standard programming c++ of this year that: "Static initialization shall
be performed before any dynamic initialization takes place. Dynamic
initialization of non-local variable with static storage duration is either
ordered or unordered. Definitions of explicitly specialized class template
static data members have ordered initialization."

> Best Regards,
> Axel

-- 
Best regards,
 Gilberto Cuba Ricardo

Re: Maybe bug in call function to static declaration variable?

[Jonathan Wakely]

[This question should have been sent to gcc-help, this list is for
discussing development of GCC]

On 18 November 2010 03:03, Gilberto Cuba Ricardo wrote:
>
> Maybe it's possible, though, I searched in the working draft of
> standard programming c++ of this year that: "Static initialization shall
> be performed before any dynamic initialization takes place. Dynamic
> initialization of non-local variable with static storage duration is either
> ordered or unordered. Definitions of explicitly specialized class template
> static data members have ordered initialization."

That's not a non-local variable or a static data member. The relevant
text is 6.7 [stmt.decl] p4

If control re-enters the declaration (recursively) while the object is
being initialized, the behavior is undefined. [Example:
int foo(int i)
{
  static int s = foo(2*i); // recursive call – undefined
  return i+1;
}
—end example]

Re: Boostrap fails on i386-pc-solaris2.10 - libquadmath error

[Ralf Wildenhues]

* Rainer Orth wrote on Wed, Nov 17, 2010 at 09:15:55PM CET:
> 
> * One cannot -lm to libquadmath_la_LIBADD since that gets passed to nm,
>   which doesn't know (and doesn't need to be run) -lm.

That's a bug in the rule using nm then, though.

>   Again, as in
>   libjava/Makefile.am, I've moved it to libquadmath_la_LDFLAGS instead.

Using *_LDFLAGS for -l flags is wrong though because it might mess up
the ordering of libraries, at least for static linking.  You might get
away with this here because -lm is probably added from some other bit as
well, but in general that is not a good idea.

Cheers,
Ralf

Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64

[Xinliang David Li]

Some text size measurement.

Summary:
1) LTO with -O3 bloats up code considerably;
2) LTO with -O2 reduces text size compared with -O2
3) Google 4.4.3 based compiler is really effective in reducing C++
program size -- this is where the focus of the tuning was done.
Witnessed by eon in SPEC2k and all C++ apps in SPEC06


Notes:
  1.  -ffunction-sections -Wl,-gc-sections are used in the build.
  2. SPEC06 dealII does not build with trunk GCC with some parsing
error.  Hj Lu, what alt source should be used? (it builds fine with
4.4.3 compiler)
  3. xalancbmk and omnetpp do not build with TOT gcc compiler using
FDO -- compiler ICEes.  Will investigate when there is time.


David

SPEC06 C++ program Data (the first data column is the TOT O2 base number)

1. TOT O3 vs TOT O2 ( 3.35% total increase)

471.omnetpp/853708867988  1.67%
 450.soplex/643273656349 2.03%
  483.xalancbmk/   3634416   3777600  3.94%
   444.namd/3931424020382.26%
  473.astar/102182111038  8.67%
size_sum   5626721   5815013  3.35%

2. TOT LTO+whole program + O3 vs TOT O2 (0.35% total increase)

471.omnetpp/853708937728  9.84%
 450.soplex/643273654057  1.68%
  483.xalancbmk/   3634416   3540646 -2.58%
   444.namd/393142401318  2.08%
  473.astar/102182112538 10.13%
size_sum   5626721   5646287  0.35%

3. TOT LTO+whole program + O2 vs TOT O2 (8.10% total reduction)

471.omnetpp/853708822868 -3.61%
 450.soplex/643273611653 -4.92%
  483.xalancbmk/   3634416   3245157-10.71%
   444.namd/393142391698 -0.37%
  473.astar/102182 99586 -2.54%
size_sum   5626721   5170962 -8.10%

4. google 4.4.3 compiler  O2 vs TOT O2 (13.95% total reduction)

471.omnetpp/853708545840-36.06%
 450.soplex/643273374674-41.76%
  483.xalancbmk/   3634416   3556306 -2.15%
   444.namd/393142329897-16.09%
  473.astar/102182 35301-65.45%
size_sum   5626721   4842018-13.95%

5. Google 4.4.3 compiler O2 FDO vs TOT O2 (24.81% total reduction)

471.omnetpp/853708514732-39.71%
 450.soplex/643273357426-44.44%
  483.xalancbmk/   3634416   2985761-17.85%
   444.namd/393142332806-15.35%
  473.astar/102182 39797-61.05%
size_sum   5626721   4230522-24.81%

6. Google 4.4.3 compiler O2 LIPO vs TOT O2 (20.86 % total reduction)

   471.omnetpp/853708559944-34.41%
 450.soplex/643273393399-38.84%
  483.xalancbmk/   3634416   3126428-13.98%
   444.namd/393142334666-14.87%
  473.astar/102182 38749-62.08%
size_sum   5626721   4453186-20.86%



SPEC2k text size data:

1. tot O1 vs tot O2 ( 4.48% total reduction)

  300.twolf/182884177223 -3.10%
181.mcf/ 11794 11338 -3.87%
   164.gzip/ 36705 34388 -6.31%
 186.crafty/171663164898 -3.94%
 255.vortex/463463456034 -1.60%
  256.bzip2/ 28803 28091 -2.47%
176.gcc/   1422042   1368365 -3.77%
 197.parser/103225 96644 -6.38%
253.perlbmk/563927515898 -8.52%
175.vpr/139321134316 -3.59%
252.eon/607704591780 -2.62%
254.gap/496262459593 -7.39%
size_sum   4227793   4038568 -4.48%


2. tot O3 vs tot O2 : (10.8% total size increase)

  300.twolf/182884194620  6.42%
181.mcf/ 11794 13290 12.68%
   164.gzip/ 36705 46049 25.46%
 186.crafty/171663189892 10.62%
 255.vortex/463463495875  6.99%
  256.bzip2/ 28803 39939 38.66%
176.gcc/   1422042   1609786 13.20%
 197.parser/103225143558 39.07%
253.perlbmk/563927616855  9.39%
175.vpr/139321147081  5.57%
252.eon/607704625176  2.88%
254.gap/496262563187 13.49%
size_sum   4227793   4685308 10.82%


3. tot LTO + -fwhole-program + -O2  vs tot O2 : (3.65% total size reduction)

  300.twolf/182884176572 -3.45%
181.mcf/ 11794  9594-18.65%
   164.gzip/ 36705 34439 -6.17%
 186.crafty/171663173071  0.82%
 255.vortex/463463382157-17.54%
  256.bzip2/ 28803 27142 -5.77%
176.gcc/   1422042   1364796 -4.03%
 197.parser/103225 94997 -7.97%