[Bug debug/53235] [4.8 Regression] 20120504 broke -fdebug-types-section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53235 Jan Kratochvil changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | --- Comment #7 from Jan Kratochvil 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 changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #1 from Mark Wielaard 2012-05-19 13:47:00 UTC --- This looks like bug #39177 which should have been fixed by: 2009-10-21 Richard Guenther 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 changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Mark Wielaard 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 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 changed: What|Removed |Added Summary|multiple assignments can be |optimize multiple movb into |optimized |a single movl --- Comment #1 from Daniel Marjamäki 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 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 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 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 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 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 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 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 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 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 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 2012-05-19 19:44:13 UTC --- To clarify a little. The objdump output from my code example is: : 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 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 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 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 Y&’ 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 Y&()’ 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 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 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 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
.file"x.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
.ident"GCC: (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 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 to continue, or q 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 , 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 , 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 , ---Type to continue, or q 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 , 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 , 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 , fallback=0) at ../../gcc/gcc/gimplify.c:7085 #29 0x00e5254c in gimplify_stmt (stmt_p=0x7ab944a8, seq_p=0x7b043930) ---Type to continue, or q 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 , 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 , fallback=0) at ../../gcc/gcc/gimplify.c:7299 #35 0x00e5254c in gimplify_stmt (stmt_p=0x7ab944b8, seq_p=0x7b042760) at ../../gcc/gcc/gimplify.c:5662 #36 0x00e2f0a8 in gimplify_statement_list (expr_p=0x7abf3ad8, pre_p=0x7b042760) at ../../gcc/gcc/gimplify.c:152
[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 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 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 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 changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #5 from Andrew Pinski 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 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 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 changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #19 from Dominique d'Humieres 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 changed: What|Removed |Added CC||daniel.marjamaki at gmail ||dot com --- Comment #25 from Andrew Pinski 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 changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #3 from Andrew Pinski 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 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.
[Bug bootstrap/53423] New: gcc/32/crtbegin.o: wrong ELF class: ELFCLASS64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53423
Bug #: 53423
Summary: gcc/32/crtbegin.o: wrong ELF class: ELFCLASS64
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: keith_o...@hotmail.com
buliding {objectdir}/gcc/32 all files are built using the -m64 option, but the
linker uses -m32 and -m64, and since all files are 64-bit, the link fails.
configure is setup as the solaris 10 specific
CC=gcc -m64
/home/keith/src/gcc-4.7.0/configure \
--enable-languages=c,c++,fortran \
--prefix=/usr/local \
--with-as=/usr/ccs/bin/as \
--without-gnu-ld \
--with-ld=/usr/ccs/bin/ld \
--with-boot-ldflags=-m64 \
--with-stage1-ldflags=-m64 \
--enable-bootstrap \
--enable-shared \
--target=x86_64-pc-solaris2.10
/bin/bash /home/keith/src/gcc-4.7.0/libgcc/../mkinstalldirs 32
mkdir 32
/home/keith/src/gcc-obj/./gcc/xgcc -B/home/keith/src/gcc-obj/./gcc/
-B/usr/local/x86_64-pc-solaris2.10/bin/ -B/usr/local/x86_64-pc-solaris2.10/lib/
-isystem /usr/local/x86_64-pc-solaris2.10/include -isystem
/usr/local/x86_64-pc-solaris2.10/sys-include-O2 -g -m64 -DIN_GCC -W
-Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -fpic -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector -shared -nodefaultlibs
-Wl,-h,libgcc_s.so.1 -Wl,-z,text -Wl,-z,defs -Wl,-M,libgcc.map -o
32/libgcc_s.so.1.tmp -g -m64 -m32 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o
_ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o
_trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o
_subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o
_ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o
_ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o
_paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o
_muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o
_divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o
_fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o
_fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o
_floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o
_floatundixf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o
_udiv_w_sdiv_s.o _udivmoddi4_s.o tf-signs_s.o addtf3_s.o divtf3_s.o eqtf2_s.o
getf2_s.o letf2_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o
fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o
floatditf_s.o floatunditf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o
trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o enable-execute-stack_s.o
unwind-dw2_s.o unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o
-lc && rm -f 32/libgcc_s.so && if [ -f 32/libgcc_s.so.1 ]; then mv -f
32/libgcc_s.so.1 32/libgcc_s.so.1.backup; else true; fi && mv
32/libgcc_s.so.1.tmp 32/libgcc_s.so.1 && ln -s libgcc_s.so.1 32/libgcc_s.so
ld: fatal: file /home/keith/src/gcc-obj/./gcc/32/crtbegin.o: wrong ELF class:
ELFCLASS64
ld: fatal: file processing errors. No output written to 32/libgcc_s.so.1.tmp
collect2: error: ld returned 1 exit status
make[5]: *** [libgcc_s.so] Error 1
make[5]: Leaving directory
`/export/home/keith/src/gcc-obj/x86_64-pc-solaris2.10/32/libgcc'
make[4]: *** [multi-do] Error 1
make[4]: Leaving directory
`/export/home/keith/src/gcc-obj/x86_64-pc-solaris2.10/libgcc'
make[3]: *** [all-multi] Error 2
make[3]: Leaving directory
`/export/home/keith/src/gcc-obj/x86_64-pc-solaris2.10/libgcc'
make[2]: *** [all-stage1-target-libgcc] Error 2
make[2]: Leaving directory `/export/home/keith/src/gcc-obj'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/export/home/keith/src/gcc-obj'
make: *** [bootstrap] Error 2
[Bug c/53424] dynamic array expressions get wrong sizeof() if pointers to const are involved and the pointers are changed (const is misapplied to the whole expression)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53424 --- Comment #1 from Frank Barrus 2012-05-20 05:31:02 UTC --- Of particular attention, look at the example function "negativesizeof2". It's not just the sizeof() function returning the incorrect size. In this case, the pointer change retroactively changed the size of a struct already declared, and which a variable was instantiated from. And it didn't just change it for sizeof(). Pointer arithmetic is actually wrong, and the size is negative. So a step forward actually goes backwards!
[Bug c/53424] New: dynamic array expressions get wrong sizeof() if pointers to const are involved and the pointers are changed (const is misapplied to the whole expression)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53424
Bug #: 53424
Summary: dynamic array expressions get wrong sizeof() if
pointers to const are involved and the pointers are
changed (const is misapplied to the whole expression)
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcc...@shaggy.cc
Created attachment 27448
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27448
compile with -std=c99, optimization on or off
If a dynamic array on the stack is declared using an expression with a pointer
to const, as follows:
int y[2] = {10,20};
const int *x = y;
char buf[*x];
Then changing x (which is valid, since it is *x that is const, not x), as
follows:
++x;
results in sizeof(buf) being something quite different than the size it was
originally created.
Removing the const makes it work as one would expect.
Changing sizeof(buf) after the buffer is allocated on the stack is a very
dangerous thing. If this pattern using expressions with const to initialize
the array is known to be in any code, it could probably be exploited to get
access to the stack, and thus could be a security concern.
The attached code generates pairs of functions that ought to be identical. The
only difference is the "const". The "works()" and "broken()" functions should
both return 10. The "crashes()" and "nocrash()" functions should both assign
to the last byte of the array on the stack (index 9), but the crashing one
tries to assign it far beyond those bounds, using the 3rd element of array y
just because x got moved.
The const is being misapplied to treat the entire array initializer as a
constant expression, so the compiler appears to think it can simply re-evaluate
the expression as needed to get sizeof(buf), even though the pointer in the
expression has been changed.
The older gcc-4.2.1 LLVM compilers (Mac) I tried it on have the same bug.
