[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4
--- Comment #11 from iains at gcc dot gnu dot org 2010-04-12 06:57 --- (In reply to comment #9) > checked for each instance. So if all four test cases are actually emitting > valid dwarf, we can drop the usage of -lm on darwin[921] The two things are totally unrelated - AFAICT the reason the "-lm" causes the problem to "go away" is because of a specs bug causing dsymutil not to run when "-lm" is on the C/L. So we WILL have to find a solution - because we need to fix the specs bug and the use of "-lm". ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43254
[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4
--- Comment #10 from iains at gcc dot gnu dot org 2010-04-12 06:43 --- (In reply to comment #9) > I confirmed with the dsymutil maintainer that my reading of his response was > correct. Indeed, the warning may or may not be significant and has to be > checked for each instance. So if all four test cases are actually emitting > valid dwarf, we can drop the usage of -lm on darwin[921] (although we will > have > to > add a dg-prune-output to eliminate the failures from these false warnings. OK, sorry for the noise on the list. We will, however, have to figure out what to do for D9.. and D8... since we can't expect a fix there.. I suppose. -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43254
[Bug testsuite/31846] Logs are not being parsed correctly by testsuite and "test_summary" scripts.
--- Comment #6 from manu at gcc dot gnu dot org 2010-04-12 06:41 --- (In reply to comment #5) > > Some three years later we might expect I am unable to assist further and might > focus my efforts where they are more productive. Sorry about that. I totally understand your frustration. Lack of resources and focus on the most visible/severe bugs explain in part the appearance of inaction.The time delay totally depends on the bug. Thanks anyway for the report and sorry again. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31846
[Bug target/43724] GCC produces suboptimal ARM NEON code for zero vector assignment
--- Comment #1 from siarhei dot siamashka at gmail dot com 2010-04-12 06:17 --- Or just "vmov.i32 q8, #0" would be better to avoid any potential data dependency. -- siarhei dot siamashka at gmail dot com changed: What|Removed |Added CC||siarhei dot siamashka at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43724
[Bug target/43724] New: GCC produces suboptimal ARM NEON code for zero vector assignment
The intrinsic family for vdupq_n_XXX with argument of 0. The code generated is: mov r0, #0 vdup.32 q8, r0 Instead of the faster veor.32 q8, q8, q8 Thing to note is that GCC will use xorps on x86[_64] for SSE when using _mm_setzero_ps() or _mm_set1_ps(0). -- Summary: GCC produces suboptimal ARM NEON code for zero vector assignment Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: liranuna at gmail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: arm-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43724
[Bug target/43364] Suboptimal code for the use of ARM NEON intrinsic "vset_lane_f32"
--- Comment #2 from siarhei dot siamashka at gmail dot com 2010-04-12 05:26 --- (In reply to comment #1) > mov r3, #0 > vdup.32 d16, r3 Also maybe "veor.32 d16, d16, d16" here? Or drop this NEON register initialization completely because it is a redundant operation and was not explicitly requested in the original C code? After all, from IHI0042D_aapcs.pdf: "The FPSCR is the only status register that may be accessed by conforming code. It is a global register with the following properties: * The condition code bits (28-31), the cumulative saturation (QC) bit (27) and the cumulative exception-status bits (0-4) are not preserved across a public interface." and from ARM ARM: "Advanced SIMD arithmetic always uses untrapped exception handling" Tracking the cumulative exception-status bits may be tricky in general (using ununitialized value for NEON arithmetics can set them arbitrarily), but as long as they are not used in any way in the function itself, they are irrelevant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43364
[Bug c/36774] -Wmissing-prototypes triggers on nested functions
--- Comment #7 from pzhao at gcc dot gnu dot org 2010-04-12 04:00 --- Fixed on trunk. -- pzhao at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36774
[Bug target/43723] New: Some ARMs support unaligned
Source:
struct s { int i; } __attribute__((packed));
int a(struct s *s)
{
return s->i;
}
Using 4.5:
> /usr/local/gcc-arm/bin/arm-none-linux-gnueabi-gcc -Os -mcpu=cortex-a8 -S
> unaligned.c
> cat unaligned.s
.cpu cortex-a8
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 4
.eabi_attribute 18, 4
.file "unaligned.c"
.text
.align 2
.global a
.type a, %function
a:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldrbr2, [r0, #1]@ zero_extendqisi2
ldrbr3, [r0, #0]@ zero_extendqisi2
orr r3, r3, r2, asl #8
ldrbr2, [r0, #2]@ zero_extendqisi2
ldrbr0, [r0, #3]@ zero_extendqisi2
orr r3, r3, r2, asl #16
orr r0, r3, r0, asl #24
bx lr
.size a, .-a
.ident "GCC: (GNU) 4.5.0 20100325 (experimental)"
.section.note.GNU-stack,"",%progbits
At least some configurations of cortex-a8 support unaligned access just fine,
so it should be possible to use it. But it doesn't look like it is - there is
no -mno-strict-align for arm. This would be a major code size reduction for
FFmpeg.
--
Summary: Some ARMs support unaligned
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: astrange at ithinksw dot com
GCC target triplet: arm-unknown-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43723
[Bug rtl-optimization/43721] Failure to optimise (a/b) and (a%b) into single __aeabi_idivmod call
--- Comment #1 from astrange at ithinksw dot com 2010-04-12 03:54 ---
Still the case with 4.5.
> arm-none-linux-gnueabi-gcc -Os -S divmod.c
> cat divmod.s
.cpu arm10tdmi
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 4
.eabi_attribute 18, 4
.file "divmod.c"
.global __aeabi_idivmod
.global __aeabi_idiv
.text
.align 2
.global divmod
.type divmod, %function
divmod:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
stmfd sp!, {r4, r5, r6, lr}
mov r6, r0
mov r5, r1
bl __aeabi_idivmod
mov r0, r6
mov r4, r1
mov r1, r5
bl __aeabi_idiv
add r0, r4, r0
ldmfd sp!, {r4, r5, r6, pc}
.size divmod, .-divmod
.ident "GCC: (GNU) 4.5.0 20100325 (experimental)"
.section.note.GNU-stack,"",%progbits
--
astrange at ithinksw dot com changed:
What|Removed |Added
CC||astrange at ithinksw dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43721
[Bug c/36774] -Wmissing-prototypes triggers on nested functions
--- Comment #6 from pzhao at gcc dot gnu dot org 2010-04-12 03:43 --- Subject: Bug 36774 Author: pzhao Date: Mon Apr 12 03:43:21 2010 New Revision: 158214 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158214 Log: gcc/ 2010-04-12 Shujing Zhao PR c/36774 * c-decl.c (start_function): Move forward check for nested function. gcc/testsuite/ 2010-04-12 Shujing Zhao PR c/36774 * gcc.dg/pr36774-1.c: New test. * gcc.dg/pr36774-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr36774-1.c trunk/gcc/testsuite/gcc.dg/pr36774-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36774
[Bug bootstrap/43715] configure option --enable-plugin fails on darwin
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-04-12 03:31 --- Third (and hopefully really the final) revision of the patch posted at http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00545.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43715
[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2010-04-12 03:25 --- I confirmed with the dsymutil maintainer that my reading of his response was correct. Indeed, the warning may or may not be significant and has to be checked for each instance. So if all four test cases are actually emitting valid dwarf, we can drop the usage of -lm on darwin[921] (although we will have to add a dg-prune-output to eliminate the failures from these false warnings. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43254
[Bug target/43722] ICE when passing NEON registers using const refrences
--- Comment #1 from liranuna at gmail dot com 2010-04-12 03:24 --- I would like to add that changing void printv_f32(const float32x4_t &v) into: void printv_f32(float32x4_t v) makes the problem go away, but the generated code is suboptimal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43722
[Bug target/43722] New: ICE when passing NEON registers using const refrences
Giving GCC 4.4.3 the following code with the arguments "-O1 -mcpu=cortex-a8
-mfpu=neon -mfloat-abi=softfp":
#include
#include
void printv_f32(const float32x4_t &v)
{
printf("%f\n", vgetq_lane_f32(v, 0));
}
int main()
{
float32x4_t v = {0.0, 1.0f, 2.0f, 3.0f};
printv_f32(v);
return 0;
}
Results into an ICE:
/home/liranuna/Projects/mathlib_md/source/main.cpp: In function 'int main()':
/home/liranuna/Projects/mathlib_md/source/main.cpp:21: error: insn does not
satisfy its constraints:
(insn 25 5 7 2 /home/liranuna/Projects/mathlib_md/source/main.cpp:11 (set
(mem/c/i:V4SF (pre_dec:SI (reg/f:SI 0 r0 [134])) [0 v+0 S16 A64])
(reg:V4SF 95 d16)) 710 {*neon_movv4sf} (expr_list:REG_INC (reg/f:SI 0
r0 [134])
(nil)))
/home/liranuna/Projects/mathlib_md/source/main.cpp:21: internal compiler error:
in reload_cse_simplify_operands, at postreload.c:396
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
--
Summary: ICE when passing NEON registers using const refrences
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: liranuna at gmail dot com
GCC host triplet: x86_64-linux-gnu
GCC target triplet: arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43722
[Bug testsuite/31846] Logs are not being parsed correctly by testsuite and "test_summary" scripts.
--- Comment #5 from rob1weld at aol dot com 2010-04-12 02:23 --- (In reply to comment #4) > Rob, this is very old. Is it still a problem? Thank you kindly for being the one to reply to my Report. Due to the fact that it often takes a year for some replies, and in this case three years, I am working with another group that is producing a free Operating System rather than sitting idle. It is _great_ of you to go through these old reports and try to close (resolve) them. I have done that job previously and know that sometimes it can be frustrating. Some three years later we might expect I am unable to assist further and might focus my efforts where they are more productive. Thanks, Rob Reporter: Changing status from "Waiting" to "New" (since I can not choose "Old") and you are welcome to change the Resolution to "Wontfix" (since you can not choose "Abandoned"). :) -- rob1weld at aol dot com changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31846
[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2010-04-12
01:54 ---
The response from the dsymutil maintainer was...
The warning was cause for alarm, and the root cause has been fixed (checked
in), though it isn't affecting your test case.
If you see this type of warning again before you get a fixed dsymutil, look at
the dwarfdump output as you were doing for a matching attribute value. In this
case it was:
0x0205: TAG_subrange_type [28]
AT_type[FORM_ref4] ( {0x0048} ( base ) )
AT_upper_bound[FORM_ref4] ( {0x0149} )
Then you want to make sure that the reference (FORM_ref4) it has ({0x0149})
made it into the output file which it did:
0x0149: TAG_variable [21]
AT_artificial[FORM_flag] ( 0x01 )
AT_type[FORM_ref4] ( {0x020f} ( const base ) )
AT_location[FORM_data4] ( 0x0144
0x00010d46 - 0x00010e62: r13-1
0x00010e64 - 0x00010e6f: r13-1 )
So everything is ok in this case.
dsymutil will track exactly which DIEs make it into the dSYM and only put those
DIEs and the dependent DIEs. This helps deal with gcc's one definition rule
which can bloat up the debug info. If dead code stripping is on, and only one
function of 100 makes it into the dSYM, we strip 99% of the debug info and keep
the DWARF small. In a failing case, dsymutil would not add 0x0149 to the
output dSYM and the DWARF would have a DIE with an invalid reference.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43254
[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor
--- Comment #26 from rob1weld at aol dot com 2010-04-12 01:54 --- (In reply to comment #25) > I understand that this is INVALID because all the points raised by comment > #21. > If crlibm is better than what we have, but we cannot use it, it is the same as > if it didn't exist. It is possible to use various other Programs (or Libraries with a bit of programming) and run them seperately on a test script to check that both programs give the same result. We could compile and run 'crlibm' (and some other programs) _without_ incorporating it's code into gcc and compare the results of the two Programs with each other using 'diff' . Doing the above is useful for _testing_ but ultimatley we should either 'fix' our code to use the default flags (so the math is not broken) _or_ use the flags that I suggested as the defaults and avoid the problem altogether. We could (but do not have to) use a different math Library. The existance of other code that works correctly proves that we could write our own code differently (properly) and have correct results instead of insisting that we can only have a wrong result and that we should accept it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180
[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4
--- Comment #7 from iains at gcc dot gnu dot org 2010-04-12 00:55 ---
this causes the message at any optimization > 0.
which kinda points to variable length arrays as the issue (wherever that issue
is).
extern long random(void);
int main(int ac,char *av[])
{
int n = random();
int x[n+1];
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43254
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #34 from sherpya at netfarm dot it 2010-04-11 23:58 --- good point :) it should be written in caps, it's not common usage of linking flags :) anyway the reason is easy to understand results aren't exactly as expected by at least not crazy :) --- SCAN SUMMARY --- Known viruses: 754681 Engine version: de...@clamwin MinGW - Apr 12 2010 Scanned directories: 1 Scanned files: 4402 Infected files: 0 Data scanned: 980.84 MB Data read: 998.92 MB (ratio 0.98:1) Time: 443.047 sec (7 m 23 s) about the llvm dll I still get an ice lto1: internal compiler error: in input_gimple_stmt, at lto-streamer-in.c:1108 /* In case of type mismatches across units we can fail to unify some types and thus not find a proper field-decl here. So only assert here if checking is enabled. */ #ifdef ENABLE_CHECKING gcc_assert (tem != NULL_TREE); #endif any suggestion about submitting this bug? I suspect that intermediate file for this report would become very large (normally the resulting binary is 8-9mb large) I've not tested natively but only a cross, but in my opinion your patch looks ok, the produced code was always working -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-04-11 23:42 --- Opened radar://7851516 and have pinged the Apple dsymutil maintainer to take a look. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43254
[Bug bootstrap/43715] configure option --enable-plugin fails on darwin
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2010-04-11 23:07 --- Hopefully the final revision posted at http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00539.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43715
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #33 from steven at gcc dot gnu dot org 2010-04-11 22:59 --- A common mistake is to not pass the optimizer flags properly to the linker. There is a thread about that, too: http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00438.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4
--- Comment #5 from iains at gcc dot gnu dot org 2010-04-11 22:52 --- It's possible that the message from dsymutil is misleading: Is this correct ? I'm very new to dwarf - but it looks like the DW_AT_upper_bound is missing a value? .byte 0x6 # uleb128 0x6; (DIE (0x10d) DW_TAG_base_type) .byte 0x4 # DW_AT_byte_size .byte 0x5 # DW_AT_encoding .ascii "int\0" # DW_AT_name .byte 0x7 # uleb128 0x7; (DIE (0x114) DW_TAG_array_type) .long 0x10d # DW_AT_type .long 0x127 # DW_AT_sibling .byte 0x8 # uleb128 0x8; (DIE (0x11d) DW_TAG_subrange_type) .long 0x127 # DW_AT_type .long 0xf5# DW_AT_upper_bound .byte 0x0 # end of children of DIE 0x114 .byte 0x9 # uleb128 0x9; (DIE (0x127) DW_TAG_base_type) -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43254
[Bug rtl-optimization/43721] New: Failure to optimise (a/b) and (a%b) into single __aeabi_idivmod call
Consider the following code:
int divmod(int a, int b)
{
int q = a / b;
int r = a % b;
return q + r;
}
For an ARM EABI target, this results in one __aeabi_idivmod() call and one
__aeabi_idiv() call even though the former already calculates the quotient.
--
Summary: Failure to optimise (a/b) and (a%b) into single
__aeabi_idivmod call
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mans at mansr dot com
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: arm-unknown-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43721
[Bug rtl-optimization/43653] ICE: in reload, at reload1.c:1188 with -O1 -ftree-vectorize and empty struct
--- Comment #2 from ubizjak at gmail dot com 2010-04-11 20:35 ---
Works with -fno-omit-frame-pointer. We expand to:
(insn 8 7 0 pr43653.c:4 (set (reg:V2DI 61 [ vect_cst_.2 ])
(vec_duplicate:V2DI (reg/f:DI 54 virtual-stack-vars))) 1700
{*vec_dupv2d
i} (nil))
(insn 9 8 0 pr43653.c:4 (parallel [
(set (reg:DI 64 [ ivtmp.9 ])
(plus:DI (reg/f:DI 54 virtual-stack-vars)
(const_int -512 [0xfe00])))
(clobber (reg:CC 17 flags))
]) -1 (nil))
In -fomit-frame-pointer case, RA is trying to eliminate frame reg and at the
same time trying to satisfy "x" register constraint, RA chokes on either of:
(insn 8 5 9 2 pr43653.c:4 (set (reg:V2DI 61 [ vect_cst_.2 ])
(vec_duplicate:V2DI (reg/f:DI 20 frame))) 1700 {*vec_dupv2di} (nil))
(insn 9 8 10 2 pr43653.c:4 (parallel [
(set (reg:DI 64 [ ivtmp.9 ])
(plus:DI (reg/f:DI 20 frame)
(const_int -512 [0xfe00])))
(clobber (reg:CC 17 flags))
]) 252 {*adddi_1} (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
The failure in (insn 8) can be triggered on non-TARGET_INTER_UNIT_MOVES targets
(i.e. -march=k8) when temp stack slot is generated to move from (eliminated?)
integer %rbp to SSE %xmm reg via stack slot.
The failure in (insn 9) can be triggered with -march=core2 also when frame
pointer is to be eliminated.
Using -mno-omit-frame-pointer, we get:
(insn 32 5 33 2 pr43653.c:4 (set (mem/c:DI (plus:DI (reg/f:DI 6 bp)
(const_int -520 [0xfdf8])) [0 S8 A64])
(reg/f:DI 6 bp)) 89 {*movdi_1_rex64} (nil))
(insn 33 32 8 2 pr43653.c:4 (set (reg:DI 22 xmm1)
(mem/c:DI (plus:DI (reg/f:DI 6 bp)
(const_int -520 [0xfdf8])) [0 S8 A64])) 89
{*movdi_1
_rex64} (nil))
(insn 8 33 34 2 pr43653.c:4 (set (reg:V2DI 22 xmm1)
(vec_duplicate:V2DI (reg:DI 22 xmm1))) 1700 {*vec_dupv2di}
(expr_list:RE
G_EQUIV (vec_duplicate:V2DI (reg/f:DI 6 bp))
(nil)))
(insn 34 8 9 2 pr43653.c:4 (set (reg:V2DI 21 xmm0 [orig:61 vect_cst_.2 ] [61])
(reg:V2DI 22 xmm1)) 1049 {*movv2di_internal} (nil))
(insn 9 34 10 2 pr43653.c:4 (parallel [
(set (reg:DI 0 ax [orig:64 ivtmp.9 ] [64])
(plus:DI (reg/f:DI 6 bp)
(const_int -512 [0xfe00])))
(clobber (reg:CC 17 flags))
]) 252 {*adddi_1} (expr_list:REG_EQUAL (plus:DI (reg/f:DI 6 bp)
(const_int -512 [0xfe00]))
(nil)))
Adding CC.
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-04-11 20:35:55
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43653
[Bug target/43708] [4.6 Regression] gcc.dg/pragma-darwin.c "set not used", not working with pragma
--- Comment #3 from jakub at gcc dot gnu dot org 2010-04-11 19:53 --- TREE_USED is not redundant. The patch looks good to me, though I can't approve it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43708
[Bug target/43708] [4.6 Regression] gcc.dg/pragma-darwin.c "set not used", not working with pragma
-- 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=43708
[Bug bootstrap/43714] missing check for zlib.h, fails to build lto-compress.c
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-11 19:28 --- Well, I believe --with-system-zlib is a promise. Thus, I think this bug is invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43714
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
-- 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=43716
[Bug c++/43719] uninitialized const member incorrectly accepted, using an array
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-11 19:23 --- Use a bugzilla account with your @gcc.gnu.org address. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fabien dot chene at gmail |dot org |dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43719
[Bug c++/43720] undefined reference to static const integral class member
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-11 19:22 --- You need a proper definition for the constant. -- 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=43720
[Bug bootstrap/43715] configure option --enable-plugin fails on darwin
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2010-04-11 19:11 --- (In reply to comment #3) s/do/do not/g -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43715
[Bug bootstrap/43715] configure option --enable-plugin fails on darwin
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-04-11 19:10 --- Revised patch posted at http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00533.html. I do see any combination of options for otool which would give us the required exported symbol list. In any case, this wouldn't help any other non-darwin targets that happen to be missing objdump. Using '$gcc_cv_nm -g | grep T' seems most portable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43715
[Bug c++/43720] New: undefined reference to static const integral template class member
$ cat test1.cpp
template
void zzz(X const& x) {
return;
}
struct ttt_t {
static int const static_const_int=0;
int func()const {
zzz(static_const_int);
return 0;
}
};
int main() {
return ttt_t().func();
}
$ g++ -O test1.cpp --save-temps
#no errors
$ g++ test1.cpp --save-temps
test1.o: In function `ttt_t::func() const':
test1.cpp:(.text._ZNK5ttt_t4funcEv[ttt_t::func() const]+0xd): undefined
reference to `ttt_t::static_const_int'
collect2: ld returned 1 exit status
$ grep 'static_const_int' test1.s
movl$_ZN5ttt_t16static_const_intE, %edi
$ cat test2.cpp
template
void __attribute((noinline)) zzz(X const& x) {
static bool volatile junk=false;
if (junk) zzz(x);
return;
}
struct ttt_t {
static int const static_const_int=0;
int func()const {
zzz(static_const_int);
return 0;
}
};
int main() {
return ttt_t().func();
}
$ g++ -O3 test2.cpp --save-temps
#no errors
$ g++ -O2 test2.cpp --save-temps
test2.o: In function `main':
test2.cpp:(.text+0x5): undefined reference to `ttt_t::static_const_int'
collect2: ld returned 1 exit status
$ grep 'static_const_int' test2.s
movl$_ZN5ttt_t16static_const_intE, %edi
4.4.4 has same issues except that -O3 fails with test2.cpp
--
Summary: undefined reference to static const integral template
class member
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roman at binarylife dot net
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=43720
[Bug tree-optimization/43560] [4.3 Regression] possible wrong code bug
--- Comment #15 from rguenther at suse dot de 2010-04-11 18:08 ---
Subject: Re: [4.3 Regression] possible wrong
code bug
On Fri, 9 Apr 2010, jakub at gcc dot gnu dot org wrote:
> --- Comment #14 from jakub at gcc dot gnu dot org 2010-04-09 18:24
> ---
> Testcase distilled from OO.o that has been also fixed by this bugfix (failed
> at
> -Os). Do we want it for the testsuite too?
>
> struct S
> {
> int a, b;
> char c[10];
> };
>
> __attribute__((noinline)) void
> test (struct S *x)
> {
> while (x->b > 1 && x->c[x->b - 1] == '/')
> {
> x->b--;
> x->c[x->b] = '\0';
> }
> }
>
> const struct S s = { 0, 0, "" };
>
> int
> main ()
> {
> struct S *p;
> asm ("" : "=r" (p) : "0" (&s));
> test (p);
> return 0;
> }
Yes please.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43560
[Bug c++/43719] uninitialized const member incorrectly accepted, using an array
--- Comment #1 from fabien dot chene at gmail dot com 2010-04-11 18:04 --- related to PR 25811. Mine. (it should be great if someone could grant me the access to the 'assign bug' checkbox). -- fabien dot chene at gmail dot com changed: What|Removed |Added Known to fail||4.4.3 4.3.4 4.2.4 4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43719
[Bug fortran/41359] Wrong line numbers for debugging/profiling
--- Comment #4 from jv244 at cam dot ac dot uk 2010-04-11 18:02 --- looks like we have a patch... -- jv244 at cam dot ac dot uk changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41359
[Bug c++/43719] New: uninitialized const member incorrectly accepted, using an array
struct A
{
int const i;
};
void f ()
{
A a; // not accepted: OK
A aa[ 1 ]; // incorrectly accepted
}
--
Summary: uninitialized const member incorrectly accepted, using
an array
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fabien dot chene at gmail 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=43719
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #32 from sherpya at netfarm dot it 2010-04-11 17:38 --- I've repeated the test multiple times, I already done scan benchmarks before I think I need to check if I have same results on linux -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug c++/43641] [C++0x] internal compiler error: tree check: expected call_expr, have target_expr in maybe_add_lambda_conv_op
--- Comment #8 from indy2718 at gmail dot com 2010-04-11 17:31 ---
reduced the test.cpp case to:
struct B
{
public:
int _a;
};
void func()
{
[](const B & b) -> const int & { return b._a; };
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43641
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #41 from dominiq at lps dot ens dot fr 2010-04-11 15:36 --- > Has the issue in Comment 33/38 been reported on radar? No. If you want to do it, be my guest!-(You got answer to my last one I did not get, not even an acknowledgement). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #40 from howarth at nitro dot med dot uc dot edu 2010-04-11 15:24 --- Has the issue in Comment 33/38 been reported on radar? If so, let me know the radar problem number and I'll ping the dsymutil developer at Apple. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #39 from iains at gcc dot gnu dot org 2010-04-11 15:10 --- (In reply to comment #38) > Interestingly, while the change in Comment 37 eliminates the failures in > gcc.dg/torture/builtin-math-7.c, it introduces the failures... > > FAIL: gcc.c-torture/execute/20020412-1.c compilation, -O3 -g > FAIL: gcc.c-torture/execute/20040811-1.c compilation, -O3 -g > FAIL: gcc.c-torture/execute/pr43220.c compilation, -O3 -g > FAIL: gcc.c-torture/execute/vla-dealloc-1.c compilation, -O3 -g > > These appear in the form... This is what Dominque already reported [comment #33] (and the reason for my comments on dsymutil). We will have to look at what to do about this - the cases have already been investigated and declared "dsymutil bug" maybe we can add a prune command to the testcase in the short term. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #38 from howarth at nitro dot med dot uc dot edu 2010-04-11 14:47 --- Interestingly, while the change in Comment 37 eliminates the failures in gcc.dg/torture/builtin-math-7.c, it introduces the failures... FAIL: gcc.c-torture/execute/20020412-1.c compilation, -O3 -g FAIL: gcc.c-torture/execute/20040811-1.c compilation, -O3 -g FAIL: gcc.c-torture/execute/pr43220.c compilation, -O3 -g FAIL: gcc.c-torture/execute/vla-dealloc-1.c compilation, -O3 -g These appear in the form... Executing on host: /sw/src/fink.build/gcc45-4.5.0-0rc1/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc45-4.5.0-0rc1/darwin_objdir/gcc/ /sw/src/fink.build/gcc45-4.5.0-0rc1/gcc-4.5-20100410/gcc/testsuite/gcc.c-torture/execute/20020412-1.c -w -O3 -g -o /sw/src/fink.build/gcc45-4.5.0-0rc1/darwin_objdir/gcc/testsuite/gcc/20020412-1.x6 (timeout = 300) warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4 output is: warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4 FAIL: gcc.c-torture/execute/20020412-1.c compilation, -O3 -g I guess we should try to convert these into a test case for the existing dejagnu and open a new PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug bootstrap/43531] [4.5 Regression] host files being used during cross compilation
--- Comment #29 from rwild at gcc dot gnu dot org 2010-04-11 14:24 --- Created an attachment (id=20361) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20361&action=view) patch to address issue described in comment #21 The main issue described in this bug is fixed, and it has rightly been closed. The issue described in comment #21 should probably still be addressed. Attached is a patch that I think would do so. However, it requires GNU make 3.81 for the $(abspath ...) function, and it will do the wrong thing in case the builddir contains a percent sign %. There might be a cleaner way to fix the issue by rewriting libgcc/Makefile.in to pass a relative path or so. Feedback appreciated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #37 from howarth at nitro dot med dot uc dot edu 2010-04-11
13:56 ---
Actually, it has to be...
@@ -30,8 +30,8 @@
#set_board_info host_library_path "[file dirname [file dirname [file dirname
[file dirname [file dirname [exec [find_gcc] --print-prog-name=cc1]]/lib"
-# Do not use -lm on Cygwin
-if { [istarget "*-*-cygwin*"] } {
+# Do not use -lm on Cygwin or Darwin
+if { [istarget "*-*-cygwin*"] || [istarget "*-*-darwin9*"] || [istarget
"*-*-darwin2*"] || [istarget "*-*-darwin1*"] } {
set_board_info mathlib ""
}
as dejagnu doesn't appear to support the [921] regex syntax. Also, I wouldn't
hold my breath for this showing up in a dejagnu release anytime soon since
there hasn't been an update since 2004.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug fortran/34554] time compiling complicated size initialization expression
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2010-04-11 13:07 --- Dominique, thanks for testing. You are not getting near the same speedup I am. It must be related to cache size. I will submit the patch for approval some time in the next few days. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34554
[Bug target/43129] Simplify global variable's address loading with option -fpic
--- Comment #7 from carrot at google dot com 2010-04-11 12:12 --- (In reply to comment #6) > Some experiment results: > > Compile CSiBE with options -Os -fpic -mthumb -fno-short-enums > > without this optimization: 2830665 > simplify-got before ra:2825737 > simplify-got after ra: 2826853 These numbers are sum of each line in file result-size.csv. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43129
[Bug target/43129] Simplify global variable's address loading with option -fpic
--- Comment #6 from carrot at google dot com 2010-04-11 12:09 --- Some experiment results: Compile CSiBE with options -Os -fpic -mthumb -fno-short-enums without this optimization: 2830665 simplify-got before ra:2825737 simplify-got after ra: 2826853 So this optimization should be done before RA. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43129
[Bug bootstrap/37632] Darwin bootstrap failure, "ld: bl out of range"
--- Comment #9 from iains at gcc dot gnu dot org 2010-04-11 10:29 --- (In reply to comment #6) > I wrote > which means using gcc-4.0.1; I used *exactly* your configure line. > Did you have the gmp and mpfr sources in the gcc-4_4-branch source directory? 1. I re-tried with the current gmp/mpfr symlinked to the dirs I shared with current trunk and 4.5 GNU C (GCC) version 4.4.4 20100410 (prerelease) [gcc-4_4-branch revision 158195] (powerpc64-apple-darwin9) compiled by GNU C version 4.4.4 20100410 (prerelease) [gcc-4_4-branch revision 158195], GMP version 4.3.2, MPFR version 2.4.2. no problem. $ autoconf --version autoconf (GNU Autoconf) 2.61 $ automake --version automake (GNU automake) 1.10 $ m4 --version GNU M4 1.4.6 I do use gawk3-1-6 on Geoff Keating's advice - but I tried with the stock install of awk on Darwin9 and that also works... $ awk --version GNU Awk 3.1.6 2. As a matter of curiosity - do you see a big improvement in performance from building gcc 64bit? I normally build ppc-apple-darwin9 - since this is quite capable of generating m64 code should I have an app that requires it. 3. note that those tools *do* need to be updated for 4.5 and current trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37632
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #36 from iains at gcc dot gnu dot org 2010-04-11 10:18 --- (In reply to comment #33) > (In reply to comment #32) > > Note that when using the patch in comment #22 triggers pr43254: another side > effect of -lm is to prevent the run of dsymutil even with -g. my 0,02 euro... 1. the whole dsymutil thing is a mess and needs sorting out separately - it's not being run at all for Fortran at the moment - and it's inconsistent in any event (not run when only objects are present on the cl, for e.g.) .. I'm going to take a look at that - but need to discuss with people what the 'correct' behavior should be. 2. we should test what is intended: (a) ergo Jack should submit his patch (at comment 23) to DejaGnu - if -lm is not needed on Darwin > x it should not be applied (b) whilst it is "the User's Problem" if they put the wrong libraries on the C/L, IMO we should try to help them .. therefore we should control the placement and/or inclusion of lm (this is already done for Fortran and we have a "" don't include for g++ - so there's a precedent). 3. maybe we need to look at how to work around the debug generation for darwin < 10 ; it's unlikely that dsymutil will be updated on those systems and, as of now, it's not part of the Open Source stuff so we can't fix it ourselves. = assuming people agree with the philosophy of 2. --- on the "How To" side. = It seems one can't use %http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug fortran/34554] time compiling complicated size initialization expression
--- Comment #11 from dominiq at lps dot ens dot fr 2010-04-11 08:26 --- > + /* If we can successfully get an array element at the max array size then s/can/cannot/ ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34554
[Bug fortran/34554] time compiling complicated size initialization expression
--- Comment #10 from dominiq at lps dot ens dot fr 2010-04-11 08:11 --- With the patch in comment #9 applied to the fortran-exp branch, the timing for the original test is slightly slower than trunk ~250s compared to ~240s. Note that the procedure node_copy_and_append should be deleted otherwise you get the error: cc1: warnings being treated as errors ../../cons_clean/gcc/fortran/constructor.c:65:1: error: 'node_copy_and_append' defined but not used make[3]: *** [fortran/constructor.o] Error 1 make[3]: *** Waiting for unfinished jobs make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [all] Error 2 Thanks for the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34554
