[Bug tree-optimization/41881] [4.5/4.6 regression] Complete unrolling (inner) versus vectorization of reduction
--- Comment #5 from drow at gcc dot gnu dot org 2010-08-10 16:01 --- Verified on x86_64 using: gcc-4.3 -O3 -o 43.s -S reduc.c -ftree-vectorizer-verbose=1 [two loops vectorized] gcc-4.4 -O3 -o 43.s -S reduc.c -ftree-vectorizer-verbose=1 [one loop vectorized] -- drow at gcc dot gnu dot org changed: What|Removed |Added CC||irar at gcc dot gnu dot org Known to fail||4.4.4 Known to work||4.3.5 Summary|Complete unrolling (inner) |[4.5/4.6 regression] |versus vectorization of |Complete unrolling (inner) |reduction |versus vectorization of ||reduction http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41881
[Bug middle-end/45017] miscompile with bitfield and optimization
--- Comment #7 from drow at gcc dot gnu dot org 2010-07-23 02:49 --- FYI, confirmed to fail for ColdFire. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45017
[Bug debug/44113] bad debugging information for unrolled loops
--- Comment #8 from drow at gcc dot gnu dot org 2010-05-19 18:08 --- It seems to me that a series of line notes for each copy of line 5 are the right debug output, and if GCC can generate that, someone should hack up GDB until it recognizes that and treats it sensibly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44113
[Bug debug/43628] [4.5 Regression] in-class func-ptr type parameter has unspecified DW_AT_type
--- Comment #2 from drow at gcc dot gnu dot org 2010-04-04 15:45 ---
FYI, this patch also fixes a number of failures in cpexprs.exp in GDB.
Testcase:
struct s
{
bool operator!= (s const o) const { return false; }
};
bool
func (const struct s arg, const struct s right)
{
return arg != right;
}
The THIS argument of operator!= gets a valid type. The O argument gets the
self-typedef, and produces a DW_TAG_const_type with no type argument.
I'd say an assertion in modified_type_die after creating a new const or
volatile DIE with sub_die == NULL would be appropriate, if it weren't for the
ERROR_MARK handling... I don't know if we get here after errors.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43628
[Bug debug/43521] java: this pointer not marked with DW_AT_artificial
--- Comment #1 from drow at gcc dot gnu dot org 2010-03-25 18:47 --- Interesting note: if this case had an abstract origin instead of a specification, then 15e and 173 would both have DW_AT_abstract_origin, and the DW_AT_artificial would be inherited. As it is, though, the debug info is wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43521
[Bug rtl-optimization/42575] arm-eabi-gcc 64-bit multiply weirdness
--- Comment #5 from drow at gcc dot gnu dot org 2010-02-22 21:06 --- (In reply to comment #3) * What is the purpose of insn 12 here? It looks to me like this is dead code, since r5 is restored in insn 38 (although, not knowing ARM so well, I may be wrong). I couldn't figure this out either. Where did it come from - was it so late that we never DCE'd it, or does something bizarre claim to be dependent on the value? Note how the sched1 pass has switched the two insns around. The register allocator now decides to use two new registers here, because r0 and r3 are both live. After RA, sched2 switches insn 9 and insn 10 again, and r2 and r3 become available in insn 10 -- but this is too late. Question for the ARM maintainer now is: Why does sched1 want to swap insns 9 and 10, when sched2 wants to swap them back again? I'm guessing, but presumably we want to separate the mul from the mla because they're dependent; the umull isn't. But I don't know what would swap them back again and that's probably the crux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42575
[Bug debug/27160] Debugging output forgets scope for typedefs.
--- Comment #3 from drow at gcc dot gnu dot org 2010-02-22 21:34 --- Works for me too, using GCC 4.4. -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27160
[Bug tree-optimization/38785] [4.3/4.4/4.5 Regression] huge performance regression on EEMBC bitmnp01
--- Comment #24 from drow at gcc dot gnu dot org 2010-02-19 14:08 --- If no one else has EEMBC available, ask me and we can verify any fix. We've been using Steven's and Joern's patches; we tried other approaches, but in the end we weren't able to come up with any other approach that worked as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785
[Bug libstdc++/15047] libstdc++ testing does not work remotely
--- Comment #15 from drow at gcc dot gnu dot org 2010-02-15 14:34 --- I no longer care whether this works; I don't do build-tree testing. It's probably still broken, but with no one using it, closing as WONTFIX. -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15047
[Bug debug/43053] New: DWARF info adds bogus const to 'this' argument
Compile this code (from the GDB testsuite) with G++ (tested 4.4.3, trunk):
class foo {
public:
int overload1arg (char);
};
int main ()
{
foo foo_instance1;
return 0;
}
int foo::overload1arg (char arg){ arg = 0; return 2;}
Here's the relevant bit of debug info:
22d: Abbrev Number: 3 (DW_TAG_subprogram)
2e DW_AT_external: 1
2f DW_AT_name: (indirect string, offset: 0x59): overload1arg
33 DW_AT_decl_file : 1
34 DW_AT_decl_line : 3
35 DW_AT_MIPS_linkage_name: (indirect string, offset: 0x0):
_ZN3foo12overload1argEc
39 DW_AT_type: 0x4b
3d DW_AT_declaration : 1
33e: Abbrev Number: 4 (DW_TAG_formal_parameter)
3f DW_AT_type: 0x52
43 DW_AT_artificial : 1
344: Abbrev Number: 5 (DW_TAG_formal_parameter)
45 DW_AT_type: 0x58
194: Abbrev Number: 12 (DW_TAG_subprogram)
95 DW_AT_specification: 0x2d
99 DW_AT_decl_line : 13
9a DW_AT_low_pc : 0xe
9e DW_AT_high_pc : 0x25
a2 DW_AT_frame_base : 0x38 (location list)
a6 DW_AT_sibling : 0xc6
2aa: Abbrev Number: 13 (DW_TAG_formal_parameter)
ab DW_AT_name: (indirect string, offset: 0x66): this
af DW_AT_type: 0xc6
b3 DW_AT_artificial : 1
b4 DW_AT_location: 2 byte block: 91 0 (DW_OP_fbreg: 0)
2b7: Abbrev Number: 14 (DW_TAG_formal_parameter)
b8 DW_AT_name: arg
bc DW_AT_decl_file : 1
bd DW_AT_decl_line : 13
be DW_AT_type: 0x58
c2 DW_AT_location: 2 byte block: 91 64 (DW_OP_fbreg: -28)
1c6: Abbrev Number: 15 (DW_TAG_const_type)
c7 DW_AT_type: 0x52
The in-class declaration of foo::overload1arg function has two arguments, of
types 0x52 and 0x58. The out of line version references that with
DW_AT_specification, but has argument types 0xc6 and 0x58. The
specification has a foo * argument, the implementation has a foo * const
argument.
'this' can not be modified, so arguably the const is right. But it should be
consistent between the two DIEs.
--
Summary: DWARF info adds bogus const to 'this' argument
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-debug
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=43053
[Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location
--- Comment #2 from drow at gcc dot gnu dot org 2010-02-12 15:52 --- The type of the class only contains one destructor. If you have to pick one for a debugger to call, in-charge makes the most sense. For other debugger purposes they all make equal sense (or nonsense). If you want to represent all three in the debug info, then not only do we need to know that they are clones of the same function, we also need to know which one is the in-charge versus not-in-charge versus deleting destructor to call the right one for debugger implementation of the delete statement. I'm pretty sure that would require new debug info extensions and new debugger support. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237
[Bug tree-optimization/43001] Missed vectorization on ARM NEON
--- Comment #4 from drow at gcc dot gnu dot org 2010-02-08 22:14 --- With -fmloat-abi=softfp, it looks to me like this is vectorized correctly on trunk. It's a little unintuitive because it becomes a left vector shift by 249 == -7. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43001
[Bug target/40887] GCC generates suboptimal code for indirect function calls on ARM
--- Comment #10 from drow at gcc dot gnu dot org 2010-01-07 14:42 --- Ramana, is this fixed or are you planning on applying it to more branches? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40887
[Bug debug/42380] CFI statements vs. -pg
--- Comment #3 from drow at gcc dot gnu dot org 2009-12-16 13:15 --- The CFA also needs to be adjusted after __gnu_mcount_nc returns; __gnu_mcount_nc is a pop instruction from the point-of-view of the caller. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42380
[Bug tree-optimization/41881] New: Complete unrolling (inner) versus vectorization of reduction
Here are two pretty straight-forward ways to write the same operation:
#define TYPE int
TYPE fun1(TYPE *x, TYPE *y, unsigned int n)
{
int i, j;
TYPE dot = 0;
for (i = 0; i n; i++)
dot += *(x++) * *(y++);
return dot;
}
TYPE fun2(TYPE *x, TYPE *y, unsigned int n)
{
int i, j;
TYPE dot = 0;
for (i = 0; i n / 8; i++)
for (j = 0; j 8; j++)
dot += *(x++) * *(y++);
return dot;
}
GCC 4.3 can vectorize both of them. GCC 4.4 can only vectorize fun1. I figure
this is why:
reduc.c:17: note: === vect_analyze_scalar_cycles ===
reduc.c:17: note: Analyze phi: dot_103 = PHI dot_110(5), 0(3)
reduc.c:17: note: Access function of PHI: {0, +, ((D.1621_32 + D.1621_43) +
D.1621_54) + D.1621_65)
+ D.1621_76) + D.1621_87) + D.1621_98) + D.1621_109}_1
reduc.c:17: note: step: ((D.1621_32 + D.1621_43) + D.1621_54) + D.1621_65)
+ D.1621_76) + D.1621_87)
+ D.1621_98) + D.1621_109, init: 0
reduc.c:17: note: step unknown.
The cunrolli pass (which there is no way to disable) has completely unrolled
the inner loop. Vectorizer SLP support can not handle the unrolled version of
the loop.
Also observed on ARM NEON with TYPE == float.
--
Summary: Complete unrolling (inner) versus vectorization of
reduction
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41881
[Bug tree-optimization/41881] Complete unrolling (inner) versus vectorization of reduction
--- Comment #3 from drow at gcc dot gnu dot org 2009-10-30 22:41 ---
Subject: Re: Complete unrolling (inner)
versus vectorization of reduction
On Fri, Oct 30, 2009 at 10:20:46PM -, rguenth at gcc dot gnu dot org wrote:
You could use -O2 -ftree-vectorize.
No:
static bool
gate_tree_complete_unroll_inner (void)
{
return optimize = 2;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41881
[Bug rtl-optimization/36712] Inefficient loop unrolling
--- Comment #7 from drow at gcc dot gnu dot org 2009-10-15 12:12 --- I really would like to see this submitted - at least as a starting point for discussion. You don't need to do anything different than for a small patch; if you've missed any steps, a reviewer will tell you. Another problem I noticed is that if RTL loop unrolling unrolls a loop, only the first iteration will use auto-inc patterns. This leads to silly omissions in the assembly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712
[Bug tree-optimization/38785] [4.3/4.4/4.5 Regression] huge performance regression on EEMBC bitmnp01
--- Comment #17 from drow at gcc dot gnu dot org 2009-07-23 21:50 --- Steven, have you had time for this? Anything we can do to help? -- drow at gcc dot gnu dot org changed: What|Removed |Added CC||steven at gcc dot gnu dot ||org, drow at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785
[Bug tree-optimization/40768] PRE backfires when given a sequence of if statements
--- Comment #3 from drow at gcc dot gnu dot org 2009-07-15 21:30 --- Hi Steven, Maybe I'm missing something, but what do patches talking about SMALL_REGISTER_CLASSES have to do with this issue? For ARM, the registers involved are general purpose and ! SMALL_REGISTER_CLASSES. There's about 14 of them available, and these PHIs want a virtually unbounded number of registers. And we are not optimizing for size (-O3). So I can't see how your patch is going to help. Don't get me wrong, I'm happy to close it again if they will :-) But I don't think either of the checks in want_to_pre_p will apply. -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40768
[Bug target/40672] constant address loads moved into loop unnecessarily
--- Comment #1 from drow at gcc dot gnu dot org 2009-07-07 15:03 --- It looks, roughly speaking, like the two nearby addresses are initially commonized. In the process, the use after the loop ends up sharing a REG with the use in the loop. Then the use in the loop is changed to use a new copy, and the initialization in the loop feeds the out-of-loop copy. And the use in the loop gets materialized above the loop as it should. In a quick look I didn't work out which RTL pass is at fault. -- drow 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=40672
[Bug debug/40573] DWARF for inlined subroutines refers to the outlined copy
--- Comment #4 from drow at gcc dot gnu dot org 2009-06-30 14:19 --- It looks like you're right. Jan K. recently added support to GDB to attach the unreferenced children of abstract DIEs to each concrete instance, and that caused my existing test case to fail in a new way. -- drow at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.4/4.5 Regression] DWARF |DWARF for inlined |for inlined subroutines |subroutines refers to the |refers to the outlined copy |outlined copy http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40573
[Bug debug/40573] DWARF for inlined subroutines refers to the outlined copy
--- Comment #5 from drow at gcc dot gnu dot org 2009-06-30 14:21 --- (In reply to comment #3) Hmm, I tought GCC was doing the same thing for years. So we need abstract function for each inline? Why? I think we each inlined copy (and the outlined copy) to refer to the one abstract copy. The problem is the links from the inlined copies to the outlined copy. Meanwhile I'll try to work around this in GDB. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40573
[Bug debug/40573] DWARF for inlined subroutines refers to the outlined copy
--- Comment #7 from drow at gcc dot gnu dot org 2009-06-30 17:52 --- Subject: Re: DWARF for inlined subroutines refers to the outlined copy On Tue, Jun 30, 2009 at 04:29:25PM -, jakub at gcc dot gnu dot org wrote: --- Comment #6 from jakub at gcc dot gnu dot org 2009-06-30 16:29 --- Created an attachment (id=18101) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18101action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18101action=view) gcc45-pr40573.patch Does this patch do what you wanted to see? No changes in the (patched to handle earlier GCC) GDB testsuite - good. No visible changes in the testcase DWARF either - bad. 21a6: Abbrev Number: 3 (DW_TAG_formal_parameter) 1a7 DW_AT_name: (indirect string, offset: 0xcc): arg1 1ab DW_AT_decl_file : 1 1ac DW_AT_decl_line : 22 1ad DW_AT_type: 0x1bd 21f4: Abbrev Number: 10 (DW_TAG_formal_parameter) 1f5 DW_AT_abstract_origin: 0x1a6 1f9 DW_AT_location: 1 byte block: 53(DW_OP_reg3) 42f7: Abbrev Number: 13 (DW_TAG_formal_parameter) 2f8 DW_AT_abstract_origin: 0x1f4 should be 0x1a6. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40573
[Bug debug/40573] DWARF for inlined subroutines refers to the outlined copy
--- Comment #9 from drow at gcc dot gnu dot org 2009-06-30 18:59 --- Subject: Re: DWARF for inlined subroutines refers to the outlined copy On Tue, Jun 30, 2009 at 06:13:16PM -, jakub at gcc dot gnu dot org wrote: Weird, the difference I get with the patch on the testcase at -O2 -g is attached. You're right, my test run was foobar. Your patch causes this: -arg1 = 0 -(gdb) PASS: gdb.opt/inline-locals.exp: info args above bar (2) +arg1 = value optimized out +(gdb) FAIL: gdb.opt/inline-locals.exp: info args above bar (2) Despite the appearance, this is good. The previous result was luck, a DW_AT_location in the out-of-line instance that used the same register as in the inlined instance. I hope VTA will fix this failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40573
[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 debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #4 from drow at gcc dot gnu dot org 2009-06-23 12:24 --- Subject: Re: [4.4/4.5 Regression] -g causes GCC to generate .eh_frame On Tue, Jun 23, 2009 at 11:09:48AM -, jakub at gcc dot gnu dot org wrote: I think if we don't want to emit .eh_frame, we should just default to -fno-dwarf2-cfi-asm. But if we do want to generate it, I fail to see what do we gain by also generating .debug_frame. Duplicating the same info, in one case in a more compat form, doesn't look like a good idea. That sounds reasonable. At one point there was a proposal to emit completely accurate unwind information for .debug_frame, and skip some prologue/epilogue information in .eh_frame; if we do that, obviously we need both sets of output, but otherwise we don't. We should make this be consistent though, not depend on -fno-dwarf2-cfi-asm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug rtl-optimization/9702] [ARM] Constant pools are not shared among functions
--- Comment #7 from drow at gcc dot gnu dot org 2009-06-23 15:49 --- Nope. It would be somewhere between hard and impossible to do in the linker, because these have to go in the middle of the .text section, and within compile-time known offsets from the using functions (to accommodate limited range pc-relative displacements). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9702
[Bug debug/40521] New: [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
Put this in main.c and build it with a 4.4-branch compiler using recent
binutils:
int main ()
{
return 0;
}
Versions:
GNU assembler (GNU Binutils) 2.19.51.20090611
i686-pc-linux-gnu-gcc (GCC) 4.4.1 20090611 (prerelease)
% i686-pc-linux-gnu-gcc -c main.c; objdump --wide -h main.o | grep ALLOC
0 .text 000a 0034 2**2 CONTENTS,
ALLOC, LOAD, READONLY, CODE
1 .data 0040 2**2 CONTENTS,
ALLOC, LOAD, DATA
2 .bss 0040 2**2 ALLOC
% i686-pc-linux-gnu-gcc -c -g main.c; objdump --wide -h main.o | grep ALLOC
0 .text 000a 0034 2**2 CONTENTS,
ALLOC, LOAD, READONLY, CODE
1 .data 0040 2**2 CONTENTS,
ALLOC, LOAD, DATA
2 .bss 0040 2**2 ALLOC
12 .eh_frame 0034 01c0 2**2 CONTENTS,
ALLOC, LOAD, RELOC, READONLY, DATA
We're using GAS's .cfi_startproc et cetera directives to generate debug
information. But they only generate .eh_frame, not .debug_frame.
I also noticed this problem on an ARM EABI target. ARM EABI does not use
.eh_frame, only .debug_frame and .ARM.exidx.
The easiest fix is to disable use of the CFI directives when we are trying to
generate .debug_frame. I believe GCC used to generate both .debug_frame and
.eh_frame for the same function. If we want both to gain the advantages of
using CFI directives (e.g. potentially accurate across inline asm), then we
need to teach gas to emit .debug_frame/.eh_frame/both as requested.
--
Summary: [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #1 from drow at gcc dot gnu dot org 2009-06-22 15:20 --- CC'ing some people who know about CFI for opinions on the best resolution. Do we need a new gas option and/or CFI directive for this? -- drow at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org, ||aoliva at gcc dot gnu dot ||org, jakub at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #2 from drow at gcc dot gnu dot org 2009-06-22 15:22 --- I've confirmed that older GCC emits both .debug_frame and .eh_frame. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug fortran/36031] ARM -fshort-enums attribute not emitted for Fortran
--- Comment #5 from drow at gcc dot gnu dot org 2009-05-16 17:31 --- Subject: Re: ARM -fshort-enums attribute not emitted for Fortran On Sat, May 16, 2009 at 04:12:28PM -, fxcoudert at gcc dot gnu dot org wrote: Probably fixed on trunk. Please reopen if not. Thanks! I forgot to leave a note on how I encountered this, and I don't remember :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36031
[Bug target/35296] init_expr_once suboptimal for Thumb
--- Comment #2 from drow at gcc dot gnu dot org 2009-05-12 11:36 --- Sorry, I don't know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35296
[Bug bootstrap/21751] [csl-arm-branch and HEAD] fails to bootstrap with EABI
--- Comment #7 from drow at gcc dot gnu dot org 2009-04-29 16:40 --- GLIBC patches are no longer required and I know folks have built iwmmxt-targeted ARM Linux toolchains since this was filed. -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21751
[Bug rtl-optimization/34263] missed optimization: cleanup loop latch (SMS)
--- Comment #2 from drow at gcc dot gnu dot org 2009-04-04 18:41 --- If a patch was committed, can this bug be closed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34263
[Bug target/14202] [arm] Thumb __builtin_setjmp not interworking safe
--- Comment #10 from drow at gcc dot gnu dot org 2009-01-05 18:34 --- Right. You would need an arm-elf (not arm-eabi) or arm-linux (not arm-linux-gnueabi) toolchain to test this. Those are slowly becoming obsolete... -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2005-07-02 01:31:50 |2009-01-05 18:34:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14202
[Bug debug/7081] DWARF enhancements for C++
--- Comment #14 from drow at gcc dot gnu dot org 2008-12-22 13:46 --- Part fixed, part refiled. -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7081
[Bug debug/36748] scev const-prop pass adds bad line numbers
--- Comment #3 from drow at gcc dot gnu dot org 2008-12-06 15:18 --- I tried 4.4.0 20081130; it does not look fixed. bb 8: # mult_acc.14_40 = PHI mult_acc.14_17(6) [break.c : 12] D.2737_41 = value_13 + -1; [break.c : 12] D.2738_42 = (unsigned int) D.2674_12; [break.c : 12] D.2739_43 = 2 - D.2738_42; [break.c : 12] D.2740_44 = (int) D.2739_43; value_39 = D.2737_41 + D.2740_44; There are no references to code on line 13 or 25, which are the opening braces. But those lines are now associated with line 12 and 24, which are the declarations of main and factorial respectively. The references are still introduced by scev. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36748
[Bug debug/36748] scev const-prop pass adds bad line numbers
-- drow at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-06 15:19:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36748
[Bug bootstrap/38014] [4.4 Regression] in-tree gmp and mpfr libraries no longer work
--- Comment #4 from drow at gcc dot gnu dot org 2008-11-14 14:53 --- Subject: Bug 38014 Author: drow Date: Fri Nov 14 14:51:38 2008 New Revision: 141859 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141859 Log: PR bootstrap/38014 PR bootstrap/37923 Revert: 2008-10-24 Daniel Jacobowitz [EMAIL PROTECTED] * Makefile.tpl (HOST_EXPORTS): Correct CPPFLAGS typo. * Makefile.in: Regenerated. 2008-10-22 Daniel Jacobowitz [EMAIL PROTECTED] * Makefile.def (flags_to_pass): Add CPPFLAGS_FOR_BUILD and CPPFLAGS. * Makefile.tpl (BUILD_EXPORTS): Set CPPFLAGS. (EXTRA_BUILD_FLAGS): Correct typo. Pass CPPFLAGS. (HOST_EXPORTS): Pass CPPFLAGS. (CPPFLAGS_FOR_BUILD, CPPFLAGS, CPPFLAGS_FOR_TARGET): Define. (LDFLAGS_FOR_TARGET): Initialize from configure script. (EXTRA_TARGET_FLAGS): Set CPPFLAGS. * Makefile.in, configure: Regenerated. * configure.ac: Set CPPFLAGS_FOR_TARGET, LDFLAGS_FOR_TARGET, and CPPFLAGS_FOR_BUILD. Modified: trunk/ChangeLog trunk/Makefile.def trunk/Makefile.in trunk/Makefile.tpl trunk/configure trunk/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38014
[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.
--- Comment #34 from drow at gcc dot gnu dot org 2008-11-14 14:53 --- Subject: Bug 37923 Author: drow Date: Fri Nov 14 14:51:38 2008 New Revision: 141859 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141859 Log: PR bootstrap/38014 PR bootstrap/37923 Revert: 2008-10-24 Daniel Jacobowitz [EMAIL PROTECTED] * Makefile.tpl (HOST_EXPORTS): Correct CPPFLAGS typo. * Makefile.in: Regenerated. 2008-10-22 Daniel Jacobowitz [EMAIL PROTECTED] * Makefile.def (flags_to_pass): Add CPPFLAGS_FOR_BUILD and CPPFLAGS. * Makefile.tpl (BUILD_EXPORTS): Set CPPFLAGS. (EXTRA_BUILD_FLAGS): Correct typo. Pass CPPFLAGS. (HOST_EXPORTS): Pass CPPFLAGS. (CPPFLAGS_FOR_BUILD, CPPFLAGS, CPPFLAGS_FOR_TARGET): Define. (LDFLAGS_FOR_TARGET): Initialize from configure script. (EXTRA_TARGET_FLAGS): Set CPPFLAGS. * Makefile.in, configure: Regenerated. * configure.ac: Set CPPFLAGS_FOR_TARGET, LDFLAGS_FOR_TARGET, and CPPFLAGS_FOR_BUILD. Modified: trunk/ChangeLog trunk/Makefile.def trunk/Makefile.in trunk/Makefile.tpl trunk/configure trunk/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37923
[Bug bootstrap/38014] [4.4 Regression] in-tree gmp and mpfr libraries no longer work
--- Comment #5 from drow at gcc dot gnu dot org 2008-11-14 15:37 --- Patches reverted. This is really a bug in gmp/mpfr/intl, but no point triggering it. -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38014
[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.
--- Comment #35 from drow at gcc dot gnu dot org 2008-11-14 15:38 --- Patches reverted. This is really a bug in gmp/mpfr/intl, but no point triggering it. -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37923
[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.
--- Comment #17 from drow at gcc dot gnu dot org 2008-10-27 13:55 ---
Subject: Re: [4.4 Regression] CPPFLAGS now unset for
stage 1 build of libcpp files.
On Mon, Oct 27, 2008 at 03:37:27AM -, howarth at nitro dot med dot uc dot
edu wrote:
already. I think the issue is that while both libcpp/configure of 20081016 and
20081026 are
properly setting CPPFLAGS in the libcpp/Makefile
No they're not. Again, what is setting CPPFLAGS in libcpp? The
project is supposed to build correctly with user specified CPPFLAGS,
just like CFLAGS.
A number of macros in config/ set CPPFLAGS=. My guess is that the
path you want is coming from one of those, and they should be setting
some other variable. E.g.
dnl Sets and AC_SUBSTs the LIB${NAME} and LTLIB${NAME} variables and
dnl augments the CPPFLAGS variable.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37923
[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.
--- Comment #19 from drow at gcc dot gnu dot org 2008-10-27 14:13 --- It won't be logged. Paolo, any comment on the CPPFLAGS problem from comment 17? I want the top level CPPFLAGS passed down, because that's how users can add additional -I arguments. But it seems typical to do CPPFLAGS = foo @CPPFLAGS@ in subdirectories, or put foo in @CPPFLAGS@ in the subdirectory configure script, which loses foo now. -- drow at gcc dot gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37923
[Bug bootstrap/37923] [4.4 Regression] CPPFLAGS now unset for stage 1 build of libcpp files.
--- Comment #10 from drow at gcc dot gnu dot org 2008-10-27 02:45 --- Do you have: 2008-10-24 Daniel Jacobowitz [EMAIL PROTECTED] * Makefile.tpl (HOST_EXPORTS): Correct CPPFLAGS typo. * Makefile.in: Regenerated. What was previously setting CPPFLAGS? I don't see anything in your command line that would. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37923
[Bug rtl-optimization/2175] fold in fold_const.c associates non-multiply expressions
--- Comment #3 from drow at gcc dot gnu dot org 2008-10-22 13:31 --- Subject: Bug 2175 Author: drow Date: Wed Oct 22 13:30:19 2008 New Revision: 141292 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141292 Log: ./ PR gdb/921 PR gdb/1646 PR gdb/2175 PR gdb/2176 * Makefile.def (flags_to_pass): Add CPPFLAGS_FOR_BUILD and CPPFLAGS. * Makefile.tpl (BUILD_EXPORTS): Set CPPFLAGS. (EXTRA_BUILD_FLAGS): Correct typo. Pass CPPFLAGS. (HOST_EXPORTS): Pass CPPFLAGS. (CPPFLAGS_FOR_BUILD, CPPFLAGS, CPPFLAGS_FOR_TARGET): Define. (LDFLAGS_FOR_TARGET): Initialize from configure script. (EXTRA_TARGET_FLAGS): Set CPPFLAGS. * Makefile.in, configure: Regenerated. * configure.ac: Set CPPFLAGS_FOR_TARGET, LDFLAGS_FOR_TARGET, and CPPFLAGS_FOR_BUILD. libiberty/ * Makefile.in (CPPFLAGS): Define. (FLAGS_TO_PASS, COMPILE.c): Add CPPFLAGS. Modified: trunk/ChangeLog trunk/Makefile.def trunk/Makefile.in trunk/Makefile.tpl trunk/configure trunk/configure.ac trunk/libiberty/ChangeLog trunk/libiberty/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2175
[Bug c++/921] 2.95.2 generates incorrect ref to static initialized char[] in classes. 2.8.1 works fine
--- Comment #4 from drow at gcc dot gnu dot org 2008-10-22 13:31 --- Subject: Bug 921 Author: drow Date: Wed Oct 22 13:30:19 2008 New Revision: 141292 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141292 Log: ./ PR gdb/921 PR gdb/1646 PR gdb/2175 PR gdb/2176 * Makefile.def (flags_to_pass): Add CPPFLAGS_FOR_BUILD and CPPFLAGS. * Makefile.tpl (BUILD_EXPORTS): Set CPPFLAGS. (EXTRA_BUILD_FLAGS): Correct typo. Pass CPPFLAGS. (HOST_EXPORTS): Pass CPPFLAGS. (CPPFLAGS_FOR_BUILD, CPPFLAGS, CPPFLAGS_FOR_TARGET): Define. (LDFLAGS_FOR_TARGET): Initialize from configure script. (EXTRA_TARGET_FLAGS): Set CPPFLAGS. * Makefile.in, configure: Regenerated. * configure.ac: Set CPPFLAGS_FOR_TARGET, LDFLAGS_FOR_TARGET, and CPPFLAGS_FOR_BUILD. libiberty/ * Makefile.in (CPPFLAGS): Define. (FLAGS_TO_PASS, COMPILE.c): Add CPPFLAGS. Modified: trunk/ChangeLog trunk/Makefile.def trunk/Makefile.in trunk/Makefile.tpl trunk/configure trunk/configure.ac trunk/libiberty/ChangeLog trunk/libiberty/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=921
[Bug other/2176] Printing unsigned long int with int format in dwarf2out.c
--- Comment #4 from drow at gcc dot gnu dot org 2008-10-22 13:31 --- Subject: Bug 2176 Author: drow Date: Wed Oct 22 13:30:19 2008 New Revision: 141292 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141292 Log: ./ PR gdb/921 PR gdb/1646 PR gdb/2175 PR gdb/2176 * Makefile.def (flags_to_pass): Add CPPFLAGS_FOR_BUILD and CPPFLAGS. * Makefile.tpl (BUILD_EXPORTS): Set CPPFLAGS. (EXTRA_BUILD_FLAGS): Correct typo. Pass CPPFLAGS. (HOST_EXPORTS): Pass CPPFLAGS. (CPPFLAGS_FOR_BUILD, CPPFLAGS, CPPFLAGS_FOR_TARGET): Define. (LDFLAGS_FOR_TARGET): Initialize from configure script. (EXTRA_TARGET_FLAGS): Set CPPFLAGS. * Makefile.in, configure: Regenerated. * configure.ac: Set CPPFLAGS_FOR_TARGET, LDFLAGS_FOR_TARGET, and CPPFLAGS_FOR_BUILD. libiberty/ * Makefile.in (CPPFLAGS): Define. (FLAGS_TO_PASS, COMPILE.c): Add CPPFLAGS. Modified: trunk/ChangeLog trunk/Makefile.def trunk/Makefile.in trunk/Makefile.tpl trunk/configure trunk/configure.ac trunk/libiberty/ChangeLog trunk/libiberty/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2176
[Bug web/1646] The GNATS query filters do not work correctly
--- Comment #8 from drow at gcc dot gnu dot org 2008-10-22 13:31 --- Subject: Bug 1646 Author: drow Date: Wed Oct 22 13:30:19 2008 New Revision: 141292 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141292 Log: ./ PR gdb/921 PR gdb/1646 PR gdb/2175 PR gdb/2176 * Makefile.def (flags_to_pass): Add CPPFLAGS_FOR_BUILD and CPPFLAGS. * Makefile.tpl (BUILD_EXPORTS): Set CPPFLAGS. (EXTRA_BUILD_FLAGS): Correct typo. Pass CPPFLAGS. (HOST_EXPORTS): Pass CPPFLAGS. (CPPFLAGS_FOR_BUILD, CPPFLAGS, CPPFLAGS_FOR_TARGET): Define. (LDFLAGS_FOR_TARGET): Initialize from configure script. (EXTRA_TARGET_FLAGS): Set CPPFLAGS. * Makefile.in, configure: Regenerated. * configure.ac: Set CPPFLAGS_FOR_TARGET, LDFLAGS_FOR_TARGET, and CPPFLAGS_FOR_BUILD. libiberty/ * Makefile.in (CPPFLAGS): Define. (FLAGS_TO_PASS, COMPILE.c): Add CPPFLAGS. Modified: trunk/ChangeLog trunk/Makefile.def trunk/Makefile.in trunk/Makefile.tpl trunk/configure trunk/configure.ac trunk/libiberty/ChangeLog trunk/libiberty/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1646
[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*
--- Comment #8 from drow at gcc dot gnu dot org 2008-10-22 15:48 --- Subject: Re: [4.4 Regression] Small structs are not passed correctly on hppa64-*-* On Wed, Oct 22, 2008 at 03:37:09PM -, jakub at gcc dot gnu dot org wrote: Was the I am reasonably sure it will only affect only E500 comment in http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00255.html meant for this patch or the other one? Clearly it makes a big difference. It was meant for this patch; for the other, I was absolutely sure. Your explanation makes sense to me. I have the same questions you do, too; I got completely lost in the different modes/types being dealt with here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37316
[Bug debug/28064] .debug_str is used only when optimizing
--- Comment #3 from drow at gcc dot gnu dot org 2008-10-15 18:57 --- Then let's forget about the -fmerge-constants question and mark this fixed. -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28064
[Bug bootstrap/37086] [4.4 Regression] GCC 3.4 miscompiles trunk (for cross compiling)
--- Comment #15 from drow at gcc dot gnu dot org 2008-09-12 12:43 --- Reopening... -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37086
[Bug bootstrap/37086] [4.4 Regression] GCC 3.4 miscompiles trunk (for cross compiling)
--- Comment #16 from drow at gcc dot gnu dot org 2008-09-12 12:43 --- Fixed. -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37086
[Bug c/37428] New: GNU VLA-in-structure extension is undocumented
This is a GNU extension to C99:
void foo(int n)
{
struct S { int x[n]; };
}
It is not mentioned in the C Extensions section of the manual.
--
Summary: GNU VLA-in-structure extension is undocumented
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
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=37428
[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*
--- Comment #5 from drow at gcc dot gnu dot org 2008-09-09 03:16 --- That patch isn't supposed to make any difference, because of when the parallel is removed - it's not supposed to be early enough to affect where things are passed. It just happens within the function. Unfortunately I'm not going to have a chance to look at this for a while :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37316
[Bug debug/37237] New: Debug information for virtual destructors omits DW_AT_vtable_elem_location
Compile a C++ file containing a class with a virtual destructor. Example from
gdb's class2.cc test:
struct A
{
virtual ~A ();
int a1;
};
A::~A()
{
a1 = 800;
}
From the DWARF:
2270: Abbrev Number: 10 (DW_TAG_subprogram)
271 DW_AT_external: 1
272 DW_AT_name: ~A
275 DW_AT_decl_file : 1
276 DW_AT_decl_line : 25
277 DW_AT_virtuality : 1 (virtual)
278 DW_AT_containing_type: 221
27c DW_AT_declaration : 1
There's a DIE for the member function definition which refers to this
(DW_AT_specification), too. But neither of them has
DW_AT_vtable_elem_location; this is not optional for virtual methods.
I assume this is related to the fact that the destructor is cloned (whole
object and partial object). That's why it doesn't get a
DW_AT_MIPS_linkage_name. I believe there are two vtable slots for the two
clones; the most practical thing would be to describe the whole-object version
in the DWARF since that's what a debugger will be looking up.
I can't think of a better way to handle this; maybe someone else can.
--
Summary: Debug information for virtual destructors omits
DW_AT_vtable_elem_location
Product: gcc
Version: 4.4.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=37237
[Bug fortran/29635] debug info of modules
--- Comment #9 from drow at gcc dot gnu dot org 2008-08-18 12:38 --- Interesting, I didn't know this was for the benefit of some debugger. I don't think GDB has needed it in several years. If things work with GDB 6.8 and without these DIEs, I think it's safe to combine the declaration and the reference to it. (It's not right to call a DIE with DW_AT_specification a specification; the target of the attribute is the specification.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29635
[Bug bootstrap/37086] Cross-compilers built with GCC 3.4 do not work
--- Comment #4 from drow at gcc dot gnu dot org 2008-08-12 11:55 --- In the past, we've worked around bugs like this in widely used compilers - they make life difficult. Obviously it depends how nasty a workaround is found! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37086
[Bug bootstrap/37086] New: Cross-compilers built with GCC 3.4 do not work
Building libgcc, I get:
/scratch/dan/mips-nonpic-upstream/src/gcc-mainline/libgcc/../gcc/unwind-pe.h:
In function 'size_of_encoded_value':
/scratch/dan/mips-nonpic-upstream/src/gcc-mainline/libgcc/../gcc/unwind-pe.h:78:
internal compiler error: tree check: accessed elt 7 of tree_vec with 5 elts in
find_switch_asserts, at tree-vrp.c:4346
/scratch/dan/mips-nonpic-upstream/src/gcc-mainline/libgcc/../gcc/unwind-dw2.c:1257:
internal compiler error: tree check: accessed elt 9 of tree_vec with 7 elts in
find_switch_asserts, at tree-vrp.c:4346
If I recompile tree-vrp.o with -O0, then libgcc compiles OK.
Joseph suggests this came in at the time of the tuples merge. If possible, it
would be nice if we could avoid the problematic construct...
The code in question is:
/* If there are multiple case labels with the same destination
we need to combine them to a single value range for the edge. */
if (idx + 1 n
CASE_LABEL (cl) == CASE_LABEL (TREE_VEC_ELT (vec2, idx + 1)))
{
/* Skip labels until the last of the group. */
do {
++idx;
} while (idx n
CASE_LABEL (cl) == CASE_LABEL (TREE_VEC_ELT (vec2,
idx)));
--idx;
When we reach the outer if, idx == 3 and n == 5. We go around twice, but idx
goes up to 7.
It looks like a loop optimization issue:
0x84fa0fd find_switch_asserts+1309: lea0x2(%edi),%esi
0x84fa100 find_switch_asserts+1312: mov-0x40(%ebp),%edi
0x84fa103 find_switch_asserts+1315: cmp-0x3c(%ebp),%edi
0x84fa106 find_switch_asserts+1318: mov%esi,-0x40(%ebp)
0x84fa109 find_switch_asserts+1321: jb 0x84fa080
find_switch_asserts+1184
0x84fa10f find_switch_asserts+1327: mov-0x38(%ebp),%ecx
0x84fa112 find_switch_asserts+1330: dec%esi
0x84fa113 find_switch_asserts+1331: mov%esi,-0x40(%ebp)
-0x40(%ebp) is idx, and idx+1 is in %edi before the above code.
--
Summary: Cross-compilers built with GCC 3.4 do not work
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37086
[Bug tree-optimization/36861] [4.3 Regression] boost's compressed avl confuses GCC
--- Comment #18 from drow at gcc dot gnu dot org 2008-07-24 22:18 --- Putting the regression marker back. The code doesn't matter; if it's a regression, then it's regression. -- drow at gcc dot gnu dot org changed: What|Removed |Added Summary|boost's compressed avl |[4.3 Regression] boost's |confuses GCC|compressed avl confuses GCC http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36861
[Bug target/36701] [4.4 Regression] unaligned access in gcc.c-torture/execute/complex-7.c
--- Comment #10 from drow at gcc dot gnu dot org 2008-07-08 20:26 --- Subject: Re: [4.4 Regression] unaligned access in gcc.c-torture/execute/complex-7.c It sounds plausible but I suggest you ask on gcc-patches, I can't review that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36701
[Bug debug/36748] New: scev const-prop pass adds bad line numbers
I'm testing inlined function support for GCC. When I compile the attached testcase with GCC (Debian's 4.3 package or unmodified trunk) and -g -O2, break main in the patched GDB puts a breakpoint at the start of main and again inside the inlined copy of factorial. This happens because there are several bits of code associated with the line containing main's opening brace. The bad line numbers are introduced by pass_scev_cprop (why is this dumped into sccp; having a dump named sccp shortly after one named store_ccp is confusing). Here's the relevant piece of the diff between 096t.lim and 099t.sccp: @@ -88,7 +100,11 @@ bb 8: # mult_acc.12_13 = PHI mult_acc.12_15(6) - # value_16 = PHI value_14(6) + [../break.c : 13] D.2700_29 = value_11 + -1; + [../break.c : 13] D.2701_7 = (unsigned int) D.2633_10; + [../break.c : 13] D.2702_30 = 2 - D.2701_7; + [../break.c : 13] D.2703_31 = (int) D.2702_30; + value_16 = D.2700_29 + D.2703_31; bb 9: # mult_acc.12_19 = PHI mult_acc.12_13(8), 1(4) There are no other lines associated with break.c:13 in the dump at this point. The location came from internal_get_tmp_var. 644 if (EXPR_HAS_LOCATION (val)) 645 SET_EXPR_LOCUS (mod, EXPR_LOCUS (val)); 646 else 647 SET_EXPR_LOCATION (mod, input_location); input_location has nothing to do with anything at this point. -- Summary: scev const-prop pass adds bad line numbers Product: gcc Version: 4.4.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 GCC host triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36748
[Bug debug/36748] scev const-prop pass adds bad line numbers
--- Comment #1 from drow at gcc dot gnu dot org 2008-07-07 13:56 --- Created an attachment (id=15869) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15869action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36748
[Bug target/36701] [4.4 Regression] unaligned access in gcc.c-torture/execute/complex-7.c
--- Comment #7 from drow at gcc dot gnu dot org 2008-07-07 22:31 --- Subject: Re: [4.4 Regression] unaligned access in gcc.c-torture/execute/complex-7.c On Mon, Jul 07, 2008 at 10:25:08PM -, hjl dot tools at gmail dot com wrote: is incorrect for ia64 HFA. You can't do rtx parmreg = gen_reg_rtx (GET_MODE (entry_parm)); when entry_parm is HFA passed in GR: What does HFA mean? Why can't you copy it into a reg:SC? This shouldn't change the incoming location of the argument; it's generating code at the start of the function to retrieve the argument. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36701
[Bug target/36701] [4.4 Regression] unaligned access in gcc.c-torture/execute/complex-7.c
--- Comment #3 from drow at gcc dot gnu dot org 2008-07-04 03:14 --- Does the new function do anything on this test case? What are the various incoming modes (nominal, promoted) and the actual RTX? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36701
[Bug bootstrap/34257] --with-sysroot does not change default linux glibc dynamic-linker path
--- Comment #4 from drow at gcc dot gnu dot org 2008-05-14 13:47 --- I agree that a new option would be useful. Something like --target-sysroot to go parallel to --sysroot, with an optional value or a special value same or some other way to avoid duplicating the path on the command line. In general you need both -dynamic-linker and -rpath. -- drow 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=34257
[Bug target/36031] New: ARM -fshort-enums attribute not emitted for Fortran
The -fshort-enums option emits a note in the object file that the linker can use to detect mismatches. It does not work for Fortran; the int-sized enums attribute is emitted with or without -fshort-enums. -- Summary: ARM -fshort-enums attribute not emitted for Fortran Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drow at gcc dot gnu dot org GCC target triplet: arm-none-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36031
[Bug debug/35615] Debug information for .debug_loc section incorrect
--- Comment #13 from drow at gcc dot gnu dot org 2008-03-21 19:30 --- Closing, then. -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35615
[Bug target/35296] New: init_expr_once suboptimal for Thumb
init_expr_once sets direct_load and direct_store arrays, which are indexed by mode. These are supposed to indicate can we load a value of this mode from memory and similar for store. It does this by passing a bunch of (set (reg) (mem)) instructions to recog. At the top of the function: /* Try indexing by frame ptr and try by stack ptr. It is known that on the Convex the stack ptr isn't a valid index. With luck, one or the other is valid on any machine. */ mem = gen_rtx_MEM (VOIDmode, stack_pointer_rtx); mem1 = gen_rtx_MEM (VOIDmode, frame_pointer_rtx); That's actually base, not index, in current GCC parlance. And the assumption isn't true for Thumb. You can load SImode using [sp], but not QImode. And frame_pointer_rtx is a pseudo that isn't valid to index off of anyway. The hard frame pointer is r7 for Thumb, and that would be a valid index. Possibilities: also check hard_frame_pointer_rtx, also check a target-specified register, find a valid register for each mode using ok_for_base_1. The last seems best except it would be the earliest call to REGNO_OK_FOR_BASE_P et cetera in the compiler. The ARM version will crash if reg_renumber isn't allocated. This isn't a big problem because we'll go on to handle QImode loads as bitfield accesses and bitfield optimizations will more or less sort things out. Fixing it might enable some other RTL optimizations though. -- Summary: init_expr_once suboptimal for Thumb Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drow at gcc dot gnu dot org GCC target triplet: arm*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35296
[Bug driver/35300] References to original ${prefix} paths in relocated toolchain and /lib and /usr/lib search paths appear in cross toolchain.
--- Comment #4 from drow at gcc dot gnu dot org 2008-02-23 04:38 --- It's found through multilib os-directory suffixes. How did you configure GCC? The standard_exec_prefix_1, et cetera patch is not necessary on HEAD and will conflict. In fact that's another of Carlos's patches. I don't know about the update_path patch, but CodeSourcery's been building relocatable sysrooted compilers since before 4.1.1 and never encountered this problem. I think we avoid the code in prefix.c entirely. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35300
[Bug target/35071] bad instruction `do_itt eq'
--- Comment #5 from drow at gcc dot gnu dot org 2008-02-14 16:11 --- Looks like it should be do_it eq, t. Each additional t or e predicates one more instruction. The mvfeqd has to be predicated and so does the RETc(eq). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35071
[Bug target/34526] no-altivec ABI should be fixed or no longer be the default
--- Comment #11 from drow at gcc dot gnu dot org 2008-02-14 16:31 --- Might want to try at least one SPE target, for completeness. I think powerpc-*-eabispe is sim testable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34526
[Bug target/34526] no-altivec ABI should be fixed or no longer be the default
--- Comment #7 from drow at gcc dot gnu dot org 2008-02-05 03:19 --- Subject: Re: no-altivec ABI should be fixed or no longer be the default On Tue, Feb 05, 2008 at 02:23:20AM -, janis at gcc dot gnu dot org wrote: There's another mess hiding under the ABI change, which is that synthetic vectors of the same size as AltiVec vectors are passed differently for -mabi=altivec than for -mabi=no-altivec. FYI, this is target/33899. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34526
[Bug bootstrap/32287] gas version style changed causes warnings with configure
--- Comment #14 from drow at gcc dot gnu dot org 2008-01-22 13:30 --- Subject: Re: gas version style changed causes warnings with configure Thanks, H.J.! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32287
[Bug bootstrap/32287] gas version style changed causes warnings with configure
--- Comment #9 from drow at gcc dot gnu dot org 2008-01-21 20:41 --- Here's why I didn't remember the patch - I just checked it in, I didn't write it. 2007-08-23 Brian Sidebotham [EMAIL PROTECTED] * configure.ac (leb128): Modify sed statement to work with any binutils version string. * configure: Regenerate That version definitely handles: as_ver='GNU assembler (GNU Binutils for Debian) 2.18.20071027' It does not handle: as_ver='GNU assembler (Linux/GNU Binutils) 2.18.50.0.3.20071102' This version format is new and is not produced by the FSF binutils. I assume it's a result of HJ Lu's Linux binutils after a merge from FSF trunk. The ld_vers check up higher in the file was changed to handle the new version format on 2007-09-23. HJ, Richi, I can find a lot of confused versions of HJ's patch in that thread, which starts here: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01170.html Nowhere can I find the actual approval. The only version which was approved was safe, but the patch as applied is unsafe. If you put a .* there, then it will match any xx.yy string anywhere in the version string, including after the binutils version! This does not mess up on --with-pkgversion on new versions of binutils but only because sed will use the shorter match, and the binutils version comes second. + -e 's,^.*[ ]\([0-9][0-9]*\.[0-9][0-9]*.*\)$,\1,p' \ -e 's,^.*[ ]\([0-9][0-9]*\.[0-9][0-9]*\)[ ].*$,\1,p' \ Note that second line will never match now. The ld and as tests should be made uniform again but I think that we should go back to this one: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01170.html -- drow at gcc dot gnu dot org changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com, rguenther at suse dot ||de, bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32287
[Bug debug/23336] [4.0/4.1 Regression] enum constants not visible to gdb because of -feliminate-unused-debug-types
--- Comment #12 from drow at gcc dot gnu dot org 2008-01-21 20:59 --- I don't care about 4.0/4.1 at this date. -- drow at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|drow at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23336
[Bug debug/27473] [4.0/4.1 Regression] g++.dg/other/unused1.C and gcc.dg/20060410.c fail on powerpc-darwin
--- Comment #5 from drow at gcc dot gnu dot org 2008-01-21 21:00 --- I don't care about 4.0/4.1 at this date. -- drow at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|drow at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27473
[Bug c++/28460] [4.0/4.1 Regression] g++ emits bogus namespace DIE
--- Comment #16 from drow at gcc dot gnu dot org 2008-01-21 21:00 --- I don't care about 4.0/4.1 at this date. -- drow at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|drow at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28460
[Bug bootstrap/32287] gas version style changed causes warnings with configure
--- Comment #11 from drow at gcc dot gnu dot org 2008-01-21 21:46 --- Subject: Re: gas version style changed causes warnings with configure On Mon, Jan 21, 2008 at 09:43:09PM -, hjl dot tools at gmail dot com wrote: The second line isn't needed. I checked the following versions: ./check GNU ld version 2.17.50.0.6-5.fc6 20061020 ./check GNU ld version 2.17.50.0.12-4 20070128 ./check GNU ld version 2.15.92.0.2 20040927 ./check GNU ld (GNU Binutils) 2.18.50.20070913 ./check GNU ld (Linux/GNU Binutils) 2.18.50.0.1.20070906 ./check GNU ld (GNU Binutils) 2.17.50.20070726-12 (SUSE Linux) ./check GNU assembler (GNU Binutils for Debian) 2.17.50.20070426 and they work fine. Do you have more to add? It will fail on any line that contains xx.yy after the binutils version. Didn't that used to happen? If not we can remove basically the entire test. Once the first pattern matches the rest is mostly irrelevant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32287
[Bug bootstrap/34205] iwmmxt type/size error
--- Comment #5 from drow at gcc dot gnu dot org 2007-11-27 19:27 --- Probably. Why are you using the iwmmxt ABI? Don't. Just trust the AAPCS, it knows what's good for you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34205
[Bug bootstrap/34205] iwmmxt type/size error
--- Comment #2 from drow at gcc dot gnu dot org 2007-11-26 13:50 --- I don't know how you configured to get this. It looks like you've got -fshort-enums by default; GCC can not be built with that option (although it should be fixable). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34205
[Bug debug/33440] gcc-compiled program possibly reporting wrong variable address to gdb
--- Comment #2 from drow at gcc dot gnu dot org 2007-11-06 22:02 --- Works for me on Debian/unstable using GCC 4.2, GDB 6.7, so I expect this was a bug in Ubuntu's compiler version. -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33440
[Bug debug/33921] FAIL: gcc.dg/debug/debug-6.c -gdwarf-2 -O scan-assembler xyzzy
--- Comment #5 from drow at gcc dot gnu dot org 2007-11-03 17:50 --- Subject: Bug 33921 Author: drow Date: Sat Nov 3 17:50:20 2007 New Revision: 129872 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129872 Log: PR debug/33921 * reorg.c (emit_delay_sequence): Do not clear the locator on the jump instruction. Modified: trunk/gcc/ChangeLog trunk/gcc/reorg.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33921
[Bug debug/33921] FAIL: gcc.dg/debug/debug-6.c -gdwarf-2 -O scan-assembler xyzzy
--- Comment #6 from drow at gcc dot gnu dot org 2007-11-03 17:54 --- Checked in on trunk. -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33921
[Bug debug/33921] FAIL: gcc.dg/debug/debug-6.c -gdwarf-2 -O scan-assembler xyzzy
--- Comment #3 from drow at gcc dot gnu dot org 2007-10-27 16:39 --- All that patch does is change the line number associated with an instruction, i.e., .debug_line. xyzzy is supposed to appear in .debug_info, so I don't see how it could make a difference. That doesn't mean it doesn't, though. I'll build a cross-compiler and see. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33921
[Bug debug/33921] FAIL: gcc.dg/debug/debug-6.c -gdwarf-2 -O scan-assembler xyzzy
--- Comment #4 from drow at gcc dot gnu dot org 2007-10-27 17:42 --- Confirmed. Here the xyzzy and the call are in the same line. That means that previously the sequence got the right locator by accident, and the jump kept the right locator. Afterwards the sequence has the right locator and the jump has none. When reorder_blocks reconstructs block nesting from notes, it does not attach the subblock. That's because a NOTE_INSN_BLOCK_BEG is missing. reemit_insn_block_notes: /* For sequences compute scope resulting from merging all scopes of instructions nested inside. */ It ignores the locator on the sequence itself and selects one based on the block inside. I'm not sure that code makes any sense. Anyway, the easiest fix is to leave the locator on the jump alone. -- drow at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |drow at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-27 17:42:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33921
[Bug target/33899] New: -maltivec option changes ABI
rs6000_return_in_memory has: /* Allow -maltivec -mabi=no-altivec without warning. Altivec vector modes only exist for GCC vector types if -maltivec. */ if (TARGET_32BIT !TARGET_ALTIVEC_ABI ALTIVEC_VECTOR_MODE (TYPE_MODE (type))) return false; The code below warns for big vectors and returns true. That means a function returning __vector int does so in an AltiVec register with -mabi=altivec, in r3 r4 r5 r6 with -maltivec only, and in memory without -maltivec. This means GDB can not tell where the return value goes and whether a reference argument is necessary, even when it knows whether -mabi=altivec was used. This comes from here: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02035.html I read through that entire thread and I still don't understand the behavior. If __vector int should be returned in four GPRs for -maltivec -mabi=no-altivec, then shouldn't we return it in four GPRs for non-AltiVec configurations too? In my simpler world, every option either affects the ABI or does not, -mabi=altivec does, and -maltivec does not. -- Summary: -maltivec option changes ABI Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drow at gcc dot gnu dot org GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33899
[Bug debug/33861] New: Debugging info for C++ template parameters is incorrect
Compile this code, reduced from gdb.cp/templates.cc:
===
char name[3];
templatechar *V struct Qux
{
int foo();
};
templatechar *V int QuxV::foo()
{
return V[0];
}
Quxname qux;
===
Look at the resulting debug information, by building with -c -g and using
readelf -wi, or by compiling with -S -dA. Take a look at the type of the
instantiated foo. G++ calls it Qux(char*)( name)::foo(). But that's not
right.
For the first thing, I believe it's not valid C++. G++ certainly rejects the
obvious ways of writing this. But worse is that it is representable in the
mangling. The actual method:
_ZN3QuxIXadL_Z4nameEEE3fooEv - Qux(name)::foo()
But this is validly mangled:
_ZN3QuxIXcvPcadL_Z4nameEEE3fooEv - Qux(char*)((name))::foo()
There are tons of other places where GCC emits debug info different from the
demangler, usually in spacing or in the spelling of basic types (long unsigned
int vs unsigned long); I have code in GDB to correct for all such cosmetic
differences but I am reluctant to make it remove casts that could be important.
--
Summary: Debugging info for C++ template parameters is incorrect
Product: gcc
Version: 4.2.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=33861
[Bug debug/33861] Debugging info for C++ template parameters is incorrect
--- Comment #1 from drow at gcc dot gnu dot org 2007-10-22 14:13 --- Fixing bug 30161 might fix, or at least simplify, this too. But I suspect this name still shows up in error messages where it is suboptimal. -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-22 14:13:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33861
[Bug debug/33537] New: [4.0/4.1/4.2/4.3 regression] C++ arguments passed by invisible reference have wrong type
Compile the code below using g++ -g, load the object into gdb, and 'ptype foo'.
You will see that the type of foo is 'int (Obj )'. If this function is
called from GDB, and the called function modifies its argument, it will end up
modifying the original copy. It's supposed to get a temporary copy.
This changed sometime between g++ 3.3 and g++ 4.0.
class Obj {
public:
Obj ();
Obj (const Obj );
~Obj ();
int var[2];
};
int foo (Obj arg)
{
return arg.var[0] + arg.var[1];
}
int main() { return 0; }
Obj::Obj ()
{
var[0] = 1;
var[1] = 2;
}
Obj::Obj (const Obj obj)
{
var[0] = obj.var[0];
var[1] = obj.var[1];
}
Obj::~Obj ()
{
}
--
Summary: [4.0/4.1/4.2/4.3 regression] C++ arguments passed by
invisible reference have wrong type
Product: gcc
Version: 4.2.1
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=33537
[Bug debug/33537] [4.0/4.1/4.2/4.3 regression] C++ arguments passed by invisible reference have wrong type
--- Comment #2 from drow at gcc dot gnu dot org 2007-09-23 17:49 --- I got the correct result on amd64 with g++-3.3 (GCC) 3.3.6 (Debian 1:3.3.6-15). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33537
[Bug debug/33537] [4.0/4.1/4.2/4.3 regression] C++ arguments passed by invisible reference have wrong type
--- Comment #4 from drow at gcc dot gnu dot org 2007-09-23 18:40 --- Subject: Re: [4.0/4.1/4.2/4.3 regression] C++ arguments passed by invisible reference have wrong type On Sun, Sep 23, 2007 at 06:31:42PM -, pluto at agmk dot net wrote: If this function is called from GDB, and the called function modifies its argument, it will end up modifying the original copy. It's supposed to get a temporary copy. compiler does the temporary copy. please look at this example: That's why the bug report said from GDB. It's a debug info bug, not a C++ wrong-code bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33537
[Bug middle-end/31490] Compile error section type conflict
--- Comment #15 from drow at gcc dot gnu dot org 2007-08-31 17:42 --- Has Segher's patch been sent to gcc-patches? I've just encountered the ppc64 bootstrap failure too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31490
[Bug testsuite/31884] priority_queue_dijkstra.cc operates on deallocated memory
--- Comment #2 from drow at gcc dot gnu dot org 2007-08-17 17:24 --- Subject: Bug 31884 Author: drow Date: Fri Aug 17 17:24:22 2007 New Revision: 127590 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127590 Log: PR testsuite/31884 * testsuite/ext/pb_ds/example/priority_queue_dijkstra.cc (main): Do not access deleted nodes. * testsuite/25_algorithms/copy/streambuf_iterators/char/4.cc, testsuite/25_algorithms/find/istreambuf_iterators/char/2.cc, testsuite/27_io/basic_filebuf/open/char/4.cc, testsuite/27_io/objects/char/9.cc: Use dg-require-fileio. * testsuite/ext/forced_exception_error/cons_virtual_derivation.cc, testsuite/ext/pb_ds/regression/hash_data_map_rand.cc, testsuite/ext/pb_ds/regression/trie_data_map_rand.cc, testsuite/ext/pb_ds/regression/list_update_no_data_map_rand.cc, testsuite/ext/pb_ds/regression/tree_no_data_map_rand.cc, testsuite/ext/pb_ds/regression/list_update_data_map_rand.cc, testsuite/ext/pb_ds/regression/hash_no_data_map_rand.cc, testsuite/ext/pb_ds/regression/priority_queue_rand.cc, testsuite/ext/pb_ds/regression/tree_data_map_rand.cc, testsuite/ext/pb_ds/regression/trie_no_data_map_rand.cc, testsuite/ext/throw_allocator/deallocate_global.cc, testsuite/ext/throw_allocator/check_delete.cc, testsuite/ext/throw_allocator/check_allocate_max_size.cc, testsuite/ext/throw_allocator/check_deallocate_null.cc, testsuite/ext/throw_allocator/check_new.cc, testsuite/ext/throw_allocator/deallocate_local.cc, testsuite/tr1/5_numerical_facilities/random/subtract_with_carry_01/cons/gen1.cc, testsuite/tr1/5_numerical_facilities/random/subtract_with_carry/cons/gen1.cc, testsuite/tr1/5_numerical_facilities/random/linear_congruential/cons/gen1.cc, testsuite/tr1/5_numerical_facilities/random/mersenne_twister/cons/gen1.cc, testsuite/23_containers/list/modifiers/insert/25288.cc: Use dg-require-time. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/23_containers/list/modifiers/insert/25288.cc trunk/libstdc++-v3/testsuite/25_algorithms/copy/streambuf_iterators/char/4.cc trunk/libstdc++-v3/testsuite/25_algorithms/find/istreambuf_iterators/char/2.cc trunk/libstdc++-v3/testsuite/27_io/basic_filebuf/open/char/4.cc trunk/libstdc++-v3/testsuite/27_io/objects/char/9.cc trunk/libstdc++-v3/testsuite/ext/forced_exception_error/cons_virtual_derivation.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/example/priority_queue_dijkstra.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/hash_data_map_rand.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/hash_no_data_map_rand.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/list_update_data_map_rand.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/list_update_no_data_map_rand.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/priority_queue_rand.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/tree_data_map_rand.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/tree_no_data_map_rand.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/trie_data_map_rand.cc trunk/libstdc++-v3/testsuite/ext/pb_ds/regression/trie_no_data_map_rand.cc trunk/libstdc++-v3/testsuite/ext/throw_allocator/check_allocate_max_size.cc trunk/libstdc++-v3/testsuite/ext/throw_allocator/check_deallocate_null.cc trunk/libstdc++-v3/testsuite/ext/throw_allocator/check_delete.cc trunk/libstdc++-v3/testsuite/ext/throw_allocator/check_new.cc trunk/libstdc++-v3/testsuite/ext/throw_allocator/deallocate_global.cc trunk/libstdc++-v3/testsuite/ext/throw_allocator/deallocate_local.cc trunk/libstdc++-v3/testsuite/tr1/5_numerical_facilities/random/linear_congruential/cons/gen1.cc trunk/libstdc++-v3/testsuite/tr1/5_numerical_facilities/random/mersenne_twister/cons/gen1.cc trunk/libstdc++-v3/testsuite/tr1/5_numerical_facilities/random/subtract_with_carry/cons/gen1.cc trunk/libstdc++-v3/testsuite/tr1/5_numerical_facilities/random/subtract_with_carry_01/cons/gen1.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31884
[Bug debug/32990] [Regression] gdb has symbol table issues
--- Comment #8 from drow at gcc dot gnu dot org 2007-08-14 14:08 --- I don't think there's anything useful we can do with it without a testcase, unfortunately. -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32990
[Bug target/32130] [4.3 Regression] linking problems: multiple definition of `__DTOR_END__'
--- Comment #4 from drow at gcc dot gnu dot org 2007-08-14 16:02 --- I encountered this as a build failure for powerpc-eabispe in libstdc++-v3. -- drow at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org, drow at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-14 16:02:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32130
[Bug debug/32990] [Regression] gdb has symbol table issues
--- Comment #6 from drow at gcc dot gnu dot org 2007-08-13 20:29 --- Sorry, my mistake. I meant readelf -wi (lowercase I). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32990
[Bug testsuite/19232] Failure in gcc.dg/assign-warn-3.c on i686-pc-linux-gnu with -fpic/-fPIC
--- Comment #5 from drow at gcc dot gnu dot org 2007-08-02 21:59 --- Nathan Froyd checked in a patch for this. -- drow at gcc dot gnu dot org changed: What|Removed |Added CC||froydnj at gcc dot gnu dot ||org Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19232
[Bug tree-optimization/32919] [4.3 Regression] SSA corruption because of abnormal edges and PRE
--- Comment #4 from drow at gcc dot gnu dot org 2007-08-01 16:53 --- Subject: Bug 32919 Author: drow Date: Wed Aug 1 16:53:01 2007 New Revision: 127132 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127132 Log: PR tree-optimization/32919 * tree-ssa-sccvn.c (visit_phi): Do not visit abnormal PHIs. * tree-ssa-coalesce.c (ssa_conflicts_dump): New. (coalesce_ssa_name): Call it. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr32919.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-coalesce.c trunk/gcc/tree-ssa-sccvn.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32919
