[Bug lto/61969] [4.8/4.9/4.10 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969 --- Comment #2 from Zhendong Su --- > You mean in 32bit mode. Richard, yes, I meant 32-bit mode. > I can't reproduce it with trunk or 4.9 but only > with 4.8: > > rguenther@murzim:/tmp> ./compile.sh gcc-4.8 32 1 > rguenther@murzim:/tmp> ./t > 2052 > > maybe it's sensitive to the linker used? it works with both GNU ld and gold > for me with 4.9 and trunk. I used the GNU gold linker: $ ld -v GNU gold (GNU Binutils for Ubuntu 2.22) 1.11 $
[Bug c/61985] It's possible to declare a function pointer as noreturn using the old volatile syntax but not normally.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61985 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Marek Polacek --- The reporter seems to complain that it is not possible to declare a function pointer as noreturn using the noreturn keyword or attribute. But the attribute should work: __attribute__ ((__noreturn__)) void (*fp1) (void); // OK _Noreturn void (*fp2) (void); // invalid You only have to be careful that if you include , the "noreturn" gets expanded to _Noreturn, so you'd get "attribute directive ignored".
[Bug c/61985] It's possible to declare a function pointer as noreturn using the old volatile syntax but not normally.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61985 --- Comment #1 from joseph at codesourcery dot com --- I'm afraid I can't tell what you think the bug here is. You make a true statement about C11 - that's not a bug report. You give some C code - that's not a bug report either. You don't say what GCC version or command-line options you use with the C code, or what you think GCC is doing wrong with that code, why you think that is wrong and what you think it should do instead.
[Bug ipa/61144] [4.9/4.10 Regression] Invalid optimizations for extern vars with local weak definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144 --- Comment #30 from Rich Felker --- I don't really understand how weak aliases come into play for implementing C++ features, but if their semantics are not identical to the necessary C++ semantics, the compiler should just distinguish between the relevant C++ semantics and weak alias semantics rather than trying to force two semantically different concepts to use the same feature in ways that breaks either one or the other. Also, was C++ behavior broken prior to 4.9.0, or is there some other reason that weak aliases worked without breaking C++ mandatory constant folding prior to 4.9.0?
[Bug c/61985] New: It's possible to declare a function pointer as noreturn using the old volatile syntax but not normally.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61985
Bug ID: 61985
Summary: It's possible to declare a function pointer as
noreturn using the old volatile syntax but not
normally.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sstewartgallus00 at mylangara dot bc.ca
It's against the C11 standard to let people use the _Noreturn keyword on a
function pointer type. It's treated the same as the inline keyword. In my
opinion this is silly but whatever. Anyways, it is possible to declare a
function pointer as noreturn using the old volatile syntax but not using the
noreturn keyword or attribute. Eg)
#include
#include
#include
#include
typedef void f(void * restrict, int);
typedef volatile f next_t;
__attribute__((noinline)) noreturn void increment(void * restrict context,
next_t * next,
int xx)
{
next(context, xx + 1);
}
__attribute__((noinline)) noreturn void main_1(void * restrict context, int
xx);
__attribute__((noinline)) noreturn void main_2(void * restrict context, int
xx);
int main(void)
{
{
int value = 4;
printf("value: %i\n", value);
increment(NULL, main_1, value);
}
}
__attribute__((noinline)) noreturn void main_1(void * restrict context, int xx)
{
printf("value + 1: %i\n", xx);
increment(NULL, main_2, xx);
}
__attribute__((noinline)) noreturn void main_2(void * restrict context, int xx)
{
printf("value + 2: %i\n", xx);
exit(EXIT_FAILURE);
}
[Bug target/61984] use mr. to remove extra cmp instruction on ppc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61984 --- Comment #1 from Andrew Pinski --- Basically the scheduler has to move the mr 3,4 above the compare and then combine it with the cmpdi. This is not doable with any of the current infrastructure of GCC though.
[Bug target/61844] ICE when building libgcc for sh64 cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61844 Oleg Endo changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Oleg Endo --- Fixed on trunk and 4.9. 4.8 doesn't seem to be affected.
[Bug target/61984] New: use mr. to remove extra cmp instruction on ppc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61984
Bug ID: 61984
Summary: use mr. to remove extra cmp instruction on ppc
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: carrot at google dot com
Target: powerpc64le
Compile following code with options -m64 -mcpu=power8 -O2
extern void free (void *__ptr);
void my_free ( void* p, void* addr )
{
if (addr != ((void *)0)) free ( addr );
}
Trunk gcc generates:
my_free:
0:addis 2,12,.TOC.-0b@ha
addi 2,2,.TOC.-0b@l
.localentrymy_free,.-my_free
cmpdi 0,4,0 //mr. 3,4
beqlr 0 //beqlr 0
mflr 0 //mflr 0
mr 3,4 //
std 0,16(1)
stdu 1,-32(1)
bl free
nop
addi 1,1,32
ld 0,16(1)
mtlr 0
blr
The instructions from cmpdi to mr can be changed to following
mr. 3, 4
beqlr 0
mflr 0
...
so we can remove the cmpdi instruction.
[Bug target/55143] vms-c.o:(.toc+0x0): undefined reference to `c_default_pointer_mode' (building cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55143 Martin Liška changed: What|Removed |Added CC||mliska at suse dot cz --- Comment #1 from Martin Liška --- Problem is still present in 4.10.0.
[Bug target/61983] New: 64 bit floating point instructions created for 32 bit FPU on MIPS r5900
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61983 Bug ID: 61983 Summary: 64 bit floating point instructions created for 32 bit FPU on MIPS r5900 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: JuergenUrban at gmx dot de Created attachment 33221 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33221&action=edit Test code When compiling the attached test code, the following errors occur: mips64r5900el-linux-gnu-gcc -mhard-float -msingle-float -march=r5900 -mabi=n32 -c -o test.o float64test.c /tmp/ccFuqKvD.s: Assembler messages: /tmp/ccFuqKvD.s:28: Error: opcode not supported on this processor: r5900 (mips3) `dmtc1 $4,$f0' /tmp/ccFuqKvD.s:29: Error: opcode not supported on this processor: r5900 (mips3) `dmtc1 $2,$f2' /tmp/ccFuqKvD.s:66: Error: opcode not supported on this processor: r5900 (mips3) `dmfc1 $2,$f0' /tmp/ccFuqKvD.s:67: Error: opcode not supported on this processor: r5900 (mips3) `dmfc1 $4,$f2' /tmp/ccFuqKvD.s:72: Error: opcode not supported on this processor: r5900 (mips3) `dmtc1 $4,$f0' /tmp/ccFuqKvD.s:73: Error: opcode not supported on this processor: r5900 (mips3) `dmtc1 $2,$f2' The MIPS r5900 supports 64 bit instructions, but doesn't have a 64 bit FPU. It just has a 32 bit FPU. The compiler should not create dmtc1 or dmfc1. The instructions as created in function mips_output_move() file gcc-4.9.0/gcc/config/mips/mips.c line 4583/4538: return dbl_p ? "dmtc1\t%z1,%0" : "mtc1\t%z1,%0"; return dbl_p ? "dmfc1\t%0,%1" : "mfc1\t%0,%1";
[Bug sanitizer/61978] implement blacklist for sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Jakub Jelinek --- This is intentionally not implemented, you should mark functions you don't want to sanitize in the source, not on the side, so just use the attribute for it.
[Bug target/61844] ICE when building libgcc for sh64 cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61844 --- Comment #14 from Oleg Endo --- Author: olegendo Date: Thu Jul 31 20:19:43 2014 New Revision: 213384 URL: https://gcc.gnu.org/viewcvs?rev=213384&root=gcc&view=rev Log: gcc/ Backport from mainline 2014-07-31 Oleg Endo PR target/61844 * config/sh/sh.c (sh_legitimate_address_p, sh_legitimize_reload_address): Handle reg+reg address modes when ALLOW_INDEXED_ADDRESS is false. * config/sh/predicates.md (general_movsrc_operand, general_movdst_operand): Likewise. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/sh/predicates.md branches/gcc-4_9-branch/gcc/config/sh/sh.c
[Bug middle-end/57541] [Cilkplus]: internal compiler error: in gimplify_expr, at gimplify.c:7809
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57541 Igor Zamyatin changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #14 from Igor Zamyatin --- I have a bunch of changes in my local tree that should fix this issue. Hope to send them out next week
[Bug c++/61982] New: Optimizer does not eliminate stores to destroyed objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
Bug ID: 61982
Summary: Optimizer does not eliminate stores to destroyed
objects
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
After a destructor is run, access to the object is forbidden; the object is
turned into a pile of bytes. Yet the generated code for:
struct X {
int i;
void clear() { i = 0; }
};
void f(X* x) {
x->clear();
x->~X();
}
void g(X* x) {
x->clear();
delete x;
}
contains a store for each of f() and g(), stores that should have been
eliminated:
:
0:c7 07 00 00 00 00movl $0x0,(%rdi)
6:c3 retq
7:66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
e:00 00
0010 :
10:c7 07 00 00 00 00movl $0x0,(%rdi)
16:e9 00 00 00 00 jmpq 1b
17: R_X86_64_PC32operator delete(void*)-0x4
To be clear, the generated code is correct, but not optimal.
[Bug target/61981] New: PowerPC Linux Split-Stack Support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61981 Bug ID: 61981 Summary: PowerPC Linux Split-Stack Support Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dje at gcc dot gnu.org Enable and implement split-stack support for PowerPC Linux such that GCC Testsuite passes with -fsplit-stack option enabled.
[Bug c/59855] Support sparse-style __attribute__((designated_init)) on structures, requiring designated initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59855 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #6 from Marek Polacek --- Tom: I can add the testcase(s) above if you want.
[Bug tree-optimization/58122] loops are not evaluated at compile time if loop count > 17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58122
--- Comment #4 from Oleg Endo ---
(In reply to Oleg Endo from comment #0)
>
> I've also briefly checked with trunk rev 201282 and the problem seems to be
> still there. Here is a reduced test case:
>
> int test (void)
> {
> int sum = 0;
> for (int x = 0; x < 100; x++)
> sum += x;
>
> return sum;
> }
>
As of r213381 the reduced test case seems to work OK with at least loop counts
up to 4.
[Bug c/59855] Support sparse-style __attribute__((designated_init)) on structures, requiring designated initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59855
--- Comment #5 from Josh Triplett ---
(In reply to Tom Tromey from comment #4)
> Implemented on trunk.
Thanks!
Please consider including anonymous structs and unions in the test case as
well:
struct S {
int a;
union {
int b;
int c;
};
} __attribute__((designated_init));
static struct S s = {
.a = 0,
.b = 0,
};
union U {
int a;
struct {
int b;
int c;
} __attribute__((designated_init));
};
static union U u = {
.b = 0,
.c = 0,
};
Both of the cases above should produce no warnings; analogous positional
initializers should produce warnings.
[Bug rtl-optimization/55190] [SH] ivopts causes loop setup bloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55190 Oleg Endo changed: What|Removed |Added Known to fail||4.9.0 --- Comment #5 from Oleg Endo --- As of r213381 the issue still persists.
[Bug c++/15339] [DR217] Adding default arguments to function templates in redeclarations should be forbidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15339 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #15 from Paolo Carlini --- Mine.
[Bug middle-end/61980] [GCC-4.9.1] ICE: in compute_affine_dependence, at tree-data-ref.c:4233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61980 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Component|c |middle-end Severity|critical|normal
[Bug c/61980] New: [GCC-4.9.1] ICE: in compute_affine_dependence, at tree-data-ref.c:4233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61980
Bug ID: 61980
Summary: [GCC-4.9.1] ICE: in compute_affine_dependence, at
tree-data-ref.c:4233
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sabrinadfs at gmail dot com
GCC-4.9.1
x86_64-apple-darwin11.4.2
Running the following tests:
1)
make -s -C gcc check-gcc RUNTESTFLAGS="dg.exp=pr39794.c
--target_board=unix/-fcheck-data-deps"
GCC throw an ICE:
/Users/sabrinasouto/Downloads/gcc4.9/gcc-4.9.1/gcc/testsuite/gcc.dg/pr39794.c:
In function 'foo':
/Users/sabrinasouto/Downloads/gcc4.9/gcc-4.9.1/gcc/testsuite/gcc.dg/pr39794.c:8:1:
internal compiler error: in compute_affine_dependence, at tree-data-ref.c:4233
/Users/sabrinasouto/Downloads/gcc4.9/gcc-4.9.1/gcc/testsuite/gcc.dg/pr39794.c:8:1:
internal compiler error: Abort trap: 6
xgcc: internal compiler error: Abort trap: 6 (program cc1)
FAIL: gcc.dg/pr39794.c (internal compiler error)
FAIL: gcc.dg/pr39794.c (test for excess errors)
Excess errors:
(Number of distance vectors differ: Banerjee has 1, Omega has 0.
Banerjee dist vectors:
1
Omega dist vectors:
data dependence relation:
(Data Dep:
#(Data Ref:
# bb: 5
# stmt: _9 = *_8;
# ref: *_8;
# base_object: *a_5(D);
# Access function 0: {0B, +, 4}_1
#)
#(Data Ref:
# bb: 5
# stmt: *_14 = _21;
# ref: *_14;
# base_object: *a_5(D);
# Access function 0: {4B, +, 4}_1
#)
access_fn_A: {0B, +, 4}_1
access_fn_B: {4B, +, 4}_1
(subscript
iterations_that_access_an_element_twice_in_A: [1 + 1 * x_1]
last_conflict: 2147483646
iterations_that_access_an_element_twice_in_B: [0 + 1 * x_1]
last_conflict: 2147483646
(Subscript distance: 1 ))
inner loop index: 0
loop nest: (1 )
)
)
2)
make -s -C gcc check-gcc RUNTESTFLAGS="dg.exp=20090922-1.c
--target_board=unix/-fcheck-data-deps"
GCC throw an ICE:
/Users/sabrinasouto/Downloads/gcc4.9/gcc-4.9.1/gcc/testsuite/gcc.dg/20090922-1.c:
In function 'test':
/Users/sabrinasouto/Downloads/gcc4.9/gcc-4.9.1/gcc/testsuite/gcc.dg/20090922-1.c:33:1:
internal compiler error: in compute_affine_dependence, at tree-data-ref.c:4233
/Users/sabrinasouto/Downloads/gcc4.9/gcc-4.9.1/gcc/testsuite/gcc.dg/20090922-1.c:33:1:
internal compiler error: Abort trap: 6
xgcc: internal compiler error: Abort trap: 6 (program cc1)
FAIL: gcc.dg/20090922-1.c (internal compiler error)
FAIL: gcc.dg/20090922-1.c (test for excess errors)
Excess errors:
(Number of distance vectors differ: Banerjee has 2, Omega has 1.
Banerjee dist vectors:
0
1
Omega dist vectors:
0
data dependence relation:
(Data Dep:
#(Data Ref:
# bb: 19
# stmt: _47 = MEM[(struct U *)v_19 + 16B].u3;
# ref: MEM[(struct U *)v_19 + 16B].u3;
# base_object: MEM[(struct U *)v_19 + 16B];
# Access function 0: 64
#)
#(Data Ref:
# bb: 19
# stmt: MEM[(struct U *)v_19 + 16B].u3 = _50;
# ref: MEM[(struct U *)v_19 + 16B].u3;
# base_object: MEM[(struct U *)v_19 + 16B];
# Access function 0: 64
#)
access_fn_A: 64
access_fn_B: 64
(subscript
iterations_that_access_an_element_twice_in_A: [0]
last_conflict: scev_not_known
iterations_that_access_an_element_twice_in_B: [0]
last_conflict: scev_not_known
(Subscript distance: 0 ))
inner loop index: 0
loop nest: (4 )
distance_vector: 0
direction_vector: =
)
)
Can anyone confirm these bugs?
[Bug tree-optimization/61964] [4.8/4.9 regression] krb5 database propagation enters infinite loop; reduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964 --- Comment #12 from vries at gcc dot gnu.org --- Created attachment 33220 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33220&action=edit Alternative patch > But that line is never executed at runtime (well, unless tail > merging comes along and makes it the only version present). Ah, right, we consider a program with dead type-unsafe code valid. This follow-up patch attempts to fix things less conservatively on trunk. Shall I put this through testing or do you see a problem with this approach? Furthermore, I suspect that a similar issue exists for loads, I'll look into that.
[Bug tree-optimization/56365] Missed opportunities for smin/smax standard name patterns when compiling as C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56365
--- Comment #4 from Oleg Endo ---
As of r213381 this problem still exists.
compiled as C 003t.original:
;; Function min (null)
;; enabled by -tree-original
{
return MIN_EXPR ;
}
;; Function max (null)
;; enabled by -tree-original
{
return MAX_EXPR ;
}
;; Function test_04 (null)
;; enabled by -tree-original
{
return max (-128, min (127, a));
}
compiled as C++ 003t.original:
;; Function int min(int, int) (null)
;; enabled by -tree-original
return = a < b ? a : b;
;; Function int max(int, int) (null)
;; enabled by -tree-original
return = a < b ? b : a;
;; Function int test_04(int, int) (null)
;; enabled by -tree-original
< = max (-128, min (127, a))>>;
[Bug other/61979] New: Why float variable loading twice into the FTU Stack during condition checking ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61979 Bug ID: 61979 Summary: Why float variable loading twice into the FTU Stack during condition checking ? Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: nasika.srikanth1 at gmail dot com Actually its not a bug. But i identified that float variables are loading twice into the FTU STACK during the condition checking ,that's actually my doubt and i check without loading it again i remove repeated code and getting the same output . But why gcc complier loads the float variable again into the FTU Stack ? For checking the condition it first checks the parity flags(whether NAN ,INF )then it again loads the float variable into FTU stack and check for the zero flag( whether non zero) set or not. But we can directly check the zero flag after checking parity flag with out loading the variable into the FTU stack.
[Bug target/61844] ICE when building libgcc for sh64 cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61844 --- Comment #13 from Oleg Endo --- Author: olegendo Date: Thu Jul 31 16:27:56 2014 New Revision: 213381 URL: https://gcc.gnu.org/viewcvs?rev=213381&root=gcc&view=rev Log: gcc/ PR target/61844 * config/sh/sh.c (sh_legitimate_address_p, sh_legitimize_reload_address): Handle reg+reg address modes when ALLOW_INDEXED_ADDRESS is false. * config/sh/predicates.md (general_movsrc_operand, general_movdst_operand): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/predicates.md trunk/gcc/config/sh/sh.c
[Bug sanitizer/61978] New: implement blacklist for sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61978 Bug ID: 61978 Summary: implement blacklist for sanitizer Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: gcc at dpinol 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 clang has a -fsanitize-blacklist for this thanks
[Bug target/53911] [SH] Improve displacement addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53911 --- Comment #3 from Oleg Endo --- Another offset assignment related paper: ftp://gcc.gnu.org/pub/gcc/summit/2003/Optimal%20Stack%20Slot%20Assignment.pdf
[Bug middle-end/56924] Folding of checks into a range check should check upper boundary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56924
--- Comment #3 from Joshua Conner ---
It appears that gcc has a different approach now, which has its own advantages
and disadvantages. Specifically, when I compile this same example I'm now
seeing an initial tree of:
if ((SAVE_EXPR & 240>) == 224 || (SAVE_EXPR
& 240>) == 240)
{
bar ();
}
Which indeed generates much better assembly code (for ARM):
and r0, r0, #224
cmp r0, #224
beq .L4
But with a slight modification of the original code to:
if ((input.val == 0xd) || (input.val == 0xe) || (input.val == 0xf))
bar();
The tree looks like:
if (((SAVE_EXPR & 240>) == 208 || (SAVE_EXPR
& 240>) == 224) || (BIT_FIELD_REF &
240) == 240)
And the generated assembly is:
uxtbr0, r0
and r3, r0, #240
and r0, r0, #208
cmp r0, #208
cmpne r3, #224
beq .L4
Which could be much better as:
ubfxr0, r0, #4, #4
cmp r0, #12
bhi .L4
[Bug target/61844] ICE when building libgcc for sh64 cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61844 --- Comment #12 from dhowells at redhat dot com --- (In reply to Oleg Endo from comment #10) > Created attachment 33197 [details] > a possible fix It permits me to build a slew of sh64 libgccs, so it's looking good.
[Bug c++/60167] [4.9 regression] Bogus error: conflicting declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60167 Bug 60167 depends on bug 58606, which changed state. Bug 58606 Summary: [4.8 Regression] [c++11] ICE with specialization in variadic template https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58606 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug c++/58606] [4.8 Regression] [c++11] ICE with specialization in variadic template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58606 Jason Merrill changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED Target Milestone|4.8.4 |4.9.0 --- Comment #9 from Jason Merrill --- I think this is riskier than I want to apply to 4.8.
[Bug c++/61623] [4.10 Regression] ICE: verify_symtab failed: Two symbols with same comdat_group are not linked by the same_comdat_group list.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61623 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Merrill --- Fixed.
[Bug target/61977] New: powerpc-eabi preprocessor breaks on lines that end with "vector"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61977 Bug ID: 61977 Summary: powerpc-eabi preprocessor breaks on lines that end with "vector" Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: drivshin at allworx dot com Created attachment 33219 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33219&action=edit patch to revert 210055 and 211656 The powerpc-eabi (and powerpc-eabispe -mno-spe; I haven't tried other powerpc-*) preprocessor misbehaves when a line ends with "vector". I happened to hit this in assembler comments, but that does not appear to be a requirement. Examples of lines which cause the failure: vector # vector # x vector x # vector ; vector # .vector # +vector Examples of lines which do not cause the failure: # vectors # vector x # vector. # _vector // vector (unless -C is given) vector; The symptom depends on whether that is the last non-whitespace line in the file. If it is, then the result is an ICE. If it is not, then just "vector" appears by itself on the next line. This did not happen on GCC 4.9.0, but does happen in GCC 4.9.1 and the current trunk. Bisecting between 4.9.0 and 4.9.1 points to SVN revision 210055 as introducing this behavior. Reverting r210055 (and also r211656 which seemed to be dependant upon r210055) appears to fix the issue, and a patch (against 4.9.1) doing that is attached. $ prefix/bin/powerpc-eabi-gcc -v Using built-in specs. COLLECT_GCC=prefix/bin/powerpc-eabi-gcc COLLECT_LTO_WRAPPER=/home/drivshin/gcc-powerpc-eabi/prefix/bin/../libexec/gcc/powerpc-eabi/4.9.1/lto-wrapper Target: powerpc-eabi Configured with: ../gcc-4.9.1/configure -v --prefix=/home/drivshin/gcc-powerpc-eabi/build-gcc/../prefix --target=powerpc-eabi --enable-languages=c Thread model: single gcc version 4.9.1 (GCC) $ echo -e "# comment ending in vector\n# another comment" | prefix/bin/powerpc-eabi-cpp -x assembler-with-cpp # 1 "" # 1 "" # 1 "" # 1 "" # comment ending in vector # 2 "" # another comment $ echo -e "# comment ending in vector" | prefix/bin/powerpc-eabi-cpp -x assembler-with-cpp # 1 "" # 1 "" # 1 "" # 1 "" :1:0: internal compiler error: Segmentation fault 0x82f7bf crash_signal ../../gcc-4.9.1/gcc/toplev.c:337 0xc37b75 _cpp_lex_direct ../../gcc-4.9.1/libcpp/lex.c:2171 0xc389fb _cpp_lex_token ../../gcc-4.9.1/libcpp/lex.c:2055 0xc3d117 cpp_get_token_1 ../../gcc-4.9.1/libcpp/macro.c:2359 0x559877 scan_translation_unit ../../gcc-4.9.1/gcc/c-family/c-ppoutput.c:176 0x559877 preprocess_file(cpp_reader*) ../../gcc-4.9.1/gcc/c-family/c-ppoutput.c:101 0x558360 c_common_init() ../../gcc-4.9.1/gcc/c-family/c-opts.c:1047 0x4ff08d c_objc_common_init() ../../gcc-4.9.1/gcc/c/c-objc-common.c:65 0x8312c6 lang_dependent_init ../../gcc-4.9.1/gcc/toplev.c:1712 0x8312c6 do_compile ../../gcc-4.9.1/gcc/toplev.c:1900
[Bug target/51729] dspr2-MULT.c and dspr2-MULTU.c fail for MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51729 Matthew Fortune changed: What|Removed |Added CC||clm at codesourcery dot com, ||matthew.fortune at imgtec dot com, ||sandra at codesourcery dot com --- Comment #3 from Matthew Fortune --- The affected tests appear to have started passing again since this commit: svn: r211959 2014-06-24 Catherine Moore Sandra Loosemore gcc/ * config/mips/mips.c (mips_order_regs_for_local_alloc): Delete. * config/mips/mips.h (ADJUST_REG_ALLOC_ORDER): Delete. * config/mips/mips-protos.h (mips_order_regs_for_local_alloc): Delete. Irritatingly they now pass for -O2 and -O3 but still fail for -O1 and -Os. I was half tempted to submit a patch to just be content that we get multiple accumulators now used at -O2 and -O3 and leave it at that but I think that is probably the wrong attitude. Has anyone else noticed the change in state for these tests and looked into it, planning to look into it or have any thoughts? I'll take a look when I get chance.
[Bug middle-end/61762] failure to optimize memcpy from constant string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61762 --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #10 from Richard Biener --- [...] > Patch attached, it may still help SPARC passing the testcase. The patch doesn't make a difference, unfortunately. Rainer
[Bug target/61948] [ARM] [4.10 regression] ICE with DImode shift by 1 bit (in copyprop_hardreg_forward_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61948 --- Comment #2 from cbaylis at gcc dot gnu.org --- Author: cbaylis Date: Thu Jul 31 14:27:58 2014 New Revision: 213376 URL: https://gcc.gnu.org/viewcvs?rev=213376&root=gcc&view=rev Log: PR target/61948 gcc/ChangeLog: 2014-07-29 Charles Baylis PR target/61948 * config/arm/neon.md (ashldi3_neon): Don't emit arm_ashldi3_1bit unless constraints are satisfied. (di3_neon): Likewise. gcc/testsuite/ChangeLog: 2014-07-29 Charles Baylis PR target/61948 * gcc.target/arm/pr61948.c: New test case. Added: trunk/gcc/testsuite/gcc.target/arm/pr61948.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/neon.md trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/61964] [4.8/4.9/4.10 regression] krb5 database propagation enters infinite loop; reduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964 --- Comment #10 from Richard Biener --- Author: rguenth Date: Thu Jul 31 14:06:59 2014 New Revision: 213375 URL: https://gcc.gnu.org/viewcvs?rev=213375&root=gcc&view=rev Log: 2014-07-31 Richard Biener PR tree-optimization/61964 * tree-ssa-tail-merge.c (gimple_equal_p): Handle non-SSA LHS solely by structural equality. * gcc.dg/torture/pr61964.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr61964.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-tail-merge.c
[Bug tree-optimization/61964] [4.8/4.9 regression] krb5 database propagation enters infinite loop; reduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964 Richard Biener changed: What|Removed |Added Known to work||4.10.0 Summary|[4.8/4.9/4.10 regression] |[4.8/4.9 regression] krb5 |krb5 database propagation |database propagation enters |enters infinite loop; |infinite loop; reduced test |reduced test case |case --- Comment #11 from Richard Biener --- Fixed on trunk sofar.
[Bug fortran/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61950 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE --- With the patch, the previously failing gfortran.dg/allocate_class_3.f90 testcase works fine on 64-bit SPARC. Thanks. Rainer
[Bug c++/59318] ICE on invalid C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59318 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Paolo Carlini --- Fixed by the same patch. *** This bug has been marked as a duplicate of bug 61723 ***
[Bug c++/61723] [C++11] ICE in contains_struct_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61723 Paolo Carlini changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #9 from Paolo Carlini --- *** Bug 59318 has been marked as a duplicate of this bug. ***
[Bug c++/51312] [C++0x] Wrong interpretation of converted constant expressions (for enumerator initializers)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51312 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #10 from Paolo Carlini --- Ah Ok...
[Bug target/61976] aix64: Data corruption in struct passed by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61976 Jonathan Wakely changed: What|Removed |Added Target||powerpc-ibm-aix* Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-31 Component|c++ |target Ever confirmed|0 |1 Known to fail||4.8.1 --- Comment #1 from Jonathan Wakely --- GCC 4.7 is no longer supported, but I can conform the bug with GCC 4.8.1 on powerpc-ibm-aix7.1.0.0
[Bug middle-end/61762] failure to optimize memcpy from constant string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61762 --- Comment #10 from Richard Biener --- Created attachment 33218 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33218&action=edit patch I have a patch but as the relevant folding already triggers during C parsing it is too early for the cgraph code to see the constant initializer ... (well, on x86_64). But well, all this memory builtin folding should move to GIMPLE anyway... Patch attached, it may still help SPARC passing the testcase. (side-note - instead of the current fold_constant_aggregate_ref I'd like to see a fold_constant_read (type, ptr) API that is, not require us building a memory reference)
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #21 from aggrostyle at gmail dot com --- Thank you! It worked perfect last night!
[Bug c++/61976] New: aix64: Data corruption in struct passed by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61976
Bug ID: 61976
Summary: aix64: Data corruption in struct passed by value
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lbl2007 at gmx dot net
Test program:
#include
struct Demo { float a; };
void foo( const Demo byval, const Demo &byref )
{
printf( "byval: %f\n", (double) byval.a );
printf( "byref: %f\n", (double) byref.a );
}
int main()
{
Demo a = { 1.23 };
foo( a, a );
return 0;
}
When I compile and run this under AIX, the first argument is corrupted:
g++ -maix64 -o demo demo.c
./demo
byval: -0.00
byref: 1.23
The problem does not occur with -maix32
GCC version:
Target: powerpc-ibm-aix6.1.0.0
Configured with: /common/mringe/gcc47_alt/gcc-4.7.2/configure
--prefix=/common/mringe/gcc47_alt/local --with-as=/usr/bin/as
--with-ld=/usr/bin/ld --enable-languages=c,c++ --enable-threads --disable-nls
--disable-shared --with-gmp=/common/mringe/gcc47_alt/local
--with-mpfr=/common/mringe/gcc47_alt/local
--with-mpc=/common/mringe/gcc47_alt/local
Thread model: aix
gcc version 4.7.2 (GCC)
[Bug tree-optimization/61964] [4.8/4.9/4.10 regression] krb5 database propagation enters infinite loop; reduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964 --- Comment #9 from rguenther at suse dot de --- On Thu, 31 Jul 2014, vries at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964 > > vries at gcc dot gnu.org changed: > >What|Removed |Added > > CC||vries at gcc dot gnu.org > > --- Comment #8 from vries at gcc dot gnu.org --- > Using this patch on the example from the description field, I can modify the > example on the command line: > ... > $ diff -u bug-orig.c bug-mod.c > --- bug-orig.c2014-07-31 14:00:50.663275717 +0200 > +++ bug-mod.c2014-07-31 14:01:49.403276412 +0200 > @@ -11,7 +11,7 @@ >struct node *n = head->first; >struct head *h = &heads[k]; > > - if (n->prev == (void *)h) > + if (FORCE n->prev == (void *)h) > h->first = n->next; >else > n->prev->next = n->next; > ... > > 1. -DFORCE="" gives the original > 2. -DFORCE="1 ||" forces the condition to true > 3. -DFORCE="0 &&" forces the confition to false > > In this experiment, we don't use tree-tail-merge: > ... > $ gcc -DFORCE="1 ||" bug-mod.c -O2 -fno-strict-aliasing -fno-tree-tail-merge > && > ./a.out ; echo $? > 0 > $ gcc -DFORCE="1 ||" bug-mod.c -O2 -fstrict-aliasing -fno-tree-tail-merge && > ./a.out ; echo $? > 0 > $ gcc -DFORCE="0 &&" bug-mod.c -O2 -fno-strict-aliasing -fno-tree-tail-merge > && > ./a.out ; echo $? > 0 > $ gcc -DFORCE="0 &&" bug-mod.c -O2 -fstrict-aliasing -fno-tree-tail-merge && > ./a.out ; echo $? > 1 > ... > > The last result seems to suggest that the example is not type-safe. > > My understanding is that the problem is in the line: > n->prev->next = n->next; > where we effectively do: > /* ((struct node*)&heads[2])->next = node.next */ > which is type-unsafe. But that line is never executed at runtime (well, unless tail merging comes along and makes it the only version present). Richard.
[Bug tree-optimization/61964] [4.8/4.9/4.10 regression] krb5 database propagation enters infinite loop; reduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964 vries at gcc dot gnu.org changed: What|Removed |Added CC||vries at gcc dot gnu.org --- Comment #8 from vries at gcc dot gnu.org --- Using this patch on the example from the description field, I can modify the example on the command line: ... $ diff -u bug-orig.c bug-mod.c --- bug-orig.c2014-07-31 14:00:50.663275717 +0200 +++ bug-mod.c2014-07-31 14:01:49.403276412 +0200 @@ -11,7 +11,7 @@ struct node *n = head->first; struct head *h = &heads[k]; - if (n->prev == (void *)h) + if (FORCE n->prev == (void *)h) h->first = n->next; else n->prev->next = n->next; ... 1. -DFORCE="" gives the original 2. -DFORCE="1 ||" forces the condition to true 3. -DFORCE="0 &&" forces the confition to false In this experiment, we don't use tree-tail-merge: ... $ gcc -DFORCE="1 ||" bug-mod.c -O2 -fno-strict-aliasing -fno-tree-tail-merge && ./a.out ; echo $? 0 $ gcc -DFORCE="1 ||" bug-mod.c -O2 -fstrict-aliasing -fno-tree-tail-merge && ./a.out ; echo $? 0 $ gcc -DFORCE="0 &&" bug-mod.c -O2 -fno-strict-aliasing -fno-tree-tail-merge && ./a.out ; echo $? 0 $ gcc -DFORCE="0 &&" bug-mod.c -O2 -fstrict-aliasing -fno-tree-tail-merge && ./a.out ; echo $? 1 ... The last result seems to suggest that the example is not type-safe. My understanding is that the problem is in the line: n->prev->next = n->next; where we effectively do: /* ((struct node*)&heads[2])->next = node.next */ which is type-unsafe.
[Bug fortran/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61950
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Component|middle-end |fortran
--- Comment #6 from Richard Biener ---
So we have (reduced from class_19.f03)
:
__builtin_memcpy (_10, &__def_init_foo_mod_Foo_outer, 0);
_22 = MEM[(struct foo_outer *)_10].int._data;
if (_22 != 0B)
goto ;
else
goto ;
:
_gfortran_abort ();
from
(struct __vtype_foo_mod_Foo_outer *) try3._vptr =
&__vtab_foo_mod_Foo_outer;
(void) __builtin_memcpy ((void *) try3._data, (void *)
try3._vptr->_def_init, (unsigned long) try3._vptr->_size);
if (try3._data->int._data != 0B)
{
_gfortran_abort ();
}
see how the size argument to memcpy is zero! FRE does that:
Value numbering _17 stmt = _17 = try3._vptr;
Setting value number of _17 to &__vtab_foo_mod_Foo_outer (changed)
Value numbering _18 stmt = _18 = _17->_size;
RHS _17->_size simplified to 0 has constants 1
fold_ctor_reference (type=0xfffb5930738, ctor=0xfffb5908e20, offset=32, size=
32, from_decl=0xfffb5ab9fb0) at ../../trunk/gcc/gimple-fold.c:3059
3059 if (useless_type_conversion_p (type, TREE_TYPE (ctor))
(gdb) p debug_generic_expr (ctor)
{._hash=13054828, ._size=16, ._extends=0B,
._def_init=&__def_init_foo_mod_Foo_outer, ._copy=__copy_foo_mod_Foo_outer,
._final=__final_foo_mod_Foo_outer}
$241 = void
where we recurse through fold_nonarray_ctor_reference to
fold_ctor_reference (type=0xfffb5930738, ctor=0xfffb5900eb8, offset=0, size=
32, from_decl=0xfffb5ab9fb0) at ../../trunk/gcc/gimple-fold.c:3059
3059 if (useless_type_conversion_p (type, TREE_TYPE (ctor))
(gdb) p debug_generic_expr (ctor)
16
but despite _size being 32bit in size:
idx unit size
the actual value in the initializer is of sizetype:
(gdb) p debug_tree (ctor)
constant
16>
so there is a mismatch created by the frontend here.
Frontend bug fixed by
Index: fortran/trans-expr.c
===
--- fortran/trans-expr.c(revision 213342)
+++ fortran/trans-expr.c(working copy)
@@ -6260,7 +6260,9 @@ gfc_conv_structure (gfc_se * se, gfc_exp
else if (cm->ts.u.derived && strcmp (cm->name, "_size") == 0)
{
val = TYPE_SIZE_UNIT (gfc_get_derived_type (cm->ts.u.derived));
- CONSTRUCTOR_APPEND_ELT (v, cm->backend_decl, val);
+ CONSTRUCTOR_APPEND_ELT (v, cm->backend_decl,
+ fold_convert (TREE_TYPE (cm->backend_decl),
+ val));
}
else
{
[Bug c++/61975] default template arguments do not work with out-of-class class declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61975 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-31 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- EDG accepts it too
[Bug ipa/61393] [trans-mem] O3 optimization level constant propagation problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61393 --- Comment #6 from Martin Jambor --- (In reply to Martin Jambor from comment #1) > However, I do not really know what the semantics of that flag mean so > at least for now I am not going to propose this (I am also not quite > sure this is the best place for the copy). What properties of a > function should be maintained in order to keep it flagged as a tm > clone? No answer, so I have actually proposed a variant of the patch in the comment #1 to the mailing list: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg02105.html
[Bug c++/61975] New: default template arguments do not work with out-of-class class declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61975
Bug ID: 61975
Summary: default template arguments do not work with
out-of-class class declaration
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
GCC shows error on this code:
template
struct x
{
template
struct y;
};
template <>
template
struct x::y
{
typedef U type;
};
x::y<>::type a;
2.cpp:17:11: error: wrong number of template arguments (0, should be 1)
x::y<>::type a;
^
2.cpp:5:12: error: provided for ‘template struct x::y’
struct y;
^
2.cpp:17:19: error: expected initializer before ‘a’
x::y<>::type a;
^
I think this code is correct because default argument for parameter U is
specified. Clang compiles this code correctly.
[Bug middle-end/61950] [4.10 regression] Many 64-bit fortran allocate tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61950 Richard Biener changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #5 from Richard Biener --- (In reply to Pat Haugen from comment #4) > Seeing the same on powerpc64-unknown-linux-gnu (big-endian). Ok, that HW I have availabe. Digging.
[Bug lto/61969] [4.8/4.9/4.10 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969 Richard Biener changed: What|Removed |Added Target||i?86-*-* Target Milestone|--- |4.8.4 Summary|wrong code by LTO on|[4.8/4.9/4.10 Regression] |x86_64-linux-gnu (affecting |wrong code by LTO on |trunk, 4.9.x, and 4.8.x)|i?86-linux-gnu (affecting ||trunk, 4.9.x, and 4.8.x) --- Comment #1 from Richard Biener --- You mean in 32bit mode. I can't reproduce it with trunk or 4.9 but only with 4.8: rguenther@murzim:/tmp> ./compile.sh gcc-4.8 32 1 rguenther@murzim:/tmp> ./t 2052 maybe it's sensitive to the linker used? it works with both GNU ld and gold for me with 4.9 and trunk.
[Bug tree-optimization/61938] Vectorization not happening .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61938
--- Comment #7 from Richard Biener ---
(In reply to harmeeksingh from comment #6)
>
> Equivalent code when written by hand where tmp is a intermediate array . The
> compiler
> vectorizes both loops.
>
> int k, i;
> /* vectorize the compares */
> for (i=0; i < arraysize; ++i) {
>tmp[i] = (array[i] == compval);
> }
>
> /* another loop now set the result array */
> for (k=0, i=0; i < arraysize; ++i) {
> if (tmp[i])
> {
>result[k] = i;
>k++;
> }
> }
I only see the first loop vectorized.
typedef long int int64;
typedef int int32;
void foo (int arraysize,
int *__restrict result,
int *__restrict tmp,
int *__restrict selectvector,
int selectelements,
int64 *__restrict array,
int64 compval)
{
int k, i;
/* another loop now set the result array */
for (k=0, i=0; i < arraysize; ++i) {
if (tmp[i])
{
result[k] = i;
k++;
}
}
}
cannot be vectorized exactly because of the said reasons.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #20 from James Clarke --- (In reply to aggrostyle from comment #18) > Guys, a question... how can i apply the patch? I've read that i have to add: > > patch do > url "https://gcc.gnu.org/bugzilla/attachment.cgi?id=33180"; > sha1 "def0cb036a255175db86f106e2bb9dd66d19b702" > end > > But i don't know WHERE to add that in the formula when i use brew edit gcc... > > Any help? Thanks! I included the patch directly in the contents of the formula (see https://github.com/jrtc27/homebrew/commit/a94f371cb24fb68e2f55e701eb2a25a56253b726), but it should also work if you add the patch do ... end block just before the fails_with :gcc_4_0 line (though I haven't tried that).
[Bug tree-optimization/61964] [4.8/4.9/4.10 regression] krb5 database propagation enters infinite loop; reduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Keywords||wrong-code Last reconfirmed||2014-07-31 CC||tom at codesourcery dot com Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Summary|[4.8 regression] krb5 |[4.8/4.9/4.10 regression] |database propagation enters |krb5 database propagation |infinite loop; reduced test |enters infinite loop; |case|reduced test case Target Milestone|--- |4.8.4 --- Comment #7 from Richard Biener --- (In reply to Anders Kaseorg from comment #4) > Another bisect between 4.7 and 4.8 shows that the bug appeared with r189321 > (bug 52009). > > My test case has triggers the bug in more versions than Kerberos does: as > far as I can tell, Kerberos was unaffected until r192604. Thanks - that pin-points it. tail-merging concludes that : _11 = n_7->next; MEM[(struct head *)_10].first = _11; goto ; and : _13 = n_7->next; _10->next = _13; are equivalent. But they are not - the stores are performed using different alias sets. Note that the actual miscompile happens during RTL instruction scheduling. In 4.9 and trunk tail-merging is faced with : _11 = n_7->next; MEM[(struct head *)&heads][k.1_8].first = _11; goto ; : _13 = n_7->next; _10->next = _13; instead but I bet the issue is still there. So it simply does (on the 4.8 branch): case GIMPLE_ASSIGN: lhs1 = gimple_get_lhs (s1); lhs2 = gimple_get_lhs (s2); if (TREE_CODE (lhs1) != SSA_NAME && TREE_CODE (lhs2) != SSA_NAME) return (vn_valueize (gimple_vdef (s1)) == vn_valueize (gimple_vdef (s2))); which shows that we value-number the VDEFs the same. IMHO VDEF value-numbering is dangerous here. I have a patch.
[Bug tree-optimization/61964] [4.8 regression] krb5 database propagation enters infinite loop; reduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964 --- Comment #6 from Andreas Schwab --- Equality test against pointer to void is explicitly allowed by the standard and implicitly converts the other pointer to void*.
[Bug c++/60517] warning/error for taking address of member of a temporary object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517 --- Comment #15 from Marc Glisse --- Author: glisse Date: Thu Jul 31 09:33:58 2014 New Revision: 213323 URL: https://gcc.gnu.org/viewcvs?rev=213323&root=gcc&view=rev Log: 2014-07-31 Marc Glisse PR c++/60517 gcc/c/ * c-typeck.c (c_finish_return): Return 0 instead of the address of a local variable. gcc/cp/ * typeck.c (maybe_warn_about_returning_address_of_local): Return whether it is returning the address of a local variable. (check_return_expr): Return 0 instead of the address of a local variable. gcc/c-family/ * c.opt (-Wreturn-local-addr): Move to common.opt. gcc/ * common.opt (-Wreturn-local-addr): Moved from c.opt. * gimple-ssa-isolate-paths.c: Include diagnostic-core.h and intl.h. (isolate_path): New argument to avoid inserting a trap. (find_implicit_erroneous_behaviour): Handle returning the address of a local variable. (find_explicit_erroneous_behaviour): Likewise. gcc/testsuite/ * c-c++-common/addrtmp.c: New file. * c-c++-common/uninit-G.c: Adapt. Added: trunk/gcc/testsuite/c-c++-common/addrtmp.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c.opt trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/common.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/gimple-ssa-isolate-paths.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/uninit-G.c
[Bug lto/61646] [4.10 Regression] ICE: in write_ts_type_non_common_tree_pointers, at tree-streamer-out.c:812
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61646 Markus Trippelsdorf changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Markus Trippelsdorf --- Closing.
[Bug tree-optimization/61964] [4.8 regression] krb5 database propagation enters infinite loop; reduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61964 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #5 from Mikael Pettersson --- I've been staring as this test case, and I cannot find any dereference of a wrong-typed pointer value. The only oddity I can find is that at if (n->prev == (void *)h) n == &node, n->prev == (struct node *)&heads[2] (so wrong-typed), h == &heads[2], so there is a '==' being applied to a wrong-typed pointer. Is that undefined behaviour? I'll note that changing the test to if ((void *)n->prev == (void *)h) still reproduces the wrong-code while looking technically Ok. Also, there is no out-of-bounds error.
[Bug lto/61868] -frandom-seed always results in random_seed of 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61868 Bingfeng Mei changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Bingfeng Mei --- Fixed in r213321
[Bug lto/61868] -frandom-seed always results in random_seed of 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61868 --- Comment #2 from meibf at gcc dot gnu.org --- Author: meibf Date: Thu Jul 31 08:50:50 2014 New Revision: 213321 URL: https://gcc.gnu.org/viewcvs?rev=213321&root=gcc&view=rev Log: 2014-07-31 Bingfeng Mei PR lto/61868 * toplev.c (init_random_seed): Move piece of code never called to set_random_seed. (set_random_seed): see above. * gcc.dg/pr61868.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr61868.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/toplev.c
[Bug target/61974] New: error: ‘ASM_WEAKEN_DECL’ was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61974 Bug ID: 61974 Summary: error: ‘ASM_WEAKEN_DECL’ was not declared in this scope Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: mliska at suse dot cz Host: x86_64 Target: rs6000-ibm-aix4.3 Attempting to build cross compiler for rs6000 target: ./configure --enable-languages=c --target=rs6000-ibm-aix4.3 Error: g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/../libbacktrace -o rs6000.o -MT rs6000.o -MMD -MP -MF ./.deps/rs6000.TPo ../../gcc/config/rs6000/rs6000.c ../../gcc/config/rs6000/rs6000.c: In function ‘bool rs6000_declare_alias(symtab_node*, void*)’: ../../gcc/config/rs6000/rs6000.c:29612:50: error: ‘ASM_WEAKEN_DECL’ was not declared in this scope ASM_WEAKEN_DECL (data->file, n->decl, name, NULL);
[Bug c++/58408] [C++11] __thread + trivially_constructible -> error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58408 Nadav Har'El changed: What|Removed |Added CC||nyh at math dot technion.ac.il --- Comment #2 from Nadav Har'El --- I don't think should be considered a bug. "__thread" doesn't get a chance to run the object's constructor, so the constructor must be constexpr, meaning that the compiler can figure out, in compile type, the string of bytes needed to initialize this object, and put it proper section of the executable (the standard C library then copies this TLS area for each new thread). So you just need to mark your constructor "constexpr", and your code will work. It is arguable that the compiler could figure out that your constructor *can be* constexpr, even if you don't tell it that it is (since when you do tell it is, it already has the machinary to verify), but I'm not sure why it is worth the hassle?
[Bug lto/61967] regression: cannot link with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61967 --- Comment #7 from Дилян Палаузов --- (In reply to Andrew Pinski from comment #6) > (In reply to Дилян Палаузов from comment #5) > > Using gcc-ar instead of ar does not help: > > > > $grep AR\ = Makefile > > AR = gcc-ar > > ... > > > ranlib libgnu.a > > You need to use gcc-ranlib too otherwise the symbol table is also messed up. Okay, using gcc-ranlib did help.
[Bug c++/61973] New: __thread and deleted destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61973
Bug ID: 61973
Summary: __thread and deleted destructor
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nyh at math dot technion.ac.il
Hi, right now "__thread" insists that the given type has a trivial destructor.
There is unfortunately no way to silence this error, even when I deliberately
want this (e.g., I know I'll call ~T() explicitly in another way).
I figured out a way (see below) to *delete* a type's destructor, using a union
(see below). However, __thread only accepts a trivial destructor, not a deleted
destructor. Is there a reason __thread cannot accept a type with a deleted
destructor?
Bonus points to anyone who can figure out how I can use __thread (not
thread_local) on a type with a non-trivial destructor even in existing gcc ;-)
The code to "delete" a type's destructor:
template
class mask_destructor {
private:
union {
alignas(T) char bytes[sizeof(T)];
T obj;
};
public:
T& get() const { return obj; }
// preserve T's constexpr constructor
constexpr mask_destructor() : obj() { }
mask_destructor(const mask_destructor &other) : obj(other.obj) { }
mask_destructor &operator=(const mask_destructor &other){
obj = other.obj;
return *this;
}
// Note no destructor defined. The compile implicitly deletes it
// because of the anonymous union above.
};
