[Bug java/40731] New: Failure to bootstrap GCJ 4.4.0

2009-07-13 Thread ludo at gnu dot org
#x27;
java/mangle_name.o: In function `VEC_tree_gc_free':
/tmp/nix-build-r7ajl7733zmbh0dw1pxpxbmh2766146v-gcj-4.4.0.drv-0/build/gcc/../../gcc-4.4.0/gcc/tree.h:191:
undefined reference to `ggc_free'
java/mangle_name.o: In function `VEC_tree_gc_copy':
/tmp/nix-build-r7ajl7733zmbh0dw1pxpxbmh2766146v-gcj-4.4.0.drv-0/build/gcc/../../gcc-4.4.0/gcc/tree.h:191:
undefined reference to `vec_gc_p_reserve_exact'
java/mangle_name.o: In function `VEC_tree_gc_reserve':
/tmp/nix-build-r7ajl7733zmbh0dw1pxpxbmh2766146v-gcj-4.4.0.drv-0/build/gcc/../../gcc-4.4.0/gcc/tree.h:191:
undefined reference to `vec_gc_p_reserve'
java/mangle_name.o: In function `VEC_tree_gc_reserve_exact':
/tmp/nix-build-r7ajl7733zmbh0dw1pxpxbmh2766146v-gcj-4.4.0.drv-0/build/gcc/../../gcc-4.4.0/gcc/tree.h:191:
undefined reference to `vec_gc_p_reserve_exact'
java/mangle_name.o: In function `VEC_tree_heap_alloc':
/tmp/nix-build-r7ajl7733zmbh0dw1pxpxbmh2766146v-gcj-4.4.0.drv-0/build/gcc/../../gcc-4.4.0/gcc/tree.h:192:
undefined reference to `vec_heap_p_reserve_exact'
java/mangle_name.o: In function `VEC_tree_heap_copy':
/tmp/nix-build-r7ajl7733zmbh0dw1pxpxbmh2766146v-gcj-4.4.0.drv-0/build/gcc/../../gcc-4.4.0/gcc/tree.h:192:
undefined reference to `vec_heap_p_reserve_exact'
java/mangle_name.o: In function `VEC_tree_heap_reserve':
/tmp/nix-build-r7ajl7733zmbh0dw1pxpxbmh2766146v-gcj-4.4.0.drv-0/build/gcc/../../gcc-4.4.0/gcc/tree.h:192:
undefined reference to `vec_heap_p_reserve'
java/mangle_name.o: In function `VEC_tree_heap_reserve_exact':
/tmp/nix-build-r7ajl7733zmbh0dw1pxpxbmh2766146v-gcj-4.4.0.drv-0/build/gcc/../../gcc-4.4.0/gcc/tree.h:192:
undefined reference to `vec_heap_p_reserve_exact'
java/mangle_name.o: In function `VEC_constructor_elt_gc_alloc':
/tmp/nix-build-r7ajl7733zmbh0dw1pxpxbmh2766146v-gcj-4.4.0.drv-0/build/gcc/../../gcc-4.4.0/gcc/tree.h:1533:
undefined reference to `vec_gc_o_reserve_exact'
java/mangle_name.o: In function `VEC_constructor_elt_gc_copy':
/tmp/nix-build-r7ajl7733zmbh0dw1pxpxbmh2766146v-gcj-4.4.0.drv-0/build/gcc/../../gcc-4.4.0/gcc/tree.h:1533:
undefined reference to `vec_gc_o_reserve_exact'
java/mangle_name.o: In function `VEC_constructor_elt_gc_free':
/tmp/nix-build-r7ajl7733zmbh0dw1pxpxbmh2766146v-gcj-4.4.0.drv-0/build/gcc/../../gcc-4.4.0/gcc/tree.h:1533:
undefined reference to `ggc_free'
java/mangle_name.o: In function `VEC_constructor_elt_gc_reserve':
/tmp/nix-build-r7ajl7733zmbh0dw1pxpxbmh2766146v-gcj-4.4.0.drv-0/build/gcc/../../gcc-4.4.0/gcc/tree.h:1533:
undefined reference to `vec_gc_o_reserve'
java/mangle_name.o: In function `VEC_constructor_elt_gc_reserve_exact':
/tmp/nix-build-r7ajl7733zmbh0dw1pxpxbmh2766146v-gcj-4.4.0.drv-0/build/gcc/../../gcc-4.4.0/gcc/tree.h:1533:
undefined reference to `vec_gc_o_reserve_exact'
java/mangle_name.o: In function `truth_value_p':
/tmp/nix-build-r7ajl7733zmbh0dw1pxpxbmh2766146v-gcj-4.4.0.drv-0/build/gcc/../../gcc-4.4.0/gcc/tree.h:4859:
undefined reference to `tree_code_type'
java/mangle_name.o: In function `tree_operand_length':
/tmp/nix-build-r7ajl7733zmbh0dw1pxpxbmh2766146v-gcj-4.4.0.drv-0/build/gcc/../../gcc-4.4.0/gcc/tree.h:5265:
undefined reference to `tree_code_type'
/tmp/nix-build-r7ajl7733zmbh0dw1pxpxbmh2766146v-gcj-4.4.0.drv-0/build/gcc/../../gcc-4.4.0/gcc/tree.h:5268:
undefined reference to `tree_code_length'
collect2: ld returned 1 exit status
make[3]: *** [jvgenmain] Error 1
--8<---cut here---start->8---

The `configure' flags are:

--prefix=/nix/store/yxj765br3ryx2sknm2qrbp78w4nci2lz-gcj-4.4.0
--disable-multilib
--disable-libstdcxx-pch
--with-system-zlib
--enable-languages=c,c++,java

Am I missing something here?

Thanks,
Ludo'.


-- 
   Summary: Failure to bootstrap GCJ 4.4.0
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ludo at gnu dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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



[Bug java/40731] Failure to bootstrap GCJ 4.4.0

2009-07-24 Thread ludo at gnu dot org


--- Comment #1 from ludo at gnu dot org  2009-07-24 23:17 ---
(In reply to comment #0)
> gcc  -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings

This differs from what I've seen in Debian build logs, where `jvgenmain' is
compiled at a later stage with `prev-gcc/xgcc'.  Both are doing "make
bootstrap" and I fail to see why `jvgenmain' ends up being produced earlier in
the NixOS case.

Ludo'.


-- 

ludo at gnu dot org changed:

   What|Removed |Added

     CC|            |ludo at gnu dot org


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



[Bug java/40731] Failure to bootstrap GCJ 4.4.0

2009-07-27 Thread ludo at gnu dot org


--- Comment #2 from ludo at gnu dot org  2009-07-27 15:25 ---
All this was due to our build script building the `configure-gcc' target early
on, which apparently confused the build process.  Sigh.

This bug can be closed now.

Sorry for the noise.

Ludo'.


-- 

ludo at gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug c/28319] sentinel attribute should support non-NULL sentinels

2008-02-21 Thread ludo at gnu dot org


--- Comment #2 from ludo at gnu dot org  2008-02-21 09:00 ---
(In reply to comment #1)
> The only time I can think this comes up is that the sentinel is -1.

As another example, GNU Guile has a number of variadic functions (e.g.,
`scm_list_n ()') whose sentinel is `SCM_UNDEFINED' (which happens to be 2^8 +
4).  It would be great to be able to specify that value as a second (optional)
argument to the `sentinel' attribute.

Ludovic.


-- 

ludo at gnu dot org changed:

   What|Removed |Added

 CC|                |ludo at gnu dot org


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



[Bug gcov-profile/57015] New: Link error while building GCC 4.8.0 with 4.7.2 and Binutils 2.22: hidden symbol `__deregister_frame_info' in /.../4.7.2/libgcc_eh.a(unwind-dw2-fde-dip.o) is referenced by

2013-04-20 Thread ludo at gnu dot org


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



 Bug #: 57015

   Summary: Link error while building GCC 4.8.0 with 4.7.2 and

Binutils 2.22: hidden symbol `__deregister_frame_info'

in /.../4.7.2/libgcc_eh.a(unwind-dw2-fde-dip.o) is

referenced by DSO

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: gcov-profile

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: l...@gnu.org





While building GCC 4.8.0 with GCC 4.7.2 and ld from Binutils 2.22, I get the

following error while link gcov:



g++   -g -DIN_GCC   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W

-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute

-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings

-fno-common  -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  gcov.o

libcommon.a ../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a

../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  -o gcov

ld: gcov: hidden symbol `__deregister_frame_info' in

/nix/store/47myfniw4x7kfc601d7q1yvz5mixlr00-gcc-4.7.2/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/libgcc_eh.a(unwind-dw2-fde-dip.o)

is referenced by DSO

ld: final link failed: Bad value

collect2: error: ld returned 1 exit status



The problem vanishes when switching to Binutils 2.23.2.



In case it matters, the configure flags are:

("CONFIG_SHELL=/nix/store/ryk1ywzz31kp4biclxq3yq6hpjycalyy-bash-4.2/bin/bash"

"SHELL=/nix/store/ryk1ywzz31kp4biclxq3yq6hpjycalyy-bash-4.2/bin/bash"

"--prefix=/nix/store/2qwicp3m3lwq6j44i72kdly7awv3pppx-gcc-4.8.0"

"--enable-fast-install" "--enable-plugin" "--enable-languages=c,c++"

"--disable-multilib" "--with-local-prefix=/no-gcc-local-prefix"

"--with-native-system-header-dir=/nix/store/9fnjjsbarscbmakr44ixfv9yhg6z12mw-glibc-2.17/include").



Thanks,

Ludo'.


[Bug libmudflap/18885] linker does not link libmudflap automatically with -fmudflap

2011-02-08 Thread ludo at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18885

Ludovic Courtès  changed:

   What|Removed |Added

 CC||ludo at gnu dot org

--- Comment #4 from Ludovic Courtès  2011-02-08 15:58:22 
UTC ---
I can confirm the problem with 4.5.1 on x86_64-linux-gnu.

Indeed, the `mflib' spec lacks `-lmudflap':

$ gcc -dumpspecs |grep -A2 -E '(mflib|link_command)'
*mflib:
%{fmudflap|fmudflapth: -export-dynamic}

--
*link_command:
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:%(linker)
%{fuse-linker-plugin: -plugin %(linker_plugin_file)
-plugin-opt=%(lto_wrapper) -plugin-opt=%(lto_gcc)
%{static|static-libgcc:-plugin-opt=-pass-through=%(lto_libgcc)}
%{static:-plugin-opt=-pass-through=-lc} %{O*:-plugin-opt=-O%*}
%{w:-plugin-opt=-w} %{f*:-plugin-opt=-f%*} %{m*:-plugin-opt=-m%*}
%{v:-plugin-opt=-v} } %{flto} %{fwhopr} %l %{pie:-pie} %X %{o*} %{A}
%{d} %{e*} %{m} %{N} %{n} %{r}%{s} %{t} %{u*} %{x} %{z} %{Z}
%{!A:%{!nostdlib:%{!nostartfiles:%S}}}%{static:} %{L*} %(mfwrap)
%(link_libgcc) %o   
%{fopenmp|ftree-parallelize-loops=*:%:include(libgomp.spec)%(link_gomp)}
%(mflib)%{fprofile-arcs|fprofile-generate*|coverage:-lgcov}   
%{!nostdlib:%{!nodefaultlibs:%(link_ssp) %(link_gcc_c_sequence)}}   
%{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} }}


[Bug c/53212] New: cpp consumes comment after pragma

2012-05-03 Thread ludo at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53212

 Bug #: 53212
   Summary: cpp consumes comment after pragma
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: l...@gnu.org


Consider this program:

  int foo ()
  {
  #pragma foo bar /* this is a comment */
  }

"gcc -C -E the-file.c" consumes the comment, whereas it should leave it as is.


[Bug bootstrap/59217] New: GCC fails to cross-build: conflicting declarations of 'basename', 'sbrk', etc.

2013-11-20 Thread ludo at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59217

Bug ID: 59217
   Summary: GCC fails to cross-build: conflicting declarations of
'basename', 'sbrk', etc.
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
      Reporter: ludo at gnu dot org

Cross-building GCC for GNU/Linux, with host & build glibc 2.18, fails while
building genconstants, genhooks, & co:

#v+
In file included from ../../gcc-4.8.2/gcc/genenums.c:21:0:
../../gcc-4.8.2/gcc/system.h:444:23: error: declaration of C function 'void*
sbrk(int)' conflicts with
 extern void *sbrk (int);
   ^
In file included from ../../gcc-4.8.2/gcc/system.h:254:0,
 from ../../gcc-4.8.2/gcc/genenums.c:21:
/nix/store/jwd1hc3i3pmnsxf2347r4k2c77nbr9vw-glibc-2.18/include/unistd.h:1065:14:
error: previous declaration 'void* sbrk(intptr_t)' here
 extern void *sbrk (intptr_t __delta) __THROW;
[...]
In file included from ../../gcc-4.8.2/gcc/system.h:645:0,
 from ../../gcc-4.8.2/gcc/genenums.c:21:
../../gcc-4.8.2/gcc/../include/libiberty.h:110:36: error: new declaration
'char* basename(const char*)'
 extern char *basename (const char *);
#v-

The configure flags are:

#v+
("CONFIG_SHELL=/nix/store/0r0r5wlg1mzf57haxfkalk62px93gch3-bash-4.2/bin/bash"
"SHELL=/nix/store/0r0r5wlg1mzf57haxfkalk62px93gch3-bash-4.2/bin/bash"
"--prefix=/nix/store/cjl2h4j31v03k13npnyb8v5q51qylp57-gcc-static-4.8.2"
"--enable-fast-install" "--host=mips64el-linux-gnuabi64" "--disable-shared"
"--disable-plugin" "--enable-languages=c" "--disable-libmudflap"
"--disable-libatomic" "--disable-libsanitizer" "--disable-libitm"
"--disable-libgomp" "--disable-libssp" "--disable-libquadmath"
"--disable-decimal-float" "--disable-multilib" "--disable-libstdcxx-pch"
"--with-local-prefix=/no-gcc-local-prefix"
"--with-native-system-header-dir=/nix/store/jwd1hc3i3pmnsxf2347r4k2c77nbr9vw-glibc-2.18/include"
"--with-abi=64" "CC_FOR_TARGET=mips64el-linux-gnuabi64-gcc"
"CXX_FOR_TARGET=mips64el-linux-gnuabi64-g++"
"LD_FOR_TARGET=mips64el-linux-gnuabi64-ld"
"AR_FOR_TARGET=mips64el-linux-gnuabi64-ar"
"NM_FOR_TARGET=mips64el-linux-gnuabi64-nm"
"RANLIB_FOR_TARGET=mips64el-linux-gnuabi64-ranlib"
"STRIP_FOR_TARGET=mips64el-linux-gnuabi64-strip")
#v-

(See <http://hydra.gnu.org/build/26604/nixlog/1/raw> for a complete log.)

One problem may be that all the configure tests are run with gcc (or
mips*-gcc), whereas gen{enums,hooks,checksum}.c get built with g++.  G++
automatically defines _GNU_SOURCE.  That leads to  emitting a
'basename' declaration, for instance; likewise the sbrk declaration in
 is conditioned by various __USE flags, which are prerequisites of
__USE_GNU.

Suggestions?

Thanks,
Ludo'.


[Bug bootstrap/59217] GCC fails to cross-build: conflicting declarations of 'basename', 'sbrk', etc.

2013-11-23 Thread ludo at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59217

Ludovic Courtès  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Ludovic Courtès  ---
After investigation I realized that the misdetections of missing 'basename'
etc. declarations on the build machine was a side-effect of not having
GMP/MPFR/MPC available for the build machine (presumably 'genconstants.c' & co.
didn't include it in 4.7.)

So this bug can be closed.  Apologies for the noise!

Ludo'.

PS: For the record the corresponding fix in Guix is
.

[Bug bootstrap/59217] GCC fails to cross-build: conflicting declarations of 'basename', 'sbrk', etc.

2013-11-23 Thread ludo at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59217

--- Comment #2 from Ludovic Courtès  ---
> PS: For the record the corresponding fix in Guix is
> .

err, should read:
.

[Bug bootstrap/71399] New: GCC 5.3.0 bootstrap comparison failure on arm-linux-gnueabihf

2016-06-03 Thread ludo at gnu dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399

Bug ID: 71399
   Summary: GCC 5.3.0 bootstrap comparison failure on
arm-linux-gnueabihf
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ludo at gnu dot org
  Target Milestone: ---

Created attachment 38637
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38637&action=edit
Diff of stage-2 and stage-3 disassembly of 'real.o'

We (GNU Guix) are getting a bootstrap comparison failure when building 5.3.0 on
arm-linux-gnueabihf:

  make[3]: Leaving directory '/tmp/guix-build-gcc-5.3.0.drv-0/build'
  Comparing stages 2 and 3
  warning: gcc/cc1plus-checksum.o differs
  warning: gcc/cc1-checksum.o differs
  Bootstrap comparison failure!
  gcc/libgcov-driver-tool.o differs
  gcc/tree-nested.o differs
  gcc/df-scan.o differs
  gcc/double-int.o differs
  gcc/simplify-rtx.o differs
  gcc/c/c-parser.o differs
  gcc/c/c-typeck.o differs
  gcc/gcov-dump.o differs
  gcc/tree-ssa-math-opts.o differs
  gcc/fold-const.o differs
  gcc/cp/semantics.o differs
  gcc/cp/optimize.o differs
  gcc/tree-dfa.o differs
  gcc/tree-inline.o differs
  gcc/c-family/cilk.o differs
  gcc/ipa-inline.o differs
  gcc/lto-section-out.o differs
  gcc/omp-low.o differs
  gcc/tree-switch-conversion.o differs
  gcc/lto-streamer-out.o differs
  gcc/real.o differs
  gcc/tree-ssa-sccvn.o differs
  gcc/coverage.o differs
  gcc/dwarf2cfi.o differs
  libiberty/pic/sort.o differs
  libiberty/pic/fibheap.o differs
  libiberty/pic/simple-object-xcoff.o differs
  libiberty/sort.o differs
  libiberty/fibheap.o differs
  libiberty/simple-object-xcoff.o differs
  Makefile:21400: recipe for target 'compare' failed
  make[2]: *** [compare] Error 1

The configure flags (from the top-level 'config.log) are:

  ../gcc-5.3.0/configure
CONFIG_SHELL=/gnu/store/h32j1gbdfsik6ap5szgvi8rlw1kqpsc9-bootstrap-binaries-0/bin/bash
SHELL=/gnu/store/h32j1gbdfsik6ap5szgvi8rlw1kqpsc9-bootstrap-binaries-0/bin/bash
--prefix=/gnu/store/6xdd64b8343v9vd3nkhkkqg7mayyxvwp-gcc-5.3.0
--enable-fast-install
--libdir=/gnu/store/40csg72342wcdfi3a3h1hxvbmmg6smi6-gcc-5.3.0-lib/lib
--includedir=/gnu/store/40csg72342wcdfi3a3h1hxvbmmg6smi6-gcc-5.3.0-lib/include
--build=arm-unknown-linux-gnueabihf --enable-plugin --enable-languages=c,c++
--disable-multilib --with-system-zlib --disable-libstdcxx-pch
--with-local-prefix=/no-gcc-local-prefix
--with-gxx-include-dir=/gnu/store/6xdd64b8343v9vd3nkhkkqg7mayyxvwp-gcc-5.3.0/include/c++
--with-native-system-header-dir=/gnu/store/n9dy4hb10l2s5vl1vxrmdcg6jgdz0p2x-glibc-2.23/include
--with-arch=armv7-a --with-float=hard --with-mode=thumb --with-fpu=neon

We also pass these 'make' variables when building:

  LDFLAGS='
-Wl,-rpath=/gnu/store/n9dy4hb10l2s5vl1vxrmdcg6jgdz0p2x-glibc-2.23/lib
-Wl,-dynamic-linker
-Wl,/gnu/store/n9dy4hb10l2s5vl1vxrmdcg6jgdz0p2x-glibc-2.23/lib/ld-linux-armhf.so.3
-L/gnu/store/gnkcmxqjscfw551l41lyxhmykcgnqwqp-libstdc++-5.3.0/lib
-L/gnu/store/03351ibq24p0f6jjpyjbyary4gpza5si-zlib-1.2.8/lib
-Wl,-rpath=/gnu/store/03351ibq24p0f6jjpyjbyary4gpza5si-zlib-1.2.8/lib'
  LDFLAGS_FOR_TARGET="$LDFLAGS"
  BOOT_CFLAGS="-O2 -g0"

As an example, attached is the disassembly of stage2-gcc/real.o and that of
stage3-gcc/real.o (one of the files that differ), obtained with 'objdump
--line-numbers --disassemble --section=.text real.o'.

Let me know if there's additional information I can provide.

(Originally discussed at
<https://lists.gnu.org/archive/html/guix-devel/2016-05/msg00988.html>.)

[Bug bootstrap/71399] GCC 5.3.0 bootstrap comparison failure on arm-linux-gnueabihf

2016-06-03 Thread ludo at gnu dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399

--- Comment #2 from Ludovic Courtès  ---
(In reply to ktkachov from comment #1)
> I tried a bootstrap of the GCC 5.3.0 release as taken from one of the
> mirrors in:
> https://gcc.gnu.org/mirrors.html
> 
> This was done on an ARMv8-A machine inside an aarch32 chroot with binutils
> 2.24 and glibc 2.19.

FWIW, I'm using Binutils 2.25.1 and glibc 2.23.

> The configure command was:
> --target=arm-none-linux-gnueabihf --build=arm-none-linux-gnueabihf
> --host=arm-none-linux-gnueabihf --with-arch=armv7-a --with-float=hard
> --with-mode=thumb --with-fpu=neon --enable-languages=c,c++
> --disable-multilib  --with-system-zlib --disable-libstdcxx-pch
> --enable-plugin
> 
> The bootstrap succeeded without problems.

Thanks for testing!

[Bug bootstrap/71399] GCC 5.3.0 bootstrap comparison failure on arm-linux-gnueabihf

2016-06-06 Thread ludo at gnu dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399

--- Comment #4 from Ludovic Courtès  ---
Created attachment 38650
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38650&action=edit
Diff of one of the RTL phases between stage 2 and 3, gcc/real.c, GCC 5.4.0

[Bug bootstrap/71399] GCC 5.3.0 bootstrap comparison failure on arm-linux-gnueabihf

2016-06-06 Thread ludo at gnu dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399

--- Comment #5 from Ludovic Courtès  ---
I tried this time with GCC 5.4.0, and with BOOT_CFLAGS='-O2 -g0 -da'.  I'm also
getting the failure:

  make[3]: Leaving directory '/tmp/guix-build-gcc-5.4.0.drv-0/build'
  Comparing stages 2 and 3
  warning: gcc/cc1plus-checksum.o differs
  warning: gcc/cc1-checksum.o differs
  Bootstrap comparison failure!
  gcc/c/c-parser.o differs
  gcc/c/c-typeck.o differs
  gcc/cp/semantics.o differs
  gcc/cp/optimize.o differs
  gcc/c-family/cilk.o differs
  gcc/coverage.o differs
  gcc/df-scan.o differs
  gcc/double-int.o differs
  gcc/dwarf2cfi.o differs
  gcc/fold-const.o differs
  gcc/ipa-inline.o differs
  gcc/omp-low.o differs
  gcc/real.o differs
  gcc/simplify-rtx.o differs
  gcc/tree-dfa.o differs
  gcc/tree-nested.o differs
  gcc/tree-inline.o differs
  gcc/tree-switch-conversion.o differs
  gcc/tree-ssa-math-opts.o differs
  gcc/tree-ssa-sccvn.o differs
  gcc/gcov-dump.o differs
  gcc/libgcov-driver-tool.o differs
  libiberty/simple-object-xcoff.o differs
  libiberty/fibheap.o differs
  libiberty/sort.o differs
  libiberty/pic/simple-object-xcoff.o differs
  libiberty/pic/fibheap.o differs
  libiberty/pic/sort.o differs
  Makefile:21400: recipe for target 'compare' failed
  make[2]: *** [compare] Error 1
  make[2]: Leaving directory '/tmp/guix-build-gcc-5.4.0.drv-0/build'

I have attached the diff of stage[23]-gcc/real.c.192r.expand in the hope it
would provide useful info.  I have hundreds of GiBs of RTL dumps to share, so
let me know what you'd like to see!  :-)

[Bug bootstrap/71399] GCC 5.3.0 bootstrap comparison failure on arm-linux-gnueabihf

2016-06-06 Thread ludo at gnu dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399

--- Comment #6 from Ludovic Courtès  ---
FWIW, we're bootstrapping from an ARM->ARM pseudo cross-compiler (same version,
that is 5.3.0 in the initial report, 5.4.0 in the latest report), along the
lines of:

  http://linuxfromscratch.org/lfs/view/stable/chapter05/toolchaintechnotes.html
  http://linuxfromscratch.org/lfs/view/stable/chapter05/gcc-pass1.html

The stragegy works fine on x86_64, i686, and mips64el.  It also worked well on
armhf with GCC 4.9.

Ludo'.

[Bug bootstrap/71399] GCC 5.3.0 bootstrap comparison failure on arm-linux-gnueabihf

2016-06-06 Thread ludo at gnu dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399

--- Comment #7 from Ludovic Courtès  ---
> I have attached the diff of stage[23]-gcc/real.c.192r.expand in the hope it
> would provide useful info.

The diffs are too noisy: due to '-gtoggle', we not only get "# DEBUG" comments
in stage2 dumps and not in stage3 dumps, but we also get 'debug_insn's in
stage2 that offset all the insn UIDs compared to stage3.  (Indeed, I believe
the 'real.c.192r.expand' dumps are in fact equivalent modulo "# DEBUG" comments
and 'debug_insn' forms.)

I narrowed this dump to the 'round_for_format' function since that's where the
assembly diverged.  Right from the beginning of the function, we see different
variable decls:

--- real.c.s2.narrowed  2016-06-06 16:10:01.482909061 +0200
+++ real.c.s3.narrowed  2016-06-06 16:09:46.321718424 +0200
@@ -99,10 +99,8 @@ void round_for_format(const real_format*
   int _119;
   bool _122;
   void * _126;
-  long unsigned int _128;
   struct real_value * _129;
   long unsigned int _130;
-  long unsigned int _131;
   sizetype _133;
   long unsigned int _135;
   unsigned int _136;
@@ -110,33 +108,32 @@ void round_for_format(const real_format*
   long unsigned int _138;
   long unsigned int _139;
   sizetype _141;
+  unsigned int _154;
   unsigned int _155;
-  unsigned int _156;
-  int _157;
-  void * _158;
-  bool _159;
-  unsigned int _161;
-  struct real_value * _162;
-  unsigned int _163;
+  int _156;
+  void * _157;
+  bool _158;
+  unsigned int _160;
+  struct real_value * _161;
+  unsigned int _162;
+  unsigned int _165;
   unsigned int _166;
-  unsigned int _167;
-  struct real_value * _168;
+  struct real_value * _167;
+  void * _169;
   void * _170;
-  void * _171;
-  bool _173;
-   pretmp_194;
-  int pretmp_196;
-  int prephitmp_197;
-   pretmp_204;
-  int pretmp_207;
-  int prephitmp_209;
-   pretmp_210;
-  int pretmp_212;
-  int prephitmp_213;
+  bool _172;
+   pretmp_193;
+  int pretmp_195;
+  int prephitmp_196;
+   pretmp_203;
+  int pretmp_206;
+  int prephitmp_208;
+   pretmp_209;
+  int pretmp_211;
+  int prephitmp_212;

 ;;   basic block 2, loop depth 0
 ;;pred:   ENTRY
-  # DEBUG round_up => 0
   _14 = BIT_FIELD_REF <*r_13(D), 8, 0>;
   _15 = _14 & 4;
   if (_15 != 0)


Does that help at all?

Any idea on how to get more exploitable debugging data?

Alternately, I can give instructions on how to reproduce with GNU Guix, which
shouldn't take long.

[Bug target/71399] [5/6/7 Regression] 5.3.0 bootstrap comparison failure on arm-linux-gnueabihf

2016-11-23 Thread ludo at gnu dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399

--- Comment #15 from Ludovic Courtès  ---
Hi Jakub,

Thanks for the suggestions.  Unfortunately I cannot offer to rebuild everything
with dumps right now; I'll see if I can do something later, no promise.

Hopefully, with the details and faulty commit I gave earlier, people can more
easily reproduce and pinpoint the problem.

[Bug bootstrap/71399] GCC 5.3.0 bootstrap comparison failure on arm-linux-gnueabihf

2016-09-04 Thread ludo at gnu dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399

--- Comment #8 from Ludovic Courtès  ---
Created attachment 39547
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39547&action=edit
Revert ARM-specific 4.9.3-to-4.9.4 changes

[Bug bootstrap/71399] GCC 5.3.0 bootstrap comparison failure on arm-linux-gnueabihf

2016-09-04 Thread ludo at gnu dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399

--- Comment #9 from Ludovic Courtès  ---
GCC 4.9.4 exhibits the same bootstrapping failure (again on
arm-linux-gnueabihf).

I reverted the ARM-specific changes made between 4.9.3 and 4.9.4 by applying
the result of "diff -ur gcc-4.9.{4,3}/gcc/config/arm" to 4.9.4 (patch
attached); the resulting compiler bootstraps fine.

[Bug target/71399] [5/6/7 Regression] 5.3.0 bootstrap comparison failure on arm-linux-gnueabihf

2016-09-09 Thread ludo at gnu dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399

--- Comment #10 from Ludovic Courtès  ---
In fact, the revert only needs to be done on the initial pseudo-cross-compiler
that is used to build the native compiler (I'm attaching a PDF of the
dependency graph, where the initial pseudo-cross-compiler as described at
http://linuxfromscratch.org/lfs/view/stable/chapter05/gcc-pass1.html is marked
as "gcc-cross-boot0", and the final native compiler is simply "gcc").

To summarize, if we build 4.9.4 with a cross-4.9.3, that's fine; if we build
4.9.4 with a cross-4.9.4, we get the bootstrap comparison failure.

That would suggest a code generation issue that somehow propagates from the
initial cross-compiler up to stage2 of the compiler we're building.

[Bug target/71399] [5/6/7 Regression] 5.3.0 bootstrap comparison failure on arm-linux-gnueabihf

2016-09-09 Thread ludo at gnu dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399

--- Comment #11 from Ludovic Courtès  ---
Created attachment 39587
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39587&action=edit
Dependency graph of the native compiler

[Bug target/71399] [5/6/7 Regression] 5.3.0 bootstrap comparison failure on arm-linux-gnueabihf

2016-09-12 Thread ludo at gnu dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399

--- Comment #12 from Ludovic Courtès  ---
(In reply to Ludovic Courtès from comment #10)
> In fact, the revert only needs to be done on the initial
> pseudo-cross-compiler that is used to build the native compiler (I'm
> attaching a PDF of the dependency graph, where the initial
> pseudo-cross-compiler as described at
> http://linuxfromscratch.org/lfs/view/stable/chapter05/gcc-pass1.html is
> marked as "gcc-cross-boot0", and the final native compiler is simply "gcc").
> 
> To summarize, if we build 4.9.4 with a cross-4.9.3, that's fine; if we build
> 4.9.4 with a cross-4.9.4, we get the bootstrap comparison failure.

The faulty commit is r231177 (commit f6ab85b7049a03962ea98924d00802da357a1ad3
in the Git mirror).

If we take 4.9.4 and revert r231177 in the "gcc-cross-boot0" compiler, then the
final gcc builds fine (no bootstrap comparison failure).  Note that the revert
needs not be applied to the final gcc, only to gcc-cross-boot0.

(For reference, we applied the revert here:
http://git.savannah.gnu.org/cgit/guix.git/commit/?id=e7e43727ce7b3426a31b2f50b035a5b0aba61d52
.)

Any idea what's going on here?

[Bug target/71399] [5/6/7 Regression] 5.3.0 bootstrap comparison failure on arm-linux-gnueabihf

2016-10-28 Thread ludo at gnu dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71399

--- Comment #13 from Ludovic Courtès  ---
Ping!

[Bug target/65711] arm*-linux* "link" spec passes '-dynamic-linker' even for '-shared'

2015-04-09 Thread ludo at gnu dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65711

Ludovic Courtès  changed:

   What|Removed |Added

 CC||ludo at gnu dot org

--- Comment #1 from Ludovic Courtès  ---
Created attachment 35270
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35270&action=edit
Proposed patch

[Bug target/65711] New: arm*-linux* "link" spec passes '-dynamic-linker' even for '-shared'

2015-04-09 Thread ludo at gnu dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65711

Bug ID: 65711
   Summary: arm*-linux* "link" spec passes '-dynamic-linker' even
for '-shared'
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
          Reporter: ludo at gnu dot org

gcc/config/arm/linux-elf.h defines LINUX_TARGET_LINK_SPEC to (simplified):

  %{!static -dynamic-linker LINKER}

However, '-dynamic-linker' should not be passed when '-shared' is used.  The
correct way appears to be what config/i386/gnu-user.h does, which is:

  %{!static %{!shared -dynamic-linker LINKER}}

I believe the attached patch fixes that.  At least both 4.8.4 and 4.9.2 are
affected.

(Initially discussed in the context of <http://bugs.gnu.org/20102>.)


[Bug libfortran/63930] New: libgfortran should use 'abort ()' instead of 'exit (2)' for run-time errors

2014-11-18 Thread ludo at gnu dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63930

Bug ID: 63930
   Summary: libgfortran should use 'abort ()' instead of 'exit
(2)' for run-time errors
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
      Reporter: ludo at gnu dot org

libgfortran/runtime/error.c uses "exit (2)" in a few places to handle run-time
errors.  I would suggest replacing these calls with "abort ()".

The rationale is that using "abort" would make things more convenient for
users: one could inspect the core dump, or, when running the program in GDB,
directly get a prompt upon SIGABRT instead of having to resort to "catch
syscall exit_group".

Thanks.


[Bug c/28319] sentinel attribute should support non-NULL sentinels

2008-04-21 Thread ludo at gnu dot org


--- Comment #3 from ludo at gnu dot org  2008-04-21 12:14 ---
I proposed a patch, which awaits approval and copyright assignment:

  http://article.gmane.org/gmane.comp.gcc.patches/160923/focus=160991

Ludovic.


-- 


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