[Bug lto/62179] New: undefined reference linking failure when combining extern template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62179 Bug ID: 62179 Summary: undefined reference linking failure when combining extern template Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: miles at gnu dot org
[Bug ipa/61800] [5 Regression] ICE: Segmentation fault during Firefox build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61800 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/62156] memcmp doesn't see through memcpy at compile-time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62156 --- Comment #4 from rguenther at suse dot de rguenther at suse dot de --- On Mon, 18 Aug 2014, glisse at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62156 --- Comment #2 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) What kind of std::string code is this? That is, can we expect memcmp and memcpy to be adjacent (without intermediate memory operations?) I don't remember the exact code, but it was similar to: std::string(foo)==bar which, with _GLIBCXX_EXTERN_TEMPLATE=0 (or LTO) gives: _29 = _50 + 24; __builtin_memcpy (_29, foo, 3); if (_50 != _S_empty_rep_storage) goto bb 3; bb 3: MEM[(struct _Rep *)_50].D.20711._M_length = 3; MEM[(char_type )_50 + 27] = 0; __r_86 = __builtin_memcmp (_29, bar, 3); So it is setting the null character right after the string (could have used memcpy of size 4?) and the length right before, which requires tight alias checking to be sure that memcmp is not affected :-( Probably a bit too specific to be worth it. Eventually worth fixing the libstdc++ side to generate better initial code? Other than that it seems this would need careful special-handling in value-numbering ... not sure if optimizing std::string(foo) == bar is important.
[Bug target/62180] New: (RX600) - compiler doesn't honor -fstrict-volatile-bitfields and generates incorrect machine code for I/O register access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62180
Bug ID: 62180
Summary: (RX600) - compiler doesn't honor
-fstrict-volatile-bitfields and generates incorrect
machine code for I/O register access
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.capek at braiins dot cz
Created attachment 33359
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33359action=edit
broken output from gcc 4.9.0
I have come across this issue while testing 4.9.x series of the compiler with
Renesas RX600 target
The compiler now generates byte accesses when writing bitfields completely
ignoring their 'type'. The strict-volatile-bitfields options seems to have no
effect. Our original compiler version 4.7.2 seems to work correctly and
generates accesses to the bitfields based on their type. This is essentially
what the documentation for the 'strict-volatile-bitfields' says.
I have tested this with 4.8.2 and 4.8.3, too with the same result. The test
case demonstrates access to a 16-bit memory mapped peripheral register. It is
absolutely necessary that the register is always being written in 16-bit
quantities.
A simple testcase:
struct st_cmt0 {
union {
unsigned short WORD;
struct {
volatile unsigned short CKS:2;
volatile unsigned short :4;
volatile unsigned short CMIE:1;
volatile unsigned short :9;
} BIT;
} CMCR;
unsigned short CMCNT;
unsigned short CMCOR;
};
void test(volatile struct st_cmt0 *reg)
{
reg-CMCR.BIT.CMIE = 1;
}
The output for gcc 4.7.2 is:
.filetest.c
.section P,ax
.global_test
.type_test, @function
_test:
pushmr6-r11
add#-4, r0, r6
mov.Lr6, r0
mov.Lr1, [r6]
mov.L[r6], r11
mov.W[r11], r10 ; HONORS the 16-bit register size
bset#6, r10
mov.Wr10, [r11] ; HONORS the 16-bit register size
rtsd#28, r6-r11
.size_test, .-_test
.identGCC: (GNU) 4.7.2
The output for gcc 4.9.0 is:
.filetest.c
.section P,ax
.global_test
.type_test, @function
_test:
pushmr6-r11
add#-4, r0, r6
mov.Lr6, r0
mov.Lr1, [r6]
mov.L[r6], r11
mov.B[r11], r10 ; broken - reads only part of the register
bset#6, r10
mov.Br10, [r11] ; broken - writes only part of the register
rtsd#28, r6-r11
.size_test, .-_test
.identGCC: (GNU) 4.9.0
[Bug target/62180] (RX600) - compiler doesn't honor -fstrict-volatile-bitfields and generates incorrect machine code for I/O register access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62180 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords|wrong-code | Target|Renesas RX600 | Known to work|4.7.2 | Host|linux amd64 | Known to fail|4.9.0 | --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- C11 says something different here.
[Bug target/62180] (RX600) - compiler doesn't honor -fstrict-volatile-bitfields and generates incorrect machine code for I/O register access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62180 --- Comment #2 from Jan Čapek jan.capek at braiins dot cz --- (In reply to Andrew Pinski from comment #1) C11 says something different here. Can you be a bit more specific?
[Bug target/62180] (RX600) - compiler doesn't honor -fstrict-volatile-bitfields and generates incorrect machine code for I/O register access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62180 --- Comment #3 from Jan Čapek jan.capek at braiins dot cz --- (In reply to Andrew Pinski from comment #1) C11 says something different here. I can see the following the -fstrict-volatile-bitfields documentation: This option should be used if accesses to volatile bit-fields (or other structure fields, although the compiler usually honors those types anyway) should use a single access of the width of the field's type, aligned to a natural alignment if possible. And this is actually the case with gcc 4.7.2, it ignore the -fstrict option, and also doesn't need volatile on the individual bit-fields and it still generates correct code due to specifying the bitfield types.
[Bug lto/62179] undefined reference linking failure when combining extern template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62179 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-08-19 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Waiting for ... the bugreport? Testcase?
[Bug c++/62175] Internal compiler error in gimplify_modify_expr gimplify.c:4616
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62175 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-19 Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. Also takes 2gb of ram for building. Reducing.
[Bug c++/62181] New: [C/C++] Expected new warning: adding 'char' to a string does not append to the string [-Wstring-plus-int]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62181
Bug ID: 62181
Summary: [C/C++] Expected new warning: adding 'char' to a
string does not append to the string
[-Wstring-plus-int]
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org
CLANG warns for the following code, GCC doesn't (with the options tried):
foo.cc:4:24: warning: adding 'char' to a string does not append to the string
[-Wstring-plus-int]
const char *a = aa + 'a';
~^
foo.cc:4:24: note: use array indexing to silence this warning
const char *a = aa + 'a';
^
[]
1 warning generated.
Interestingly, the warning does not trigger for integer literals - only for
single-character literals and for long/int/char returning functions. That's
probably because abcd + 1 is the pointer address shifted by one, i.e.
pointing to bcd. One can also argue whether the note is helpful or not.
In the real-world code, the LHS was a string class and the conversion of aa
to the string class was missing such that the operator+ wasn't triggered.
Test case, gives three warnings (and three notes) with CLANG:
#include stdio.h
char bar() {
return 1;
}
int foobar() {
return 1;
}
int main() {
const char *a = aa + 'c';
const char *b = bb + bar();
const char *c = cc + foobar();
printf(%s, %s, %s\n, a, b, c);
return 0;
}
[Bug lto/62179] undefined reference linking failure when combining extern template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62179 --- Comment #2 from miles at gnu dot org --- Sorry, that got submitted accidentally (it turns out that RET in the web page Summary text-box is bound to submit!) I'm not sure how to delete a bogus report... ^^; Could you delete that? [I updated my copy of gcc and it seems the bug I was going to report _may_ have been fixed but I'm running into other problems so I'm not sure yet.] Thanks, -miles 2014年8月19日火曜日、rguenth at gcc dot gnu.orggcc-bugzi...@gcc.gnu.orgさんは書きました: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62179 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-08-19 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Waiting for ... the bugreport? Testcase? -- You are receiving this mail because: You reported the bug.
[Bug c/40989] -Werror= and #pragma diagnostics do not work with group flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40989 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Manuel López-Ibáñez manu at gcc dot gnu.org --- I consider this FIXED. Almost all options now work. The ones that don't are due to missing features in the *.opt files, which are tracked in PR53063.
[Bug c++/62182] New: New warning wished: operator== and equality comparison result unused [-Wunused-comparison]/-Wunsed-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62182
Bug ID: 62182
Summary: New warning wished: operator== and equality
comparison result unused
[-Wunused-comparison]/-Wunsed-value
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org
For a simple:
int i;
i == 5;
GCC diagnoses (but warning is enabled not by default):
warning: statement with no effect [-Wunused-value]
i == 7;
CLANG does the same (warning enabled by default):
warning: equality comparison result unused [-Wunused-comparison]
i == 7;
~~^~~~
note: use '=' to turn this equality comparison into an assignment
i == 7;
^~
=
However, in our code C++ code, we used an operator==. In that case, GCC doesn't
warn while Clang does (by default):
foo.cc:6:7: warning: equality comparison result unused [-Wunused-comparison]
str == bar;
^~~~
foo.cc:6:7: note: use '=' to turn this equality comparison into an assignment
str == bar;
^~
=
C++ test case:
#include stdio.h
#include string
int main() {
std::string str(init);
str == bar;
printf(%s\n, str.c_str());
return 0;
}
[Bug c/62183] New: [C/C++] Warning wished for !int_val == const / logical not is only applied to the left hand side of this comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62183
Bug ID: 62183
Summary: [C/C++] Warning wished for !int_val == const /
logical not is only applied to the left hand side of
this comparison
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org
That's a bug I tend to make from time to time (and usually spot it
immediately), it popped up also in our C++ code, and Coverity also had found
some instances in the GCC code.
Namely, using !a == b only rarely makes sense and usually should be a != b.
I didn't manage to get GCC to warn in this case while Clang warns by default.
For the code:
int foo(int i) {
if (!i == 5)
return 0;
else
return 1;
}
Clang prints:
foo.cc:2:7: warning: logical not is only applied to the left hand side of this
comparison [-Wlogical-not-parentheses]
if (!i == 5)
^ ~~
foo.cc:2:7: note: add parentheses after the '!' to evaluate the comparison
first
if (!i == 5)
^
( )
foo.cc:2:7: note: add parentheses around left hand side expression to silence
this warning
if (!i == 5)
^
( )
foo.cc:2:10: warning: comparison of constant 5 with expression of type 'bool'
is always false [-Wtautological-constant-out-of-range-compare]
if (!i == 5)
~~ ^ ~
2 warnings generated.
[Bug c/62184] New: [C/C++] Extend -Wempty-body to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62184 Bug ID: 62184 Summary: [C/C++] Extend -Wempty-body to Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org
[Bug c/62184] [C/C++] Extend -Wempty-body to 'while' loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62184
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
CC||mpolacek at gcc dot gnu.org
Summary|[C/C++] Extend -Wempty-body |[C/C++] Extend -Wempty-body
|to |to 'while' loops
--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org ---
For an empty if loop, GCC warns with -Wextra:
foo.cc:5:13: warning: suggest braces around empty body in an ‘if’ statement
[-Wempty-body]
if (bar());
^
However, using a while loop, it doesn't. Clang warns (by default) in that
case:
foo.cc:5:16: warning: while loop has empty body [-Wempty-body]
while (bar());
^
foo.cc:5:16: note: put the semicolon on a separate line to silence this warning
Again, I found that issue in a real-world code.
Test case:
int bar ();
void sleep();
int foo() {
while (bar());
sleep();
return 1;
}
[Bug c/62183] [C/C++] Warning wished for !int_val == const / logical not is only applied to the left hand side of this comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62183 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- I implemented -Wlogical-not-parentheses a while ago. It's not in -Wall yet though, see PR61271.
[Bug tree-optimization/62167] [tail-merge] dead type-unsafe load replaces type-safe load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62167 --- Comment #1 from vries at gcc dot gnu.org --- Created attachment 33360 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33360action=edit tentative patch, testing atm
[Bug tree-optimization/62167] [tail-merge] dead type-unsafe load replaces type-safe load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62167 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-08-19 Ever confirmed|0 |1
[Bug target/62178] [AArch64] Performance regression on matrix matrix multiply due to r211211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62178
bin.cheng amker.cheng at gmail dot com changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #3 from bin.cheng amker.cheng at gmail dot com ---
I think it's a flaw in iv candidates choosing algorithm revealed by my patch.
Though r211211 does change cost of addressing modes, it doesn't change the cost
of optimal candidate set. The problem with iv candidates choosing algorithm is
it's a heuristic one and would fail to find the optimal set for this specific
case.
In details, the only cost differences between r211210/r211211 is like below
***
*** 1,8
Use 1:
candcostcompl.depends on
! 11611
910
! 10411
1110
! 1250
! 14811
--- 1,8
Use 1:
candcostcompl.depends on
! 11311
910
! 10111
1110
! 1211
! 14511
The final candidates set choosed by r211210 is like below.
Initial set of candidates:
cost: 19 (complexity 2)
cand_cost: 10
cand_use_cost: 5 (complexity 2)
candidates: 11, 14
use:0 -- iv_cand:14, cost=(4,2)
use:1 -- iv_cand:11, cost=(1,0)
use:2 -- iv_cand:11, cost=(0,0)
invariants 1
Improved to:
cost: 15 (complexity 0)
cand_cost: 10
cand_use_cost: 2 (complexity 0)
candidates: 11, 13
use:0 -- iv_cand:13, cost=(1,0)
use:1 -- iv_cand:11, cost=(1,0)
use:2 -- iv_cand:11, cost=(0,0)
invariants 1
The final candidates set choosed by r211211 is like below.
Initial set of candidates:
cost: 17 (complexity 3)
cand_cost: 5
cand_use_cost: 9 (complexity 3)
candidates: 14
use:0 -- iv_cand:14, cost=(4,2)
use:1 -- iv_cand:14, cost=(5,1)
use:2 -- iv_cand:14, cost=(0,0)
It is clear, r211211 doesn't change the optimal candidates set (which is
13/11). It is the algorithm that can't find out the optimal set because it's
heuristic and would fail on this one.
With manual changes of candidates set, the diff of assembly code is like below.
*** 6,46
.typeIntmm, %function
Intmm:
moviv3.2s, 0
adrpx6, a+128
! adrpx8, r+128
! adrpx10, r+3848
! adrpx9, b+128
! adrpx7, b+248
addx6, x6, :lo12:a+128
! addx8, x8, :lo12:r+128
! addx10, x10, :lo12:r+3848
! addx9, x9, :lo12:b+128
! addx7, x7, :lo12:b+248
.L2:
! movx5, x8
! movx4, x8
! movx3, x9
.L4:
! strd3, [x4]
! addx2, x3, 3720
moviv0.2s, 0
movx1, x6
! movx0, x3
.L3:
! ldrd1, [x0]
! addx0, x0, 124
ld1r{v2.2s}, [x1], 4
! cmpx0, x2
mlav0.2s, v2.2s, v1.2s
bne.L3
! strd0, [x5], 8
addx3, x3, 8
! cmpx3, x7
! addx4, x4, 8
bne.L4
! addx8, x8, 124
addx6, x6, 124
! cmpx8, x10
bne.L2
ret
.sizeIntmm, .-Intmm
--- 6,42
.typeIntmm, %function
Intmm:
moviv3.2s, 0
+ adrpx4, r+128
adrpx6, a+128
! adrpx7, r+3848
! adrpx5, b
! addx4, x4, :lo12:r+128
addx6, x6, :lo12:a+128
! addx7, x7, :lo12:r+3848
! addx5, x5, :lo12:b
.L2:
! movx3, 0
.L4:
! strd3, [x4, x3]
! addx0, x3, 128
moviv0.2s, 0
+ addx2, x3, 3848
+ addx2, x2, x5
movx1, x6
! addx0, x5, x0
.L3:
! ldrd1, [x0], 124
ld1r{v2.2s}, [x1], 4
! cmpx2, x0
mlav0.2s, v2.2s, v1.2s
bne.L3
! strd0, [x4, x3]
addx3, x3, 8
! cmpx3, 120
bne.L4
! addx4, x4, 124
addx6, x6, 124
! cmpx4, x7
bne.L2
ret
.sizeIntmm, .-Intmm
You can see the inner most loop is back to optimized. The additinal
instruction in the second loop is caused by addressing mode change, but I think
it can be fixed by enabling auto-increment addressing mode for IVOPT on
aarch64. YES, we hasn't done that yet.
I will see how the IVOPT candidates choosing algorithm should be improved.
[Bug tree-optimization/62156] memcmp doesn't see through memcpy at compile-time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62156 --- Comment #5 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #4) Eventually worth fixing the libstdc++ side to generate better initial code? Replacing memcpy(,,3)+assign(,'\0') with memcpy(,,4) can indeed be done at the libstdc++ level (although simplify_builtin_call in tree-ssa-forwprop.c already does a transformation extremely similar and could be extended). As shown in comment #3, the test/jump will disappear when we move to C++11. But essentially, it can't avoid doing memcpy, setting the length of the string, and calling memcmp. One surprising thing it does not is, at the beginning of operator==, check if the sizes are the same before calling memcmp... Other than that it seems this would need careful special-handling in value-numbering ... That seems like the best place indeed. not sure if optimizing std::string(foo) == bar is important. The question is how many other optimizations this would enable. I remember other cases where we couldn't see through memcpy well enough (PR 58483 for instance, there were others probably more relevant), but I don't know if this would help them. In any case, I agree this isn't a priority.
[Bug tree-optimization/62156] memcmp doesn't see through memcpy at compile-time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62156 --- Comment #6 from rguenther at suse dot de rguenther at suse dot de --- On Tue, 19 Aug 2014, glisse at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62156 --- Comment #5 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #4) Eventually worth fixing the libstdc++ side to generate better initial code? Replacing memcpy(,,3)+assign(,'\0') with memcpy(,,4) can indeed be done at the libstdc++ level (although simplify_builtin_call in tree-ssa-forwprop.c already does a transformation extremely similar and could be extended). As shown in comment #3, the test/jump will disappear when we move to C++11. But essentially, it can't avoid doing memcpy, setting the length of the string, and calling memcmp. One surprising thing it does not is, at the beginning of operator==, check if the sizes are the same before calling memcmp... Other than that it seems this would need careful special-handling in value-numbering ... That seems like the best place indeed. not sure if optimizing std::string(foo) == bar is important. The question is how many other optimizations this would enable. I remember other cases where we couldn't see through memcpy well enough (PR 58483 for instance, there were others probably more relevant), but I don't know if this would help them. In any case, I agree this isn't a priority. The special thing with memcmp is that it evaluates to a value we'd like to compute while the usual look-through-memcpy is for value-numbering loads. So it won't be that easy... IMHO it would be nicer if we'd fix PR52171 which should be able to catch your simple case then via existing value-numbering code at least if the compare includes the trailing zero.
[Bug c/61271] 10 * possible coding error with logical not (!)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61271 --- Comment #12 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Tue Aug 19 11:35:39 2014 New Revision: 214142 URL: https://gcc.gnu.org/viewcvs?rev=214142root=gccview=rev Log: PR c/61271 * cgraphunit.c (handle_alias_pairs): Fix condition. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c
[Bug c/62141] [GCC-4.10.0][ASAN] ICE: Segmentation fault: 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62141 Yuri Gribov tetra2005 at gmail dot com changed: What|Removed |Added CC||tetra2005 at gmail dot com --- Comment #2 from Yuri Gribov tetra2005 at gmail dot com --- I couldn't repro with fresh trunk on x86_64-apple-darwin12.5.0 and x86_64-unknown-linux-gnu.
[Bug c++/62185] New: New warning for defined as a struct here but previously declared as a class / [-Wmismatched-tags]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62185
Bug ID: 62185
Summary: New warning for defined as a struct here but
previously declared as a class / [-Wmismatched-tags]
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
I am not really sure whether it's worthwhile, but browsing through the warnings
for our code, I found the following one by Clang, which GCC doesn't seem to
have:
foo.cc:5:1: warning: 'foo' defined as a struct here but previously declared as
a class [-Wmismatched-tags]
struct foo {
^
foo.cc:2:1: note: did you mean struct here?
class foo;
^
struct
Clang emits this warning with -Wall.
Test case:
// Assume some forward declaration in a header file
class foo;
// Assume a C file, #including the header file
struct foo {
int a;
};
[Bug c++/62185] New warning for defined as a struct here but previously declared as a class / [-Wmismatched-tags]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62185 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- This warning is useless and is a broken warning.
[Bug sanitizer/62089] Sanitizer may fail to instrument struct accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62089 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Yury Gribov y.gribov at samsung dot com --- Fixed.
[Bug sanitizer/61875] ATRIBUTE_NONNULL macro error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61875 Yuri Gribov tetra2005 at gmail dot com changed: What|Removed |Added CC||tetra2005 at gmail dot com --- Comment #5 from Yuri Gribov tetra2005 at gmail dot com --- Libsanitizer does not support building with -fexceptions. Patch was proposed in https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01764.html
[Bug debug/59051] DW_tag_restrict_type not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59051 --- Comment #2 from Mark Wielaard mark at gcc dot gnu.org --- Author: mark Date: Tue Aug 19 11:50:55 2014 New Revision: 214143 URL: https://gcc.gnu.org/viewcvs?rev=214143root=gccview=rev Log: Emit DW_tag_restrict_type for restrict-qualified pointers. gcc/ChangeLog PR debug/59051 * dwarf2out.c (modified_type_die): Handle TYPE_QUAL_RESTRICT. gcc/testsuite/ChangeLog PR debug/59051 * gcc.dg/guality/restrict.c: New test. Added: trunk/gcc/testsuite/gcc.dg/guality/restrict.c Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
[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 Yuri Gribov tetra2005 at gmail dot com changed: What|Removed |Added CC||jakub at redhat dot com, ||tetra2005 at gmail dot com --- Comment #3 from Yuri Gribov tetra2005 at gmail dot com --- This is probably duplicate of #61897 .
[Bug c++/62186] New: segfault on map.insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62186
Bug ID: 62186
Summary: segfault on map.insert
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: james1479 at gmail dot com
Getting a segfault on map.insert if called as a global initialiser from another
source file.
a.cpp
#include map
std::mapint, int m;
int g() {
m.insert( std::pairint,int(1,1) );
return 0;
}
main.cpp
int g(int i);
int a = g(1);
int main() { return 0; }
##
This code either works or segfaults depending on which order they are passed to
g++:
% g++ a.cpp main.cpp
% ./a.out
% g++ main.cpp a.cpp
% ./a.out
[1]9548 segmentation fault (core dumped) ./a.out
This also happens if they are compiled to .o files and linked together:
% g++ -c a.cpp
% g++ -c main.cpp
% g++ a.o main.o
% ./a.out
% g++ main.o a.o
% ./a.out
[1]10485 segmentation fault (core dumped) ./a.
The program works if compiled as a single source program.
Or if `int a = g(1);` is moved inside the main function.
Or if m.clear() is called before the insert.
g++ version (from archlinux repo):
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-4.9.1/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-cloog-backend=isl --disable-isl-version-check
--disable-cloog-version-check --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu --disable-multilib
--disable-werror --enable-checking=release
Thread model: posix
gcc version 4.9.1 (GCC)
[Bug lto/62179] undefined reference linking failure when combining extern template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62179 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID
[Bug libstdc++/62187] New: std::string==const char* could compare sizes first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62187 Bug ID: 62187 Summary: std::string==const char* could compare sizes first Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Hello, when I compare 2 basic_string with ==, libstdc++ only uses the optimization of first checking that the sizes are the same (before calling compare) if __is_char_CharT and the traits and allocator are the default ones. I don't understand why, but assuming there is a good reason, I believe the optimization should still apply when comparing std::string and const char*. (this applies to __vstring as well) This was noticed in PR 62156, where we also see that std::string(foo) does a memcpy of size 3 then sets the 4th char to '\0', where a single memcpy of size 4 would make sense.
[Bug libfortran/62188] New: Array bounds overrun in bessel_yn_r4/8/16 and other functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62188 Bug ID: 62188 Summary: Array bounds overrun in bessel_yn_r4/8/16 and other functions Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: vogt at linux dot vnet.ibm.com There's an array bounds overrun in gfortran/generated/bessel_r4.c:bessel_yn_r4(). The function is passed the arguments n1 and n2 (n1 = n2) and allocates memory for (n2 - n1 + 1) result values: size_t size = n2 n1 ? 0 : n2-n1+1; ... ret-base_addr = xmallocarray (size, sizeof (GFC_REAL_4)); But later on it writes from index 0 to n1 + n2: for (...; i = n1+n2; ...) ... ^ ret-base_addr[i*stride] = ...; The loop should be for (i = 2; i n2-n1; i++) instead. The same bug exists in bessel_r8.c and bessel_r16.c and has been present since at least gcc-4.8. The existing test cases (bessel_n.f90) all use 0 or low values 0, so they have not caught this bug yet.
[Bug c++/62150] [5.0 regression] test case g++.dg/ext/arm-fp16/fp16-mangle-1.C failed on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62150 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.8.3, 4.9.0, 4.9.1 Keywords||wrong-code Last reconfirmed||2014-08-19 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 Summary|test case |[5.0 regression] test case |g++.dg/ext/arm-fp16/fp16-ma |g++.dg/ext/arm-fp16/fp16-ma |ngle-1.C failed on ARM |ngle-1.C failed on ARM Known to fail||5.0 --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Confirmed.
[Bug c/45584] typeof with casting from const to non-const does not work properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45584 --- Comment #2 from ppalka at gcc dot gnu.org --- Author: ppalka Date: Tue Aug 19 14:14:15 2014 New Revision: 214151 URL: https://gcc.gnu.org/viewcvs?rev=214151root=gccview=rev Log: 2014-08-19 Patrick Palka ppa...@gcc.gnu.org PR c/45584 * c-typeck.c (build_c_cast): Do a conversion even when the TYPE_MAIN_VARIANTs are the same. 2014-08-19 Patrick Palka ppa...@gcc.gnu.org PR c/45584 * gcc.dg/pr13519-1.c: Adjust. Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr13519-1.c
[Bug tree-optimization/62091] [5 Regression] ice in before_dom_children
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62091 --- Comment #7 from David Binderman dcb314 at hotmail dot com --- I am not sure this is fixed. Attached code, when compiled by 20140817, with flags -std=gnu++11 -O2, does the following $ ../results/bin/gcc -c -std=gnu++11 -O2 bug161.cc listformatter.cpp: In member function ‘icu_53::UnicodeString icu_53::ListFormatter::format(const icu_53::UnicodeString*, int32_t, icu_53::UnicodeString, int32_t, int32_t, UErrorCode) const’: listformatter.cpp:304:16: internal compiler error: in before_dom_children, at tree-ssa-pre.c:4410 0xbecf2c eliminate_dom_walker::before_dom_children(basic_block_def*) ../../src/trunk/gcc/tree-ssa-pre.c:4410 0xf72c67 dom_walker::walk(basic_block_def*) ../../src/trunk/gcc/domwalk.c:177 0xbe9fd2 eliminate ../../src/trunk/gcc/tree-ssa-pre.c:4525 0xbeb1dc execute ../../src/trunk/gcc/tree-ssa-pre.c:4940 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 tree-optimization/55334] [4.8/4.9/5 Regression] mgrid regression (ipa-cp disables vectorization)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 vp at gcc dot gnu.org changed: What|Removed |Added CC||vp at gcc dot gnu.org --- Comment #37 from vp at gcc dot gnu.org --- I see this issue in AArch64 as well on 4.9 branch and on the trunk causing performance regression. Since MG3P is inlined at MAIN__, all the four calls to RESID are in MAIN__. Two of which are to the clone resid_.constprop.1 (not vectorized) and one to resid_ (vectorized) and the last one inlined (not vectorized and it looks very similar to the resid_.constprop.1 version). I could however, improve by passing -fno-inline-functions and -fno-ipa-cp at -Ofast (so that all the calls are to resid_ which gets vectorized). Anyone working on this issue?
[Bug c++/62186] segfault on map.insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62186 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- The order outside translation units of initialization is unspecified in c++.
[Bug other/62168] error in configure: line 21572: test: =: unary operator expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62168 --- Comment #9 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org --- Author: hjl Date: Tue Aug 19 16:23:36 2014 New Revision: 214168 URL: https://gcc.gnu.org/viewcvs?rev=214168root=gccview=rev Log: Set install_gold_as_default to no first PR other/62168 * configure.ac: Set install_gold_as_default to no first. * configure: Regenerated. Modified: trunk/gcc/ChangeLog trunk/gcc/configure trunk/gcc/configure.ac
[Bug debug/61033] [4.8/4.9 Regression] Infinite loop in variable tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61033 David Binderman dcb314 at hotmail dot com changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #8 from David Binderman dcb314 at hotmail dot com --- Created attachment 33361 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33361action=edit C++ source code
[Bug tree-optimization/62091] [5 Regression] ice in before_dom_children
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62091 --- Comment #8 from David Binderman dcb314 at hotmail dot com --- Created attachment 33362 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33362action=edit C++ source code
[Bug target/62180] (RX600) - compiler doesn't honor -fstrict-volatile-bitfields and generates incorrect machine code for I/O register access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62180 DJ Delorie dj at redhat dot com changed: What|Removed |Added CC||dj at redhat dot com --- Comment #4 from DJ Delorie dj at redhat dot com --- Perhaps you need this patch: https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00993.html
[Bug debug/61033] [4.8/4.9 Regression] Infinite loop in variable tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61033 --- Comment #9 from David Binderman dcb314 at hotmail dot com --- (In reply to David Binderman from comment #8) Created attachment 33361 [details] C++ source code Please ignore this attachment. It is for a different bug.
[Bug libfortran/62188] Array bounds overrun in bessel_yn_r4/8/16 and other functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62188
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-08-19
CC||kargl at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from kargl at gcc dot gnu.org ---
Confirmed. I assume you found this by using a libc with
a malloc that has buffer overflow detection. The obvious
patch is
Index: m4/bessel.m4
===
--- m4/bessel.m4(revision 213593)
+++ m4/bessel.m4(working copy)
@@ -163,7 +163,7 @@ bessel_yn_r'rtype_kind` ('rtype` * const
x2rev = GFC_REAL_'rtype_kind`_LITERAL(2.)/x;
- for (i = 2; i = n1+n2; i++)
+ for (i = 2; i = n2 - n1; i++)
{
#if defined('rtype_name`_INFINITY)
if (unlikely (last2 == -'rtype_name`_INFINITY))
I'll commit this later.
[Bug c/45584] typeof with casting from const to non-const does not work properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45584 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Should be fixed now.
[Bug ipa/61659] [4.9/5 Regression] Extra undefined symbol because of devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61659 --- Comment #22 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Aug 19 17:29:41 2014 New Revision: 214177 URL: https://gcc.gnu.org/viewcvs?rev=214177root=gccview=rev Log: PR lto/53808 PR c++/61659 * decl.c (maybe_commonize_var): Don't use DECL_COMDAT to trigger comdat_linkage. Added: trunk/gcc/testsuite/g++.dg/abi/spec1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c
[Bug lto/53808] Undefined symbol when building a library with lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53808 --- Comment #15 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Aug 19 17:29:41 2014 New Revision: 214177 URL: https://gcc.gnu.org/viewcvs?rev=214177root=gccview=rev Log: PR lto/53808 PR c++/61659 * decl.c (maybe_commonize_var): Don't use DECL_COMDAT to trigger comdat_linkage. Added: trunk/gcc/testsuite/g++.dg/abi/spec1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c
[Bug c++/62189] New: Different result between 4.6 and 4.9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62189
Bug ID: 62189
Summary: Different result between 4.6 and 4.9.1
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pangbw at gmail dot com
For this program, I get different result for G++ 4.6.3 and G++ 4.9.1, and I
have a C++ test suite which thinks 4.6.3 is right:
#include functional
#include iostream
int (*pfb_)() = nullptr;
int main()
{
std::function int() e (pfb_);
std::cout !!e std::endl;
return 0;
}
For 4.6.3 the output is 1 but for 4.9.1 the output is 0.
[Bug lto/62190] New: LTO DWARF produces __unknown__ type for unsigned int function argument type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62190
Bug ID: 62190
Summary: LTO DWARF produces __unknown__ type for unsigned int
function argument type
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: mark at gcc dot gnu.org
Take the following program:
/* LTO sometimes outputs __unknown__ for an unsigned int argument type. */
/* { dg-do run } */
/* { dg-options -gdwarf } */
static __attribute__((noclone, noinline)) int
func (unsigned int n)
{
return (int) n;
}
int
main (int argc, char **argv)
{
return func (0);
}
/* { dg-final { gdb-test 12 type:func int (unsigned int) } } */
And compile it with /opt/local/build/gcc-obj/gcc/xgcc
-B/opt/local/build/gcc-obj/gcc/ ltounsignedint.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none -g -o ./ltounsignedint.exe
Or just drop it in gcc/testsuite/gcc.dg/guality/ltounsignedint.c and run make
check-c RUNTESTFLAGS=guality.exp=ltounsignedint.c
Notice how the formal_parameter n gets a type with name __unknown__:
[46] formal_parameter
name (string) n
decl_file(data1) 1
decl_line(data1) 6
type (ref4) [59]
location (exprloc)
[ 0] reg5
[59]base_type
byte_size(data1) 4
encoding (data1) unsigned (7)
name (strp) __unknown__
[Bug target/62191] New: extra shift generated for vector integer division by constant 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62191
Bug ID: 62191
Summary: extra shift generated for vector integer division by
constant 2
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: spatel at rotateright dot com
Using gcc 4.9:
$ cat sdiv.c
typedef int vecint __attribute__((vector_size(16)));
vecint f(vecint x) {
return x/2;
}
$ gcc -O2 sdiv.c -S -o -
...
movdqa%xmm0, %xmm1
psrad$31, %xmm1--- splat the sign bit
psrld$31, %xmm1--- then shift sign bit down to LSB
paddd%xmm1, %xmm0 --- add sign bit to quotient
psrad$1, %xmm0 --- div via alg shift right
ret
--
I don't think the first shift right algebraic is necessary. We splat the sign
bit and then shift that right logically, so the upper bits are all zero'd
anyway.
This is a special case for signed integer division by 2. You need that first
'psrad' for any other power of 2 because the subsequent logical shift would not
also be a shift of 31.
[Bug tree-optimization/62091] [5 Regression] ice in before_dom_children
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62091 --- Comment #9 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Aug 19 18:25:45 2014 New Revision: 214181 URL: https://gcc.gnu.org/viewcvs?rev=214181root=gccview=rev Log: PR tree-optimization/62091 * decl2.c (decl_needed_p): Return true for virtual functions when devirtualizing. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/testsuite/g++.dg/ipa/devirt-38.C
[Bug tree-optimization/62091] [5 Regression] ice in before_dom_children
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62091 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #10 from Jason Merrill jason at gcc dot gnu.org --- My patch doesn't fix the ICE in comment 7, just devirtualization on devirt-38.C.
[Bug c++/62192] New: Segmentation fault when linking with Qt libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62192
Bug ID: 62192
Summary: Segmentation fault when linking with Qt libraries
Product: gcc
Version: 4.7.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lakjdsfiudslkfj at mailinator dot com
Created attachment 33363
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33363action=edit
gdb backtrace
Hi,
I'm currently having some difficulties linking to my library when my main
executable is linked with some Qt libraries. I'm running FreeBSD 10 and gcc47
but the latest 410 package for FreeBSD exhibits the same behavior.
My main.cc looks like this:
---
#include foo.h
int main() {
foo();
}
---
My library libfoo consists of a file foo.cc:
---
#include string
#include iostream
void foo() {
std::string lol = test;
std::cout lol std::endl;;
}
---
foo.h for completeness:
--
void foo();
--
and is compiled via
g++ -g -c -fPIC foo.cc -o libfoo.o
g++ -shared -fPIC libfoo.o -o libfoo.so
After this my main.cc is compiled/linked:
g++ -g -O0 -I/tmp/delme2 -DQT_SHARED -I/usr/local/include/qt4
-I/usr/local/include/qt4/QtCore -L/usr/local/lib/qt4 -lQtCore -L/tmp/delme2
-lfoo main.cc
running a.out yields segmentation fault (core dumped) ./a.out
with clang++ -g -O0 -I/tmp/delme2 -DQT_SHARED -I/usr/local/include/qt4
-I/usr/local/include/qt4/QtCore -L/usr/local/lib/qt4 -lQtCore -L/tmp/delme2
-lfoo main.cc
the output is test as expected.
It also works when I remove the Qt libraries, i.e.
g++ -g -O0 -I/usr/local/include -I/tmp/delme2 -L/tmp/delme2 -lfoo main.cc
Am I doing something wrong here? Is it a Qt problem rather than gcc? But why
does it work with clang then? I attached a GDB backtrace just in case.
[Bug c++/62153] warn for bool expression compared with integer different from 0/1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62153 --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Tue Aug 19 18:50:00 2014 New Revision: 214183 URL: https://gcc.gnu.org/viewcvs?rev=214183root=gccview=rev Log: PR c++/62153 * doc/invoke.texi: Document -Wbool-compare. c-family/ * c-common.c (maybe_warn_bool_compare): New function. * c-common.h (maybe_warn_bool_compare): Declare. * c.opt (Wbool-compare): New option. c/ * c-typeck.c (build_binary_op): If either operand of a comparison is a boolean expression, call maybe_warn_bool_compare. cp/ * call.c (build_new_op_1): Remember the type of arguments for a comparison. If either operand of a comparison is a boolean expression, call maybe_warn_bool_compare. testsuite/ * c-c++-common/Wbool-compare-1.c: New test. Added: trunk/gcc/testsuite/c-c++-common/Wbool-compare-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/c-family/c-common.h trunk/gcc/c-family/c.opt trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug ada/62193] New: There is a bug in the Ada runtime which causes some Ada time functions to fail on the MinGW 32-bit platform .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62193 Bug ID: 62193 Summary: There is a bug in the Ada runtime which causes some Ada time functions to fail on the MinGW 32-bit platform . Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: jdgress...@amli-denton.com Created attachment 33364 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33364action=edit A patch which corrects a problem that occurs in 32-bit Windows Ada when the compiler is built with a C runtime with a 64-bit time_t type There is a bug in the gcc Ada runtime which causes some routines in the Ada.Calendar runtime package (and its child packages) to produce incorrect results on the MinGW 32-bit Windows platform. I found the bug when using the V4.8.1 MinGW Windows 32-bit, but it is a long-standing bug that still exists in later releases. This can be demonstrated with the following Ada program when it is compiled with the MinGW 32-bit 4.8.1 compiler: with Ada.Calendar, Ada.Text_IO; use Ada.Calendar, Ada.Text_IO; procedure Simple_BugTest is Test_Date: Time; YN: Year_number; MN: Month_Number; DN: Day_Number; SN: Day_Duration; ISN: Integer; begin Test_Date := Time_Of(2013, 10, 3); Split(Test_Date, YN, MN, DN, SN); ISN := Integer(SN); Put_Line(Time_Of(2013, 10, 3) is ); Put(Year: Integer'Image(YN)); Put(, Month: Integer'Image(MN)); Put(, Day: Integer'Image(DN)); Put_Line(, Seconds: Integer'Image(ISN)); end Simple_BugTest; When compiled with the MinGW 4.8.1-4 Ada compiler, which uses the MinGW 4.0.3-1 runtime package, this produces the following incorrect output: Time_Of(2013, 10, 3) is Year: 2013, Month: 9, Day: 29, Seconds: 68327 When compiled with an Ada runtime patch which corrects the problem, the output becomes: Time_Of(2013, 10, 3) is Year: 2013, Month: 10, Day: 3, Seconds: 0 which is correct. The bug which causes the problem is in the Ada runtime library source code, found in the gcc/ada subdirectory of the compiler source. It is caused by an incorrect assumption about time types which is embedded in the Ada and C source code files in the gcc/ada subdirectory. The Ada calendar routines define the Ada version of the time_t type as type time_t is range -(2 (Standard'Address_Size - Integer'(1))) .. +(2 (Standard'Address_Size - Integer'(1)) - 1); The key item here is the Ada expression Standard'Address_Size The MinGW Ada compiler is a 32-bit compiler. The result is that the Ada time_t is a 32-bit signed integer type. A value of this type is passed to the C procedure __gnat_localtime_tzoff which is in a C file named sysdep.c in the Ada runtime source code directory. In the C code, the receiving argument of this Ada time_t type is a C time_t type, the first argument of __gnat_localtime_tzoff, declared as: const time_t *timer This is where the trouble starts. When the C time_t is a 64-bit type, the value passed into __gnat_localtime_tzoff contains the Ada time_t value as 32 bits of a 64-bit value, and the other 32 bits are nonsense. In short, the Ada runtime library code is assuming that Ada Standard'Address_Size and C sizeof(time_t) are always the same value. The V4 release of the MinGW runtime has broken that assumption. The patch works by defining a new time type for use in the __gnat_localtime_tzoff function: ada_time_t. This new type is based on the existing type intptr_t found in stdint.h and is defined by the patch as typedef intptr_t ada_time_t; The offending time declaration is in the first argument of __gnat_localtime_tzoff: void __gnat_localtime_tzoff (const time_t timer, const int is_historic, long *off) The patch corrects that to void __gnat_localtime_tzoff (const ada_time_t ada_timer, const int is_historic, long *off) The patch defines a new local variable in __gnat_localtime_tzoff: time_t timer; The local variable is then initialized: timer = (time_t) *ada_timer; This line is where the bug is actually fixed. The 32-bit Ada time type is properly extended to a 64-bit type, but it would just be a trivial copy when compiled by a 64-bit compiler. The new local variable timer then replaces all instances of *timer in the body of the function __gnat_localtime_tzoff. Note that a patch like this would work on any 32-bit platform which introduced a new 64-bit time_t type in its C runtime. That is why I did not base ada_time_t on a Windows-specific type. The patch is in the attachment.
[Bug c++/62153] warn for bool expression compared with integer different from 0/1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62153 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- -Wbool-compare has been added.
[Bug rtl-optimization/62151] [5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org --- I will try to test a patch, meanwhile, I am wondering if any combine expert has something to share. distribute_notes is certainly an endless source of bugs. BTW, combine pass seems to be another ad-hoc implementation like reload, I saw several Don't know in comments during this investigation! You would need to define what an ad-hoc implementation is exactly. See the top of the file for the origin of the pass.
[Bug c++/62189] Different result between 4.6 and 4.9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62189 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com --- You need to change your expected outcome of your test-suite. According to the C++ standard, the expected outcome is 0. As of [func.wrap.func.con] p9: Postconditions: !*this if any of the following hold: — f is a null function pointer value. [..] Therefore, gcc 4.9.1 is right.
[Bug c/62194] New: Add deadfield attribute to ignore initializers for a structure field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62194
Bug ID: 62194
Summary: Add deadfield attribute to ignore initializers for a
structure field
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: josh at joshtriplett dot org
This request is the result of a discussion at Kernel Summit 2014, about
handling conditional code without massive transitions or excessive preprocessor
abuse.
Frequently, a structure will have a field that is only used with specific
configurations. For instance, a driver may have an ops structure with
suspend/resume methods, but those methods will only be called if the kernel
configuration supports suspend/resume. If we configure suspend/resume out of
the kernel, nothing will call or otherwise read foo-suspend(...). However,
drivers will still have designated assignments to that structure field:
struct something_ops {
...
.suspend = foo_suspend,
.resume = foo_resume,
...
}
Currently, this has to work in one of two ways: either the structure fields
unconditionally exist in all cases so that the designated assignments don't
break (keeping a reference to the functions and preventing them from being
compiled out), or the structure field and corresponding designated assignments
must be #ifdef'd out (requiring a massive transition and a pile of ugly
preprocessor directives proportional to the number of structures).
Discussion at Kernel Summit came up with the following alternative:
Create a new attribute deadfield. A field with that attribute is not
actually included in the layout of the structure. Writes or designated
assignments to the field get ignored. Attempting to read from the field
produces an error. Values assigned to dead fields are treated as
__attribute__((unused)).
That would then allow definitions of instances of the structure to remain
unmodified in all configurations.
Optionally, the deadfield attribute could take a single parameter, which is a
constant value to substitute for any read from the field rather than producing
an error. For instance, a function pointer field may have a do-nothing stub
function (which GCC can then inline and turn into no code), or a flag field may
have a constant value (allowing subsequent constant-folding).
I'm willing to work on a patch for this.
[Bug c++/62153] warn for bool expression compared with integer different from 0/1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62153 --- Comment #8 from Franz Sirl sirl at gcc dot gnu.org --- Hmm, what about the assignment part of the merged bug 44077: _Bool var = 3; Does the fix warn about this? Should I create a new bug report for this part?
[Bug fortran/61847] bug in gfortran runtime: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #19 from Janne Blomqvist jb at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #17) I have a patch in the works. The idea is to query the locale at the time the Unit is connected and save the LC_NUMERIC character in the unit structure. Then, if the decimal character matches the DECIMAL_STATUS (decimal=point or decimal=comma) active at the time of reading, change the decimal character internally to the current locale character previously saved. This way, only one call to locale is needed per unit connection, preserving efficiency. The real string will then be converted correctly, regardless of locale. While clever, I'm not sure this approach works. A program can change the locale between opening the file and reading from it (potentially in another thread, since the locale is a process-wide property). What can be done instead is to use the POSIX 2008 extended locale functionality (newlocale) to create a locale object in the default C locale and then use functions like strtod_l (for some reason not in POSIX 2008, though at least glibc and BSD/OSX have it, IIRC) that take such a locale object as argument. This is fairly new though and not available everywhere, but ought to be robust. See also PR 47007. As an aside, AFAIK the C and POSIX locales are the same, just two names for the same thing. C might be more portable, as that should work everywhere there is a C implementation.
[Bug target/62195] New: [5 Regression] Invalid mnemonic 'xxlxor' on powerpc-apple-darwin9 with -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62195 Bug ID: 62195 Summary: [5 Regression] Invalid mnemonic 'xxlxor' on powerpc-apple-darwin9 with -m64 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: iains at gcc dot gnu.org, meissner at gcc dot gnu.org, segher at gcc dot gnu.org Host: powerpc-apple-darwin9 Target: powerpc-apple-darwin9 Build: powerpc-apple-darwin9 Between revisions r213754 (no error) and r214053 I get the following failures on powerpc-apple-darwin9 with -m64: Running target unix/-m64 FAIL: gcc.c-torture/compile/920501-15.c -O1 (test for excess errors) FAIL: gcc.c-torture/compile/920501-15.c -O2 (test for excess errors) FAIL: gcc.c-torture/compile/920501-15.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/920501-15.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/920501-15.c -Os (test for excess errors) FAIL: gcc.c-torture/compile/920501-15.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: gcc.c-torture/compile/920501-15.c -O2 -flto (test for excess errors) FAIL: gcc.c-torture/compile/920928-2.c -O1 (test for excess errors) FAIL: gcc.c-torture/compile/920928-2.c -O2 (test for excess errors) FAIL: gcc.c-torture/compile/920928-2.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/920928-2.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gcc.c-torture/compile/920928-2.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gcc.c-torture/compile/920928-2.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/920928-2.c -Os (test for excess errors) FAIL: gcc.c-torture/compile/920928-2.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: gcc.c-torture/compile/920928-2.c -O2 -flto (test for excess errors) FAIL: gcc.c-torture/compile/pr34091.c -O1 (test for excess errors) FAIL: gcc.c-torture/compile/pr34091.c -O2 (test for excess errors) FAIL: gcc.c-torture/compile/pr34091.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/pr34091.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gcc.c-torture/compile/pr34091.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gcc.c-torture/compile/pr34091.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/pr34091.c -Os (test for excess errors) FAIL: gcc.c-torture/compile/pr34091.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: gcc.c-torture/compile/pr34091.c -O2 -flto (test for excess errors) The errors are of the kind /var/tmp//ccPo810U.s:8:Invalid mnemonic 'xxlxor' and require -On and -m64 with n0.
[Bug target/62195] [5 Regression] Invalid mnemonic 'xxlxor' on powerpc-apple-darwin9 with -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62195 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-08-19 Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Following the thread on IRC makers as ASSIGNED to meiss...@gcc.gnu.org.
[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Attachment #33349|0 |1 is obsolete|| --- Comment #26 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Created attachment 33365 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33365action=edit Better reduced testcase
[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #27 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Thanks. This seems to be a conjunction of several factors, the initial one being that the 4.8+ compiler generates (e.g for the reduced testcase at -O): addl r14 = @ltoffx(_rtld_local#+15032385536), r1 ;; ld8.mov r14 = [r14], _rtld_local#+15032385536 The huge number is not problematic per se, although it very likely runs afoul of some limitation/quirk here, since the value loaded from the GOT is truncated. In fact it looks like the value loaded from the GOT is just the huge number, that is to say the value of _rtld_local has been zeroed during the relocation. This may come from _rtld_local being in the .sdata section, in which case there is a relevant comment in sdata_symbolic_operand: /* Deny the stupid user trick of addressing outside the object. Such things quickly result in GPREL22 relocation overflows. Of course, they're also highly undefined. From a pure pedant's point of view they deserve a slap on the wrist (such as provided by a relocation overflow), but that just leads to bugzilla noise. */ In other words, the compiler skips the efficient @gprel relocation on purpose, only to generate the @ltoffx relocation, which doesn't work either here...
[Bug preprocessor/60975] -Wvariadic-macros does not print warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60975 --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Author: manu Date: Tue Aug 19 22:37:49 2014 New Revision: 214200 URL: https://gcc.gnu.org/viewcvs?rev=214200root=gccview=rev Log: gcc/ChangeLog: 2014-08-20 Manuel López-Ibáñez m...@gcc.gnu.org PR c/60975 PR c/53063 * doc/options.texi (CPP): Document it. * doc/invoke.texi (Wvariadic-macros): Fix documentation. * optc-gen.awk: Handle CPP. * opth-gen.awk: Likewise. gcc/c-family/ChangeLog: 2014-08-20 Manuel López-Ibáñez m...@gcc.gnu.org PR c/60975 PR c/53063 * c.opt (Wvariadic-macros): Use CPP and LangEnabledBy. * c-opts.c (c_common_handle_option): Call cpp_handle_option_auto. (c_common_post_options): Call init_global_opts_from_cpp. (sanitize_cpp_opts): Do not handle Wvariadic-macros here. gcc/testsuite/ChangeLog: 2014-08-20 Manuel López-Ibáñez m...@gcc.gnu.org PR c/60975 PR c/53063 * gcc.dg/cpp/Wvariadic-1p.c: New test. Added: trunk/gcc/testsuite/gcc.dg/cpp/Wvariadic-1p.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-opts.c trunk/gcc/c-family/c.opt trunk/gcc/doc/invoke.texi trunk/gcc/doc/options.texi trunk/gcc/optc-gen.awk trunk/gcc/opth-gen.awk trunk/gcc/testsuite/ChangeLog
[Bug c/53063] encode group options in the .opt files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53063 --- Comment #10 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Author: manu Date: Tue Aug 19 22:37:49 2014 New Revision: 214200 URL: https://gcc.gnu.org/viewcvs?rev=214200root=gccview=rev Log: gcc/ChangeLog: 2014-08-20 Manuel López-Ibáñez m...@gcc.gnu.org PR c/60975 PR c/53063 * doc/options.texi (CPP): Document it. * doc/invoke.texi (Wvariadic-macros): Fix documentation. * optc-gen.awk: Handle CPP. * opth-gen.awk: Likewise. gcc/c-family/ChangeLog: 2014-08-20 Manuel López-Ibáñez m...@gcc.gnu.org PR c/60975 PR c/53063 * c.opt (Wvariadic-macros): Use CPP and LangEnabledBy. * c-opts.c (c_common_handle_option): Call cpp_handle_option_auto. (c_common_post_options): Call init_global_opts_from_cpp. (sanitize_cpp_opts): Do not handle Wvariadic-macros here. gcc/testsuite/ChangeLog: 2014-08-20 Manuel López-Ibáñez m...@gcc.gnu.org PR c/60975 PR c/53063 * gcc.dg/cpp/Wvariadic-1p.c: New test. Added: trunk/gcc/testsuite/gcc.dg/cpp/Wvariadic-1p.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-opts.c trunk/gcc/c-family/c.opt trunk/gcc/doc/invoke.texi trunk/gcc/doc/options.texi trunk/gcc/optc-gen.awk trunk/gcc/opth-gen.awk trunk/gcc/testsuite/ChangeLog
[Bug preprocessor/60975] -Wvariadic-macros does not print warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60975 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org --- FIXED in GCC 5.0
[Bug preprocessor/51303] -Wmissing-include-dirs warnings reported as [enabled by default]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51303 --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Author: manu Date: Tue Aug 19 22:52:02 2014 New Revision: 214201 URL: https://gcc.gnu.org/viewcvs?rev=214201root=gccview=rev Log: gcc/ChangeLog: 2014-08-20 Manuel López-Ibáñez m...@gcc.gnu.org PR preprocessor/51303 * incpath.c (remove_duplicates): Use cpp_warning. gcc/c-family/ChangeLog: 2014-08-20 Manuel López-Ibáñez m...@gcc.gnu.org PR preprocessor/51303 * c-common.c (struct reason_option_codes_t option_codes): Add CPP_W_MISSING_INCLUDE_DIRS. Sort alphabetically. gcc/testsuite/ChangeLog: 2014-08-20 Manuel López-Ibáñez m...@gcc.gnu.org PR preprocessor/51303 * gcc.dg/cpp/Wmissingdirs.c: Test for the warning option. Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/incpath.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/cpp/Wmissingdirs.c
[Bug preprocessor/51303] -Wmissing-include-dirs warnings reported as [enabled by default]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51303 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- FIXED for GCC 5.0
[Bug c++/62196] New: running time segment fault with valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62196
Bug ID: 62196
Summary: running time segment fault with valarray
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pangbw at gmail dot com
The code would segment fault at running time, I see the same result with G++
4.6.3(which comes with Ubuntu 12.04) and 4.9.1:
#include iostream
#include valarray
int main(int argc, char *argv[])
{
const char vl[] = {abcdefghijklmnopqrstuvwxyz};
const char vu[] = {ABCDEFGHIJKLMNOPQRSTUVWXYZ};
const std::valarraychar v0(vl, 27), vm6(vu, 6);
const bool vb[] = {false, false, true, true, false, true};
const std::valarraybool vmask(vb, 6);
std::valarraychar x = v0;
for(int i = 0; i x.size(); i++)
std::cout x[i];
std::cout std::endl;
x[vmask] = vm6;
for(int i = 0; i x.size(); i++)
std::cout x[i];
std::cout std::endl;
return 0;
}
The command line is just simply as:
g++ -std=c++0x x.cpp
[Bug c++/60417] [DR 1518] Bogus error on C++03 aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60417 --- Comment #9 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Aug 20 01:16:31 2014 New Revision: 214205 URL: https://gcc.gnu.org/viewcvs?rev=214205root=gccview=rev Log: PR c++/60417 * init.c (build_vec_init): Set CONSTRUCTOR_IS_DIRECT_INIT on init-list for trailing elements. * typeck2.c (process_init_constructor_array): Likewise. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/init/explicit2.C Modified: branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/init.c branches/gcc-4_9-branch/gcc/cp/typeck2.c
[Bug c++/61566] [4.9/4.10 Regression] ICE in write_unscoped_name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61566 --- Comment #11 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Aug 20 01:17:37 2014 New Revision: 214206 URL: https://gcc.gnu.org/viewcvs?rev=214206root=gccview=rev Log: PR c++/61566 * pt.c (instantiate_class_template_1): Ignore lambda on CLASSTYPE_DECL_LIST. (push_template_decl_real): A lambda is not primary. * lambda.c (maybe_add_lambda_conv_op): Distinguish between being currently in a function and the lambda living in a function. Modified: branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/lambda.c branches/gcc-4_9-branch/gcc/cp/pt.c branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template13.C
[Bug c++/61566] [4.9/4.10 Regression] ICE in write_unscoped_name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61566 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED Target Milestone|4.9.1 |4.9.2 --- Comment #12 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 4.9.2.
[Bug tree-optimization/62091] [5 Regression] ice in before_dom_children
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62091 --- Comment #11 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Aug 20 01:54:40 2014 New Revision: 214208 URL: https://gcc.gnu.org/viewcvs?rev=214208root=gccview=rev Log: PR c++/61214 PR tree-optimization/62091 * decl2.c (decl_needed_p): Return true for virtual functions when devirtualizing. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ipa/devirt-39.C Modified: branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/decl2.c
[Bug c++/61214] [4.9/5 regression] Weird interaction between -fvisibility-inlines-hidden, inline virtuals and devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61214 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Aug 20 01:54:40 2014 New Revision: 214208 URL: https://gcc.gnu.org/viewcvs?rev=214208root=gccview=rev Log: PR c++/61214 PR tree-optimization/62091 * decl2.c (decl_needed_p): Return true for virtual functions when devirtualizing. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ipa/devirt-39.C Modified: branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/decl2.c
[Bug tree-optimization/62091] [5 Regression] ice in before_dom_children
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62091 --- Comment #12 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Aug 20 02:03:56 2014 New Revision: 214209 URL: https://gcc.gnu.org/viewcvs?rev=214209root=gccview=rev Log: PR tree-optimization/62091 * g++.dg/ipa/devirt-39.C: New. Added: trunk/gcc/testsuite/g++.dg/ipa/devirt-39.C
[Bug c++/61214] [4.9/5 regression] Weird interaction between -fvisibility-inlines-hidden, inline virtuals and devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61214 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 4.9.2 and trunk.
[Bug target/62111] ICE when building Linux kernel for sh64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111 Segher Boessenkool segher at gcc dot gnu.org changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #11 from Segher Boessenkool segher at gcc dot gnu.org --- Re: #c7: In sh.c, change char amount[6] to signed char amount[6] -- does that help?
[Bug rtl-optimization/62151] [5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151 --- Comment #9 from amker at gcc dot gnu.org --- (In reply to Eric Botcazou from comment #8) I will try to test a patch, meanwhile, I am wondering if any combine expert has something to share. distribute_notes is certainly an endless source of bugs. One patch is sent at https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01718.html It's a scratch patch for discussion's purpose. Though I think it's right to find distribution place for REG_DEAD note starting from i2 if it kills the register, I am not sure if it's fixing the issue in a case by case manner. So it's highly appreciated if any expert in this area can share some opinions, or review the patch? BTW, combine pass seems to be another ad-hoc implementation like reload, I saw several Don't know in comments during this investigation! You would need to define what an ad-hoc implementation is exactly. See the top of the file for the origin of the pass. Err, I may used the wrong word. These are just frustrating words after seeing several Don't know comments in the code. Please ignore them. Thanks.
[Bug lto/62032] FAIL: vsnprintf-chk.c execution, -O2 -flto -fno-use-linker-plugin -flto-partition=none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62032 amker at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from amker at gcc dot gnu.org --- Closing.
[Bug c/62197] New: Option -Bprefix does not affect the search for the assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62197
Bug ID: 62197
Summary: Option -Bprefix does not affect the search for the
assembler
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: r.berber at computer dot org
A simple example showing the problem:
$ uname -a
Linux DiskStation 3.2.40 #4493 SMP Wed Jul 9 21:14:19 CST 2014 x86_64 GNU/Linux
$ gcc -dumpversion
4.9.1
$ echo 'main(){}' dummy.c
$ strace gcc -B/opt/src/binutils-build/ld/tmpdir/gas/ dummy.c 21 | grep /as
access(/opt/bin/as, X_OK) = 0
$ /opt/src/binutils-build/ld/tmpdir/gas/as -V
GNU assembler version 2.24 (x86_64-unknown-linux-gnu) using BFD version (GNU
Binutils) 2.24
Every other program and file is searched for as the manual says, except the
assembler.
Using the alternative, GCC_EXEC_PREFIX, results in failure to find cc1.
[Bug c++/62150] [5.0 regression] test case g++.dg/ext/arm-fp16/fp16-mangle-1.C failed on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62150 wangzheyu tony.wang at arm dot com changed: What|Removed |Added CC||tony.wang at arm dot com --- Comment #2 from wangzheyu tony.wang at arm dot com --- Also happened on thumb1/thumb2.
[Bug c++/62129] [4.9/5 Regression] internal compiler error: in output_constant, at varasm.c:4755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62129 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c/62198] New: spurious warning - initialization discards qualifier from pointer target type for pointer to array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62198
Bug ID: 62198
Summary: spurious warning - initialization discards qualifier
from pointer target type for pointer to array
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gary at intrepid dot com
Although this bug is filed against the 5.0 trunk, it can be duplicated with at
least 4.8.3.
Given:
$ cat q.c
typedef unsigned long size_t;
extern const void *alloc (size_t);
int main()
{
const int (*X0)[10] = alloc (10 * sizeof (int));
return !X0;
}
When compiled with gcc 4.8.3 the following warning is issued:
$ gcc -fpreprocessed -c q.c
q.c: In function ‘main’:
q.c:7:25: warning: initialization discards ‘const’ qualifier from pointer
target type [enabled by default]
const int (*X0)[10] = alloc (10 * sizeof (int));
^
Same thing for GCC 5.0 (trunk version 214178):
$ xgcc -fpreprocessed -c q.c
q.c: In function ‘main’:
q.c:7:25: warning: initialization discards ‘const’ qualifier from pointer
target type [-Wdiscarded-qualifiers]
const int (*X0)[10] = alloc (10 * sizeof (int));
^
Clang 3.4 issues no warning:
$ clang -Wall -pedantic -Wextra -c q.c
no output
Given that the qualifier 'const' is associated with the array's element type,
it seems that the front end should derive the qualifier from the element type
when it is the target type of a declared pointer, before making the discards
qualifier check.
