[Bug debug/24943] New: [hppa64] Bad dwarf output using non-preserved base register
Given a program like this:
int foo(int a, int b, int c)
{
return a+b+c;
}
int bar(int a, int b, int c)
{
return foo(a, b, c);
}
int main(int argc, char **argv)
{
return bar(1,2,3);
}
for foo and bar, gcc generates code that stores the arguments a, b, and c on
the stack by using the argument pointer, but it does this indirectly, like so:
foo
.PROC
.CALLINFO FRAME=80,NO_CALLS,SAVE_SP,ENTRY_GR=3
.ENTRY
copy %r3,%r1
copy %r30,%r3
std,ma %r1,80(%r30)
std %r3,-8(%r30)
ldo -64(%r29),%r20
stw %r26,4(%r20)
stw %r25,12(%r20)
stw %r24,20(%r20)
[...]
gcc proceeds to emit debug info for a, b, and c relative to r20:
$ opt/bin/readelf -wi dwarfbug
[...]
<2><7d>: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name: a
DW_AT_decl_file : 1
DW_AT_decl_line : 1
DW_AT_type:
DW_AT_location: 2 byte block: 84 4 (DW_OP_breg20: 4)
<2><89>: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name: b
DW_AT_decl_file : 1
DW_AT_decl_line : 1
DW_AT_type:
DW_AT_location: 2 byte block: 84 c (DW_OP_breg20: 12)
<2><95>: Abbrev Number: 3 (DW_TAG_formal_parameter)
DW_AT_name: c
DW_AT_decl_file : 1
DW_AT_decl_line : 1
DW_AT_type:
DW_AT_location: 2 byte block: 84 14(DW_OP_breg20: 20)
The problem is that since r20 is not a call preserved register, when you are
doing a stack unwind, you have no way to retrieve those variables in anything
other than the topmost frame.
I've seen it do this with r20 and r28, but I guess it can do it with any
available register.
On 32-bit hppa, the parameters are always described relative to the frame base
(DW_OP_fbreg), which works fine.
I'm testing this on hpux, but this looks like it affects all 64-bit hppa
targets.
--
Summary: [hppa64] Bad dwarf output using non-preserved base
register
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tausq at debian dot org
GCC build triplet: hppa64-hp-hpux11.11
GCC host triplet: hppa64-hp-hpux11.11
GCC target triplet: hppa64-hp-hpux11.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24943
[Bug debug/24943] [hppa64] Bad dwarf output using non-preserved base register
--- Comment #1 from tausq at debian dot org 2005-11-20 03:38 --- I forgot to mention that the above was compiled with gcc -g -o dwarfbug dwarfbug.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24943
[Bug debug/25258] New: [4.0 regression/hpux] gcc generates incorrect stabs debug output
Programs compiled with gcc-4.x on 32-bit hpux targets cannot be debugged. When
loaded into gdb, the programs behave as if no debugging information is present.
For example, given:
int foo(int x)
{
return x;
}
int main(int argc, char **argv)
{
return foo(argc);
}
Placing a breakpoint on foo gives:
(gdb) b foo
During symbol reading, unknown symbol type 0x2e.
During symbol reading, block end address less than block start address in main
(patched it).
During symbol reading, inner block (0x2960-0x2960) not inside outer block
(0x2920-0x2920).
Breakpoint 1 at 0x292c
The "unknown symbol type" warning is for the new BNSYM stab entry that was
added to gcc but not yet updated in gdb.
this problem seems to only occur on the 32-bit HPUX port. On 64-bit HPUX and
32-bit Linux there does not appear to be any problems with slabs debugging.
--
Summary: [4.0 regression/hpux] gcc generates incorrect stabs
debug output
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tausq at debian dot org
GCC build triplet: hppa2.0w-hp-hpux11.11
GCC host triplet: hppa2.0w-hp-hpux11.11
GCC target triplet: hppa2.0w-hp-hpux11.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25258
[Bug debug/25258] [4.0 regression/hpux] gcc generates incorrect stabs debug output
--- Comment #1 from tausq at debian dot org 2005-12-06 05:38 --- The difference is that gcc-3.x creates: .proc .callinfo xxx .entry ... .exit .procend .space $TEXT$ .nsubspa $CODE$,QUAD=0,ALIGN=8,ACCESS=44,CODE_ONLY .stabs "",100,0,0,L$text_end L$text_end: whereas gcc-4.x creates: .proc .callinfo xxx .entry ... .exit .procend .space $TEXT$ .subspa $CODE$ L$scope0001: .space $TEXT$ .subspa $CODE$ .stabs "",100,0,0,L$etext L$etext: By using subspa, the L$etext label is placed back at the beginning of the original code section, so it does not properly indicate the end of the compilation unit. -- tausq at debian dot org changed: What|Removed |Added Known to fail||4.0.2 Known to work||3.3.5 Summary|[4.0 regression/hpux] gcc |[4.0 regression/hpux] gcc |generates incorrect stabs |generates incorrect stabs |debug output|debug output http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25258
[Bug debug/25258] [4.0 regression/hpux] gcc generates incorrect stabs debug output
--- Comment #2 from tausq at debian dot org 2005-12-06 05:47 --- I'm guessing this is the patch that introduced this regression: 2004-08-20 Zack Weinberg <[EMAIL PROTECTED]> John David Anglin <[EMAIL PROTECTED]> * config/pa/pa-protos.h (readonly_data, one_only_readonly_data_section, one_only_data_section): Rename to som_readonly_data_section, som_one_only_readonly_data_section and som_one_only_data_section. * config/pa/pa.c (ONE_ONLY_TEXT_SECTION_ASM_OP, NEW_TEXT_SECTION_ASM_OP, DEFAULT_TEXT_SECTION_ASM_OP): Delete conditional defines. (som_text_section_asm_op): Replace ONE_ONLY_TEXT_SECTION_ASM_OP, NEW_TEXT_SECTION_ASM_OP and DEFAULT_TEXT_SECTION_ASM_OP with actual string values. (pa_select_section): Use renamed section functions. * config/pa/pa.h (EXTRA_SECTIONS, EXTRA_SECTION_FUNCTIONS, SOM_READONLY_DATA_SECTION_FUNCTION, SOM_ONE_ONLY_READONLY_DATA_SECTION_FUNCTION, SOM_ONE_ONLY_DATA_SECTION_FUNCTION, FORGET_SECTION_FUNCTION): Define here ... * config/pa/som.h: ... not here. (DEFAULT_TEXT_SECTION_ASM_OP, NEW_TEXT_SECTION_ASM_OP, ONE_ONLY_TEXT_SECTION_ASM_OP, READONLY_DATA_ASM_OP, ONE_ONLY_READONLY_DATA_SECTION_ASM_OP, ONE_ONLY_DATA_SECTION_ASM_OP): Delete. (READONLY_DATA_SECTION): Use som_readonly_data_section. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25258
[Bug debug/24943] [hppa64] Bad dwarf output using non-preserved base register
--- Comment #2 from tausq at debian dot org 2005-12-08 05:26 --- Some discussion about this PR is here: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01563.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24943
[Bug c++/28620] New: [4.1 regression] static const member in template class leads to multiple definitions at linktime
with the attached testcase, during linking you get:
test2.o:(.data+0x0): multiple definition of `_ZN3BadIT_E2_yE'
test1.o:(.data+0x0): first defined here
this comes from a template class:
template
class Bad {
static const int _y;
};
template const int Bad::_y = 1023;
although this seems like a generic c++ problem, it was only observed on
hppa-linux and not on other platforms.
this test was simplified from a failure reported in building the quantlib
package against g++-4.1. With earlier g++ versions the package builds fine.
--
Summary: [4.1 regression] static const member in template class
leads to multiple definitions at linktime
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tausq at debian dot org
GCC build triplet: hppa-unknown-linux
GCC host triplet: hppa-unknown-linux
GCC target triplet: hppa-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28620
[Bug c++/28620] [4.1 regression] static const member in template class leads to multiple definitions at linktime
--- Comment #1 from tausq at debian dot org 2006-08-06 10:07 --- Created an attachment (id=12026) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12026&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28620
[Bug c++/26957] [4.0/4.1/4.2 regression] ICE in make_decl_rtl, at varasm.c:871
--- Comment #13 from tausq at debian dot org 2006-09-08 15:04 --- Works for me on the original test case (ACE package) and on the reduced test case in #3. Tested on hppa-linux native. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26957
[Bug rtl-optimization/17264] [hppa] Missing address increment optimization for fp load/stores
--- Comment #4 from tausq at debian dot org 2006-09-24 23:49 --- Fixed in gcc-4.x -- tausq at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17264
[Bug rtl-optimization/23369] New: [4.0.x regression] Generates wrong code for funcptr comparison
Compiling the attached testcase with gcc -O2 -S signals.c, the generated asm contains: .loc 1 51 0 bl __canonicalize_funcptr_for_compare,%r2 ldo -2(%r7),%r26 ldi -4,%r26 bl __canonicalize_funcptr_for_compare,%r2 copy %r28,%r4 .loc 1 52 0 .loc 1 51 0 comb,>>= %r28,%r4,.L15 ldi 0,%r28 "old" is assigned to %r7. Why is it subtracting 2 from it before passing it to __cffc? gcc-3.x does not have this problem. This testcase was extracted from signals.c from glibc/linuxthreads, based on our investigation of Debian BTS bug #321785 -- Summary: [4.0.x regression] Generates wrong code for funcptr comparison Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tausq at debian dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux GCC host triplet: hppa-unknown-linux GCC target triplet: hppa-unknown-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23369
[Bug rtl-optimization/23369] [4.0.x regression] Generates wrong code for funcptr comparison
--- Additional Comments From tausq at debian dot org 2005-08-13 02:51 --- Created an attachment (id=9487) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9487&action=view) Testcase Compile with gcc -O2 -S -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23369
[Bug rtl-optimization/23369] [4.0.x regression] Generates wrong code for funcptr comparison
-- What|Removed |Added Keywords||wrong-code Known to fail||4.0.1 Known to work||3.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23369
[Bug rtl-optimization/23369] [4.0.x regression] Generates wrong code for funcptr comparison
--- Additional Comments From tausq at debian dot org 2005-08-13 03:08 --- The line of code in question is: 51 if (old == SIG_IGN || old == SIG_DFL || old == SIG_ERR) after preprocessing, this becomes if (old == ((__sighandler_t) 1) || old == ((__sighandler_t) 0) || old == ((__sighandler_t) -1)) It appears gcc optimized out the the old == 0 case, and it does the right thing for the old == 1 case. For the old == -1 case, it seems to subtract 2 from old, and converts -1 to -4. Weird. This also happens with -O1. Dave says it looks like the initial rtl generation is wrong, so maybe this is not an optimization bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23369
[Bug rtl-optimization/23369] [4.0.x regression] Generates wrong code for funcptr comparison
--- Additional Comments From tausq at debian dot org 2005-08-13 03:46 --- Created an attachment (id=9488) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9488&action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23369
[Bug middle-end/23369] [4.0/4.1 regression] build_range_check generates wrong code for funcptr comparison
--- Additional Comments From tausq at debian dot org 2005-08-15 05:31 --- Do I understand correctly that there are two distinct problems: 1) gcc should not be canonicalizing constants casted as function pointers 2) gcc should not generate relational comparisons against function pointers ? it seems from my quick tests that #1 is not affected by build_range_test (i.e. something else is wrong). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23369
[Bug c/34762] New: [4.2 regression] internal compiler error: in delete_output_reload, at reload1.c:7958
While building RPM on hppa with gcc-4.2, build fails with the captioned error. Somewhat reduced testcase attached. Builds fine with -O1 or without -fPIC, or with older compilers. ffmpeg and squashfs also fail to build with a similar error (not always built with -fPIC) -- Summary: [4.2 regression] internal compiler error: in delete_output_reload, at reload1.c:7958 Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tausq at debian dot org GCC build triplet: hppa-linux GCC host triplet: hppa-linux GCC target triplet: hppa-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34762
[Bug c/34762] [4.2 regression] internal compiler error: in delete_output_reload, at reload1.c:7958
--- Comment #1 from tausq at debian dot org 2008-01-12 20:54 --- Created an attachment (id=14931) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14931&action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34762
[Bug target/26255] New: [3.3 regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:391
Ref: http://bugs.debian.org/352529
The attached testcase, reduced from the Debian BTS bug report, causes an ICE
bug.c: In function 'foo':
bug.c:31: error: insn does not satisfy its constraints:
(insn 156 35 37 0 (set (reg:HI 70 %fr23 [122])
(reg:HI 20 %r20)) 53 {*pa.md:2926} (nil)
(nil))
bug.c:31: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:391
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
bug.c -
typedef short int16_t;
int round_sample(int *sum);
#define MULS(ra, rb) ((ra) * (rb))
#define SUM8(sum, op, w, p) \
{ \
sum op MULS((w)[0 * 64], p[0 * 64]);\
sum op MULS((w)[1 * 64], p[1 * 64]);\
sum op MULS((w)[2 * 64], p[2 * 64]);\
sum op MULS((w)[3 * 64], p[3 * 64]);\
sum op MULS((w)[4 * 64], p[4 * 64]);\
sum op MULS((w)[5 * 64], p[5 * 64]);\
sum op MULS((w)[6 * 64], p[6 * 64]);\
sum op MULS((w)[7 * 64], p[7 * 64]);\
}
void foo(int *dither_state, int *samples)
{
int16_t *synth_buf;
const int16_t *w, *p;
int sum;
sum = *dither_state;
p = synth_buf + 16;
SUM8(sum, +=, w, p);
p = synth_buf + 48;
SUM8(sum, -=, w + 32, p);
*samples = round_sample(&sum);
}
bug.c -
$ cc -O2 -c bug.c
bug.c: In function 'foo':
bug.c:31: error: insn does not satisfy its constraints:
(insn 156 35 37 0 (set (reg:HI 70 %fr23 [122])
(reg:HI 20 %r20)) 53 {*pa.md:2926} (nil)
(nil))
bug.c:31: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:391
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
Problem only happens with -O2.
--
Summary: [3.3 regression] internal compiler error: in
reload_cse_simplify_operands, at postreload.c:391
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tausq at debian dot org
GCC build triplet: hppa-linux
GCC host triplet: hppa-linux
GCC target triplet: hppa-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26255
[Bug target/26255] [4.0 regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:391
--- Comment #1 from tausq at debian dot org 2006-02-13 05:13 --- I forgot to mention that this bug does not happen with the 20060104 snapshot of gcc-4.0_branch (Debian 4.0.2-6), only with 20060128 (Debian 4.0.2-8) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26255
[Bug target/26255] [4.0 regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:391
--- Comment #6 from tausq at debian dot org 2006-02-15 05:50 --- Will this go into the 4.0 branch too? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26255
[Bug debug/26330] New: gcc generates code that does not allow retrieval of struct arguments with debugger
Given the following code from gdb's funcargs test:
typedef struct s
{
short s;
int i;
long l;
} SVAL;
void recurse (SVAL a, int depth)
{
a.s = a.i = a.l = --depth;
if (depth == 0)
hitbottom ();
else
recurse (a, depth);
}
compiled with -g
gcc-4.0 does not emit a dwarf location for the 'a' argument:
$ readelf -wi funcargs
[]
<2><1921>: Abbrev Number: 11 (DW_TAG_formal_parameter)
DW_AT_name: a
DW_AT_decl_file : 1
DW_AT_decl_line : 612
DW_AT_type: <18e0>
in gcc-3.x, you will get one more dwarf attribute:
DW_AT_location: 3 byte block: 91 18 6 (DW_OP_fbreg: 24; DW_OP_deref)
The difference is that in gcc 3.x, the first argument is first copied from the
incoming argument register to the stack. In gcc-4.x the generated code does not
do this stack save and uses the incoming register directly (actually it first
copies it to a scratch register).
--
Summary: gcc generates code that does not allow retrieval of
struct arguments with debugger
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tausq at debian dot org
GCC build triplet: hppa-unknown-linux
GCC host triplet: hppa-unknown-linux
GCC target triplet: hppa-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26330
[Bug target/26743] New: gcc generates unreachable branch
gcc -O2 -c hamlibperl_wrap.i gives: /tmp/ccxskRBB.s: Assembler messages: /tmp/ccxskRBB.s:232018: Error: Field out of range [-262144..262143] (319532). /tmp/ccxskRBB.s:312290: Error: Field out of range [-262144..262143] (-320952). The problem happens with gcc-3.3.6, gcc-3.4.5, gcc-4.0.3 and gcc-4.1.0 -- Summary: gcc generates unreachable branch Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tausq at debian dot org GCC build triplet: hppa-unknown-linux GCC host triplet: hppa-unknown-linux GCC target triplet: hppa-unknown-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26743
[Bug target/26743] gcc generates unreachable branch
--- Comment #1 from tausq at debian dot org 2006-03-18 10:14 --- Created an attachment (id=11066) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11066&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26743
[Bug target/26743] gcc generates unreachable branch
--- Comment #3 from tausq at debian dot org 2006-03-19 15:52 --- I think this is a bit different, the bit of code that causes the problem is: 339796 .loc 1 38663 0 339797 or,<> %r28,%r0,%r3 339798 b .L25049 339799 copy %r4,%r19 This bit of code is (I think) generated by output_movb() in pa.c, which doesn't check if the branch target is reachable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26743
[Bug debug/24943] [hppa64] Bad dwarf output using non-preserved base register
--- Comment #5 from tausq at debian dot org 2006-03-20 02:34 --- Indeed, as Dave said this is a different and not yet fixed problem. -- tausq at debian dot org changed: What|Removed |Added Known to fail|3.3.4 4.0.1 |3.3.4 4.0.1 4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24943
[Bug rtl-optimization/26945] New: [3.4/4.0/4.1 regression] Attempt to delete prologue/epilogue insn
Compile attached test case with optimization causes an ICE:
$ gcc -c -O1 bug.c
bug.c: In function 'parsearguments':
bug.c:46: error: Attempt to delete prologue/epilogue insn:
(insn/f 97 96 98 0 (set (mem:SI (plus:SI (reg/f:SI 30 %r30)
(const_int -124 [0xff84])) [0 S4 A32])
(reg:SI 4 %r4)) -1 (nil)
(nil))
bug.c:46: internal compiler error: in propagate_one_insn, at flow.c:1690
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
This may be related to PR12535 but the code that triggers the problem is
different.
--
Summary: [3.4/4.0/4.1 regression] Attempt to delete
prologue/epilogue insn
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tausq at debian dot org
GCC build triplet: hppa-unknown-linux
GCC host triplet: hppa-unknown-linux
GCC target triplet: hppa-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26945
[Bug rtl-optimization/26945] [3.4/4.0/4.1 regression] Attempt to delete prologue/epilogue insn
--- Comment #1 from tausq at debian dot org 2006-03-30 16:28 --- Created an attachment (id=11167) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11167&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26945
[Bug rtl-optimization/26945] [3.4/4.0/4.1 regression] Attempt to delete prologue/epilogue insn
--- Comment #2 from tausq at debian dot org 2006-03-30 16:31 --- The code is valid syntactically, but there is actually a bug. the longoptions array only has 3 elements, but we try to fill in 4 entries. if we make the longoptions array bigger than it doesn't cause the ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26945
[Bug c++/26957] New: [4.0 regression] ICE in make_decl_rtl, at varasm.c:871
$ g++ -c bug.cc
bug.cc: In member function 'void
TAO_DynCommon::_ZTv0_n100_N13TAO_DynCommon17insert_longdoubleEN7ACE_CDR10LongDoubleE(CORBA::LongDouble)':
bug.cc:28887: internal compiler error: in make_decl_rtl, at varasm.c:871
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
Testcase is extracted from the "ace" package on Debian.
--
Summary: [4.0 regression] ICE in make_decl_rtl, at varasm.c:871
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tausq at debian dot org
GCC build triplet: hppa-unknown-linux
GCC host triplet: hppa-unknown-linux
GCC target triplet: hppa-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26957
[Bug c++/26957] [4.0 regression] ICE in make_decl_rtl, at varasm.c:871
--- Comment #1 from tausq at debian dot org 2006-03-30 23:52 --- Created an attachment (id=11171) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11171&action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26957
[Bug tree-optimization/22051] New: [4.0 regression] Wrong code for function pointer comparision during optimization
with the following test program, gcc-4.0 doesn't emit the required function
canonicalization code (calls to __canonicalize_funcptr_for_compare) to do the
comparison when optimization is enabled.
[EMAIL PROTECTED]:/tmp/dl$ gcc-3.3 -D_GNU_SOURCE -O2 -o default default.c -ldl;
./default; echo $?
0
[EMAIL PROTECTED]:/tmp/dl$ gcc-4.0 -D_GNU_SOURCE -O2 -o default default.c -ldl;
./default; echo $?
1
#include
#include
int
main (int argc, char *argv[])
{
void *p;
/* Find function `main'. */
p = dlsym (RTLD_DEFAULT, "main");
if (p == NULL)
return -1;
else if ((int (*)(int, char **))p != main)
return 1;
else
return 0;
}
--
Summary: [4.0 regression] Wrong code for function pointer
comparision during optimization
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tausq at debian dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: hppa-unknown-linux
GCC host triplet: hppa-unknown-linux
GCC target triplet: hppa-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22051
[Bug tree-optimization/22051] [4.0 regression/hppa-linux] Wrong code for function pointer comparision during optimization
-- What|Removed |Added Known to fail||4.0.0 Known to work||3.3.5 Summary|[4.0 regression] Wrong code |[4.0 regression/hppa-linux] |for function pointer|Wrong code for function |comparision during |pointer comparision during |optimization|optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22051
[Bug middle-end/22051] [4.0/4.1 regression] Wrong code for function pointer comparision during optimization
--- Additional Comments From tausq at debian dot org 2005-06-13 16:23 --- this is what you get with gcc-3.3: .LC0: .stringz"main" .section.rodata.cst4,"aM",@progbits,4 .align 4 .LC1: .word P%main [...] ldil LR'.LC0,%r25 ldi -1,%r4 bl dlsym,%r2 ldo RR'.LC0(%r25),%r25 comib,= 0,%r28,.L1 copy %r28,%r26 bl __canonicalize_funcptr_for_compare,%r2 nop ldil LR'.LC1,%r19 copy %r28,%r4 bl __canonicalize_funcptr_for_compare,%r2 ldw RR'.LC1(%r19),%r26 comclr,= %r28,%r4,%r4 ldi 1,%r4 .L1: copy %r4,%r28 And with gcc-4.0, you get instead: .LC0: .stringz"main" .section.rodata.cst4,"aM",@progbits,4 .align 4 .LC1: .word P%main [...] ldil LR'.LC0,%r25 bl dlsym,%r2 ldo RR'.LC0(%r25),%r25 movb,= %r28,%r20,.L4 ldi -1,%r19 ldil LR'.LC1,%r28 ldw RR'.LC1(%r28),%r19 comclr,= %r19,%r20,%r19 ldi 1,%r19 .L4: copy %r19,%r28 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22051
[Bug debug/15860] [3.3/3.4/4.0 regression] No DW_AT_location debug info is emitted for formal arguments to a function that uses "register" qualifiers
--- Additional Comments From tausq at debian dot org 2004-10-13 21:24 --- Verified with gcc-3.4.1 and gdb-6.2.1 on hppa-linux. Thanks Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15860
[Bug middle-end/17564] [4.0 Regression] New treatment of function pointers when used with equality operators
-- What|Removed |Added CC||tausq at debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17564
[Bug c++/18509] New: [hppa] try-catch program fails when compiled with frame pointers
[EMAIL PROTECTED]:/tmp$ g++ -o try_catch try_catch.cc [EMAIL PROTECTED]:/tmp$ ./try_catch Segmentation fault (core dumped) [EMAIL PROTECTED]:/tmp$ g++ -fomit-frame-pointer -o try_catch try_catch.cc [EMAIL PROTECTED]:/tmp$ ./try_catch [EMAIL PROTECTED]:/tmp$ [EMAIL PROTECTED]:/tmp$ g++ -O1 -fno-omit-frame-pointer -o try_catch try_catch.cc [EMAIL PROTECTED]:/tmp$ ./try_catch free(): invalid pointer 0xbff004b8! Segmentation fault (core dumped) [EMAIL PROTECTED]:/tmp$ The same problem is seen in 3.0, but not in gcc-3.4. -- Summary: [hppa] try-catch program fails when compiled with frame pointers Product: gcc Version: 3.3.5 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tausq at debian dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux GCC host triplet: hppa-unknown-linux GCC target triplet: hppa-unknown-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18509
[Bug c++/18509] [hppa] try-catch program fails when compiled with frame pointers
--- Additional Comments From tausq at debian dot org 2004-11-16 00:07 --- Created an attachment (id=7550) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7550&action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18509
[Bug target/18509] [3.3 only] [hppa] try-catch program fails when compiled with frame pointers
--- Additional Comments From tausq at debian dot org 2004-11-16 00:55 --- (In reply to comment #3) > I don't believe there have been any specific changes to the backend > with respect to exception support since 3.3.0. 3.0 didn't have dwarf2 > EH support. There possibly have been some changes in the libstdc++ > support. > > Which exception model (sjlj or dwarf2) are you using? sjlj for gcc-3.3. now that you mention it, i see that my 3.4 compiler is compiled to use dwarf2. i don't have a sjlj-compiled gcc-3.4 compiler handy... but i can try it if that will help. randolph -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18509
[Bug debug/18856] New: Missing .loc information after prologue
The attached program is extracted from the gdb testsuite (gdb.base/annota3.c) According to Dan, the code generated by gcc is missing a .loc directive: http://sources.redhat.com/ml/gdb-patches/2004-12/msg00143.html i.e. gcc generates: .loc 1 6 0 handle_USR1: .PROC .CALLINFO FRAME=64,NO_CALLS,SAVE_SP,ENTRY_GR=3 .ENTRY copy %r3,%r1 .LCFI0: copy %r30,%r3 .LCFI1: stwm %r1,64(%r30) .LCFI2: stw %r26,-36(%r3) ldo 64(%r3),%r30 ldwm -64(%r30),%r3 bv,n %r0(%r2) .EXIT .PROCEND but there should be another .loc 1 6 0 before the ldo insn. gcc-3.4 handles this properly. -- Summary: Missing .loc information after prologue Product: gcc Version: 3.3.5 Status: UNCONFIRMED Severity: normal Priority: P2 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tausq at debian dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux GCC host triplet: hppa-unknown-linux GCC target triplet: hppa-unknown-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18856
[Bug debug/18856] Missing .loc information after prologue
--- Additional Comments From tausq at debian dot org 2004-12-06 18:50 --- Created an attachment (id=7692) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7692&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18856
[Bug debug/18856] Missing .loc information after prologue
-- What|Removed |Added Known to work||3.4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18856
[Bug debug/18856] [3.3 only, regression] Missing .loc information after prologue
-- What|Removed |Added Known to work|3.4.2 |3.0.4 3.4.2 Summary|[3.3 only] Missing .loc |[3.3 only, regression] |information after prologue |Missing .loc information ||after prologue http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18856
