[Bug c++/44186] Wrong code generated with -O2 and above
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-05-18 06:31 --- *** Bug 44187 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44186
[Bug c++/44187] Wrong code generated with -O2 and above
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-18 06:31 --- *** This bug has been marked as a duplicate of 44186 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44187
[Bug c/31367] Should not warn about use of deprecated type in deprecated struct
--- Comment #4 from ethouris at gmail dot com 2010-05-18 07:14 ---
No matter which entity is actually affected in the example above, 'foo' is a
type of field used inside the entity. In all these cases, deprecation warning
should not be reported for the field of type 'foo'. It should be reported only
when no part of the structure definition is deprecated.
The difference between deprecating only a typedef for a structure or the
structure itself, but not its typedef, should not be seen when it concerns one
integrated declaration (that is, when you deprecate any of these two, both
the typedef and the struct are deprecated). To only deprecate the typedef or
the struct, they should be declared separately - for example, bop4/bar4 should
be declared this way:
struct bar4
{
foo baz;
};
typedef struct bar4 bop4 __attribute__((deprecated));
So, in the examples for bop1-bop4, all of barN/bopN symbols should be
deprecation-attributed (and, simultaneously, in all these declarations the
deprecation warning should not be reported for 'baz' field declaration). For
this above declaration, the compiler should issue a warning about 'baz' field,
as the structure isn't deprecated and is using a deprecated type 'foo'; so
should be reported a warning about using struct bar4 (this structure is this
way implicitly deprecated) and bop4 (which is explicitly deprecated).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31367
[Bug middle-end/44185] [4.6 regression] New prefetch test failures
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-18 07:29 --- In general, with inlining, not a huge deal, although it can still occur when functons are short-circuited. For certain applicatons that are built with PIC, the IP-thunk, at the very least, should be padded since it's a guaranteed stall on every call. Help Dhrysyone -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44185
[Bug middle-end/44101] [4.6 regression] ICE compiling 25_algorithms/fill/4.cc on Tru64 UNIX V5.1B
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-05-18 07:41 --- I need the preprocessed file. Thanks in advance. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44101
[Bug lto/44184] asm goto does not work with LTO
-- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-18 08:10:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44184
[Bug rtl-optimization/44169] Wrong code while generating TLS offsets
--- Comment #4 from segher at gcc dot gnu dot org 2010-05-18 08:26 --- Confirmed with current 4.4 branch and mainline. -mabi=nospe -mno=spe doesn't make the problem go away; only changing -mcpu does. -- segher at gcc dot gnu dot org changed: What|Removed |Added CC||segher at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.4.4 4.6.0 Last reconfirmed|-00-00 00:00:00 |2010-05-18 08:26:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44169
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
--- Comment #17 from iains at gcc dot gnu dot org 2010-05-18 09:09 --- Created an attachment (id=20693) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20693action=view) latest version a few more tweaks. with this emutls is working for lto/whopr OMP is still broken and so will be tree-prof if it uses TLS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug c++/44186] Wrong code generated with -O2 and above
--- Comment #3 from paolo dot carlini at oracle dot com 2010-05-18 09:25 --- Note however, that both the warning and the miscompilation do not happen with current 4_5-branch and mainline... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44186
[Bug c++/44188] New: Fails to produce DW_AT_typedef for typedef of anonymous struct
typedef struct
{
int i;
} AAA;
typedef struct BBB
{
int i;
} BBB;
int main(void) {
BBB bb;
AAA aa;
return 0;
}
produces
3a2: Abbrev Number: 9 (DW_TAG_variable)
a3 DW_AT_name: bb
a6 DW_AT_decl_file : 1
a7 DW_AT_decl_line : 13
a8 DW_AT_type: 0x66
ac DW_AT_location: 2 byte block: 91 60 (DW_OP_fbreg: -32)
3af: Abbrev Number: 9 (DW_TAG_variable)
b0 DW_AT_name: aa
b3 DW_AT_decl_file : 1
b4 DW_AT_decl_line : 14
b5 DW_AT_type: 0x2d
b9 DW_AT_location: 2 byte block: 91 50
where
166: Abbrev Number: 6 (DW_TAG_typedef)
67 DW_AT_name: BBB
6b DW_AT_decl_file : 1
6c DW_AT_decl_line : 10
6d DW_AT_type: 0x4d
(good)
12d: Abbrev Number: 2 (DW_TAG_structure_type)
2e DW_AT_byte_size : 4
2f DW_AT_decl_file : 1
30 DW_AT_decl_line : 3
31 DW_AT_name: AAA
35 DW_AT_sibling : 0x46
(bad)
This seems to be because in gen_type_die_with_usage we arrive with a
type that has a non-typedef type-decl as its name.
--
Summary: Fails to produce DW_AT_typedef for typedef of anonymous
struct
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-debug
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44188
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #27 from jakub at gcc dot gnu dot org 2010-05-18 09:36 --- Subject: Bug 41371 Author: jakub Date: Tue May 18 09:35:52 2010 New Revision: 159528 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159528 Log: PR debug/41371 * var-tracking.c (find_loc_in_1pdv): Add a few checks from rtx_equal_p inline. Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug c++/44186] Wrong code generated with -O2 and above
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-05-18 09:53 --- (In reply to comment #3) Note however, that both the warning and the miscompilation do not happen with current 4_5-branch and mainline... Which is because we see the must-alias and punt. After all this just invokes undefined behavior which includes works and does not work. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44186
[Bug middle-end/44185] [4.6 regression] New prefetch test failures
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44185
[Bug tree-optimization/44182] [4.5/4.6 Regression] -fcompare-debug failure (length) with -O1
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-18 10:04 --- Confirmed. Assembly with 4.4 is equal -g vs. -g0 and different starting with 4.5. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.5.0 Known to work||4.4.3 Last reconfirmed|-00-00 00:00:00 |2010-05-18 10:04:30 date|| Summary|-fcompare-debug failure |[4.5/4.6 Regression] - |(length) with -O1 |fcompare-debug failure ||(length) with -O1 Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44182
[Bug lto/44184] asm goto does not work with LTO
-- steven at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|x86_64-pc-linux-gnu | GCC host triplet|x86_64-pc-linux-gnu | GCC target triplet|x86_64-pc-linux-gnu | Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44184
[Bug rtl-optimization/44174] [4.4/4.5/4.6 Regression] can't find a register in class 'CLOBBERED_REGS' while reloading 'asm'
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44174
[Bug c++/44186] Wrong code generated with -O2 and above
--- Comment #5 from paolo dot carlini at oracle dot com 2010-05-18 10:08 --- Ok ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44186
[Bug bootstrap/42347] [4.5/4.6 Regression] sched-deps.c:3840:1: internal compiler error: in fixup_reorder_chain, at cfglayout.c:796
--- Comment #28 from siarhei dot siamashka at gmail dot com 2010-05-18 10:09 --- Thanks, this patch fixes bootstrap for powerpc/powerpc64. But still fails for arm on all the same gcc_assert() in another place. Should a new bug be filed about this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42347
[Bug target/42159] [4.4/4.5/4.6] app SIGABRTs after a trivial nested throw/stack unwinding
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2010-05-18 10:28 --- Confirmed on gcc version 4.5.1 20100506 (prerelease). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail|4.4.1 4.4.2 |4.4.1 4.4.2 4.5.1 Known to work|4.5.0 | Last reconfirmed|-00-00 00:00:00 |2010-05-18 10:28:59 date|| Summary|[4.4 only] app compiled with|[4.4/4.5/4.6] app SIGABRTs |4.4.2 SIGABRTs after a |after a trivial nested |trivial nested throw/stack |throw/stack unwinding |unwinding | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159
[Bug debug/43821] -feliminate-dwarf2-dups produces no debug symbols in executable warning from dsymutil
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2010-05-18 10:35 --- Doesn't happen for me with the 4.5 branch. (I don't have a current trunk compiler to compare with.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43821
[Bug fortran/43895] [OOP] internal compiler error: verify_ssa failed
--- Comment #9 from sfilippone at uniroma2 dot it 2010-05-18 10:41 --- (In reply to comment #8) (In reply to comment #7) Btw, after the recent patch for PR43969, this might well be fixed already ... Unfortunately, no, I still get the ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43895
[Bug bootstrap/42347] [4.5/4.6 Regression] sched-deps.c:3840:1: internal compiler error: in fixup_reorder_chain, at cfglayout.c:796
--- Comment #29 from jakub at gcc dot gnu dot org 2010-05-18 10:58 --- Please file a new PR for that, with preprocessed source and all other relevant info for reproduction. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42347
[Bug tree-optimization/44182] [4.5/4.6 Regression] -fcompare-debug failure (length) with -O1
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-18 11:26 --- The differences start during inlining. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44182
[Bug target/44189] New: PIC compilation on ARM screws up DWARF lineinfo in function prologue
SVN revision: 159525
Configure line: ../gcc-svn/configure --prefix=/tmp/gcc-cross/gcc-svn-bin/
--target=arm-linux-gnueabi
--with-headers=/tmp/gcc-cross/gcc-svn-bin/arm-linux-gnueabi/include
--with-libs=/tmp/gcc-cross/gcc-svn-bin/arm-linux-gnueabi/lib/
--enable-threads=posix --enable-shared --enable-languages=c
Command line: arm-linux-gnueabi-gcc -fpic -Wall -g -O0 -S -o - -c test.c
No errors/warnings from the compiler.
Input program, test.c:
int ext_var;
void ext_fn(int x);
void bad(int x) {
ext_fn(ext_var);
}
The resulting assembly of the bad function:
bad:
.LFB0:
.file 1 test.c
.loc 1 4 0
.cfi_startproc
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 1, uses_anonymous_args = 0
stmfd sp!, {fp, lr}
.LCFI0:
.cfi_def_cfa_offset 8
add fp, sp, #4
.cfi_offset 14, -4
.cfi_offset 11, -8
.LCFI1:
.cfi_def_cfa 11, 4
sub sp, sp, #8
.loc 1 5 0 -- should not be here
ldr r3, .L2
.LPIC0:
add r3, pc, r3
.loc 1 4 0 -- should not be here
str r0, [fp, #-8]
.loc 1 5 0
ldr r2, .L2+4
ldr r3, [r3, r2]
ldr r3, [r3, #0]
mov r0, r3
bl ext_fn(PLT)
.loc 1 6 0
sub sp, fp, #4
ldmfd sp!, {fp, pc}
I have marked the .loc directives that cause the problems for me, because of
those GDB stops too early (when the function parameters are not stored yet) and
because of this GDB command `bt' shows bad parameters for the top frame. The
`next' command is confused too, of course. Furthermore, objdump -S is also
confused, shows the function header twice:
bad:
int ext_var;
void ext_fn(int x);
void bad(int x) {
0: e92d4800push{fp, lr}
4: e28db004add fp, sp, #4
8: e24dd008sub sp, sp, #8
ext_fn(ext_var);
c: e59f3020ldr r3, [pc, #32] ; 34 bad+0x34
10: e08f3003add r3, pc, r3
int ext_var;
void ext_fn(int x);
void bad(int x) {
14: e50b0008str r0, [fp, #-8]
ext_fn(ext_var);
18: e59f2018ldr r2, [pc, #24] ; 38 bad+0x38
1c: e7933002ldr r3, [r3, r2]
20: e5933000ldr r3, [r3]
24: e1a3mov r0, r3
28: ebfebl 0 ext_fn
}
2c: e24bd004sub sp, fp, #4
30: e8bd8800pop {fp, pc}
34: 001c.word 0x001c
38: .word 0x
To my understanding, the issue is caused by the on-demand generation of the
pic register loading logic for the function prologue. That part of the
prologue gets line number info of the statement that causes the generation.
My quick fix is:
Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c(revision 159525)
+++ gcc/config/arm/arm.c(working copy)
@@ -4897,13 +4897,23 @@
process. */
if (current_ir_type () != IR_GIMPLE || currently_expanding_to_rtl)
{
+ /* We want the PIC register loading instructions to have
+the same line number info as the function
+prologue. */
+ location_t saved_curr_loc = get_curr_insn_source_location ();
+ set_curr_insn_source_location (cfun-function_start_locus);
+
crtl-uses_pic_offset_table = 1;
start_sequence ();
arm_load_pic_register (0UL);
seq = get_insns ();
end_sequence ();
+
+ set_curr_insn_source_location (saved_curr_loc);
+
/* We can be called during expansion of PHI nodes, where
we can't yet emit instructions directly in the final
insn stream. Queue the insns on the entry edge, they will
This patch solves the issue for me.
This is the first time I try to do anything internally with GCC, so please
forgive my mistakes and show me the better way to fix the issue.
--
Summary: PIC compilation on ARM screws up DWARF lineinfo in
function prologue
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gergely+gccbug at risko dot hu
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44189
[Bug middle-end/44101] [4.6 regression] ICE compiling 25_algorithms/fill/4.cc on Tru64 UNIX V5.1B
--- Comment #3 from ro at gcc dot gnu dot org 2010-05-18 11:55 --- Created an attachment (id=20694) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20694action=view) preprocessed source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44101
[Bug fortran/43895] [OOP] internal compiler error: verify_ssa failed
--- Comment #10 from janus at gcc dot gnu dot org 2010-05-18 12:19 --- (In reply to comment #9) Btw, after the recent patch for PR43969, this might well be fixed already ... Unfortunately, no, I still get the ICE. Sure. Actually my comment was only targeted towards Tobias' ALLOCATED example, not the original ICE :) -- janus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43895
[Bug fortran/43895] [OOP] internal compiler error: verify_ssa failed
--- Comment #11 from burnus at gcc dot gnu dot org 2010-05-18 12:24 --- (In reply to comment #8) If one adds b = ALLOCATED(x) one finds: Where do you add this? Add in bug14 of attachment 20491 before 'end subroutine': logical b b = allocated(a%a) However, this is now fixed. * * * There are other problems related to allocatable scalars, but I think those are tracked in PR 42647. For instance (again based on attachment 20491): use d_mat_mod implicit none type(d_sparse_mat), ALLOCATABLE :: x call bug14(x) ! OK around here contains subroutine bug14(a) type(d_sparse_mat), ALLOCATABLE, intent(out) :: a logical b ! ICE here b = allocated(a); if (b) call abort() ! OK here end subroutine bug14 end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43895
[Bug debug/43821] -feliminate-dwarf2-dups produces no debug symbols in executable warning from dsymutil
--- Comment #3 from iains at gcc dot gnu dot org 2010-05-18 12:30 ---
it still fails for me on ppc and i686 4.6.0 r159518 and 159528 resp.
gcc version 4.5.1 20100518 (prerelease) [gcc-4_5-branch revision 159528] (GCC)
apollo:gcc-4-5-branch-build $ ./gcc/xgcc -B gcc -g -feliminate-dwarf2-dups
../tests/trivial-debug-sym.c
warning: no debug symbols in executable (-arch i386)
$ cat ../tests/trivial-debug-sym.c
int main (int ac, char *av[])
{
int a ;
return a + 1;
}
$ xcodebuild -version
Xcode 3.1.4
Component versions: DevToolsCore-1204.0; DevToolsSupport-1186.0
BuildVersion: 9M2809
$ ld -v
@(#)PROGRAM:ld PROJECT:ld64-85.2.1
$ dsymutil -v
@(#)PROGRAM:dsymutil PROJECT:dwarfutils-70
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43821
[Bug tree-optimization/44182] [4.5/4.6 Regression] -fcompare-debug failure (length) with -O1
--- Comment #4 from jakub at gcc dot gnu dot org 2010-05-18 13:04 --- I guess this is related to the EH rewrite in 4.5. In particular, when building cfg for f2 in make_blocks on (gdb) p debug_gimple_stmt (stmt) S::f3 (this, D.2140); (gdb) p stmt_can_throw_internal (stmt) $47 = 0 '\000' (gdb) p stmt_could_throw_p (stmt) $48 = 1 '\001' (apparently cfun-eh-throw_stmt_table is NULL). This means a new bb isn't created right after the call and so j = 0; stmt can be after it. Later on this j = 0; is replaced with DEBUG j = j_* and for -g0 case with nothing. The only two calls for which add_stmt_to_eh_lp_fn is called before inlining are S::f2 (nc_1(D), D.2136); and S::~S (D.2136); in f, no stmts in f2 nor f3. During inlining of f2 into f copy_bb - maybe_duplicate_eh_stmt_fn - add_stmt_to_eh_lp_fn is called on S::f3 (nc_1(D), D.2158_8); and from that point the f3 call is considered stmt_can_throw_internal. As with -g the f3 call is followed by a DEBUG stmt (which is invalid after it started to be a throwing insn), that bb is split during copy_edges_for_bb, but the -g0 f3 call was the last, so no splitting happens. I wonder whether it is correct that stmt_can_throw_internal changes on a call during inlining. If it is always false or always true, then either no DEBUG stmts would appear after it or no splitting would happen after the call during inlining. If it is intended that stmt_can_throw_internal changes during inlining, then guess copy_edges_for_bb 1901 if (!gsi_end_p (si)) 1902/* Note that bb's predecessor edges aren't necessarily 1903 right at this point; split_block doesn't care. */ would need to skip over is_gimple_debug stmts for the test and if there are any, drop them (or something else, Alex?). -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44182
[Bug lto/44184] asm goto does not work with LTO
--- Comment #1 from steven at gcc dot gnu dot org 2010-05-18 13:52 --- Subject: Bug 44184 Author: steven Date: Tue May 18 13:51:50 2010 New Revision: 159531 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159531 Log: gcc/ PR lto/44184 * lto-streamer-out.c (output_gimple_stmt): Output number of labels in a GIMPLE_ASM. * lto-streamer-in.c (input_gimple_stmt): Read number of labels in a GIMPLE_ASM. testsuite/ PR lto/44184 * gcc.dg/lto/20100518_0.c: New test. Added: trunk/gcc/testsuite/gcc.dg/lto/20100518_0.c Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-in.c trunk/gcc/lto-streamer-out.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44184
[Bug lto/44184] asm goto does not work with LTO
--- Comment #2 from steven at gcc dot gnu dot org 2010-05-18 14:07 --- Subject: Bug 44184 Author: steven Date: Tue May 18 14:06:31 2010 New Revision: 159532 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159532 Log: gcc/ PR lto/44184 * lto-streamer-out.c (output_gimple_stmt): Output number of labels in a GIMPLE_ASM. * lto-streamer-in.c (input_gimple_stmt): Read number of labels in a GIMPLE_ASM. testsuite/ PR lto/44184 * gcc.dg/lto/20100518_0.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/lto/20100518_0.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/lto-streamer-in.c branches/gcc-4_5-branch/gcc/lto-streamer-out.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44184
[Bug lto/44184] asm goto does not work with LTO
--- Comment #3 from steven at gcc dot gnu dot org 2010-05-18 14:08 --- Fixed for GCC 4.5.1 and later. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44184
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #11 from ktietz at gcc dot gnu dot org 2010-05-18 14:22 --- (In reply to comment #10) Re-opening. It turns out that GCC fails to actually apply the dllexport attribute to TLS control vars. So solving the binutils problem allows auto-export of a TLS variable to work, but as auto-export gets disabled in the presence of any explicit dllexport directives, this isn't an effective solution. I believe the problem needs to be addressed in config/i386/winnt.c#i386_pe_encode_section_info() I have doubts about the approach in winnt.c, but well maybe I am wrong here. I investigated for this issue and see the real issue in declaration cloning in varasm.c's emutls_decl- function, which simply doesn't copy attributes of the delaration, which then leads to issues about name-decoration. Also the DECL_DLLIMPORT_P has to be copied here, too (for import). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #12 from davek at gcc dot gnu dot org 2010-05-18 14:29 --- (In reply to comment #11) I have doubts about the approach in winnt.c, but well maybe I am wrong here. I investigated for this issue and see the real issue in declaration cloning in varasm.c's emutls_decl- function, which simply doesn't copy attributes of the delaration, which then leads to issues about name-decoration. Also the DECL_DLLIMPORT_P has to be copied here, too (for import). Well, what I was thinking when I wrote that is that we could recognize the TARGET_EMUTLS_xxx_PREFIX in winnt.c, look up the original decl, and copy whatever necessary attributes over at that time. However it does look like the TARGET_EMUTLS_VAR_INIT hook might be what we're actually looking for here; I'll check the code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #13 from davek at gcc dot gnu dot org 2010-05-18 14:33 --- (In reply to comment #12) TARGET_EMUTLS_VAR_INIT Nah, scratch that, it's not really sensible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-05-18 14:58
---
(In reply to comment #9)
But the standard says in [basic.types] that For any trivially copyable type
T,
if two pointers to T point to distinct T objects obj1 and obj2, where neither
obj1 nor obj2 is a base-class subobject, if the underlying bytes (1.7) making
up obj1 are copied into obj2,40 obj2 shall subsequently hold the same value as
obj1.
Yep. But an assignment is not a byte-copy and exactly the assignment is
what invokes the undefined behavior (not the subsequent access).
So,
struct X
{
char data[ sizeof( float ) ];
};
int main()
{
X x1;
new( x1.data ) float( 3.14f );
X x2 = x1;
GCC sees this as reading the float object you made live in x1.data via
an lvalue of type X and thus decides that the float object is unused
and removes it.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44164
[Bug target/44163] [4.6 Regression] Multiple failures in the objc and libgomp test suites
-- dje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-18 14:59:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44163
[Bug middle-end/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-05-18 15:00
---
(In reply to comment #10)
(In reply to comment #9)
But the standard says in [basic.types] that For any trivially copyable
type T,
if two pointers to T point to distinct T objects obj1 and obj2, where
neither
obj1 nor obj2 is a base-class subobject, if the underlying bytes (1.7)
making
up obj1 are copied into obj2,40 obj2 shall subsequently hold the same value
as
obj1.
Yep. But an assignment is not a byte-copy and exactly the assignment is
what invokes the undefined behavior (not the subsequent access).
So,
struct X
{
char data[ sizeof( float ) ];
};
int main()
{
X x1;
new( x1.data ) float( 3.14f );
X x2 = x1;
GCC sees this as reading the float object you made live in x1.data via
an lvalue of type X and thus decides that the float object is unused
and removes it.
Oh, and
float is a trivially copyable type. Copying X results in copying the bytes
of
X::data (because the default copy constructor of a class does a memberwise
copy, and the default copy constructor of an array does an elementwise copy).
Therefore, the underlying bytes of the object of type float, initialized at
x1.data, are copied into x2.data, which then must, if interpreted as a float,
hold the same value as the original object.
is not what the C++ frontend does. It emits the assignment literally:
cleanup_point Unknown tree: expr_stmt
(void) (x2 = TARGET_EXPR D.21180, x1)
;
gimplified to
x2 = x1;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44164
[Bug c++/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-05-18 15:02 --- Making this a C++ frontend bug. The only way to avoid expanding the copy to a loop is by using memcpy which will then run into PR42834. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org Component|middle-end |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44164
[Bug lto/44143] [4.6 Regression] -fdump-tree-all for lto does not work as expected
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-05-18 15:11 --- Subject: Bug 44143 Author: rguenth Date: Tue May 18 15:11:01 2010 New Revision: 159536 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159536 Log: 2010-05-18 Richard Guenther rguent...@suse.de PR lto/44143 * lto-wrapper.c (verbose): New variable. Initialize from -v. (debug): Initialize from -save-temps. (collect_execute): Print command-line when verbose. (run_gcc): Always use COLLECT_GCC_OPTIONS. Use fork_execute for ltrans invocation. Produce -dumpbase flag again. (process_args): Remove. (main): Simplify. * collect2.c (maybe_run_lto_and_relink): Only pass object files to lto-wrapper. * gcc.c (LINK_COMMAND_SPEC): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/collect2.c trunk/gcc/gcc.c trunk/gcc/lto-wrapper.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44143
[Bug lto/44143] [4.6 Regression] -fdump-tree-all for lto does not work as expected
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-05-18 15:11 --- Fixed again. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44143
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #14 from ktietz at gcc dot gnu dot org 2010-05-18 15:18 ---
Hi Dave,
following patch solves the issue for me pretty well.
ChangeLog
* varasm.c (emutls_decl): Clone attributes for new decl.
Index: gcc/gcc/varasm.c
===
--- gcc.orig/gcc/varasm.c 2010-05-18 13:19:20.0 +0200
+++ gcc/gcc/varasm.c2010-05-18 17:10:11.385445300 +0200
@@ -403,6 +403,8 @@ emutls_decl (tree decl)
int foo() { return i; }
__thread int i = 1;
in which I goes from external to locally defined and initialized. */
+ DECL_DLLIMPORT_P (to) = DECL_DLLIMPORT_P (decl);
+ DECL_ATTRIBUTES (to) = targetm.merge_decl_attributes (decl, to);
TREE_STATIC (to) = TREE_STATIC (decl);
TREE_USED (to) = TREE_USED (decl);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #15 from davek at gcc dot gnu dot org 2010-05-18 15:26 --- (In reply to comment #14) Hi Dave, following patch solves the issue for me pretty well. That looks good to me to, although doing it in the middle-end makes me worry that some other target might /not/ be expecting attributes to be merged from one to the other! That's the slight advantage of doing it in the encode section hook, even though string-matching the symbols is a bit kludgey. I can't test it right now owing to parallel make check being thoroughly borked on cygwin :( Could be a few days before it gets fixed and I can do anything productive gcc-wise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
--- Comment #18 from iains at gcc dot gnu dot org 2010-05-18 15:55 --- (In reply to comment #17) Created an attachment (id=20693) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20693action=view) [edit] latest version a few more tweaks. with this emutls is working for lto/whopr actually, with that patch, lto is clean and whopr has reduced fails (still some symbols not getting through). OMP is still broken hmm. it's not quite that -- the working libgomp was *not* using emutls (but standard pthread calls). So the configury machinery is detecting that tls works on with the current patch :) -- it just doesn't work well enough ... ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #16 from dominiq at lps dot ens dot fr 2010-05-18 16:28 --- You may be interested by pr 44132. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
--- Comment #19 from dominiq at lps dot ens dot fr 2010-05-18 16:55 --- This PR may have an overlap with pr44139. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug lto/44149] -fuse-linker-plugin lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:610
-- ccoutant at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ccoutant at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-05-17 09:10:19 |2010-05-18 18:15:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44149
[Bug rtl-optimization/44174] [4.4/4.5/4.6 Regression] can't find a register in class 'CLOBBERED_REGS' while reloading 'asm'
--- Comment #1 from vmakarov at redhat dot com 2010-05-18 19:06 --- It will be fixed by IRA without cover classes which I am working on. The code is planned to be included in gcc4.6. For older versions, it should be fixed in reload because I believe it is a hidden reload bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44174
[Bug target/44189] PIC compilation on ARM screws up DWARF lineinfo in function prologue
--- Comment #1 from gergely+gccbug at risko dot hu 2010-05-18 19:17 --- Added wrong-debug as a keyword. -- gergely+gccbug at risko dot hu changed: What|Removed |Added CC||gergely+gccbug at risko dot ||hu Keywords||wrong-debug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44189
[Bug objc/44140] objc.dg/torture/tls/thr-init-3.m failure
--- Comment #2 from ro at gcc dot gnu dot org 2010-05-18 19:39 --- This happens on i386-pc-solaris2.11, too, but only with -flto and -fwhopr. -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||ro at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44140
[Bug middle-end/44185] [4.6 regression] New prefetch test failures
--- Comment #2 from changpeng dot fang at amd dot com 2010-05-18 19:39 --- I have a patch to fix the test cases: http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01359.html For prefetch-6.c, patch http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00567.html applies the insn to prefetch ratio heuristic to loops with known trip count, and thus filtered one prefetch out. Add --param min-insn-to-prefetch-ratio=6 (default is 10) fixes the problem. For prefetch-7.c, patch http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00566.html does not generate prefetch if the loop is far from being sufficiently unrolled required by the prefetching. In this case, prefetching requires the loop to be unrolled 16 times, but the loop is not unrolled due to the parameter constraint. We remove --param max-unrolled-insns=1 to allow unrolling and thus generating prefetches. The movnti count is also adjusted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44185
[Bug objc/44140] objc.dg/torture/tls/thr-init-3.m failure
--- Comment #3 from ro at gcc dot gnu dot org 2010-05-18 19:42 --- Ian, you've introduced this testcase; could you have a look? -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||developer at sandoe- ||acoustics dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44140
[Bug c/19541] need another option to support what -I- did just besides -iquote
--- Comment #15 from chris dot litchfield at gmail dot com 2010-05-18 19:48 --- This is still a huge issue. We would wish to inhibit use of the CURRENT Working directory to find include files. Basically FORCE every time a new include file is found with #include to start AGAIN from the begining of the Include Path system. using -iquote will simply cause the same problem where an include file that includes another include file will include that sub-include file even if you can pulled it away in a previous include path. Make files with VPATH or put Development paths first in lists are totally hosed by removing the -I- functionality. This is NOT an enhancement but a Priority 2 bug which there is NO WORKAROUND provided by removing a feature. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19541
[Bug objc/44140] objc.dg/torture/tls/thr-init-3.m failure
--- Comment #4 from iains at gcc dot gnu dot org 2010-05-18 20:04 --- (In reply to comment #3) Ian, you've introduced this testcase; could you have a look? Yes.. working my way through .. I'm sure that it is problem with ObjC (and ObjC++, if you apply http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01039.html) -- iains at gcc dot gnu dot org changed: What|Removed |Added CC|developer at sandoe-|iains at gcc dot gnu dot org |acoustics dot co dot uk | AssignedTo|unassigned at gcc dot gnu |iains at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-18 20:04:17 date|| Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44140
[Bug c++/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function
--- Comment #13 from pluto at agmk dot net 2010-05-18 20:57 --- btw. the boost::optional uses char-based storage and cast storage - void* - some_type* via address() and get_object() methods. it looks like aliasing violation too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44164
[Bug fortran/41859] ICE on invalid expression involving DT with pointer components in I/O
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-18 21:17 --- If print *, (foo()) is changed to print *, foo() one gets: $ gfortran-svn pr41859.f90 pr41859.f90:17.19: print *, foo() ! -- ICE here! 1 Error: Data transfer element at (1) cannot have POINTER components Same for the second problem: $ gfortran-svn pr41859-c1.f90 pr41859-c1.f90:37.19: print *, foo() ! 1 Error: Data transfer element at (1) cannot have PRIVATE components -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-18 21:17:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41859
[Bug fortran/41859] ICE on invalid expression involving DT with pointer components in I/O
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-18 21:30 ---
Breakpoint 9, resolve_transfer (code=0x8bfed90) at
/home/daniel/svn/gcc-svn/gcc/fortran/resolve.c:7369
(gdb) list
7367 exp = code-expr1;
7368
7369 if (exp-expr_type != EXPR_VARIABLE exp-expr_type !=
EXPR_FUNCTION)
7370return;
7371
(gdb) print *exp
$2 = {expr_type = EXPR_OP, ts = {type = BT_DERIVED, kind = 0, u = {derived =
0x8bc7ad8, cl = 0x8bc7ad8}, interface = 0x0, is_c_interop = 0, is_iso_c = 0,
f90_type = BT_UNKNOWN},
rank = 0, shape = 0x0, symtree = 0x0, ref = 0x0, where = {nextc = 0x8bfa9ec,
lb = 0x8bfa9b0}, inline_noncopying_intrinsic = 0, is_boz = 0, is_snan = 0,
error = 0,
user_operator = 0, representation = {length = 0, string = 0x0}, value =
{logical = 27, iokind = 27, integer = {{_mp_alloc = 27, _mp_size = 0, _mp_d =
0x8bb1450}}, real = {{
_mpfr_prec = 27, _mpfr_sign = 0, _mpfr_exp = 146478160, _mpfr_d =
0x0}}, complex = {{re = {{_mpfr_prec = 27, _mpfr_sign = 0, _mpfr_exp =
146478160, _mpfr_d = 0x0}}, im = {
{_mpfr_prec = 0, _mpfr_sign = 0, _mpfr_exp = 0, _mpfr_d = 0x0, op
= {op = INTRINSIC_PARENTHESES, uop = 0x0, op1 = 0x8bb1450, op2 = 0x0}, function
= {actual = 0x1b,
name = 0x0, isym = 0x8bb1450, esym = 0x0}, compcall = {actual = 0x1b,
name = 0x0, base_object = 0x8bb1450, tbp = 0x0, ignore_pass = 0, assign = 0},
character = {
length = 27, string = 0x0}, constructor = 0x1b}}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41859
[Bug rtl-optimization/43332] valgrind warns about using uninitialized variable with -fsched-pressure -fschedule-insns
--- Comment #4 from vmakarov at redhat dot com 2010-05-18 21:40 --- Thanks for reporting the problem. The problem has no effect on generated code whatever initialization is used. The code in question tries to get basic block for BARRIER which is wrong. Whatever it gets basic block for BARRIER the code will still work right. In any case, it is really annoying to see such valgrind diagnostic. Therefore I'll send a patch to fix it soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43332
[Bug libstdc++/44190] New: Debug vector resize does not update capacity
The assertion in the following testcase should /not/ fail, but does:
#define _GLIBCXX_DEBUG
#define _GLIBCXX_DEBUG_PEDANTIC
#include vector
#include cassert
int main()
{
std::vectorint v;
v.resize(10);
assert(v.size() = v.capacity());
}
--
Summary: Debug vector resize does not update capacity
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44190
[Bug libstdc++/44190] Debug vector resize does not update capacity
--- Comment #1 from gcc-bugzilla at contacts dot eelis dot net 2010-05-18 21:45 --- Created an attachment (id=20695) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20695action=view) Trivial patch that fixes the problem. The problem was just a missing call to _M_update_guaranteed_capacity(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44190
[Bug c++/44188] Fails to produce DW_AT_typedef for typedef of anonymous struct
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-18 21:50:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44188
[Bug fortran/39427] F2003: Procedures with same name as types/type constructors
--- Comment #13 from burnus at gcc dot gnu dot org 2010-05-18 21:51 --- Created an attachment (id=20696) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20696action=view) Fifth draft patch - with test case New approach. The attached patch now also works with twisted modules (cf. test case in the attachment). However, it needs still some clean up as there are test suite failures. Additional tasks: (a) Check whether one can get rid of gfc_match_structure_constructor. (b) Add check to ensure that the generic name only contains functions and that the type name does not exist as specific function name. (c) Do general clean up, bug fixing, and add test cases. Regarding C489 [F2003] and C496 [F2008], see also: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/b3580ffd988330d7 -- burnus at gcc dot gnu dot org changed: What|Removed |Added Attachment #20599|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
[Bug fortran/41859] ICE on invalid expression involving DT with pointer components in I/O
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-18 21:54 ---
Comment #3 is somewhat hard to parse. Once more with this reduced testcase:
TYPE :: ptype
character, pointer, dimension(:) :: x = null()
END TYPE
TYPE(ptype) :: p
print *, (p)! '()' are significant
end
Breakpoint 9, resolve_transfer (code=0x8bfed90) at
/home/daniel/svn/gcc-svn/gcc/fortran/resolve.c:7369
7369 if (exp-expr_type != EXPR_VARIABLE exp-expr_type !=
EXPR_FUNCTION)
(gdb) list
7367 exp = code-expr1;
7368
7369 if (exp-expr_type != EXPR_VARIABLE exp-expr_type !=
EXPR_FUNCTION)
7370return;
7371
(gdb) p exp-expr_type
$11 = EXPR_OP
(gdb) p exp-ts.u.derived-name
$12 = 0xb7f47a08 ptype
(gdb) p exp-value.op
$13 = {op = INTRINSIC_PARENTHESES, uop = 0x0, op1 = 0x8bb1450, op2 = 0x0}
(gdb) p exp-value.op.op1-expr_type
$14 = EXPR_VARIABLE
(gdb) p exp-value.op.op1-ts.u.derived-name
$15 = 0xb7f47a08 ptype
No idea how to fix this, adding the obvious check and workaround for EXPR_OP
feels wrong. More likely, EXPR_OP should never have been passed down here?!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41859
[Bug rtl-optimization/43332] valgrind warns about using uninitialized variable with -fsched-pressure -fschedule-insns
--- Comment #5 from vmakarov at gcc dot gnu dot org 2010-05-18 22:09 --- Subject: Bug 43332 Author: vmakarov Date: Tue May 18 22:09:19 2010 New Revision: 159545 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159545 Log: 2010-05-18 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/43332 * haifa-sched.c (setup_insn_max_reg_pressure): Check barrier. Modified: trunk/gcc/ChangeLog trunk/gcc/haifa-sched.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43332
[Bug fortran/42851] ICE (segfault) at gfc_trans_pointer_assignment for subpointer
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-18 22:09 --- Reduced testcase: type t real :: a(3) end type t contains function func(x) type(t), target :: x(:) real, dimension(:), pointer :: func func = x%a(1) end function func end -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Known to fail||4.4.3 4.5.1 4.6.0 Priority|P5 |P3 Summary|[4.3/4.4/4.5] ICE (segfault)|ICE (segfault) at |at |gfc_trans_pointer_assignment |gfc_trans_pointer_assignment|for subpointer |for subpointer | Target Milestone|4.3.5 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42851
[Bug libstdc++/44190] Debug vector resize does not update capacity
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-18 22:12:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44190
[Bug fortran/42851] ICE (segfault) at gfc_trans_pointer_assignment for subpointer
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-18 22:22 --- Roughly the same testcase, same backtrace. *** This bug has been marked as a duplicate of 34640 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42851
[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer
--- Comment #14 from dfranke at gcc dot gnu dot org 2010-05-18 22:22 --- *** Bug 42851 has been marked as a duplicate of this bug. *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640
[Bug rtl-optimization/43332] valgrind warns about using uninitialized variable with -fsched-pressure -fschedule-insns
--- Comment #6 from zsojka at seznam dot cz 2010-05-18 22:22 --- Thank you for fixing this. I hope to rebuild gcc with valgrind checking in few days again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43332
[Bug fortran/38471] ICE with subreference pointer assignment
--- Comment #11 from dfranke at gcc dot gnu dot org 2010-05-18 22:26 --- As commented multiple times in PR34640, given the similarity of the testcase, the identical backtrace and the same assignee ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38471
[Bug fortran/38471] ICE with subreference pointer assignment
--- Comment #12 from dfranke at gcc dot gnu dot org 2010-05-18 22:28 --- (In reply to comment #11) As commented multiple times in PR34640, given the similarity of the testcase, the identical backtrace and the same assignee ... *** This bug has been marked as a duplicate of 34640 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38471
[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer
--- Comment #15 from dfranke at gcc dot gnu dot org 2010-05-18 22:28 --- *** Bug 38471 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640
[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer
--- Comment #16 from dfranke at gcc dot gnu dot org 2010-05-18 22:30 --- The dupes PR38471 and PR42851 have more testcases, the former an equally lengthy discussion as this PR. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640
[Bug c/44191] New: -E output broken for gcc-4.5.0
Hey,
while working on a low-prio PR24024, I recognized that the -E output of
gcc-4.5.0 is somehow broken for certain constructs, for example:
test.c
int main ()
{
int ret, a;
ret = a + \
b;
}
END test.c
(gcc-4.5.0) # gcc -E test.c
# 1 test.c
# 1 built-in
# 1 command-line
# 1 test.c
int main ()
{
int ret, a;
ret = a +
b;
}
I also tested this on older versions of gcc and each of these versions (4.2.0,
4.3.0 and 4.4.3) return the expected output:
# 1 test.c
# 1 built-in
# 1 command-line
# 1 test.c
int main ()
{
int ret, a;
ret = a + b;
}
I currently suspect that this incorrect output in gcc-4.5.0 is caused by
_cpp_clean_line. For my understanding, _cpp_clean_line should detect the splice
operator and merge the two lines to form a new logical line which is then
output due to the -E option.
--
Summary: -E output broken for gcc-4.5.0
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bug at andihellmund dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44191
[Bug fortran/43591] PPC: internal compiler error: in gfc_traverse_expr, at fortran/expr.c:3604
--- Comment #18 from dfranke at gcc dot gnu dot org 2010-05-18 22:36 --- (In reply to comment #17) Fixed on the trunk (4.6). Planned to be committed also to GCC 4.5.1. Patch was applied to trunk about 6 weeks ago - how are the backporting plans? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43591
[Bug fortran/43266] ICE on invalid: in ensure_not_abstract_walker, at fortran/resolve.c:10290
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-05-18 22:38 --- Paul, is there anything left to do here or can this PR be closed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43266
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #17 from dannysmith at users dot sourceforge dot net
2010-05-18 22:43 ---
(In reply to comment #14)
Index: gcc/gcc/varasm.c
===
--- gcc.orig/gcc/varasm.c 2010-05-18 13:19:20.0 +0200
+++ gcc/gcc/varasm.c2010-05-18 17:10:11.385445300 +0200
@@ -403,6 +403,8 @@ emutls_decl (tree decl)
int foo() { return i; }
__thread int i = 1;
in which I goes from external to locally defined and initialized. */
+ DECL_DLLIMPORT_P (to) = DECL_DLLIMPORT_P (decl);
+ DECL_ATTRIBUTES (to) = targetm.merge_decl_attributes (decl, to);
TREE_STATIC (to) = TREE_STATIC (decl);
TREE_USED (to) = TREE_USED (decl);
I like this approach better too. It would be even cleaner (here and elswhere)
if we had a decl_with_vis.dllexport_flag and DECL_DLLEXPORT_P. 14 spare bits
left in decl_with_vis. Are they too precious??
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
CC||dannysmith at users dot
||sourceforge dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug fortran/43179] ICE invalid if accessing array member of non-array
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-18 22:44 --- (In reply to comment #2) OK for trunk with the usual embellishments of ChangeLogs and testcase? Yes, if you have an example for EXPR_FUNCTION - otherwise I would claim that EXPR_VARIABLE is enough. Paul, any plans to wrap this up? :) -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43179
[Bug preprocessor/44191] -E output broken for gcc-4.5.0
--- Comment #1 from jakub at gcc dot gnu dot org 2010-05-18 22:44 --- That's just incorrect assumption. The reason why the first alternative is now preferred is to provide proper locus for the b token. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44191
[Bug c++/44172] Compiling never ends
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-05-18 22:46 --- Well I don't think we should cause an infinite loop on any input. Note Comeau C++ also causes an infinite loop. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44172
[Bug libstdc++/44190] Debug vector resize does not update capacity
--- Comment #2 from paolo dot carlini at oracle dot com 2010-05-18 23:36 --- I'm going to apply the patch: could you please provide name and family name for the ChangeLog entry? Thanks! -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||paolo dot carlini at oracle ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44190
[Bug libstdc++/44190] Debug vector resize does not update capacity
--- Comment #3 from gcc-bugzilla at contacts dot eelis dot net 2010-05-18 23:38 --- (In reply to comment #2) I'm going to apply the patch Great, thanks! :) could you please provide name and family name for the ChangeLog entry? It's Eelis van der Weegen -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44190
[Bug libstdc++/44190] Debug vector resize does not update capacity
--- Comment #4 from paolo at gcc dot gnu dot org 2010-05-18 23:59 --- Subject: Bug 44190 Author: paolo Date: Tue May 18 23:58:50 2010 New Revision: 159549 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159549 Log: 2010-05-18 Eelis van der Weegen gcc-bugzi...@contacts.eelis.net PR libstdc++/44190 * include/debug/vector (vector::resize): Call _M_update_guaranteed_capacity. * testsuite/23_containers/vector/capacity/44190.cc: New. Added: trunk/libstdc++-v3/testsuite/23_containers/vector/capacity/44190.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/debug/vector -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44190
[Bug libstdc++/44190] Debug vector resize does not update capacity
--- Comment #5 from paolo dot carlini at oracle dot com 2010-05-19 00:00 --- Fixed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44190
[Bug bootstrap/44192] New: [4.6 regression] Failed to bootstrap
On Linux, revision gave 159549: ../../src-trunk/gcc/fortran/trans-expr.c: In function 'gfc_conv_procedure_call': ../../src-trunk/gcc/fortran/trans-expr.c:3344:3: error: implicit declaration of function 'build_call_list' [-Werror=implicit-function-declaration] ../../src-trunk/gcc/fortran/trans-expr.c:3344:12: error: assignment makes pointer from integer without a cast [-Werror] -- Summary: [4.6 regression] Failed to bootstrap Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44192
[Bug c++/44193] New: [4.3/4.4/4.5/4.6 Regression] function types, cv-quals and typename
Starting with version 4.0 G++ fails to accept this testcase:
bool f(int i) { return i != 5; }
template class X, class P = bool(X)
struct Traits
{
typedef P type;
};
template class X, class P = typename TraitsX::type
struct S
{
const P p_;
S( const P p ) : p_(p) {} // const reference
};
template class X
SX make_s(const typename TraitsX::type p) // const reference
{
return SX(p); // HERE
}
int main()
{
make_sint(f);
}
because the parameter of make_sint ends up with reference to const function
type. This is wrong; applying const to a function type should produce the same
function type, not a const variant.
--
Summary: [4.3/4.4/4.5/4.6 Regression] function types, cv-quals
and typename
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: jason at gcc dot gnu dot org
ReportedBy: jason at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44193
[Bug c++/44193] [4.3/4.4/4.5/4.6 Regression] function types, cv-quals and typename
-- jason at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-19 04:03:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44193
[Bug fortran/43072] unneeded temporary (s=s+f(a))
--- Comment #9 from pault at gcc dot gnu dot org 2010-05-19 04:28 --- Fixed. Thanks, Joost! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43072
[Bug fortran/43266] ICE on invalid: in ensure_not_abstract_walker, at fortran/resolve.c:10290
--- Comment #8 from pault at gcc dot gnu dot org 2010-05-19 04:32 --- Fixed. Thanks, Tobias. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43266
[Bug rtl-optimization/44194] New: struct returned by value generates useless stores
Test case:
--
#include stdint.h
struct twoints { uint64_t a, b; } foo();
void bar(uint64_t a, uint64_t b);
void func() {
struct twoints s = foo();
bar(s.a, s.b);
}
--
$ gcc -save-temps -Wall -c -o testbad.o -msse2 -O3 -fomit-frame-pointer
testbad.c
$ objdump -d -r -M intel testbad.o
testbad.o: file format elf64-x86-64
Disassembly of section .text:
func:
0: 48 83 ec 28 subrsp,0x28
4: 31 c0 xoreax,eax
6: e8 00 00 00 00 call b func+0xb
7: R_X86_64_PC32foo-0x4
b: 48 89 04 24 movQWORD PTR [rsp],rax
f: 48 89 54 24 08 movQWORD PTR [rsp+0x8],rdx
14: 48 89 d6movrsi,rdx
17: 48 89 44 24 10 movQWORD PTR [rsp+0x10],rax
1c: 48 89 54 24 18 movQWORD PTR [rsp+0x18],rdx
21: 48 89 c7movrdi,rax
24: 48 83 c4 28 addrsp,0x28
28: e9 00 00 00 00 jmp2d func+0x2d
29: R_X86_64_PC32 bar-0x4
--
As you can see above, rax and rdx are stored to the stack twice, but these
stores are unnecessary.
$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
--disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
--
Summary: struct returned by value generates useless stores
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jhaberman at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
[Bug bootstrap/44192] [4.6 regression] Failed to bootstrap
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-19 05:42 --- Fixed as of revision 159555. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44192
[Bug fortran/41859] ICE on invalid expression involving DT with pointer components in I/O
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-05-19 05:47 --- I have a patch testing. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-05-18 21:17:52 |2010-05-19 05:47:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41859
