[Bug c/63235] building fails with --disable-bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63235 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- Maybe this is why bootstrap is even more important :).
[Bug c/63224] False Positive for -Wmaybe-uninitialized at -Os, not -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63224
--- Comment #7 from Sebastian Huber sebastian.hu...@embedded-brains.de ---
I reduced the test case using the delta tool to:
void foo(void);
void bar(int s, int *a)
{
int i;
int c;
for (i = 0; s != 0 (c = a[i]); ++i) {
}
if (s == 2 c == 0) {
} else if (s != 0) {
foo();
}
}
cp test.c Os.c
cp test.c O2.c
arm-rtems4.11-gcc -Wfatal-errors -Wall -Os -S Os.c -o Os.s
-fdump-tree-all-all-lineno
Os.c: In function 'bar':
Os.c:11:25: warning: 'c' may be used uninitialized in this function
[-Wmaybe-uninitialized]
if (s == 2 c == 0) {
^
arm-rtems4.11-gcc -Wfatal-errors -Wall -O2 -S O2.c -o O2.s
-fdump-tree-all-all-lineno
diff -u O*c*uni*
--- O2.c.140t.uninit1 2014-09-12 09:20:47.983177990 +0200
+++ Os.c.140t.uninit1 2014-09-12 09:20:47.909178064 +0200
@@ -5,73 +5,138 @@
Pass statistics:
+[WORKLIST]: add to initial list: c_2 = PHI c_5(D)(2), c_12(8)
+[CHECK]: examining phi: c_2 = PHI c_5(D)(2), c_12(8)
+
+[CHECK] Found def edge 1 in c_2 = PHI c_5(D)(2), c_12(8)
+[CHECK]: Found unguarded use: c_3 = PHI c_2(9), 0(10)
+[WORKLIST]: Update worklist with phi: c_3 = PHI c_2(9), 0(10)
+[CHECK]: examining phi: c_3 = PHI c_2(9), 0(10)
+[CHECK]: Found unguarded use: _15 = c_3 == 0;
Pass statistics:
bar (intD.3 sD.4075, intD.3 * aD.4076)
{
- unsigned int ivtmp.12D.4111;
+ unsigned int ivtmp.10D.4109;
intD.3 cD.4080;
intD.3 iD.4079;
+ _BoolD.1375 _14;
+ _BoolD.1375 _15;
+ _BoolD.1375 _16;
+ _BoolD.1375 _21;
+ intD.3 * _23;
+ voidD.63 * _24;
;; basic block 2, loop depth 0, count 0, freq 880, maybe hot
-;;prev block 0, next block 6, flags: (NEW, REACHABLE)
+;;prev block 0, next block 3, flags: (NEW, REACHABLE)
;;pred: ENTRY [100.0%] (FALLTHRU,EXECUTABLE)
-;; starting at line 8
- [O2.c : 8:9] if (s_6(D) != 0)
-goto bb 3;
+;; starting at line -1
+ _23 = a_9(D) + 4294967292;
+ # RANGE [0, 4294967295]
+ ivtmp.10_22 = (unsigned int) _23;
+;;succ: 3 [100.0%] (FALLTHRU,EXECUTABLE)
+
+;; basic block 3, loop depth 1, count 0, freq 1, maybe hot
+;;prev block 2, next block 4, flags: (NEW, REACHABLE)
+;;pred: 2 [100.0%] (FALLTHRU,EXECUTABLE)
+;;8 [100.0%] (FALLTHRU,DFS_BACK)
+;; starting at line 8, discriminator 1
+ # RANGE ~[0, 0]
+ # c_2 = PHI c_5(D)(2), c_12(8)
+ # ivtmp.10_19 = PHI ivtmp.10_22(2), ivtmp.10_18(8)
+ [Os.c : 8:9] if (s_6(D) != 0)
+goto bb 4;
else
-goto bb 6;
-;;succ: 3 [95.5%] (TRUE_VALUE,EXECUTABLE)
-;;6 [4.5%] (FALSE_VALUE,EXECUTABLE)
-
-;; basic block 6, loop depth 0, count 0, freq 40, maybe hot
-;;prev block 2, next block 3, flags: (NEW)
-;;pred: 2 [4.5%] (FALSE_VALUE,EXECUTABLE)
+goto bb 9;
+;;succ: 4 [95.5%] (TRUE_VALUE,EXECUTABLE)
+;;9 [4.5%] (FALSE_VALUE,EXECUTABLE)
+
+;; basic block 4, loop depth 1, count 0, freq 9550, maybe hot
+;;prev block 3, next block 10, flags: (NEW, REACHABLE)
+;;pred: 3 [95.5%] (TRUE_VALUE,EXECUTABLE)
+;; starting at line -1, discriminator 3
+ # RANGE [0, 4294967295]
+ ivtmp.10_18 = ivtmp.10_19 + 4;
+ # PT = nonlocal
+ _24 = (voidD.63 *) ivtmp.10_18;
+ [Os.c : 8:34] # VUSE .MEM_11(D)
+ c_12 = MEM[base: _24, offset: 0B];
+ [Os.c : 8:28] if (c_12 != 0)
+goto bb 8;
+ else
+goto bb 10;
+;;succ: 8 [95.5%] (TRUE_VALUE,EXECUTABLE)
+;;10 [4.5%] (FALSE_VALUE,EXECUTABLE)
+
+;; basic block 10, loop depth 0, count 0, freq 430, maybe hot
+;;prev block 4, next block 8, flags: (NEW)
+;;pred: 4 [4.5%] (FALSE_VALUE,EXECUTABLE)
;;
goto bb 5;
;;succ: 5 [100.0%] (FALLTHRU)
-;; basic block 3, loop depth 0, count 0, freq 430, maybe hot
-;; Invalid sum of incoming frequencies 840, should be 430
-;;prev block 6, next block 7, flags: (NEW, REACHABLE)
-;;pred: 2 [95.5%] (TRUE_VALUE,EXECUTABLE)
-;; starting at line 11
- [O2.c : 11:12] if (s_6(D) == 2)
-goto bb 7;
- else
-goto bb 4;
-;;succ: 7 [79.8%] (TRUE_VALUE,EXECUTABLE)
-;;4 [20.2%] (FALSE_VALUE,EXECUTABLE)
+;; basic block 8, loop depth 1, count 0, freq 9120, maybe hot
+;;prev block 10, next block 9, flags: (NEW)
+;;pred: 4 [95.5%] (TRUE_VALUE,EXECUTABLE)
+;;
+ goto bb 3;
+;;succ: 3 [100.0%] (FALLTHRU,DFS_BACK)
-;; basic block 7, loop depth 0, count 0, freq 343, maybe hot
-;;prev block 3, next block 4, flags: (NEW)
-;;pred: 3 [79.8%] (TRUE_VALUE,EXECUTABLE)
+;; basic block 9, loop depth 0, count 0, freq 450, maybe hot
+;;prev block 8, next block 5, flags: (NEW)
+;;pred: 3 [4.5%] (FALSE_VALUE,EXECUTABLE)
;;
- goto bb 5;
;;succ: 5 [100.0%] (FALLTHRU)
-;; basic block 4, loop depth 0, count 0, freq 209, maybe hot
-;; Invalid sum of
[Bug middle-end/63237] New: [5 Regression] error: invalid operand in unary operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63237
Bug ID: 63237
Summary: [5 Regression] error: invalid operand in unary
operation
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
markus@x4 llvm_build % RewriteMacros.ii
extern C unsigned long strlen(const char *);
class A {
int Length;
public:
A(const char *p1) { Length = strlen(p1); }
};
class B {
public:
void m_fn1(int, A);
};
class C {
public:
B m_fn2();
};
int a;
void RewriteMacrosInInput() {
C b;
B c = b.m_fn2();
c.m_fn1(0, [a]);
}
markus@x4 llvm_build % g++ -c -O2 RewriteMacros.ii
RewriteMacros.ii: In function ‘void RewriteMacrosInInput()’:
RewriteMacros.ii:21:1: error: invalid operand in unary operation
}
^
RewriteMacros.ii:21:1: error: invalid operand to unary operator
(ssizetype) a.0_6
RewriteMacros.ii:6:41: note: in statement
A(const char *p1) { Length = strlen(p1); }
^
_14 = (long unsigned int) -(ssizetype) a.0_6;
RewriteMacros.ii:21:1: internal compiler error: verify_gimple failed
}
^
0xc04b7a verify_gimple_in_cfg(function*, bool)
../../gcc/gcc/tree-cfg.c:5003
0xb12cd2 execute_function_todo
../../gcc/gcc/passes.c:1751
0xb136e3 execute_todo
../../gcc/gcc/passes.c:1808
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug c/63224] False Positive for -Wmaybe-uninitialized at -Os, not -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63224
--- Comment #8 from Sebastian Huber sebastian.hu...@embedded-brains.de ---
Actually the for loop is not necessary.
int bar(int s, int *a)
{
int c;
int r;
r = s != 0 (c = a[s]);
if (s == 2 c == 0) {
} else if (s != 0) {
return 0;
}
return r;
}
cp test.c Os.c
cp test.c O2.c
arm-rtems4.11-gcc -Wfatal-errors -Wall -Os -S Os.c -o Os.s
-fdump-tree-all-all-lineno
Os.c: In function 'bar':
Os.c:8:18: warning: 'c' may be used uninitialized in this function
[-Wmaybe-uninitialized]
if (s == 2 c == 0) {
^
arm-rtems4.11-gcc -Wfatal-errors -Wall -O2 -S O2.c -o O2.s
-fdump-tree-all-all-lineno
diff -u O*c*uni*
--- O2.c.140t.uninit1 2014-09-12 09:29:10.627991057 +0200
+++ Os.c.140t.uninit1 2014-09-12 09:29:10.574991191 +0200
@@ -5,6 +5,9 @@
Pass statistics:
+[WORKLIST]: add to initial list: c_1 = PHI c_5(D)(7), c_11(3)
+[CHECK]: examining phi: c_1 = PHI c_5(D)(7), c_11(3)
+[CHECK]: Found unguarded use: _13 = c_1 == 0;
Pass statistics:
@@ -13,13 +16,97 @@
{
intD.3 rD.4078;
intD.3 cD.4077;
+ intD.3 _3;
+ unsigned intD.6 s.1_6;
+ unsigned intD.6 _7;
+ intD.3 * _9;
+ _BoolD.1375 _12;
+ _BoolD.1375 _13;
+ _BoolD.1375 _14;
+ _BoolD.1375 _16;
+ _BoolD.1375 _18;
;; basic block 2, loop depth 0, count 0, freq 1, maybe hot
-;;prev block 0, next block 1, flags: (NEW, REACHABLE)
+;;prev block 0, next block 7, flags: (NEW, REACHABLE)
;;pred: ENTRY [100.0%] (FALLTHRU,EXECUTABLE)
+;; starting at line 6
+ [Os.c : 6:13] if (s_4(D) != 0)
+goto bb 3;
+ else
+goto bb 7;
+;;succ: 3 [50.0%] (TRUE_VALUE,EXECUTABLE)
+;;7 [50.0%] (FALSE_VALUE,EXECUTABLE)
+
+;; basic block 7, loop depth 0, count 0, freq 5000, maybe hot
+;;prev block 2, next block 3, flags: (NEW)
+;;pred: 2 [50.0%] (FALSE_VALUE,EXECUTABLE)
+;;
+ goto bb 4;
+;;succ: 4 [100.0%] (FALLTHRU)
+
+;; basic block 3, loop depth 0, count 0, freq 5000, maybe hot
+;;prev block 7, next block 4, flags: (NEW, REACHABLE)
+;;pred: 2 [50.0%] (TRUE_VALUE,EXECUTABLE)
+;; starting at line 6, discriminator 1
+ [Os.c : 6:22] # RANGE [1, 4294967295]
+ s.1_6 = (unsigned intD.6) s_4(D);
+ [Os.c : 6:22] # RANGE [0, 4294967295] NONZERO 0x0fffc
+ _7 = s.1_6 * 4;
+ [Os.c : 6:22] # PT = nonlocal
+ _9 = a_8(D) + _7;
+ [Os.c : 6:19] # VUSE .MEM_10(D)
+ c_11 = [Os.c : 6] *_9;
+ [Os.c : 6:13] # RANGE [0, 1]
+ _16 = c_11 != 0;
+ [Os.c : 6:13] # RANGE [0, 1] NONZERO 0x1
+ r_19 = (intD.3) _16;
+;;succ: 4 [100.0%] (FALLTHRU,EXECUTABLE)
+
+;; basic block 4, loop depth 0, count 0, freq 1, maybe hot
+;;prev block 3, next block 8, flags: (NEW, REACHABLE)
+;;pred: 7 [100.0%] (FALLTHRU)
+;;3 [100.0%] (FALLTHRU,EXECUTABLE)
+;; starting at line 8, discriminator 6
+ # c_1 = PHI c_5(D)(7), c_11(3)
+ # RANGE [0, 1] NONZERO 0x1
+ # r_2 = PHI [Os.c : 6:13] 0(7), [Os.c : 6:13] r_19(3)
+ [Os.c : 8:8] # RANGE [0, 1]
+ _12 = s_4(D) == 2;
+ [Os.c : 8:18] # RANGE [0, 1]
+ _13 = c_1 == 0;
+ [Os.c : 8:13] # RANGE [0, 1]
+ _14 = _13 _12;
+ [Os.c : 9:12] # RANGE [0, 1]
+ _18 = s_4(D) != 0;
+ [Os.c : 9:12] if (_14 _18)
+goto bb 5;
+ else
+goto bb 8;
+;;succ: 5 [39.0%] (TRUE_VALUE,EXECUTABLE)
+;;8 [61.0%] (FALSE_VALUE,EXECUTABLE)
+
+;; basic block 8, loop depth 0, count 0, freq 6100, maybe hot
+;;prev block 4, next block 5, flags: (NEW)
+;;pred: 4 [61.0%] (FALSE_VALUE,EXECUTABLE)
+;;
+ goto bb 6;
+;;succ: 6 [100.0%] (FALLTHRU)
+
+;; basic block 5, loop depth 0, count 0, freq 3900, maybe hot
+;;prev block 8, next block 6, flags: (NEW)
+;;pred: 4 [39.0%] (TRUE_VALUE,EXECUTABLE)
+;;
+;;succ: 6 [100.0%] (FALLTHRU,EXECUTABLE)
+
+;; basic block 6, loop depth 0, count 0, freq 1, maybe hot
+;;prev block 5, next block 1, flags: (NEW, REACHABLE)
+;;pred: 5 [100.0%] (FALLTHRU,EXECUTABLE)
+;;8 [100.0%] (FALLTHRU)
;; starting at line -1
+ # RANGE [0, 1] NONZERO 0x1
+ # _3 = PHI [Os.c : 10:3] 0(5), [Os.c : 13:2] r_2(8)
# VUSE .MEM_10(D)
- return 0;
+ return _3;
;;succ: EXIT [100.0%]
}
[Bug middle-end/63237] [5 Regression] error: invalid operand in unary operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63237 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-12 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug middle-end/63237] [5 Regression] error: invalid operand in unary operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63237 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug pch/63229] [5.0 Regression] FAIL: ./except-1.h -O0 (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63229 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug middle-end/63220] error: inlining failed in call to always_inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63220
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to davidxl from comment #2)
(In reply to Richard Biener from comment #1)
First of all you should mark the functions 'inline' as well.
This does not help.
Then the issue
is that 'eq' is called indirectly which isn't allowed for always_inline
functions:
Is this documented somewhere? A function can be called indirectly and
directly. What is the right way to force inlining the direct calls?
A warning is already emitted about always_inline might not be inlinable, why
the error?
@item always_inline
@cindex @code{always_inline} function attribute
Generally, functions are not inlined unless optimization is specified.
For functions declared inline, this attribute inlines the function
independent of any restrictions that otherwise apply to inlining.
Failure to inline such a function is diagnosed as an error.
Note that if such a function is called indirectly the compiler may
or may not inline it depending on optimization level and a failure
to inline an indirect call may or may not be diagnosed.
always_inline is _not_ an optimization hint! always_inline was meant
to mark functions that won't work correctly if not inlined.
There is no way to force only inlining of direct calls.
t.C:81:66: error: inlining failed in call to always_inline 'static constexpr
bool std::__1::char_traitschar::eq(std::__1::char_traitschar::char_type,
std::__1::char_traitschar::char_type)': indirect function call with a yet
undetermined callee
__attribute__ (( __always_inline__)) static constexpr bool
eq(char_type __c1, char_type __c2) {
^
t.C:75:37: error: called from here
if (!__pred(*__m1, *__m2)) { }
^
which means this is a missed-optimization only. The error is your fault.
Note that getting the error is unreliable so -O0 simply doesn't discover the
failed inlining.
-O2 works fine -- I have not debugged the problem -- but it seems to be some
newly cloned cgraph edge to be in inconsistent state.
David
[Bug go/63172] gccgo testcase cplx2.go execution provides incorrect answers on trunk for powerpc64, powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63172 --- Comment #4 from Dominik Vogt vogt at linux dot vnet.ibm.com --- On s390x, the option -fcx-limited-range fixes the deviation in the C test program (tried with -O0 and -O3), but it has no effect for the Go test program.
[Bug debug/56974] c++ ref qualifiers not represented in DWARF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56974 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-12 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug debug/63238] New: DWARF does not represent _Alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63238 Bug ID: 63238 Summary: DWARF does not represent _Alignas Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: mpolacek at gcc dot gnu.org C11 has the _Alignas specifier, but it isn't emitted in DWARF. The proposal is here: https://www.mail-archive.com/dwarf-discuss@lists.dwarfstd.org/msg00159.html
[Bug tree-optimization/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631 --- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org --- I think that's easiest for Eric to say. Not really, I guess you want to debug the function and replay the computation since the cost is synthetized and doesn't come directly from the back-end. I've found what's going on: * In expmed.c (init_expmed_one_mode), l.194 set_shiftadd_cost (speed, mode, m, set_src_cost (all-shift_add, speed)); with all-shift_add something like (plus:QI (mult:QI (reg:QI 109 [0]) (const_int 8 [0x8])) (reg:QI 109 [0])) * For the mult part, rtx_code calls sparc_rtx_cost, which has case MULT: if (float_mode_p) *total = sparc_costs-float_mul; else if (! TARGET_HARD_MUL) *total = COSTS_N_INSNS (25); On SPARCv9/-m64, TARGET_HARD_MUL is false, so we get the 25*4 = 100 part, unlike v8, which explains why the test only fails for 64-bit. Rainer
[Bug debug/63239] New: DWARF does not represent C++ deleted methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63239
Bug ID: 63239
Summary: DWARF does not represent C++ deleted methods
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
C++11 has implicitly deleted functions. These are declared with the = delete
specifier, and their usage in the program is forbidden.
struct A
{
int i;
A() = delete;
};
A a = { 42 };
However, it seems that currently the deleted functions are emitted like any
other.
[Bug middle-end/63237] [5 Regression] error: invalid operand in unary operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63237 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Sep 12 11:06:49 2014 New Revision: 215212 URL: https://gcc.gnu.org/viewcvs?rev=215212root=gccview=rev Log: 2014-09-12 Richard Biener rguent...@suse.de PR middle-end/63237 * gimple-fold.c (get_maxval_strlen): Gimplify string length. * g++.dg/torture/pr63237.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr63237.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/63237] [5 Regression] error: invalid operand in unary operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63237 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug debug/63240] New: DWARF does not represent C++ defaulted methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63240
Bug ID: 63240
Summary: DWARF does not represent C++ defaulted methods
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Similarly to PR63239, DWARF does not seem to represent C++ defaulted methods.
struct A
{
int i;
A() = default;
};
Not sure whether that is really an issue, might be just an implementation
detail.
[Bug debug/16063] Debuggers need more information about enum types in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16063 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #9 from Marek Polacek mpolacek at gcc dot gnu.org --- So, is this fixed?
[Bug libstdc++/59603] std::random_shuffle tries to swap element with itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59603 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Jörg Richter from comment #2) Seems like we have hit this bug too. It happens not only in debug mode. We have a testcase that triggers valgrind errors in non-debug mode while calling random_shuffle. I can try to reduce this testcase if it would help. Would you be able to provide such a test? self-move in non-debug mode should not cause valgrind errors, it should just cause the vector to be left empty (so the valgrind errors might come later if you assume the vector still contains data and try to access it).
[Bug debug/16063] Debuggers need more information about enum types in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16063 Mark Wielaard mark at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Mark Wielaard mark at gcc dot gnu.org --- (In reply to Marek Polacek from comment #9) So, is this fixed? Yes, I do believe so, in gcc trunk. Sorry for not closing earlier.
[Bug c++/63241] New: Internal error in gimplify_init_constructor when using constexr and multidimensional arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63241
Bug ID: 63241
Summary: Internal error in gimplify_init_constructor when using
constexr and multidimensional arrays
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thibaut.lutz at googlemail dot com
I stumbled upon a weird regression bug. The test case below is working fine
with GCC 4.8 and 4.9.0 but triggers an internal error on 4.9.1. I haven't
tested 4.9.2.
Any of these modifications would remove the error:
- removing `constexpr` from the constructor at line 2
- using `0` instead of `i` in the second array element constructor at line 8
- using `const int i` instead of `int i` at line 6
- using a 1D array instead of a 2D array at line 7
So I believe the example below cannot be reduced further.
However somehow the combination of `constexpr` constructor and multidimensional
array is causing the compiler to crash.
Details:
* GCC version: 4.9.1 built with default config
* System: x86_64 GNU/Linux
* Command line: c++ -std=c++11 bug.cpp
* Minimal example:
struct A {
constexpr A(int){}
};
int main() {
int i = 1;
A array[2][2] =
{{{0}, {i}},
{{0}, {0}}};
}
* Output:
bug.cpp: In function ‘int main()’:
bug.cpp:9:16: internal compiler error: in gimplify_init_constructor, at
gimplify.c:4007
{{0}, {0}}};
^
0x7f6213 gimplify_init_constructor
../.././gcc/gimplify.c:4007
0x7f6dee gimplify_modify_expr_rhs
../.././gcc/gimplify.c:4167
0x7f6ec4 gimplify_modify_expr
../.././gcc/gimplify.c:4486
0x7f7dda gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../.././gcc/gimplify.c:7627
0x7facd6 gimplify_stmt(tree_node**, gimple_statement_base**)
../.././gcc/gimplify.c:5373
0x7f806a gimplify_cleanup_point_expr
../.././gcc/gimplify.c:5149
0x7f806a gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../.././gcc/gimplify.c:7990
0x7facd6 gimplify_stmt(tree_node**, gimple_statement_base**)
../.././gcc/gimplify.c:5373
0x7f8d3b gimplify_statement_list
../.././gcc/gimplify.c:1432
0x7f8d3b gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../.././gcc/gimplify.c:8042
0x7facd6 gimplify_stmt(tree_node**, gimple_statement_base**)
../.././gcc/gimplify.c:5373
0x7f806a gimplify_cleanup_point_expr
../.././gcc/gimplify.c:5149
0x7f806a gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../.././gcc/gimplify.c:7990
0x7facd6 gimplify_stmt(tree_node**, gimple_statement_base**)
../.././gcc/gimplify.c:5373
0x7f8d3b gimplify_statement_list
../.././gcc/gimplify.c:1432
0x7f8d3b gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../.././gcc/gimplify.c:8042
0x7facd6 gimplify_stmt(tree_node**, gimple_statement_base**)
../.././gcc/gimplify.c:5373
0x7fb56b gimplify_bind_expr
../.././gcc/gimplify.c:1099
0x7f7fc0 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../.././gcc/gimplify.c:7824
0x7facd6 gimplify_stmt(tree_node**, gimple_statement_base**)
../.././gcc/gimplify.c:5373
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Component|tree-optimization |target Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #10 from Eric Botcazou ebotcazou at gcc dot gnu.org --- * For the mult part, rtx_code calls sparc_rtx_cost, which has case MULT: if (float_mode_p) *total = sparc_costs-float_mul; else if (! TARGET_HARD_MUL) *total = COSTS_N_INSNS (25); On SPARCv9/-m64, TARGET_HARD_MUL is false, so we get the 25*4 = 100 part, unlike v8, which explains why the test only fails for 64-bit. Ugh, thanks for spotting it, this looks like an annoying oversight.
[Bug lto/63242] New: memory starvation caused by flatten attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63242 Bug ID: 63242 Summary: memory starvation caused by flatten attribute Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: wbrana at gmail dot com forwarded from https://bugs.freedesktop.org/show_bug.cgi?id=77580 Hello, I've been testing GCC 4.9 for a virtual gentoo machine and I noticed that you us flatten attribute in source code. In case of src/sna/sna_glyphs.c flatten functions, inliner inlines about 3.3M functions and crashes because of no free memory (I have 8GB memory). Please notice that LTO has ability to optimize whole program. As a result, it sees almost all function bodies and that leads to enormous inlining. Suggested patch removes these flatten attributes for selected functions. Thank you, MArtin
[Bug libstdc++/59603] std::random_shuffle tries to swap element with itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59603 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Fri Sep 12 13:30:35 2014 New Revision: 215219 URL: https://gcc.gnu.org/viewcvs?rev=215219root=gccview=rev Log: PR libstdc++/59603 * include/bits/stl_algo.h (random_shuffle): Prevent self-swapping. * testsuite/25_algorithms/random_shuffle/59603.cc: New. Added: trunk/libstdc++-v3/testsuite/25_algorithms/random_shuffle/59603.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_algo.h
[Bug libstdc++/59603] std::random_shuffle tries to swap element with itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59603 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed on trunk so far.
[Bug debug/63243] New: [meta-bug] RH GDB project tracker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63243 Bug ID: 63243 Summary: [meta-bug] RH GDB project tracker Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: mpolacek at gcc dot gnu.org This bug tracks various GCC bugs that are blocking or hindering GDB progress.
[Bug middle-end/63224] false positive for -Wmaybe-uninitialized at -Os (not -O2) with transformed to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63224 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-12 Component|c |middle-end Blocks||24639 Summary|False Positive for |false positive for |-Wmaybe-uninitialized at|-Wmaybe-uninitialized at |-Os, not -O2|-Os (not -O2) with ||transformed to Ever confirmed|0 |1 --- Comment #9 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #6) I think this is PR56574, but we need to check the dumps to be sure. The dump should be something like: test.c.NNNt.uninit1, you can get it with -fdump-tree-all-all-lineno. According to this: + [Os.c : 8:8] # RANGE [0, 1] + _12 = s_4(D) == 2; + [Os.c : 8:18] # RANGE [0, 1] + _13 = c_1 == 0; + [Os.c : 8:13] # RANGE [0, 1] + _14 = _13 _12; the same bug is involved, but this one is a bit more complicated because it is not clear that the uninit pass realizes that the c_5(D)(7) edge is guarded by s==0, so in that case _12==0 and c_1 doesn't matter.
[Bug tree-optimization/56654] uninit warning behaves erratically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56654 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-12 Ever confirmed|0 |1 --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Anyway, it is at least one bug, perhaps more.
[Bug c++/59500] Bogus maybe-uninitialized warning due to optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59500 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Could you remove the stdbool.h header (just use char or int, it should not change the bug)? Also could you compile with -fdump-tree-all-all-lineno and paste/attach the dump file that looks similar to test.c.XXXt.uninitX? It should show clearly whether it is a duplicate or a different issue.
[Bug middle-end/57832] compiling sha-256 code (xz 5.0.5) generates false warnings when using -march=native on Atom CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57832 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Olivier Langlois from comment #1) Created attachment 30466 [details] original c file very macro heavy loop unrolling sha-256 code hand optimized code (I have peaked into the resulting intermediate code, yuck!) but the code seems ok: If you want someone to look at this code, you need to reduce it further: https://gcc.gnu.org/bugs/minimize.html You can also check what the uninit pass is doing by using -fdump-tree-all-all-lineno, which will create a test.c.XXXt,uninitX file.
[Bug debug/63239] DWARF does not represent C++ deleted methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63239 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||dodji at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Perhaps we need some DWARF extension for this?
[Bug middle-end/62084] [avr] ICE: in convert_debug_memory_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62084 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Keywords||addr-space, ||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-12 CC||law at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org --- CC'ing Jeff as he also fixed PR52472... ICE with Jörg's code for 4.9.2and 5.0 (from 2014-09-12 SVN 215212)
[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 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Fri Sep 12 14:39:25 2014 New Revision: 215226 URL: https://gcc.gnu.org/viewcvs?rev=215226root=gccview=rev Log: PR c++/63201 * decl.c (start_decl): Handle specialization of member variable template. * pt.c (check_explicit_specialization): Adjust error. Added: trunk/gcc/testsuite/g++.dg/cpp1y/var-templ11.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/g++.old-deja/g++.robertl/eb103.C
[Bug lto/63226] ICE with -flto-odr-type-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63226
--- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org ---
Created attachment 33478
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33478action=edit
Second test file pair (1/2): one37.ii
namespace std {
templatetypename _Arg, typename _Result struct unary_function
{
};
}
namespace mpl_ {
}
namespace mpl_ {
template bool C_ struct bool_ {
};
template typename T, T N struct integral_c;
}
namespace boost {
namespace mpl {
using ::mpl_::integral_c;
}
}
namespace mpl_ {
template typename T, T N struct integral_c {
static const T value = N;
};
}
namespace boost{
template class T, T val struct integral_constant : public
mpl::integral_cT, val {
};
namespace detail {
template typename T struct cv_traits_imp {
typedef T unqualified_type;
};
};
template typename T struct is_void :
::boost::integral_constantbool,false {
};
template typename T struct is_integral :
::boost::integral_constantbool,false {
};
namespace type_traits {
template typename T struct is_mem_fun_pointer_impl {
static const bool value = false;
};
}
template typename T struct remove_cv {
typedef typename boost::detail::cv_traits_impT*::unqualified_type type;
};
template typename T struct is_member_function_pointer :
::boost::integral_constantbool,::boost::type_traits::is_mem_fun_pointer_impltypename
remove_cvT::type::value {
};
template typename T struct is_member_pointer :
::boost::integral_constantbool,::boost::is_member_function_pointerT::value
{
};
namespace type_traits {
template bool b1, bool b2, bool b3 = true, bool b4 = true, bool b5 =
true, bool b6 = true, bool b7 = true struct ice_and;
template bool b1, bool b2, bool b3, bool b4, bool b5, bool b6, bool b7
struct ice_and {
static const bool value = false;
};
template bool b struct ice_not {
static const bool value = true;
};
}
namespace detail {
template typename T struct is_pointer_helper {
static const bool value = false;
};
template typename T struct is_pointer_impl {
static const bool value = (::boost::type_traits::ice_and
::boost::detail::is_pointer_helpertypename remove_cvT::type::value ,
::boost::type_traits::ice_not ::boost::is_member_pointerT::value ::value
::value) ;
};
}
template typename T struct is_pointer :
::boost::integral_constantbool,::boost::detail::is_pointer_implT::value {
};
namespace mpl {
template bool C , typename T1 , typename T2 struct
if_c {
};
template typename T1 , typename T2 struct
if_cfalse,T1,T2 {
typedef T2 type;
};
}
template bool B, class T = void struct enable_if_c {
typedef T type;
};
templatetypename Signature class function;
namespace detail {
namespace function {
union function_buffer { mutable void (*func_ptr)();
};
struct function_ptr_tag { };
templatetypename F class get_function_tag {
typedef typename mpl::if_c(is_pointerF::value),
function_ptr_tag,
function_ptr_tag::type ptr_or_obj_tag; public: typedef
ptr_or_obj_tag type; };
templatetypename Functor struct functor_manager {
public: static inline void manage(const function_buffer
in_buffer, function_buffer out_buffer) { } };
struct vtable_base { void (*manager)(const
function_buffer in_buffer, function_buffer
out_buffer); };
}
}
class function_base {
};
namespace detail {
namespace function {
template typename FunctionObj, typename R ,
typename T0 struct function_obj_invoker1 { static
R invoke(function_buffer function_obj_ptr , T0 a0)
{ } };
template typename FunctionObj, typename R ,
typename T0 struct void_function_obj_invoker1 { };
template typename FunctionObj, typename R ,
typename T0 struct get_function_obj_invoker1 {
typedef typename mpl::if_c(is_voidR::value),
void_function_obj_invoker1 FunctionObj,
R , T0
,
[Bug lto/63226] ICE with -flto-odr-type-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63226 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org --- Created attachment 33479 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33479action=edit Second test file pair (1/2): two22.ii
[Bug middle-end/61848] [5 Regression] a previous declaration causes the section attribute to be lost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848 Alan Modra amodra at gmail dot com changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #10 from Alan Modra amodra at gmail dot com --- Created attachment 33480 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33480action=edit A different approach to fixing this bug I was playing with this one today, before I found your bugzilla Andrew. It has been regression tested on x86_64, fixes the loss of section attributes, and builds a 3.16 x86_64 defconfig kernel - haven't checked if it boots yet.. Adds a fix for C++ which has the same problem as C. (The s/olddecl/newdecl/ lines are because if (TREE_CODE (newdecl) == FUNCTION_DECL) ... else switch (TREE_CODE (olddecl)) looks horrible. Cosmetic really since we exit the function before this code if TREE_CODE (newdecl) != TREE_CODE (olddecl).)
[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 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC|jason at redhat dot com|jason at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|--- |5.0 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
[Bug lto/63226] ICE with -flto-odr-type-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63226 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #5) Created attachment 33478 [details] Second test file pair (1/2): one37.ii Mixed up the fields ... That should have been the attachment - and the attachment should have been the comment. Still, if you take the code of comment 5 together with attachment 33479, one can still reproduce it. Here what I actually wanted to write (and is in the attachment): (In reply to Jan Hubicka from comment #4) this is patch I am testing. It fixes few issues in the ODR comparsions code and seems to handle this testcase sanely. Thanks. Works for the two files (also for the two files of the big program). However, the big program (as a whole) still fails with the ICE: internal compiler error: in odr_types_equivalent_p, at ipa-devirt.c:1125 g++ -O0 -w -c -std=c++11 -flto one37.ii two22.ii; g++ -flto one37.o two22.o
[Bug lto/63242] memory starvation caused by flatten attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63242 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-09-12 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- It would nice if you attach a testcase which uses large amount of memory.
[Bug lto/63242] memory starvation caused by flatten attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63242 --- Comment #2 from wbrana wbrana at gmail dot com --- How I can create such testcase? I can reproduce it on Gentoo by adding -flto to /etc/portage/make.conf and running: emerge xf86-video-intel but can't reproduce from command-line gcc -std=gnu99 -O3 -shared -fPIC -flto sna_glyphs.i -o test.so
[Bug rtl-optimization/62265] [4.8/4.9/5 regression] FAIL: gcc.dg/20111227-2.c scan-rtl-dump ree Elimination opportunities = 3 realized = 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62265 Teresa Johnson tejohnson at google dot com changed: What|Removed |Added CC||tejohnson at google dot com --- Comment #3 from Teresa Johnson tejohnson at google dot com --- I believe this was fixed by the following commit: r214848 | uros | 2014-09-03 00:58:17 -0700 (Wed, 03 Sep 2014) | 4 lines Changed paths: M /trunk/gcc/testsuite/ChangeLog M /trunk/gcc/testsuite/gcc.dg/20111227-2.c M /trunk/gcc/testsuite/gcc.dg/20111227-3.c * gcc.dg/20111227-2.c: Compile only for x86 targets. * gcc.dg/20111227-3.c: Ditto.
[Bug debug/63243] [meta-bug] RH GDB project tracker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63243 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-12 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Confirmed so it doesn't show up in the list of unconfirmed bugs.
[Bug fortran/63205] [OOP] Wrongly rejects type = class (for identical declared type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63205 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-12 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- I see two issues with the test assign_11.f90: (1) an ICE, reduced test program test implicit none type t integer :: ii end type t type(t) :: y(3) y = func2() contains function func2() result(res) class(t), allocatable :: res(:) end function func2 end program test [Book15] f90/bug% gfc49 pr63205_red.f90 pr63205_red.f90: In function 'test': pr63205_red.f90:8:0: internal compiler error: in gfc_trans_arrayfunc_assign, at fortran/trans-expr.c:7369 y = func2() ^ (2) a wrong code, reduced test module m implicit none type t integer :: ii = 55 end type t contains subroutine sub (from, from2) class(t) :: from, from2(:) type(t) :: to, to2(3) if (from%ii /= 43) call abort() if (size (from2) /= 3) call abort() if (any (from2(:)%ii /= [11,22,33])) call abort() to = from ! TYPE = CLASS to2 = from2 ! TYPE = CLASS print *, to%ii !if (to%ii /= 43) call abort() if (any (to2(:)%ii /= [11,22,33])) call abort() end subroutine sub end module m program test use m implicit none type(t), target :: x type(t), target :: y(3) x%ii = 43 y(:)%ii = [11,22,33] call sub(x,y) x = func1() print *, x ! if (x%ii /= 123) call abort() y = func1() print *, y ! if (any (y(:)%ii /= 123)) call abort() contains function func1() class(t), allocatable :: func1 allocate(func1) func1%ii = 123 end function func1 end program test [Book15] f90/bug% gfc49 pr63205_red_1.f90 [Book15] f90/bug% a.out 167182484 586153984 586154000 586154000 586154000 Any objection that I open a new PR for the ICE? 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. AFAICT the assignment works for array variable, at least in the to2 context.
[Bug c++/63244] New: x86_64-pc-linux-gnu-g++: internal compiler error: Segmentation fault (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63244 Bug ID: 63244 Summary: x86_64-pc-linux-gnu-g++: internal compiler error: Segmentation fault (program cc1plus) Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nheghathivhistha at gmail dot com Created attachment 33481 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33481action=edit Preprocessed un-reduced file Part of media-libs/mesa-10.2.7 Gentoo package segfaults cc1plus: x86_64-pc-linux-gnu-g++ -m32 -DPACKAGE_NAME=\Mesa\ -DPACKAGE_TARNAME=\mesa\ -DPACKAGE_VERSION=\10.2.7\ -DPACKAGE_STRING=\Mesa 10.2.7\ -DPACKAGE_BUGREPORT=\https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\; -DPACKAGE_URL=\\ -DPACKAGE=\mesa\ -DVERSION=\10.2.7\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\.libs/\ -DHAVE___BUILTIN_BSWAP32=1 -DHAVE___BUILTIN_BSWAP64=1 -DHAVE_DLADDR=1 -DHAVE_CLOCK_GETTIME=1 -DHAVE_PTHREAD=1 -I. -DHAVE_PIPE_LOADER_XLIB -DHAVE_PIPE_LOADER_DRI -DHAVE_PIPE_LOADER_DRM -DPIPE_SEARCH_DIR=\/usr/lib32/gallium-pipe\ -I../../../../include -I../../../../src/gallium/include -I../../../../src/gallium/drivers -I../../../../src/gallium/auxiliary -I../../../../src/gallium/winsys -I. -std=c++11 -fvisibility=hidden -flto=4 -fuse-linker-plugin -O2 -ggdb -pipe -march=core2 -mtune=core2 -mno-3dnow -mno-sse4.2 -mno-avx -mno-xop -mno-fma4 -mno-sse4a -Wall -fno-strict-aliasing -fno-builtin-memcmp -c core/context.cpp -fPIC -DPIC -o core/.libs/libclover_la-context.o -save-temps x86_64-pc-linux-gnu-g++: warning: -pipe ignored because -save-temps specified x86_64-pc-linux-gnu-g++: internal compiler error: Segmentation fault (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See https://bugs.gentoo.org/ for instructions. When LTO is not enabled it not happens. It crashes the same way in 64 bit mode.
[Bug c++/63244] x86_64-pc-linux-gnu-g++: internal compiler error: Segmentation fault (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63244 --- Comment #1 from David Kredba nheghathivhistha at gmail dot com --- gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.2-alpha20140911/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.2-alpha20140911/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.9.2_alpha20140911/work/gcc-4.9-20140911/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.2-alpha20140911 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2-alpha20140911/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.2-alpha20140911 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.2-alpha20140911/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.2-alpha20140911/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2-alpha20140911/include/g++-v4 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.9.2-alpha20140911/python --enable-languages=c,c++,go,objc,obj-c++,fortran,ada --enable-obsolete --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.9.2_alpha20140911' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp --enable-lto --with-cloog --disable-isl-version-check Thread model: posix gcc version 4.9.2-alpha20140911 20140912 (prerelease) [gcc-4_9-branch revision 215199] (Gentoo 4.9.2_alpha20140911)
[Bug c++/63244] x86_64-pc-linux-gnu-g++: internal compiler error: Segmentation fault (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63244 --- Comment #2 from David Kredba nheghathivhistha at gmail dot com --- x86_64-pc-linux-gnu-g++ -m32 -std=c++11 -fvisibility=hidden -flto=4 -fuse-linker-plugin -O2 -ggdb -pipe -march=core2 -mtune=core2 -mno-3dnow -mno-sse4.2 -mno-avx -mno-xop -mno-fma4 -mno-sse4a -Wall -fno-strict-aliasing -fno-builtin-memcmp -c context.ii -fPIC -DPIC -o context.o reproduces it from my home folder.
[Bug sanitizer/63245] New: renderMemorySnippet shouldn't show more bytes than the underlying type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63245 Bug ID: 63245 Summary: renderMemorySnippet shouldn't show more bytes than the underlying type Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org c-c++-common/ubsan/align-4.c fails at random for -m32 on Linux/x86: /export/gnu/import/git/gcc/gcc/testsuite/c-c++-common/ubsan/align-2.c:37:11: runtime error: load of misaligned address 0x08049ff1 for type 'long long int', which requires 4 byte alignment 0x08049ff1: note: pointer points here 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Program received signal SIGSEGV, Segmentation fault. 0xf79f0e98 in renderMemorySnippet (Args=optimized out, NumRanges=optimized out, Ranges=optimized out, Loc=optimized out, Decor=...) at /export/gnu/import/git/gcc/libsanitizer/ubsan/ubsan_diag.cc:208 208Printf(%s%02x, (P % 8 == 0) ?: , C); (gdb) The program has 08048000-08049000 r-xp 08:11 39853233 /export/build/gnu/gcc-x32-mx32/build-x86_64-linux/gcc/testsuite/g++/align-4.exe 08049000-0804a000 rw-p 08:11 39853233 /export/build/gnu/gcc-x32-mx32/build-x86_64-linux/gcc/testsuite/g++/align-4.exe There is a long long int at 0x08049ff1. But renderMemorySnippet tries to show 32 bytes even though long long int only has 8 bytes.
[Bug middle-end/61654] [4.9/5 Regression] ICE in release_function_body, at cgraph.c:1699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61654 --- Comment #14 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Fri Sep 12 16:52:24 2014 New Revision: 215228 URL: https://gcc.gnu.org/viewcvs?rev=215228root=gccview=rev Log: 2014-09-12 Martin Jambor mjam...@suse.cz PR ipa/61654 * cgraph.h (cgraph_analyze_function): Declare. * cgraphunit.c: (analyze_function): Remove forward declaration, rename to cgraph_analyze_function, made external. * cgraphclones.c (duplicate_thunk_for_node): Copy arguments of the new decl properly. Analyze the new thunk if it is expanded. gcc/testsuite/ * g++.dg/ipa/pr61654.C: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ipa/pr61654.C Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/cgraph.h branches/gcc-4_9-branch/gcc/cgraphclones.c branches/gcc-4_9-branch/gcc/cgraphunit.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug middle-end/61654] [4.9/5 Regression] ICE in release_function_body, at cgraph.c:1699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61654 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Martin Jambor jamborm at gcc dot gnu.org --- Fixed.
[Bug c++/63244] x86_64-pc-linux-gnu-g++: internal compiler error: Segmentation fault (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63244 --- Comment #3 from David Kredba nheghathivhistha at gmail dot com --- C-Reduce in progress.
[Bug target/61142] [SH] QImode/HImode @(R0,Rm),Rn does not load to Rn = R0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61142 --- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org --- I've tried the above test case with LRA on (sh-lra branch, not fully working yet) and it produces the following code: mov r5,r0 mov.b @(r0,r4),r0 cmp/eq #92,r0 bt .L3 mov r7,r0 rts nop .align 1 .L3: rts mov r6,r0 i.e. the problem is gone.
[Bug middle-end/63244] [4.9 regression] internal compiler error: Segmentation fault (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63244
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||4.7.3, 5.0
Last reconfirmed||2014-09-12
Component|c++ |middle-end
CC||trippels at gcc dot gnu.org
Ever confirmed|0 |1
Summary|x86_64-pc-linux-gnu-g++:|[4.9 regression] internal
|internal compiler error:|compiler error:
|Segmentation fault (program |Segmentation fault (program
|cc1plus)|cc1plus)
Target Milestone|--- |4.9.3
Known to fail||4.9.2
--- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
markus@x4 tmp % cat context.ii
namespace std {
template typename
void declval();
class A;
}
namespace detail {
template typename...
class iterator_adaptor;
template typename, typename, typename
class basic_range;
template typename T
using preferred_iterator_type = decltype(std::declvalT);
}
template typename... Os
class adaptor_range
: detail::basic_range
adaptor_rangeOs...,
detail::iterator_adaptordetail::preferred_iterator_typeOs...,
detail::iterator_adaptordetail::preferred_iterator_typeOs... {};
template typename
using property_list = std::A;
class B {
B(const property_listint p1, const adaptor_rangeint, int p2);
};
B::B(const ::property_listint p1, const adaptor_rangeint, int p2) {}
markus@x4 tmp % gdb --args g++ -std=c++11 -c context.ii
Reading symbols from g++...done.
(gdb) run
Starting program: /usr/bin/g++ -std=c++11 -c context.ii
process 30304 is executing new program:
/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.2/g++
[New process 30308]
process 30308 is executing new program:
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.2/cc1plus
Program received signal SIGSEGV, Segmentation fault.
[Switching to process 30308]
0x00c2ffd6 in analyze_functions() ()
(gdb) bt
#0 0x00c2ffd6 in analyze_functions() ()
#1 0x00c2ed95 in finalize_compilation_unit() ()
#2 0x00d2a2d4 in cp_write_global_declarations() ()
#3 0x00c29020 in compile_file() [clone .lto_priv.2474] ()
#4 0x00b6ccd7 in toplev_main(int, char**) ()
#5 0x77741fd0 in __libc_start_main () from /lib/libc.so.6
#6 0x00b66a93 in _start ()
(gdb)
[Bug middle-end/63246] New: OpenMP target: gimplifier produces unsuitable implicit map clauses if inside a data region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63246
Bug ID: 63246
Summary: OpenMP target: gimplifier produces unsuitable implicit
map clauses if inside a data region
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Consider:
int
main(int argc, char **argv)
{
#define N 4
short a[N];
#pragma omp target data map(a[1:N-1])
{
#pragma omp target
{
a[1] = 51;
}
}
return 0;
}
..., which results in the following gimple:
[...]
#pragma omp target data map(tofrom:a[1] [len: 6]) map(alloc:a
[pointer assign, bias: 2])
{
try
{
{
#pragma omp target map(tofrom:a [len: 8])
{
{
a[1] = 51;
[...]
The outer data region sets up an expicit mapping for a subset of the array, and
the inner target construct then again gets an implicit map clause added for
*the whole* region. A suitably equipped libgomp (for example, gomp-4_0-branch
with the non-shared memory host plugin) doesn't like this:
libgomp: Trying to map into device [0x7fff6f513410..0x7fff6f513418) object
when[0x7fff6f513412..0x7fff6f513418) is already mapped
[Bug bootstrap/63235] building fails with --disable-bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63235 --- Comment #5 from Andi Kleen andi-gcc at firstfloor dot org --- Created attachment 33482 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33482action=edit use ifdef instead of builtin_cpu_supports This patch fixes the problem for me. Just use an ifdef instead of builtin_cpu_supports.
[Bug fortran/63247] New: fortran array alignment in omp target map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63247 Bug ID: 63247 Summary: fortran array alignment in omp target map Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: cesar at codesourcery dot com I've noticed that lower_omp_target is not passing the proper pointer alignment to libgomp for fortran array maps. While this isn't a problem for trunk, it does affect our nvptx target. Here is a test case: program test implicit none integer a(5) a = 10; write (*, '(a,Z16)') 'address of a = ', loc(a) !$omp target map(a(1:5)) a(1) = 5 a(2) = 5 a(3) = 5 a(4) = 5 a(5) = 5 !$omp end target end program test Here's my gdb session: Breakpoint 5, lower_omp_target (gsi_p=, ctx=) at ../../../gcc/gcc/omp-low.c:10191 10191CONSTRUCTOR_APPEND_ELT (vkind, purpose, (gdb) p talign $10 = 2 (gdb) p ovar $11 = (tree) (gdb) pt warning: Expression is not an assignment (and might have no effect) var_decl 0x7630a900 a type array_type 0x7643e3f0 type integer_type 0x76303690 integer(kind=4) public SI size integer_cst 0x762ffdb0 constant 32 unit size integer_cst 0x762ffdc8 constant 4 align 32 symtab 0 alias set -1 canonical type 0x76303690 precision 32 min integer_cst 0x762ffd68 -2147483648 max integer_cst 0x762ffd80 2147483647 pointer_to_this pointer_type 0x76319738 type_2 BLK size integer_cst 0x7641b798 constant 160 unit size integer_cst 0x7643a300 constant 20 align 32 symtab 0 alias set -1 canonical type 0x7643e3f0 domain integer_type 0x7643e738 type integer_type 0x763037e0 integer(kind=8) DI size integer_cst 0x762ffb70 constant 64 unit size integer_cst 0x762ffb88 constant 8 align 64 symtab 0 alias set -1 canonical type 0x7643e738 precision 64 min integer_cst 0x7631d1f8 0 max integer_cst 0x7643a1f8 4 pointer_to_this pointer_type 0x7643e930 addressable used decl_0 BLK file /home/cphilipp/tools/nvidia/demos/fortran-tests/pointer-align-2.f90 line 4 col 0 size integer_cst 0x7641b798 160 unit size integer_cst 0x7643a300 20 align 32 context function_decl 0x7643d360 test (gdb) p talign $12 = 2 How should this issue be resolved? I think the fortran FE behavior is correct. Should lower_omp_target have something like this if (tkind == OMP_CLAUSE_MAP_POINTER) talign = POINTER_SIZE / BITS_PER_UNIT; or should libgomp correct the alignment for OMP_CLAUSE_MAP_POINTER? It should be noted the C FE doesn't have this problem with arrays. Thanks, Cesar
[Bug target/50751] SH Target: Displacement addressing does not work for QImode and HImode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Depends on||55212 --- Comment #36 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Oleg Endo from comment #35) (In reply to Oleg Endo from comment #34) Compiling with -Os -m4 -ml -matomic-model=soft-gusa, I get: Probably we really should try switching to LRA (PR 55212). I've tried compiling the problematic test case with the sh-lra branch (LRA enabled) and '-Os -m4 -ml -matomic-model=soft-gusa' and '-Os -m4 -mb -matomic-model=soft-gusa'. The problem seems to be gone for those parameters, but when compiling for '-O2 -m4 -ml -matomic-model=soft-gusa' it crashes: internal compiler error: in check_rtl, at lra.c:1928 TEST_FUNCS (complex_float_add, _Complex float, , += 1, 0, 2) ^ 0x8523d00 check_rtl ../../gcc-sh-lra/gcc/lra.c:1928 0x85273f7 lra(_IO_FILE*) ../../gcc-sh-lra/gcc/lra.c:2318 0x84e6823 do_reload ../../gcc-sh-lra/gcc/ira.c:5306 0x84e6823 execute ../../gcc-sh-lra/gcc/ira.c:5465
[Bug bootstrap/63235] building fails with --disable-bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63235 --- Comment #6 from Andi Kleen andi-gcc at firstfloor dot org --- Created attachment 33483 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33483action=edit Preprocessed file from the cilk runtime library I'm not sure it'll help you because you would likely need a compiler miscompiled in the same way as mine?
[Bug target/59400] [SH] gcc.c-torture/compile/pr55921.c fails with -O0 on big endian with FPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59400 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Depends on||55212 --- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org --- I've tried the problematic case with the sh-lra branch and the problem seems to be gone.
[Bug c++/63248] New: Crash when OpenMP target's array section handling is used with templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63248
Bug ID: 63248
Summary: Crash when OpenMP target's array section handling is
used with templates
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Consider:
template typename T
void f(T A, T B)
{
extern int *v;
T a = 2;
T b = 4;
#pragma omp target map(to: v[a:b])
v[a] = 0;
#pragma omp target map(to: v[A:B])
v[a] = 0;
}
void g()
{
f(1, 5);
}
GCC doesn't like that template usage:
../../openacc/T.C: In function 'void f(T, T)':
../../openacc/T.C:8:35: internal compiler error: Segmentation fault
0xc1833f crash_signal
../../source/gcc/toplev.c:339
0x697f0d tree_class_check
../../source/gcc/tree.h:2851
0x697f0d cp_omp_mappable_type(tree_node*)
../../source/gcc/cp/decl2.c:1393
0x764777 finish_omp_clauses(tree_node*)
../../source/gcc/cp/semantics.c:5671
0x6d3d39 cp_parser_omp_all_clauses
../../source/gcc/cp/parser.c:28680
0x6c6265 cp_parser_omp_target
../../source/gcc/cp/parser.c:30649
[...]
Discussion in
http://news.gmane.org/find-root.php?message_id=%3C87zje7rdho.fsf%40schwinge.name%3E.
[Bug c++/60894] [4.8/4.9/5 Regression] Use of redundant struct keyword in function prototype combined with using statement causes compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60894 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Known to fail|4.10.0 |5.0 --- Comment #8 from Jason Merrill jason at gcc dot gnu.org --- (In reply to fabien from comment #6) I looked into it but did not manage to get it fixed. I will have another try this week. Thanks for the reminder. Ping?
[Bug middle-end/63244] [4.9 regression] internal compiler error: Segmentation fault (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63244
--- Comment #5 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
(gdb) bt
#0 analyze_functions () at ../../gcc/gcc/cgraphunit.c:1042
#1 0x006e03f0 in finalize_compilation_unit () at
../../gcc/gcc/cgraphunit.c:2326
#2 0x00594dd4 in cp_write_global_declarations () at
../../gcc/gcc/cp/decl2.c:4643
#3 0x00951a4d in compile_file () at ../../gcc/gcc/toplev.c:562
#4 0x00953620 in do_compile () at ../../gcc/gcc/toplev.c:1917
#5 toplev_main (argc=15, argv=0x7fffdfb8) at ../../gcc/gcc/toplev.c:1993
#6 0x775fcfd0 in __libc_start_main () from /lib/libc.so.6
#7 0x0052cf61 in _start ()
(gdb) l
1037 will be later needed to output debug info. */
1038 if (DECL_ABSTRACT_ORIGIN (decl))
1039{
1040 struct cgraph_node *origin_node
1041 = cgraph_get_node (DECL_ABSTRACT_ORIGIN (decl));
1042 origin_node-used_as_abstract_origin = true;
1043}
1044}
1045 else
1046{
[Bug middle-end/63244] [4.9 regression] internal compiler error: Segmentation fault (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63244 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.9.3 |4.9.2
[Bug target/34777] uClibc-0.9.29 compilation error for sh4 arch with gcc-4.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34777
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Depends on||55212
--- Comment #12 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #11)
seems to fix the test case of PR 34807. However, I've not tested it any
further and probably the fix is incomplete and works only for mem loads and
not stores.
In fact it can be broken again quite easily by inserting another insn that
requires R0 (tst #imm,r0 in this case):
int glob, glob1;
static int _dl_mmap (int xx)
{
register int __sc0 __asm__ (r0) = glob1;
register int __sc1 __asm__ (r1) = glob;
if (xx 3)
__asm__ (trapa %1 : =z (__sc0) : i (0x10), 0 (__sc0), r
(__sc1));
return (__sc0);
}
void _start(int xx)
{
static int buf;
buf = _dl_mmap(xx);
}
I've tried that test case with the sh-lra branch and the problems seem to be
gone.
[Bug c++/63249] New: [OpenMP] Spurious »set but not used« warnings when actually used in OpenMP target's array section's lower-bound and length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63249
Bug ID: 63249
Summary: [OpenMP] Spurious »set but not used« warnings when
actually used in OpenMP target's array section's
lower-bound and length
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Depends on: 63248
This is similar to what has previously been addressed in
https://gcc.gnu.org/PR51360,
http://news.gmane.org/find-root.php?message_id=%3C20111215173852.GT1957%40tyan-ft48-01.lab.bos.redhat.com%3E:
int f(int A, int B)
{
int r = 0;
extern int *v;
int a = 2;
int b = 4;
int n = 3;
v[n] = 0;
#pragma omp target map(to: v[a:b])
r |= v[n];
#pragma omp target map(to: v[A:B])
r |= v[n];
return r;
}
../../openacc/w.c: In function 'f':
../../openacc/w.c:6:7: warning: variable 'b' set but not used
[-Wunused-but-set-variable]
int b = 4;
^
../../openacc/w.c:5:7: warning: variable 'a' set but not used
[-Wunused-but-set-variable]
int a = 2;
^
../../openacc/w.c:1:11: warning: parameter 'A' set but not used
[-Wunused-but-set-parameter]
int f(int A, int B)
^
../../openacc/w.c:1:18: warning: parameter 'B' set but not used
[-Wunused-but-set-parameter]
int f(int A, int B)
^
Patch (for C) submitted in
http://news.gmane.org/find-root.php?message_id=%3C87y4trrcsk.fsf%40schwinge.name%3E,
C++ blocked on PR63248.
[Bug bootstrap/63235] building fails with --disable-bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63235 --- Comment #7 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Andi Kleen from comment #6) Created attachment 33483 [details] Preprocessed file from the cilk runtime library I'm not sure it'll help you because you would likely need a compiler miscompiled in the same way as mine? There were surly a number of wrong-code bugs fixed between your version 4.8.1 20130909 and the 4.8.3 release. I cannot reproduce the issue with 4.8.3.
[Bug fortran/63247] fortran array alignment in omp target map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63247
Thomas Schwinge tschwinge at gcc dot gnu.org changed:
What|Removed |Added
Keywords||openmp
CC||tschwinge at gcc dot gnu.org
Version|unknown |5.0
--- Comment #1 from Thomas Schwinge tschwinge at gcc dot gnu.org ---
Actually, here is a C test case that exhibits the problem on x86 (which has a
flag to switch on alignment checking), with OpenMP using the non-shared memory
host plugin. Need to build with -O, as otherwise there will be other alignment
errors. This is probably too fragile for any test suite usage, though.
#include stdlib.h
int
main(int argc, char **argv)
{
#define N 4
short a[N];
a[0] = 10;
a[1] = 10;
a[2] = 10;
a[3] = 10;
#pragma omp target map(a[1:N-1])
{
__asm__(pushf\norl $(118),(%rsp)\npopf);
a[1] = 51;
a[2] = 52;
a[3] = 53;
__asm__(pushf\nandl $(~(118)),(%rsp)\npopf);
}
if (a[0] != 10)
abort ();
if (a[1] != 51)
abort ();
if (a[2] != 52)
abort ();
if (a[3] != 53)
abort ();
return 0;
}
$ gdb -q ./a.out
Reading symbols from ./a.out...done.
(gdb) r
Starting program: [...]/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
Program received signal SIGBUS, Bus error.
0x0040080e in main._omp_fn.0 (.omp_data_i=0x6020c0) at
source-gcc/libgomp/testsuite/libgomp.c/pointer-align-1.c:19
19 a[1] = 51;
(gdb) disassemble
Dump of assembler code for function main._omp_fn.0:
0x00400801 +0: pushfq
0x00400802 +1: orl$0x4,(%rsp)
0x00400809 +8: popfq
0x0040080a +9: mov0x8(%rdi),%rax
= 0x0040080e +13:mov(%rax),%rax
0x00400811 +16:movw $0x33,0x2(%rax)
0x00400817 +22:mov0x8(%rdi),%rax
0x0040081b +26:mov(%rax),%rax
0x0040081e +29:movw $0x34,0x4(%rax)
0x00400824 +35:mov0x8(%rdi),%rax
0x00400828 +39:mov(%rax),%rax
0x0040082b +42:movw $0x35,0x6(%rax)
0x00400831 +48:pushfq
0x00400832 +49:andl $0xfffb,(%rsp)
0x00400839 +56:popfq
0x0040083a +57:retq
End of assembler dump.
(gdb) info registers rax
rax0x6020d6 6299862
[Bug middle-end/63244] [4.9 regression] internal compiler error: Segmentation fault (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63244
--- Comment #6 from David Kredba nheghathivhistha at gmail dot com ---
For the record only, git version of c-reduce returned
namespace std {
template typename struct less;
template typename struct add_rvalue_reference;
template typename _Tp typename add_rvalue_reference_Tp::type declval();
template typename _Tp struct __add_rvalue_reference_helper {
typedef _Tp type;
};
template typename _Tp
struct add_rvalue_reference : __add_rvalue_reference_helper_Tp {};
}
typedef int intptr_t;
namespace std {
template typename class allocator;
template typename _Tp, typename = allocator_Tp class vector {};
}
typedef intptr_t cl_context_properties;
namespace clover {
class device;
}
namespace std {
template typename _Key, typename = less_Key class map;
}
namespace clover {
template typename class intrusive_ref;
struct derefs;
namespace detail {
template typename, typename... class iterator_adaptor;
template typename, typename, typename class basic_range {
public:
template typename V operator V() const {}
};
template typename T using preferred_iterator_type =
decltype(std::declvalT);
}
template typename F, typename... Os
class adaptor_range : public detail::basic_range
adaptor_rangeF, detail::iterator_adaptorF,
detail::iterator_adaptor
F, detail::preferred_iterator_typeOs... {};
template typename T
class ref_vector : public adaptor_rangederefs, std::vectorT {};
template typename class property_element;
template typename D using property_list = std::mapproperty_elementD ;
class context {
typedef clover::property_listcl_context_properties property_list;
context(const property_list , const ref_vectordevice );
std::vectorintrusive_refdevice devs;
};
}
using namespace clover;
context::context(const property_list , const ref_vectordevice devs)
: devs(devs) {}
[Bug middle-end/63244] [4.9 regression] internal compiler error: Segmentation fault (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63244
--- Comment #7 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
When one uses a naive test script one arrives at the testcase
from comment 4. Using a differential script (-O2 vs. -flto -O2 -g)
one gets:
markus@x4 /tmp % cat context2.ii
namespace std {
template typename _Tp
_Tp declval();
}
class A {};
namespace std {
template typename
using __allocator_base = A;
template typename
class H : __allocator_baseint {};
template typename _Tp, typename = std::H_Tp
class I {};
}
template typename
class D;
struct F;
namespace detail {
template typename, typename...
class iterator_adaptor;
template typename, typename, typename
class basic_range {
public:
template typename
using store_traits = int;
template typename V
operator V() const {}
};
template typename T
using preferred_iterator_type = decltype(std::declvalT);
}
template typename... Os
class adaptor_range
: public detail::basic_range
adaptor_rangeOs...,
detail::iterator_adaptorF, detail::preferred_iterator_typeOs...,
detail::iterator_adaptor
F, detail::preferred_iterator_typeconst Os... {};
class J : public adaptor_rangestd::Iint * {};
template typename
using property_list = int;
class G {
G(const property_listint props, const J );
std::IDint devs;
};
G::G(const property_listint props, const J devs) : devs(devs) {}
markus@x4 /tmp % g++ -std=c++11 -flto -O2 -g -c context2.ii
g++: internal compiler error: Segmentation fault (program cc1plus)
0x40c96c execute
../../gcc/gcc/gcc.c:2855
0x40cd34 do_spec_1
../../gcc/gcc/gcc.c:4659
0x40f5f6 process_brace_body
../../gcc/gcc/gcc.c:5942
0x40f5f6 handle_braces
../../gcc/gcc/gcc.c:5856
0x40dba9 do_spec_1
../../gcc/gcc/gcc.c:5313
0x40f5f6 process_brace_body
../../gcc/gcc/gcc.c:5942
0x40f5f6 handle_braces
../../gcc/gcc/gcc.c:5856
0x40dba9 do_spec_1
../../gcc/gcc/gcc.c:5313
0x40d913 do_spec_1
../../gcc/gcc/gcc.c:5428
0x40f5f6 process_brace_body
../../gcc/gcc/gcc.c:5942
0x40f5f6 handle_braces
../../gcc/gcc/gcc.c:5856
0x40dba9 do_spec_1
../../gcc/gcc/gcc.c:5313
0x40f5f6 process_brace_body
../../gcc/gcc/gcc.c:5942
0x40f5f6 handle_braces
../../gcc/gcc/gcc.c:5856
0x40dba9 do_spec_1
../../gcc/gcc/gcc.c:5313
0x40f5f6 process_brace_body
../../gcc/gcc/gcc.c:5942
0x40f5f6 handle_braces
../../gcc/gcc/gcc.c:5856
0x40dba9 do_spec_1
../../gcc/gcc/gcc.c:5313
0x40f5f6 process_brace_body
../../gcc/gcc/gcc.c:5942
0x40f5f6 handle_braces
../../gcc/gcc/gcc.c:5856
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
Looks like a stack overflow.
(-g and -flto alone are fine)
markus@x4 /tmp % g++ -std=c++11 -O2 -g -c context2.ii
markus@x4 /tmp % g++ -std=c++11 -flto -O2 -c context2.ii
markus@x4 /tmp %
[Bug c++/59500] Bogus maybe-uninitialized warning due to optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59500 --- Comment #3 from Andy Lutomirski luto at mit dot edu --- Created attachment 33484 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33484action=edit Headerless reproducer (c++ only)
[Bug c++/59500] Bogus maybe-uninitialized warning due to optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59500 --- Comment #4 from Andy Lutomirski luto at mit dot edu --- Created attachment 33485 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33485action=edit Output from g++ -O2 -Wall -fdump-tree-all-all-lineno pr59500.cc
[Bug middle-end/63246] OpenMP target: gimplifier produces unsuitable implicit map clauses if inside a data region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63246 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- IMNSHO this is just a buggy testcase, whether something is present in map clauses on target data region matters only for the actual allocations, but not for what map clauses are explicit or implicit on the target region. I've already earlier today commented on the IMHO invalid textcase from OpenMP 4.0.1 examples 56.3[cf] in the ticket discussing bugs in the Examples document. If you don't want the implicit map(a) clause, you should provide the map(a[1:N-1]) there (which will not map anything, because it is already mapped, but will DTRT wrt. pointer translation).
[Bug libstdc++/61909] Small function optimization not applied to small objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61909 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-12 Ever confirmed|0 |1 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- The right fix requires std::is_trivially_copyable, so fixing this properly this will have to wait until someone implements that.
[Bug libstdc++/54316] [C++11] move constructor for stringstream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54316 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug libstdc++/56193] ios_base should replace operator void* with explicit operator bool in C++11 onwards.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56193 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug c++/62052] function parameter has wrong address in lambda converted to pointer-to-function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62052 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-12 Ever confirmed|0 |1 Known to fail|4.10.0 |5.0
[Bug bootstrap/63235] building fails with --disable-bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63235 --- Comment #8 from Andi Kleen andi-gcc at firstfloor dot org --- Yes it doesn't happen when compiling with 4.8 branch tip. So has been fixed. Anyways i'm still going to submit the patch to make the opensuse 13.1 build work again. I don't think it should hurt anything here to use ifdef.
[Bug bootstrap/63235] building fails with --disable-bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63235 --- Comment #9 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Andi Kleen from comment #8) Yes it doesn't happen when compiling with 4.8 branch tip. So has been fixed. Anyways i'm still going to submit the patch to make the opensuse 13.1 build work again. I don't think it should hurt anything here to use ifdef. The difference is run-time check vs compile-time check.
[Bug bootstrap/63235] building fails with --disable-bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63235 --- Comment #10 from Andi Kleen andi-gcc at firstfloor dot org --- Ok fair enough. Can do the runtime check in the else of the ifdef then. Then at least x86_64 or 32bit with SSE would work.
[Bug target/63250] New: Complex fp16 arithmetic uses nonexistent libgcc functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63250
Bug ID: 63250
Summary: Complex fp16 arithmetic uses nonexistent libgcc
functions
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jsm28 at gcc dot gnu.org
Target: arm*-*-*
If on ARM you declare complex __fp16 values using __attribute__((mode(HC)))
(because you can't use _Complex __fp16 directly, the ARM analogue of bug
32187), this is accepted, but multiplication and division of those values
produces references to libgcc functions __mulhc3 and __divhc3 that don't exist.
E.g., compiled with -O2 -mfp16-format=ieee:
typedef _Complex float fp16c __attribute__((mode(HC)));
fp16c a, b;
fp16c f (void) { return a * b; }
Just as __fp16 values are promoted to float for arithmetic, so should complex
fp16 values probably be promoted to complex float. (Were TS 18661-3
implemented, there would be various differences from the existing __fp16 and
__float128 support in GCC, but there would still be no need for HCmode
operations as distinct from promoting to SCmode then converting results back to
HCmode at some point, whether you define FLT_EVAL_METHOD to 32, which would be
the closest equivalent to the existing promotion, or treat the promotion as an
implementation detail and truncate after every operation.)
[Bug c++/59500] Bogus maybe-uninitialized (|| converted to nested-if)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59500 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-12 Blocks||24639 Summary|Bogus maybe-uninitialized |Bogus maybe-uninitialized |warning due to |(|| converted to nested-if) |optimizations | Ever confirmed|0 |1 --- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Andy Lutomirski from comment #1) This might be a duplicate of PR56574 I think not. In this case the problem is that # value = PHIvalue(D),intval() if (!valid || intval() value) is converted to # value = PHIvalue(D),intval() if(!valid) else if (intval() value) and I think the uninit pass is not smart enough to realize that the use is guarded by valid != 0 but the default definition implies valid == 0. Perhaps it is also a missed-optimization, since if(cond()) could jump directly to if (intval() value).
[Bug sanitizer/63251] New: tsan: corrupted shadow stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63251 Bug ID: 63251 Summary: tsan: corrupted shadow stack Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: dvyukov at google dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Created attachment 33486 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33486action=edit reproducer Reported in the ThreadSanitizer bug tracker, but it looks like gcc instrumentation issue: https://code.google.com/p/thread-sanitizer/issues/detail?id=76 gcc version 5.0.0 20140830 (experimental) (GCC) $ g++ -fsanitize=thread /tmp/stack.cc -pie -fPIE -g $ ./a.out == WARNING: ThreadSanitizer: data race (pid=27898) ... Thread T2 (tid=27901, running) created by main thread at: #0 pthread_create ../../.././libsanitizer/tsan/tsan_interceptors.cc:853 (libtsan.so.0+0x00026eb4) #1 main /tmp/stack.cc:28 (a.out+0x1017) #2 void std::__introsort_loop__gnu_cxx::__normal_iteratorint*, std::vectorint, std::allocatorint , long, __gnu_cxx::__ops::_Iter_less_iter(__gnu_cxx::__normal_iteratorint*, std::vectorint, std::allocatorint , __gnu_cxx::__normal_iteratorint*, std::vectorint, std::allocatorint , long, __gnu_cxx::__ops::_Iter_less_iter) /ssd/src/gcc_trunk/install/include/c++/5.0.0/bits/stl_algo.h:1952 (a.out+0x1d60) #3 void std::__sort__gnu_cxx::__normal_iteratorint*, std::vectorint, std::allocatorint , __gnu_cxx::__ops::_Iter_less_iter(__gnu_cxx::__normal_iteratorint*, std::vectorint, std::allocatorint , __gnu_cxx::__normal_iteratorint*, std::vectorint, std::allocatorint , __gnu_cxx::__ops::_Iter_less_iter) /ssd/src/gcc_trunk/install/include/c++/5.0.0/bits/stl_algo.h:1967 (a.out+0x182c) #4 void std::sort__gnu_cxx::__normal_iteratorint*, std::vectorint, std::allocatorint (__gnu_cxx::__normal_iteratorint*, std::vectorint, std::allocatorint , __gnu_cxx::__normal_iteratorint*, std::vectorint, std::allocatorint ) /ssd/src/gcc_trunk/install/include/c++/5.0.0/bits/stl_algo.h:4676 (a.out+0x130a) #5 main /tmp/stack.cc:24 (a.out+0x0fd9) Frames #1-4 are bogus and must not be present in the thread creation stack. Clang produces a correct stack, which is: Thread T2 (tid=12121, running) created by main thread at: #0 pthread_create /ssd/src/llvm/build/../projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:847 (a.out+0x00048403) #1 main /tmp/stack.cc:28:3 (a.out+0x00095bcf) Looking at the symptoms I think that the sort-related functions do not call __tsan_func_exit and so they are left on the shadow stack. It's not only about report quality. If it happens enough times, then it will overflow and blow up tsan shadow stack.
[Bug fortran/63252] New: [5 Regression] tree_class_check_failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63252 Bug ID: 63252 Summary: [5 Regression] tree_class_check_failed Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: bur...@net-b.de On Linux/x32, r213979 caused [hjl@gnu-mic-2 gcc]$ ./xgcc -B./ /export/gnu/import/git/gcc/gcc/testsuite/gfortran.dg/coarray_32.f90 -fcoarray=lib -S f951: internal compiler error: Segmentation fault 0xa5499f crash_signal /export/gnu/import/git/gcc/gcc/toplev.c:337 0xca11be tree_class_check_failed(tree_node const*, tree_code_class, char const*, int, char const*) /export/gnu/import/git/gcc/gcc/tree.c:9203 0xca56d0 tree_class_check(tree_node*, tree_code_class, char const*, int, char const*) /export/gnu/import/git/gcc/gcc/tree.h:2852 0xca56d0 type_hash_list /export/gnu/import/git/gcc/gcc/tree.c:6639 0xca5acd build_function_type(tree_node*, tree_node*) /export/gnu/import/git/gcc/gcc/tree.c:7994 0x60b989 build_library_function_decl_1 /export/gnu/import/git/gcc/gcc/fortran/trans-decl.c:2784 0x60bc8f gfc_build_library_function_decl_with_spec(tree_node*, char const*, tree_node*, int, ...) /export/gnu/import/git/gcc/gcc/fortran/trans-decl.c:2835 0x60d9e6 gfc_build_builtin_function_decls() /export/gnu/import/git/gcc/gcc/fortran/trans-decl.c:3422 0x5e4377 gfc_create_decls /export/gnu/import/git/gcc/gcc/fortran/f95-lang.c:196 0x5e4377 gfc_be_parse_file /export/gnu/import/git/gcc/gcc/fortran/f95-lang.c:211 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. [hjl@gnu-mic-2 gcc]$ for stage2 and stage3 f951.
[Bug bootstrap/63253] New: boot strap failure due to ODR warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63253 Bug ID: 63253 Summary: boot strap failure due to ODR warnings Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: andi-gcc at firstfloor dot org I suppose it's Honza's commit commit b99d67c130c18dc99bc123dcf3fb9b06784892db Author: gccadmin gccadmin@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Fri Sep 12 00:16:51 2014 + Daily bump. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@215199 138bc75d-0d04-0410-961f-82ee72b054a4 commit d585ba22a6b4250b0d819d3d7da72f7dd37e2981 Author: hubicka hubicka@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Thu Sep 11 23:16:42 2014 + ../../gcc/gcc/tlink.c:62:16: error: type 'struct file_hash_entry' violates one definition rule [-Werror=odr] typedef struct file_hash_entry ^ ../../gcc/libcpp/files.c:143:8: note: a different type is defined in another translation unit struct file_hash_entry ^ ../../gcc/gcc/tlink.c:64:15: note: the first difference of corresponding definitions is field 'key' const char *key; ^ ../../gcc/libcpp/files.c:145:27: note: a field with different name is defined in another translation unit struct file_hash_entry *next; ^ lto1: all warnings being treated as errors
[Bug bootstrap/63253] boot strap failure due to ODR warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63253 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc/2014-09/msg00161.html
[Bug middle-end/61848] [5 Regression] a previous declaration causes the section attribute to be lost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848 --- Comment #11 from Alan Modra amodra at gmail dot com --- It boots Linux version 3.17.0-rc4-00222-gc73f6fd-dirty (anton@tul181p1) (gcc version 5.0.0 20140912 (experimental) (GCC) ) #23 SMP Fri Sep 12 21:19:06 UTC 2014
[Bug c++/63254] New: elfos.h missing space between literal and identifier.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63254 Bug ID: 63254 Summary: elfos.h missing space between literal and identifier. Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: scott.clark at itron dot com Created attachment 33487 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33487action=edit Zip file of the output (which shows the command line) and .ii file. On lines 102 and 170 of elfos.h, the compiler throws the following warning: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wliteral-suffix]
[Bug middle-end/61848] [5 Regression] a previous declaration causes the section attribute to be lost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848 --- Comment #12 from Alan Modra amodra at gmail dot com --- extern char foo; char foo __attribute__ ((__section__(.machine.desc))); char foo __attribute__ ((__section__(.mymachine.desc))); It looks like we should take out the DECL_SECTION_NAME (olddecl) == NULL checks. The above gives no diagnostic with older compilers, and results in section .mymachine.desc being used. trunk+patch results in section .machine.desc.
[Bug c++/63254] elfos.h missing space between literal and identifier.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63254 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-13 Ever confirmed|0 |1
