[Bug target/43469] [4.5 Regression] ICE trying to compile glibc for ARM thumb2
--- Comment #10 from tschwinge at gcc dot gnu dot org 2010-04-03 15:18 --- Confirmed. -- tschwinge at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43469
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #24 from tschwinge at gcc dot gnu dot org 2010-03-31 15:49 --- Regression report for arm-none-linux-gnueabi: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01188.html Patch: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01505.html -- tschwinge at gcc dot gnu dot org changed: What|Removed |Added CC||tschwinge at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug target/43469] [4.5 Regression] ICE trying to compile glibc for ARM thumb2
--- Comment #5 from tschwinge at gcc dot gnu dot org 2010-03-23 14:14 --- Also got hit by this. -- tschwinge at gcc dot gnu dot org changed: What|Removed |Added CC||tschwinge at gcc dot gnu dot ||org Last reconfirmed|2010-03-22 08:56:27 |2010-03-23 14:14:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43469
[Bug debug/42380] CFI statements vs. -pg
--- Comment #5 from tschwinge at gcc dot gnu dot org 2010-01-06 17:57 --- This bug exists, by the way, not only when GCC is emitting CFI statements, but also when it's emitting .debug_frame directly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42380
[Bug debug/42403] New: Incorrect CFI: doesn't readjust CFA after pop
$ install/bin/arm-none-linux-gnueabi-gcc --version
arm-none-linux-gnueabi-gcc (GCC) 4.5.0 20091214 (experimental)
[...]
GCC fails to re-adjust the CFA after pop:
$ cat d.c
void foo(void)
{
register int r7 asm(r7);
asm volatile ( : : r (r7) : memory);
}
$ install/bin/arm-none-linux-gnueabi-gcc -g -O -c -o d.o d.c
$ install/bin/arm-none-linux-gnueabi-objdump -dr d.o
d.o: file format elf32-littlearm
Disassembly of section .text:
foo:
0: e52d7004push{r7}; (str r7, [sp, #-4]!)
4: e8bd0080pop {r7}
8: e12fff1ebx lr
$ install/bin/arm-none-linux-gnueabi-readelf -wf d.o
Contents of the .debug_frame section:
000c CIE
Version: 1
Augmentation:
Code alignment factor: 1
Data alignment factor: -4
Return address column: 14
DW_CFA_def_cfa: r13 ofs 0
0010 0014 FDE cie= pc=..000c
DW_CFA_advance_loc: 4 to 0004
DW_CFA_def_cfa_offset: 4
DW_CFA_offset: r7 at cfa-4
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
For correctness, GCC should emit .cfi_adjust_cfa_offset 0 and
.cfi_restore r7 at pos. 8.
--
Summary: Incorrect CFI: doesn't readjust CFA after pop
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tschwinge at gcc dot gnu dot org
GCC target triplet: arm-none-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42403
[Bug debug/42404] New: Incorrect CFI generated
$ install/bin/arm-none-linux-gnueabi-gcc --version
arm-none-linux-gnueabi-gcc (GCC) 4.5.0 20091214 (experimental)
[...]
This GCC contains the following patch for gcc/config/arm/arm.c:
@@ -1877,7 +1877,8 @@ arm_override_options (void)
debug info. However this also creates the .eh_frame
section, so disable them until GAS can handle
this properly. See PR40521. */
- if (TARGET_AAPCS_BASED)
+ if (TARGET_AAPCS_BASED
+ !getenv(GCC_ALLOW_CFI))
flag_dwarf2_cfi_asm = 0;
GCC created incorrect CFI:
$ cat d.c
void foo(void)
{
register int r7 asm(r7);
asm volatile ( : : r (r7) : memory);
}
$ GCC_ALLOW_CFI= install/bin/arm-none-linux-gnueabi-gcc -g -O -c -o d.o d.c
$ install/bin/arm-none-linux-gnueabi-objdump -dr d.o
d.o: file format elf32-littlearm
Disassembly of section .text:
foo:
0: e52d7004push{r7}; (str r7, [sp, #-4]!)
4: e8bd0080pop {r7}
8: e12fff1ebx lr
$ install/bin/arm-none-linux-gnueabi-readelf -wf d.o
Contents of the .debug_frame section:
000c CIE
Version: 1
Augmentation:
Code alignment factor: 2
Data alignment factor: -4
Return address column: 14
DW_CFA_def_cfa: r13 ofs 0
0010 0014 FDE cie= pc=..000c
DW_CFA_advance_loc: 4 to 0004
DW_CFA_def_cfa_offset: 4
DW_CFA_advance_loc: 8 to 000c
DW_CFA_offset: r7 at cfa-4
DW_CFA_nop
DW_CFA_nop
The .cfi_offset r7, -4 belongs at pos. 4, not 0xc.
Also, for correctness, GCC should emit .cfi_adjust_cfa_offset -4 and
.cfi_restore r7 at pos. 8, see PR42403.
--
Summary: Incorrect CFI generated
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tschwinge at gcc dot gnu dot org
GCC target triplet: arm-none-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42404
[Bug debug/42403] Incorrect CFI: doesn't readjust CFA after pop
--- Comment #1 from tschwinge at gcc dot gnu dot org 2009-12-17 14:12 --- Last paragraph: .cfi_adjust_cfa_offset *-4*, of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42403
[Bug debug/42380] CFI statements vs. -pg
--- Comment #2 from tschwinge at gcc dot gnu dot org 2009-12-16 09:58 --- As a tiny, years-old pointer: in http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01006.html, Daniel J. suggested that ``appropriate dwarf2 frame gunk'' should be added. -- tschwinge at gcc dot gnu dot org changed: What|Removed |Added CC||drow at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42380
[Bug debug/42380] New: CFI statements vs. -pg
See http://gcc.gnu.org/ml/gcc/2009-12/msg00183.html.
To sum up: the question is whether the CFA needs to be adjusted after push
{lr}, and before calling __gnu_mcount_nc. Currently it is not valid until
__gnu_mcount_nc returns.
--
Summary: CFI statements vs. -pg
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tschwinge at gcc dot gnu dot org
GCC target triplet: arm-none-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42380
[Bug debug/42380] CFI statements vs. -pg
--- Comment #1 from tschwinge at gcc dot gnu dot org 2009-12-15 16:57 --- Richard Earnshaw wrote: I'm not sure what other architectures do in this case. Do they also put out adjustments to the cfi? I had a look at x86 and x86_64 -- they still need a frame pointer together with -pg, which is thus set-up (with CFI information) before calling mcount. I'll try to locate and have a look at another architecture. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42380
[Bug java/38827] New: gcj emitting incorrect code
I originally found this problem when trying to compile a Java package written
by the Universität Stuttgart's institute IKR. I was using Debian's gcj
package, version 4.3.2-2, but can likewise reproduce this using SVN trunk, as
well as Debian's 4.2.4-4 package.
I completely reduced the test case to the following:
public class Bug_Class
{
}
public interface Bug_Interface
{
}
public class Bug
{
public X extends Bug_Class Bug_Interface Bug(X x)
{
set(x);
}
public void set(Bug_Interface x)
{
}
}
Directly compiling this will fail as follows:
$ ~/GCC/trunk.build.64.install/bin/gcj -c Bug.java
Bug.java: In class 'Bug':
Bug.java: In constructor '(Bug_Class)':
In file included from built-in:3:
Bug.java:3: error: verification failed at PC=9: incompatible type on stack
gcj is able to emit a class file, but that one is considered non-verifying by
the BCEL verifier:
[...]
Pass 3b, method number 0 ['public void init(Bug_Class arg1)
[Signature(E:LBug_Class;:LBug_Interface;(TE;)V)]']:
VERIFIED_REJECTED
Constraint violated in method 'public void init(Bug_Class arg1)
[Signature(E:LBug_Class;:LBug_Interface;(TE;)V)]':
Instruction INVOKEVIRTUAL constraint violated: Expecting a 'Bug_Interface'
but found a 'Bug_Class' on the stack (which is not assignment compatible).
InstructionHandle:6: invokevirtual[182](3) 13
[...]
What Sun's javac does differently (as per class-file disassembly inspection) is
emitting a checkcast against class Bug_Interface before calling invokevirtual.
--
Summary: gcj emitting incorrect code
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tschwinge at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38827
[Bug driver/21706] MAXPATHLEN usage in [gcc]/gcc/tlink.c
--- Comment #9 from tschwinge at gcc dot gnu dot org 2008-11-20 13:26 --- Fixed on trunk as rev142043. -- tschwinge at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21706
[Bug target/28102] [4.2/4.3/4.4 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- Comment #29 from tschwinge at gcc dot gnu dot org 2008-11-13 23:30 --- Subject: Bug 28102 Author: tschwinge Date: Thu Nov 13 23:28:46 2008 New Revision: 141838 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141838 Log: 2008-11-13 Thomas Schwinge [EMAIL PROTECTED] PR target/28102 * config.gcc (*-*-gnu*): Move Alpha parts into the `alpha*-*-gnu*', x86 parts into the `i[34567]86-*-linux*' and parts that are independent of the processor architecture into the `*-*-linux*' cases. (*-*-linux*): Consider `linux.opt' only for Linux-based configurations. * config/i386/gnu.h (GLIBC_DYNAMIC_LINKER): Redefine. (TARGET_OS_CPP_BUILTINS, LINK_SPEC): Don't redefine. [TARGET_LIBC_PROVIDES_SSP] (TARGET_THREAD_SSP_OFFSET): Undefine. * config/gnu.h (NO_IMPLICIT_EXTERN_C): Don't redefine. (HURD_TARGET_OS_CPP_BUILTINS): Don't define, but instead... (LINUX_TARGET_OS_CPP_BUILTINS): Redefine. Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config/gnu.h trunk/gcc/config/i386/gnu.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
[Bug target/28102] [4.2/4.3/4.4 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
-- tschwinge at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tschwinge at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-08-23 18:53:11 |2008-11-13 23:40:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
[Bug target/28102] [4.2/4.3/4.4 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC' undeclared
--- Comment #30 from tschwinge at gcc dot gnu dot org 2008-11-13 23:42 --- I have fixed this on the GCC trunk. Installing this fix on the 4.2 and 4.3 branches would be very difficult I was told, so we're going to abstain from even trying and are happy with a functional GCC trunk / 4.4 again. :-) -- tschwinge at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
