[Bug target/60480] gcc 4.8.2 fails to do optimization on global register variables when compiling on x86_64 Linux.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60480 --- Comment #1 from Andrew Pinski --- This is due to x86 being a small register class target.
[Bug target/60480] gcc 4.8.2 fails to do optimization on global register variables when compiling on x86_64 Linux.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60480 --- Comment #2 from ganboing at gmail dot com --- (In reply to Andrew Pinski from comment #1) > This is due to x86 being a small register class target. The thing is that x86_64 has 16 GPRs, and register r12-r15 are preserved across function calls (SYSV ABI x86_64). The should be no reason that such opt. can't be done.
[Bug target/59726] [4.9 Regression] r206148 exposes broken vec_perm for big-endian aarch64; ICE at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59726 Ramana Radhakrishnan changed: What|Removed |Added Status|NEW |RESOLVED CC||ramana at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Ramana Radhakrishnan --- For 4.9 we just ended up disabling the vec_perm support for AArch64 BE, thanks to this patch - http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00988.html For the next stage1 Tejas had a patch that tried to fix these up properly in the backend. http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01334.html Therefore on that ground I think this should be closed as I don't see this testsuite failures on aarch64_be today. ramana
[Bug target/60459] Crash seen in _Unwind_VRS_Pop() for ARM platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60459 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-03-10 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Ramana Radhakrishnan --- 4.2.1 is completely unsupported. There is not enough information here to try and reproduce the issue either - can you please follow instructions here http://gcc.gnu.org/bugs/ for reporting issues with the compiler ?
[Bug target/60298] [ARM/Thumb1] ICE caused by LRA for case pr54713-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60298 Ramana Radhakrishnan changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |RESOLVED CC||ramana at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #3 from Ramana Radhakrishnan --- Fixed as per Vlad's last comment.
[Bug target/60109] __builtin_frame_address does not work as documented on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60109 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Ramana Radhakrishnan --- WONTFIX as there have been no further comments and based on the last 2 comments.
[Bug c++/60106] ICE in g++.dg/gomp/pr59150.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60106 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #1 from Ramana Radhakrishnan --- Can you please add your configure flags here ?
[Bug c++/60106] ICE in g++.dg/gomp/pr59150.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60106 --- Comment #2 from Bernd Edlinger --- (In reply to Ramana Radhakrishnan from comment #1) > Can you please add your configure flags here ? Sure, ../gcc-4.9-20140202/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf --enable-languages=c,c++,objc,obj-c++,fortran,ada,go --with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard
[Bug c++/60474] [4.9 Regression] Crash in tree_class_check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60474 Kai Tietz changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #3 from Kai Tietz --- Issue is that in double_int_ext_for_comb we try to get type-precision of a comb->type, where type is a NULL_TREE.
[Bug rtl-optimization/60473] optimization after shift sub-optimal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60473
--- Comment #1 from Martin ---
After some checking I've found that the problem is with the binary OR operator.
Addition doesn't have a problem but or does. Here are my results.
unsigned long long **_rdtsc_64 () {
unsigned long long h,l;
asm volatile ("rdtsc" : "=a" (l), "=d" (h) );
return **;
}
x1_rdtsc_64():
rdtsc ; return l + h*(0x1LLU)
salq$32, %rdx
addq%rdx, %rax
ret
x2_rdtsc_64():
rdtsc ; return l | h*(0x1LLU)
salq$32, %rdx
orq %rax, %rdx
movq%rdx, %rax
ret
x3_rdtsc_64():
rdtsc ; return l + (h<<32)
salq$32, %rdx
addq%rdx, %rax
ret
x4_rdtsc_64():
rdtsc ; return l | (h<<32)
salq$32, %rdx
orq %rax, %rdx
movq%rdx, %rax
ret
[Bug c++/60474] [4.9 Regression] Crash in tree_class_check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60474 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener --- Mine.
[Bug middle-end/60419] [4.8/4.9 Regression] ICE Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60419 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-10 CC||hubicka at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Jakub Jelinek --- The slsr issue is just a pilot error, I've mistakenly used ~ r205NNN compiler in that case, so it looks like an already fixed issue. Anyway, the ICE on ppc64 with the reduced testcase started with r208184 (thus I wonder about the 4.8 regression status), the problem is that getMeanVal function (method?) calls _ZThn8_NK4mrpt5utils16CPosePDFGaussian7getMeanERNS_5poses7CPose2DE thunk that has NULL node->callee (without -fPIC it ICEs in one spot, with -fPIC in another one). node->callees is set to non-NULL in: #0 cgraph_create_edge (caller=, callee=, call_stmt=, count=0, freq=1000) at ../../gcc/cgraph.c:927 #1 0x008ffe81 in analyze_function ( node=) at ../../gcc/cgraphunit.c:611 #2 0x009010b4 in analyze_functions () at ../../gcc/cgraphunit.c:1017 #3 0x00904979 in finalize_compilation_unit () at ../../gcc/cgraphunit.c:2320 #4 0x0068b61d in cp_write_global_declarations () at ../../gcc/cp/decl2.c:4612 #5 0x00d0ee72 in compile_file () at ../../gcc/toplev.c:562 #6 0x00d11015 in do_compile () at ../../gcc/toplev.c:1914 #7 0x00d11180 in toplev_main (argc=8, argv=0x7fffe358) at ../../gcc/toplev.c:1990 #8 0x012c0464 in main (argc=8, argv=0x7fffe358) at ../../gcc/main.c:36 and cleared again in: #0 cgraph_node_remove_callees (node=) at ../../gcc/cgraph.c:1617 #1 0x00b2dc63 in symtab_remove_unreachable_nodes (before_inlining_p=false, file=0x0) at ../../gcc/ipa.c:493 #2 0x0124c93f in ipa_inline () at ../../gcc/ipa-inline.c:2060 #3 0x0124d385 in (anonymous namespace)::pass_ipa_inline::execute (this=0x1c73710) at ../../gcc/ipa-inline.c:2412 #4 0x00c299d6 in execute_one_pass (pass=) at ../../gcc/passes.c:2229 #5 0x00c2a71b in execute_ipa_pass_list (pass=) at ../../gcc/passes.c:2607 #6 0x009042ad in ipa_passes () at ../../gcc/cgraphunit.c:2084 #7 0x0090455e in compile () at ../../gcc/cgraphunit.c:2174 #8 0x00904988 in finalize_compilation_unit () at ../../gcc/cgraphunit.c:2329 #9 0x0068b61d in cp_write_global_declarations () at ../../gcc/cp/decl2.c:4612 #10 0x00d0ee72 in compile_file () at ../../gcc/toplev.c:562 #11 0x00d11015 in do_compile () at ../../gcc/toplev.c:1914 #12 0x00d11180 in toplev_main (argc=8, argv=0x7fffe358) at ../../gcc/toplev.c:1990 #13 0x012c0464 in main (argc=8, argv=0x7fffe358) at ../../gcc/main.c:36 At that point the thunk apparently has no callers. But somewhat later it gains one: #0 cgraph_set_edge_callee (e=0x7fffef50a8f0, n=) at ../../gcc/cgraph.c:1080 #1 0x008f74a8 in cgraph_make_edge_direct (edge=0x7fffef50a8f0, callee=) at ../../gcc/cgraph.c:1313 #2 0x00b1f7ae in ipa_make_edge_direct_to_target (ie=0x7fffef50a8f0, target=) at ../../gcc/ipa-prop.c:2551 #3 0x00b20091 in try_make_edge_direct_virtual_call (ie=0x7fffef50a8f0, jfunc=0x7085b078, new_root_info=0x1e4cce0) at ../../gcc/ipa-prop.c:2799 #4 0x00b201e2 in update_indirect_edges_after_inlining (cs=0x7fffef9baf08, node=, new_edges=0x0) at ../../gcc/ipa-prop.c:2852 #5 0x00b20476 in propagate_info_to_inlined_callees (cs=0x7fffef9baf08, node=, new_edges=0x0) at ../../gcc/ipa-prop.c:2924 #6 0x00b20c3d in ipa_propagate_indirect_call_infos (cs=0x7fffef9baf08, new_edges=0x0) at ../../gcc/ipa-prop.c:3086 #7 0x0124e183 in inline_call (e=0x7fffef9baf08, update_original=true, new_edges=0x0, overall_size=0x0, update_overall_summary=true) at ../../gcc/ipa-inline-transform.c:277 #8 0x0124c6da in inline_to_all_callers (node=, data=0x7fffe024) at ../../gcc/ipa-inline.c:1987 #9 0x008f9a18 in cgraph_for_node_and_aliases (node=, callback= 0x124c5f5 , data=0x7fffe024, include_overwritable=true) at ../../gcc/cgraph.c:2212 #10 0x0124cacc in ipa_inline () at ../../gcc/ipa-inline.c:2118 #11 0x0124d385 in (anonymous namespace)::pass_ipa_inline::execute (this=0x1c73710) at ../../gcc/ipa-inline.c:2412 #12 0x00c299d6 in execute_one_pass (pass=) at ../../gcc/passes.c:2229 #13 0x00c2a71b in execute_ipa_pass_list (pass=) at ../../gcc/passes.c:2607 #14 0x009042ad in ipa_passes () at ../../gcc/cgraphunit.c:2084 #15 0x0090455e in compile () at ../../gcc/cgraphunit.c:2174 #16 0x00904988 in finalize_compilation_unit () at ../../gc
[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 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #17 from Richard Biener --- I'll have a look.
[Bug lto/60461] [4.9 Regression] LTO linking error at -Os (and above) on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60461 Richard Biener changed: What|Removed |Added Keywords||lto, wrong-code CC||hubicka at gcc dot gnu.org Target Milestone|--- |4.9.0 Summary|LTO linking error at -Os|[4.9 Regression] LTO |(and above) on |linking error at -Os (and |x86_64-linux-gnu|above) on x86_64-linux-gnu
[Bug ipa/60457] [4.9 Regression] ICE in cgraph_get_node
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60457 --- Comment #3 from Richard Biener --- Looks obvious to me.
[Bug middle-end/60478] convert_move assert failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60478 --- Comment #2 from linzj --- (In reply to Marek Polacek from comment #1) > You've filed the same bug twice. > > *** This bug has been marked as a duplicate of bug 60479 *** 小手一抖，jj没有
[Bug c++/60474] [4.9 Regression] Crash in tree_class_check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60474
--- Comment #5 from Richard Biener ---
type = signed_type_for (TREE_TYPE (e1));
tree_to_aff_combination (e1, type, &aff_e1);
tree_to_aff_combination (e2, type, &aff_e2);
signed_type_for (offset_type 0x76d9cc78)
returns NULL_TREE. OFFSET_TYPE in the IL ... ugh.
void fn1(A&, int Layer::*, int) (struct A & p1, <<< Unknown tree:
offset_type >>> p2, int p3)
{
I have a patch.
[Bug target/60481] New: [4.9 Regression] Missing diagnostic "ISO C++ forbids declaration of 'foo' with no type"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60481
Bug ID: 60481
Summary: [4.9 Regression] Missing diagnostic "ISO C++ forbids
declaration of 'foo' with no type"
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: d.g.gorbachev at gmail dot com
Target: *-*-mingw32
$ cat > foo.C
foo()
{
return 0;
}
^D
$ i686-w64-mingw32-g++-4.9.0 -S foo.C
$ i686-pc-linux-gnu-g++-4.9.0 -S foo.C
foo.C:1:5: error: ISO C++ forbids declaration of 'foo' with no type
[-fpermissive]
foo()
^
[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 #25 from Jakub Jelinek ---
(In reply to linzj from comment #23)
> (In reply to Richard Henderson from comment #19)
> > Created attachment 32311 [details]
> > proposed patch
> >
> > Running full tests on this overnight, but it fixes the ICE.
>
> I try to remove the following hunk from you patch,it compiles Jakub's
> testcase right.Not run the full tests yet.
> diff --git a/gcc/combine-stack-adj.c b/gcc/combine-stack-adj.c
> index 69fd5ea..5abec30 100644
> --- a/gcc/combine-stack-adj.c
> +++ b/gcc/combine-stack-adj.c
> @@ -454,6 +454,14 @@ combine_stack_adjustments_for_block (basic_block bb)
> {
> HOST_WIDE_INT this_adjust = INTVAL (XEXP (src, 1));
>
> + /* It's quite tricky to adjust the notes associated
> +with frame related insns. */
> + if (RTX_FRAME_RELATED_P (insn))
> + {
> + last2_sp_set = last_sp_set = NULL;
> + continue;
> + }
> +
> /* If we've not seen an adjustment previously, record
> it now and continue. */
> if (! last_sp_set)
Perhaps we can handle some most common cases of frame related insns (e.g. if
both have REG_CFA_ADJUST_CFA notes, etc.), perhaps it would be worth it to run
a bootstrap which would log when the above hunk prevented some merging and
append both insns to some /tmp/ file across whole bootstrap, then we could see
what is common enough to care about.
[Bug target/60481] [4.9 Regression] Missing diagnostic "ISO C++ forbids declaration of 'foo' with no type"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60481 --- Comment #1 from Jonathan Wakely --- I think you need -fno-ms-extensions, which may be on by default for mingw
[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 #18 from Jakub Jelinek --- Shouldn't we just prefer the original IL if possible? That is not SSA_NAME_VERSION, but not gimple_uid of the stmt definition either. If you have: _4 = something; _5 = somethingelse; _6 = somethingdifferent; _7 = _6 + _4; _8 = _7 + _5; then both SSA_NAME_VERSION and gimple_uid of def_stmt sorting would result in _9 = _4 + _5; _8 = _9 + _6; wouldn't it? But what do we gain by reassociating this (perhaps it can help value numbering and CSE if you have differently ordered sequences, but other than that this seems to be unnecessary reshufling and especially for floating point values and -ffast-math unnecessary source of extra ulps). So perhaps we want to sort by gimple uid of the first use among the insns we are looking at (and take into account also the operand number)?
[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
--- Comment #18 from Richard Biener ---
Seems to be a PTA issue:
InsertionSort_pETEchase.29_82, points-to vars: { }
InsertionSort_pETEchase.29_86, points-to non-local, points-to escaped,
points-to vars: { }
p1_155, points-to NULL, points-to vars: { }
:
InsertionSort_pETEchase.29_82->next = p1_84;
p1_155->next = InsertionSort_pETEchase.28_85;
InsertionSort_pETEchase.29_86 = InsertionSort_pETEchase.28_85->back;
InsertionSort_pETEchase.29_86->next = p1_155;
p1_155->back = &InsertionSort_pETEchaseBackTMP;
taking _155 as example
# p1_155 = PHI <_35(57), p1_58(60)>
_35, points-to NULL, points-to vars: { }
p1_58, points-to vars: { }
_35 = MEM[(struct _EdgeTableEntry * *)&AET + 16B];
# p1_58 = PHI
p1_84 = p1_155->next;
p1_87 = p1_155->next;
so it's a cycle seeded only by MEM[(struct _EdgeTableEntry * *)&AET + 16B];
_35 = { NULL } same as AET.128+64
_35 = AET.128+64
# p1_150 = PHI <&AET(47), p1_151(49)>
# p1_151 = PHI
p1_45 = p1_151->next;
fn3_tmp = p1_45;
p1_151->next = p1_47;
p1_151->back = p1_150;
p1_150 = &AET.0+96
*p1_150 + 128 = p1_151
Note that valgrind shows loads of errors (with the reduced testcase at least)
that show invalid reads and writes even at -O0. So we may just optimistically
optimize based on that undefined behavior.
At least I can't see anything wrong with what PTA derives ...
[Bug c/55383] -Wcast-qual reports incorrect message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55383 Magnus Reftel changed: What|Removed |Added CC||magnus.reftel at gmail dot com --- Comment #4 from Magnus Reftel --- Also affects 4.6, 4.8 and trunk as of version 96c7d4b1727c5f9ddcbb02fb69f727a0f2f3572e. 4.4 correctly prints just "error: cast discards qualifiers from pointer target type". Did not check with version 4.5. Since 4.4 had it right, does this count as a 4.6/4.7/4.8/4.9 regression?
[Bug c/55383] -Wcast-qual reports incorrect message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55383 --- Comment #5 from Manuel López-Ibáñez --- (In reply to Magnus Reftel from comment #4) > Also affects 4.6, 4.8 and trunk as of version > 96c7d4b1727c5f9ddcbb02fb69f727a0f2f3572e. 4.4 correctly prints just "error: > cast discards qualifiers from pointer target type". Did not check with > version 4.5. > > Since 4.4 had it right, does this count as a 4.6/4.7/4.8/4.9 regression? This just needs someone willing to test the patch in comment #1 and submit it. It is such a trivial patch that I cannot claim any authorship, so please adopt it and get it fixed. If you are fast enough, you may be able to sneak it in GCC 4.9. (The time it took you to do all those tests would have been better spent fixing the bug.)
[Bug c/55383] -Wcast-qual reports incorrect message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55383 --- Comment #6 from Magnus Reftel --- Sorry, I'm not a GCC developer - just another user aflicted by the bug.
[Bug middle-end/55874] Incorrect warning location for uninitialized variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55874 Manuel López-Ibáñez changed: What|Removed |Added Keywords|patch | --- Comment #3 from Manuel López-Ibáñez --- Sorry, changed keyword on the wrong bug!
[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 --- Comment #2 from Antony Lewis --- Here's a related example: module A implicit none Type T integer :: val = 2 contains final :: testfree end type contains subroutine testfree(this) Type(T) this print *,'freed' end subroutine subroutine Testf() associate(X => T()) print *, X%val end associate print *,'after scope' end subroutine Testf end module which gives print *, X%val 1 Error: Symbol 'x' at (1) has no IMPLICIT type (I was checking if finalization is called correctly, but didn't get that far) This code compiles in ifort.
[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 #26 from linzj --- (In reply to Jakub Jelinek from comment #25) > Perhaps we can handle some most common cases of frame related insns (e.g. if > both have REG_CFA_ADJUST_CFA notes, etc.), perhaps it would be worth it to > run a bootstrap which would log when the above hunk prevented some merging > and append both insns to some /tmp/ file across whole bootstrap, then we > could see what is common enough to care about. Hi,Jakub,I remove the hunk, because I want some merging happen,not prevent it from.
[Bug c/55383] -Wcast-qual reports incorrect message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55383 Manuel López-Ibáñez changed: What|Removed |Added Keywords||patch --- Comment #7 from Manuel López-Ibáñez --- (In reply to Magnus Reftel from comment #6) > Sorry, I'm not a GCC developer - just another user aflicted by the bug. Everybody can be a GCC developer. You don't need special powers, just some free time and willing to be. For such a small patch, you don't need any copyright assignment. Just check out svn trunk, set up a bootstrap, test without the patch, apply the patch, bootstrap and test with the patch and compare the results. (Check the gccfarming script here: http://gcc.gnu.org/wiki/ManuelL%C3%B3pezIb%C3%A1%C3%B1ez for all the details). If the patch does not produce any new FAILs in the testsuite, submit to gcc-patches with a changelog and ask the reviewer to commit it once accepted. (You don't even need a powerful computer to do all this, just get an account on the compile farm: http://gcc.gnu.org/wiki/CompileFarm )
[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 --- Comment #19 from Markus Trippelsdorf --- Yes, looks like the reduced testcase is invalid and contains a few buffer overflows.
[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
--- Comment #20 from Richard Biener ---
As for what Andrew said, yes, the reinterpret_casts<> look bogus, you should
really change
typedef struct _POINTBLOCK {
int data[200 * sizeof(QPoint)];
QPoint *pts;
struct _POINTBLOCK *next;
} POINTBLOCK;
to
typedef struct _POINTBLOCK {
char data[200 * sizeof(QPoint) * sizeof (int)];
QPoint *pts;
struct _POINTBLOCK *next;
} POINTBLOCK;
but that doesn't change the outcome of the testcase. The reduced testcase
requiring QtCore is valgrind clean for me.
The cause of the issue _is_ what tree PRE does to the function though.
+Replaced AET.next with prephitmp_4 in pPrevAET_44 = AET.next;
in PolygonRegion, with -O2 -fno-ipa-cp. Still most of the pointers are
computed to point to noting by PTA.
Function calls left in that function after inlining are operator delete[],
free, operator new, qBadAlloc and malloc calls.
--param max-fields-for-field-sensitive=0 fixes it as well, so it does point
at a PTA issue. Still looking ...
[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 #27 from Jakub Jelinek --- (In reply to Jakub Jelinek from comment #25) > Perhaps we can handle some most common cases of frame related insns (e.g. if > both have REG_CFA_ADJUST_CFA notes, etc.), perhaps it would be worth it to > run a bootstrap which would log when the above hunk prevented some merging > and append both insns to some /tmp/ file across whole bootstrap, then we > could see what is common enough to care about. Wonder if we just shouldn't pass the other insn (the one we'd like to delete) to try_apply_stack_adjustment and if either of them is frame related insn, check harder to see if we can handle it or give up if we can't handle it. At least merging of a frame related stack adjustment and following non-frame related one (or vice versa?) is I think very common.
[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 #7 from Jakub Jelinek ---
(In reply to Eric Botcazou from comment #6)
> > 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?
>
> Again quite an artificial testcase... What about adding a comparison of the
> offset with the result of get_frame_size if the base register is SFP/HFP/SP?
But what would be safe positive/negative offsets from frame_pointer?
I mean, e.g. size of arguments is not included in the frame size, so size of
arguments would need to be taken into account too, plus does the middle-end
really know all the biases etc.?
[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 --- Comment #3 from janus at gcc dot gnu.org --- (In reply to Antony Lewis from comment #2) > Here's a related example: Though the test case may be loosely related to comment 0, the error is probably not so much related. Reduced version of comment 2: implicit none Type T integer :: val = 2 end type associate(X => T()) print *, X%val end associate end This compiles and runs cleanly with 4.6, but gives errors with 4.7, 4.8 and trunk. I think this should go into a separate PR.
[Bug middle-end/60482] New: Loop optimization regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60482
Bug ID: 60482
Summary: Loop optimization regression
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: yvan.roux at linaro dot org
Created attachment 32323
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32323&action=edit
trunk.s
Hi,
I didn't had time to investigate further, but I want to raise quickly that the
code bellow was optimized at r204283 by taking into account the trip count
information of the loop and is not with the trunk (I spotted the issue on
AArch64 and x86_64).
code:
typedef double adouble __attribute__ ((__aligned__(16)));
double p1(adouble *x, int n)
{
double p1_ = 0.0;
(!(n % 128) == 0) ? __builtin_unreachable() : 1 ;
for (int i=0; i
[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 --- Comment #4 from Antony Lewis --- OK, will do. (thought the underlying cause might be same issue with associate variables)
[Bug fortran/60483] New: associate error on valid code: no IMPLICIT type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60483 Bug ID: 60483 Summary: associate error on valid code: no IMPLICIT type 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 implicit none Type T integer :: val = 2 contains final :: testfree end type contains subroutine testfree(this) Type(T) this print *,'freed' end subroutine subroutine Testf() associate(X => T()) print *, X%val end associate print *,'after scope' end subroutine Testf end module which gives print *, X%val 1 Error: Symbol 'x' at (1) has no IMPLICIT type (code checks if finalization is called correctly, but didn't get that far) This code compiles in ifort.
[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 #8 from Eric Botcazou --- > But what would be safe positive/negative offsets from frame_pointer? > I mean, e.g. size of arguments is not included in the frame size, so size of > arguments would need to be taken into account too, plus does the middle-end > really know all the biases etc.? No, that would be either conservative or not bullet-proof, at least if used alone. Maybe compare MEM_OFFSET and get_frame_size and return true if the former is larger than the latter. Why do we drop the MEM_EXPR if the DECL_RTL is a reg?
[Bug ada/60411] ADA bootstrap failure on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411 Bernd Edlinger changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Bernd Edlinger --- OK, the cross build for arm-linux-gnueabihf succeeds again. So I will close this tracker now. Thanks, BUT if I look at these lines in gcc/ada/gcc-interace/Makefile.in: # ARM android ifeq ($(strip $(filter-out arm% linux-androideabi,$(target_cpu) $(target_os))),) LIBGNAT_TARGET_PAIRS = \ a-intnam.ads
[Bug c/60484] New: -fdump-rtl-expand and attribute optimize gives incorrect dump file path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60484 Bug ID: 60484 Summary: -fdump-rtl-expand and attribute optimize gives incorrect dump file path Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: secondary.mail7865220 at gmail dot com Created attachment 32324 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32324&action=edit test.c - Source to trigger the bug To trigger this bug, three conditions must be met: - At least one function must be annotated with "__attribute__((optimize))". - The object file is placed in a sub-directory to where the source file is located. - The flag -fdump-rtl-expand is used. The path to the directory where the dump file is supposed to be saved is prepended the same number of times as there are functions with "attribute optimize" in the source C file. Compiler output: $ gcc -std=c99 -fdump-rtl-expand -o objs/test.o -c test.c test.c: In function ‘Optimized_1’: test.c:3:1: error: could not open dump file ‘objs/objs/objs/test.c.166r.expand’: No such file or directory Optimized_1(int arg) ^ test.c: In function ‘Optimized_2’: test.c:10:1: error: could not open dump file ‘objs/objs/objs/test.c.166r.expand’: No such file or directory Optimized_2(int arg) ^ test.c: In function ‘main’: test.c:15:5: error: could not open dump file ‘objs/objs/objs/test.c.166r.expand’: No such file or directory int main() ^ Compiler version: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure Thread model: posix gcc version 4.8.2 (GCC) System type: $ uname -a Linux jf-linux 3.4.63-2.44-desktop #1 SMP PREEMPT Wed Oct 2 11:18:32 UTC 2013 (d91a619) x86_64 x86_64 x86_64 GNU/Linux
[Bug middle-end/60482] Loop optimization regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60482 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-10 CC||amker at gcc dot gnu.org, ||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started to be optimized probably with r204255, is not optimized anymore again starting with r208165.
[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 #28 from linzj --- (In reply to Jakub Jelinek from comment #27) > Wonder if we just shouldn't pass the other insn (the one we'd like to > delete) to > try_apply_stack_adjustment and if either of them is frame related insn, > check harder to see if we can handle it or give up if we can't handle it. > At least merging of a frame related stack adjustment and following non-frame > related one (or vice versa?) is I think very common. I think the final solution will both a fulfillment of dwarf2cfi & csa & jump2. That is csa is able to combine the stack operations,jump2 is able to find the common insn in ends of blocks,and dwarf2cfi is able to get the correct input data.
[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
--- Comment #21 from Richard Biener ---
AFAIK I can understand the reduced testcase AET is never written to anything
but the initial NULL pointers. Neither CerateETandAET nor loadAET do anything
to the PolygonRegion local AET.
I have a fix (bah, this function needs a LOT of TLC!)
Index: gcc/tree-ssa-structalias.c
===
--- gcc/tree-ssa-structalias.c (revision 208448)
+++ gcc/tree-ssa-structalias.c (working copy)
@@ -3218,7 +3218,12 @@ get_constraint_for_component_ref (tree t
{
cexpr.var = curr->id;
results->safe_push (cexpr);
- if (address_p)
+ /* If we take the address and the field starts exactly
+at the desired position that was all we need to add. */
+ if (address_p
+ && curr->offset == (unsigned HOST_WIDE_INT) bitpos
+ && bitmaxsize != -1
+ && bitsize == bitmaxsize)
break;
}
}
Re: [Bug ada/60411] ADA bootstrap failure on ARM
> the cross build for arm-linux-gnueabihf succeeds again. Great. > So they use the same system.ads, which now links with a-exexpr-gcc.adb; > Should'nt this target now also use EH_MECHANISM=-gcc or -arm? Yes, android should also use EH_MECHANISM=-arm I'll make that change.
[Bug ada/60411] ADA bootstrap failure on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411 --- Comment #7 from charlet at adacore dot com --- > the cross build for arm-linux-gnueabihf succeeds again. Great. > So they use the same system.ads, which now links with a-exexpr-gcc.adb; > Should'nt this target now also use EH_MECHANISM=-gcc or -arm? Yes, android should also use EH_MECHANISM=-arm I'll make that change.
[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 #19 from rguenther at suse dot de --- On Mon, 10 Mar 2014, jakub at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418 > > --- Comment #18 from Jakub Jelinek --- > Shouldn't we just prefer the original IL if possible? That is not > SSA_NAME_VERSION, but not gimple_uid of the stmt definition either. > If you have: > _4 = something; > _5 = somethingelse; > _6 = somethingdifferent; > _7 = _6 + _4; > _8 = _7 + _5; > then both SSA_NAME_VERSION and gimple_uid of def_stmt sorting would result in > _9 = _4 + _5; > _8 = _9 + _6; > wouldn't it? But what do we gain by reassociating this (perhaps it can help > value numbering and CSE if you have differently ordered sequences, but other > than that this seems to be unnecessary reshufling and especially for floating > point values and -ffast-math unnecessary source of extra ulps). > So perhaps we want to sort by gimple uid of the first use among the insns we > are looking at (and take into account also the operand number)? Yes, it wants to canonicalize to get more CSE as followup. So sorting after SSA_NAME_VERSION (or its definition UID) does make sense ... Looking at the first use is also possible, but what _is_ the first use? _4 = something if (foo) _5 = _4 + 1; else _6 = _4 + 2;
[Bug c++/60474] [4.9 Regression] Crash in tree_class_check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60474 --- Comment #6 from Richard Biener --- Author: rguenth Date: Mon Mar 10 13:27:16 2014 New Revision: 208451 URL: http://gcc.gnu.org/viewcvs?rev=208451&root=gcc&view=rev Log: 2014-03-10 Richard Biener PR middle-end/60474 * tree.c (signed_or_unsigned_type_for): Handle OFFSET_TYPEs. * g++.dg/torture/pr60474.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr60474.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c
[Bug c++/60474] [4.9 Regression] Crash in tree_class_check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60474 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug target/60481] [4.9 Regression] Missing diagnostic "ISO C++ forbids declaration of 'foo' with no type"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60481 --- Comment #2 from Dmitry Gorbachev --- Yes, it seems that it is on (there is an error with -fno-ms-extensions), but: $ i686-w64-mingw32-g++-4.9.0 -Q --help=c++ | grep ms-ext -fms-extensions [disabled]
[Bug tree-optimization/60485] field-sensitive points-to confused by pointer offsetting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60485 Richard Biener changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-03-10 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine.
[Bug tree-optimization/60485] New: field-sensitive points-to confused by pointer offsetting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60485
Bug ID: 60485
Summary: field-sensitive points-to confused by pointer
offsetting
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
extern void abort (void);
struct S {
int *i[4];
int *p1;
int *p2;
int *p3;
int *p4;
};
int **b;
int main()
{
int i = 1;
struct S s;
s.p3 = &i;
int **p;
if (b)
p = b;
else
p = &s.i[2];
p += 4;
if (!b)
**p = 0;
if (i != 0)
abort ();
return i;
}
[Bug middle-end/60482] Loop optimization regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60482 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 32325 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32325&action=edit gcc49-pr60482.patch Untested fix. Apparently the problem is that we add an ASSERT_EXPR right before the __builtin_unreachable, even when it obviously isn't needed there. The comment talks about pre-4.4 FOUND_IN_SUBGRAPH stuff, at least right now with live_on_edge that function returns false in this case.
[Bug ipa/60457] [4.9 Regression] ICE in cgraph_get_node
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60457 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Mon Mar 10 14:55:20 2014 New Revision: 208454 URL: http://gcc.gnu.org/viewcvs?rev=208454&root=gcc&view=rev Log: PR ipa/60457 * ipa.c (symtab_remove_unreachable_nodes): Don't call cgraph_get_create_node on VAR_DECLs. * g++.dg/ipa/pr60457.C: New test. Added: trunk/gcc/testsuite/g++.dg/ipa/pr60457.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa.c trunk/gcc/testsuite/ChangeLog
[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 #8 from Richard Earnshaw --- (In reply to Jeremy Cooper from comment #7) > Is there a reason these were commented out? Is the armv7 multilib unstable? Volume of variants that have to be compiled at build time. Each enabled entry practically doubles the build time for the libraries.
[Bug ipa/60457] [4.9 Regression] ICE in cgraph_get_node
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60457 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug other/60486] New: [avr] missed optimization on detecting zero flag set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60486
Bug ID: 60486
Summary: [avr] missed optimization on detecting zero flag set
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: darryl.piper at gmail dot com
detection of a variable being decremented to reach zero missed optimization.
int main(uint16_t, uint16_t );
int main(uint16_t x, uint16_t y) {
uint16_t z = x;
while (x > y) {
if ( --z == 0 ) return 1;
x++;
}
return 0;
}
produces with gcc 4.8.0 and 4.8.1 and I expect 4.8.2 as well.
compiled with -Os
the code at 0x82 to 0x8a uses a compare against zero, when the subi and sbc,
leave the zero flag set on a atmega8.
7a:9c 01 movwr18, r24
7c:68 17 cpr22, r24
7e:79 07 cpcr23, r25
80:38 f4 brcc.+14 ; 0x90
82:21 50 subir18, 0x01; 1
84:31 09 sbcr19, r1
86:21 15 cpr18, r1
88:31 05 cpcr19, r1
8a:29 f0 breq.+10 ; 0x96
8c:01 96 adiwr24, 0x01; 1
8e:f6 cf rjmp.-20 ; 0x7c
90:80 e0 ldir24, 0x00; 0
92:90 e0 ldir25, 0x00; 0
94:08 95 ret
96:81 e0 ldir24, 0x01; 1
98:90 e0 ldir25, 0x00; 0
9a:08 95 ret
in gcc/config/avr/avr.md the code for (define_insn "add3" no longer says
it alters the zero of negative flag which the 4.7.2 branch did depending on
which choice of add & adc or sub & sbc choice it used.
[Bug c/55383] -Wcast-qual reports incorrect message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55383 Gerald Pfeifer changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #8 from Gerald Pfeifer --- I'll see what I can do.
[Bug rtl-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 changed:
What|Removed |Added
Component|tree-optimization |rtl-optimization
--- Comment #9 from Jakub Jelinek ---
expand_expr_real_1 for the ARRAY_REF in question does:
/* If we have either an offset, a BLKmode result, or a reference
outside the underlying object, we must force it to memory.
Such a case can occur in Ada if we have unchecked conversion
of an expression from a scalar type to an aggregate type or
for an ARRAY_RANGE_REF whose type is BLKmode, or if we were
passed a partially uninitialized object or a view-conversion
to a larger size. */
must_force_mem = (offset
|| mode1 == BLKmode
|| bitpos + bitsize > GET_MODE_BITSIZE (mode2));
...
/* Otherwise, if this is a constant or the object is not in memory
and need be, put it there. */
else if (CONSTANT_P (op0) || (!MEM_P (op0) && must_force_mem))
{
tree nt = build_qualified_type (TREE_TYPE (tem),
(TYPE_QUALS (TREE_TYPE (tem))
| TYPE_QUAL_CONST));
memloc = assign_temp (nt, 1, 1);
emit_move_insn (memloc, op0);
op0 = memloc;
mem_attrs_from_type = true;
}
op0 is DECL_RTL of the array, (reg/v:DI 85 [ e ]), bitpos is 0x40, bitsize
is 32, mode2 is DImode.
Not sure if it is safe to set MEM_EXPR (etc. on assign_temp result, if it is,
we could do that. Note that MEM_NOTRAP_P is set on it (I assume it is fine
too, because we should consider it only when not out of bound access).
In any case, as the #c3 testcase shows, even when we do have MEM_EXPR and could
see that it is out of bound, we don't use that info at all.
[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 --- Comment #5 from Jason Merrill --- Author: jason Date: Mon Mar 10 15:44:50 2014 New Revision: 208455 URL: http://gcc.gnu.org/viewcvs?rev=208455&root=gcc&view=rev Log: PR c++/53492 * parser.c (cp_parser_class_head): Also check PRIMARY_TEMPLATE_P when deciding whether to call push_template_decl for a member class. * pt.c (push_template_decl_real): Return after wrong levels error. Added: trunk/gcc/testsuite/g++.dg/template/memtmpl4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c
[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 #20 from H.J. Lu --- (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? copyprop2 pass removed a preheader and cunrolli pass added it back: : # n_213 = PHI <1(2)> : # n_8 = PHI copyprop3 pass optimized it to : n_213 = 1; : # n_8 = PHI <1(3), n_218(7)> Then the unused n_213 disappeared in reassoc1 pass and n_213 was put on FREE_SSANAMES.
[Bug testsuite/60487] New: FAIL: gcc.dg/tree-prof/crossmodule-indircall-1a.c compilation, -fprofile-generate -D_PROFILE_GENERATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60487 Bug ID: 60487 Summary: FAIL: gcc.dg/tree-prof/crossmodule-indircall-1a.c compilation, -fprofile-generate -D_PROFILE_GENERATE Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/gnu/gcc/gc c/gcc/testsuite/gcc.dg/tree-prof/crossmodule-indircall-1a.c -fno-diagnostics-sho w-caret -fdiagnostics-color=never /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-pr of/crossmodule-indircall-1a.c -fprofile-generate -D_PROFILE_GENERATE -lm -o /tes t/gnu/gcc/objdir/gcc/testsuite/gcc/crossmodule-indircall-1a.x01 /usr/ccs/bin/ld: Duplicate symbol "main" in files /var/tmp//ccFgQFKi.o and /var/ tmp//ccQoAKFt.o /usr/ccs/bin/ld: Duplicate symbol "global constructors keyed to 65535_1_main" in files /var/tmp//ccFgQFKi.o and /var/tmp//ccQoAKFt.o /usr/ccs/bin/ld: Found 2 duplicate symbol(s) collect2: error: ld returned 1 exit status compiler exited with status 1 Test probability needs to check visibility.
[Bug c/60488] New: missing -Wmaybe-uninitialized on a conditional with goto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60488
Bug ID: 60488
Summary: missing -Wmaybe-uninitialized on a conditional with
goto
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gmail dot com
The -Wmaybe-uninitialized option is documented like so: "For an automatic
variable, if there exists a path from the function entry to a use of the
variable that is initialized, but there exist some other paths for which the
variable is not initialized, the compiler emits a warning if it cannot prove
the uninitialized paths are not executed at run time."
In the program below, when f(&a) returns zero, the variable b is considered to
have been initialized by the call to f(&b) when it's used as the argument in
the first call to g(b). However, when f(&a) returns non-zero, the variable b is
used uninitialized in the second call to g(b). Therefore, there exists a path
through the function where b is used initialized as well as one where it's used
uninitialized. Thus, GCC should issue a warning. It, however, does not.
$ cat t.c && gcc -O2 -Wuninitialized -Wmaybe-uninitialized -c -o/dev/null t.c
int f (int**);
void g (int*);
int foo (void) {
int *a, *b;
if (f (&a) || f (&b))
goto end;
g (a);
g (b);
return 0;
end:
g (b);
return 1;
}
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 Jason Merrill changed: What|Removed |Added Assignee|jason at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #30 from Jason Merrill --- Honza was going to make some adjustments to my patch.
[Bug tree-optimization/59121] [4.8/4.9 Regression] endless loop with -O2 -floop-parallelize-all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59121 --- Comment #14 from Mircea Namolaru --- Confirmed. Start looking at it. This test also enters in an endless loop with the options -fgraphite-identiy -floop-nest-optimize -O2 -c.
[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 #21 from Jakub Jelinek ---
Can you try if sorting on gimple_uid would help this or not? I think it would
be something like:
--- gcc/tree-ssa-reassoc.c.jj2014-02-19 06:59:35.0 +0100
+++ gcc/tree-ssa-reassoc.c2014-03-10 17:26:06.707683626 +0100
@@ -506,11 +506,17 @@ sort_by_operand_rank (const void *pa, co
}
/* Lastly, make sure the versions that are the same go next to each
- other. We use SSA_NAME_VERSION because it's stable. */
+ other. Prefer gimple_uid of def stmt, fall back to SSA_NAME_VERSION
+ if more stmts have the same uid. */
if ((oeb->rank - oea->rank == 0)
&& TREE_CODE (oea->op) == SSA_NAME
&& TREE_CODE (oeb->op) == SSA_NAME)
{
+ unsigned int uida = gimple_uid (SSA_NAME_DEF_STMT (oea->op));
+ unsigned int uidb = gimple_uid (SSA_NAME_DEF_STMT (oeb->op));
+ if (uida && uidb && uida != uidb)
+return uidb - uida;
+
if (SSA_NAME_VERSION (oeb->op) != SSA_NAME_VERSION (oea->op))
return SSA_NAME_VERSION (oeb->op) - SSA_NAME_VERSION (oea->op);
else
(make check RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} dg.exp=*reassoc*
tree-ssa.exp=*reassoc*'
with it still passes, haven't tested it more than that).
[Bug tree-optimization/59121] [4.8/4.9 Regression] endless loop with -O2 -floop-parallelize-all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59121 --- Comment #15 from Jeffrey A. Law --- Mircea, thanks. I'm definitely looking forward to seeing Graphite in a better state! With you on board at INRIA and working on Graphite, I will not be calling for Graphite's removal after the 4.9 release. Thanks again, jeff
[Bug libstdc++/60489] New: Document which functions can be recursively reentered
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60489 Bug ID: 60489 Summary: Document which functions can be recursively reentered Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org The standard says: 17.6.5.8 Reentrancy [reentrancy] Except where explicitly specified in this standard, it is implementation-defined which functions in the Standard C ++ library may be recursively reentered. Our docs on implementation-defined properties (with the C++03 section number) say: "[17.4.4.5] Non-reentrant functions are probably best discussed in the various sections on multithreading (see above)." While that may be true, (1) the sections on multithreading are not "above" and (2) don't say anything about reentrancy. This affects whether, for example, an element being erased from a container during a call to clear() can call clear() on the container again, see http://stackoverflow.com/q/20755194/981959 (we probably *could* make that work if we wanted to, but it would require more work to support a very uncommon case). I think the simplest solution is to document that for our implementation no functions are reentrant unless specified otherwise, then specify otherwise later for particular functions.
[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 #22 from H.J. Lu --- (In reply to Jakub Jelinek from comment #21) > Can you try if sorting on gimple_uid would help this or not? I think it > would be something like: Yes, it works.
[Bug tree-optimization/59025] [4.9 Regression] Revision 203979 causes failure in CPU2006 benchmark 435.gromacs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59025 --- Comment #9 from Jakub Jelinek --- Can you please try the http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418#c21 patch?
[Bug other/60486] [avr] missed optimization on detecting zero flag set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60486 Georg-Johann Lay changed: What|Removed |Added CC||gjl at gcc dot gnu.org --- Comment #1 from Georg-Johann Lay --- Created attachment 32326 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32326&action=edit C test case Here is a valid test case. Compiled with avr-gcc 4.8.2 $ avr-gcc pr60486.c -S -Os -mmcu=atmega8 -dp we get: pr60486: movw r18,r24 ; 5*movhi/1[length = 1] .L2: cp r22,r24 ; 21*cmphi/3[length = 2] cpc r23,r25 brsh .L7 ; 22branch[length = 1] subi r18,1 ; 13addhi3_clobber/2[length = 2] sbc r19,__zero_reg__ cp r18,__zero_reg__ ; 14*cmphi/2[length = 2] cpc r19,__zero_reg__ breq .L5 ; 15branch[length = 1] adiw r24,1 ; 17addhi3_clobber/1[length = 1] rjmp .L2 ; 55jump[length = 1] .L7: ldi r24,0 ; 7*movhi/2[length = 2] ldi r25,0 ret ; 49return[length = 1] .L5: ldi r24,lo8(1) ; 6*movhi/5[length = 2] ldi r25,0 ret ; 51return[length = 1] The superfluous insn is #14 (*cmphi). This worked with 4.7 with the output as follows: pr60486: movw r18,r24 ; 7*movhi/1[length = 1] rjmp .L2 ; 48jump[length = 1] .L4: subi r18,1 ; 15addhi3_clobber/2[length = 2] sbc r19,__zero_reg__ breq .L5 ; 17branch[length = 1] adiw r24,1 ; 19addhi3_clobber/1[length = 1] .L2: cp r22,r24 ; 23*cmphi/3[length = 2] cpc r23,r25 brlo .L4 ; 24branch[length = 1] ldi r18,0 ; 9*movhi/2[length = 2] ldi r19,0 rjmp .L3 ; 50jump[length = 1] .L5: ldi r18,lo8(1) ; 8*movhi/5[length = 2] ldi r19,0 .L3: movw r24,r18 ; 56*movhi/1[length = 1] ret ; 55return[length = 1]
[Bug other/60486] [avr] missed optimization on detecting zero flag set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60486 Georg-Johann Lay changed: What|Removed |Added Target||avr Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-10 Known to work||4.7.2 Ever confirmed|0 |1 Known to fail||4.8.2 --- Comment #2 from Georg-Johann Lay --- cc0 should be set appropriately by avr.c:notice_update_cc which eventually calls avr.c:avr_out_plus_1 to get cc0 for addhi3_clobber (insn #13).
[Bug other/60486] [avr] missed optimization on detecting zero flag set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60486
--- Comment #3 from Georg-Johann Lay ---
Here is a smaller test case with similar artifact (insn #7):
extern void foo (unsigned);
char v;
void pr_60486 (unsigned z)
{
if (--z == 0)
v = 0;
foo (z);
}
pr_60486:
sbiw r24,1 ; 6addhi3_clobber/1[length = 1]
sbiw r24,0 ; 7*cmphi/1[length = 1]
brne .L9 ; 8branch[length = 1]
sts v,__zero_reg__ ; 10movqi_insn/3[length = 2]
.L9:
rjmp foo ; 14call_insn/4[length = 1]
[Bug c/60490] New: please define __LITTLE_ENDIAN__/__BIG_ENDIAN__ for every target where it makes sense
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60490 Bug ID: 60490 Summary: please define __LITTLE_ENDIAN__/__BIG_ENDIAN__ for every target where it makes sense Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: rafael.espindola at gmail dot com CC: chandlerc at gmail dot com, echristo at gmail dot com We noticed that both clang and gcc were fairly inconsistent and incompatible as to which targets cause __LITTLE_ENDIAN__/__BIG_ENDIAN__ to be defined. They are not as flexible __BYTE_ORDER__ (cannot represent __ORDER_PDP_ENDIAN__), but they cover the needs of most software. On the clang side we decided to just always define them if the target is little endian or big endian. It would be nice if gcc could do the same.
[Bug middle-end/60482] Loop optimization regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60482 Jakub Jelinek changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- The patch regresses the tree-ssa/ssa-ifcombine-10.c testcase, but that to me just looks as tree-ssa-ifcombine.c being not enough flexible. The difference starting with VRP1 without -> with the patch is just: @@ -27,14 +27,14 @@ f (int x, int a, int b) : _5 = x_3(D) & 4; if (_5 != 0) -goto ; - else goto ; + else +goto ; : : - # t_1 = PHI <0(2), 3(4), 0(3)> + # t_1 = PHI <0(2), 3(3), 0(4)> return t_1; which I'd say is quite unimportant difference ifcombine shouldn't care about, but apparently it does.
[Bug c/60490] please define __LITTLE_ENDIAN__/__BIG_ENDIAN__ for every target where it makes sense
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60490 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Looks like a bad decision on the clang side, don't see why we should follow it. The macros GCC has model the stuff, are flexible and I duplicating the info in yet another form doesn't make any sense.
[Bug c/60490] please define __LITTLE_ENDIAN__/__BIG_ENDIAN__ for every target where it makes sense
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60490 --- Comment #2 from Eric Christopher --- Why does it seem like a bad decision? Endianness can be separate from OS (or bare metal) so I don't see how outputting the macro as a per-cpu define is a bad thing.
[Bug c/60490] please define __LITTLE_ENDIAN__/__BIG_ENDIAN__ for every target where it makes sense
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60490 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jakub Jelinek --- Because it is redundant with __BYTE__ORDER__ == __LITTLE_ENDIAN__ (etc.) And, portable apps should use #include #if BYTE_ORDER == LITTLE_ENDIAN anyway. Note that __LITTLE_ENDIAN__ etc. is then fairly ambiguous, because it looks like a special version of LITTLE_ENDIAN macro, but has completely different meaning. And it is unclear from it what is little endian, whether bytes, words, floating point value bytes.
[Bug c/60490] please define __LITTLE_ENDIAN__/__BIG_ENDIAN__ for every target where it makes sense
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60490 --- Comment #4 from Eric Christopher --- I disagree for bare metal that including endian is the right way, but agree that __BYTE_ORDER__ is the right way to do this in general. Thanks Jakub.
[Bug c/60490] please define __LITTLE_ENDIAN__/__BIG_ENDIAN__ for every target where it makes sense
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60490 --- Comment #5 from Chandler Carruth --- (In reply to Eric Christopher from comment #4) > I disagree for bare metal that including endian is the right way, but agree > that __BYTE_ORDER__ is the right way to do this in general. > > Thanks Jakub. I don't really have a strong feeling about __BYTE_ORDER__ vs. other systems, but it would be very nice if there were consistently available macros in both GCC and Clang that could be used to detect endianness. If you don't like just defining __BIG_ENDIAN__ and __LITTLE_ENDIAN__, could you suggest a concrete pattern for __BYTE_ORDER__ which should be defined by the compiler on every platform Jakub? I'm particularly interested for the sake of bare metal or other freestanding implementations which benefit from asking the compiler rather than a system header.
[Bug c/60490] please define __LITTLE_ENDIAN__/__BIG_ENDIAN__ for every target where it makes sense
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60490 --- Comment #6 from Jakub Jelinek --- Just look what GCC does? Say on x86_64 it does: gcc -E -dD -xc /dev/null | grep ENDIAN #define __ORDER_LITTLE_ENDIAN__ 1234 #define __ORDER_BIG_ENDIAN__ 4321 #define __ORDER_PDP_ENDIAN__ 3412 #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ #define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__ on e.g. ppc64 it does: gcc -E -dD -xc /dev/null | grep ENDIAN #define __ORDER_LITTLE_ENDIAN__ 1234 #define __ORDER_BIG_ENDIAN__ 4321 #define __ORDER_PDP_ENDIAN__ 3412 #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ #define __FLOAT_WORD_ORDER__ __ORDER_BIG_ENDIAN__ Don't have access to PDP nor built cross-compiler for that, but it would expectably define __BYTE_ORDER__ to __ORDER_PDP_ENDIAN__.
[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 --- Comment #5 from janus at gcc dot gnu.org --- (In reply to janus from comment #3) > I think this should go into a separate PR. The problem of comment 2/3 is now tracked as PR60483.
[Bug c/60490] please define __LITTLE_ENDIAN__/__BIG_ENDIAN__ for every target where it makes sense
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60490 --- Comment #7 from Chandler Carruth --- (In reply to Jakub Jelinek from comment #6) > Just look what GCC does? > Say on x86_64 it does: > gcc -E -dD -xc /dev/null | grep ENDIAN > #define __ORDER_LITTLE_ENDIAN__ 1234 > #define __ORDER_BIG_ENDIAN__ 4321 > #define __ORDER_PDP_ENDIAN__ 3412 > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ > #define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__ > on e.g. ppc64 it does: > gcc -E -dD -xc /dev/null | grep ENDIAN > #define __ORDER_LITTLE_ENDIAN__ 1234 > #define __ORDER_BIG_ENDIAN__ 4321 > #define __ORDER_PDP_ENDIAN__ 3412 > #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ > #define __FLOAT_WORD_ORDER__ __ORDER_BIG_ENDIAN__ > Don't have access to PDP nor built cross-compiler for that, but it would > expectably define __BYTE_ORDER__ to __ORDER_PDP_ENDIAN__. Cool, seems like we could easily support both this and consistently defining __BIG_ENDIAN__ and __LITTLE_ENDIAN__ in Clang. Is there any reason to specifically avoid defining the latter two on systems where __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ (or little respectively)? If there is a reason to not do so, we probably shouldn't do it in Clang either. If there isn't a reason, maybe both GCC and Clang should do so?
[Bug libgcc/60472] Warning: array subscript is above array bounds when compiling crtstuff.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60472 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-03-10 Component|middle-end |libgcc Target Milestone|--- |4.9.0 Ever confirmed|0 |1
[Bug fortran/60483] [4.7/4.8/4.9 Regression] No IMPLICIT type error with: ASSOCIATE( X => derived_type() ) [i.e. w/ structure constructor]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60483 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-10 CC||janus at gcc dot gnu.org Summary|No IMPLICIT type error |[4.7/4.8/4.9 Regression] No |with: ASSOCIATE( X => |IMPLICIT type error with: |derived_type() ) [i.e. w/ |ASSOCIATE( X => |structure constructor] |derived_type() ) [i.e. w/ ||structure constructor] Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- This is a carry-over from PR 60458. Reduced test case: implicit none Type T integer :: val = 2 end type associate(X => T()) print *, X%val end associate end The error with 4.8 and trunk is: print *, X%val 1 Error: Symbol 'x' at (1) has no IMPLICIT type With 4.7 it is: print *, X%val 1 Error: Syntax error in PRINT statement at (1) And with 4.6 it compiles cleanly, which makes it a regression.
[Bug libgcc/60472] Warning: array subscript is above array bounds when compiling crtstuff.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60472 --- Comment #2 from uros at gcc dot gnu.org --- Author: uros Date: Mon Mar 10 18:31:20 2014 New Revision: 208457 URL: http://gcc.gnu.org/viewcvs?rev=208457&root=gcc&view=rev Log: PR libgcc/60472 * crtstuff.c (frame_dummy): Use void **jcr_list temporary variable to avoid array subscript is above array bounds warnings. Use __builtin_expect when checking *jcr_list for NULL. Modified: trunk/libgcc/ChangeLog trunk/libgcc/crtstuff.c
[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 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-10 Ever confirmed|0 |1 --- Comment #6 from Dominique d'Humieres --- Confirmed for 4.9.0 r208448.
[Bug libgcc/60472] Warning: array subscript is above array bounds when compiling crtstuff.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60472 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2014-03/msg00476.htm ||l Resolution|--- |FIXED --- Comment #3 from Uroš Bizjak --- Fixed for 4.9.
[Bug c++/60367] Default argument object is not getting constructed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60367 Jonathan Wakely changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #7 from Jonathan Wakely --- Jason, I don't think this is a regression, but it can have pretty bad results from seemingly harmless code (double free and other crashes caused by shallow copies instead of calling copy constructors)
[Bug fortran/60483] [4.7/4.8/4.9 Regression] No IMPLICIT type error with: ASSOCIATE( X => derived_type() ) [i.e. w/ structure constructor]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60483 --- Comment #2 from Dominique d'Humieres --- The change in behavior occurred after r181425 (r181424 is OK).
[Bug target/60410] [4.7/4.8/4.9 Regression] -fshort-double ICEs x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60410 --- Comment #5 from Dominique d'Humieres --- See also http://gcc.gnu.org/ml/gcc-testresults/2014-03/msg00661.html (x86_64-unknown-linux-gnu).
[Bug libstdc++/60491] New: Macros defined in sys/sysmacros.h pulled in by even in -std=c++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60491 Bug ID: 60491 Summary: Macros defined in sys/sysmacros.h pulled in by even in -std=c++11 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: will at wmitchell dot net The following minimal test case: #include void minor(int row, int col); fails to compile with gcc 4.8.2 even when -std=c++11 is passed. $ g++ -std=c++11 -pedantic test.cpp test.cpp:2:28: error: macro "minor" passed 2 arguments, but takes just 1 void minor(int row, int col); ^ test.cpp:2:6: error: variable or field ‘minor’ declared void void minor(int row, int col); ^ $ The problem is that pulls in sys/sysmacros.h, which defines: # define major(dev) gnu_dev_major (dev) # define minor(dev) gnu_dev_minor (dev) # define makedev(maj, min) gnu_dev_makedev (maj, min) There is an old, related bug at https://bugzilla.redhat.com/show_bug.cgi?id=130601 closed as WONTFIX I'm filing again because my expectation is that -std=c++11 wouldn't pull in these macros. Obviously these are not reserved words by the standard, so I don't think pulling in part of the standard library should define these macros. sys/sysmacros.h may also be pulled in by other standard library headers, I have not tested which ones do or do not.
[Bug libstdc++/51749] Including pollutes global namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51749 Jonathan Wakely changed: What|Removed |Added CC||will at wmitchell dot net --- Comment #31 from Jonathan Wakely --- *** Bug 60491 has been marked as a duplicate of this bug. ***
[Bug libstdc++/60491] Macros defined in sys/sysmacros.h pulled in by even in -std=c++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60491 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- (In reply to Will Mitchell from comment #0) > I'm filing again because my expectation is that -std=c++11 wouldn't pull in > these macros. I don't know why you thought -std=c++11 would change anything :-) To fix this we need to stop defining _GNU_SOURCE unconditionally, which I'm going to work on after the 4.9 release. *** This bug has been marked as a duplicate of bug 51749 ***
[Bug preprocessor/60492] New: Using the L#param in a macro fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60492 Bug ID: 60492 Summary: Using the L#param in a macro fails Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: jr at heisey dot org #define DEFINE_XML_TOKEN_STRING(n, s) const char n##a[] = #s; const wchar_t n##w[] = L#s; //defines for tags DEFINE_XML_TOKEN_STRING(CONFIG_ELM, config) The preprocessor inserts a space resulting in L "config" rather than L"config" First saw this on gcc on Windows. [D:\Proj\Synaptics\tools]"d:\Program Files (x86)\CodeBlocks.13\MinGW\bin\gcc.exe " --version gcc.exe (tdm-2) 4.8.1 Copyright (C) 2013 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. Reproduced it on GCC 4.5.1 on Fedora. [jrheisey@usu-fury CDCIApi]$ g++ --version g++ (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4) Copyright (C) 2010 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 preprocessor/60492] Using the L#param in a macro fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60492 --- Comment #1 from J.R. Heisey --- Created attachment 32327 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32327&action=edit preprocessor results for GCC 4.5.1
[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 #29 from Richard Henderson --- linj, that hunk is required. It's easy to produce a difference ICE without it. I believe that even this pr's test case with -fno-crossjumping is enough to trigger the different ICE. Jakub, it's way more difficult to merge these notes than one might think. Primarily because CSA hasn't done full CFA analysis. It might be possible to merge two REG_CFA_ADJUST_CFA relatively easily. But I'm not really sure how common that is. Certainly it didn't happen in this test case at all. I think at this point, any such optimization will have to wait for stage1.
[Bug c++/60367] Default argument object is not getting constructed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60367 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[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 #30 from Jakub Jelinek --- (In reply to Richard Henderson from comment #29) > linj, that hunk is required. It's easy to produce a difference ICE > without it. I believe that even this pr's test case with -fno-crossjumping > is enough to trigger the different ICE. > > Jakub, it's way more difficult to merge these notes than one might think. > Primarily because CSA hasn't done full CFA analysis. It might be possible > to merge two REG_CFA_ADJUST_CFA relatively easily. But I'm not really sure > how common that is. Certainly it didn't happen in this test case at all. > > I think at this point, any such optimization will have to wait for stage1. I'll try to gather some statistics on the combine-stack-adj.c hunk alone tomorrow.
[Bug debug/60339] gnat weird DW_AT_abstract_origin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60339 --- Comment #2 from Jan Kratochvil --- (In reply to Eric Botcazou from comment #1) > This is a non-inlined subroutine nested in an inlined subroutine, see > 3.3.8.4. OK, thanks for the pointer. > > BTW master (4.9 - r208124) failed on GNAT internal error during bootstrap. > > Please open a separate PR for this. I have seen it discussed elsewhere as a known issue.
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #35 from Dominique d'Humieres --- > http://gcc.gnu.org/ml/fortran/2014-03/msg00079.html The test character buffer*10 integer i,j DO j=1, write(buffer,'(i4)') j read(buffer,'(i10)') i ENDDO end takes ~3.5s without the patch (and 4.7.4 or 4.8.3) and ~0.7s with it (~2s with 4.6). The test character buffer(1)*10 integer i,j DO j=1, write(buffer(1),'(i4)') j read(buffer,*) i ENDDO end takes ~1.8s with/without the patch (~11.3s with 4.6, ~10.2s with 4.7.4, and ~13.6 with 4.8.3, i7 2.8Ghz, turbo 3.8Ghz).
