[Bug libstdc++/60448] swap_ranges does not use ADL correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60448 --- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Marc Glisse from comment #6) libc++ sfinae constrains std::swap. Aha! I suppose we could do that too, but that would be an enhancement (and have to wait until after the 4.9 release), but apart from that I think we agree now this is not a bug.
[Bug tree-optimization/60454] Code mistakenly detected as doing bswap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60454 --- Comment #1 from Thomas Preud'homme thomas.preudhomme at arm dot com --- Created attachment 32297 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32297action=edit Unpreprocessed testcase for incorrect bswap detection
[Bug libstdc++/60448] swap_ranges does not use ADL correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60448 --- Comment #11 from Alisdair Meredith public at alisdairm dot net --- Created attachment 32298 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32298action=edit Portable test of ADL on local type Agreed, not-a-bug. For completeness, I attach a final test case that does perform ADL on a local class to unambiguously find the right 'swap', properly using CRTP to inject the friend that is the strongest match. Thanks to David Rodriguez Ibeas for the exact syntax to make this example work. This example works correctly with both libstdc++ and libc++ - no bug. Can I withdraw/close the issue myself? (don't know gcc bug system for handling user-error)
[Bug tree-optimization/60452] [4.8/4.9 Regression] wrong code at -O1 on x86_64-linux-gnu (affecting trunk and 4.8.x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60452 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-07 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.8.3 Summary|wrong code at -O1 on|[4.8/4.9 Regression] wrong |x86_64-linux-gnu (affecting |code at -O1 on |trunk and 4.8.x)|x86_64-linux-gnu (affecting ||trunk and 4.8.x) Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r192946. Looking into it.
[Bug tree-optimization/60454] [4.7/4.8/4.9 Regression] Code mistakenly detected as doing bswap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60454 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-07 CC||wschmidt at gcc dot gnu.org Target Milestone|--- |4.7.4 Summary|Code mistakenly detected as |[4.7/4.8/4.9 Regression] |doing bswap |Code mistakenly detected as ||doing bswap Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. Regression from bswap pass introduction. Bill, can you have a look?
[Bug tree-optimization/60452] [4.8/4.9 Regression] wrong code at -O1 on x86_64-linux-gnu (affecting trunk and 4.8.x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60452 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2
[Bug debug/60438] dwarf2cfi :2239 still assert,not the same cause as PR 59575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438 --- Comment #4 from linzj manjian2006 at gmail dot com --- Further debug show this push op is gen by sched2 pass
[Bug target/60451] X86 vectorization improve: pack instead of pshufb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60451 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-07 Component|tree-optimization |target Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug lto/60449] Merging function DECLs discards leaf attribute which causes cfg verifier to fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60449 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Shouldn't fixup_cfg fix this up? Simply prefering the decl with attributes isn't enough if you attach an urelated attribute to both fns as well.
[Bug lto/60449] Merging function DECLs discards leaf attribute which causes cfg verifier to fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60449 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- OTOH, why do we have to merge the decls/cgraph nodes at all? Can't we simply make them aliases if tree merging decides the decls are not equal?
[Bug debug/60438] dwarf2cfi :2239 still assert,not the same cause as PR 59575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438 --- Comment #5 from linzj manjian2006 at gmail dot com --- No confirm yet! (In reply to linzj from comment #4) Further debug show this push op is gen by sched2 pass
[Bug tree-optimization/60454] [4.7/4.8/4.9 Regression] Code mistakenly detected as doing bswap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60454 --- Comment #3 from Thomas Preud'homme thomas.preudhomme at arm dot com --- Created attachment 32299 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32299action=edit Fix_bswap_detection See in attachment for the patch I wrote to fix the issue. I'm welcoming any comment on it.
[Bug libstdc++/60448] swap_ranges does not use ADL correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60448 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org --- Yes, as reporter you can close it, the usual status for user error is RESOLVED-INVALID, which I've now set it to.
[Bug middle-end/60418] [4.9 Regression] 435.gromacs in SPEC CPU 2006 is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418 --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to H.J. Lu from comment #8) With LTO, current_loops-state may not be set and loops_state_satisfies_p () may always be false. It's zero. It probably should be LOOPS_MAY_HAVE_MULTIPLE_LATCHES, but that doesn't change anything ;)
[Bug middle-end/60418] [4.9 Regression] 435.gromacs in SPEC CPU 2006 is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #13 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to H.J. Lu from comment #10) Sources have many FP loops contains codes like: rsq11 = dx11*dx11+dy11*dy11+dz11*dz11; When they are compiled with -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin LTO input IRs contain statements like powmult_241 = dy11_71 * dy11_71; powmult_240 = dz11_72 * dz11_72; _699 = powmult_240 + powmult_80; rsq11_77 = _699 + powmult_241; During the final LTO link, lto1 repeatedly removes loop a preheader in one pass and adds it back in the next pass. Each removal/add changes the statements to powmult_213 = dy11_71 * dy11_71; _75 = powmult_213 + powmult_80; powmult_244 = dz11_72 * dz11_72; rsq11_77 = _75 + powmult_244; Each such re-order may change the FP result slightly. They can accumulate to such a degree that the end result is outside of tolerance. Huh, adding a pre-header should _never_ do sth like that. Can you produce a small testcase that exhibits these kind of changes with adding/removing a preheader?
[Bug tree-optimization/60454] [4.7/4.8/4.9 Regression] Code mistakenly detected as doing bswap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60454 Thomas Preud'homme thomas.preudhomme at arm dot com changed: What|Removed |Added Attachment #32299|0 |1 is obsolete|| --- Comment #4 from Thomas Preud'homme thomas.preudhomme at arm dot com --- Created attachment 32300 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32300action=edit Fix_bswap_detection_with_ChangeLog Added ChangeLog entries to previous patch.
[Bug debug/60438] dwarf2cfi :2239 still assert,not the same cause as PR 59575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
--- Comment #6 from linzj manjian2006 at gmail dot com ---
The push edx is gen by originally fop_sf_2_i387.
(insn 180 281 288 17 (set (reg:SF 9 st(1) [orig:153 D.227396 ] [153])
(mult:SF (float:SF (reg:SI 1 dx [160]))
(reg:SF 9 st(1) [orig:153 D.227396 ] [153])))
/home/linzj/src/u3/shell-git/core/WebCore/rendering/RenderImage.cpp:98 671
{*fop_sf_2_i387}
(nil))
in the split2 pass.
[Bug tree-optimization/60452] [4.8/4.9 Regression] wrong code at -O1 on x86_64-linux-gnu (affecting trunk and 4.8.x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60452
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
Can be simplified into:
int a;
int
main ()
{
int e[2] = { 0, 0 }, f = 0;
if (a == 131072)
f = e[a];
return f;
}
which then starts to crash even starting from 4.3 or so (in between r125500 and
r126000).
The problem is that ifcvt.c doesn't consider e[131072], clearly out of bound
access to an automatic array, as possibly trapping/faulting.
[Bug debug/60438] dwarf2cfi :2239 still assert,not the same cause as PR 59575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
--- Comment #7 from linzj manjian2006 at gmail dot com ---
confirm that in csa pass:
(insn 288 281 289 17 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A8])
(reg:SI 1 dx [160]))
/home/linzj/src/u3/shell-git/core/WebCore/rendering/RenderImage.cpp:98 64
{*pushsi2}
(expr_list:REG_DEAD (reg:SI 1 dx [160])
(nil)))
(insn 289 288 290 17 (set (reg:SF 9 st(1) [orig:153 D.227396 ] [153])
(mult:SF (float:SF (mem:SI (reg/f:SI 7 sp) [0 S4 A8]))
(reg:SF 9 st(1) [orig:153 D.227396 ] [153])))
/home/linzj/src/u3/shell-git/core/WebCore/rendering/RenderImage.cpp:98 671
{*fop_sf_2_i387}
(nil))
(insn 290 289 273 17 (set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int 4 [0x4])))
/home/linzj/src/u3/shell-git/core/WebCore/rendering/RenderImage.cpp:98 235
{*leasi}
(nil))
...
(insn 200 264 259 17 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int 12 [0xc])))
(clobber (reg:CC 17 flags))
])
/home/linzj/src/u3/shell-git/core/WebCore/platform/graphics/IntSize.h:65 241
{*addsi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_ARGS_SIZE (const_int 0 [0])
(nil
(jump_insn 259 200 260 17 (set (pc)
(label_ref 102)) 570 {jump}
(nil)
- 102)
is combined as
(insn 288 281 289 17 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A8])
(reg:SI 1 dx [160]))
/home/linzj/src/u3/shell-git/core/WebCore/rendering/RenderImage.cpp:98 64
{*pushsi2}
(expr_list:REG_DEAD (reg:SI 1 dx [160])
(nil)))
(insn 289 288 273 17 (set (reg:SF 9 st(1) [orig:153 D.227396 ] [153])
(mult:SF (float:SF (mem:SI (reg/f:SI 7 sp) [0 S4 A8]))
(reg:SF 9 st(1) [orig:153 D.227396 ] [153])))
/home/linzj/src/u3/shell-git/core/WebCore/rendering/RenderImage.cpp:98 671
{*fop_sf_2_i387}
(nil))
...
(insn 200 264 259 17 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int 16 [0x10])))
(clobber (reg:CC 17 flags))
])
/home/linzj/src/u3/shell-git/core/WebCore/platform/graphics/IntSize.h:65 241
{*addsi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_ARGS_SIZE (const_int 0 [0])
(nil
(jump_insn 259 200 260 17 (set (pc)
(label_ref 102)) 570 {jump}
(nil)
- 102)
12 + 4 - 4 - 12 is changed to 12 + 4 - 16
but REG_ARGS_SIZE is forgotten here.
[Bug libstdc++/60448] swap_ranges does not use ADL correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60448 --- Comment #13 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #10) (In reply to Marc Glisse from comment #6) libc++ sfinae constrains std::swap. Aha! I suppose we could do that too, Indeed. I could never estimate the drawbacks properly. Doesn't it force types to be complete earlier than it would otherwise? It probably isn't that bad if libc++ got away with it.
[Bug lto/60449] Merging function DECLs discards leaf attribute which causes cfg verifier to fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60449 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #7 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to Richard Biener from comment #5) Shouldn't fixup_cfg fix this up? Simply prefering the decl with attributes isn't enough if you attach an urelated attribute to both fns as well. Yes, I know. I did not really mean to call it a proposed fix, did that somewhat automatically. On the other hand, I am able to slim-LTO build Firefox with the patch though. (In reply to Richard Biener from comment #6) OTOH, why do we have to merge the decls/cgraph nodes at all? Can't we simply make them aliases if tree merging decides the decls are not equal? Good idea, this might indeed be the best way to fix this. (Although I do not really know what needs to be done to turn a previously proper decl and its symtab node into an alias. Honza, do you think it would be difficult?).
[Bug debug/60438] dwarf2cfi :2239 still assert,not the same cause as PR 59575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438 --- Comment #8 from linzj manjian2006 at gmail dot com --- Okay let me sum it up: at first the code looks like this call xxx: .cfa 92 float ops add sp 12 .cfa 80 And then split2 splits the float ops,then it looks like this call xxx: .cfa 92 push edx float ops2 add sp 4 ... add sp 12 .cfa 80 Note that the split code has a sp ops but no cfa notes. And then cfa feels that's ugly,it changes the code to call xxx : .cfa 92 push edx float ops2 ... add sp 16 .cfa 80 And then jump2 finds another branch also has an add sp 16 .cfa 80,so the combination has occurred: call xxx :.cfa 92 push edx float ops2 ... label jump_from_other_branch ( (hasRelativeWidth || hasRelativeHeight) == true ) add sp 16 .cfa 80 then dwarf2cfi.c will first find the add sp 16 .cfa 80 row has cfa 92 coming first,and then cfa 96.
[Bug tree-optimization/60452] [4.8/4.9 Regression] wrong code at -O1 on x86_64-linux-gnu (affecting trunk and 4.8.x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60452
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
If I modify the shorter testcase such that int e[2]; is a static array, then we
don't generate cmove for it, because on:
(mem:SI (const:DI (plus:DI (symbol_ref:DI (e) var_decl 0x719d6098 e)
(const_int 524288 [0x8]))) [2 e+524288 S4 A32])
may_trap_or_fault_p returns true (correctly). But in the case of automatic
out-of-bound access we get instead:
(mem/c:SI (plus:DI (reg/f:DI 20 frame)
(const_int 524272 [0x7fff0])) [2 S4 A128])
and there may_trap_or_fault_p really can't (easily) know if it is valid or not,
there is no MEM_EXPR even. This is because in the #c2 testcase as well as the
original one DECL_RTL of e variable is a register, not MEM.
But even if I try:
int a;
__attribute__((noinline, noclone)) void
foo (int *e)
{
asm volatile ( : : r (e) : memory);
}
int
main ()
{
int e[2] = { 0, 0 }, f = 0;
if (a == 131072)
f = e[a];
foo (e);
return f;
}
where we have:
(mem:SI (plus:DI (reg/f:DI 20 frame)
(const_int 524272 [0x7fff0])) [2 e+524288 S4 A128])
instead and thus from MEM_EXPR we perhaps could find out that it is an out of
bound access, we still always treat all frame based accesses (whatever the
offset is) as non-trapping.
So perhaps we need to handle known out of bound MEMs specially when we find
that fact out (if we want to emit them into the RTL IL at all), one thing is
expansion, another thing if say initially non-constant offset is later
CSEd/forwprop etc. into constant out of bound offset.
Thoughts?
[Bug tree-optimization/60452] [4.8/4.9 Regression] wrong code at -O1 on x86_64-linux-gnu (affecting trunk and 4.8.x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60452 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Perhaps some new flag (MEM access will always fault?) or something similar.
[Bug c/60455] New: Imprecise column number of -Woverflow in array initializers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60455
Bug ID: 60455
Summary: Imprecise column number of -Woverflow in array
initializers
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
$: cat s.c
char a[] = {0x, 4, 0x};
$: gcc-trunk -c s.c
s.c:1:1: warning: overflow in implicit constant conversion [-Woverflow]
char a[] = {0x, 4, 0x};
^
s.c:1:1: warning: overflow in implicit constant conversion [-Woverflow]
$: gcc-trunk --version
gcc (GCC) 4.9.0 20140306 (experimental)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug libstdc++/60448] swap_ranges does not use ADL correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60448 --- Comment #14 from Alisdair Meredith public at alisdairm dot net --- Among other things, it lets fools like me write code relying on a behavior, not realizing that the code is not portable. As a user I swing between the convenience of having that utility, vs. the inconvenience of it being an extension rather than mandated. Other issues are whether rampant use of SFINAE tricks has an impact on resource usage during compilation, and more confusing error messages along the lines of I could not find this function that you have clearly supplied. With Concepts Lite coming, there should be a cleaner way in the language to get the same effects, so as a single user data point, I would prefer to defer any non-standard-mandated changes along these lines until after Concepts lands - in whatever form that turns out to be. More research demonstrating the cost is really not significant in medium-large scale software might soften my view.
[Bug tree-optimization/60454] [4.7/4.8/4.9 Regression] Code mistakenly detected as doing bswap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60454 --- Comment #5 from Thomas Preud'homme thomas.preudhomme at arm dot com --- I have posted the patch on gcc-patches mailing list. The discussion can be followed from http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00313.html.
[Bug rtl-optimization/60456] New: Uninitialized read in copy_rtx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60456 Bug ID: 60456 Summary: Uninitialized read in copy_rtx Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: eugeni.stepanov at gmail dot com Created attachment 32301 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32301action=edit proof ==26761== WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x7f2c4996caa9 in copy_rtx(rtx_def*) build-msan/gcc/../../gcc/rtl.c:263:42 #1 0x7f2c49992513 in process_rtx(rtx_def*, int) build-msan/gcc/../../gcc/gensupport.c:535 #2 0x7f2c49992513 in rtx_handle_directive(int, char const*) build-msan/gcc/../../gcc/gensupport.c:2243 #3 0x7f2c499c4540 in handle_file(void (*)(int, char const*)) build-msan/gcc/../../gcc/read-md.c:984 #4 0x7f2c499c39bd in handle_toplevel_file(void (*)(int, char const*)) build-msan/gcc/../../gcc/read-md.c:1010 #5 0x7f2c499c2176 in read_md_files(int, char**, bool (*)(char const*), void (*)(int, char const*)) build-msan/gcc/../../gcc/read-md.c:1138 #6 0x7f2c4998a397 in init_rtx_reader_args_cb(int, char**, bool (*)(char const*)) build-msan/gcc/../../gcc/gensupport.c:2504 #7 0x7f2c4996017c in main build-msan/gcc/../../gcc/genpreds.c:1369 Uninitialized value was created by a heap allocation #0 0x7f2c4990579d in malloc /code/llvm/build0/../projects/compiler-rt/lib/msan/msan_interceptors.cc:781 #1 0x7f2c499d4d80 in xmalloc build-msan/build-x86_64-unknown-linux-gnu/libiberty/../../../libiberty/xmalloc.c:147 #2 0x7f2c499878e9 in ggc_internal_alloc_stat(unsigned long) build-msan/gcc/../../gcc/ggc-none.c:46 #3 0x7f2c4996b469 in ggc_alloc_rtx_def_stat(unsigned long) build-msan/gcc/../../gcc/ggc.h:257 #4 0x7f2c4996afdc in rtx_alloc_stat(rtx_code) build-msan/gcc/../../gcc/rtl.c:195:12 #5 0x7f2c49980e84 in read_rtx_code(char const*) build-msan/gcc/../../gcc/read-rtl.c:1127 #6 0x7f2c49984c52 in read_nested_rtx() build-msan/gcc/../../gcc/read-rtl.c:1351 #7 0x7f2c499814fe in read_rtx_code(char const*) build-msan/gcc/../../gcc/read-rtl.c:1156 #8 0x7f2c49984c52 in read_nested_rtx() build-msan/gcc/../../gcc/read-rtl.c:1351 #9 0x7f2c49982c7b in read_rtx_code(char const*) build-msan/gcc/../../gcc/read-rtl.c:1190 #10 0x7f2c4997c44d in read_rtx(char const*, rtx_def**) build-msan/gcc/../../gcc/read-rtl.c:1084 #11 0x7f2c49991d39 in rtx_handle_directive(int, char const*) build-msan/gcc/../../gcc/gensupport.c:2241 #12 0x7f2c499c4540 in handle_file(void (*)(int, char const*)) build-msan/gcc/../../gcc/read-md.c:984 #13 0x7f2c499c39bd in handle_toplevel_file(void (*)(int, char const*)) build-msan/gcc/../../gcc/read-md.c:1010 #14 0x7f2c499c2176 in read_md_files(int, char**, bool (*)(char const*), void (*)(int, char const*)) build-msan/gcc/../../gcc/read-md.c:1138 #15 0x7f2c4998a397 in init_rtx_reader_args_cb(int, char**, bool (*)(char const*)) build-msan/gcc/../../gcc/gensupport.c:2504 #16 0x7f2c4996017c in main build-msan/gcc/../../gcc/genpreds.c:1369 Uninitialized memory comes from this expression on line 263: ORIGINAL_REGNO (XEXP (orig, 0)) To verify, apply the attached patch, go the build directory and run ./gcc/build/genpreds -h ../gcc/config/i386/i386.md The patch fills malloc()-ed memory with a specific pattern and then finds that pattern at the line above.
[Bug fortran/59746] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59746 --- Comment #3 from Bud Davis bdavis at gcc dot gnu.org --- Not so fast... Made a test for it: !pr59746 CALL RCCFL(NVE,IR,NU3,VE(1,1,1,I)) COMMON /CCFILE/ INTG,NT1,NT2,NT3,NVM,NVE,NFRLE,NRESF,NRESL COMMON /CCFILE/ INTG,NT1,NT2,NT3,NVM,NVE,NFRLE,NRESF,NRESL ! the PR only contained the two above. ! success is no segfaults or infinite loops. ! let's check some combinations CALL ABC (INTG) COMMON /CCFILE/ INTG,NT1,NT2,NT3,NVM,NVE,NFRLE,NRESF,NRESL COMMON /CCFILE/ INTG,NT1,NT2,NT3,NVM,NVE,NFRLE,NRESF,NRESL CALL DEF (NT1) COMMON /CCFILE/ INTG,NT1,NT2,NT3,NVM,NVE,NFRLE,NRESF,NRESL COMMON /CCFILE/ INTG,NT1,NT2,NT3,NVM,NVE,NFRLE,NRESF,NRESL CALL GHI (NRESL) COMMON /CCFILE/ INTG,NT1,NT2,NT3,NVM,NVE,NFRLE,NRESF,NRESL COMMON /CCFILE/ INTG,NT1,NT2,NT3,NVM,NVE,NFRLE,NRESF,NRESL END And all the 'extras' also cause a segfault.
[Bug middle-end/60429] Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Allan Jensen from comment #6) I posted like this in case the description would be enough to make someone know where to look. If you need to debug it and dig into it, I will try to make a proper reduced test case. That would be nice.
[Bug tree-optimization/60452] [4.8/4.9 Regression] wrong code at -O1 on x86_64-linux-gnu (affecting trunk and 4.8.x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60452 Mikael Pettersson mikpelinux at gmail dot com changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #5 from Mikael Pettersson mikpelinux at gmail dot com --- (In reply to Jakub Jelinek from comment #2) The problem is that ifcvt.c doesn't consider e[131072], clearly out of bound access to an automatic array, as possibly trapping/faulting. Thus this one looks related to PR50588.
[Bug bootstrap/58572] [4.9 regression] make bootstrap-lean leads to installation failure (doing extra rebuilds and invoking system compiler)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58572 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Fri Mar 7 12:58:27 2014 New Revision: 208400 URL: http://gcc.gnu.org/viewcvs?rev=208400root=gccview=rev Log: PR bootstrap/58572 * Makefile.tpl (POSTSTAGE1_CXX_EXPORT): Use -isystem instead of -I for libstdc++-v3 includes if $(LEAN). * Makefile.in: Regenerated. Modified: trunk/ChangeLog trunk/Makefile.in trunk/Makefile.tpl
[Bug rtl-optimization/60456] Uninitialized read in copy_rtx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60456 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01824.html aka r207230 ?
[Bug bootstrap/58572] [4.9 regression] make bootstrap-lean leads to installation failure (doing extra rebuilds and invoking system compiler)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58572 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Should be fixed now.
[Bug rtl-optimization/60456] Uninitialized read in copy_rtx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60456 Evgeniy Stepanov eugeni.stepanov at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Evgeniy Stepanov eugeni.stepanov at gmail dot com --- Yeah, that's it. I should run on trunk next time.
[Bug fortran/60450] [4.7/4.8 Regression] ICE with SHAPE intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60450 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-07 CC||janus at gcc dot gnu.org Summary|ICE with SHAPE intrinsic|[4.7/4.8 Regression] ICE ||with SHAPE intrinsic Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- The test case compiles cleanly here with 4.4 and 4.6, then I get segfaults with 4.7 and 4.8 and it works again with trunk. With a current 4.8 branch build I get this backtrace: f951: internal compiler error: Segmentation fault 0x8a96af crash_signal /home/jweil/gcc48/branch/gcc/toplev.c:332 0x547d8b gfc_clear_shape(__mpz_struct (*) [1], int) /home/jweil/gcc48/branch/gcc/fortran/expr.c:405 0x5b5d70 gfc_simplify_shape(gfc_expr*, gfc_expr*) /home/jweil/gcc48/branch/gcc/fortran/simplify.c:5540 0x5567d1 do_simplify /home/jweil/gcc48/branch/gcc/fortran/intrinsic.c:3810 0x563e66 gfc_intrinsic_func_interface(gfc_expr*, int) /home/jweil/gcc48/branch/gcc/fortran/intrinsic.c:4160 0x59fe51 resolve_unknown_f /home/jweil/gcc48/branch/gcc/fortran/resolve.c:2602 0x59fe51 resolve_function /home/jweil/gcc48/branch/gcc/fortran/resolve.c:3204 0x59fe51 gfc_resolve_expr(gfc_expr*) /home/jweil/gcc48/branch/gcc/fortran/resolve.c:6544 0x5a66e1 resolve_code /home/jweil/gcc48/branch/gcc/fortran/resolve.c:10208 0x5a8b8e resolve_codes /home/jweil/gcc48/branch/gcc/fortran/resolve.c:15061 0x599562 gfc_resolve /home/jweil/gcc48/branch/gcc/fortran/resolve.c:15089 0x58dda2 resolve_all_program_units /home/jweil/gcc48/branch/gcc/fortran/parse.c:4406 0x58dda2 gfc_parse_file() /home/jweil/gcc48/branch/gcc/fortran/parse.c:4673 0x5c9de5 gfc_be_parse_file /home/jweil/gcc48/branch/gcc/fortran/f95-lang.c:189
[Bug debug/60438] dwarf2cfi :2239 still assert,not the same cause as PR 59575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438 --- Comment #9 from linzj manjian2006 at gmail dot com --- I have tried to modify i386.c to make ix86_force_to_memoryix86_free_from_memory to generate frame related insn.That causes another problem.Seems the only way to go is have a look at jump2. The another problem: ARGS_SIZE 12 .cfa_offset 12 push xxx .cfa_offset 16 ... ARGS_SIZE 0.cfa_offset 4 see?There is an orphan 4!
[Bug bootstrap/58572] [4.9 regression] make bootstrap-lean leads to installation failure (doing extra rebuilds and invoking system compiler)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58572 --- Comment #11 from Mario Held mario.held at de dot ibm.com --- Checked out revision 208400 and did a make -j NUM_CPUS bootstrap-lean 1$OUTPUT 21 on s390x (IBM System z). Success, works as expected.
[Bug fortran/60450] [4.7/4.8 Regression] ICE with SHAPE intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60450 --- Comment #2 from janus at gcc dot gnu.org --- Slightly reduced test case: real, allocatable :: x(:,:) allocate (x(3,2),source=99.) print *, shape (x / 10.0) end Still works with 4.6 and trunk, but ICEs with 4.7 and 4.8.
[Bug fortran/60450] [4.7/4.8 Regression] ICE with SHAPE intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60450
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
--- Comment #3 from janus at gcc dot gnu.org ---
The following patch is sufficient to fix it on 4.8:
Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c(revision 208401)
+++ gcc/fortran/simplify.c(working copy)
@@ -5528,7 +5528,7 @@ gfc_simplify_shape (gfc_expr *source, gfc_expr *ki
if (e == gfc_bad_expr || range_check (e, SHAPE) == gfc_bad_expr)
{
gfc_free_expr (result);
- if (t)
+ if (t == SUCCESS)
gfc_clear_shape (shape, source-rank);
return gfc_bad_expr;
}
@@ -5536,7 +5536,7 @@ gfc_simplify_shape (gfc_expr *source, gfc_expr *ki
gfc_constructor_append_expr (result-value.constructor, e, NULL);
}
- if (t)
+ if (t == SUCCESS)
gfc_clear_shape (shape, source-rank);
return result;
On trunk, 't' was changed from 'gfc_try' to bool in r197682, which also fixed
the problem.
[Bug ipa/60457] New: [4.9 Regression] ICE in cgraph_get_node
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60457
Bug ID: 60457
Summary: [4.9 Regression] ICE in cgraph_get_node
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
template class T
struct A
{
};
struct B : A B
{
B ();
};
B::B ()
{
const int c[] = { 1, 1 };
}
ICEs at -O0 starting with r201408.
[Bug ipa/60457] [4.9 Regression] ICE in cgraph_get_node
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60457 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-07 Target Milestone|--- |4.9.0 Ever confirmed|0 |1
[Bug ipa/60457] [4.9 Regression] ICE in cgraph_get_node
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60457 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 CC||mpolacek at gcc dot gnu.org
[Bug ipa/60457] [4.9 Regression] ICE in cgraph_get_node
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60457 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 32302 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32302action=edit gcc49-pr60457.patch Perhaps something like this can fix this? From the patch description it seems you were after functions only.
[Bug middle-end/60429] Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 --- Comment #8 from Allan Jensen linux at carewolf dot com --- Created attachment 32303 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32303action=edit Reduced test
[Bug ipa/60457] [4.9 Regression] ICE in cgraph_get_node
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60457 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Honza?
[Bug middle-end/60429] Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 --- Comment #9 from Allan Jensen linux at carewolf dot com --- Created attachment 32304 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32304action=edit Reduced test assembler
[Bug middle-end/60429] Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 --- Comment #10 from Allan Jensen linux at carewolf dot com --- I have uploaded a reduced test. Compiled with -O0 or -O1 it outputs 180, compiled with -O2 or higher it outputs 179.
[Bug middle-end/60429] Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 --- Comment #11 from Allan Jensen linux at carewolf dot com --- Note that to run it, it links against Qt5Core.
[Bug fortran/60458] New: Error message on associate: deferred type parameter and requires either the pointer or allocatable attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60458 Bug ID: 60458 Summary: Error message on associate: deferred type parameter and requires either the pointer or allocatable attribute Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info module A Type T contains procedure :: Test procedure :: TestP end type contains subroutine test(this) class(T) this associate(S= this%TestP()) print *,S end associate end subroutine function TestP(this) class(T) this character(LEN=:), allocatable :: TestP TestP ='' end function TestP end module gives error associate(S= this%TestP()) 1 Error: Entity 's' at (1) has a deferred type parameter and requires either the pointer or allocatable attribute At best the error message is unhelpful (defining S with pointer attribute does not help), and the code seems valid (though it also happens to ICE ifort).
[Bug c++/60459] New: Crash seen in _Unwind_VRS_Pop() for ARM platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60459
Bug ID: 60459
Summary: Crash seen in _Unwind_VRS_Pop() for ARM platform
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: raghupv30 at gmail dot com
Hi,
With ARM target platform, crashes in _Unwind_VRS_Pop() during exception
propagation.
Below is the stack trace:
Program terminated with signal 11, Segmentation fault.
#0 _Unwind_VRS_Pop (context=0x1140bf4, regclass=optimized out,
discriminator=optimized out, representation=_UVRSD_UINT32) at
/home/ben/Katalix/Toolchain/drx780-build/stb_toolchain_2.1/toolchain_build_arm_nofpu/gcc-4.2.1/gcc/config/arm/unwind-arm.c:269
#0 _Unwind_VRS_Pop (context=0x1140bf4, regclass=optimized out,
discriminator=optimized out, representation=_UVRSD_UINT32) at
/home/ben/Katalix/Toolchain/drx780-build/stb_toolchain_2.1/toolchain_build_arm_nofpu/gcc-4.2.1/gcc/config/arm/unwind-arm.c:269
ptr = 0x4
mask = 16384
i = 14
#1 0x1a5ac6f8 in __gnu_unwind_execute (context=0x1140bc0, uws=0x1140b80) at
/home/ben/Katalix/Toolchain/drx780-build/stb_toolchain_2.1/toolchain_build_arm_nofpu/gcc-4.2.1/gcc/config/arm/pr-support.c:157
op = 16384
set_pc = 0
reg = 1
#2 0x1a5abdf0 in __gnu_unwind_pr_common (state=_US_UNWIND_FRAME_STARTING,
ucbp=0x11416f8, context=0x1140bc0, id=1) at
/home/ben/Katalix/Toolchain/drx780-build/stb_toolchain_2.1/toolchain_build_arm_nofpu/gcc-4.2.1/gcc/config/arm/unwind-arm.c:974
uws =
{data = 0, next = 0xb14aa8, bytes_left = 0 '\000', words_left = 0 '\000'}
data = optimized out
offset = 8
len = 18091248
rtti_count = 18091248
phase2_call_unexpected_after_unwind = 9
in_range = optimized out
forced_unwind = 18093816
#3 0x1b09d6dc in ?? ()
No symbol table info available.
#4 0x1b09d6dc in ?? ()
No symbol table info available.
Analysing the core dump:
(gdb) x/24i _Unwind_VRS_Pop
0x1a5ac34c _Unwind_VRS_Pop:push{r4, r5, r6, r7, r8, r10, lr}
0x1a5ac350 _Unwind_VRS_Pop+4: mov r7, r0
0x1a5ac354 _Unwind_VRS_Pop+8: sub sp, sp, #140; 0x8c
0x1a5ac358 _Unwind_VRS_Pop+12: mov r5, r3
0x1a5ac35c _Unwind_VRS_Pop+16: cmp r1, #4
0x1a5ac360 _Unwind_VRS_Pop+20: addls pc, pc, r1, lsl #2
0x1a5ac364 _Unwind_VRS_Pop+24: b 0x1a5ac468
_Unwind_VRS_Pop+284
0x1a5ac368 _Unwind_VRS_Pop+28: b 0x1a5ac384 _Unwind_VRS_Pop+56
0x1a5ac36c _Unwind_VRS_Pop+32: b 0x1a5ac3cc
_Unwind_VRS_Pop+128
0x1a5ac370 _Unwind_VRS_Pop+36: b 0x1a5ac37c _Unwind_VRS_Pop+48
0x1a5ac374 _Unwind_VRS_Pop+40: b 0x1a5ac37c _Unwind_VRS_Pop+48
0x1a5ac378 _Unwind_VRS_Pop+44: b 0x1a5ac37c _Unwind_VRS_Pop+48
0x1a5ac37c _Unwind_VRS_Pop+48: mov r0, #1
0x1a5ac380 _Unwind_VRS_Pop+52: b 0x1a5ac46c
_Unwind_VRS_Pop+288
0x1a5ac384 _Unwind_VRS_Pop+56: cmp r3, #0
0x1a5ac388 _Unwind_VRS_Pop+60: bne 0x1a5ac468
_Unwind_VRS_Pop+284
0x1a5ac38c _Unwind_VRS_Pop+64: lsl r2, r2, #16
0x1a5ac390 _Unwind_VRS_Pop+68: ldr r12, [r0, #56] ; 0x38
0x1a5ac394 _Unwind_VRS_Pop+72: lsr r2, r2, #16
0x1a5ac398 _Unwind_VRS_Pop+76: mov r1, r3
0x1a5ac39c _Unwind_VRS_Pop+80: mov lr, #1
0x1a5ac3a0 _Unwind_VRS_Pop+84: andsr3, r2, lr, lsl r1
= 0x1a5ac3a4 _Unwind_VRS_Pop+88: ldrne r3, [r12], #4
0x1a5ac3a8 _Unwind_VRS_Pop+92: add r0, r7, r1, lsl #2
(gdb) info locals
ptr = 0xfa
mask = 26624 = 0x6800
i = 11
print ptr
$1 = (_uw *) 0xfa
(gdb) print *ptr
Cannot access memory at address 0xfa
(gdb) info reg
r0 0x11a6be818508776
r1 0xb 11
r2 0x6800 26624
r3 0x8002048
r4 0x86800 550912
r5 0x0 0
r6 0x11a6bc018508736
r7 0x11a6bc018508736
r8 0x0 0
r9 0xff04080
r100x11a6b4418508612
r110x1a5b5f2c 442195756
r120xfa 250
sp 0x11a6a900x11a6a90
lr 0x1 1
pc 0x1a5ac3a4 0x1a5ac3a4 _Unwind_VRS_Pop+88
cpsr 0x10 16
Using the gcc in http://ftp.gnu.org/gnu/gcc/gcc-4.2.1/gcc-core-4.2.1.tar.bz2
Is anyone aware of the reason for this crash in _Unwind_VRS_Pop() for ARM
platform?
Thanks in advance
-Raghu
[Bug rtl-optimization/60159] improve code for conditional sibcall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60159 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com --- Comment #2 from Jeffrey A. Law law at redhat dot com --- Lots of things mess up debug info :-) This seems reasonably desirable to me and shouldn't be terribly difficult to implement, possibly guarding it on -Og.
[Bug debug/60438] dwarf2cfi :2239 still assert,not the same cause as PR 59575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438 --- Comment #10 from linzj manjian2006 at gmail dot com --- Adding a -fno-crossjumping compile flag stops the assertion.
[Bug fortran/60450] [4.7/4.8 Regression] ICE with SHAPE intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60450 --- Comment #4 from janus at gcc dot gnu.org --- (In reply to janus from comment #3) The following patch is sufficient to fix it on 4.8: ... and regtests cleanly.
[Bug c++/55004] [meta-bug] constexpr issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 58609, which changed state. Bug 58609 Summary: [4.9 Regression] [c++11] ICE with uninitialized variable in constexpr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58609 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/58609] [4.9 Regression] [c++11] ICE with uninitialized variable in constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58609 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed.
[Bug c++/58609] [4.9 Regression] [c++11] ICE with uninitialized variable in constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58609 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Fri Mar 7 18:33:38 2014 New Revision: 208410 URL: http://gcc.gnu.org/viewcvs?rev=208410root=gccview=rev Log: /cp 2014-03-07 Paolo Carlini paolo.carl...@oracle.com PR c++/58609 * decl.c (check_initializer): Return NULL_TREE after error; consistently use inform. /testsuite 2014-03-07 Paolo Carlini paolo.carl...@oracle.com PR c++/58609 * g++.dg/cpp0x/constexpr-ice12.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ice12.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug target/60459] Crash seen in _Unwind_VRS_Pop() for ARM platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60459 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c++ |target Severity|blocker |normal --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Can you try a newer version than GCC 4.2.1? Also can you provide the exact options you compiled your source with? And the exact configure options you configured GCC with?
[Bug middle-end/60429] Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 --- Comment #12 from Andrew Pinski pinskia at gcc dot gnu.org --- tmpPtBlock-pts = reinterpret_castQPoint *(tmpPtBlock-data); Does this not violate C/C++ aliasing rules later on? I think data should be char array with the alignment of QPoint instead of an int array.
[Bug middle-end/60350] Incorrect -Wmaybe-uninitialized warning with incorrect location information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60350 --- Comment #3 from Chengnian Sun chengniansun at gmail dot com --- (In reply to Marek Polacek from comment #2) I think the maybe-used-uninitialized warning is in place here, it depends on I whether pf or pv is evaluated. The column info looks bogus indeed. Thanks, Marek. I misunderstood the meaning of maybe-used-uninitialized warnings
[Bug middle-end/60429] Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 --- Comment #13 from Allan Jensen linux at carewolf dot com --- (In reply to Andrew Pinski from comment #12) tmpPtBlock-pts = reinterpret_castQPoint *(tmpPtBlock-data); Does this not violate C/C++ aliasing rules later on? I think data should be char array with the alignment of QPoint instead of an int array. True, the data array is also four times too big for 200 QPoints because of the int type. So fixing that would lower memory consumption, but I can't see how that would break anything, since the this is casting an uninitialized structure. And it doesn't seem to fit in with the symptoms.
[Bug middle-end/60429] Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #14 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Created attachment 32305 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32305action=edit reduced testcase A bit more reduced (doesn't need external lib): markus@x4 tmp % g++ -O2 test.ii ./a.out 179 markus@x4 tmp % g++ -O1 test.ii ./a.out 180
[Bug c++/60376] [4.9 Regression] [c++1y] ICE on invalid with using declaration in template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60376 --- Comment #6 from Volker Reichelt reichelt at gcc dot gnu.org --- Just for the record: the new bug is PR60409.
[Bug middle-end/60429] Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Attachment #32305|0 |1 is obsolete|| --- Comment #15 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Created attachment 32306 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32306action=edit reduced testcase
[Bug ada/60411] ADA bootstrap failure on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411 --- Comment #3 from Arnaud Charlet charlet at gcc dot gnu.org --- Author: charlet Date: Fri Mar 7 20:35:33 2014 New Revision: 208419 URL: http://gcc.gnu.org/viewcvs?rev=208419root=gccview=rev Log: 2014-03-07 Doug Rupp r...@adacore.com PR ada/60411 * system-linux-armel.ads (Backend_Overflow_Checks): Set to True. (Support_64_Bit_Divides): Removed, no longer used. (ZCX_By_Default): Enabled. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/system-linux-armel.ads
[Bug fortran/60458] Error message on associate: deferred type parameter and requires either the pointer or allocatable attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60458
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
--- Comment #1 from janus at gcc dot gnu.org ---
I'm not fully sure if this is valid, but I tend to agree. I think the error you
get is supposed to check for C402 in Fortran 2008:
C402 (R401) A colon shall not be used as a type-param-value except in the
declaration of an entity or component that has the POINTER or ALLOCATABLE
attribute.
If I prevent it from being triggered here, via this patch ...
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 208386)
+++ gcc/fortran/resolve.c(working copy)
@@ -10784,7 +10784,8 @@ resolve_fl_variable (gfc_symbol *sym, int mp_flag)
}
/* Constraints on deferred type parameter. */
- if (sym-ts.deferred !(sym-attr.pointer || sym-attr.allocatable))
+ if (sym-ts.deferred !(sym-attr.pointer || sym-attr.allocatable)
+ !sym-attr.associate_var)
{
gfc_error (Entity '%s' at %L has a deferred type parameter and
requires either the pointer or allocatable attribute,
... then I get the following (which looks like a middle-end error):
c0.f90: In function ‘test’:
c0.f90:13:0: error: size of variable ‘s’ is too large
associate(S = this%TestP())
[Bug ada/60411] ADA bootstrap failure on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411 Arnaud Charlet charlet at gcc dot gnu.org changed: What|Removed |Added CC||charlet at gcc dot gnu.org --- Comment #4 from Arnaud Charlet charlet at gcc dot gnu.org --- Let me know how things go after the recent commit I made on trunk, thanks.
[Bug c++/60437] New: [C++11] Bogus error: no matching function for call to 'X::X(brace-enclosed initializer list)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60437
Bug ID: 60437
Summary: [C++11] Bogus error: no matching function for call to
'X::X(brace-enclosed initializer list)'
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
CC: daniel.kruegler at googlemail dot com
CC: daniel.kruegler at googlemail dot com
Using current trunk
g++ (GCC) 4.9.0 20140305 (experimental)
g++ -c t.cc -std=c++11
t.cc: In function 'void f()':
t.cc:10:8: error: no matching function for call to 'X::X(brace-enclosed
initializer list)'
X x{1};
^
t.cc:10:8: note: candidates are:
t.cc:6:3: note: X::X(std::initializer_listint)
X(std::initializer_listint init = std::initializer_listint()){}
^
t.cc:6:3: note: no known conversion for argument 1 from 'int' to
'std::initializer_listint'
t.cc:3:7: note: constexpr X::X(const X)
class X {
^
t.cc:3:7: note: no known conversion for argument 1 from 'int' to 'const X'
t.cc:3:7: note: constexpr X::X(X)
t.cc:3:7: note: no known conversion for argument 1 from 'int' to 'X'
Code accepted by clang, and is correct (AFAICT):
#include initializer_list
class X {
public:
// X(std::initializer_listint init); // OK
X(std::initializer_listint init = std::initializer_listint()){}
};
void f(){
X x{1};
}
[Bug ada/60411] ADA bootstrap failure on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411 --- Comment #5 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Arnaud Charlet from comment #4) Let me know how things go after the recent commit I made on trunk, thanks. I'll try that on monday, but how about linux-androideabi? isn't that one broken now?
[Bug fortran/60392] Problem with TRANSPOSE and CONTIGUOUS dummy arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60392 --- Comment #5 from Mikael Morin mikael at gcc dot gnu.org --- Created attachment 32307 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32307action=edit preliminary patch This removes the difference between my_mul/my_mul_cont. However this is not yet correct, with the patch the program output is: Normal: 0 7 10 15 22 7 10 15 22 Transposed: 0 5 11 11 25 5 11 11 25 and according to maxima (so rather accurate): matmul(transpose(a), a) == matrix([10, 14], [14, 20]) and matrix([5, 11], [11, 25]) == matmul(a, transpose(a)) So there remains a wrong transposition hiding somewhere.
[Bug fortran/60392] Problem with TRANSPOSE and CONTIGUOUS dummy arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60392 --- Comment #6 from Mikael Morin mikael at gcc dot gnu.org --- (In reply to Mikael Morin from comment #5) This removes the difference between my_mul/my_mul_cont. However this is not yet correct, with the patch the program output is: Maybe it's correct after all. It's matter of matrix representation in memory. I never have it right.
[Bug middle-end/60429] [4.7/4.8/4.9 Regression] Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW CC||jakub at gcc dot gnu.org Target Milestone|--- |4.7.4 Summary|Miscompilation (aliasing) |[4.7/4.8/4.9 Regression] |with -finline-functions |Miscompilation (aliasing) ||with -finline-functions --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r179799.
[Bug c++/60460] New: warn_unused_result doesn't warn on unused result when std::pair return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60460 Bug ID: 60460 Summary: warn_unused_result doesn't warn on unused result when std::pair return type Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mdennis at merfer dot net possibly doesn't warn for any templated return type. possibly related to 39808 and/or 47461. see attached for repro.
[Bug c++/60460] warn_unused_result doesn't warn on unused result when std::pair return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60460 --- Comment #1 from Matthew Dennis mdennis at merfer dot net --- Created attachment 32308 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32308action=edit reproduction of warn_unused_result problem
[Bug middle-end/60418] [4.9 Regression] 435.gromacs in SPEC CPU 2006 is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418 --- Comment #14 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Richard Biener from comment #13) Huh, adding a pre-header should _never_ do sth like that. Can you produce a small testcase that exhibits these kind of changes with adding/removing a preheader? I don't have a small testcase and it only shows up with -mx32. Here is what I see. The diffs in 064t.copyprop3 are diff -up good/gromacs.x.064t.copyprop3 bad/gromacs.x.064t.copyprop3 --- good/gromacs.x.064t.copyprop32014-03-06 13:14:22.897298915 -0800 +++ bad/gromacs.x.064t.copyprop32014-03-06 13:22:00.221999369 -0800 @@ -22774,6 +22774,7 @@ inl3300 (int restrict nri, int[0:] * r goto bb 8; bb 3: + n_213 = 1; bb 4: # n_8 = PHI 1(3), n_218(7) n_213 is unused. There are many diffs in SSA_NAME_VERSION in 066t.vrp1. Diffs in 082t.reassoc1 are diff -up good/gromacs.x.082t.reassoc1 bad/gromacs.x.082t.reassoc1 --- good/gromacs.x.082t.reassoc12014-03-06 13:14:22.948297990 -0800 +++ bad/gromacs.x.082t.reassoc12014-03-06 13:22:00.273998425 -0800 @@ -24250,11 +24250,11 @@ inl3300 (int restrict nri, int[0:] * r float _201; float _202; int _206; + float _208; float _210; float _211; float _215; float _216; - float _242; bb 2: _19 = *nri_18(D); @@ -24403,8 +24403,8 @@ inl3300 (int restrict nri, int[0:] * r ff_152 = _155 + fp_147; vnb12_153 = vv_149 * c12_116; fijr_154 = ff_152 * c12_116; - _242 = vnb12_153 + vnb6_134; - vnbtot_156 = _242 + vnbtot_11; + _208 = vnb12_153 + vnb6_134; + vnbtot_156 = _208 + vnbtot_11; _157 = fijd_135 + fijc_109; _158 = _157 + fijr_154; _159 = ((_158)); When it gets to 089t.sincos, diffs are diff -up good/gromacs.x.089t.sincos bad/gromacs.x.089t.sincos --- good/gromacs.x.089t.sincos2014-03-06 13:14:22.967297646 -0800 +++ bad/gromacs.x.089t.sincos2014-03-06 13:22:00.291998098 -0800 @@ -24252,14 +24252,14 @@ inl3300 (int restrict nri, int[0:] * r float _201; float _202; int _206; + float _208; float _210; float _211; + float powmult_213; float _215; float _216; - float powmult_238; - float powmult_240; - float powmult_241; - float _242; + float powmult_243; + float powmult_244; powmult_xxx are created by make_temp_ssa_name (type, NULL, powmult) in tree-ssa-math-opts.c for rsq11 = dx11*dx11+dy11*dy11+dz11*dz11; Different powmult_xxx have nothing to do with each others. The orders of powmult SSA_NAME_VERSION are different. As the result, sort_by_operand_rank sorts them differently and diffs in 125t.reassoc2 are powmult_80 = dx11_70 * dx11_70; - powmult_241 = dy11_71 * dy11_71; - powmult_240 = dz11_72 * dz11_72; - _699 = powmult_240 + powmult_80; - rsq11_77 = _699 + powmult_241; + powmult_213 = dy11_71 * dy11_71; + _75 = powmult_213 + powmult_80; + powmult_244 = dz11_72 * dz11_72; + rsq11_77 = _75 + powmult_244; This is rsq11 = dx11*dx11+dz11*dz11+dy11*dy11; vs rsq11 = dx11*dx11+dy11*dy11+dz11*dz11; For FP operations, they may generate slightly different results. It shows the reassoc pass is unstable, depending on FREE_SSANAMES when make_temp_ssa_name is called.
[Bug debug/60438] dwarf2cfi :2239 still assert,not the same cause as PR 59575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-03-07
CC||jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org ---
Reduced testcase for -Os -m32 -fomit-frame-pointer:
struct A { int a; };
struct B { A foo (); };
struct C { B *foo (); };
int foo (struct C *, float);
void bar (struct C *);
void baz (struct A *);
int a, b, c;
int
foo (struct C *y, float x)
{
struct A d;
if (c)
bar (y);
else
{
C g;
g.foo ()-foo ();
a = b;
d.a = (int) (b * x);
}
baz (d);
}
Started with r205498.
[Bug debug/60438] [4.9 Regression] dwarf2cfi :2239 still assert,not the same cause as PR 59575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0 Summary|dwarf2cfi :2239 still |[4.9 Regression] dwarf2cfi |assert,not the same cause |:2239 still assert,not the |as PR 59575 |same cause as PR 59575
[Bug middle-end/60418] [4.9 Regression] 435.gromacs in SPEC CPU 2006 is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org --- Please look at PR59025, 435.gromacs is apparently very sensitive to any changes in reassociation orders, not just on x32.
[Bug c++/38172] warn_unused_result does not work with structs not containing a copy constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38172 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2014-03-07 Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org --- Reopening since it is not fully fixed.
[Bug c++/38172] warn_unused_result does not work with structs not containing a copy constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38172 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||mdennis at merfer dot net --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 60460 has been marked as a duplicate of this bug. ***
[Bug c++/60460] warn_unused_result doesn't warn on unused result when std::pair return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60460 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- Dup of bug 38172. *** This bug has been marked as a duplicate of bug 38172 ***
[Bug fortran/60450] [4.7/4.8 Regression] ICE with SHAPE intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60450 --- Comment #5 from Dave Allured dave.allured at noaa dot gov --- Janus, thank you! --Dave
[Bug lto/60461] New: LTO linking error at -Os (and above) on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60461
Bug ID: 60461
Summary: LTO linking error at -Os (and above) on
x86_64-linux-gnu
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code triggers a linker error when it is compiled by the current
gcc trunk using LTO at -Os on x86_64-linux-gnu (in both 32-bit and 64-bit
modes).
It also triggers the error at -O2 and -O3 in 32-bit mode.
This is a regression from 4.8.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.9.0 20140307 (experimental) [trunk revision 208393] (GCC)
$
$ gcc-trunk -Os small.c; a.out
$ gcc-trunk -flto -O1 small.c; a.out
$ gcc-4.8.2 -flto -Os small.c; a.out
$
$ gcc-trunk -flto -Os small.c
/tmp/ccv33rju.ltrans0.ltrans.o:ccv33rju.ltrans0.o:function fn2: error:
undefined reference to 'a'
collect2: error: ld returned 1 exit status
$
--
struct S
{
int f1;
int f2;
} a[1] = { {0, 0} };
int b, c;
static unsigned short fn1 (struct S);
void
fn2 ()
{
for (; c;)
;
b = 0;
fn1 (a[0]);
}
unsigned short
fn1 (struct S p)
{
if (p.f1)
fn2 ();
return 0;
}
int
main ()
{
fn2 ();
return 0;
}
[Bug fortran/60462] New: get_command returns more than it should
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60462 Bug ID: 60462 Summary: get_command returns more than it should Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fkrogh#gcc at mathalacarte dot com
[Bug middle-end/60418] [4.9 Regression] 435.gromacs in SPEC CPU 2006 is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418
--- Comment #16 from H.J. Lu hjl.tools at gmail dot com ---
This patch:
diff --git a/gcc/tree-ssanames.c b/gcc/tree-ssanames.c
index 2fc8220..56160bd 100644
--- a/gcc/tree-ssanames.c
+++ b/gcc/tree-ssanames.c
@@ -136,7 +136,7 @@ make_ssa_name_fn (struct function *fn, tree var, gimple
stmt)
|| (TYPE_P (var) is_gimple_reg_type (var)));
/* If our free list has an element, then use it. */
- if (!vec_safe_is_empty (FREE_SSANAMES (fn)))
+ if (!vec_safe_is_empty (FREE_SSANAMES (fn)) stmt)
{
t = FREE_SSANAMES (fn)-pop ();
if (GATHER_STATISTICS)
avoids putting temporaries free SSANAMES list so that sort_by_operand_rank
is more stable.
[Bug fortran/60462] get_command returns more than it should
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60462 --- Comment #1 from Fred Krogh fkrogh#gcc at mathalacarte dot com --- With this command line ./tapt -u ./mps afiro it gives /home/m/math77/lin/cons/anypoint/tapt ./tapt -u ./mps afiro The standard makes no mention of providing the first part of what is here. That first part is the full path for the command.
[Bug fortran/60462] get_command returns more than it should
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60462 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- There's an incredible amount of missing detail. % cat foo.f90 program foo implicit none character(len=80) s call get_command(s) print '(A)', trim(s) end program foo % gfc4x -o tapt foo.f90 % ./tapt -u ./mps afiro ./tapt -u ./mps afiro % gfc48 -o tapt foo.f90 % ./tapt -u ./mps afiro ./tapt -u ./mps afiro % gfc47 -o tapt foo.f90 % ./tapt -u ./mps afiro ./tapt -u ./mps afiro Works as expected on 4.9.0, 4.8.3, and 4.7.4.
[Bug c++/60463] New: Lambda function can call a non-const member function with const this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60463
Bug ID: 60463
Summary: Lambda function can call a non-const member function
with const this
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: topi.musto at gmail dot com
The following C++11 translation unit shouldn't compile, because g is non-const
and f is const:
struct A
{
void g()
{
}
void f() const
{
[this]() { g(); }();
}
};
Yet it compiles with g++ -std=c++11 -Wall -Wextra
Tested with
g++ (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1, and
g++ (GCC) 4.9.0 20140307 (experimental)
Note that calling the function with this-g(); gives the expected error
message:
error: passing ‘const A’ as ‘this’ argument of ‘void A::g()’ discards
qualifiers [-fpermissive]
[Bug fortran/60450] [4.7/4.8 Regression] ICE with SHAPE intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60450 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #6 from kargl at gcc dot gnu.org --- (In reply to janus from comment #4) (In reply to janus from comment #3) The following patch is sufficient to fix it on 4.8: ... and regtests cleanly. Patch is OK with a testcase.
[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #51 from Harald van Dijk harald at gigawatt dot nl ---
(In reply to Marc Glisse from comment #49)
Fixing this particular issue should
not be too hard, there must be a place in the compiler that merges a number
of properties from the early declaration into the definition, and we need to
add extern C to that list.
That does indeed seem simple enough. duplicate_decls can change the type pretty
much the same way it can change the name's linkage (except it cannot simply
modify the old type; it does have to build a new one, but it can set the new
type in the existing declaration), and can do so at the same location. It seems
like the right place to do it, since the inheritance of the type's linkage
works pretty much the same way as the inheritance of the name's linkage.
Note that a consequence of this is that a function declaration that uses a
typedef may not be compatible with the typedef (I think):
extern C { void f(); }
typedef void t();
t f, *g = f; // valid redeclaration of f, invalid initialisation of g
extern C t f; // invalid redeclaration of f
extern C++ t f; // invalid redeclaration of f
Linkage conflicts with built-in declarations of functions are also a bit of a
problem: implementing this as described makes GCC fail to compile, because of
conflicts with built-in functions. The implicit declarations of built-in
functions have types with C++ linkage. A simple example:
extern C { int (myputs)(const char *) = __builtin_puts; }
test.cc:1:44: error: invalid initialization of reference of type ‘int ()(const
char*) extern C’ from expression of type ‘int(const char*)’
extern C { int (myputs)(const char *) = __builtin_puts; }
^
So the same logic to change the a redeclaration's type would need to be applied
to built-in function declarations as well.
(I may well continue working on this, but if I do, I will only do so
occasionally and will likely not be able to send anything meaningful or useful
for a long time.)
[Bug libgcc/60464] New: [arm] ARM -mthumb version of libgcc contains ARM (non-thumb) code; not safe for thumb-only architectures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60464
Bug ID: 60464
Summary: [arm] ARM -mthumb version of libgcc contains ARM
(non-thumb) code; not safe for thumb-only
architectures
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: jeremygccb at baymoo dot org
SUMMARY
Configuring and building gcc 4.8.2 for the target 'arm-none-eabi' results in a
thumb version of libgcc.a that is not entirely suitable for thumb-only
processors. This bug is also present in 4.8.1.
DETAILS
I have built GCC 4.8.2 using the following configuration:
- config.log snippet -
$ /Users/build/Downloads/gcc-4.8.2/configure --target=arm-none-eabi
--enable-languages=c --disable-libssp --disable-libstcdxx
## - ##
## Platform. ##
## - ##
hostname = not-relevant.local
uname -m = x86_64
uname -r = 12.4.0
uname -s = Darwin
uname -v = Darwin Kernel Version 12.4.0: Wed May 1 17:57:12 PDT 2013;
root:xnu-2050.24.15~1/RELEASE_X86_64
---
When using this compiler to compile code targeted for '-mcpu=cortex-m3 -mthumb'
I noticed that some of the routines in the resulting binary still seem to
expect the processor to support ARM (non-thumb) mode. On further inspection I
found that these routines came from '_clzsi2.o' and '_divsi3.o' from libgcc.a.
I double-checked that the correct version of libgcc.a was being used:
-
$ /usr/local/bin/arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb
-print-libgcc-file-name
/usr/local/lib/gcc/arm-none-eabi/4.8.2/thumb/libgcc.a
-
TO REPRODUCE
1. Configure: --target=arm-none-eabi --enable-languages=c --disable-libssp
--disable-libstcdxx
2. Compile a short test program:
$ arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -S test.c
- test.c
unsigned int
test1(unsigned long long a)
{
return a % 10;
}
-
3. Notice that the resultant 'test.s' generates a call to __aeabi_uldivmod:
-
.global test1
.thumb
.thumb_func
.type test1, %function
test1:
...
movwr2, #34464
movtr2, 1
mov r3, #0
bl __aeabi_uldivmod
mov r3, r2
mov r0, r3
-
4. Notice that __aeabi_uldivmod in
/usr/local/lib/gcc/arm-none-eabi/4.8.2/thumb/libgcc.a is a non-thumb function.
$ arm-none-eabi-objdump -d
/usr/local/lib/gcc/arm-none-eabi/4.8.2/thumb/libgcc.a
-
_aeabi_uldivmod.o: file format elf32-littlearm
Disassembly of section .text:
__aeabi_uldivmod:
0: e353cmp r3, #0
4: 0352cmpeq r2, #0
8: 1a04bne 20 __aeabi_uldivmod+0x20
c: e351cmp r1, #0
10: 0350cmpeq r0, #0
14: 13e01000mvnne r1, #0
18: 13e0mvnne r0, #0
1c: eafeb 0 __aeabi_ldiv0
20: e24dd008sub sp, sp, #8
24: e92d6000push{sp, lr}
28: ebfebl 0 __gnu_uldivmod_helper
2c: e59de004ldr lr, [sp, #4]
30: e28dd008add sp, sp, #8
34: e8bd000cpop {r2, r3}
38: e12fff1ebx lr
-
5. Notice that this occurred even though the build process for
thumb/libgcc.a(_aeabi_uldivmod.o) correctly asserted its intent by passing the
'-mthumb' to the compiler driver by inspecting the GCC build log:
-
/Users/build/builds/gcc-4.8.2-arm-none-eabi/./gcc/xgcc
-B/Users/build/builds/gcc-4.8.2-arm-none-eabi/./gcc/
-B/usr/local/arm-none-eabi/bin/ -B/usr/local/arm-none-eabi/lib/ -isystem
/usr/local/arm-none-eabi/include -isystem /usr/local/arm-none-eabi/sys-include
-g -O2 -mthumb -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -fno-inline -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -fno-inline -I. -I.
-I../../.././gcc -I/Users/build/Downloads/gcc-4.8.2/libgcc
-I/Users/build/Downloads/gcc-4.8.2/libgcc/.
-I/Users/build/Downloads/gcc-4.8.2/libgcc/../gcc
-I/Users/build/Downloads/gcc-4.8.2/libgcc/../include -DHAVE_CC_TLS -o
_aeabi_uldivmod.o -MT _aeabi_uldivmod.o -MD -MP -MF _aeabi_uldivmod.dep
-DL_aeabi_uldivmod -xassembler-with-cpp -c
/Users/build/Downloads/gcc-4.8.2/libgcc/config/arm/lib1funcs.S -include
_aeabi_uldivmod.vis
-
[Bug libgcc/60464] [arm] ARM -mthumb version of libgcc contains ARM (non-thumb) code; not safe for thumb-only architectures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60464 --- Comment #1 from Jeremy Cooper jeremygccb at baymoo dot org --- Seeing as this could be an assembler bug, my arm-none-eabi-as is: $ arm-none-eabi-as -v GNU assembler version 2.23.2 (arm-none-eabi) using BFD version (GNU Binutils) 2.23.2
[Bug debug/60438] [4.9 Regression] dwarf2cfi :2239 still assert,not the same cause as PR 59575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
--- Comment #12 from linzj manjian2006 at gmail dot com ---
I have never known that regression is such a useful resort.
(In reply to Jakub Jelinek from comment #11)
Reduced testcase for -Os -m32 -fomit-frame-pointer:
struct A { int a; };
struct B { A foo (); };
struct C { B *foo (); };
int foo (struct C *, float);
void bar (struct C *);
void baz (struct A *);
int a, b, c;
int
foo (struct C *y, float x)
{
struct A d;
if (c)
bar (y);
else
{
C g;
g.foo ()-foo ();
a = b;
d.a = (int) (b * x);
}
baz (d);
}
Started with r205498.
[Bug libgcc/60464] [arm] ARM -mthumb version of libgcc contains ARM (non-thumb) code; not safe for thumb-only architectures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60464 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID Severity|critical|normal --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- Configuring and building gcc 4.8.2 for the target 'arm-none-eabi' results in a thumb version of libgcc.a that is not entirely suitable for thumb-only processors That is correct. The default is to configure arm target to be armv5 processor. You need to configure for building for armv6m or an armv7m (or even armv7-a) if you want to use -mthumb for a thumb (or thumb2 only) processor.
[Bug c++/53492] [4.7/4.8/4.9 Regression] ICE in retrieve_specialization, at cp/pt.c:985
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53492 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug libgcc/60464] [arm] ARM -mthumb version of libgcc contains ARM (non-thumb) code; not safe for thumb-only architectures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60464 Jeremy Cooper jeremygccb at baymoo dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #3 from Jeremy Cooper jeremygccb at baymoo dot org --- I have done as you suggested and built gcc for the target armv7m-none-eabi and the thumb version of libgcc.a still has functions with ARM code. Shall I re-open this bug or create a new one?
[Bug libgcc/60464] [arm] ARM -mthumb version of libgcc contains ARM (non-thumb) code; not safe for thumb-only architectures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60464 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- Can you configure with --with-arch=armv7-m and try again? You might need to edit config/arm/t-arm-elf to enable only the multi-lib that you need. armv7m-none-eabi Does nothing really to change the default target.
[Bug libgcc/60464] [arm] ARM -mthumb version of libgcc contains ARM (non-thumb) code; not safe for thumb-only architectures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60464 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org --- Invalid as explained before. arm*-eabi says it is for armv5 rather than armv6 with thumb and thumb2.
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #10 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sat Mar 8 06:04:34 2014 New Revision: 208423 URL: http://gcc.gnu.org/viewcvs?rev=208423root=gccview=rev Log: 2014-03-08 Dominique d'Humieres domi...@lps.ens.fr PR libgfortran/60128 * io/write_float.def (output_float): Remove unused variable nzero_real. Replace a double space with a single one. (determine_en_precision): Fix wrong handling of the EN format. PR libfortran/60128 * gfortran.dg/fmt_en.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/fmt_en.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/write_float.def
[Bug debug/60438] [4.9 Regression] dwarf2cfi :2239 still assert,not the same cause as PR 59575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
--- Comment #13 from linzj manjian2006 at gmail dot com ---
Thank Jakub for the short test case and the revision.
Before revision 205498,the prologue is:
(insn/f:TI 77 78 79 2 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -36 [0xffdc])))
(clobber (reg:CC 17 flags))
(clobber (mem:BLK (scratch) [0 A8]))
]) 1.cpp:11 798 {pro_epilogue_adjust_stack_si_add}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
Then r205498:
(insn/f:TI 75 76 77 2 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -40 [0xffd8])))
(clobber (reg:CC 17 flags))
(clobber (mem:BLK (scratch) [0 A8]))
]) 1.cpp:11 798 {pro_epilogue_adjust_stack_si_add}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_CFA_ADJUST_CFA (set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -40 [0xffd8])))
See the added REG_CFA_ADJUST_CFA?,that make the cur_cfa-reg ==
dw_stack_pointer_regnum.Before r205498,without this expr,cur_cfa-reg ==
dw_frame_pointer_regnum.
And we can see r205498 actually makes the data looks right.Because we have
omitted the frame pointer, so cur_cfa-reg == dw_frame_pointer_regnum makes no
sense.So the real problem is still the jump2 pass.It should never cross jump
between two blocks without the same REG_ARGS_SIZE.
