[Bug tree-optimization/47411] New: [4.5 Regression] Bootstrap failure on x86-64/Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47411
Summary: [4.5 Regression] Bootstrap failure on x86-64/Darwin
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ebotca...@gcc.gnu.org
The backport
2011-01-17 Richard Guenther rguent...@suse.de
PR tree-optimization/44592
* tree-ssa-ccp.c (gimplify_and_update_call_from_tree): Copy
from trunk.
has introduced a bootstrap failure for x86-64/Darwin on the 4.5 branch:
/lena.a/gnatmail/gcc-45/build-lena/obj/./prev-gcc/xgcc
-B/lena.a/gnatmail/gcc-45/build-lena/obj/./prev-gcc/
-B/usr/local/gnat/x86_64-apple-darwin10.2.0/bin/
-B/usr/local/gnat/x86_64-apple-darwin10.2.0/bin/
-B/usr/local/gnat/x86_64-apple-darwin10.2.0/lib/ -isystem
/usr/local/gnat/x86_64-apple-darwin10.2.0/include -isystem
/usr/local/gnat/x86_64-apple-darwin10.2.0/sys-include-c -O2 -gtoggle
-DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition
-Wc++-compat -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../src/gcc
-I../../src/gcc/build -I../../src/gcc/../include
-I../../src/gcc/../libcpp/include
-I/lena.a/gnatmail/gcc-45/build-lena/libmpfr/install/include
-I/lena.a/gnatmail/gcc-45/build-lena/libmpfr/install/include
-I/lena.a/gnatmail/gcc-45/build-lena/libmpfr/install/include
-I../../src/gcc/../libdecnumber -I../../s
rc/gcc/../libdecnumber/dpd -I../libdecnumber \
-o build/gengenrtl.o ../../src/gcc/gengenrtl.c
../../src/gcc/genmodes.c: In function 'new_mode':
../../src/gcc/genmodes.c:153:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
Reduced testcase to be attached for x86/Linux. The problem is that a new SSA
name is created in gimplify_and_update_call_from_tree:
Program received signal SIGSEGV, Segmentation fault.
0x085a0139 in vrp_finalize ()
at /home/eric/gnat/gnat6_45/src/gcc/tree-vrp.c:7338
7338BITMAP_FREE (vr_value[i]-equiv);
(gdb) p cfun-gimple_df-ssa_names.base
$12 = {num = 22, alloc = 50, vec = {0x0}}
Breakpoint 1, vrp_initialize ()
at /home/eric/gnat/gnat6_45/src/gcc/tree-vrp.c:5354
5354 vr_value = XCNEWVEC (value_range_t *, num_ssa_names);
(gdb) p cfun-gimple_df-ssa_names.base
$13 = {num = 21, alloc = 50, vec = {0x0}}
Hardware watchpoint 2: { unsigned int } 0xf7ca5a00
Old value = 21
New value = 22
0x0855e711 in VEC_tree_base_quick_push (
function_=0x8b7a17e make_ssa_name_fn, line_=146, obj_=0xf7d26d20,
vec_=0xf7ca5a00,
file_=0x8b7a0e8 /home/eric/gnat/gnat6_45/src/gcc/tree-ssanames.c)
at /home/eric/gnat/gnat6_45/src/gcc/tree.h:182
182 DEF_VEC_P(tree);
(gdb) bt
#0 0x0855e711 in VEC_tree_base_quick_push (
function_=0x8b7a17e make_ssa_name_fn, line_=146, obj_=0xf7d26d20,
vec_=0xf7ca5a00,
file_=0x8b7a0e8 /home/eric/gnat/gnat6_45/src/gcc/tree-ssanames.c)
at /home/eric/gnat/gnat6_45/src/gcc/tree.h:182
#1 VEC_tree_gc_safe_push (function_=0x8b7a17e make_ssa_name_fn, line_=146,
file_=0x8b7a0e8 /home/eric/gnat/gnat6_45/src/gcc/tree-ssanames.c,
obj_=0xf7d26d20, vec_=0xf7cae918)
at /home/eric/gnat/gnat6_45/src/gcc/tree.h:183
#2 make_ssa_name_fn (fn=0xf7cb2210, var=0xf7d29564, stmt=0xf7d26cc0)
at /home/eric/gnat/gnat6_45/src/gcc/tree-ssanames.c:146
#3 0x084dbcf0 in make_ssa_name (stmt=0xf7d26cc0, var=value optimized out)
at /home/eric/gnat/gnat6_45/src/gcc/tree-flow-inline.h:1247
#4 gimplify_and_update_call_from_tree (si_p=0xcd68,
expr=value optimized out)
at /home/eric/gnat/gnat6_45/src/gcc/tree-ssa-ccp.c:3434
[Bug tree-optimization/47411] [4.5 Regression] Bootstrap failure on x86-64/Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47411 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-22 09:41:19 UTC --- Created attachment 23075 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23075 Reduced testcase for x86 To be compiled at -O2.
[Bug c++/47317] [4.6 Regression][C++0x] ICE in fixed_type_or_null.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47317 --- Comment #4 from Pawel Sikora pluto at agmk dot net 2011-01-22 11:11:41 UTC --- (In reply to comment #3) Seems to have been fixed already, perhaps by my patch for 46977. yes, pure gcc works now but the recent fix-candidate http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01381.html causes a crash in fixed_type_or_null.
[Bug preprocessor/47311] [4.6 Regression][C++0x] ICE in tsubst @cp/pt.c:10502
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47311 --- Comment #25 from Pawel Sikora pluto at agmk dot net 2011-01-22 11:14:41 UTC --- (In reply to comment #24) A candidate fix was posted to http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01381.html with this patch the *current* gcc-trunk (with fixed PR47317) ICEs in fixed_type_or_null.
[Bug tree-optimization/47411] [4.5 Regression] Bootstrap failure on x86-64/Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47411 Geert Bosch bosch at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.22 12:08:12 CC||bosch at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Geert Bosch bosch at gcc dot gnu.org 2011-01-22 12:08:12 UTC --- I've confirmed that reverting Richard's patch to tree-ssa-ccp.c restores bootstrap. -Geert
[Bug lto/47410] Linker plugin specification makes it difficult to handle mixed IR/non-IR objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47410 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-01-22 13:28:06 UTC --- It is a linker bug, which has been fixed.
[Bug fortran/47399] [OOP] ICE with TBP of a PARAMETER
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47399 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-22 13:50:28 UTC --- Author: burnus Date: Sat Jan 22 13:50:25 2011 New Revision: 169126 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169126 Log: 2011-01-22 Tobias Burnus bur...@net-b.de PR fortran/47399 * primary.c (gfc_match_varspec): Relax gcc_assert to allow for PARAMETER TBP. 2011-01-22 Tobias Burnus bur...@net-b.de PR fortran/47399 * gfortran.dg/typebound_proc_19.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_proc_19.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog
[Bug libfortran/47285] G format outputs wrong number of characters when decimal supplied in literal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47285 --- Comment #4 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-01-22 13:53:52 UTC --- Created attachment 23076 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23076 A possible patch This patch seems to be acceptable. I add a try return value to output float to communicate when the field width is not successful. Oddly, I had to make an adjustment to the exponent width to take care of a case that returns successfully. if (e 4)\ e = 4;\ This seems to work, but I wonder if I have a latent bug within. This patch does regression test OK. I thought I would let others play with it before I submit.
[Bug c++/47412] New: Output: x = 31 but y = 30
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47412
Summary: Output: x = 31 but y = 30
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: msarsha...@gmail.com
#include stdio.h
int main() {
int x, y;
x = 10;
x = 20 + x++;
printf(x = %d\n, x);
x = 10;
y = 20 + x++;
printf(y = %d\n, y);
return 0;
}
Output of above program:
x = 31
y = 30
x have to be 30
[Bug c++/47412] Output: x = 31 but y = 30
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47412 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-22 14:16:26 UTC --- (In reply to comment #0) x = 20 + x++; This is undefined behaviour because there is no sequence point between the increment and the assignment. Compiling with -Wall warns you about it
[Bug fortran/47296] I/O Segfault when running out of file descriptors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47296 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-01-22 14:23:45 UTC --- Patch committed: Sendinglibgfortran/ChangeLog Sendinglibgfortran/io/unix.c Transmitting file data .. Committed revision 16. Thanks. Closing
[Bug fortran/47293] libquadmath: strtoflt128 - NAN not correctly read and C99 hex floating point format missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47293 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added CC||jvdelisle at gcc dot ||gnu.org AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot |gnu.org |gnu.org --- Comment #2 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-01-22 14:25:52 UTC --- Taking this one
[Bug c++/47412] Output: x = 31 but y = 30
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47412
HM hamotahari at gmail dot com changed:
What|Removed |Added
CC||hamotahari at gmail dot com
--- Comment #2 from HM hamotahari at gmail dot com 2011-01-22 15:51:21 UTC ---
(In reply to comment #1)
(In reply to comment #0)
x = 20 + x++;
This is undefined behaviour because there is no sequence point between the
increment and the assignment.
Compiling with -Wall warns you about it
I know the word the behavior is undefined, and then this can not be a bug.
But I wrote this code in Java as the below:
public class TestXPP {
/**
* @param args
*/
public static void main(String[] args) {
int x = 10;
x = 20 + x++;
System.out.println(X is: + x);
x = 10;
int y = 20 + x++;
System.out.println(Y is: + y);
}
}
And the output, both are 30:
X is: 30
Y is: 30
It seems interesting for me. It means Java doesn't assume it as an undefined
behavior point or at least Java's compiler does in a unique way and doesn't
care about being X or Y.
Can anyone explain it?
[Bug tree-optimization/47190] [4.5/4.6 Regression] ICE: in function_and_variable_visibility, at ipa.c:934 with static weakref variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47190 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org |gnu.org | --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-22 15:52:07 UTC --- Testing patch...
[Bug tree-optimization/47193] [4.6 Regression] ICE: in function_and_variable_visibility, at ipa.c:857 with static var weakref'd to other weakref'd static var
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47193 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-22 15:54:35 UTC --- Seems to work for me now. Probably fixed with other aliasing changes. jh@gcc10:~/trunk/build/gcc$ cat weak2.c typedef int vtype; static vtype Wv10a __attribute__((weakref (Wv10b))); static vtype Wv10b __attribute__((weakref (Wv10c))); static vtype Wv10c __attribute__((weakref (Wv10d))); static vtype Wv10d __attribute__((weakref (wv10))); extern vtype wv10; jh@gcc10:~/trunk/build/gcc$ ./xgcc -B ./ weak2.c /usr/lib/../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: ld returned 1 exit status jh@gcc10:~/trunk/build/gcc$ cat weak3.c static int i __attribute__ ((weakref (j))); static int j __attribute__ ((weakref (k))); jh@gcc10:~/trunk/build/gcc$ ./xgcc -B ./ weak3.c /usr/lib/../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: ld returned 1 exit status
[Bug c/21659] [4.3/4.4/4.5/4.6 Regression] [unit-at-a-time] weak declaration must precede definition error missing at = O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21659 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org |gnu.org | Known to fail|| --- Comment #10 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-22 16:04:49 UTC --- I think with unit-at-a-time mode for all compilation settings, we should just drop the restriction. Will make patch.
[Bug lto/47410] Linker plugin specification makes it difficult to handle mixed IR/non-IR objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47410 --- Comment #2 from Jan Hubicka hubicka at ucw dot cz 2011-01-22 16:06:27 UTC --- How it was fixed?
[Bug lto/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44334 --- Comment #24 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-22 16:23:49 UTC --- PR 43884 has similar problem with deep loop nests.
[Bug target/43884] [4.4/4.5/4.6 Regression] Performance degradation for simple fibonacci numbers calculation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43884 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org |gnu.org | --- Comment #19 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-22 16:24:36 UTC --- The profile is consistent, but due to recursive inlining we create deep loop nest in the function making profile estimation to believe that code outside the loop nest is cold. Path for PR44334 should cure this testcase too. I will look into if I can get the testsuite updated and the patch comitted.
[Bug lto/47410] Linker plugin specification makes it difficult to handle mixed IR/non-IR objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47410 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2011-01-22 16:49:54 UTC --- (In reply to comment #2) How it was fixed? It is very trivial. Linker just needs to add the object-only file to input file list: http://git.kernel.org/?p=devel/binutils/hjl/x86.git;a=patch;h=31ef643b40d1fe0953d2acf465d06d9175b56b79
[Bug fortran/47348] wrong string length with array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47348 --- Comment #5 from paul.richard.thomas at gmail dot com paul.richard.thomas at gmail dot com 2011-01-22 16:50:00 UTC --- Dear Thomas, Paul, this is a case of something (trans-*?) picking up the wrong string length and ignoring the substring. Do you have any idea where to start looking? Almost certainly. I am very busy right now with reallocation in scalar assignments. I'll flag this one up. cheers Paul
[Bug tree-optimization/47413] New: Constant Propagation and Virtual Function Tables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47413
Summary: Constant Propagation and Virtual Function Tables
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jo...@joergleis.com
The tested GCC version does not fully use its knowledge about (constant)
function pointers. In some cases (with LTO), this occurs frequently. The
following example should illustrate it and it's relevance:
#include stdio.h
#include stdlib.h
/* the types */
struct obj;
struct vtab {
int (*f)(struct obj *obj);
};
struct obj {
const struct vtab *vtab;
};
static int f1337(struct obj *obj)
{
return 1337;
}
static const struct vtab vtab1337 = {
.f = f1337
};
/* the functions */
static struct obj *create()
{
struct obj *obj;
if (!(obj = malloc(sizeof(struct obj {
return NULL;
}
obj-vtab = vtab1337;
return obj;
}
static int call(struct obj *obj)
{
return obj-vtab-f(obj);
}
/* the program */
int main()
{
struct obj *obj;
if (!(obj = create())) {
return 0;
}
printf(%d\n, call(obj));
return 1;
}
When compiling with -O3, I'd expect GCC to just pass 1337 to printf, as it does
without a virtual function table. Instead, it uses its knowledge about obj to
call vtab1337.f(), as in
call *vtab1337
but doesn't simplify *vtab1337 to f1337, or the entire call to 1337.
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr-ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536 --- Comment #21 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-01-22 17:30:27 UTC --- Author: tkoenig Date: Sat Jan 22 17:30:22 2011 New Revision: 169130 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169130 Log: 2011-01-22 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/38536 * resolve.c (gfc_iso_c_func_interface): For C_LOC, check for array sections followed by component references which are illegal. Also check for coindexed arguments. 2011-01-22 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/38536 * gfortran.dg/c_loc_tests_16.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/c_loc_tests_16.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug c++/47412] Output: x = 31 but y = 30
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47412 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-22 17:31:03 UTC --- (In reply to comment #2) It seems interesting for me. It means Java doesn't assume it as an undefined behavior point or at least Java's compiler does in a unique way and doesn't care about being X or Y. Can anyone explain it? Java is a different language with different rules about evaluation of expressions. That code is well-defined in Java, but not C or C++ http://sgaur.wordpress.com/2009/03/30/java-evalorder-ops/ http://stackoverflow.com/questions/2028464/logic-differences-in-c-and-java/
[Bug fortran/47352] [F03] ICE with proc-pointers in generic procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47352 --- Comment #5 from janus at gcc dot gnu.org 2011-01-22 17:48:04 UTC --- (In reply to comment #4) Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c (revision 169052) +++ gcc/fortran/resolve.c (working copy) @@ -167,6 +167,8 @@ resolve_procedure_interface (gfc_symbol *sym) sym-attr.function = ifc-attr.function; sym-attr.subroutine = ifc-attr.subroutine; gfc_copy_formal_args (sym, ifc); + if (sym-attr.function) + sym-result = sym; sym-attr.allocatable = ifc-attr.allocatable; sym-attr.pointer = ifc-attr.pointer; This one also regtests cleanly, and I think it is preferable over the previous one.
[Bug libfortran/46267] strerror() is not necessarily thread-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46267 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Janne Blomqvist jb at gcc dot gnu.org 2011-01-22 18:59:41 UTC --- Fixed, closing
[Bug fortran/47399] [OOP] ICE with TBP of a PARAMETER
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47399 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-22 19:22:46 UTC --- The ICE is fixed (cf. comment 1), but the issue of comment 2 (spec-expr vs. init/constant-expr) still exists; for this PR itself, the issue is about the missing diagnostic for automatic objects in PROGRAM and MODULE declarations. Steve pointed out on fortran@gcc that at least the following PRs are related: PR 25095, PR 25104, PR 29962, PR 31292, PR 31560, PR 31592, PR 32365, PR 34663, PR 35040, and PR 38822.
[Bug c++/19351] operator new[] can return heap blocks which are too small
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351 Florian Weimer fw at gcc dot gnu.org changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #22 from Florian Weimer fw at gcc dot gnu.org 2011-01-22 20:15:08 UTC --- New patch posted: http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01593.html
[Bug rtl-optimization/47414] New: [4.6 Regression] wrong code with -O -freorder-blocks -fschedule-insns2 -fno-early-inlining -fstrict-aliasing -ftracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47414 Summary: [4.6 Regression] wrong code with -O -freorder-blocks -fschedule-insns2 -fno-early-inlining -fstrict-aliasing -ftracer Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 23077 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23077 reduced testcase Output: $ g++ -O -freorder-blocks -fschedule-insns2 -fno-early-inlining -fstrict-aliasing -ftracer testcase.C $ ./a.out ==32217== Invalid write of size 8 ==32217==at 0x40061B: test01() (testcase.C:44) ==32217==by 0x4006BC: main (testcase.C:62) ==32217== Address 0x0 is not stack'd, malloc'd or (recently) free'd Segmentation fault The assembly looks like: 2movrcx, rsp# nul, movQWORD PTR [rax], rbp# b_17-D.2238.next, b movDWORD PTR [rax+8], 1# b_17-i, 1movrdx, QWORD PTR [rcx]# nul, nul_23-D.2238.next 3movQWORD PTR [rsp], rax# MEM[(struct A *)s].next, b movesi, 0# nul, testrdx, rdx# nul jne.L10#, .L6: mov QWORD PTR [rsi], 0 # nul_12-D.2238.next, ^ crash The problem is that (1) loads the value before it is stored at (3). rcx == rsp because of (2). Without -fschedule-insns2: movDWORD PTR [rax+8], 1# b_17-i, movQWORD PTR [rax], rbp# b_17-D.2238.next, b 1movQWORD PTR [rsp], rax# MEM[(struct A *)s].next, b movesi, 0# nul, 2movrcx, rsp# nul, 3movrdx, QWORD PTR [rcx]# nul, nul_23-D.2238.next testrdx, rdx# nul jne.L10#, .L6: movQWORD PTR [rsi], 0# nul_12-D.2238.next, The order is correct. Tested revisions: r169125 - fail 4.5 r168785 - OK
[Bug tree-optimization/47415] New: -fcompare-debug failure with -O -fpredictive-commoning -fno-tree-fre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47415 Summary: -fcompare-debug failure with -O -fpredictive-commoning -fno-tree-fre Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz CC: aol...@gcc.gnu.org Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 23078 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23078 reduced testcase Compiler output: $ gcc -O -fpredictive-commoning -fno-tree-fre -fcompare-debug testcase.c gcc: error: testcase.c: -fcompare-debug failure Tested revisions: r169125 - fail 4.5 r168785 - fail
[Bug middle-end/47401] Support for must-not-throw regions with SJLJ exceptions broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47401 --- Comment #5 from Ulrich Weigand uweigand at gcc dot gnu.org 2011-01-22 21:24:57 UTC --- Author: uweigand Date: Sat Jan 22 21:24:54 2011 New Revision: 169134 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169134 Log: PR middle-end/47401 * except.c (sjlj_assign_call_site_values): Move setting the crtl-uses_eh_lsda flag to ... (sjlj_mark_call_sites): ... here. (sjlj_emit_function_enter): Support NULL dispatch label. (sjlj_build_landing_pads): In a function with no landing pads that still has must-not-throw regions, generate code to register a personality function with empty LSDA. Modified: trunk/gcc/ChangeLog trunk/gcc/except.c
[Bug middle-end/47401] Support for must-not-throw regions with SJLJ exceptions broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47401 Ulrich Weigand uweigand at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #6 from Ulrich Weigand uweigand at gcc dot gnu.org 2011-01-22 21:26:37 UTC --- Fixed.
[Bug c++/47416] New: ICE in build_data_member_initialization, at cp/semantics.c:5509
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47416 Summary: ICE in build_data_member_initialization, at cp/semantics.c:5509 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: pl...@agmk.net g++46 -std=gnu++0x -c espmFileGenerator.ii
[Bug c++/47416] ICE in build_data_member_initialization, at cp/semantics.c:5509
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47416 --- Comment #1 from Pawel Sikora pluto at agmk dot net 2011-01-22 21:44:24 UTC --- Created attachment 23079 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23079 testcase
[Bug target/43884] [4.4/4.5/4.6 Regression] Performance degradation for simple fibonacci numbers calculation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43884 --- Comment #20 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-22 21:45:23 UTC --- Patch posted http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01597.html I tested that is seems to bring us back to the 4.3 speed jh@gcc10:~/trunk/build/gcc$ time ./a.out 45 fib(45)=1134903170 real0m7.978s user0m7.976s sys 0m0.000s jh@gcc10:~/trunk/build/gcc$ gcc-4.3 Display all 708 possibilities? (y or n) jh@gcc10:~/trunk/build/gcc$ gcc-4.3 -O3 tt.c jh@gcc10:~/trunk/build/gcc$ time ./a.out 45 fib(45)=1134903170 real0m7.902s user0m7.888s sys 0m0.000s and before patch jh@gcc10:~/trunk/build2/gcc$ time ./a.out 45 fib(45)=1134903170 real0m8.222s user0m8.213s sys 0m0.000s
[Bug lto/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44334 --- Comment #25 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-22 21:47:43 UTC --- Author: hubicka Date: Sat Jan 22 21:47:40 2011 New Revision: 169136 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169136 Log: PR tree-optimization/43884 PR lto/44334 * predict.c (maybe_hot_frequency_p): Use entry block frequency as an base. * doc/invoke.texi (hot-bb-frequency-fraction): Update docs. * gcc.dg/autopar/outer-2.c: Increase array size. * gcc.dg/tree-ssa/ldist-pr45948.c: Update test. Modified: trunk/gcc/ChangeLog trunk/gcc/predict.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/autopar/outer-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-pr45948.c
[Bug lto/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44334 --- Comment #26 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-22 21:49:19 UTC --- OK, i comitted the branch prediction change. I am bit confused by the rest of trail, can you please confirm if the problem is fixed in all the configurations mentioned?
[Bug fortran/43062] NAMELIST attribute conflicts with ALLOCATABLE attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43062 --- Comment #22 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-22 21:50:54 UTC --- (In reply to comment #20) so, I am bit lost, bug is resolved or not ? Correction available with next version of gcc ? No the bug (or problem report, PR) is not yet resolved. But PR 47339 contains an almost ready patch, which fixes this issue (and some more namelist-related issues). The patch will likely be submitted soon.
[Bug target/43884] [4.4/4.5/4.6 Regression] Performance degradation for simple fibonacci numbers calculation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43884 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #22 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-22 21:49:51 UTC --- Fixed.
[Bug target/43884] [4.4/4.5/4.6 Regression] Performance degradation for simple fibonacci numbers calculation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43884 --- Comment #21 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-22 21:47:43 UTC --- Author: hubicka Date: Sat Jan 22 21:47:40 2011 New Revision: 169136 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169136 Log: PR tree-optimization/43884 PR lto/44334 * predict.c (maybe_hot_frequency_p): Use entry block frequency as an base. * doc/invoke.texi (hot-bb-frequency-fraction): Update docs. * gcc.dg/autopar/outer-2.c: Increase array size. * gcc.dg/tree-ssa/ldist-pr45948.c: Update test. Modified: trunk/gcc/ChangeLog trunk/gcc/predict.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/autopar/outer-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-pr45948.c
[Bug fortran/47339] Fortran 2003/2008: Valid NAMELIST rejected; Fortran 95: Invalid namelist objects accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47339 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Attachment #23018|0 |1 is obsolete|| --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-22 21:56:04 UTC --- Created attachment 23080 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23080 Almost ready patch Updated patch - should be almost ready. TODO: - Cleanup comment mess in nml_get_addr_expr - Add character(len=n) -std=f95 test case - Add character run-time test case - Do full bootstrap regtesting
[Bug fortran/43062] NAMELIST attribute conflicts with ALLOCATABLE attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43062 --- Comment #23 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-22 21:58:02 UTC --- (In reply to comment #21) It is not resolved because we are waiting for an interpretation from the Fortran standards committee on whether the test case is valid or invalid Fortran. Cf. comment 17: The J3 agreed that it is a bug in the standard and agreed on the proposed change, which solves the ambiguity in the standard and allows such namelists. The next step is to get passed a WG5 ballot. Finally, the change will be released as Corrigendum 1 to Fortran 2008. While it could be still rejected, the changes for a rejection are quite low. Thus, I went ahead and implemented it. (cf. attachment 23080 of PR 47339). Xavier: You do not have to wait for a new release, you could fetch the patch and build GCC/gfortran your self. Alternatively, when the patch is committed, you can get nightly builds. Both is described at http://gcc.gnu.org/wiki/GFortranBinaries
[Bug lto/47333] [4.6 regression] g++.dg/lto/20091219 FAILs on Solaris 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org |gnu.org | --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-22 21:57:35 UTC --- Hmm, weakref is fun ;( Seems we fail to stream the alias pair for those two vars.
[Bug lto/47333] [4.6 regression] g++.dg/lto/20091219 FAILs on Solaris 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333
--- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-22
22:10:08 UTC ---
testing the following patch for pasto in reachable_from_this_partition_p
Index: lto-cgraph.c
===
--- lto-cgraph.c(revision 168831)
+++ lto-cgraph.c(working copy)
@@ -383,10 +383,6 @@ bool
reachable_from_this_partition_p (struct cgraph_node *node, cgraph_node_set
set)
{
struct cgraph_edge *e;
- if (!node-analyzed)
-return false;
- if (node-global.inlined_to)
-return false;
for (e = node-callers; e; e = e-next_caller)
if (cgraph_node_in_set_p (e-caller, set))
return true;
[Bug fortran/40737] Pointer references sometimes fail to define span symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40737 --- Comment #13 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-01-22 22:37:05 UTC --- (In reply to comment #10) Isn't this the same as PR34640? I think so, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46339#c11 .
[Bug c++/47417] New: [4.6 Regression][C++0x] error: use of deleted function 'S::S(const S)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47417 Summary: [4.6 Regression][C++0x] error: use of deleted function 'S::S(const S)' Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: pl...@agmk.net hi, during build of my code base gcc reports an error: (...) include/c++/4.6.0/bits/stl_pair.h:110:17: error: 'constexpr std::pair_T1, _T2::pair(const std::pair_T1, _T2) [with _T1 = const void* const, _T2 = S, std::pair_T1, _T2 = std::pairconst void* const, S]' is implicitly deleted because the default definition would be ill-formed: .../include/c++/4.6.0/bits/stl_pair.h:110:17: error: use of deleted function 'S::S(const S)
[Bug c++/47417] [4.6 Regression][C++0x] error: use of deleted function 'S::S(const S)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47417 --- Comment #1 from Pawel Sikora pluto at agmk dot net 2011-01-22 22:41:56 UTC --- Created attachment 23081 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23081 source testcase.
[Bug c++/47417] [4.6 Regression][C++0x] error: use of deleted function 'S::S(const S)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47417 --- Comment #2 from Pawel Sikora pluto at agmk dot net 2011-01-22 22:42:26 UTC --- Created attachment 23082 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23082 preprocessed testcase.
[Bug lto/47333] [4.6 regression] g++.dg/lto/20091219 FAILs on Solaris 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333 --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-22 23:45:47 UTC --- Author: hubicka Date: Sat Jan 22 23:45:45 2011 New Revision: 169137 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169137 Log: PR lto/47333 * g++.dg/lto/pr47333.C: New file. * lto-cgraph.c (reachable_from_this_partition_p): Fix pasto. Added: trunk/gcc/testsuite/g++.dg/lto/pr47333.C Modified: trunk/gcc/ChangeLog trunk/gcc/lto-cgraph.c trunk/gcc/testsuite/ChangeLog
[Bug lto/47333] [4.6 regression] g++.dg/lto/20091219 FAILs on Solaris 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-22 23:46:38 UTC --- Commited patch fixing the linux testcase. Can you please double check that sloaris is fine too?
[Bug lto/47225] [4.6 regression]: cross-compile fails while configuring libgcc with xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47225 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added AssignedTo|hubicka at gcc dot gnu.org |unassigned at gcc dot ||gnu.org --- Comment #14 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-22 23:49:29 UTC --- We probably still could tweak toplevel configury to not build liblto when libtool is not able to produce shared libs, but unassigning myself. Someone with better libtool-fu hopefully will look into this.
[Bug c/47418] New: warning: array subscript is above array bounds at O2 with sin6_addr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47418 Summary: warning: array subscript is above array bounds at O2 with sin6_addr Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dpmc...@gmail.com Host: x86_64-unknown-linux-gnu Target: x86_64-unknown-linux-gnu Build: x86_64-unknown-linux-gnu Created attachment 23083 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23083 Preprocessed test case Originally from http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=43491 Preprocessed stripped test case (100 lines) attached. Only occurs on x86_64. At -O1 or -O0 this does not warn. It obviously also warns at -O3. $ pacman -Q glibc glibc 2.13-1 $ uname -a Linux galway 2.6.36-ARCH #1 SMP PREEMPT Sat Jan 8 14:15:27 CET 2011 x86_64 Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz GenuineIntel GNU/Linux $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/src/gcc-4.5.2/configure --prefix=/usr --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-gnu-unique-object --enable-lto --enable-plugin --enable-gold --with-plugin-ld=ld.gold --disable-multilib --disable-libstdcxx-pch --with-system-zlib --with-ppl --with-cloog --with-cloog-include=/usr/include/cloog-ppl --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info Thread model: posix gcc version 4.5.2 (GCC) $ gcc -O2 -Wall -c ftp-stripped.i ftp-stripped.i: In function ‘main’: ftp-stripped.i:86:30: warning: array subscript is above array bounds ftp-stripped.i:86:22: warning: array subscript is above array bounds ftp-stripped.i:86:14: warning: array subscript is above array bounds ftp-stripped.i:86:6: warning: array subscript is above array bounds ftp-stripped.i:85:28: warning: array subscript is above array bounds ftp-stripped.i:85:20: warning: array subscript is above array bounds ftp-stripped.i:85:13: warning: array subscript is above array bounds ftp-stripped.i:85:6: warning: array subscript is above array bounds On i686, no warnings at any optimization level occur. $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-linux-gnu/4.5.2/lto-wrapper Target: i686-pc-linux-gnu Configured with: /build/src/gcc-4.5.2/configure --prefix=/usr --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-gnu-unique-object --enable-lto --enable-plugin --enable-gold --with-plugin-ld=ld.gold --disable-multilib --disable-libstdcxx-pch --with-system-zlib --with-ppl --with-cloog --with-cloog-include=/usr/include/cloog-ppl --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info Thread model: posix gcc version 4.5.2 (GCC)
[Bug c/47418] warning: array subscript is above array bounds at O2 with sin6_addr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47418 --- Comment #1 from Dan McGee dpmcgee at gmail dot com 2011-01-23 00:15:29 UTC --- Also of note is the commented bit in the test case- if you instead dereference the s6_addr bit of the union, it all works without warnings. In the preprocessed source, replace ap = (char *)u.sin6.sin6_addr; with: ap = (char *)u.sin6.sin6_addr.__in6_u.__u6_addr8;
[Bug libstdc++/47387] AIX ctype 'mask' override not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47387 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added CC||dje at gcc dot gnu.org --- Comment #2 from David Edelsohn dje at gcc dot gnu.org 2011-01-23 00:22:02 UTC --- The patch seems reasonable to me. Is it posted as a formally posted patch waiting for approval?
[Bug libstdc++/47387] AIX ctype 'mask' override not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47387 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.23 01:01:42 Ever Confirmed|0 |1 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-01-23 01:01:42 UTC --- Thanks David. Indeed, please Graham post the patch to the libstdc++ mailing list (and of course say explicitly that you regression tested it): the patch is small enough and affects only AIX, thus if David doesn't object I believe it can go in for 4.6.0 too.
[Bug inline-asm/47419] New: missed 'mov (base,index,scale),reg' optimization?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47419
Summary: missed 'mov (base,index,scale),reg' optimization?
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net
following code...
unsigned __attribute__((regparm(2)))
asm_read_mapped_register( unsigned* address, unsigned long index )
{
unsigned value;
asm /* reading has side-effects in hardware */ volatile (
movl (%1), %0
: /* output operands */ =r ( value )
: /* input operands */ r ( address + index )
: /* clobbers */
);
return value;
}
produces...
asm_read_mapped_register:
leaq (%rdi,%rsi,4), %rax
movl (%rax), %eax
ret
is it a bug in asm inline? why the 'movl (%rdi,%rsi,4),%eax' isn't emitted?
question about lead contact generation
Hello, I was researching online tools for lead and contact generation (or extraction) from the web and came across your information. Do you currently use an online or web-based system? If so, would you mind sharing with me what system you use and how it's working for you? Thanks for your time! Chris LaRue
[Bug c/47418] warning: array subscript is above array bounds at O2 with sin6_addr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47418 Xavier chantry.xavier at gmail dot com changed: What|Removed |Added CC||chantry.xavier at gmail dot ||com --- Comment #2 from Xavier chantry.xavier at gmail dot com 2011-01-23 02:02:18 UTC --- (In reply to comment #1) Also of note is the commented bit in the test case- if you instead dereference the s6_addr bit of the union, it all works without warnings. In the preprocessed source, replace ap = (char *)u.sin6.sin6_addr; with: ap = (char *)u.sin6.sin6_addr.__in6_u.__u6_addr8; Actually it works with any member from __in6.u union. It seems gcc gets confused with the other anonymous union, and use the size of struct sockaddr instead of struct sockaddr_in6. I've got a simpler testcase which shows another interesting information : gcc gets confused when the sign of ap is the same as the size of the smallest struct/array of the union, and different from the sign of the big member that should be used.
[Bug c/47418] warning: array subscript is above array bounds at O2 with sin6_addr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47418 --- Comment #3 from Xavier chantry.xavier at gmail dot com 2011-01-23 02:06:35 UTC --- Created attachment 23084 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23084 simpler testcase $ gcc -O3 -Wall -c small-test.c small-test.c: In function 'main': small-test.c:18:51: warning: array subscript is above array bounds small-test.c:18:43: warning: array subscript is above array bounds small-test.c:18:35: warning: array subscript is above array bounds so gcc seems to think that the size of ap is 13 instead of 16. It's important that ap and sa_data are both char, and u6_addr8 is unsigned char. Same warning if ap and sa_data are unsigned char and u6_addr8 is char. But other combinations apparently do not give any warning.
[Bug rtl-optimization/47414] [4.6 Regression] wrong code with -O -freorder-blocks -fschedule-insns2 -fno-early-inlining -fstrict-aliasing -ftracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47414 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.23 03:21:30 CC||rguenth at gcc dot gnu.org Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-01-23 03:21:30 UTC --- It is caused by revision 165641: http://gcc.gnu.org/ml/gcc-cvs/2010-10/msg00826.html
[Bug lto/44334] rnflow.f90 ~27% slower with -fwhole-program -flto after revision 159852
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44334 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #27 from Jack Howarth howarth at nitro dot med.uc.edu 2011-01-23 03:36:02 UTC --- On x86_64-apple-darwin10 at r169137, the pb05 benchmarks compiled with benchmark -O3 -ffast-math -O3 -ffast-math -funroll-loops %change -funroll-loops -flto -fwhole-program ac8.818.810.0 aermod 17.30 17.501.2 air 5.625.57 -0.9 capacita 32.77 33.351.8 channel 1.891.890.0 doduc26.58 26.52 -0.2 fatigue 8.378.36 -0.1 gas_dyn 4.364.35 -0.2 induct 13.05 13.04 -0.1 linpk17.15 17.05 -0.6 mdbx 11.25 11.260.1 nf 32.14 33.504.2 protein 32.50 32.27 -0.7 rnflow 24.11 24.843.0 test_fpu 8.228.20 -0.2 tfft 1.891.88 -0.5 Geometric11.07 11.110.4 Mean
