[Bug bootstrap/56311] gcc/include-fixed/stdio.h: In function ‘_func’: gcc/include-fixed/stdio.h:135:3: error: expected declaration specifiers before ‘__extension__’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56311 devurandom at gmx dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #6 from devurandom at gmx dot net --- I currently have no need for a Windows cross-compiler. The patch is attached here, should anyone need it -- assuming the issue still exists and the patch still works.
[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465 --- Comment #6 from devurandom at gmx dot net --- Did anyone figure out what's going on? Did the gdb log bring new insights?
[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465 --- Comment #8 from devurandom at gmx dot net --- (In reply to Mike Frysinger from comment #7) it's beyond my (ia64 beginners) experience to track this down further i can certainly make available ssh access to interested devs ... it's a fast system on a fast edu connection Similar situation and offer from me: Slow system on a fast connection available for the dev who wants to track this down, but lacks an own machine.
[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
devurandom at gmx dot net changed:
What|Removed |Added
Target||ia64-unknown-linux-gnu
Known to work||4.7.3
Host||ia64-unknown-linux-gnu
Known to fail||4.8.2
Build||ia64-unknown-linux-gnu
--- Comment #3 from devurandom at gmx dot net ---
Mike Frysinger 2014-03-18 07:17:05 UTC
if you build current master glibc w/gcc-4.8.2 binutils-2.23.2 like so:
../configure --prefix=/usr libc_cv_ehdr_start=no
make -j4
then try to run a simple app like so:
echo 'main(){puts(HI);}' | gcc -x c - -o a.out
./elf/ld.so --library-path $PWD ./a.out
it crashes like so:
Segmentation fault (core dumped)
i suspect bad code generation because:
- recompiling only elf/rtld.c w/gcc-4.7.3 produces a working build
- the C code looks correct (via poking; see below)
- tweaking the code slightly produces a working build w/4.8:
- else if ((d_tag_utype) DT_ADDRTAGIDX (dyn-d_tag) DT_ADDRNUM)
-info[DT_ADDRTAGIDX (dyn-d_tag) + DT_NUM + DT_THISPROCNUM
- + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM] = dyn;
+{
+ size_t i = DT_ADDRTAGIDX (dyn-d_tag) + DT_NUM + DT_THISPROCNUM
+ + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM;
+ info[i] = dyn;
+}
throwing it into a debugger shows:
$ gdb --args ./elf/ld.so --library-path $PWD ./a.out
Reading symbols from /home/vapier/glibc/build/elf/ld.so...done.
(gdb) run
Starting program: /home/vapier/glibc/build/./elf/ld.so --library-path
/home/vapier/glibc/build ./a.out
Program received signal SIGSEGV, Segmentation fault.
0x2008b010 in elf_get_dynamic_info (temp=0x0, l=0x200800051b08
_rtld_local+2456) at get-dynamic-info.h:61
61 + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM] = dyn;
(gdb) list
56else if ((d_tag_utype) DT_VALTAGIDX (dyn-d_tag) DT_VALNUM)
57 info[DT_VALTAGIDX (dyn-d_tag) + DT_NUM + DT_THISPROCNUM
58 + DT_VERSIONTAGNUM + DT_EXTRANUM] = dyn;
59else if ((d_tag_utype) DT_ADDRTAGIDX (dyn-d_tag) DT_ADDRNUM)
60 info[DT_ADDRTAGIDX (dyn-d_tag) + DT_NUM + DT_THISPROCNUM
61 + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM] = dyn;
62++dyn;
63 }
64
65 #define DL_RO_DYN_TEMP_CNT 8
the info pointer is sane:
(gdb) p _rtld_global._dl_rtld_map.l_info
$1 = (Elf64_Dyn *(*)[77]) 0x2008000515d8 _rtld_local+2520
(gdb) print info
$2 = (Elf64_Dyn **) 0x2008000515d8 _rtld_local+2520
as is the dyn tag:
(gdb) print dyn
$3 = (Elf64_Dyn *) 0x20080004c8d8
(gdb) print *dyn
$4 = {
d_tag = 0x6ef5,
d_un = {
d_val = 0x2d8,
d_ptr = 0x2d8
}
}
that calculated offset is 0x4c and the link map is big enough to hold it:
(gdb) print sizeof(_rtld_local._dl_rtld_map.l_info) /
sizeof(_rtld_local._dl_rtld_map.l_info[0])
$5 = 0x4d
but the assembly is clearly wrong:
(gdb) display/i $pc
1: x/i $pc
= 0x2008b271 _dl_start+2737: (p07) st8 [r14]=r15
(gdb) p $r15
$6 = 0x20080004c8d8
(gdb) p $r14
$7 = 0x51838
$r15 is set to the right value (dyn), but r14 is now incomplete. stepping
through the previous ~20 insns shows that the right value doesn't get near $r14
... but my ia64 asm skills are not great, so i could be missing something.
[Bug other/60465] New: Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
Bug ID: 60465
Summary: Compiling glibc-2.17,2.18 with gcc-4.8.2 and
binutils-2.23.2,2.24 results in segfaults in _start /
elf_get_dynamic_info
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: devurandom at gmx dot net
Created attachment 32309
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32309action=edit
backtrace (glibc-2.18,binutils-2.24,gcc-4.8.2)
I tried to build glibc-2.17 and 2.18 with binutils-2.23.2 or 2.24 and
gcc-4.8.2, but always run into the same segfault when loading programs with the
new runtime linker.
Please find a backtrace for the glibc-2.18, binutils-2.24, gcc-4.8.2
combination attached.
It crashes in exactly the same way when running without --library-path and when
running with ../usr/bin/locale (from glibc-2.18) or /bin/date as argument.
Since glibc-2.17 compiled fine with gcc-4.7.3, I assume that gcc-4.8.2 is to
blame.
The context of the crash is (according to glibc-2.18/elf/get-dynamic-info.h):
elf_get_dynamic_info (struct link_map *l, ElfW(Dyn) *temp) {
ElfW(Dyn) **info;
info = l-l_info;
info[DT_ADDRTAGIDX (dyn-d_tag) + DT_NUM + DT_THISPROCNUM + DT_VERSIONTAGNUM
+ DT_EXTRANUM + DT_VALNUM] = dyn;
}
GDB reports this function being called as:
elf_get_dynamic_info (temp=0x0, l=0x200800051458 _rtld_local+2456)
What I find to be suspicious is the changed order of parameters.
I would like to check this with valgrind, too, but it is not available on ia64
(i.e. anything but x86, ppc and arm).
See-Also: https://bugs.gentoo.org/show_bug.cgi?id=503838
[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465 --- Comment #1 from devurandom at gmx dot net --- Created attachment 32310 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32310action=edit emerge --info
[Bug plugins/41757] Add PLUGIN_FINISH_DECL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41757 devurandom at gmx dot net changed: What|Removed |Added CC||devurandom at gmx dot net --- Comment #6 from devurandom at gmx dot net --- (In reply to PaX Team from comment #5) this feature seems to have been implemented already in gcc 4.7.x, can it be backported to 4.5.x and 4.6.x perhaps? I would like to see that happen, too. E.g. gcc-lua-cdecl and Gentoo's hardened-sources would benefit from this.
[Bug libstdc++/56332] libstdc++-v3 does not support x86_64-pc-mingw64: No support for this host/target combination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56332 --- Comment #6 from devurandom at gmx dot net 2013-02-16 13:15:27 UTC --- Ok... I assumed that in the cpu-vendor-os triplet the os part contains the reference to the c library and/or kernel, while vendor refers to the distribution that packaged the compiler (or is often just pc for i386). Apparently this was completely wrong. I'll ask the Gentoo maintainers to rename the package to something that is not plain wrong.
[Bug libstdc++/56332] libstdc++-v3 does not support x86_64-pc-mingw64: No support for this host/target combination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56332 --- Comment #7 from devurandom at gmx dot net 2013-02-16 13:20:49 UTC --- P.S: Is relaxing the match to accept mingw*, because the library and compiler are called mingw(-w64), an option? That shouldn't hurt anyone and not make anything more complicated either.
[Bug libstdc++/56332] libstdc++-v3 does not support x86_64-pc-mingw64: No support for this host/target combination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56332 --- Comment #3 from devurandom at gmx dot net 2013-02-15 10:37:58 UTC --- (In reply to comment #2) For mingw-w64 isn't the triplet supposed to be 'x86_64-w64-mingw32'? Or has the 'old mingw' now grown its own 64-bit support? That would be quite confusing, because the 32-bit target seems to be named i386-pc-mingw32 and not i386-w32-mingw32. IMO w64-mingw32 also looks ridiculous, but that is just my opinion. And also the package is named mingw64-runtime in Gentoo. On the other hand the project itself seems to be named mingw-w64 - which just makes w64-mingw32 look more wrong.
[Bug bootstrap/56311] gcc/include-fixed/stdio.h: In function ‘_func’: gcc/include-fixed/stdio.h:135:3: error: expected declaration specifiers before ‘__extension__’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56311 --- Comment #2 from devurandom at gmx dot net 2013-02-14 10:44:25 UTC --- P.S: I am willing to debug this further on my own, but I need some help. My first guess is that the files in include-fixed are system headers, which are somehow mangled with sed or a similar tool. Where does that happen and with what intend?
[Bug bootstrap/56311] gcc/include-fixed/stdio.h: In function ‘_func’: gcc/include-fixed/stdio.h:135:3: error: expected declaration specifiers before ‘__extension__’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56311 --- Comment #4 from devurandom at gmx dot net 2013-02-14 19:45:33 UTC --- Created attachment 29454 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29454 gcc-4.7.2-inclhack-hpux10_stdio_declarations.patch Attached patch fixes the issue for me. Someone with a HP-UX 10 system should probably test it, though! I added an $ anchor to the end of the match, to exclude the __iob_func() line that MinGW seems to use. If there is anything (e.g. a comment) after __iob on HP-UX 10, this will obviously fail! (But then it might have created bad code before, too.)
[Bug libstdc++/56332] New: libstdc++-v3 does not support x86_64-pc-mingw64: No support for this host/target combination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56332 Bug #: 56332 Summary: libstdc++-v3 does not support x86_64-pc-mingw64: No support for this host/target combination Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: devuran...@gmx.net Created attachment 29458 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29458 gcc-4.7.2-libstdc++-v3-crossconfig-support-mingw64.patch When trying to configure libstdc++-v3 for a x86_64-pc-mingw64 crosscompiler (on a x86_64-pc-linux-gnu system), I get an error: No support for this host/target combination Attached patches fix that by adjusting configure to accept mingw64 as an alternative to mingw32.
[Bug libstdc++/56332] libstdc++-v3 does not support x86_64-pc-mingw64: No support for this host/target combination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56332 --- Comment #1 from devurandom at gmx dot net 2013-02-14 22:30:16 UTC --- Created attachment 29459 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29459 gcc-4.7.2-libstdc++-v3-os_include_dir-and-error_constants_dir-for-mingw64.patch
[Bug bootstrap/56311] New: gcc/include-fixed/stdio.h: In function ‘_func’: gcc/include-fixed/stdio.h:135:3: error: expected declaration specifiers before ‘__extension__’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56311 Bug #: 56311 Summary: gcc/include-fixed/stdio.h: In function ‘_func’: gcc/include-fixed/stdio.h:135:3: error: expected declaration specifiers before ‘__extension__’ Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: devuran...@gmx.net Created attachment 29445 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29445 stdio.h I am building a crosscompiler for x86_64-pc-mingw64 on Gentoo/Linux and get the following error during build: In file included from /var/tmp/portage/cross-x86_64-pc-mingw64/gcc-4.7.2/work/gcc-4.7.2/libgcc/../gcc/tsystem.h:88:0, from /var/tmp/portage/cross-x86_64-pc-mingw64/gcc-4.7.2/work/gcc-4.7.2/libgcc/libgcc2.c:29: /var/tmp/portage/cross-x86_64-pc-mingw64/gcc-4.7.2/work/build/./gcc/include-fixed/stdio.h: In function ‘_func’: /var/tmp/portage/cross-x86_64-pc-mingw64/gcc-4.7.2/work/build/./gcc/include-fixed/stdio.h:135:3: error: expected declaration specifiers before ‘__extension__’ /var/tmp/portage/cross-x86_64-pc-mingw64/gcc-4.7.2/work/build/./gcc/include-fixed/stdio.h:173:15: error: storage class specified for parameter ‘__mingw_sscanf’ /var/tmp/portage/cross-x86_64-pc-mingw64/gcc-4.7.2/work/build/./gcc/include-fixed/stdio.h:176:15: error: storage class specified for parameter ‘__mingw_vsscanf’ /var/tmp/portage/cross-x86_64-pc-mingw64/gcc-4.7.2/work/build/./gcc/include-fixed/stdio.h:179:15: error: storage class specified for parameter ‘__mingw_scanf’ /var/tmp/portage/cross-x86_64-pc-mingw64/gcc-4.7.2/work/build/./gcc/include-fixed/stdio.h:182:15: error: storage class specified for parameter ‘__mingw_vscanf’ /var/tmp/portage/cross-x86_64-pc-mingw64/gcc-4.7.2/work/build/./gcc/include-fixed/stdio.h:185:15: error: storage class specified for parameter ‘__mingw_fscanf’ /var/tmp/portage/cross-x86_64-pc-mingw64/gcc-4.7.2/work/build/./gcc/include-fixed/stdio.h:188:15: error: storage class specified for parameter ‘__mingw_vfscanf’ /var/tmp/portage/cross-x86_64-pc-mingw64/gcc-4.7.2/work/build/./gcc/include-fixed/stdio.h:192:15: error: storage class specified for parameter ‘__mingw_vsnprintf’ /var/tmp/portage/cross-x86_64-pc-mingw64/gcc-4.7.2/work/build/./gcc/include-fixed/stdio.h:196:15: error: storage class specified for parameter ‘__mingw_snprintf’ /var/tmp/portage/cross-x86_64-pc-mingw64/gcc-4.7.2/work/build/./gcc/include-fixed/stdio.h:199:15: error: storage class specified for parameter ‘__mingw_printf’ /var/tmp/portage/cross-x86_64-pc-mingw64/gcc-4.7.2/work/build/./gcc/include-fixed/stdio.h:202:15: error: storage class specified for parameter ‘__mingw_vprintf’ /var/tmp/portage/cross-x86_64-pc-mingw64/gcc-4.7.2/work/build/./gcc/include-fixed/stdio.h:205:15: error: storage class specified for parameter ‘__mingw_fprintf’ /var/tmp/portage/cross-x86_64-pc-mingw64/gcc-4.7.2/work/build/./gcc/include-fixed/stdio.h:208:15: error: storage class specified for parameter ‘__mingw_vfprintf’ /var/tmp/portage/cross-x86_64-pc-mingw64/gcc-4.7.2/work/build/./gcc/include-fixed/stdio.h:211:15: error: storage class specified for parameter ‘__mingw_sprintf’ /var/tmp/portage/cross-x86_64-pc-mingw64/gcc-4.7.2/work/build/./gcc/include-fixed/stdio.h:214:15: error: storage class specified for parameter ‘__mingw_vsprintf’ /var/tmp/portage/cross-x86_64-pc-mingw64/gcc-4.7.2/work/build/./gcc/include-fixed/stdio.h:217:15: error: storage class specified for parameter ‘__mingw_asprintf’ /var/tmp/portage/cross-x86_64-pc-mingw64/gcc-4.7.2/work/build/./gcc/include-fixed/stdio.h:220:15: error: storage class specified for parameter ‘__mingw_vasprintf’ The code that seems to lead to this problem appears to be around line 96: #ifndef _STDIO_DEFINED #ifdef _WIN64 [...] _func() #else #ifdef _MSVCRT_ [...] #else [...] _func() #endif #endif #endif Apparently GCC somehow destroyed the file during its bootstrap process.
[Bug bootstrap/56311] gcc/include-fixed/stdio.h: In function ‘_func’: gcc/include-fixed/stdio.h:135:3: error: expected declaration specifiers before ‘__extension__’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56311 --- Comment #1 from devurandom at gmx dot net 2013-02-13 22:31:03 UTC --- Created attachment 29446 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29446 cross-x86_64-pc-mingw64-gcc-stage1.log.xz
[Bug bootstrap/55886] gcc/configure.ac problems lead to GCC 4.7.2 not building for x86_64-pc-mingw64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55886 --- Comment #1 from devurandom at gmx dot net 2013-02-13 22:33:33 UTC --- Created attachment 29447 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29447 gcc-4.7.2-define-have_gas_aligned_comm.patch (In reply to comment #0) case $target_os in 3604: cygwin* | pe | mingw32* | interix*) # Recent binutils allows the three-operand form of .comm on PE. This [...] At least the last one (gcc/configure.ac:3604) is wrong and leads to HAVE_GAS_ALIGNED_COMM being undefined for mingw64, which makes gcc/options.c (autogenerated file) fail to compile: options.c:952:3: error: ‘HAVE_GAS_ALIGNED_COMM’ undeclared here (not in a function) Attached patch fixes this error. However, I ran into further problems (bug #56311), so it might have other side-effects.
[Bug bootstrap/55886] New: gcc/configure.ac problems lead to GCC 4.7.2 not building for x86_64-pc-mingw64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55886 Bug #: 55886 Summary: gcc/configure.ac problems lead to GCC 4.7.2 not building for x86_64-pc-mingw64 Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: devuran...@gmx.net gcc/configure.ac contains several checks for mingw hosts, which are tied to mingw32 instead of generic mingw. This might lead to problems when crosscompiling a x86_64-pc-mingw64 compiler. Possibly problematic lines in gcc-4.7.2/gcc/configure.ac: case $host in 1453: *-*-mingw32*) use_cxa_atexit=yes case $host_os in 1656: win32 | pe | cygwin* | mingw32* | uwin*) if test x$enable_win32_registry != xno; then [case $target_os in 2565: win32 | pe | cygwin* | mingw32* | uwin*) # Need to check that we generated the correct relocation for the case $target_os in 3604: cygwin* | pe | mingw32* | interix*) # Recent binutils allows the three-operand form of .comm on PE. This They should probably use mingw* instead of mingw32*. At least the last one (gcc/configure.ac:3604) is wrong and leads to HAVE_GAS_ALIGNED_COMM being undefined for mingw64, which makes gcc/options.c (autogenerated file) fail to compile: options.c:952:3: error: ‘HAVE_GAS_ALIGNED_COMM’ undeclared here (not in a function) See also: https://bugs.gentoo.org/show_bug.cgi?id=447708
[Bug other/54956] New: GCC 4.7.2: internal compiler error: in emit_move_insn, at expr.c:3435
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54956 Bug #: 54956 Summary: GCC 4.7.2: internal compiler error: in emit_move_insn, at expr.c:3435 Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: devuran...@gmx.net When configuring libstdc++v3 for CHOST/CTARGET=spu-elf: configure:15317: checking for atomic builtins for bool configure:15319: /var/tmp/portage/cross-spu-elf/gcc-4.7.2/work/build/./gcc/xgcc -shared-libgcc -B/var/tmp/portage/cross-spu-elf/gcc-4.7.2/work/b uild/./gcc -nostdinc++ -L/var/tmp/portage/cross-spu-elf/gcc-4.7.2/work/build/spu-elf/libstdc++-v3/src -L/var/tmp/portage/cross-spu-elf/gcc-4.7.2/ work/build/spu-elf/libstdc++-v3/src/.libs -B/usr/spu-elf/bin/ -B/usr/spu-elf/lib/ -isystem /usr/spu-elf/include -isystem /usr/spu-elf/sys-include -c -O0 -S conftest.cpp 5 configure: In function 'int main()': configure:15309:47: internal compiler error: in emit_move_insn, at expr.c:3435 Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.gentoo.org/ for instructions. configure:15322: $? = 1 configure:15330: result: Code as found in gcc-4.7.2/libstdc++-v3/acinclude.m4: typedef bool atomic_type; atomic_type c1; atomic_type c2; atomic_type c3(0); __atomic_fetch_add(c1, c2, __ATOMIC_RELAXED); __atomic_compare_exchange_n(c1, c2, c3, true, __ATOMIC_ACQ_REL, __ATOMIC_RELAXED); __atomic_test_and_set(c1, __ATOMIC_RELAXED); __atomic_load_n(c1, __ATOMIC_RELAXED); Portage 2.2.0_alpha138 (default/linux/amd64/10.0, gcc-4.7.2, glibc-2.15-r2, 2.6.18-308.16.1.el5 x86_64) = System uname: Linux-2.6.18-308.16.1.el5-x86_64-Quad-Core_AMD_Opteron-tm-_Processor_2352-with-gentoo-2.1 Timestamp of tree: Tue, 16 Oct 2012 21:45:01 + distcc 3.1 x86_64-pc-linux-gnu [disabled] app-shells/bash: 4.2_p37 dev-lang/python: 2.7.3-r2, 3.2.3::ambro-cross sys-apps/baselayout: 2.1-r1 sys-apps/openrc: 0.9.8.4 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.68 sys-devel/automake: 1.11.6 sys-devel/binutils: 2.22-r1 sys-devel/gcc:4.7.2 sys-devel/gcc-config: 1.7.3 sys-devel/libtool:2.4-r1 sys-devel/make: 3.82-r3 sys-kernel/linux-headers: 3.4-r2 (virtual/os-headers) sys-libs/glibc: 2.15-r2 Repositories: gentoo ambro-cross local sunrise ACCEPT_KEYWORDS=amd64 ACCEPT_LICENSE=* -@EULA CBUILD=x86_64-pc-linux-gnu CFLAGS=-pipe -O2 -march=opteron-sse3 CHOST=x86_64-pc-linux-gnu CONFIG_PROTECT=/etc CONFIG_PROTECT_MASK=/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo CXXFLAGS=-pipe -O2 -march=opteron-sse3 DISTDIR=/var/cache/portage/distfiles EMERGE_DEFAULT_OPTS=--usepkg --binpkg-respect-use --keep-going FCFLAGS=-O2 -pipe FEATURES=assume-digests binpkg-logs buildpkg config-protect-if-modified distlocks ebuild-locks fixlafiles news parallel-fetch parallel-install p reserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync FFLAGS=-O2 -pipe GENTOO_MIRRORS=http://ftp.spline.inf.fu-berlin.de/mirrors/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://distfiles.gentoo.o rg LDFLAGS=-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu PKGDIR=/var/cache/portage/packages PORTAGE_COMPRESS=xz PORTAGE_CONFIGROOT=/ PORTAGE_RSYNC_OPTS=--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout= 180 --exclude=/distfiles --exclude=/local --exclude=/packages PORTAGE_TMPDIR=/var/tmp PORTDIR=/var/cache/portage/gentoo PORTDIR_OVERLAY=/var/lib/layman/ambro-cross /var/cache/portage/local /var/cache/portage/overlays/sunrise [...] Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LANG, LC_ALL, LINGUAS, MAKEOPTS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OP TS, USE_PYTHON
[Bug target/43603] gcc-4.4.3 ICE on ia64 with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43603 --- Comment #26 from devurandom at gmx dot net 2011-06-20 12:09:26 UTC --- Thanks a lot!
[Bug target/43603] gcc-4.4.3 ICE on ia64 with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43603 --- Comment #22 from devurandom at gmx dot net 2011-06-17 11:21:02 UTC --- (In reply to comment #20) Created attachment 24112 [details] backported patch Good. Then attached is the initial backport, I have just verified that it passes the testcase. It would be great if the Gentoo folks could test it in their setup, too. If all goes well, I will apply it to 4_4-branch at the beginning of May. Is this applied to any branch yet?
[Bug target/43603] gcc-4.4.3 ICE on ia64 with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43603 --- Comment #23 from devurandom at gmx dot net 2011-06-17 14:04:50 UTC --- (In reply to comment #22) (In reply to comment #20) Created attachment 24112 [details] backported patch Good. Then attached is the initial backport, I have just verified that it passes the testcase. It would be great if the Gentoo folks could test it in their setup, too. If all goes well, I will apply it to 4_4-branch at the beginning of May. Is this applied to any branch yet? Confirming that the attached patch allows compilation of Erlang 14B03 when applied to GCC 4.4.5.
[Bug target/43603] gcc-4.4.3 ICE on ia64 with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43603 --- Comment #15 from devurandom at gmx dot net 2011-04-27 07:45:19 UTC --- (In reply to comment #14) (In reply to comment #13) Fixed on 4.5. Can it please be fixed in 4.4, too? (Maybe I am wrong, but I see only commits to trunk/4.6 and 4.5 here.)
[Bug target/43603] gcc-4.4.3 ICE on ia64 with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43603 --- Comment #18 from devurandom at gmx dot net 2011-04-27 08:26:51 UTC --- P.S: Maybe you can backport it anyway, since I opened Gentoo bug #365045 [1]. Having the backport readily available from upstream would probably help including it in a distro release of GCC. [1] http://bugs.gentoo.org/show_bug.cgi?id=365045
[Bug target/43603] gcc-4.4.3 ICE on ia64 with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43603 --- Comment #17 from devurandom at gmx dot net 2011-04-27 08:25:13 UTC --- This bug prevents Erlang 14B2 from building on my machine, so for me it is serious. Someone else has to tell whether there will be further 4.4 releases, of course.
[Bug target/43603] gcc-4.4.3 ICE on ia64 with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43603 --- Comment #21 from devurandom at gmx dot net 2011-04-27 10:56:18 UTC --- (In reply to comment #20) Created attachment 24112 [details] backported patch Thanks! I notified downstream, hopefully they will give it testing through a bump to gcc-4.4.[56].
[Bug target/43603] gcc-4.4.3 ICE on ia64 with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43603 --- Comment #14 from devurandom at gmx dot net 2011-04-13 08:05:35 UTC --- (In reply to comment #13) Fixed on 4.5. Will 4.4 also be fixed? A release candidate for 4.4.6 was just released, so it should probably happen quickly.
[Bug rtl-optimization/43653] ICE: in reload, at reload1.c:1188 with -O1 -ftree-vectorize and empty struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43653 --- Comment #4 from devurandom at gmx dot net 2011-01-03 18:24:15 UTC --- (In reply to comment #3) 4.5.1 shows the same issue when building Clang 2.8. Persists with 4.5.2.
[Bug rtl-optimization/43653] ICE: in reload, at reload1.c:1188 with -O1 -ftree-vectorize and empty struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43653 --- Comment #3 from devurandom at gmx dot net 2010-12-25 23:43:13 UTC --- 4.5.1 shows the same issue when building Clang 2.8.
[Bug lto/43659] -flto doesn't remember -fPIC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43659 devurandom at gmx dot net changed: What|Removed |Added CC||devurandom at gmx dot net --- Comment #3 from devurandom at gmx dot net 2010-11-30 10:05:17 UTC --- The issue seems to still exist in 4.5.1. Does it have something to do with bug #40546? On Gentoo, at least following packages are affected: app-arch/bzip2-1.0.6-r1, dev-libs/libebml-1.0.0, media-libs/jpeg-6b-r9, media-libs/openjpeg-1.3-r3, media-sound/gsm-1.0.13, net-libs/libsrtp-1.4.4-r1
[Bug lto/46616] New: ia64: When compiling gcc with lto support: collect2: ld returned 1 exit status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46616 Summary: ia64: When compiling gcc with lto support: collect2: ld returned 1 exit status Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: devuran...@gmx.net Created attachment 22493 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22493 build.log I am on Gentoo and am compiling GCC with LTO support. When compiling/linking cc1plus-dummy or lto1, ld will reproducibly return exit status 1. Compiling GCC without LTO support (USE=-lto) works fine. The full output is attached. The last lines are: /var/tmp/portage/sys-devel/gcc-4.5.1-r1/work/build/./prev-gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-4.5.1-r1/work/build/./prev-gcc/ -B/usr/ia64-unknown-linux-gnu/bin/ -B/usr/ia64-unknown-linux-gnu/bin/ -B/usr/ia64-unknown-linux-gnu/lib/ -isystem /usr/ia64-unknown-linux-gnu/include -isystem /usr/ia64-unknown-linux-gnu/sys-include-DEFAULT_PIE -DEFAULT_RELRO -DEFAULT_BIND_NOW -DUSE_LIBUNWIND_EXCEPTIONS -pipe -mtune=mckinley -O2 -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -o cc1plus-dummy \ cp/cp-lang.o stub-objc.o cp/call.o cp/decl.o cp/expr.o cp/pt.o cp/typeck2.o cp/class.o cp/decl2.o cp/error.o cp/lex.o cp/parser.o cp/ptree.o cp/rtti.o cp/typeck.o cp/cvt.o cp/except.o cp/friend.o cp/init.o cp/method.o cp/search.o cp/semantics.o cp/tree.o cp/repo.o cp/dump.o cp/optimize.o cp/mangle.o cp/cp-objcp-common.o cp/name-lookup.o cp/cxx-pretty-print.o cp/cp-gimplify.o tree-mudflap.o attribs.o c-common.o c-format.o c-pragma.o c-semantics.o c-lex.o c-dump.o c-pretty-print.o c-opts.o c-pch.o incpath.o c-ppoutput.o c-cppbuiltin.o prefix.o c-gimplify.o c-omp.o dummy-checksum.o main.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lmpc -lmpfr -lgmp -ldl -rdynamic -ldl -lz -lelf /var/tmp/portage/sys-devel/gcc-4.5.1-r1/work/build/./prev-gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-4.5.1-r1/work/build/./prev-gcc/ -B/usr/ia64-unknown-linux-gnu/bin/ -B/usr/ia64-unknown-linux-gnu/bin/ -B/usr/ia64-unknown-linux-gnu/lib/ -isystem /usr/ia64-unknown-linux-gnu/include -isystem /usr/ia64-unknown-linux-gnu/sys-include-DEFAULT_PIE -DEFAULT_RELRO -DEFAULT_BIND_NOW -DUSE_LIBUNWIND_EXCEPTIONS -pipe -mtune=mckinley -O2 -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -o lto1 \ lto/lto-lang.o lto/lto.o lto/lto-elf.o attribs.o main.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a -lmpc -lmpfr -lgmp -ldl -rdynamic -ldl -lz -lelf ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lelf build/genchecksum cc1-dummy cc1-checksum.c collect2: ld returned 1 exit status make[3]: *** [lto1] Error 1 make[3]: *** Waiting for unfinished jobs collect2: ld returned 1 exit status make[3]: *** [cc1plus-dummy] Error 1 Portage 2.2.0_alpha4 (hardened/linux/ia64/server, gcc-4.4.5, glibc-2.11.2-r3, 2.6.27-openvz-levitan.1 ia64) = System uname: Linux-2.6.27-openvz-levitan.1-ia64-31-with-gentoo-2.0.1 Timestamp of tree: Mon, 22 Nov 2010 15:45:01 + app-shells/bash: 4.1_p7 dev-lang/python: 2.6.5-r3, 3.1.2-r4 sys-apps/baselayout: 2.0.1-r1 sys-apps/openrc: 0.6.3 sys-apps/sandbox:2.3-r1 sys-devel/autoconf: 2.65-r1 sys-devel/automake: 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.5 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.30-r1 (sys-kernel/linux-headers) Repositories: gentoo sunrise local ACCEPT_KEYWORDS=ia64 ACCEPT_LICENSE=* -...@eula CBUILD=ia64-unknown-linux-gnu CFLAGS=-pipe -mtune=mckinley -O2 -ftree-vectorize CHOST=ia64-unknown-linux-gnu CONFIG_PROTECT=/etc CONFIG_PROTECT_MASK=/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo CXXFLAGS=-pipe -mtune=mckinley -O2 -ftree-vectorize DISTDIR=/var/cache/portage/distfiles EMERGE_DEFAULT_OPTS=--buildpkg --with-bdeps y --keep-going FEATURES=assume-digests binpkg-logs distlocks fixlafiles fixpackages news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync GENTOO_MIRRORS=http://ftp.spline.inf.fu-berlin.de/mirrors/gentoo/
[Bug other/42683] New: gcc manpage: Description of x86 -march not clear regarding mmx
The description of -march=i686/pentiumpro in the gcc manpage is: i586, pentium Intel Pentium CPU with no MMX support. pentium-mmx Intel PentiumMMX CPU based on Pentium core with MMX instruction set support. pentiumpro Intel PentiumPro CPU. i686 Same as generic, but when used as march option, PentiumPro instruction set will be used, so the code will run on all i686 family chips. In this context it is not clear whether i686 includes MMX support or not. Checking Wikipedia suggests (though it is not clearly mentioned) that the PentiumPro contained no MMX support, which arrived only with the Pentium II. Thus the description of pentiumpro should probably include with no MMX support as the description of pentium does. -- Summary: gcc manpage: Description of x86 -march not clear regarding mmx Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: devurandom at gmx dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42683
