Re: Phase 1 of gcc-in-cxx now complete
On Sat, Jun 27, 2009 at 2:55 AM, Ian Lance Taylori...@google.com wrote: Matt m...@use.net writes: * Develop some trial patches which require C++, e.g., convert VEC to std::vector. Do you have any ideas for the easiest starting points? Is there anywhere that is decently self-contained, or will if have to be a big bang? Thanks for your interest. I think the one I mentioned--converting VEC to std::vector--is a good starting point. This is the interface in vec.h. Another easy starting point would be converting uses of htab_t to type safe C++ hash tables, e.g., std::tr1:;unordered_map. Here portability suggests the ability to switch to different hash table implementations; see gold/gold.h in the GNU binutils for one way to approach that. Another easy starting point is finding calls to qsort and converting them to std::sort, which typically leads to code which is larger but runs faster. Longer term, we know that memory usage is an issue in gcc. In the old obstack days, we had a range of obstacks with different lifespans, so we could create RTL with a temporary lifetime which was given a longer lifetime when needed. We got away from that because we spent far too much time chasing bugs in which RTL should have been saved to a longer lifetime but wasn't. However, that model should permit us to run with significantly less memory, which would translate to less compile time. I think we might be able to do it by implementing a custom allocator, such as a pool allocator which permits allocating different sizes of memory, and never frees memory. Then the tree class could take an allocator as a template parameter. Then we would provide convertors which copied the tree class to a different allocation style. Then, for example, fold-const.c could use a temporary pool which lived only for the length of the call to fold. If it returned a new value, the convertor would force a copy out of the temporary pool. If this works out, we can use type safety to enforce memory discipline, use significantly less memory during compilation, and take a big step toward getting rid of the garbage collector. All that above said - do you expect us to carry both vec.h (for VEC in GC memory) and std::vector (for VECs in heap memory) (and vec.h for the alloca trick ...)? Or do you think we should try to make the GTY machinery C++ aware and annotate the standard library (ick...)? That said - I was more expecting to re-write the existing vec.h to C++ to avoid this GC vs. non-GC use differences. Also as the standard library uses a very inefficient allocator by default, should we for example switch from bitmap to an equivalend standard library container. IMHO we should at least try without the standard library for a start, fixing the GTY machinery. Richard.
Re: Phase 1 of gcc-in-cxx now complete (Ada)
Interesting. I've been testing my -Wc++-compat patches with full bootstraps including Ada, but I just looked at my make log and it does indeed appear that -Wc++-compat doesn't make it onto the Ada files. It seems to be because of this line in ada/gcc-interface/Make-lang.in: ada-warn = $(ADA_CFLAGS) $(WERROR) The other languages use DIR-warn = $(STRICT_WARN) which is what brings in -Wc++-compat. I get -Wc++-compat warnings though: /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c: In function 'substitute_in_type': /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c:7865:8: warning: identifier 'new' conflicts with C++ keyword /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c:7886:4: warning: identifier 'new' conflicts with C++ keyword /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c:7894:11: warning: identifier 'new' conflicts with C++ keyword /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c:7907:4: warning: identifier 'new' conflicts with C++ keyword /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c:7911:11: warning: identifier 'new' conflicts with C++ keyword /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c:7917:7: warning: identifier 'new' conflicts with C++ keyword /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c:7918:11: warning: identifier 'new' conflicts with C++ keyword /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c:7921:34: warning: identifier 'new' conflicts with C++ keyword /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c:7938:2: warning: identifier 'new' conflicts with C++ keyword /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c:7947:9: warning: identifier 'new' conflicts with C++ keyword /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c:7960:2: warning: identifier 'new' conflicts with C++ keyword /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c:7992:33: warning: identifier 'new' conflicts with C++ keyword /home/eric/gnat/gnat-head/src/gcc/ada/gcc-interface/decl.c:8008:9: warning: identifier 'new' conflicts with C++ keyword but they don't stop the build because -Werror is not passed. That needs to be fixed first. -- Eric Botcazou
Re: Phase 1 of gcc-in-cxx now complete (Ada)
On Fri, 2009-06-26 at 12:52 -0700, Ian Lance Taylor wrote:
Arnaud Charlet char...@adacore.com writes:
Switching gnatbind to generate Ada if there's nothing against
it might be a better solution since stage1 uses the system gnatbind, so
a patch to current gnatbind will not help (unless we push it to branches
and tell user to install a fairly recent gnatbind first).
This does create a bootstrap incompatibility/issue indeed, interesting.
Yet another alternative would be to use a C compiler to compile the binder
generated file during bootstrap.
Yes, I think that either compiling with a C compiler, or generating Ada
bindings, would be the best approach here.
Switching gnatbind to generate Ada during bootstrap and with a mostly
mechanical patch adding #ifdef __cplusplus / extern C where needed to
honor matching pragma Import/Export (C, xxx) in Ada code I now get all
three stages and gnatlib to build successfully on the branch.
There was one other C/C++ compat issue: wrong code generated in
gcc/ada/gcc-interface/utils.c and Andrew Pinski suggested the solution
on IRC:
@@ -4861,7 +4861,7 @@
va_start (list, n);
for (i = 0; i n; ++i)
{
- builtin_type a = va_arg (list, builtin_type);
+ builtin_type a = (builtin_type)va_arg (list, int);
t = builtin_types[a];
if (t == error_mark_node)
goto egress;
This was the only va_arg usage, may be we should apply it on trunk too
as the patched version is supposed to work for both C and C++.
For toplevel gnattools I have a link issue since the LINKER
variable used in the gcc subdir is not passed at toplevel, I'm currently
trying wether passing LINKER=$(CXX) will do but I'm not sure that we
really want here.
I will submit the gnatbind switch to Ada patch separately for review on
trunk after testing completes.
Hopefully there seem to be no major issue in having Ada working
on the gcc-in-cxx branch.
Sincerely,
Laurent
Re: Phase 1 of gcc-in-cxx now complete (Ada)
This was the only va_arg usage, may be we should apply it on trunk too as the patched version is supposed to work for both C and C++. Yes, but I'm testing a patch for trunk with more changes. -- Eric Botcazou
Re: Phase 1 of gcc-in-cxx now complete (Ada)
On Sat, 2009-06-27 at 13:25 +0200, Eric Botcazou wrote:
This was the only va_arg usage, may be we should apply it on trunk too
as the patched version is supposed to work for both C and C++.
Yes, but I'm testing a patch for trunk with more changes.
For reference here is my current draft patch to gcc-in-cxx branch,
it completes make bootstrap including gnattools, check
running.
Laurent
Index: gcc/ada/adadecode.h
===
--- gcc/ada/adadecode.h (revision 148953)
+++ gcc/ada/adadecode.h (working copy)
@@ -29,6 +29,11 @@
* *
/
+
+#ifdef __cplusplus
+extern C {
+#endif
+
/* This function will return the Ada name from the encoded form.
The Ada coding is done in exp_dbug.ads and this is the inverse function.
see exp_dbug.ads for full encoding rules, a short description is added
@@ -51,3 +56,8 @@
function used in the binutils and GDB. Always consider using __gnat_decode
instead of ada_demangle. Caller must free the pointer returned. */
extern char *ada_demangle (const char *);
+
+
+#ifdef __cplusplus
+}
+#endif
Index: gcc/ada/sysdep.c
===
--- gcc/ada/sysdep.c(revision 148953)
+++ gcc/ada/sysdep.c(working copy)
@@ -32,6 +32,10 @@
/* This file contains system dependent symbols that are referenced in the
GNAT Run Time Library */
+#ifdef __cplusplus
+extern C {
+#endif
+
#ifdef __vxworks
#include ioLib.h
#include dosFsLib.h
@@ -938,3 +942,7 @@
return 0;
}
}
+
+#ifdef __cplusplus
+}
+#endif
Index: gcc/ada/targext.c
===
--- gcc/ada/targext.c (revision 148953)
+++ gcc/ada/targext.c (working copy)
@@ -33,6 +33,10 @@
/* extension for object and executable files. It is used by the compiler, */
/* binder and tools. */
+#ifdef __cplusplus
+extern C {
+#endif
+
#include system.h
#include coretypes.h
#include tm.h
@@ -48,3 +52,8 @@
const char *__gnat_target_object_extension = TARGET_OBJECT_SUFFIX;
const char *__gnat_target_executable_extension = TARGET_EXECUTABLE_SUFFIX;
const char *__gnat_target_debuggable_extension = TARGET_EXECUTABLE_SUFFIX;
+
+
+#ifdef __cplusplus
+}
+#endif
Index: gcc/ada/s-oscons-tmplt.c
===
--- gcc/ada/s-oscons-tmplt.c(revision 148953)
+++ gcc/ada/s-oscons-tmplt.c(working copy)
@@ -79,6 +79,11 @@
**
**/
+
+#ifdef __cplusplus
+extern C {
+#endif
+
#include stdlib.h
#include string.h
#include limits.h
@@ -1307,8 +1312,14 @@
#endif
+
/*
end System.OS_Constants;
*/
}
+
+
+#ifdef __cplusplus
+ }
+#endif
Index: gcc/ada/env.c
===
--- gcc/ada/env.c (revision 148953)
+++ gcc/ada/env.c (working copy)
@@ -29,6 +29,11 @@
* *
/
+
+#ifdef __cplusplus
+extern C {
+#endif
+
#ifdef IN_RTS
#include tconfig.h
#include tsystem.h
@@ -313,3 +318,7 @@
clearenv ();
#endif
}
+
+#ifdef __cplusplus
+}
+#endif
Index: gcc/ada/final.c
===
--- gcc/ada/final.c (revision 148953)
+++ gcc/ada/final.c (working copy)
@@ -29,6 +29,11 @@
* *
/
+
+#ifdef __cplusplus
+extern C {
+#endif
+
extern void __gnat_finalize (void);
/* This routine is called at the extreme end of execution of an Ada program
@@ -40,3 +45,8 @@
__gnat_finalize (void)
{
}
+
+
+#ifdef __cplusplus
+}
+#endif
Index: gcc/ada/init.c
===
--- gcc/ada/init.c (revision 148953)
+++ gcc/ada/init.c (working copy)
@@ -38,6 +38,11 @@
installed by this file are used to catch the resulting signals that come
from these probes failing (i.e. touching protected pages). */
+
+#ifdef __cplusplus
+extern C {
+#endif
+
/* This file should be kept synchronized with 2sinit.ads, 2sinit.adb,
s-init-ae653-cert.adb and s-init-xi-sparc.adb. All these files implement
the required functionality for different targets. */
@@ -2319,3 +2324,7 @@
}
#endif
+
+#ifdef __cplusplus
+}
+#endif
Index: gcc/ada/xsnamest.adb
===
--- gcc/ada/xsnamest.adb(revision 148953)
+++ gcc/ada/xsnamest.adb(working copy)
@@ -194,6 +194,10 @@
Create (OutB, Out_File, snames.nb);
Create (OutH, Out_File, snames.nh);
+
Re: Phase 1 of gcc-in-cxx now complete (Ada)
On Sat, 2009-06-27 at 13:51 +0200, Laurent GUERBY wrote: On Sat, 2009-06-27 at 13:25 +0200, Eric Botcazou wrote: This was the only va_arg usage, may be we should apply it on trunk too as the patched version is supposed to work for both C and C++. Yes, but I'm testing a patch for trunk with more changes. For reference here is my current draft patch to gcc-in-cxx branch, it completes make bootstrap including gnattools, check running. During make check gnat.dg was clean but there were two FAIL in ACATS: === acats tests === FAIL: c940005 FAIL: c940007 === acats Summary === # of expected passes2313 # of unexpected failures2 Native configuration is x86_64-unknown-linux-gnu === gnat Summary === # of expected passes659 # of expected failures 5 ,.,. C940005 ACATS 2.5 09-06-27 14:16:44 C940005 Check internal calls of protected functions and procedures. * C940005 Unexpected paths taken. C940005 FAILED . ,.,. C940007 ACATS 2.5 09-06-27 14:16:46 C940007 Check internal calls of protected functions and procedures in objects declared as a type. * C940007 Unexpected paths taken. C940007 FAILED . I haven't investigated those FAIL. make install worked too and the installed compiler is able to compile and link small Ada programs. I'll let maintainers comment on what we should do and with what timing. Sincerely, Laurent
Re: Phase 1 of gcc-in-cxx now complete
All that above said - do you expect us to carry both vec.h (for VEC in GC memory) and std::vector (for VECs in heap memory) (and vec.h for the alloca trick ...)? Or do you think we should try to make the GTY machinery C++ aware and annotate the standard library (ick...)? Since the containers have mostly standard iterators, i'm not sure we have to do much to the standard library. Simply require a set of iterators with the right properties exist and generate code that depends on this. If you make your own container, you have to implement the iterators.
Re: Phase 1 of gcc-in-cxx now complete
Daniel Berlin wrote: All that above said - do you expect us to carry both vec.h (for VEC in GC memory) and std::vector (for VECs in heap memory) (and vec.h for the alloca trick ...)? Or do you think we should try to make the GTY machinery C++ aware and annotate the standard library (ick...)? Since the containers have mostly standard iterators, i'm not sure we have to do much to the standard library. Simply require a set of iterators with the right properties exist and generate code that depends on this. If you make your own container, you have to implement the iterators. Shouldn't this be a new thread, or is this really part of phase 1?
Re: Phase 1 of gcc-in-cxx now complete (Ada)
CC=../../xgcc -B../../ \ + LINKER=$(CXX) \ CFLAGS=$(CFLAGS) $(WARN_CFLAGS) \ I think you should rather do CC=../../xgcc -B../../ \ + CXX=../../g++ -B../../ \ CFLAGS=$(CFLAGS) $(WARN_CFLAGS) \ + CXXFLAGS=$(CXXFLAGS) $(WARN_CFLAGS) \ and copy the setting of COMPILER and LINKER from gcc/Makefile.in into gcc/ada/gcc-interface/Makefile.in: ENABLE_BUILD_WITH_CXX = @ENABLE_BUILD_WITH_CXX@ ifneq ($(ENABLE_BUILD_WITH_CXX),yes) COMPILER = $(CC) COMPILER_FLAGS = $(CFLAGS) LINKER = $(CC) LINKER_FLAGS = $(CFLAGS) else COMPILER = $(CXX) COMPILER_FLAGS = $(CXXFLAGS) LINKER = $(CXX) LINKER_FLAGS = $(CXXFLAGS) endif Paolo
Re: Phase 1 of gcc-in-cxx now complete
Ian Lance Taylor i...@google.com writes: I would like to encourage people to try using --enable-build-with-cxx in other configuration--other bootstraps, cross-compilers--to see how well it works. Please let me know if you run into problems that you don't know how, or don't have time, to fix. MIPS bootstraps fine with --enable-build-with-cxx: http://gcc.gnu.org/ml/gcc-testresults/2009-06/msg02323.html I don't know if the new failures are related to C++; I will do a C build later and compare. Ian, thanks for your C++ work! Adam
Re: Phase 1 of gcc-in-cxx now complete
On Thu, Jun 25, 2009 at 4:32 PM, Ian Lance Taylori...@google.com wrote: I would like to encourage people to try using --enable-build-with-cxx in other configuration--other bootstraps, cross-compilers--to see how well it works. Please let me know if you run into problems that you don't know how, or don't have time, to fix. I tried bootstrap with AIX. Because AIX static libstdc++ requires libsupc++, the search path for that library in the build directory needs to be on the link line. Manually adding that directory allows GCC on AIX to get through stage3 bootstrap. There are two other problems / annoyances independent of AIX: 1) All of the multilibs for libstdc++ are configured and built during bootstrap. This always has been the case for libgcc, but it was not as much of an inconvenience. 2) The Graphite CLooG headers are not C++-clean, so enabling Graphite fails in CXX mode. David
Re: Phase 1 of gcc-in-cxx now complete
On Sat, Jun 27, 2009 at 11:51, David Edelsohndje@gmail.com wrote: 2) The Graphite CLooG headers are not C++-clean, so enabling Graphite fails in CXX mode. I did applied the patches from Ian to the cloog-ppl git. The git version should compile with a C++ compiler. Sebastian
Inline Assembly queries
Hello All the gurus, I've been fiddling my luck with gcc 4.3.2 inline assembly on powerpc There are a few queries 1. asm volatile or simply asm produce the same assembly code. Tried with a few examples but didnt find any difference by adding volatile with asm 2. Use of memory and clobbered registers. memory - a. announce to the compiler that the memory has been modified b. this instruction writes to some memory (other than a listed output) and GCC shouldn’t cache memory values in registers across this asm. I tried with stw and stwcx instruction, adding memory has no effect. Is there any example scenerio where gcc would generate different assembly by adding / removing memory ? -TZ
The Linux binutils 2.19.51.0.11 is released
Main changes from binutils 2.19.51.0.10:
Fix strip on static executable with STT_GNU_IFUNC symbol. PR 10337.
Add STB_GNU_UNIQU support.
H.J.
---
This is the beta release of binutils 2.19.51.0.11 for Linux, which is
based on binutils 2009 0627 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been applied and
in what order they have been applied.
Starting from the 2.18.50.0.4 release, the x86 assembler no longer
accepts
fnstsw %eax
fnstsw stores 16bit into %ax and the upper 16bit of %eax is unchanged.
Please use
fnstsw %ax
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.
For
.data.init_task : { *(.data.init_task) }
LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use
.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }
to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior. You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
monitor
which works with both old and new x86_64 assemblers. They should
generate the same opcode.
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,
mov (%eax),%ds
mov %ds,(%eax)
should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support
movw (%eax),%ds
movw %ds,(%eax)
without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at
http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch
The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add
ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif
to arch/ia64/Makefile in your kernel source tree.
Please report any bugs related to binutils 2.19.51.0.11 to
hjl.to...@gmail.com
and
http://www.sourceware.org/bugzilla/
Changes from binutils 2.19.51.0.10:
1. Update from binutils 2009 0627.
2. Fix strip on static executable with STT_GNU_IFUNC symbol. PR 10337.
3. Add STB_GNU_UNIQU support.
4. Fix objcopy on empty file. PR 10321.
5. Fix debug section for PE-COFF.
6. Suport build with gcc 4.5.0.
7. Improve arm support.
8. Improve ppc support.
9. Improve m10300 support.
10. Improve mep support.
11. Improve MacOS support.
12. Improve gold support.
Changes from binutils 2.19.51.0.9:
1. Update from binutils 2009 0618.
2. Update STT_GNU_IFUNC symbol support. PR 10269/10270.
3. Fix an assembler CFI bug. PR 10255.
4. Improve objdump. PR 10263/10288
5. Improve readelf.
6. Improve arm support.
7. Improve moxie support.
8. Improve spu support.
9. Improve vax support.
10. Improve COFF/PE support.
11. Improve MacOS support.
Changes from binutils 2.19.51.0.8:
1. Update from binutils 2009 0606.
2. Update STT_GNU_IFUNC symbol support.
Changes from binutils 2.19.51.0.7:
1. Update from binutils 2009 0603.
2. Fix STT_GNU_IFUNC symbol with pointer equality.
Changes from binutils 2.19.51.0.6:
1. Update from binutils 2009 0601.
2. Update STT_GNU_IFUNC support. PR 10205.
3. Fix x86 asssembler Intel syntax regression with '$'. PR 10198.
Changes from binutils 2.19.51.0.5:
1. Update from binutils 2009 0529.
2. Rewrite STT_GNU_IFUNC, R_386_IRELATIVE and R_X86_64_IRELATIVE linker
support for STT_GNU_IFUNC symbols in shared library, dynamic executable
and static executable.
3. Add plugin support.
4. Improve spu support.
Changes from binutils 2.19.51.0.4:
1. Update from binutils 2009 0525.
2. Add STT_GNU_IFUNC, R_386_IRELATIVE and R_X86_64_IRELATIVE support to
assembler and linker.
3. Add LD_AS_NEEDED support to linker.
4. Remove AMD SSE5 support.
5. A new Intel syntax parser in x86 assembler.
6. Add DWARF discriminator support.
7. Add --64 support for x86 PE/COFF assembler.
8. Support common symbol with alignment for PE/COFF.
9. Improve gold support.
10. Improve arm support.
Re: Phase 1 of gcc-in-cxx now complete
Richard Guenther richard.guent...@gmail.com writes: All that above said - do you expect us to carry both vec.h (for VEC in GC memory) and std::vector (for VECs in heap memory) (and vec.h for the alloca trick ...)? Or do you think we should try to make the GTY machinery C++ aware and annotate the standard library (ick...)? I expect us to write a GC allocator, and use that with std::vector. This will require more hooks into the GC code, but I think it is doable. IMHO we should at least try without the standard library for a start, fixing the GTY machinery. If we can't write a GC allocator, then I agree. Ian
Exploring gcc-in-cxx compiler build requirements
Hi, all, I just tried to build gcc-in-cxx with some older gcc compilers on x86_64 linux. This is Debian testing, with 4.3.3 as the system compiler. Here's what I've gotten so far: 2.95.3 Doesn't support x86_64 3.0.4 Doesn't support x86_64 3.1.1 Fails to bootstrap 3.2.3 Fails to bootstrap Both 3.1.1 and 3.2.3 fail to bootstrap with the following error: make[1]: Entering directory `/home/jlquinn/gcc/dev/build/gcc323/gcc' gcc -c -DIN_GCC--std=gnu89 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H -DGENERATOR_FILE-I. -I. -I../../../gcc-3.2.3/gcc -I../../../gcc-3.2.3/gcc/. -I../../../gcc-3.2.3/gcc/config -I../../../gcc-3.2.3/gcc/../include ../../../gcc-3.2.3/gcc/read-rtl.c -o read-rtl.o In file included from ../../../gcc-3.2.3/gcc/read-rtl.c:24: ../../../gcc-3.2.3/gcc/rtl.h:125: warning: type of bit-field ‘code’ is a GCC extension ../../../gcc-3.2.3/gcc/rtl.h:128: warning: type of bit-field ‘mode’ is a GCC extension ../../../gcc-3.2.3/gcc/read-rtl.c: In function ‘fatal_with_file_and_line’: ../../../gcc-3.2.3/gcc/read-rtl.c:62: warning: traditional C rejects ISO C style function definitions ../../../gcc-3.2.3/gcc/read-rtl.c: In function ‘read_rtx’: ../../../gcc-3.2.3/gcc/read-rtl.c:662: error: lvalue required as increment operand make[1]: *** [read-rtl.o] Error 1 make[1]: Leaving directory `/home/jlquinn/gcc/dev/build/gcc323/gcc' make: *** [all-gcc] Error 2 3.3.6 old compiler builds. branch bootstrap fails with: make[3]: Entering directory `/home/jlquinn/gcc/dev/gcc-in-cxx/host-x86_64-unknown-linux-gnu/gcc' g++ -c -g -g -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/bid -I../libdecnumber../.././gcc/c-lang.c -o c-lang.o In file included from /home/jlquinn/gcc/dev/run/gcc336/include/c ++/3.3.6/iosfwd:46, from /usr/include/gmp-x86_64.h:24, from /usr/include/gmp.h:59, from ../../gcc/double-int.h:24, from ../../gcc/tree.h:30, from ../../gcc/c-lang.c:27: /home/jlquinn/gcc/dev/run/gcc336/include/c ++/3.3.6/x86_64-unknown-linux-gnu/bits/c++locale.h:61:40: attempt to use poisoned malloc make[3]: *** [c-lang.o] Error 1 make[3]: Leaving directory `/home/jlquinn/gcc/dev/gcc-in-cxx/host-x86_64-unknown-linux-gnu/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/jlquinn/gcc/dev/gcc-in-cxx' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/jlquinn/gcc/dev/gcc-in-cxx' make: *** [all] Error 2 I updated the system gmp to 4.2.3, so the C++ fix is present in the header. I'm configuring and bootstrapping with the 3.3.6 install at the head of the path. Maybe building with the CXX and CC explicitly specified would work better here. I didn't run the test suite on the 3.3.6 build, so it's possible it didn't build correctly. gcc 3.4.6 successfully bootstraps the branch with all default languages. Jerry
[Bug other/40302] [4.5 Regression] GCC must hard-require MPC before release
--- Comment #4 from ghazi at gcc dot gnu dot org 2009-06-27 06:23 --- Delete all the cpp HAVE_mpc goo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40302
[Bug testsuite/40565] [4.5 Regression] Extra failures
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-06-27 09:49 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40565
[Bug c++/40566] New: rejects promoted throw
void f(int x) { char c = x ? 23 : throw bla; }
error: aggregate value used where an integer was expected
because we call convert_to_integer on the throw_expression.
--
Summary: rejects promoted throw
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40566
[Bug c++/40566] [4.3/4.4/4.5 Regression] rejects promoted throw
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||3.3.6 4.0.0 4.4.1 4.5.0 Known to work||2.95.3 Summary|rejects promoted throw |[4.3/4.4/4.5 Regression] ||rejects promoted throw Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40566
[Bug testsuite/40567] New: [4.5 regression] Revision 149002 caused many failures
On Linux/ia32, revision 149002: http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg00987.html caused: FAIL: gcc.dg/vect/O3-pr36098.c (test for excess errors) FAIL: gcc.dg/vect/O3-pr39675-2.c (test for excess errors) FAIL: gcc.dg/vect/O3-pr39675-2.c scan-tree-dump-times vect vectorized 1 loops 1: dump file does not exist FAIL: gcc.dg/vect/O3-pr39675-2.c scan-tree-dump-times vect vectorizing stmts using SLP 1: dump file does not exist FAIL: gcc.dg/vect/O3-vect-pr32243.c (test for excess errors) FAIL: gcc.dg/vect/O3-vect-pr34223.c (test for excess errors) FAIL: gcc.dg/vect/O3-vect-pr34223.c scan-tree-dump-times vect vectorized 1 loops 1: dump file does not exist -- Summary: [4.5 regression] Revision 149002 caused many failures Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40567
[Bug testsuite/40567] [4.5 regression] Revision 149002 caused many failures
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40567
[Bug testsuite/40567] [4.5 regression] Revision 149002 caused many failures
--- Comment #1 from bonzini at gnu dot org 2009-06-27 14:40 --- Subject: Bug 40567 Author: bonzini Date: Sat Jun 27 14:40:29 2009 New Revision: 149006 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149006 Log: 2009-06-27 Paolo Bonzini bonz...@gnu.org PR testsuite/40567 * gcc.dg/vect/vect.exp: Fix lappend syntax. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40567
[Bug tree-optimization/26854] [4.3/4.4/4.5 Regression] Inordinate compile times on large routines
--- Comment #109 from bonzini at gnu dot org 2009-06-27 14:48 --- Subject: Bug 26854 Author: bonzini Date: Sat Jun 27 14:48:34 2009 New Revision: 149010 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149010 Log: 2009-06-07 Paolo Bonzini bonz...@gnu.org PR rtl-optimization/26854 * timevar.def: Remove TV_DF_RU, add TV_DF_MD. * df-problems.c (df_rd_add_problem): Fix comment. (df_md_set_bb_info, df_md_free_bb_info, df_md_alloc, df_md_simulate_artificial_defs_at_top, df_md_simulate_one_insn, df_md_bb_local_compute_process_def, df_md_bb_local_compute, df_md_local_compute, df_md_reset, df_md_transfer_function, df_md_init, df_md_confluence_0, df_md_confluence_n, df_md_free, df_md_top_dump, df_md_bottom_dump, problem_MD, df_md_add_problem): New. * df.h (DF_MD, DF_MD_BB_INFO, struct df_md_bb_info, df_md, df_md_get_bb_info): New. DF_LAST_PROBLEM_PLUS1): Adjust. * Makefile.in (fwprop.o): Include domwalk.h. * fwprop.c: Include domwalk.h. (reg_defs, reg_defs_stack): New. (bitmap_only_bit_between): Remove. (process_defs): New. (process_uses): Use reg_defs and local_md instead of bitmap_only_bit_between and local_rd. (single_def_use_enter_block): New, from build_single_def_use_links. (single_def_use_leave_block): New. (build_single_def_use_links): Remove code moved to single_def_use_enter_block, invoke domwalk. (use_killed_between): Adjust comment. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/df-problems.c trunk/gcc/df.h trunk/gcc/fwprop.c trunk/gcc/timevar.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug middle-end/40550] Segmentation fault caused by alignment error in sse code
--- Comment #8 from CaptainSifff at gmx dot de 2009-06-27 15:44 --- This also happens in gcc-4.2.1 on i686. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40550
[Bug fortran/40568] New: F2008: C_SIZEOF is in the wrong scope
C_SIZEOF should be a function in ISO_C_BINDING, however, in gfortran it is a normal intrinsic. Expected: - The USE statement works - Using C_SIZEOF should give an error use iso_c_binding, only: so = c_sizeof implicit none print *, c_sizeof(1) end -- Summary: F2008: C_SIZEOF is in the wrong scope Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40568
[Bug other/40024] trunk/gcc-4.3/gcc: * emutls.c (emutls_destroy): Don' t fall out of the array bound.
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-06-27 16:05 --- I noticed for version 4.4 (x86_64-*-mingw* and i686-*-mingw*) this issue still exist. On 4.5 branch it is fixed. I would like that it the patch is getting applied on the 4.4.1 branch, too. It fixed a crash in emutls_destroy, we get for 4.4 branch. Any chance? Kai -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40024
[Bug fortran/40569] New: F2008: Support COMPILER_OPTIONS() / COMPILER_VERSION()
Fortran 2008 adds the two inquiry subroutines, which return a string. In GCC the version string is in version.h: extern const char version_string[]; The options string has to constructed manually; the question is whether one wants to skip certain options. Optimally, one would record exactly those options passed to gfortran and not all those options passed to f951. The middle end has -frecord-gcc-switches and -fverbose-asm; cf. toplev.c's print_switch_values. -- Summary: F2008: Support COMPILER_OPTIONS() / COMPILER_VERSION() Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40569
[Bug target/40489] gcc.dg/builtin-unreachable-3.c doesn't work on ia64
--- Comment #2 from hjl at gcc dot gnu dot org 2009-06-27 16:43 --- Subject: Bug 40489 Author: hjl Date: Sat Jun 27 16:43:28 2009 New Revision: 149014 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149014 Log: 2009-06-27 H.J. Lu hongjiu...@intel.com PR target/40489 * config/ia64/ia64.c (ia64_reorg): Check NULL insn. Modified: trunk/gcc/ChangeLog trunk/gcc/config/ia64/ia64.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40489
[Bug other/40024] trunk/gcc-4.3/gcc: * emutls.c (emutls_destroy): Don' t fall out of the array bound.
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-06-27 17:50 --- Subject: Bug 40024 Author: ktietz Date: Sat Jun 27 17:50:20 2009 New Revision: 149015 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149015 Log: 2009-06-27 Kai Tietz kai.ti...@onevision.com Merged from trunk rev/148061 2009-06-01 Jakub Jelinek ja...@redhat.com PR other/40024 * emutls.c (__emutls_get_address): Change arr-size to mean number of allocated arr-data entries instead of # of slots + 1. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/emutls.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40024
[Bug other/40024] trunk/gcc-4.3/gcc: * emutls.c (emutls_destroy): Don' t fall out of the array bound.
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-06-27 17:52 --- Subject: Bug 40024 Author: ktietz Date: Sat Jun 27 17:52:29 2009 New Revision: 149016 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149016 Log: 2009-06-27 Kai Tietz kai.ti...@onevision.com Merged from trunk rev/148061 2009-06-01 Jakub Jelinek ja...@redhat.com PR other/40024 * emutls.c (__emutls_get_address): Change arr-size to mean number of allocated arr-data entries instead of # of slots + 1. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/emutls.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40024
[Bug other/40024] trunk/gcc-4.3/gcc: * emutls.c (emutls_destroy): Don' t fall out of the array bound.
--- Comment #7 from ktietz at gcc dot gnu dot org 2009-06-27 17:56 --- I did regression test for 4.3 and 4.4 branches and it was successful. I committed the patch for PR other/40024 to both branches. Committed revision 149015 for 4.3 branch and committed revision 149016 for 4.4 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40024
[Bug other/40024] trunk/gcc-4.3/gcc: * emutls.c (emutls_destroy): Don' t fall out of the array bound.
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-06-27 17:56 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail||4.3.3 4.4.0 Known to work||4.3.4 4.4.1 4.5.0 Resolution||FIXED Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40024
[Bug c/40570] New: ice in get_constraint_for_ptr_offset with -O3
I just tried to compile the Suse Linux package qemacs-0.3.1-381.2 with the G++ compiler version 4.5 snapshot 20090625. The compiler said css.c:819:24: warning: cast from pointer to integer of different size gcc: Internal error: Segmentation fault (program cc1) Please submit a full bug report. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source attached. Flag -O3 required. Here is valgrind helping out with a stack backtrace. ==19864== Invalid read of size 4 ==19864==at 0x8897FE: get_constraint_for_ptr_offset (tree-ssa-structalias.c:2877) ==19864==by 0x1006F: ??? ==19864==by 0x7FFF: ??? ==19864==by 0x87: ??? ==19864==by 0x645537F: ??? ==19864==by 0x7FEFFF92F: ??? ==19864==by 0x5F2C57F: ??? ==19864== Address 0x623b23c is 12 bytes inside a block of size 72 free'd ==19864==at 0x4C257E1: realloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==19864==by 0xC231CC: xrealloc (xmalloc.c:179) ==19864==by 0x9076D6: vec_heap_o_reserve_1 (vec.c:320) ==19864==by 0x889823: get_constraint_for_ptr_offset (tree-ssa-structalias.c:379) ==19864==by 0x1006F: ??? ==19864==by 0x7FFF: ??? ==19864==by 0x87: ??? ==19864==by 0x645537F: ??? ==19864==by 0x7FEFFF92F: ??? ==19864==by 0x5F2C57F: ??? -- Summary: ice in get_constraint_for_ptr_offset with -O3 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40570
[Bug c/40570] ice in get_constraint_for_ptr_offset with -O3
--- Comment #1 from dcb314 at hotmail dot com 2009-06-27 18:08 --- Created an attachment (id=18079) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18079action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40570
[Bug tree-optimization/40570] [4.5 Regression] ice in get_constraint_for_ptr_offset with -O3
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-06-27 18:38 --- Hm, for me it endlessly recurses #49 0x087e631e in cgraph_clone_inlined_nodes (e=0xb78db340, duplicate=0 '\0', update_original=1 '\001') at /home/richard/src/trunk/gcc/ipa-inline.c:261 261 cgraph_clone_inlined_nodes (e, duplicate, update_original); (gdb) #50 0x087e631e in cgraph_clone_inlined_nodes (e=0xb78e2980, duplicate=0 '\0', update_original=1 '\001') at /home/richard/src/trunk/gcc/ipa-inline.c:261 261 cgraph_clone_inlined_nodes (e, duplicate, update_original); (gdb) #51 0x087e631e in cgraph_clone_inlined_nodes (e=0xb78db340, duplicate=0 '\0', update_original=1 '\001') at /home/richard/src/trunk/gcc/ipa-inline.c:261 261 cgraph_clone_inlined_nodes (e, duplicate, update_original); (gdb) #52 0x087e631e in cgraph_clone_inlined_nodes (e=0xb78e2980, duplicate=0 '\0', update_original=1 '\001') at /home/richard/src/trunk/gcc/ipa-inline.c:261 261 cgraph_clone_inlined_nodes (e, duplicate, update_original); -O2 -fipa-cp-clone is enough to cause that. If you can reproduce the ICE in tree-ssa-structalias.c can you try to reduce it and/or debug it? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||mjambor at suse dot cz Component|c |tree-optimization Summary|ice in |[4.5 Regression] ice in |get_constraint_for_ptr_offse|get_constraint_for_ptr_offse |t with -O3 |t with -O3 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40570
[Bug tree-optimization/40570] [4.5 Regression] ice in get_constraint_for_ptr_offset with -O3
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-27 19:06 --- Created an attachment (id=18080) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18080action=view) reduced testcase slightly reduced testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40570
[Bug fortran/40571] New: F2008: ISO_FORTRAN_ENV: Missing constants
For the missing inquiry function, see PR 40569. Do not forget to update intrinsic.texi! Missing are the following integer arrays/scalars: CHARACTER_KINDS [ 1, 4 ] INTEGER_KINDS [ 1, 2, 4 ...] LOGICAL_KINDS [ 1, 2, 4, ...] REAL_KINDS [ 4, 8, ... ] IO_INQUIRE_INTERNAL_UNIT some positive number which cannot appear for any other error as value for IOSTAT= STAT_STOPPED_IMAGE positive, /= IO_INQUIRE_INTERNAL_UNIT Different from other STAT= values which appear for STAT= in ALLOCATE/DEALLOCATE and in SYNC ALL/IMAGES/MEMORY. -- Summary: F2008: ISO_FORTRAN_ENV: Missing constants Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40571
[Bug fortran/40569] F2008: Support COMPILER_OPTIONS() / COMPILER_VERSION()
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-27 19:44 --- Do not forget to update intrinsic.texi! For the missing constants in ISO_FORTRAN_ENV, see PR 40571 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40569
[Bug middle-end/40502] [4.5 Regression] crash in cp_diagnostic_starter
--- Comment #5 from reichelt at gcc dot gnu dot org 2009-06-27 20:07
---
Reduced testcase:
===
struct A
{
char x[12], y[35];
};
struct B
{
char z[50];
};
inline void foo(char* dest, const char* __restrict src, __SIZE_TYPE__ n)
{
__builtin___strncpy_chk (dest, src, n, 0);
}
void bar(const char*, int);
inline void baz(int i)
{
char s[128], t[32];
bar(s, 0);
bar(t, i);
A a;
B b;
foo(a.y, b.z, 36);
}
void quus()
{
baz(0);
}
===
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40502
[Bug debug/40012] [4.5 Regression] Revision 146817 generated bad debug info for local variables
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2009-06-27 20:18 --- This appears to still be broken in 32-bit mode. Yes, I've seen similar problems with 4.4.0 and 4.5.0 on x86. Probably the stack realignment stuff. I'd suggest opening a new PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40012
[Bug bootstrap/40572] New: gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS
I've tried my hardest to build gcc without resorting to the use of LD_LIBRARY_PATH. I simply can't understand why if LD_FLAGS is set to the path of the mpfr library, the compiler can't use them. My compile bombs out with the well known error: error: cannot compute suffix of object files: cannot compile after trying to build it for a couple of hours. A read of $BUILD_DIRECOTRYsparc-sun-solaris2.10/libgcc/config.log shows the real reason is that the compiler can't find the mpfr library. ld.so.1: cc1: fatal: libmpfr.so.1: open failed: No such file or directory But I've specified in three ways where to look for this library. 1) Use of -L 2) Use of -R 3) Use of the configure flag --with-mpfr= I've seen others report the same failure (cannot compute suffix of object files) - see for example http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35693 but it gets closed as 'invalid'. Given gcc finds the library during the initial configure stage, spends two hours compiling (making two copies of xgcc), then to bomb out since it can't find the library seems crazy. So I decided to set LD_LIBRARY_PATH (against my better judgement), but the build would not proceed. However, I expect it will if I set it first, then rebuild. Personally I think there are three things wrong here, that should be fixed, but do doubt the bug will be closed as invalid. 1) Don't expect people to use LD_LIBRARY_PATH 2) Check the location of the libraries in the configure script, so people don't waste two hours building, only to find the library is not found. 3) Respect the option --with-mpfr= 4) Respect LD_FLAGS I expect this will be closed as invalid, so you will still get people (especially on Solaris) finding this odd error. Clearly the configure script found the libraries in a way specified by the options - perhaps the compiler should not forget them a couple of hours later. I note a note by Brian Dessent on bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35693 (reported against 4.3), that the top level configure script should pick this up earlier, not when it comes to run state 1 xgcc for the first time. I can't actually understand why it wont even I will both config.log and sparc-sun-solaris2.10/libgcc/config.log in the hope someone might actually fix this bug, rather than dismiss it. -- Summary: gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: david dot kirkby at onetel dot net GCC build triplet: Sun T5240 Solaris 10 update 4 GCC host triplet: Sun T5240 Solaris 10 update 4 GCC target triplet: Sun T5240 Solaris 10 update 4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS
--- Comment #1 from david dot kirkby at onetel dot net 2009-06-27 20:25 --- Created an attachment (id=18081) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18081action=view) Top level config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS
--- Comment #2 from david dot kirkby at onetel dot net 2009-06-27 20:29 --- Created an attachment (id=18082) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18082action=view) sparc-sun-solaris2.10/libgcc/config.log This is the file, which shows it can't find the library, a couple of hours after the configure script finds it. VERY annoying. PLEASE PLEASE fix this. It hits a lot of people - I'm far from the only one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-27 20:35 --- What is the LDFLAGS supposed to do? Is it supposed to adjust the run-path of the built executables to find the mpfr/gmp libraries to not need LD_LIBRARY_PATH set? Note that setting LDFLAGS maybe not what you want (it affects stage1 only AFAIK), you likely want to set BOOT_LDFLAGS. $ ../gcc-4.4.0/configure CC=/usr/sfw/bin/gcc --prefix=/usr/local/gcc-4.4.0-Sun-linker-and-assembler-ABI32 --with-as=/usr/ccs/bin/as --without-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++,fortran --with-mpfr=/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32 --with-gmp=/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/ --with-libiconv-prefix=/usr/lib/iconv LDFLAGS=-R /usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib -L /usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS
--- Comment #4 from david dot kirkby at onetel dot net 2009-06-27 20:57 --- (In reply to comment #3) What is the LDFLAGS supposed to do? Is it supposed to adjust the run-path of the built executables to find the mpfr/gmp libraries to not need LD_LIBRARY_PATH set? Note that setting LDFLAGS maybe not what you want (it affects stage1 only AFAIK), you likely want to set BOOT_LDFLAGS. $ ../gcc-4.4.0/configure CC=/usr/sfw/bin/gcc --prefix=/usr/local/gcc-4.4.0-Sun-linker-and-assembler-ABI32 --with-as=/usr/ccs/bin/as --without-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++,fortran --with-mpfr=/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32 --with-gmp=/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/ --with-libiconv-prefix=/usr/lib/iconv LDFLAGS=-R /usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib -L /usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib LD_LIBRARY_PATH should be used as a last resort - not the first resort. But it is surely crazy for the configure script to look for the libraries and header files, then two hours later the build fails since the location of a library, which was previously check for, is now forgotten. Does that not seem a bit illogical? If I've specified the location of the library in a way the configure script accepts, AND specified -L option to the linker, why can't the linker find it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS
--- Comment #5 from david dot kirkby at onetel dot net 2009-06-27 21:00 --- (In reply to comment #3) Note that setting LDFLAGS maybe not what you want (it affects stage1 only AFAIK), you likely want to set BOOT_LDFLAGS. Sorry, forget to comment on that. I'll try that. I would have thought if one set a standard option to the linker like -R, it would have propagated, but I'll try that. It stills seems a bug to me though. This probably should be detected much earlier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-06-27 21:46 --- LD_LIBRARY_PATH is for the runtime linker/loader so it is needed as you are running programs which use shared libraries stored in a non standard place. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
[Bug debug/40573] New: [4.4/4.5 Regression] DWARF for inlined subroutines refers to the outlined copy
In the attached testcase (which will be added to the GDB testsuite), func1 is both emitted as a function and inlined into main and func2. The generated DWARF output looks like this with mainline: 11bf: Abbrev Number: 2 (DW_TAG_subprogram) 1c0 DW_AT_external: 1 1c1 DW_AT_name: (indirect string, offset: 0x11b): func1 1c5 DW_AT_decl_file : 1 1c6 DW_AT_decl_line : 22 1c7 DW_AT_prototyped : 1 1c8 DW_AT_type: 0x1e8 1cc DW_AT_inline : 3 (declared as inline and inlined) 1cd DW_AT_sibling : 0x1e8 21d1: Abbrev Number: 3 (DW_TAG_formal_parameter) 1d2 DW_AT_name: (indirect string, offset: 0x10c): arg1 1d6 DW_AT_decl_file : 1 1d7 DW_AT_decl_line : 22 1d8 DW_AT_type: 0x1e8 1202: Abbrev Number: 9 (DW_TAG_subprogram) 203 DW_AT_abstract_origin: 0x1bf 207 DW_AT_low_pc : 0x4004a0 20f DW_AT_high_pc : 0x4004e8 217 DW_AT_frame_base : 0x0 (location list) 21b DW_AT_sibling : 0x230 221f: Abbrev Number: 10 (DW_TAG_formal_parameter) 220 DW_AT_abstract_origin: 0x1d1 224 DW_AT_location: 1 byte block: 53(DW_OP_reg3) 2272: Abbrev Number: 12 (DW_TAG_inlined_subroutine) 273 DW_AT_abstract_origin: 0x1bf 277 DW_AT_entry_pc: 0x4004fa 27f DW_AT_ranges : 0x50 283 DW_AT_call_file : 1 284 DW_AT_call_line : 34 3285: Abbrev Number: 13 (DW_TAG_formal_parameter) 286 DW_AT_abstract_origin: 0x21f The problem is that the abstract origin of arg1 in the inlined copy (DIE at 0x285) refers to the outlined copy. But this is not in the abstract subtree referred to by the DIE at 0x272. Two things go wrong in consequence. GDB concludes that nothing in this subtree refers to the DIE at 0x1d1 and stitches that DIE into the tree, resulting in a second copy of arg1 (with no DW_AT_location). This could be worked around in GDB to compensate for the DWARF, but I'm convinced from the DWARF spec that the nesting is invalid. The other thing that goes wrong is even with the workaround, we try to use the DW_AT_location from the outlined copy. It works by chance in 4.5; in 4.4 a location list was used instead of a register, so of course the PC values in the location list do not apply. Honza, Richi suggested on IRC that this might be related to your changes in inline variable tracking. Any idea? -- Summary: [4.4/4.5 Regression] DWARF for inlined subroutines refers to the outlined copy Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drow at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40573
[Bug debug/40573] [4.4/4.5 Regression] DWARF for inlined subroutines refers to the outlined copy
--- Comment #1 from drow at gcc dot gnu dot org 2009-06-27 22:12 --- Created an attachment (id=18083) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18083action=view) Test case Compile with -O2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40573
[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS
--- Comment #7 from david dot kirkby at onetel dot net 2009-06-27 22:31 --- (In reply to comment #6) LD_LIBRARY_PATH is for the runtime linker/loader so it is needed as you are running programs which use shared libraries stored in a non standard place. So is any user who uses the compiler going to need to set LD_LIBRARY_PATH ? That would seem crazy if that is true. I don't need to set LD_LIBRARY_PATH on my Sun to use the gcc from Blastwave, which resides in /opt/csw/bin/gcc or the one which Sun ship which resides in /usr/sfw/bin. It is impossible for me to create a gcc-4.4.0 which links to libraries in locations I chose, without users having to set LD_LIBRARY_PATH? It is not possible to specify the locations of the libraries? I thought options like: --with-mpfr-lib=PATHspecify directory for the installed MPFR library were supposed to override the default /usr/local/lib. In some ways, an option like --ignore-usr-local would be nice on LOTS of programs. The trouble with the 'standard' /usr/local is that it tends to accumulate a lot of rubbish. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS
--- Comment #8 from david dot kirkby at onetel dot net 2009-06-27 22:57 --- It looks as though we will have to agree to differ about the LD_LIBRARY_PATH being the right way to do things. But do you not agree that this probably should be found at an earlier stage in the build process? If so, could you at least fix that, so other people don't want so much time over this problem. If you Google for it, you will find there are thousands of references to this. -- david dot kirkby at onetel dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS
--- Comment #9 from pinskia at gcc dot gnu dot org 2009-06-27 23:39 --- This is just like building any other program and running the result if you link with a library stored somewhere else. /usr/local/lib not being standard is up to your distro really, it is a standard location according to GCC and should be according to everything else, if it is not then it is a bug with your distro or the runtime loader/linker. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-06-27 23:39 --- It is semi hard to figure out early on really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
[Bug middle-end/40554] [4.5 Regression] Revision 148941 miscompiled 447.dealII in SPEC CPU 2006
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-06-27 23:41 ---
I believe the following (but yet untested) patch fixes this issue.
I will bootstrap and test it once I have a testcase that is simple
enough to be put into the testsuite. I hope to do all of this on
Monday.
Index: mine/gcc/tree-sra.c
===
--- mine.orig/gcc/tree-sra.c2009-06-28 00:58:23.0 +0200
+++ mine/gcc/tree-sra.c 2009-06-28 01:00:34.0 +0200
@@ -1908,7 +1908,8 @@ sra_modify_expr (tree *expr, gimple_stmt
host_integerp (TREE_OPERAND (bfr, 2), 1))
{
chunk_size = tree_low_cst (TREE_OPERAND (bfr, 1), 1);
- start_offset = tree_low_cst (TREE_OPERAND (bfr, 2), 1);
+ start_offset = access-offset
+ + tree_low_cst (TREE_OPERAND (bfr, 2), 1);
}
else
start_offset = chunk_size = 0;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40554
[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS
--- Comment #11 from david dot kirkby at onetel dot net 2009-06-28 03:51
---
(In reply to comment #3)
Note that setting LDFLAGS maybe not what you want (it affects stage1 only
AFAIK), you likely want to set BOOT_LDFLAGS.
FWIW, BOOT_LDFLAGS. that did not solve it either. I think I'll have a go with
'sed' and change /usr/local to somewhere else in the gcc-4.4.0.tar file.
Hopefully that will avoid the need for setting LD library path.
It would be good if the /usr/local thing could be overridden, but sed might
come to my rescuse!
../gcc-4.4.0/configure 'CC=/usr/sfw/bin/gcc' \
--prefix=/usr/local/gcc-4.4.0-Sun-linker-and-assembler-ABI32 \
--without-gnu-as \
--without-gnu-ld \
--with-as=/usr/ccs/bin/as \
--with-ld=/usr/ccs/bin/ld \
--enable-languages=c,c++,fortran \
--with-mpfr=/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32 \
--with-gmp=/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32 \
--with-libiconv-prefix=/usr/lib/iconv \
BOOT_LDFLAGS='-R
/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib
-L
/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib'
\
LDFLAGS='-R
/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib
-L
/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib'
It later failed with
-DHAVE_CONFIG_H -I. -I. -I../../gcc-4.4.0/gcc -I../../gcc-4.4.0/gcc/.
-I../../gcc-4.4.0/gcc/../include -I./../intl
-I../../gcc-4.4.0/gcc/../libcpp/include
-I/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/include
-I/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/include
-I../../gcc-4.4.0/gcc/../libdecnumber -I../../gcc-4.4.0/gcc/../libdecnumber/dpd
-I../libdecnumber\
-DSTANDARD_STARTFILE_PREFIX=\../../../\
-DSTANDARD_EXEC_PREFIX=\/usr/local/gcc-4.4.0-Sun-linker-and-assembler-ABI32/lib/gcc/\
-DSTANDARD_LIBEXEC_PREFIX=\/usr/local/gcc-4.4.0-Sun-linker-and-assembler-ABI32/libexec/gcc/\
-DDEFAULT_TARGET_VERSION=\4.4.0\
-DDEFAULT_TARGET_MACHINE=\sparc-sun-solaris2.10\
-DSTANDARD_BINDIR_PREFIX=\/usr/local/gcc-4.4.0-Sun-linker-and-assembler-ABI32/bin/\
-DTOOLDIR_BASE_PREFIX=\../../../../\ `test X${SHLIB_LINK} = X || test
yes != yes || echo -DENABLE_SHARED_LIBGCC` \
-c ../../gcc-4.4.0/gcc/gcc.c -o gcc.o)
In file included from ../../gcc-4.4.0/gcc/gcc.c:73:
./multilib.h:21: error: expected '=', ',', ';', 'asm' or '__attribute__' before
':' token
gmake[3]: *** [gcc.o] Error 1
gmake[3]: Leaving directory
`/home/kirkby/gcc-4.4.0-built-with-gcc-3.4.3-ABI32/gcc'
gmake[2]: *** [all-stage2-gcc] Error 2
gmake[2]: Leaving directory `/home/kirkby/gcc-4.4.0-built-with-gcc-3.4.3-ABI32'
gmake[1]: *** [stage2-bubble] Error 2
gmake[1]: Leaving directory `/home/kirkby/gcc-4.4.0-built-with-gcc-3.4.3-ABI32'
gmake: *** [all] Error 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
