[Bug c++/63201] Full specialization of a member variable template of a class template does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63201 Ville Voutilainen changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-08 Ever confirmed|0 |1
[Bug sanitizer/61897] sanitizer internal compiler error: in build2_stat, at tree.c:4160
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61897 Yury Gribov changed: What|Removed |Added CC||y.gribov at samsung dot com --- Comment #3 from Yury Gribov --- Tom, could you close if works for you?
[Bug middle-end/62140] [GCC-4.10.0][ASAN] ICE: : in build2_stat, at tree.c:4265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62140 --- Comment #5 from Yury Gribov --- Sabrina, could you close if works for you?
[Bug bootstrap/63204] New: gtype-desc.c:887:40: error: 'struct loop' has no member named 'former_header' breaks bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63204 Bug ID: 63204 Summary: gtype-desc.c:887:40: error: 'struct loop' has no member named 'former_header' breaks bootstrap Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: mikpelinux at gmail dot com Attempting to bootstrap latest gcc-5 snapshot (20140907, aka r215005) fails with: g++ -c -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I/mnt/scratch/gcc-5-20140907/gcc -I/mnt/scratch/gcc-5-20140907/gcc/. -I/mnt/scratch/gcc-5-20140907/gcc/../include -I/mnt/scratch/gcc-5-20140907/gcc/../libcpp/include -I/mnt/scratch/gcc-5-20140907/gcc/../libdecnumber -I/mnt/scratch/gcc-5-20140907/gcc/../libdecnumber/dpd -I../libdecnumber -I/mnt/scratch/gcc-5-20140907/gcc/../libbacktrace-o gtype-desc.o -MT gtype-desc.o -MMD -MP -MF ./.deps/gtype-desc.TPo gtype-desc.c In file included from /mnt/scratch/gcc-5-20140907/gcc/ggc.h:34:0, from /mnt/scratch/gcc-5-20140907/gcc/hash-table.h:199, from /mnt/scratch/gcc-5-20140907/gcc/hash-set.h:24, from /mnt/scratch/gcc-5-20140907/gcc/tree-core.h:24, from /mnt/scratch/gcc-5-20140907/gcc/tree.h:23, from gtype-desc.c:30: gtype-desc.c: In function 'void gt_ggc_mx_loop(void*)': gtype-desc.c:887:40: error: 'struct loop' has no member named 'former_header' gt_ggc_m_15basic_block_def ((*x).former_header); ^ ./gtype-desc.h:829:7: note: in definition of macro 'gt_ggc_m_15basic_block_def' if (X != NULL) gt_ggc_mx_basic_block_def (X);\ ^ gtype-desc.c:887:40: error: 'struct loop' has no member named 'former_header' gt_ggc_m_15basic_block_def ((*x).former_header); ^ ./gtype-desc.h:829:45: note: in definition of macro 'gt_ggc_m_15basic_block_def' if (X != NULL) gt_ggc_mx_basic_block_def (X);\ ^ gtype-desc.c: In function 'void gt_pch_nx_loop(void*)': gtype-desc.c:4070:40: error: 'struct loop' has no member named 'former_header' gt_pch_n_15basic_block_def ((*x).former_header); ^ ./gtype-desc.h:1733:7: note: in definition of macro 'gt_pch_n_15basic_block_def' if (X != NULL) gt_pch_nx_basic_block_def (X);\ ^ gtype-desc.c:4070:40: error: 'struct loop' has no member named 'former_header' gt_pch_n_15basic_block_def ((*x).former_header); ^ ./gtype-desc.h:1733:45: note: in definition of macro 'gt_pch_n_15basic_block_def' if (X != NULL) gt_pch_nx_basic_block_def (X);\ ^ gtype-desc.c: In function 'void gt_pch_p_4loop(void*, void*, gt_pointer_operator, void*)': gtype-desc.c:7312:16: error: 'struct loop' has no member named 'former_header' op (&((*x).former_header), cookie); ^ make[3]: *** [gtype-desc.o] Error 1 make[3]: Leaving directory `/mnt/scratch/objdir50/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/mnt/scratch/objdir50' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/mnt/scratch/objdir50' make: *** [bootstrap] Error 2 So far I've gotten this both on armv5tel-linux-gnueabi and x86_64-pc-linux-gnu. This is a regression from last week's snapshot.
[Bug tree-optimization/63202] tree vectorizer does not make use of alignment information from VRP/CCP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63202 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- I guess the cast prevents this from being handled by maybe_set_nonzero_bits, guess it could be handled there. That said, it is extremely fragile, because we insert the range and non-zero bits info on SSA_NAMEs and have this single exception for function parameters if they aren't used anywhere before the __builtin_unreachable check. As soon as e.g. the function is inlined, there might be more uses and the info can be lost. Richard didn't want to disable forward propagation if some SSA_NAME holds a useful range info which the to be propagated SSA_NAME does not hold (in that case, we'd keep a new SSA_NAME with the more precise range/non-zero info around and be able to stick it somewhere). The reason why we have __builtin_assume_aligned defined the way it is is that there is always an SSA_NAME to stick that info to, it is clear in which part of the function the condition is true.
[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #10 from rguenther at suse dot de --- On Mon, 8 Sep 2014, hubicka at ucw dot cz wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 > > --- Comment #9 from Jan Hubicka --- > > The issue is that we resolve aliases in a bogus way, not warning/error > > stuff. > > Those are not aliases, but duplicated declarations that are supposed to not > exist since one declaration rule was introduced in early 4.x series. > It is bug that frotnend allowed creating them and made it part of the fortify > interface. I still think it is better to resolve those early and start > rejecting > any other uses than the fortify case... Well - whatever makes the fortify case work as expected works for me. Note that it would be nice to fix this on the 4.9 branch as well.
[Bug ipa/63196] [5.0 regression] FAIL: g++.dg/torture/pr57140.C -O3 -fomit-frame-pointer (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63196 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |5.0 --- Comment #2 from Richard Biener --- Mine.
[Bug ipa/63196] [5.0 regression] FAIL: g++.dg/torture/pr57140.C -O3 -fomit-frame-pointer (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63196 --- Comment #3 from Richard Biener --- Ok, so the issue here is that we are copying a function during inline transform whose loops state needs fixups. That's undesirable.
[Bug bootstrap/63204] gtype-desc.c:887:40: error: 'struct loop' has no member named 'former_header' breaks bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63204 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-09-08 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/63202] tree vectorizer does not make use of alignment information from VRP/CCP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63202 --- Comment #2 from Richard Biener --- Well, as with restrict it would be nice to be able to annotate the memory references themselves with alignment info. Btw, a possibility would be to insert assume_aligned calls into the IL from the if (p & 15) __builtin_unreachable (); pattern and remove the test & __builtin_unreachable (). Of course quite special and breaks down for assume (!(p & 15) && a == b). As Jakub said, the testcase can be handled with the existing code as there is no use of p before the conditional. Note that there isn't an extra loop for the "unaligned" case but the extra loop is for the case where there is aliasing between p and b. But yes, we fail to use aligned loads here (but movdqu doesn't have a penalty for that).
[Bug middle-end/63200] [5.0 Regression] FAIL: gcc.dg/tls/opt-11.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63200 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |5.0
[Bug target/63195] [5.0 regression] stage3 build/gengtype miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63195 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.0
[Bug libstdc++/63199] Inserting std::wregex to std::vector loses some std::wregex values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63199 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-09-08 Assignee|unassigned at gcc dot gnu.org |timshen at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- Tim has found the problem: https://gcc.gnu.org/ml/libstdc++/2014-09/msg00020.html
[Bug c++/63198] decltype in template function declaration yields spurious error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63198
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-09-08
Summary|[c++1y] decltype in |decltype in template
|template function |function declaration yields
|declaration yields spurious |spurious error
|error |
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
struct X { using t1 = int; };
struct Y { X operator=(const Y&); } y;
template void f1(decltype(y = y)::t1);
$ g++ -std=c++11 -c d.cc
d.cc:3:50: error: variable or field ‘f1’ declared void
template void f1(decltype(y = y)::t1);
^
Using -std=c++1y is not necessary, this doesn't use any C++14 features.
The error only happens if f1 is a template, and only seems to happen if the
decltype expression uses the assignment operator, not any other expression I
tried.
[Bug rtl-optimization/63191] [4.8/4.9/5 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63191
Richard Biener changed:
What|Removed |Added
Target||i?86-*-*
Status|UNCONFIRMED |NEW
Keywords||memory-hog
Last reconfirmed||2014-09-08
CC||rth at gcc dot gnu.org
Blocks||47344
Ever confirmed|0 |1
Summary|32-bit gcc uses excessive |[4.8/4.9/5 Regression]
|memory during dead store|32-bit gcc uses excessive
|elimination with -fPIC |memory during dead store
||elimination with -fPIC
Target Milestone|--- |4.8.4
--- Comment #1 from Richard Biener ---
Confirmed. Possibly excessive value_rtx expansion from dse.c:canon_address.
The testcase is a function with a single basic-block and 3 stores
(the static initializer function) with the pattern
D.94947 = (struct Z *) &Zs;
D.94947->x1_ = &Xs1[0];
D.94947->x2_ = 1;
D.94947->x3_ = 1;
temp.20397 = D.94947 + 12;
temp.20397->x1_ = &Xs90[0];
temp.20397->x2_ = 2;
temp.20397->x3_ = 1;
...
temp.30587 = temp.30586 + 12;
temp.30587->x1_ = &Xs611[0];
temp.30587->x2_ = 2;
temp.30587->x3_ = 1;
thus groups of three stores followed by an address adjustment. The above
is from a GCC 4.3 IL dump.
The GCC 4.9 IL dump shows
MEM[(struct Z *)&Zs].x1_ = &Xs1;
MEM[(struct Z *)&Zs].x2_ = 1;
MEM[(struct Z *)&Zs].x3_ = 1;
MEM[(struct Z *)&Zs + 12B].x1_ = &Xs90;
MEM[(struct Z *)&Zs + 12B].x2_ = 2;
MEM[(struct Z *)&Zs + 12B].x3_ = 1;
MEM[(struct Z *)&Zs + 24B].x1_ = &Xs91;
MEM[(struct Z *)&Zs + 24B].x2_ = 2;
MEM[(struct Z *)&Zs + 24B].x3_ = 1;
...
MEM[(struct Z *)&Zs + 122292B].x1_ = &Xs611;
MEM[(struct Z *)&Zs + 122292B].x2_ = 2;
MEM[(struct Z *)&Zs + 122292B].x3_ = 1;
which causes each store to be expanded via st like
(insn 71298 71297 71299 2 (set (reg:SI 40822)
(const:SI (unspec:SI [
(symbol_ref:SI ("_ZL2Zs") [flags 0x2] )
] UNSPEC_GOTOFF))) t.C:5 -1
(nil))
(insn 71299 71298 71300 2 (set (mem/c:SI (plus:SI (plus:SI (reg:SI 3 bx)
(reg:SI 40822))
(const_int 122216 [0x1dd68])) [4 MEM[(struct Z *)&Zs +
122208B].x3_+0 S4 A64])
(const_int 1 [0x1])) t.C:5 -1
(nil))
I suppose "lowering" PIC addresses somewhere before RTL expansion (and
CSEing the addresses) would help here. Lowering as in not treating
them as is_gimple_min_invariant.
With 4.3 we have a single address load for &Zs (but of course we retain
the individual stored addresses loads - thus still very many PIC addresses
in this function).
Why is CSE not able to CSE the UNSPEC_GOTOFF addresses? Does it not do
it because of the (const:SI ...) wrapping (as in, not profitable)? Or is
it confused about the other intermediate UNSPEC_GOTOFF uses?
That said, cse1 should be able to turn the RTL into sth equivalent to
what 4.3 produced.
[Bug rtl-optimization/63191] [4.8/4.9/5 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63191
--- Comment #2 from Richard Biener ---
With
int a, b, c, d;
struct X { int a; int b; void *p; } z[4];
void foo (void)
{
z[0].a = 1;
z[0].b = 2;
z[0].p = &a;
z[1].a = 1;
z[1].b = 2;
z[1].p = &b;
z[2].a = 1;
z[2].b = 2;
z[2].p = &c;
z[3].a = 1;
z[3].b = 2;
z[3].p = &d;
}
CSEing of the GOT load of z works.
[Bug target/63190] Assembler errors when building md5 code from fbb on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63190 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Biener --- fixed.
[Bug tree-optimization/63189] [4.8 Regression] Incorrect results from trivial loop when optimized with O3 or O2+tree vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63189 Richard Biener changed: What|Removed |Added Keywords||wrong-code CC||congh at gcc dot gnu.org Target Milestone|--- |4.8.4
[Bug bootstrap/63188] [5 Regression] r214954 breaks bootstrap on x86_64-apple-darwin13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63188 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.0
[Bug middle-end/63186] [4.9/5 Regression] Undefined .L* symbols because of fnsplit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63186 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.2
[Bug c++/63203] Self-initialization of reference not diagnosed if it occurs within a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63203 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-08 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- IMHO we should have a specific check for self-initialized references, instead of relying on the compiler to identify the use of an uninitialized variable in later code. Doing self-init for references to silence uninitialized warnings makes no sense, because you can't re-bind the reference later, so it will always stay uselessly bound to itself.
[Bug fortran/63205] New: [OOP] Wrongly rejects type = class (for identical declared type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63205 Bug ID: 63205 Summary: [OOP] Wrongly rejects type = class (for identical declared type) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: dominiq at lps dot ens.fr, janus at gcc dot gnu.org Depends on: 57530 +++ This bug was initially created as a clone of Bug #57530 +++ PR 57530 comment #3: > Created attachment 30262 [details] > Draft patch - does not fully work, yet > > Currently fails for > x = func1() > in assign_11.f90 PR 57530 comment #8: > The original test case (cf. PR 57530 comment 0) is now solved. > > However, only "type => class" is handled. Still missing is "type = class", > where CLASS is a (coarray) scalar or (coarray) array variable, function or > an array constructor. See also PR 57530 comment 3.
[Bug c++/63203] Self-initialization of reference not diagnosed if it occurs within a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63203
--- Comment #2 from Jonathan Wakely ---
I tried something like this:
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -6101,6 +6101,12 @@ initialize_local_var (tree decl, tree init)
-Wno-init-self works (c++/34772). */
gcc_assert (TREE_OPERAND (init, 0) == decl);
DECL_INITIAL (decl) = TREE_OPERAND (init, 1);
+
+ if (warn_init_self && TREE_CODE (type) == REFERENCE_TYPE
+ && TREE_OPERAND (init, 1) == decl)
+warning_at (DECL_SOURCE_LOCATION (decl),
+OPT_Winit_self,
+"Reference %qD is initialized with itself", decl);
}
else
{
but the TREE_OPERAND (init, 1) == decl condition is false and I'm not sure how
to fix it.
[Bug tree-optimization/61743] [5 Regression] Complete unroll is not happened for loops with short upper bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61743 --- Comment #10 from Yuri Rumyantsev --- Richard, Do you have any progress? Thanks. 2014-08-13 12:35 GMT+04:00 rguenth at gcc dot gnu.org : > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61743 > > --- Comment #9 from Richard Biener --- > (In reply to Yuri Rumyantsev from comment #8) >> Richard, >> >> I tested both proposed fixes and i turned out that the first one is >> preferable since performance of benchmark came back. Note that hoisting 2nd >> vrp pass gave us another 14% slowdown but I did not investigate it. >> >> Should I tested your fix or you do it yourself? > > I'd like to explore on how to make it a little more "generic", it's a very > special hack as-is. > >> Thanks. > > -- > You are receiving this mail because: > You reported the bug.
[Bug tree-optimization/62012] Loop is not vectorized after function inlining (SCEV)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62012 --- Comment #2 from Yuri Rumyantsev --- Any updates? Thanks.
[Bug tree-optimization/61743] [5 Regression] Complete unroll is not happened for loops with short upper bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61743 --- Comment #11 from rguenther at suse dot de --- On Mon, 8 Sep 2014, ysrumyan at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61743 > > --- Comment #10 from Yuri Rumyantsev --- > Richard, > > Do you have any progress? No, I didn't yet have time to get back to this.
[Bug tree-optimization/62012] Loop is not vectorized after function inlining (SCEV)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62012
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2014-09-08
Ever confirmed|0 |1
--- Comment #3 from Richard Biener ---
So it's independend of LTO.
Confirmed. We have
_28 = &MEM[(struct Array *)&fa + 256B].a[0] + _3;
*_28 = u_23;
which SCEV messes up because it ends up with
(instantiate_scev
(instantiate_below = 4)
(evolution_loop = 1)
(chrec = &MEM[(struct Array *)&fa + 256B].a[0])
(res = &MEM[(struct Array *)&fa + 256B].a[0]))
(instantiate_scev
(instantiate_below = 4)
(evolution_loop = 1)
(chrec = {(long unsigned int) first_6(D) * 4, +, 4}_1)
(res = {(long unsigned int) first_6(D) * 4, +, 4}_1))
(set_scalar_evolution
instantiated_below = 4
(scalar = _13)
(scalar_evolution = {&MEM[(struct Array *)&fa + 256B].a[(sizetype)
first_6(D)], +, 4}_1))
)
failed: evolution of base is not affine.
Not sure why it thinks that.
Btw, on trunk we now vectorize this just fine probably because of the fix
for PR63148 which avoids moving first_6 * 4 inside the array-ref and we
get
(scalar_evolution = {&MEM[(struct Array *)&fa + 256B].a[0] + (sizetype)
((long unsigned int) first_6(D) * 4), +, 4}_1))
)
success.
instead.
So - can you re-check please?
[Bug middle-end/62140] [GCC-4.10.0][ASAN] ICE: : in build2_stat, at tree.c:4265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62140 --- Comment #6 from Sabrina Souto --- I checked with the current code in trunk and the test is passing, did you fixed it? What do you mean by "close"? Change the status for "RESOLVED"? (In reply to Yury Gribov from comment #5) > Sabrina, could you close if works for you?
[Bug middle-end/62140] [GCC-4.10.0][ASAN] ICE: : in build2_stat, at tree.c:4265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62140 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek --- Fixed then.
[Bug bootstrap/63204] gtype-desc.c:887:40: error: 'struct loop' has no member named 'former_header' breaks bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63204 --- Comment #2 from Richard Biener --- Author: rguenth Date: Mon Sep 8 12:01:50 2014 New Revision: 215012 URL: https://gcc.gnu.org/viewcvs?rev=215012&root=gcc&view=rev Log: 2014-09-08 Richard Biener PR bootstrap/63204 * cfgloop.c (mark_loop_for_removal): Track former header unconditionally. * cfgloop.h (struct loop): Add former_header member unconditionally. * loop-init.c (fix_loop_structure): Enable bogus loop removal diagnostic unconditionally. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgloop.c trunk/gcc/cfgloop.h trunk/gcc/loop-init.c
[Bug bootstrap/63204] gtype-desc.c:887:40: error: 'struct loop' has no member named 'former_header' breaks bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63204 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug fortran/47486] gfortran -M exits with fatal error when -o option is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47486 John Travers changed: What|Removed |Added CC||jtravs at gmail dot com --- Comment #8 from John Travers --- I also can confirm this bug on 4.9.1, any progress?
[Bug middle-end/40135] using alias-set zero for union accesses necessary because of RTL alias oracle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40135 --- Comment #3 from Richard Biener --- At least improved (but maybe not fixed) by 2010-02-16 Richard Guenther * alias.c (memrefs_conflict_p): Distinguish must-alias from don't know. (true_dependence): If memrefs_conflict_p computes must-alias trust it. Move TBAA check after offset-based disambiguation. (canon_true_dependence): Likewise.
[Bug middle-end/40135] using alias-set zero for union accesses necessary because of RTL alias oracle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40135 --- Comment #4 from Richard Biener --- Ok it still has in the function comment ??? Contrary to the tree alias oracle this does not return one for X + non-constant and Y + non-constant when X and Y are equal. If that is fixed the TBAA hack for union type-punning can be removed. */ which explains what is remaining to do.
[Bug middle-end/40135] using alias-set zero for union accesses necessary because of RTL alias oracle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40135 --- Comment #5 from Richard Biener --- Eventually just removing the call to mems_in_disjoint_alias_sets_p fixes the rest (rtx_refs_may_alias_p will apply TBAA as well, _after_ positively bailing out on the union punning).
[Bug target/63206] New: Gcc 4.9.1 Generated code needlessly stacks r3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63206
Bug ID: 63206
Summary: Gcc 4.9.1 Generated code needlessly stacks r3
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: alexandre.nunes at gmail dot com
Created attachment 33459
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33459&action=edit
testcase
when compiling the following testcase code:
#include
#include
static uint16_t lb[32];
void copy(uint16_t buffer[32])
{
register uint32_t ret asm("r3");
asm volatile ("mrs %0, cpsr\nmsr cpsr_c, #0xDF" : "=r" (ret));
memcpy(buffer, lb, 32 * sizeof(uint16_t));
asm volatile ("msr cpsr_c, %0" : : "r" (ret));
}
w/ -mcpu=arm7tdmi -mno-thumb-interwork -O2, GCC generates code such as:
stmfdsp!, {r3, lr}
mrs r3, cpsr
msr cpsr_c, #0xDF
ldrr1, .L3
movr2, #64
blmemcpy
msr cpsr_c, r3
ldmfdsp!, {r3, pc}
What's suboptimal is the r3 push/pop. There's no need to preserve/restore r3 as
it's a scratch register.
The testcase forces r3 to be used, because I couldn't make a minimal testcase
that would automatically do it, but I observed this in actual code (which is
very close, if not identical, to the testcase).
Without that (register var + asm("r3")), the generated code would pick r4 and
generate code identical to above, which kinds of makes sense: stacking is
required to r4 (while one could arguee why it would pick a caller-preserved reg
anyway, a different bug IMHO).
Gcc was a vanilla 4.9.1 compiled to arm-none-eabi:
arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/arm-none-eabi/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/local/arm-none-eabi-4.9.1/libexec/gcc/arm-none-eabi/4.9.1/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-4.9.1/configure --target=arm-none-eabi
--prefix=/usr/local/arm-none-eabi-4.9.1 --enable-interwork
--enable-languages=c,c++ --with-newlib
--with-headers=../newlib-20140525/newlib/libc/include --with-float=soft
--enable-long-long
Thread model: single
gcc version 4.9.1 (GCC)
[Bug ipa/63196] [5.0 regression] FAIL: g++.dg/torture/pr57140.C -O3 -fomit-frame-pointer (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63196 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug ipa/63196] [5.0 regression] FAIL: g++.dg/torture/pr57140.C -O3 -fomit-frame-pointer (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63196 --- Comment #5 from Richard Biener --- Author: rguenth Date: Mon Sep 8 14:28:51 2014 New Revision: 215016 URL: https://gcc.gnu.org/viewcvs?rev=215016&root=gcc&view=rev Log: 2014-09-08 Richard Biener PR ipa/63196 * tree-inline.c (copy_loops): The source loop header should always be non-NULL. (tree_function_versioning): If loops need fixup after removing unreachable blocks fix them. * omp-low.c (simd_clone_adjust): Do not add incr block to loop under construction. Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/gcc/tree-inline.c
[Bug c++/63207] New: ICE in expand_expr_real_l when instantiating a template with a lambda that captures a const variable with a dependent initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63207
Bug ID: 63207
Summary: ICE in expand_expr_real_l when instantiating a
template with a lambda that captures a const variable
with a dependent initializer
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: st at quanttec dot com
Compiling the following following code with the current trunk GCC results in an
ICE.
template
struct Base {
T value;
};
template
struct Test : Base {
T test() {
const int x = this->value;
return ([&]{ return x; })();
}
};
int main() {
Test t;
t.value = 0;
return t.test();
}
g++ test.cpp --std=c++11 -Wall
test.cpp: In lambda function:
test.cpp:10:28: warning: ‘x’ is used uninitialized in this function
[-Wuninitialized]
return ([&]{ return x; })();
^
test.cpp:9:15: note: ‘x’ was declared here
const int x = this->value;
^
test.cpp:10:28: internal compiler error: in expand_expr_real_1, at expr.c:9517
return ([&]{ return x; })();
^
0x8c96ba expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.c:9517
0x8d0dea store_expr(tree_node*, rtx_def*, int, bool)
../../gcc/gcc/expr.c:5338
0x8d8e4b expand_assignment(tree_node*, tree_node*, bool)
../../gcc/gcc/expr.c:5124
0x7e3b33 expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3274
0x7e3b33 expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3376
0x7e99d3 expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:5215
0x7eb86f execute
../../gcc/gcc/cfgexpand.c:5821
[Bug c++/61825] [5 regression] g++.dg/cpp0x/static_assert9.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61825 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE --- Honza, you meant to prepare a patch in July already https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00985.html but nothing has happened since. Could you please get to this soon? This regression is causing testsuite noise for two months now. Thanks. Rainer
[Bug tree-optimization/63202] tree vectorizer does not make use of alignment information from VRP/CCP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63202 --- Comment #3 from Andi Kleen --- I'm not sure rewriting the pattern to assume_aligned would be useful. After all the user could already use assume_aligned directly. I was more thinking of cases when VRP/CCP can prove alignment in other ways from the code, and the vectorizer should use that. Good point that the fallback is not for unalignment. Should probably use a more fancy test case where unalignment matters for the cost model. One interesting case is avoiding the need for tail code when the iteration is not a multiple of the vector length.
[Bug target/63208] New: [SH] Add attribute naked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63208 Bug ID: 63208 Summary: [SH] Add attribute naked Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: olegendo at gcc dot gnu.org Target: sh*-*-* Several targets support the 'naked' function attribute. It'd be nice to have support for that on SH, too.
[Bug rtl-optimization/63209] New: [ARM] Wrong conditional move generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63209
Bug ID: 63209
Summary: [ARM] Wrong conditional move generated
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: xinliangli at gmail dot com
Created attachment 33460
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33460&action=edit
patch file
GCC (arm-unknown-linux-gnueabi) generates wrong code (O2) for the following
program. The problem is that it uses a source register in the condition move
that has already been overwritten in the previous move.
The program produces output:
top[-1]: ff7a7a7a top[0]: ff7a7a7a left: ff7b7b7b pred: ff7a7a7a
pred != left
The bad assembly code is:
cmn r1, r2
mov r0, r3
movgt r0, r3
The expected output is:
top[-1]: ff7a7a7a top[0]: ff7a7a7a left: ff7b7b7b pred: ff7b7b7b
The expected assembly:
cmn r1, r2
movle r0, r3
The attached patch fixed the problem. The patch passes regression test.
// tests.c
#include
static int Sub(int a, int b) {
return b -a;
}
static unsigned Select(unsigned a, unsigned b, unsigned c) {
const int pa_minus_pb =
Sub((a >> 8) & 0xff, (b >> 8) & 0xff) +
Sub((a >> 0) & 0xff, (b >> 0) & 0xff);
return (pa_minus_pb <= 0) ? a : b;
}
__attribute__((noinline)) unsigned Predictor(unsigned left, const unsigned*
const top) {
const unsigned pred = Select(top[1], left, top[0]);
return pred;
}
int main(void) {
const unsigned top[2] = {0xff7a7a7a, 0xff7a7a7a};
const unsigned left = 0xff7b7b7b;
const unsigned pred = Predictor(left, top /*+ 1*/);
fprintf(stderr, "top[-1]: %8x top[0]: %8x left: %8x pred: %8x\n",
top[0], top[1], left, pred);
if (pred == left)
return 0;
fprintf(stderr, "pred != left\n");
return 1;
}
[Bug debug/61923] [4.8 Regression] -fcompare-debug errors while building Linux kernel.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61923 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Mon Sep 8 19:07:00 2014 New Revision: 215020 URL: https://gcc.gnu.org/viewcvs?rev=215020&root=gcc&view=rev Log: Backported from mainline 2014-08-06 Vladimir Makarov PR debug/61923 * haifa-sched.c (advance_one_cycle): Fix dump. (schedule_block): Don't advance cycle if we are already at the beginning of the cycle. * gcc.target/i386/pr61923.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr61923.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/haifa-sched.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug debug/61923] [4.8 Regression] -fcompare-debug errors while building Linux kernel.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61923 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Jakub Jelinek --- Fixed, thanks.
[Bug c++/61838] ICE on Windows with ctors defined outside class definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61838
Stephan Tolksdorf changed:
What|Removed |Added
CC||st at quanttec dot com
--- Comment #2 from Stephan Tolksdorf ---
This regression from 4.8 seems to have been fixed on trunk but is still present
on the 4.9 branch. Could the fix be packported to 4.9?
Compiling the following simple snippet with "-std=c++11" produces a segfault
with 4.9:
template struct A {};
struct B { B(A); };
B::B(A) {}
cc1plus: internal compiler error: Segmentation fault
0x919b1f crash_signal
../../gcc/gcc/toplev.c:337
0x6a5ea2 analyze_functions
../../gcc/gcc/cgraphunit.c:1043
0x6a6f4f finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2327
0x559ebb cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4616
[Bug tree-optimization/60196] [4.8 Regression] Incorrect compilation with -fwrapv and -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60196 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Mon Sep 8 20:07:29 2014 New Revision: 215024 URL: https://gcc.gnu.org/viewcvs?rev=215024&root=gcc&view=rev Log: PR tree-optimization/60196 PR tree-optimization/63189 Backported from mainline 2013-09-17 Cong Hou * tree-vect-patterns.c (vect_recog_dot_prod_pattern): Fix a bug when checking the dot production pattern. The type of rhs operand of multiply is now checked correctly. * gcc.dg/vect/pr63189.c: New test. * gcc.dg/vect/pr60196-1.c: New test. * gcc.dg/vect/pr60196-2.c: New test. Backported from mainline 2013-09-17 Cong Hou * gcc.dg/vect/vect-reduc-dot-s16c.c: Add a test case with dot product on two arrays with short and int types. This should not be recognized as a dot product pattern. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/vect/pr60196-1.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/vect/pr60196-2.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/vect/pr63189.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/vect/vect-reduc-dot-s16c.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-vect-patterns.c
[Bug tree-optimization/63189] [4.8 Regression] Incorrect results from trivial loop when optimized with O3 or O2+tree vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63189 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Mon Sep 8 20:07:29 2014 New Revision: 215024 URL: https://gcc.gnu.org/viewcvs?rev=215024&root=gcc&view=rev Log: PR tree-optimization/60196 PR tree-optimization/63189 Backported from mainline 2013-09-17 Cong Hou * tree-vect-patterns.c (vect_recog_dot_prod_pattern): Fix a bug when checking the dot production pattern. The type of rhs operand of multiply is now checked correctly. * gcc.dg/vect/pr63189.c: New test. * gcc.dg/vect/pr60196-1.c: New test. * gcc.dg/vect/pr60196-2.c: New test. Backported from mainline 2013-09-17 Cong Hou * gcc.dg/vect/vect-reduc-dot-s16c.c: Add a test case with dot product on two arrays with short and int types. This should not be recognized as a dot product pattern. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/vect/pr60196-1.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/vect/pr60196-2.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/vect/pr63189.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/vect/vect-reduc-dot-s16c.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-vect-patterns.c
[Bug tree-optimization/60196] [4.8 Regression] Incorrect compilation with -fwrapv and -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60196 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Mon Sep 8 20:15:31 2014 New Revision: 215025 URL: https://gcc.gnu.org/viewcvs?rev=215025&root=gcc&view=rev Log: PR tree-optimization/60196 PR tree-optimization/63189 * gcc.dg/vect/pr63189.c: New test. * gcc.dg/vect/pr60196-1.c: New test. * gcc.dg/vect/pr60196-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr60196-1.c trunk/gcc/testsuite/gcc.dg/vect/pr60196-2.c trunk/gcc/testsuite/gcc.dg/vect/pr63189.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/63189] [4.8 Regression] Incorrect results from trivial loop when optimized with O3 or O2+tree vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63189 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Mon Sep 8 20:15:31 2014 New Revision: 215025 URL: https://gcc.gnu.org/viewcvs?rev=215025&root=gcc&view=rev Log: PR tree-optimization/60196 PR tree-optimization/63189 * gcc.dg/vect/pr63189.c: New test. * gcc.dg/vect/pr60196-1.c: New test. * gcc.dg/vect/pr60196-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr60196-1.c trunk/gcc/testsuite/gcc.dg/vect/pr60196-2.c trunk/gcc/testsuite/gcc.dg/vect/pr63189.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/63189] [4.8 Regression] Incorrect results from trivial loop when optimized with O3 or O2+tree vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63189 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Mon Sep 8 20:18:02 2014 New Revision: 215026 URL: https://gcc.gnu.org/viewcvs?rev=215026&root=gcc&view=rev Log: PR tree-optimization/60196 PR tree-optimization/63189 * gcc.dg/vect/pr63189.c: New test. * gcc.dg/vect/pr60196-1.c: New test. * gcc.dg/vect/pr60196-2.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/pr60196-1.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/pr60196-2.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/pr63189.c Modified: branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/60196] [4.8 Regression] Incorrect compilation with -fwrapv and -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60196 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/60196] [4.8 Regression] Incorrect compilation with -fwrapv and -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60196 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Mon Sep 8 20:18:02 2014 New Revision: 215026 URL: https://gcc.gnu.org/viewcvs?rev=215026&root=gcc&view=rev Log: PR tree-optimization/60196 PR tree-optimization/63189 * gcc.dg/vect/pr63189.c: New test. * gcc.dg/vect/pr60196-1.c: New test. * gcc.dg/vect/pr60196-2.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/pr60196-1.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/pr60196-2.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/pr63189.c Modified: branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/63189] [4.8 Regression] Incorrect results from trivial loop when optimized with O3 or O2+tree vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63189 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug c/63178] Missed "incorrect-type-passed-to-function warning"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63178 --- Comment #5 from Dima Kogan --- Hi. I cherry-picked the commit you mentioned, rebuilt gcc, and the bug was not resolved. Just in case I did something wrong in that process, I waited for Debian to update their package. This just happened, and I updated. I'm now using gcc4.9 version 4.9.1-13 from Debian/unstable. The Debian changelog says this is using r215008: http://metadata.ftp-master.debian.org/changelogs//main/g/gcc-4.9/gcc-4.9_4.9.1-13_changelog As before, the bug is unresolved. Thanks.
[Bug rtl-optimization/62146] CSE replaces constant with an expression incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62146 Easwaran Raman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Easwaran Raman --- Google ref: b/16870586
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 Lawrence Velázquez changed: What|Removed |Added CC||larryv at macports dot org --- Comment #34 from Lawrence Velázquez --- (In reply to James Clarke from comment #33) > I was able to perform a complete clean bootstrap on my system, so I'm > curious as to what error(s) you got? I’m also seeing a build failure on 10.9.4 13E28 with Xcode 5.1.1 5B1008, with your mailing list patches applied. I'll attach the log in a moment; it was generated by MacPorts during a 64-bit build of our libgcc port. > I agree, the two are not equivalent, but the first one (!defined(X) || X) is > wrong in my opinion, as if the macro is not defined, the documentation for > dir(5) states that the 32-bit versions are used. I got the build to succeed by changing # if defined(_DARWIN_FEATURE_64_BIT_INODE) to # if ! defined(__DARWIN_64_BIT_INO_T) || __DARWIN_64_BIT_INO_T in your second patch.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #35 from Lawrence Velázquez --- Created attachment 33461 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33461&action=edit MacPorts log from a failed attempt to build libgcc @4.9.1_0 (x86_64) There’s a lot of text, I know. To see the environment and commands executed, search for "configure phase started" and "build phase started". As you might expect, the failure is near the end.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #36 from Lawrence Velázquez --- (In reply to Lawrence Velázquez from comment #34) > I got the build to succeed by changing > > # if defined(_DARWIN_FEATURE_64_BIT_INODE) > > to > > # if ! defined(__DARWIN_64_BIT_INO_T) || __DARWIN_64_BIT_INO_T > > in your second patch. Sorry, I might have gotten mixed up about precisely how I altered your patch. I'll do a couple of test builds and report back.
[Bug c/38354] Spurious error: initializer element is not computable at load time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38354 --- Comment #7 from joseph at codesourcery dot com --- On Mon, 8 Sep 2014, adam at consulting dot net.nz wrote: > 3. To demonstrate this, a GNU extension to C++ has no problem computing the > address of the function pointer at load time and storing it in a 32-bit > integer > array. Standard C++ allows static initializers that can only be computed at runtime; there's no such thing as an initializer being invalid for C++ because it's non-constant. Thus, it's not significant that this code is accepted for C++; quite likely the initializers get computed at runtime in the C++ case.
[Bug lto/63166] [5 Regression] ICE (LTO): ipa_intraprocedural_devirtualization, at ipa-prop.c:2611
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63166 --- Comment #3 from Jan Hubicka --- Here I get: Determining dynamic type for call: OBJ_TYPE_REF(_76;(struct Foobar_Out)&Foobar_LOG.D.2901->0) (&Foobar_LOG.D.2901, " ", 1); Starting walk at: _69 = MEM[(struct Foobar_Out *)&Foobar_LOG]._vptr.Foobar_Out; instance pointer: &Foobar_LOG.D.2901 Outer instance pointer: Foobar_LOG offset: 0 (bits) vtbl reference: MEM[(struct Foobar_Out *)&Foobar_LOG]._vptr.Foobar_Out Function call may change dynamic type:_35 = getName (_50(D), _33); Function call may change dynamic type:_33 = operator* (&caller_it); Function call may change dynamic type:_31 = atEnd (&caller_it); Function call may change dynamic type:getCallerIterator (_26); Function call may change dynamic type:_26 = OBJ_TYPE_REF(_24;(const struct ECell)_44->0) (_44); Function call may change dynamic type:D.2965 = OBJ_TYPE_REF(_21;(struct ECellList)_19->1) (_19, &D.2966); Function call may change dynamic type:_19 = getCellList (_49(D)); Function call may change dynamic type:p_cl_it_14 = OBJ_TYPE_REF(_12;(const struct ECellList)_9->0) (_9); Function call may change dynamic type:_9 = getCellList (_43(D)); Function call may change dynamic type:operator delete (p_cl_it_14); Checking vtbl store: MEM[(struct HashMapIterator *)p_cl_it_14]._vptr.HashMapIterator = &MEM[(void *)&_ZTV15HashMapIteratorI6EIdentP5ECell15DBHashFunctionsE + 16B]; base:MEM[(struct HashMapIterator *)p_cl_it_14] does not match instance:Foobar_LOG Unanalyzed store may change type. Function call may change dynamic type:OBJ_TYPE_REF(_16;(struct CellListIterator)p_cl_it_14->1) (p_cl_it_14); Function call may change dynamic type:_31 = atEnd (&caller_it); Function call may change dynamic type:OBJ_TYPE_REF(_76;(struct Foobar_Out)&Foobar_LOG.D.2901->0) (&Foobar_LOG.D.2901, " ", 1); Function call may change dynamic type:_35 = getName (_50(D), _33); Function call may change dynamic type:_33 = operator* (&caller_it); Targets of polymorphic call of type 0:struct Foobar_Out token 0 Contained in type:struct Foobar_Log at offset 0 This is a complete list. (base types included) Foobar_Log::put_to_buf/109 (no definition) Targets that are not likely: Foobar_Out::put_to_buf/108 (no definition) I seem to agree that the memory store may potentially be vtable store for the object in question. I need to check how the old code gets around it...
[Bug lto/63166] [5 Regression] ICE (LTO): ipa_intraprocedural_devirtualization, at ipa-prop.c:2611
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63166 --- Comment #4 from Jan Hubicka --- Aha, is_global_var test going wrong way. I am testing: Index: ipa-prop.c === --- ipa-prop.c (revision 215023) +++ ipa-prop.c (working copy) @@ -1537,8 +1537,8 @@ compute_known_type_jump_func (tree op, s call, current_function_decl) /* Even if the var seems to be in construction by inline call stack, we may work out the actual type by walking memory writes. */ - && (!is_global_var (base) - && detect_type_change (op, base, expected_type, call, jfunc, offset))) + && (is_global_var (base) + || detect_type_change (op, base, expected_type, call, jfunc, offset))) return; ipa_set_jf_known_type (jfunc, offset, TREE_TYPE (base),
[Bug c++/61825] [5 regression] g++.dg/cpp0x/static_assert9.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61825 --- Comment #6 from Jan Hubicka --- Hi, sorry for the delay, the problem is that I do not feel good about putting back the old code from fold-const, since it simply does not make sense. I need to dive into the C++ standard what it says about this particular case and how that corelate with our weak and visibility attributes. I will try to find time for that this week. Honza
[Bug c/38354] Spurious error: initializer element is not computable at load time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38354 --- Comment #8 from Adam Warner --- Joseph, you're correct: 4005fa: b8 c6 05 40 00 moveax,0x4005c6 4005ff: 89 05 cf 04 20 00 movDWORD PTR [rip+0x2004cf],eax # 600ad4 400605: b8 c6 05 40 00 moveax,0x4005c6 40060a: 89 05 c8 04 20 00 movDWORD PTR [rip+0x2004c8],eax # 600ad8 0x4005c6 is the address of the function which is loaded into the lookup table by a static initializer function at run time. This is identical to the workaround in C where a lookup table of 32-bit pointers has to be populated at run time. I agree it is not significant that the code is accepted for C++. I'm sorry about that. What I've done in the past is use Perl to generate printf statements to output the 32-bit addresses as an integer array. The generated array is then compiled into the binary. A command-line option performs a check that the integer addresses match the newly compiled function addresses. It usually takes one additional generation/compilation before they all match up. It is ridiculous this x86_64 workaround is required to map constants into memory at load time when the functions occupy (under the default code model) the same lower 31-bit address space as i386. The original issue from six years ago is that compilation fails with the error "initializer element is not computable at load time". These calculations are computable at load time so the error message is spurious. But from a C language perspective they might not be computable at load time. Thus I believe a compiler warning is more appropriate than an error. That's the path to finalising this bug report: 1. Can you confirm from a technical perspective that the error is spurious? If so the bug report is CONFIRMED. If there are in fact good technical reasons why the error is valid then please close the bug report as INVALID. 2. If the bug report is confirmed then please decide whether the project will turn the error message into a warning. If the project will not do this then please close the bug report as WONTFIX. This part is ultimately a political decision. Either way it would be nice to have a resolution.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #37 from Lawrence Velázquez --- Okay, what I said initially was correct. This was the specific change I made. https://gist.github.com/larryv/9b1cd34a34733c10f734
[Bug rtl-optimization/63210] New: ira does not select the best register compared with gcc 4.8 for ARM THUMB1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63210
Bug ID: 63210
Summary: ira does not select the best register compared with
gcc 4.8 for ARM THUMB1
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhenqiang.chen at arm dot com
Here is a case shown ira does not select the best register compared with gcc
4.8 for ARM Cortex-M0 with options:
-Os -mthumb -mcpu=cortex-m0
int foo1 (int c);
int foo2 (int c);
int test (int c)
{
return (foo1 (c) || foo2 (c));
}
Its rtl is like:
2: r115:SI=r0:SI
7: r0:SI=r115:SI
8: r0:SI=call [`foo1'] argc:0
9: r111:SI=r0:SI
4: r110:SI=0x1
10: pc={(r111:SI!=0)?L17:pc}
12: r0:SI=r115:SI
13: r0:SI=call [`foo2'] argc:0
14: r112:SI=r0:SI
16: {r110:SI=r112:SI!=0;clobber r118:SI;}
17: L17:
23: r0:SI=r110:SI
For gcc 4.8, r115 is assigned first, which gets "r4" since
Allocno a3r115 of GENERAL_REGS(9) has 4 avail. regs 4-7, ...
Then r110 is assigned to "r0". "r0:SI=r110:SI" can be optimized.
But for trunk/4.9, r110 is assigned first. r110 is conflict with r115 and the
confict cost of "r0" is high since "r0" is not in "avail. regs 4-7" for r115.
So r110 is not assigned with "r0".
[Bug rtl-optimization/63210] ira does not select the best register compared with gcc 4.8 for ARM THUMB1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63210
--- Comment #1 from Zhenqiang Chen ---
Here is a workaround patch to show the point.
diff --git a/gcc/ira-color.c b/gcc/ira-color.c
index e2ea359..1573fb5 100644
--- a/gcc/ira-color.c
+++ b/gcc/ira-color.c
@@ -1709,6 +1709,8 @@ assign_hard_reg (ira_allocno_t a, bool retry_p)
{
ira_allocno_t conflict_a = OBJECT_ALLOCNO (conflict_obj);
enum reg_class conflict_aclass;
+ HARD_REG_SET prof_regs;
+ prof_regs = ALLOCNO_COLOR_DATA (conflict_a)->profitable_hard_regs;
/* Reload can give another class so we need to check all
allocnos. */
@@ -1780,7 +1782,7 @@ assign_hard_reg (ira_allocno_t a, bool retry_p)
hard_regno = ira_class_hard_regs[aclass][j];
ira_assert (hard_regno >= 0);
k = ira_class_hard_reg_index[conflict_aclass][hard_regno];
-if (k < 0)
+if (k < 0 || !TEST_HARD_REG_BIT (prof_regs, hard_regno))
continue;
full_costs[j] -= conflict_costs[k];
}
For this case, "r0" is not available for r115. The conflict for r110 on "r0"
maybe meaningless.
