[Bug middle-end/52584] Fails to constant fold vector upper/lower half BIT_FIELD_REFs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52584 --- Comment #4 from davem at gcc dot gnu.org 2012-05-19 06:19:16 UTC --- Author: davem Date: Sat May 19 06:19:10 2012 New Revision: 187675 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187675 Log: Fix VIS3 vector shift wrong code generation on sparc. Backport r185385 from mainline. 2012-03-14 Richard Guenther rguent...@suse.de PR middle-end/52584 * tree-vect-generic.c (type_for_widest_vector_mode): Take element type instead of mode, use build_vector_type_for_mode instead of the langhook, build a vector of proper signedness. (expand_vector_operations_1): Adjust. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/tree-vect-generic.c
[Bug debug/53235] [4.8 Regression] 20120504 broke -fdebug-types-section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53235 Jan Kratochvil jan.kratochvil at redhat dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | --- Comment #7 from Jan Kratochvil jan.kratochvil at redhat dot com 2012-05-19 07:59:05 UTC --- Still getting for -fdebug-types-section regression against 2012-04-25 state: Running ./gdb.cp/koenig.exp ... FAIL: gdb.cp/koenig.exp: p foo(eo) FAIL: gdb.cp/koenig.exp: p foo(eo, eo) FAIL: gdb.cp/koenig.exp: p foo(eo, eo, 1) FAIL: gdb.cp/koenig.exp: p foo(fo, eo) FAIL: gdb.cp/koenig.exp: p foo(1 ,fo, eo) FAIL: gdb.cp/koenig.exp: p foo(go, fo, eo) FAIL: gdb.cp/koenig.exp: p foo(io) FAIL: gdb.cp/koenig.exp: p foo(ix) FAIL: gdb.cp/koenig.exp: p foo(ko,1) Running ./gdb.cp/m-static.exp ... FAIL: gdb.cp/m-static.exp: print svar +FAIL: gdb.ada/array_bounds.exp: print table'first (GDB internal error) +FAIL: gdb.ada/array_bounds.exp: print table'last (GDB internal error) +FAIL: gdb.ada/arrayidx.exp: print e_one_two_three, indexes off (GDB internal error) +ERROR: Process no longer exists +FAIL: gdb.ada/packed_tagged.exp: print x +FAIL: gdb.ada/packed_tagged.exp: ptype x +FAIL: gdb.ada/variant_record_packed_array.exp: print empty +FAIL: gdb.ada/whatis_array_val.exp: print full (GDB internal error) +FAIL: gdb.ada/whatis_array_val.exp: whatis $ But for example gdb.cp/class2.exp no longer regresses.
[Bug java/53400] java build failure with NullPointerException
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53400 Mark Wielaard mark at gcc dot gnu.org changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #1 from Mark Wielaard mark at gcc dot gnu.org 2012-05-19 13:47:00 UTC --- This looks like bug #39177 which should have been fixed by: 2009-10-21 Richard Guenther rguent...@suse.de PR cp-tools/39177 * tools/gnu/classpath/tools/jar/Creator.java (writeCommandLineEntries): Do not use uninitialized manifest.
[Bug java/53400] java build failure with NullPointerException
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53400 Mark Wielaard mark at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Mark Wielaard mark at gcc dot gnu.org 2012-05-19 13:50:25 UTC --- It is indeed a duplicate, you need to update your host gjar install since that is what contains the bug. *** This bug has been marked as a duplicate of bug 39177 ***
[Bug c/53416] New: 4.7.0 Wrong code when optimising loop involving _rdrand32_step
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53416 Bug #: 53416 Summary: 4.7.0 Wrong code when optimising loop involving _rdrand32_step Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: marcel.k...@fu-berlin.de Created attachment 27440 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27440 Reduced test case The attached file prints different output depending whether it is compiled with -O0, -O1 or -O2 on gcc-Version 4.7.0 20120507 (Red Hat 4.7.0-5) (GCC). When the file is built with gcc -std=c99 -mrdrnd -O0 rngtest.i, it prints four different random numbers. If it is built with gcc -std=c99 -mrdrnd -O1 rngtest.i, it prints the same number four times. If it is built with gcc -std=c99 -mrdrnd -O2 rngtest.i, it prints the random number four times and prints the random number as the result of the call to _rdrand32_step. The last one is especially surprising, because _rdrand32_step should only return 0 or 1.
[Bug target/53283] [4.8 Regression] Many failures on x86_64-apple-darwin10 after revision 186789
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53283
--- Comment #6 from Iain Sandoe iains at gcc dot gnu.org 2012-05-19 16:51:27
UTC ---
Created attachment 27441
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27441
fix (bootstrapped *darwin9,10, lightly tested).
.. well Darwin was already using TARGET_FOLD_BUILTIN which has now been
over-ridden in i386.c, leading to the breakage of CFString.
FWIW: since darwin has several targets - we try to keep common stuff in
config/darwin* .. so it's always worth a quick check there, as well as in
config/{i386,rs6000}/
The attached patch bootstrapped on *86*-darwin9/10, ppc-darwin9 - lightly
tested ... needs checking on Darwin11.
[Bug rtl-optimization/53417] New: multiple assignments can be optimized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53417
Bug #: 53417
Summary: multiple assignments can be optimized
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.marjam...@gmail.com
Hello!
It seems to me that assignments can be optimised more.
Example code:
struct X {
char a;
char b;
char c;
char d;
};
void dummy(struct X *x1);
void f() {
struct X x = {0,0,0,0};
dummy(x);
}
I compile that and look at the assembly code:
gcc -c -O2 test1.c
objdump -d test1.o
In the assembly output the struct is initialized using 4 movb instructions.
I wonder if there can't be an optimizer pass that replace these 4 movb
instructions with a single movl instruction. I assume that would be faster.
[Bug rtl-optimization/53417] optimize multiple movb into a single movl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53417 Daniel Marjamäki daniel.marjamaki at gmail dot com changed: What|Removed |Added Summary|multiple assignments can be |optimize multiple movb into |optimized |a single movl --- Comment #1 from Daniel Marjamäki daniel.marjamaki at gmail dot com 2012-05-19 17:29:18 UTC --- I changed the title a little. I hope it's more clear
[Bug c/53410] [4.8 Regression] ICE in build_int_cst_wide, at tree.c:1219
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53410 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-19 CC||rguenth at gcc dot gnu.org Target Milestone|--- |4.8.0 Summary|ICE in build_int_cst_wide, |[4.8 Regression] ICE in |at tree.c:1219 |build_int_cst_wide, at ||tree.c:1219 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-05-19 17:42:38 UTC --- It is caused by revision 186488: http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00439.html
[Bug java/53400] java build failure with NullPointerException
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53400 --- Comment #3 from John T jrt at worldlinc dot net 2012-05-19 18:24:12 UTC --- Updating it isn't possible as far as I know. If I removed java (and that may not be possible either due to dependencies) or at least gjar, would gcc-java build me a new one?
[Bug target/53383] Allow -mpreferred-stack-boundary=3 on x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383 --- Comment #8 from Jan Hubicka hubicka at ucw dot cz 2012-05-19 19:14:18 UTC --- __int128 do not require SSE and yet it is 128bit aligned I am not against allowing smaller alignments, we just need to document it breaks ABI and it would be nice to explain how (and probably warn on 128bit aligned varargs or force the dynamc alignment)
[Bug middle-end/53418] New: ICE at gimplify.c:7773
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53418
Bug #: 53418
Summary: ICE at gimplify.c:7773
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mer...@savhon.org
GCC (4.5.3 / 4.6.3 / 4.8.0 as of 20120519) fails to compile this very simple
line.
$ cat file.c
void func(void)
{
int i = (0 ? 1 : 0xCD03BE72 / 0);
}
$ ~/gcc/dist/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/merkil/gcc/dist/bin/gcc
COLLECT_LTO_WRAPPER=/home/merkil/gcc/dist/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../srcdir/configure --prefix=/home/merkil/gcc/dist CFLAGS='-O2
-pipe' CXXFLAGS='-O2 -pipe' --enable-languages=c,c++,lto
Thread model: posix
gcc version 4.8.0 20120519 (experimental) (GCC)
$ ~/gcc/dist/bin/gcc file.c
file.c: In function ‘func’:
file.c:3:33: internal compiler error: in gimplify_expr, at gimplify.c:7773
int i = (0 ? 1 : 0xCD03BE72 / 0);
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Hope that helps !
[Bug c++/40821] C++ compiler accepts __attribute__ with missing parens
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40821 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED CC|gcc-bugs at gcc dot gnu.org | AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-19 18:48:13 UTC --- Mine.
[Bug bootstrap/53321] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53321 --- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2012-05-19 18:14:17 UTC --- (In reply to comment #5) I need to add disable-werror otherwise we fail on extra warnings, but with that my bootstrap works. Is it still failing for you? The unreferenced nodes removal is very basic thing so when it breaks it should show up quite consistently. It still fails for me. Did you configure GCC with --with-build-config=bootstrap-lto?
[Bug tree-optimization/53419] New: loop incorrectly optimized to endless loop at -O2 for table delimited by extern addresses (x86-32)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419
Bug #: 53419
Summary: loop incorrectly optimized to endless loop at -O2 for
table delimited by extern addresses (x86-32)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@intrepid.com
Host: x86-32
Target: x86-32
The attached test case, duplicated below yields an infinite loop when compiled
by GCC 4.8 trunk version 187666. This appears to be a relatively recent
regression
(likely between 185454 and 186243).
typedef unsigned int size_t;
typedef void (*func_ptr_t) (void);
extern func_ptr_t init_array_begin[1];
extern func_ptr_t init_array_end[1];
void
per_thread_init (void)
{
size_t n_init = (init_array_end - init_array_begin);
int i;
for (i = 0; i n_init; ++i)
{
func_ptr_t init_func = init_array_begin[i];
if (init_func)
(*init_func) ();
}
}
At -O1, the loop looks like this:
.L4:
movlinit_array_begin(,%ebx,4), %eax
testl %eax, %eax
je .L3
call*%eax
.L3:
addl$1, %ebx
cmpl%esi, %ebx
jne .L4
At -O2 it looks like this.
.L5:
movlinit_array_begin, %eax
testl %eax, %eax
je .L3
call*%eax
.L3:
cmpl$1, %ebx
jne .L5
The comparison cmpl$1, %ebx is problematic, as well as the lack of
indexing the array.
[Bug tree-optimization/53419] loop incorrectly optimized to endless loop at -O2 for table delimited by extern addresses (x86-32)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419 --- Comment #1 from Gary Funck gary at intrepid dot com 2012-05-19 19:41:25 UTC --- Created attachment 27442 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27442 test case demonstrating endless loop at -O2 on x86-32
[Bug tree-optimization/53419] loop incorrectly optimized to endless loop at -O2 for table delimited by extern addresses (x86-32)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419 --- Comment #2 from Gary Funck gary at intrepid dot com 2012-05-19 19:42:47 UTC --- Created attachment 27443 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27443 correct code generated at -O1
[Bug tree-optimization/53419] loop incorrectly optimized to endless loop at -O2 for table delimited by extern addresses (x86-32)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419 --- Comment #3 from Gary Funck gary at intrepid dot com 2012-05-19 19:43:25 UTC --- Created attachment 27444 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27444 endless loop generated at -O2
[Bug rtl-optimization/53417] optimize multiple movb into a single movl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53417 --- Comment #2 from Daniel Marjamäki daniel.marjamaki at gmail dot com 2012-05-19 19:44:13 UTC --- To clarify a little. The objdump output from my code example is: f: 0:48 83 ec 18 sub$0x18,%rsp 4:48 89 e7 mov%rsp,%rdi 7:c6 04 24 00 movb $0x0,(%rsp) b:c6 44 24 01 00 movb $0x0,0x1(%rsp) 10:c6 44 24 02 00 movb $0x0,0x2(%rsp) 15:c6 44 24 03 00 movb $0x0,0x3(%rsp) 1a:e8 00 00 00 00 callq 1f f+0x1f 1f:48 83 c4 18 add$0x18,%rsp 23:c3 retq I guess it would be better ifthose movb was replaced with a movl.
[Bug c/53408] [4.6/4.7/4.8 Regression] ICE in get_initial_def_for_induction, at tree-vect-loop.c:3222
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53408 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-19 CC||rguenth at gcc dot gnu.org Target Milestone|--- |4.6.4 Summary|ICE in |[4.6/4.7/4.8 Regression] |get_initial_def_for_inducti |ICE in |on, at |get_initial_def_for_inducti |tree-vect-loop.c:3222 |on, at ||tree-vect-loop.c:3222 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-05-19 20:16:33 UTC --- It is caused by revision 167378: http://gcc.gnu.org/ml/gcc-cvs/2010-12/msg00059.html
[Bug c++/53421] New: __attribute((__may_alias__)) prevents taking address of conversion operator member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53421 Bug #: 53421 Summary: __attribute((__may_alias__)) prevents taking address of conversion operator member function Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: jeffrey.hellr...@gmail.com Created attachment 27446 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27446 source file exhibiting the bug when compiled Compiling attached main.cpp gives the following error: jeffrey@ubuntu:~/scratch$ g++ -o scratch main.cpp main.cpp: In function ‘int main(int, char**)’: main.cpp:21:6: error: ‘operator YX’ is not a member of ‘X’ However, no error occurs with any of the following changes: (a) Removing the __attribute__((__may_alias__)) (commenting in line 3 and commenting out line 4). (b) Removing the implementation (line 8) or using a throwing implementation (line 9) rather than the present implementation (line 10). (c) Replacing the conversion operator with a regular member function (commenting out lines 10,21 and commenting in lines 11,22 or 12,22. Further investigation reveals a possibly related error. One can define the function out-of-line (commenting in lines 8,16 and commenting out line 10) with no error, as long as line 15 remains commented out; additionally commenting in line 15 gives the following error: jeffrey@ubuntu:~/scratch$ g++ -o scratch main.cpp main.cpp:16:20: error: no ‘X::operator YX()’ member function declared in class ‘X’ This error still appears if one uses a throwing implementation (like in (b)) or replaces the conversion operator with a regular member function (like in (c)), but no error occurs with the removal of the __attribute__((__may_alias__)) (as in (a)).
[Bug middle-end/53409] [4.7/4.8 Regression] ICE: vector VEC(vec_void_p,base) index domain error, in vinfo_for_stmt at tree-vectorizer.h:630
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53409 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-19 Component|c |middle-end CC||rguenth at gcc dot gnu.org Ever Confirmed|0 |1 Summary|ICE: vector |[4.7/4.8 Regression] ICE: |VEC(vec_void_p,base) index |vector VEC(vec_void_p,base) |domain error, in|index domain error, in |vinfo_for_stmt at |vinfo_for_stmt at |tree-vectorizer.h:630 |tree-vectorizer.h:630 Target Milestone|--- |4.7.1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-05-19 20:30:50 UTC --- It is caused by revision 171734: http://gcc.gnu.org/ml/gcc-cvs/2011-03/msg01160.html:
[Bug target/53264] gcc/gcov-io.c and gcc/libgcov.c fail to compile (target vxWorks - gcc 4.7.0)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53264 --- Comment #2 from rbmj at verizon dot net 2012-05-19 20:39:14 UTC --- ping? I retagged with component:target, in hopes that someone will see. It's trivial - it shouldn't be an issue.
[Bug target/53383] Allow -mpreferred-stack-boundary=3 on x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383
--- Comment #9 from H.J. Lu hjl.tools at gmail dot com 2012-05-19 21:03:10
UTC ---
With this patch:
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index eca542c..3e4e768 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3660,9 +3660,14 @@ ix86_option_override_internal (bool main_args_p)
ix86_preferred_stack_boundary = PREFERRED_STACK_BOUNDARY_DEFAULT;
if (global_options_set.x_ix86_preferred_stack_boundary_arg)
{
- int min = (TARGET_64BIT ? 4 : 2);
+ int min;
int max = (TARGET_SEH ? 4 : 12);
+ if (TARGET_64BIT)
+min = TARGET_SSE ? 4 : 3;
+ else
+min = 2;
+
if (ix86_preferred_stack_boundary_arg min
|| ix86_preferred_stack_boundary_arg max)
{
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index ddb3645..f7f13d2 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -708,7 +708,7 @@ enum target_cpu_default
#define MAIN_STACK_BOUNDARY (TARGET_64BIT ? 128 : 32)
/* Minimum stack boundary. */
-#define MIN_STACK_BOUNDARY (TARGET_64BIT ? 128 : 32)
+#define MIN_STACK_BOUNDARY (TARGET_64BIT ? (TARGET_SSE ? 128 : 64) : 32)
/* Boundary (in *bits*) on which the stack pointer prefers to be
aligned; the compiler cannot rely on having this alignment. */
I got
[hjl@gnu-mic-2 gcc]$ cat /tmp/x.c
extern __int128 x;
extern void bar (int, int, int, int, int, __int128);
void
foo (void)
{
bar (1, 2, 3, 4, 5, x);
}
[hjl@gnu-mic-2 gcc]$ ./xgcc -B./ -S -O2 /tmp/x.c -mpreferred-stack-boundary=3
-mno-sse
[hjl@gnu-mic-2 gcc]$ cat x.s
.filex.c
.text
.p2align 4,,15
.globlfoo
.typefoo, @function
foo:
.LFB0:
.cfi_startproc
pushq%rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movl$5, %r8d
movl$4, %ecx
movl$2, %esi
movl$1, %edi
movq%rsp, %rbp
.cfi_def_cfa_register 6
andq$-16, %rsp
subq$16, %rsp
movqx+8(%rip), %rdx
movqx(%rip), %rax
movq%rdx, 8(%rsp)
movq%rax, (%rsp)
movl$3, %edx
callbar
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.sizefoo, .-foo
.identGCC: (GNU) 4.8.0 20120519 (experimental)
.section.note.GNU-stack,,@progbits
[hjl@gnu-mic-2 gcc]$
It looks OK to me.
[Bug c/53420] [4.8 Regression] ICE in iterative_hash_expr, at tree.c:7039
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53420 --- Comment #1 from John David Anglin danglin at gcc dot gnu.org 2012-05-19 20:43:48 UTC --- (gdb) bt #0 fancy_abort (file=0x45808b0 ../../gcc/gcc/tree.c, line=7039, function=0x45817d8 iterative_hash_expr) at ../../gcc/gcc/diagnostic.c:1011 #1 0x01887044 in iterative_hash_expr (t=0x7ab8a390, val=1358060887) at ../../gcc/gcc/tree.c:7039 #2 0x01887584 in iterative_hash_expr (t=0x7ac3f3a0, val=1358060887) at ../../gcc/gcc/tree.c:7072 #3 0x01887584 in iterative_hash_expr (t=0x7ab83b18, val=2819648034) at ../../gcc/gcc/tree.c:7072 #4 0x01887584 in iterative_hash_expr (t=0x7ab044e0, val=470452325) at ../../gcc/gcc/tree.c:7072 #5 0x01887584 in iterative_hash_expr (t=0x7ac3f3e0, val=1291600461) at ../../gcc/gcc/tree.c:7072 #6 0x01887584 in iterative_hash_expr (t=0x7ac3f400, val=1857436122) at ../../gcc/gcc/tree.c:7072 #7 0x01887584 in iterative_hash_expr (t=0x7ab04528, val=3933020094) at ../../gcc/gcc/tree.c:7072 #8 0x01887244 in iterative_hash_expr (t=0x7ab04558, val=2773392188) at ../../gcc/gcc/tree.c:7051 #9 0x01886880 in iterative_hash_expr (t=0x7ab943a0, val=3698532063) at ../../gcc/gcc/tree.c:6997 #10 0x00e27cdc in gimple_tree_hash (p=0x7b047c68) at ../../gcc/gcc/gimplify.c:130 ---Type return to continue, or q return to quit--- #11 0x0441ce60 in htab_find_slot (htab=0x400c1a08, element=0x7b047c68, insert=INSERT) at ../../gcc/libiberty/hashtab.c:712 #12 0x00e29170 in lookup_tmp_var (val=0x7ab943a0, is_formal=1 '\001') at ../../gcc/gcc/gimplify.c:528 #13 0x00e295f0 in internal_get_tmp_var (val=0x7ab943a0, pre_p=0x7b0457f0, post_p=0x0, is_formal=1 '\001') at ../../gcc/gcc/gimplify.c:610 #14 0x00e2999c in get_formal_tmp_var (val=0x7ab943a0, pre_p=0x7b0457f0) at ../../gcc/gcc/gimplify.c:651 #15 0x00e66bc0 in gimplify_expr (expr_p=0x7ac3f654, pre_p=0x7b0457f0, post_p=0x7b046718, gimple_test_f=@0x40029eea: 0xd5bfb8 is_gimple_min_lval, fallback=3) at ../../gcc/gcc/gimplify.c:7954 #16 0x00e360f4 in gimplify_compound_lval (expr_p=0x7ac3f678, pre_p=0x7b0457f0, post_p=0x7b046718, fallback=1) at ../../gcc/gcc/gimplify.c:2258 #17 0x00e60588 in gimplify_expr (expr_p=0x7ac3f678, pre_p=0x7b0457f0, post_p=0x7b046718, gimple_test_f=@0x4002a852: 0xe29388 is_gimple_reg_rhs_or_call, fallback=1) at ../../gcc/gcc/gimplify.c:7080 #18 0x00e4c0d4 in gimplify_modify_expr (expr_p=0x7ab943b8, pre_p=0x7b0457f0, post_p=0x7b046718, want_value=0 '\0') at ../../gcc/gcc/gimplify.c:4842 #19 0x00e606f0 in gimplify_expr (expr_p=0x7ab943b8, pre_p=0x7b0457f0, post_p=0x7b046718, gimple_test_f=@0x4002a8ba: 0xe4ac80 is_gimple_stmt, ---Type return to continue, or q return to quit--- fallback=0) at ../../gcc/gcc/gimplify.c:7127 #20 0x00e5254c in gimplify_stmt (stmt_p=0x7ab943b8, seq_p=0x7b0457f0) at ../../gcc/gcc/gimplify.c:5662 #21 0x00e2f0a8 in gimplify_statement_list (expr_p=0x7ac3f878, pre_p=0x7b0457f0) at ../../gcc/gcc/gimplify.c:1529 #22 0x00e63fac in gimplify_expr (expr_p=0x7ac3f878, pre_p=0x7b0457f0, post_p=0x7b045e98, gimple_test_f=@0x4002a8ba: 0xe4ac80 is_gimple_stmt, fallback=0) at ../../gcc/gcc/gimplify.c:7514 #23 0x00e5254c in gimplify_stmt (stmt_p=0x7ac3f878, seq_p=0x7b0457f0) at ../../gcc/gcc/gimplify.c:5662 #24 0x00e2ccfc in gimplify_bind_expr (expr_p=0x7ac3f898, pre_p=0x7b044ea0) at ../../gcc/gcc/gimplify.c:1223 #25 0x00e61e6c in gimplify_expr (expr_p=0x7ac3f898, pre_p=0x7b044ea0, post_p=0x7b045558, gimple_test_f=@0x4002a8ba: 0xe4ac80 is_gimple_stmt, fallback=0) at ../../gcc/gcc/gimplify.c:7299 #26 0x00e5254c in gimplify_stmt (stmt_p=0x7ac3f898, seq_p=0x7b044ea0) at ../../gcc/gcc/gimplify.c:5662 #27 0x00e41a6c in gimplify_cond_expr (expr_p=0x7ab944a8, pre_p=0x7b043930, fallback=0) at ../../gcc/gcc/gimplify.c:3305 #28 0x00e605a4 in gimplify_expr (expr_p=0x7ab944a8, pre_p=0x7b043930, post_p=0x7b044858, gimple_test_f=@0x4002a8ba: 0xe4ac80 is_gimple_stmt, fallback=0) at ../../gcc/gcc/gimplify.c:7085 #29 0x00e5254c in gimplify_stmt (stmt_p=0x7ab944a8, seq_p=0x7b043930) ---Type return to continue, or q return to quit--- at ../../gcc/gcc/gimplify.c:5662 #30 0x00e2f0a8 in gimplify_statement_list (expr_p=0x7ac3f8b8, pre_p=0x7b043930) at ../../gcc/gcc/gimplify.c:1529 #31 0x00e63fac in gimplify_expr (expr_p=0x7ac3f8b8, pre_p=0x7b043930, post_p=0x7b043fd8, gimple_test_f=@0x4002a8ba: 0xe4ac80 is_gimple_stmt, fallback=0) at ../../gcc/gcc/gimplify.c:7514 #32 0x00e5254c in gimplify_stmt (stmt_p=0x7ac3f8b8, seq_p=0x7b043930) at ../../gcc/gcc/gimplify.c:5662 #33 0x00e2ccfc in gimplify_bind_expr (expr_p=0x7ab944b8, pre_p=0x7b042760) at ../../gcc/gcc/gimplify.c:1223 #34 0x00e61e6c in gimplify_expr (expr_p=0x7ab944b8, pre_p=0x7b042760, post_p=0x7b043698, gimple_test_f=@0x4002a8ba: 0xe4ac80 is_gimple_stmt, fallback=0) at ../../gcc/gcc/gimplify.c:7299 #35 0x00e5254c in gimplify_stmt
[Bug c/53420] New: [4.8 Regression] ICE in iterative_hash_expr, at tree.c:7039
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53420
Bug #: 53420
Summary: [4.8 Regression] ICE in iterative_hash_expr, at
tree.c:7039
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
Host: hppa2.0w-hp-hpux11.00
Target: hppa2.0w-hp-hpux11.00
Build: hppa2.0w-hp-hpux11.00
Created attachment 27445
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27445
Preprocessed source
Following occurs in stage2:
/xxx/gnu/gcc/objdir/./prev-gcc/xgcc -B/xxx/gnu/gcc/objdir/./prev-gcc/
-B/opt/gnu
/gcc/gcc-4.8/hppa2.0w-hp-hpux11.00/bin/
-B/opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux1
1.00/bin/ -B/opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.00/lib/ -isystem
/opt/gnu/gc
c/gcc-4.8/hppa2.0w-hp-hpux11.00/include -isystem
/opt/gnu/gcc/gcc-4.8/hppa2.0w-h
p-hpux11.00/sys-include-c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND
-DIN_GCC_FRON
TEND -g -O2 -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wstr
ict-prototypes -Wmissing-prototypes -Wold-style-definition -Wc++-compat
-fno-co
mmon -DHAVE_CONFIG_H -I. -Ic-family -I../../gcc/gcc -I../../gcc/gcc/c-family
-I
../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
-I/opt/gnu/gcc/gmp/in
clude -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd
-I../
libdecnumber../../gcc/gcc/c-family/c-lex.c -o c-family/c-lex.o
In file included from ../../gcc/gcc/c-family/c-lex.c:23:0:
../../gcc/gcc/c-family/c-lex.c: In function 'c_lex_with_flags':
../../gcc/gcc/system.h:958:93: internal compiler error: in iterative_hash_expr,
at tree.c:7039
#define CONST_CAST2(TOTYPE,FROMTYPE,X) ((__extension__(union {FROMTYPE _q;
TOTY
PE _nq;})(X))._nq)
^
../../gcc/gcc/system.h:958:93: note: in expansion of macro 'CONST_CAST2'
#define CONST_CAST2(TOTYPE,FROMTYPE,X) ((__extension__(union {FROMTYPE _q;
TOTY
PE _nq;})(X))._nq)
^
../../gcc/gcc/system.h:977:28: note: expanded from here
#define CONST_CAST(TYPE,X) CONST_CAST2(TYPE, const TYPE, (X))
^
../../gcc/gcc/system.h:977:28: note: in expansion of macro 'CONST_CAST'
../../gcc/gcc/c-family/c-lex.c:355:12: note: expanded from here
str = CONST_CAST (char *, TREE_STRING_POINTER (num_string));^
# ./xgcc -B./ -v
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: hppa2.0w-hp-hpux11.00
Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu/bin/as
--enable-shared --with-local-prefix=/opt/gnu --prefix=/opt/gnu/gcc/gcc-4.8
--with-gmp=/opt/gnu/gcc/gmp --enable-debug=no --disable-nls
--disable-build-poststage1-with-cxx --enable-threads=posix
--enable-languages=c,c++,objc,fortran,java,ada,obj-c++
Thread model: posix
gcc version 4.8.0 20120518 (experimental) [trunk revision 187647] (GCC)
[Bug tree-optimization/53419] loop incorrectly optimized to endless loop at -O2 for table delimited by extern addresses (x86-32)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-05-19 CC||hjl.tools at gmail dot com Ever Confirmed|0 |1 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2012-05-19 20:34:32 UTC --- Do you have a self-contained run-time testcase?
[Bug target/53383] Allow -mpreferred-stack-boundary=3 on x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383
--- Comment #10 from Jan Hubicka hubicka at ucw dot cz 2012-05-19 21:47:39
UTC ---
The problem is va_args doing alignment based on stack pointer, i.e. in:
int
test (int a, ...)
{
va_list p;
va_start (p, a);
va_arg (p, int);
va_arg (p, int);
va_arg (p, int);
va_arg (p, int);
va_arg (p, int);
va_arg (p, int);
va_arg (p, int);
va_arg (p, int);
va_arg (p, int);
va_arg (p, int);
if (a)
va_arg (p, int);
return va_arg (p, __int128);
}
test:
.LFB0:
.cfi_startproc
leaq8(%rsp), %rax
movq%rdx, -40(%rsp)
movq%rsi, -48(%rsp)
movq%rcx, -32(%rsp)
movq%r8, -24(%rsp)
movq%rax, -72(%rsp)
leaq-56(%rsp), %rax
addq$8, -72(%rsp)
testl %edi, %edi
movq%r9, -16(%rsp)
movl$48, -80(%rsp)
movq%rax, -64(%rsp)
movq-72(%rsp), %rax
leaq32(%rax), %rdx
movq%rdx, -72(%rsp)
je .L14
addq$40, %rax
movq%rax, -72(%rsp)
.L14:
movq-72(%rsp), %rax
addq$15, %rax
andq$-16, %rax
leaq16(%rax), %rdx
movq%rdx, -72(%rsp)
movq(%rax), %rax
ret
.cfi_endproc
.LFE0:
this will get out of sync with hard coded offsets if rsp hapepns to be
misaligned.
[Bug tree-optimization/53419] loop incorrectly optimized to endless loop at -O2 for table delimited by extern addresses (x86-32)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2012-05-19 21:54:03 UTC --- extern func_ptr_t init_array_begin[1]; extern func_ptr_t init_array_end[1]; The array sizes say they are size of one. If you want to be correct and not allow GCC to optimize away the check because array overflow, use [] instead of [1].
[Bug tree-optimization/53419] loop incorrectly optimized to endless loop at -O2 for table delimited by extern addresses (x86-32)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419
--- Comment #6 from Gary Funck gary at intrepid dot com 2012-05-19 22:08:26
UTC ---
(In reply to comment #5)
extern func_ptr_t init_array_begin[1];
extern func_ptr_t init_array_end[1];
The array sizes say they are size of one. If you want to be correct and not
allow GCC to optimize away the check because array overflow, use [] instead of
[1].
Good point. Do you happen to know if
extern func_ptr_t init_array_begin[];
extern func_ptr_t init_array_end[];
is say, C89 compatible? I ask, because I thought I ran into problems with some
older compilers given the above syntax.
typedef unsigned int size_t;
typedef void (*func_ptr_t) (void);
extern func_ptr_t init_array_begin[1];
extern func_ptr_t init_array_end[1];
void
per_thread_init (void)
{
size_t n_init = (init_array_end - init_array_begin);
int i;
for (i = 0; i n_init; ++i)
{
func_ptr_t init_func = init_array_begin[i];
if (init_func)
(*init_func) ();
}
}
Questions regarding the optimization of the above.
If the compiler concludes that n_init must be 1, then code that creates an
endless loop is not a valid optimization?
Simplifying so that the loop executes only once might be, but I'm still having
a little trouble adjusting to that idea.
Is there an -f option that disables this sort of optimization?
1
[Bug tree-optimization/53419] loop incorrectly optimized to endless loop at -O2 for table delimited by extern addresses (x86-32)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53419 --- Comment #7 from Gary Funck gary at intrepid dot com 2012-05-19 22:11:42 UTC --- (In reply to comment #4) Do you have a self-contained run-time testcase? I wasn't able to create a run-time tester easily, because the code above relies upon external labels that are interposed at the beginning and end of a table, via separate compilation and linking. I can do that, but perhaps given Andrew's reply, that may be unnecessary.
[Bug tree-optimization/53346] [4.6/4.7/4.8 Regression] Bad vectorization in the proc cptrf2 of rnflow.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53346 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #19 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-05-19 22:19:02 UTC --- The change in timing occured at revision 163998 Author:matz Date:Wed Sep 8 12:34:52 2010 UTC (20 months, 1 week ago) Changed paths:4 Log Message: PR tree-optimization/33244 * tree-ssa-sink.c (statement_sink_location): Don't sink into empty loop latches. testsuite/ PR tree-optimization/33244 * gfortran.dg/vect/fast-math-vect-8.f90: New test. [macbook] test/dbg_rnflow% /opt/gcc/gcc4.6p-163997/bin/gfortran -c -O3 cptrf2.f90 [macbook] test/dbg_rnflow% makeo ; time a.out /dev/null 20.881u 0.345s 0:21.37 99.2%0+0k 3+0io 0pf+0w [macbook] test/dbg_rnflow% /opt/gcc/gcc4.6p-163998/bin/gfortran -c -O3 cptrf2.f90 [macbook] test/dbg_rnflow% makeo ; time a.out /dev/null 28.545u 0.351s 0:29.06 99.4%0+0k 3+0io 0pf+0w
[Bug middle-end/22141] [4.5/4.6/4.7/4.8 Regression] Missing optimization when storing structures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22141 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||daniel.marjamaki at gmail ||dot com --- Comment #25 from Andrew Pinski pinskia at gcc dot gnu.org 2012-05-19 23:31:40 UTC --- *** Bug 53417 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/53417] optimize multiple movb into a single movl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53417 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-05-19 23:31:40 UTC --- Dup of bug 22141 *** This bug has been marked as a duplicate of bug 22141 ***
[Bug target/53383] Allow -mpreferred-stack-boundary=3 on x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383 --- Comment #11 from H.J. Lu hjl.tools at gmail dot com 2012-05-20 02:04:40 UTC --- (In reply to comment #10) The problem is va_args doing alignment based on stack pointer, i.e. in: int return va_arg (p, __int128); } addq$15, %rax andq$-16, %rax This isn't necessary. If __int128 is put on stack by caller, the stack must be aligned at 16 bytes. leaq16(%rax), %rdx movq%rdx, -72(%rsp) movq(%rax), %rax ret .cfi_endproc .LFE0: this will get out of sync with hard coded offsets if rsp hapepns to be misaligned. I don't think it will happen.
[Bug rtl-optimization/53422] New: reduce the size of CODE_LABEL rtl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53422 Bug #: 53422 Summary: reduce the size of CODE_LABEL rtl Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@ics.uci.edu Created attachment 27447 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27447 reorder CODE_LABEL fields to reduce size CODE_LABEL has one field that is only used by the sh backend. It's kind of rude of a backend to pollute the cache and memory in all compilations. If the order of CODE_LABEL fields is changed so that the sh specific entry to be last, then it's easy to define CODE_LABEL conditionally so that it does not use that last entry on the rest of the machines. One field is only used by jump.c, if that's moved to a local data structure in jump.c, then more savings are possible, but that's much more complicated. BARRIER also has some unused fields that just pollute the cache. This simple patch is at least 5 years old, last updated a couple of years ago, attaching it here in hope that someone can pick it up and do whatever is needed to check it in. ChangeLog * rtl.def (CODE_LABEL): Reorder fields so that the sh specific entry is last. (BARRIER): Remove padding. * rtl.h (CODE_LABEL_NUMBER, LABEL_NAME, LABEL_NUSES, LABEL_REFS): * gengtype.c (adjust_field_rtx_def): Adjust for new CODE_LABEL field order.
