[Bug tree-optimization/38529] [4.3/4.4 regression] ICE with nested loops
-- irar at il dot ibm dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-15 08:26:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38529
[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy
--- Comment #1 from laurent at guerby dot net 2008-12-15 09:23 --- 4.3.2 bootstrap doesn't fail in stage1 so this is a trunk regression. -- laurent at guerby dot net changed: What|Removed |Added CC||laurent at guerby dot net Known to work||4.3.2 Summary|arm build fails to link cc1-|[4.4 regression] arm build |dummy |fails to link cc1-dummy http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523
[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy
--- Comment #2 from schwab at suse dot de 2008-12-15 09:33 --- Probably related to bug 37739. Building with optimisation may be a workaround. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523
[Bug other/38531] New: namespace, ,
after #include strlen(),strcat(), etc are declared in not in std namespace (like: std::strlen()), but in global namespace (like: ::strlen() ) -- Summary: namespace, , Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mayor1 at uralweb dot ru GCC build triplet: -Wall -Wextra --pedantic GCC host triplet: -Wall -Wextra --pedantic GCC target triplet: -Wall -Wextra --pedantic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38531
[Bug tree-optimization/38529] [4.3/4.4 regression] ICE with nested loops
-- irar at il dot ibm dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-12-15 08:26:30 |2008-12-15 14:42:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38529
[Bug fortran/38113] on warning/error: skip whitespaces, move position marker to actual variable name
--- Comment #2 from mikael at gcc dot gnu dot org 2008-12-15 14:47 --- Subject: Bug 38113 Author: mikael Date: Mon Dec 15 14:46:22 2008 New Revision: 142763 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142763 Log: 2008-12-15 Mikael Morin PR fortran/38113 * error.c (show_locus): Start counting columns at 0. * primary.c (match_actual_arg): Eat spaces before copying the current locus. (match_variable): Copy the locus before matching. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/error.c trunk/gcc/fortran/primary.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38113
[Bug rtl-optimization/38532] New: dse broken for frame related stores
Some time ago, rth changed reload so that calls to dse_record_singleton_alias_set and dse_invalidate_singleton_alias_set were removed. I believe that this was an accidental side effect of fixing some other bug. These calls identified these addresses as being "special", in the sense that the values died at the end of the function. I had discussed this with vlad, because his method of allocating stack slots was different than the old ra's and he was supposed to add these calls into where ira allocates stack slots. As of this morning's trunk, this has not been done. So I am adding this bugzilla as a reminder. Kenny -- Summary: dse broken for frame related stores Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ra Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: vmakarov at gcc dot gnu dot org ReportedBy: zadeck at naturalbridge dot com GCC build triplet: all GCC host triplet: all GCC target triplet: all http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38532
[Bug fortran/38506] -std=f*: Reject scalar character to array dummy in several cases
--- Comment #1 from burnus at gcc dot gnu dot org 2008-12-15 09:44 --- Answer by Bader: "For generics, the "R" part of the TKR rule applies, which prohibits *both* above cases." => gfortran does it right. (I'm not fully convinced, but I buy this.) Diagnostics: Bader writes: "For handing on c_char scalars to char * an exception was made in F2003, allowing scalars to be matched to an entity with the dimension(*) attribute; otherwise dimension(*) will match arrays only, though of arbitrary dimension." I think this is partially misleading. I think "12.4.1.5 Sequence association" is relevant and it also applies to default character. I.e. one seemingly needs to rejected this for kind=4 character strings with -std=f2003: Index: interface.c === --- interface.c (Revision 142761) +++ interface.c (Arbeitskopie) @@ -1525,6 +1525,12 @@ compare_parameter (gfc_symbol *formal, g formal->name, &actual->where); return 0; } + else if (where && formal->ts.kind != 1 + && gfc_notify_std (GFC_STD_GNU, "Extension: Non-default-kind" + "/C_CHAR scalar CHARACTER actual argument " + "with array dummy argument '%s' at %L", + formal->name, &actual->where) == FAILURE) + return 0; else if ((gfc_option.allow_std & GFC_STD_F2003) == 0) return 0; else -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords|rejects-valid | Summary|Character storage |-std=f*: Reject scalar |association - actual <->|character to array dummy in |dummy argument |several cases http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38506
[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI
--- Comment #13 from whaley at cs dot utsa dot edu 2008-12-15 14:52 --- >No; "The nice thing about standards is that there are so many to choose from" >is a well-known saying. And also one without application here. I am aware of no other standard for Linux ABI other than the one in the linux standard base. Gcc did not choose another standard, it violated the one and only existing standard. I am not arguing that standards should never be changed, but rather that you shouldn't violate an existing one without reason. The reason gcc had to make this change is mere convenience (it keeps you from doing a bit-level operation and a register save in the preamble), which is not near strong enough a reason to take something that used to support the standard (gcc before this decision) and make it support absolutely no standard (your position now). Please try to avoid the mischaracterizations you are making: you have not switched from standard A to standard B, you have switched from standard A to no standard. >Then you should have made it clear much earlier in this discussion that >Windows is your concern. Because there is no one ABI for "i?86-*-*", and >an ABI written for ELF-based Unix systems 1990-1996 is far, far less >relevant to PECOFF-based Windows in 2008 than the limited relevance to >Linux in 2008. Actually, both windows and the linux base ABI handle arguments the exact same way. So, until gcc arbitrarily stopped supporting the standard, there *was* uniformity in the x86 world . . . But, it appears to me that while your standards compliance is permantly broken (due, ironically, for backwards compatibility with your previous decision), the problem I was having with gcc misaligning arrays when a standard-compliant ABI is requested, has at least been solved in gcc 4.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496
[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy
--- Comment #3 from laurent at guerby dot net 2008-12-15 11:46 --- >From Richard Earnshaw: << GCC (to be precise binutils) has limit on the maximum program size on ARM, which is 32MBytes (based on the span of the BL instruction). Unfortunately, when GCC is built without optimization and with checking enabled the image exceeds this limit. You can work around this by configuring with --disable-stage1-checking. See the discussion of this back in May 2007 (the initial diagnosis of the problem was wrong :-) starting here: http://gcc.gnu.org/ml/gcc/2007-05/msg00108.html >> -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523
[Bug target/30271] -mstrict-align can an store extra for struct agrument passing
--- Comment #9 from zadeck at naturalbridge dot com 2008-12-15 15:32 --- Andrew, What is your point here? 1) Is it your claim that anything that is arg_pointer_rtx related would automatically qualify as being safe enough to remove dead stores to? or 2) Is it your claim that if we could generalize the game proposed in comment #7 to cover the arg_pointer_rtx's also? Kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271
[Bug testsuite/38526] WARNING: Could not compile gcc.dg/compat/struct-layout-1 generator
--- Comment #3 from hjl dot tools at gmail dot com 2008-12-15 15:51 --- (In reply to comment #2) > Subject: Re: WARNING: Could not compile gcc.dg/compat/struct-layout-1 > generator > > > This is really PR 36443. > > Aside from darwin specific issues with the environment, the problem looks > the same. Did anybody try Mark's suggestion (i.e., setting HOSTCC to > "unset GCC_EXEC_PREFIX && gcc")? > Other C cpmpilers may be used for bootstrap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38526
[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy
--- Comment #4 from laurent at guerby dot net 2008-12-15 15:54 --- More discussions here: http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00861.html Also from Richard: Recent binutils should also be able to generate binaries exceeding this limit, though there is some runtime and additional code size overhead when this occurs. > I'm using debian lenny binutils 2.18.1~cvs20080103-7 and > since I'm seeing the error I assume it's not recent enough? Probably not. It may not be present in any released version of binutils. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523
[Bug fortran/38530] New: ICE with the example for c_funloc
I tried to compile the test given for c_funloc in http://gcc.gnu.org/onlinedocs/gfortran/C_005fFUNLOC.html#C_005fFUNLOC and I got an ICE with trunk and 4.3.2: funloc.f90: In function 'main': funloc.f90:20: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6836 -- Summary: ICE with the example for c_funloc Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38530
[Bug ada/38400] Acats faillures due to undefined pthread_setrunon_np
--- Comment #4 from J dot J dot vanderHeijden at gmail dot com 2008-12-15 16:41 --- Created an attachment (id=16911) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16911&action=view) IRIX-6.2 only dummy implementation of pthread_setrunon_np() This patch adds an empty implementation of pthread_setrunon_np() on IRIX 6.2. Since Ada threading seems to operate independent of GCC's 'enable-threads=posix' I've chosen the existence of SGI_INITIAL_PT_SPROC as a trigger to #include and thus prevent breakage on IRIX 5.x (which doesn't have pthreads at all). Testsuite results follow -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38400
[Bug fortran/38530] ICE with the example for c_funloc
--- Comment #1 from mikael at gcc dot gnu dot org 2008-12-15 13:42 --- explanation http://gcc.gnu.org/ml/fortran/2008-12/msg00137.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38530
[Bug ada/38400] Acats faillures due to undefined pthread_setrunon_np
--- Comment #5 from J dot J dot vanderHeijden at gmail dot com 2008-12-15 16:48 --- Test results: http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg01459.html Please approve. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38400
[Bug fortran/36771] Non-Standard addition for C_LOC and character strings
--- Comment #4 from brtnfld at hdfgroup dot org 2008-12-15 16:52 --- > > In any case: I tried ifort, g95, NAG f95, gfortran, and sunf95 - of these only > "ifort" allows it (even with all checking enabled - thus presumably only by > accident and not on purpose). > > Thus I wonder whether simply using the following "evil" workaround is better > than patching the compiler: > > f_ptr = C_LOC(X(1:1)) > > That works with gfortran, ifort, g95 and NAG f95. (It fails with sunf95, whose > C interoperability is a bit shaky in general.) As the string should be > contiguous in memory it should be the OK. Additionally, that is also what one > would do in C: > > char X[40]; > ptr = &X; // or equivalently: ptr = &X[0]; as you said using C_LOC(X(1:1)) works fine and that is what I ended up doing. BTW, ifort 11 and pgf90 7.2-1 also allow C_LOC(X). But, while using X(1:1) works fine in general, if I try to use it in a derived type gfortan (all versions) it fails to compile with an internal error, Internal Error at (1): Unexpected expression reference type in gfc_iso_c_func_interface for example: MODULE modtest USE ISO_C_BINDING TYPE test CHARACTER(LEN=2), DIMENSION(1:2) :: c INTEGER(C_INT) :: i END TYPE test END MODULE modtest PROGRAM main USE ISO_C_BINDING USE modtest TYPE(test), TARGET :: chrScalar TYPE(C_PTR) :: f_ptr f_ptr = c_loc(chrScalar%c(1)(1:1)) END PROGRAM main g95, ifort, and pgf90 all compile it. But this is maybe a separate issue. Since there is a work around (in most cases) and according to the standard a character must be length = 1 for X, I'm willing to withdrawal the request for the enhancement. As for the issue with the generic interface; none of the compilers can compile the code so generic resolution does not seem to have been extended to allow this behavior and it seems the requirement of matching Type, Kind and Rank trumps all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36771
[Bug fortran/36771] Non-Standard addition for C_LOC and character strings
--- Comment #3 from burnus at gcc dot gnu dot org 2008-12-15 10:48 --- I think the patch in comment 2 is about the wrong gfc_error. Additionally, the generic resolution seems to be correct in gfortran (-> PR 38506). * * * In any case: I tried ifort, g95, NAG f95, gfortran, and sunf95 - of these only "ifort" allows it (even with all checking enabled - thus presumably only by accident and not on purpose). Thus I wonder whether simply using the following "evil" workaround is better than patching the compiler: f_ptr = C_LOC(X(1:1)) That works with gfortran, ifort, g95 and NAG f95. (It fails with sunf95, whose C interoperability is a bit shaky in general.) As the string should be contiguous in memory it should be the OK. Additionally, that is also what one would do in C: char X[40]; ptr = &X; // or equivalently: ptr = &X[0]; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36771
[Bug fortran/38530] ICE with the example for c_funloc
-- mikael at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mikael at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-15 13:28:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38530
[Bug debug/30161] GCC should generate dwarf info about template parameters
--- Comment #3 from dodji at gcc dot gnu dot org 2008-12-15 10:01 --- Started looking at this. Got a work in progress patch at http://www.seketeli.org/dodji/patches/gcc/PR30161-patch.txt. It's not ready for review yet, I am just backuping it online. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30161
[Bug fortran/37829] ICE in resolve_symbol
--- Comment #6 from dominiq at lps dot ens dot fr 2008-12-15 12:48 --- Compiling the test in comment #4 gives: pr37829_2.f90:21.6: d = c_funloc (g) 1 Error: Can't convert TYPE(_gfortran_iso_c_binding_c_funptr) to TYPE(c_funptr) at (1) looking the gfortran sources for "c_funptr" I get: in gcc/fortran/iso-c-binding.def, line 145 DERIVED_TYPE (ISOCBINDING_FUNPTR, "c_funptr", \ get_int_kind_from_node (ptr_type_node)) and in gcc/fortran/symbol.c, line 3507 generate_isocbinding_symbol (module_name, ptr_id == ISOCBINDING_NULL_PTR ? ISOCBINDING_PTR : ISOCBINDING_FUNPTR, (const char *) (ptr_id == ISOCBINDING_NULL_PTR ? "_gfortran_iso_c_binding_c_ptr" : "_gfortran_iso_c_binding_c_funptr")); line 3591 if (iso_c_sym_id == ISOCBINDING_F_PROCPOINTER) c_ptr_type = "_gfortran_iso_c_binding_c_funptr"; else c_ptr_type = "_gfortran_iso_c_binding_c_ptr"; line 4158 (const char *)(s == ISOCBINDING_FUNLOC ? "_gfortran_iso_c_binding_c_funptr" : "_gfortran_iso_c_binding_c_ptr")); I fail to see what is the difference between "c_funptr" and "_gfortran_iso_c_binding_c_funptr". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #13 from jv244 at cam dot ac dot uk 2008-12-15 17:31 --- (In reply to comment #12) > Could you try with the addition of " -fno-strict-aliasing > -fno-strict-overflow"? See pr38520. The testcase in PR38492 indeed works if I use: gfortran -O2 -ffast-math -funroll-loops -ftree-vectorize -march=native -fgraphite -fgraphite-identity -cpp -D__FFTSG -fno-strict-overflow test.f90 (i.e. no need for -fno-strict-aliasing) I'll give it a try on the full code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38492] [graphite] segfaulting code when compiled with -fgraphite -fgraphite-identity
--- Comment #5 from jv244 at cam dot ac dot uk 2008-12-15 17:32 --- As suggest in PR38431, works fine with: gfortran -O2 -ffast-math -funroll-loops -ftree-vectorize -march=native -fgraphite -fgraphite-identity -cpp -D__FFTSG -fno-strict-overflow test.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38492
[Bug fortran/38507] Bogus Warning: Deleted feature: GOTO jumps to END of construct
--- Comment #5 from tobi at gcc dot gnu dot org 2008-12-15 17:37 --- According to your readings, is the following valid? DO 10 I=1,10 IF (.TRUE.) THEN 10 END IF END -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38507
[Bug tree-optimization/38401] TreeSSA-PRE load after store misoptimization
--- Comment #15 from steven at gcc dot gnu dot org 2008-12-15 17:38 --- Re. comment #14: Yes, I suppose so. Why do you want to remove gcse-las from mainline. Not that I'm against it -- ideally RTL gcse.c would not work on memory at all anymore -- but I wouldn't remove gcse-las until we catch in the GIMPLE optimizers as much as possible of the things we still need gcse-las for. It seems to me, btw, that it might be easier to teach GIMPLE loop invariant code motion about this transformation. Adding this in GIMPLE PRE might be a little too expensive...? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38401
[Bug fortran/38507] Bogus Warning: Deleted feature: GOTO jumps to END of construct
-- tobi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-12-12 20:07:01 |2008-12-15 17:40:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38507
[Bug other/38531] namespace, ,
--- Comment #1 from jakub at gcc dot gnu dot org 2008-12-15 17:40 --- Why is that considered a bug? If you want strlen etc. in std:: namespace, you need to include . -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38531
[Bug c/38533] New: [4.2/4.3/4.4 regression] Inefficient stack usage
The stack usage of the code gcc-4.x generated looks inefficient on x86 and
x86_64. A simple test case is below;
#define copy_from_asm(x, addr, err) \
asm volatile( \
"1:\tmovl %2, %1\n" \
"2:\n" \
".section .fixup,\"ax\"\n" \
"\txor %1,%1\n" \
"\tmov $1,%0\n" \
"\tjmp 2b\n"\
".previous\n" \
: "=r" (err), "=r" (x) \
: "m" (*(int*)(addr)), "0" (err))
#define copy_from(x, addr, err) do {\
(err) = 0; \
copy_from_asm((x), (addr), (err)); \
} while (0)
#define copy(x, addr) ({ \
int __err; \
copy_from((x), (addr), __err); \
__err; \
})
int src[32];
int dst[32];
#define my_copy(x) do { err |= copy(dst[x], &src[x]); } while (0)
int test(void)
{
int err = 0;
my_copy( 0); my_copy( 1); my_copy( 2); my_copy( 3);
my_copy( 4); my_copy( 5); my_copy( 6); my_copy( 7);
my_copy( 8); my_copy( 9); my_copy(10); my_copy(11);
my_copy(12); my_copy(13); my_copy(14); my_copy(15);
my_copy(16); my_copy(17); my_copy(18); my_copy(19);
my_copy(20); my_copy(21); my_copy(22); my_copy(23);
my_copy(24); my_copy(25); my_copy(26); my_copy(27);
my_copy(28); my_copy(29); my_copy(30); my_copy(31);
return err;
}
==
I compiled this test case with gcc-3.4.6, 4.2.4, 4.3.2 and 4.4-20081205,
and the compile option is "-g -Os -mno-red-zone".
The code size of objects are below;
$ size test.o.*
textdata bss dec hex filename
945 0 0 945 3b1 test.o.34
1157 0 01157 485 test.o.42
1133 0 01133 46d test.o.43
1201 0 01201 4b1 test.o.44
gcc-3.4.6 generates;
:
0: 31 c9 xor%ecx,%ecx
2: 8b 05 00 00 00 00 mov0x0(%rip),%eax# 8
8: 89 05 00 00 00 00 mov%eax,0x0(%rip)# e
e: 31 c0 xor%eax,%eax
10: 8b 15 00 00 00 00 mov0x0(%rip),%edx# 16
16: 09 c1 or %eax,%ecx
18: 89 15 00 00 00 00 mov%edx,0x0(%rip)# 1e
1e: 31 c0 xor%eax,%eax
20: 8b 15 00 00 00 00 mov0x0(%rip),%edx# 26
26: 09 c1 or %eax,%ecx
gcc-4.4 generates;
:
0: 41 57 push %r15
2: 31 c0 xor%eax,%eax
4: 41 56 push %r14
6: 41 55 push %r13
8: 41 89 c5mov%eax,%r13d
b: 41 54 push %r12
d: 55 push %rbp
e: 53 push %rbx
f: 48 83 ec 58 sub$0x58,%rsp
13: 8b 15 00 00 00 00 mov0x0(%rip),%edx# 19
19: 89 15 00 00 00 00 mov%edx,0x0(%rip)# 1f
1f: 41 89 c6mov%eax,%r14d
22: 8b 15 00 00 00 00 mov0x0(%rip),%edx# 28
28: 89 15 00 00 00 00 mov%edx,0x0(%rip)# 2e
2e: 41 89 c4mov%eax,%r12d
...
bf: 31 d2 xor%edx,%edx
c1: 44 8b 3d 00 00 00 00mov0x0(%rip),%r15d# c8
c8: 89 54 24 04 mov%edx,0x4(%rsp)
cc: 44 89 3d 00 00 00 00mov%r15d,0x0(%rip)# d3
d3: 45 31 ffxor%r15d,%r15d
d6: 8b 15 00 00 00 00 mov0x0(%rip),%edx# dc
dc: 44 89 7c 24 54 mov%r15d,0x54(%rsp)
...
26d: 0b 54 24 54 or 0x54(%rsp),%edx
271: 0b 54 24 50 or 0x50(%rsp),%edx
275: 0b 54 24 4c or 0x4c(%rsp),%edx
279: 0b 54 24 48 or 0x48(%rsp),%edx
...
On gcc-4.x, error values temporally stored to stack and at the last "or" all
stored data. This stack usage seems inefficient.
--
Summary: [4.2/4.3/4.4 regression] Inefficient stack usage
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h-shimamoto at ct dot jp dot nec dot com
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38533
[Bug fortran/38487] Bogus Warning: INTENT(INOUT) actual argument might interfere with actual argument
--- Comment #4 from mikael at gcc dot gnu dot org 2008-12-15 18:10 --- Subject: Bug 38487 Author: mikael Date: Mon Dec 15 18:08:42 2008 New Revision: 142766 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142766 Log: 2008-12-15 Mikael Morin PR fortran/38487 * gfortran.dg/elemental_dependency_2.f90: New test. 2008-12-15 Mikael Morin PR fortran/38487 * dependency.c (gfc_is_data_pointer): New function. (gfc_check_argument_var_dependency): Disable the warning in the pointer case. (gfc_check_dependency): Use gfc_is_data_pointer. Added: trunk/gcc/testsuite/gfortran.dg/elemental_dependency_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38487
[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI
--- Comment #14 from joseph at codesourcery dot com 2008-12-15 18:17 --- Subject: Re: Gcc misaligns arrays when stack is forced follow the x8632 ABI On Mon, 15 Dec 2008, whaley at cs dot utsa dot edu wrote: > And also one without application here. I am aware of no other standard for > Linux ABI other than the one in the linux standard base. Gcc did not choose > another standard, it violated the one and only existing standard. I am not GCC chose to change the *unwritten* standard for the ABI in use for IA32 GNU/Linux. The LSB is not a plausible candidate for a written standard for that ABI; the set of such candidates is presently empty. Maybe if there were a document supported by relevant stakeholders then it would be of value to follow it, but the LSB doesn't have that support (see also Ulrich's comments); it is effectively an attempt by third parties to observe the ABI and document their imperfect observations. Just because no-one has written a useful standard document in a particular area does not mean a document that is not presently useful or accurate should be followed. The ABI is undocumented; that is reality. LSB is a good-faith attempt to document it, but for LSB to be useful for its intended purpose it needs to keep playing catch-up with reality. The SCO document may have been useful before SSE, but processor architecture and language developments have made it problematic for many years. The set of ABI standards suitable for use on IA32 GNU/Linux has been empty for many years. For it to cease to be empty a document would need to be written that reflects reality and there would need to be long-term commitment from many interested parties to keep the document and the implementation in sync in future. (A document that does not reflect reality would require even more commitment, to make an incompatible break from previous ABIs in use to move to a newer cleaner ABI.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496
[Bug libstdc++/6257] [DR 456] C-library symbols enter global namespace
--- Comment #28 from paolo dot carlini at oracle dot com 2008-12-15 18:42 --- *** Bug 38531 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||mayor1 at uralweb dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
[Bug other/38531] namespace, ,
--- Comment #2 from paolo dot carlini at oracle dot com 2008-12-15 18:42 --- *** This bug has been marked as a duplicate of 6257 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38531
[Bug other/38531] namespace, ,
--- Comment #3 from paolo dot carlini at oracle dot com 2008-12-15 18:50 --- By the way, in gcc4.3.x (and 4.4.x of course), is not included anymore by as an implementation detail (it could, it's allowed by Standard), thus this specific issue is strictly speaking moot now. But still injects declarations in the global namespace too, this is 6257. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38531
[Bug fortran/38507] Bogus Warning: Deleted feature: GOTO jumps to END of construct
--- Comment #6 from kargl at gcc dot gnu dot org 2008-12-15 18:58 --- (In reply to comment #5) > According to your readings, is the following valid? > DO 10 I=1,10 > IF (.TRUE.) THEN > 10 END IF >END > See constraint C825, page 165 in F2003 and restriction R214 on page 11. The above is an nonblock do construction and the label must appear on an action-stmt. end-if is not listed among the action statements, so I would conclude the above is invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38507
[Bug c/38534] New: gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function
/* When a function has been defined using the 'noreturn' attribute,
* there is no reason to save the callee-saved registers, mainly
* because the function is not going to return to the caller.
*
* This can save a few bytes of code generation for embedded-type
* applications which may use 'noreturn' functions to restart, for
* example, by jumping to a different address rather than returning to
* the caller.
*
* gcc information:
*
* Using built-in specs.
* Target: x86_64-redhat-linux
*
* Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
* --infodir=/usr/share/info --enable-shared
* --enable-threads=posix --enable-checking=release
* --with-system-zlib --enable-__cxa_atexit
* --disable-libunwind-exceptions
--enable-libgcj-multifile
* --enable-languages=c,c++,objc,obj-c++,java,fortran,ada
* --enable-java-awt=gtk --disable-dssi --enable-plugin
*
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
* --with-cpu=generic --host=x86_64-redhat-linux
* Thread model: posix
* gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)
*
* compilation & disassembly information:
*
* gcc -c -O3 -o noreturn.o noreturn.c
* objdump --disassemble --reloc noreturn.o
*
* Notice in the disassembly of 'return_to_caller' that the
* registers pushed in the preamble are restored before
* returning. But, in the 'no_return_to_caller', they are not
* restored; since they are no restored, there is no reason to
* even save them.
*/
#include
extern unsigned array[1024][1024][1024];
extern unsigned value(int i, int j, int k);
#define LOOP_BODY \
do { \
unsigned i, j, k; \
for (i = 1024; i > 0; --i) { \
for (j = 1024; j > 0; --j) { \
for (k = 1024; k > 0; --k) {\
array[i - 1][j - 1][k - 1] = value(i, j, k); \
} \
} \
} \
} while (0)
void
return_to_caller(int a, int b, int c, int d)
{
LOOP_BODY;
}
void __attribute__((noreturn))
no_return_to_caller(int a, int b, int c, int d)
{
LOOP_BODY;
while (1);
}
--
Summary: gcc 4.2.1 and above: No need to save called-saved
registers in 'noreturn' function
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thutt at vmware dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #14 from jv244 at cam dot ac dot uk 2008-12-15 19:06 --- (In reply to comment #13) > > (i.e. no need for -fno-strict-aliasing) I'll give it a try on the full code. OK, full code compiles & runs the test example with -fgraphite -fgraphite-identity -fno-strict-overflow -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug fortran/38507] Bogus Warning: Deleted feature: GOTO jumps to END of construct
--- Comment #7 from tobi at gcc dot gnu dot org 2008-12-15 19:16 --- (In reply to comment #6) > (In reply to comment #5) > > According to your readings, is the following valid? > > DO 10 I=1,10 > > IF (.TRUE.) THEN > > 10 END IF > >END > > > > See constraint C825, page 165 in F2003 and restriction R214 > on page 11. > > The above is an nonblock do construction and the label must > appear on an action-stmt. end-if is not listed among the > action statements, so I would conclude the above is invalid. > Thanks, I had missed the action-stmt requirement. I think I know how to fix this, then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38507
[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc > gcc-4.2.x
--- Comment #9 from andreast at gcc dot gnu dot org 2008-12-15 19:35 --- Tested the patch on F10. Results here: http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg01223.html Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739
[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )
--- Comment #11 from jv244 at cam dot ac dot uk 2008-12-15 19:38 --- as this file is included in a project compiled normally with '-O3 -march=native -funroll-loops' the timing in that case is also important. As I'm finding out, this becomes unworkable (>6h, and still compiling). Looking at -fdump-tree-original, the overloaded operators (+,-,..) expand to function call, leading to a subroutine which contains 73000 function calls. So, likely that some stuff is scaling at least quadratically wrt to this parameter. -- jv244 at cam dot ac dot uk changed: What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #15 from jv244 at cam dot ac dot uk 2008-12-15 19:44 --- (In reply to comment #14) > OK, full code compiles & runs the test example with -fgraphite > -fgraphite-identity -fno-strict-overflow compiling with -g -O2 -ffast-math -funroll-loops -ftree-vectorize -march=native -ffree-form -fgraphite -fgraphite-identity -fno-strict-overflow -floop-block -floop-strip-mine -floop-interchang it segfaults again :-) 0x00672bd1 in __distribution_optimize_MOD_compute_cost_cpu () at distribution_optimize.F:286 286 cost_cpu(local_rows(i),local_cols(j))=cost_cpu(local_rows(i),local_cols(j))+cost_ele_pair(i,j) Current language: auto; currently fortran (gdb) bt #0 0x00672bd1 in __distribution_optimize_MOD_compute_cost_cpu () at distribution_optimize.F:286 #1 0x006753da in __distribution_optimize_MOD_distribute_2d_monte_carlo () at distribution_optimize.F:247 #2 0x006706b7 in __distribution_methods_MOD_distribute_molecules_2d () at distribution_methods.F:582 #3 0x00e5822c in __qs_environment_methods_MOD_qs_env_setup () at qs_environment_methods.F:191 #4 0x00e501ba in __qs_environment_MOD_qs_init_subsys () at qs_environment.F:992 #5 0x00e55515 in __qs_environment_MOD_qs_init () at qs_environment.F:322 #6 0x00f7e66a in __qs_main_MOD_quickstep_create_force_env () at qs_main.F:87 #7 0x00715bfd in __f77_interface_MOD_create_force_env () at f77_interface.F:734 #8 0x00561abe in __cp2k_runs_MOD_cp2k_run () at cp2k_runs.F:281 #9 0x005652f7 in __cp2k_runs_MOD_run_input () at cp2k_runs.F:1079 #10 0x01463571 in cp2k () at cp2k.F:272 #11 0x0146467a in main (argc=2, argv=0x79cc5928) at /scratch/vondele/gcc/graphite/libgfortran/fmain.c:21 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38535] New: [4.4 Regression] __builtin_ia32_stmxcsr no longer works
When I configured gcc with --enable-languages=c, I got
[...@gnu-6 gcc]$ cat x.c
unsigned int
foo ()
{
return __builtin_ia32_stmxcsr ();
}
[...@gnu-6 gcc]$ ./xgcc -B./ -O2 -S x.c
x.c:1: internal compiler error: tree check: expected class type, have
exceptional (tree_list) in type_hash_list, at tree.c:4570
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
--
Summary: [4.4 Regression] __builtin_ia32_stmxcsr no longer works
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38535
[Bug fortran/38536] New: ICE with C_LOC in resolve.c due to not properly going through expr->ref
There are two C_LOC issues related to not going through all expr->ref. The second one was found by Scot Breitenfeld (in PR 36771 comment 4), the first one I found while trying to reduce it. * * * use iso_c_binding character(len=2),target :: str(2) print *, c_loc(str(1)) end Result: Gives no error Expected: Error: CHARACTER argument 'str' to 'c_loc' at (1) must have a length of 1 Using C_LOC(str) an error is printed. Seemingly, is_scalar_expr_ptr either does not work or it is the wrong function for the check in resolve.c's gfc_iso_c_func_interface. * * * The following program gives: Internal Error at (1): Unexpected expression reference type in gfc_iso_c_func_interface The problem also occurs in resolve.c's gfc_iso_c_func_interface, though at a different line. USE ISO_C_BINDING TYPE test CHARACTER(LEN=2), DIMENSION(1:2) :: c INTEGER(C_INT) :: i END TYPE test TYPE(test), TARGET :: chrScalar TYPE(C_PTR) :: f_ptr f_ptr = c_loc(chrScalar%c(1)(1:1)) end -- Summary: ICE with C_LOC in resolve.c due to not properly going through expr->ref Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536
[Bug fortran/36771] Non-Standard addition for C_LOC and character strings
--- Comment #5 from burnus at gcc dot gnu dot org 2008-12-15 20:35 --- (In reply to comment #4) > > In any case: I tried ifort, g95, NAG f95, gfortran, and sunf95 > > - of these only "ifort" allows it > > as you said using C_LOC(X(1:1)) works fine and that is what I ended up doing. > BTW, ifort 11 and pgf90 7.2-1 also allow C_LOC(X). OK. Then I close this PR as WONTFIX. > But, while using X(1:1) works fine in general, if I try to use it in a > derived type gfortan (all versions) it fails to compile with an internal > error, Filed as new PR 38536. Thanks a lot for finding and reporting this problem. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36771
[Bug middle-end/38535] [4.4 Regression] __builtin_ia32_stmxcsr no longer works
--- Comment #1 from hjl dot tools at gmail dot com 2008-12-15 20:57 --- Pilot error. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38535
[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )
--- Comment #12 from steven at gcc dot gnu dot org 2008-12-15 21:17 --- One of the bottlenecks seems to be find_temp_slot_from_address. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )
--- Comment #13 from steven at gcc dot gnu dot org 2008-12-15 21:27 ---
OK, to elaborate: I'm playing with this test case on ia64-linux, and I reduced
the test case by some 8000 lines to make it compilable at all. With this 8000
lines less, it actually spends more time for me in "expand", in the function
"find_temp_slot_from_address (rtx x)". It spends all of its time...
for (i = max_slot_level (); i >= 0; i--)
for (p = *temp_slots_at_level (i); p; p = p->next)
{
if (XEXP (p->slot, 0) == x
|| p->address == x
|| (GET_CODE (x) == PLUS
&& XEXP (x, 0) == virtual_stack_vars_rtx
&& GET_CODE (XEXP (x, 1)) == CONST_INT
&& INTVAL (XEXP (x, 1)) >= p->base_offset
&& INTVAL (XEXP (x, 1)) < p->base_offset + p->full_size))
return p;
else if (p->address != 0 && GET_CODE (p->address) == EXPR_LIST)
for (next = p->address; next; next = XEXP (next, 1))
if (XEXP (next, 0) == x) /* ...here in this loop... */
return p;
in the "for (next = p->address; ...)" loop. This list in p->address is actually
several thousand items long and it is traversed many times:
traversals ~ max_slot_level()*temp_slots_at_level(i)*list length of p->address
which is, at best, cubic behavior.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2008-12-10 15:39:38 |2008-12-15 21:27:40
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI
--- Comment #15 from whaley at cs dot utsa dot edu 2008-12-15 21:32 --- >GCC chose to change the *unwritten* standard for the ABI in use for IA32 >GNU/Linux. This is not true. Prior to this change, gcc followed the *written* standard provided by the LSB. You chose to violate the standard, or to put as you seem to prefer, you chose to declare that you followed no standard, as the written standard previously used by pretty much all OSes on the x86 was suddenly unusable. >The SCO document may have been useful before SSE, but processor architecture >and language developments have made it problematic for many years. This is not even trivially true. SSE requires no change in the ABI to support: it is purely convenience to start with a known 16-byte alignment: an andb and a register save/restore fixes the problem completely, without abandoning the standard. I believe gcc still abides by this "problematic for many years" standard in all respects except stack alignment, which is a trivial problem to solve and still abide by the standard. So, you abandoned standard compliance to solve a minor irritant, that you yourself have fixed in the new 4.4 series. >From 4.4 on, you broke the standard for no gain at all, since you have now added the minor complexity of manually aligning the stack anyway. Of course the standard seems outdated to us: it is supporting an architecture that is decades old, and that is the strength of it. If you want the shiny new stuff, you go to x86-64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496
Re: [Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI
Sent from my iPhone On Dec 15, 2008, at 1:33 PM, "whaley at cs dot utsa dot edu" > wrote: --- Comment #15 from whaley at cs dot utsa dot edu 2008-12-15 21:32 --- GCC chose to change the *unwritten* standard for the ABI in use for IA32 GNU/Linux. This is not true. Prior to this change, gcc followed the *written* standard provided by the LSB. LSB was written years after we had already did this back in gcc 3.0. Please check the history before saying gcc followed a written standard when none existed when this change was done. You chose to violate the standard, or to put as you seem to prefer, you chose to declare that you followed no standard, as the written standard previously used by pretty much all OSes on the x86 was suddenly unusable. The SCO document may have been useful before SSE, but processor architecture and language developments have made it problematic for many years. This is not even trivially true. SSE requires no change in the ABI to support: it is purely convenience to start with a known 16-byte alignment: an andb and a register save/restore fixes the problem completely, without abandoning the standard. I believe gcc still abides by this "problematic for many years" standard in all respects except stack alignment, which is a trivial problem to solve and still abide by the standard. So, you abandoned standard compliance to solve a minor irritant, that you yourself have fixed in the new 4.4 series. From 4.4 on, you broke the standard for no gain at all, since you have now added the minor complexity of manually aligning the stack anyway. Of course the standard seems outdated to us: it is supporting an architecture that is decades old, and that is the strength of it. If you want the shiny new stuff, you go to x86-64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496
[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI
--- Comment #16 from pinskia at gmail dot com 2008-12-15 21:39 --- Subject: Re: Gcc misaligns arrays when stack is forced follow the x8632 ABI Sent from my iPhone On Dec 15, 2008, at 1:33 PM, "whaley at cs dot utsa dot edu" wrote: > > > --- Comment #15 from whaley at cs dot utsa dot edu 2008-12-15 > 21:32 --- >> GCC chose to change the *unwritten* standard for the ABI in use for >> IA32 GNU/Linux. > > This is not true. Prior to this change, gcc followed the *written* > standard > provided by the LSB. LSB was written years after we had already did this back in gcc 3.0. Please check the history before saying gcc followed a written standard when none existed when this change was done. > You chose to violate the standard, or to put as you seem > to prefer, you chose to declare that you followed no standard, as > the written > standard previously used by pretty much all OSes on the x86 was > suddenly > unusable. > >> The SCO document may have been useful before SSE, but processor >> architecture and language developments have made it problematic for >> many years. > > This is not even trivially true. SSE requires no change in the ABI > to support: > it is purely convenience to start with a known 16-byte alignment: an > andb and a > register save/restore fixes the problem completely, without > abandoning the > standard. I believe gcc still abides by this "problematic for many > years" > standard in all respects except stack alignment, which is a trivial > problem to > solve and still abide by the standard. So, you abandoned standard > compliance > to solve a minor irritant, that you yourself have fixed in the new > 4.4 series. > From 4.4 on, you broke the standard for no gain at all, since you > have now > added the minor complexity of manually aligning the stack anyway. > > Of course the standard seems outdated to us: it is supporting an > architecture > that is decades old, and that is the strength of it. If you want > the shiny new > stuff, you go to x86-64. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496 > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496
[Bug c/38469] Wrong code for a function with long long argument returning int.
--- Comment #1 from rsandifo at gcc dot gnu dot org 2008-12-15 21:40 --- I think this was fixed by: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01996.html Could you check whether it works for you? -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added CC||rsandifo at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38469
[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )
--- Comment #14 from steven at gcc dot gnu dot org 2008-12-15 21:53 --- For the inline heuristics, almost all time is also spent in stack slot related stuff. The culprit is estimate_stack_frame_size (or actually, add_alias_set__conflicts) in cfgexpand.c. (What are we doing in cfgexpand anyway, for inlining?!?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )
--- Comment #15 from steven at gcc dot gnu dot org 2008-12-15 21:55 ---
>From cfgexpand.c:
static void
add_alias_set_conflicts (void)
{
size_t i, j, n = stack_vars_num;
for (i = 0; i < n; ++i)
{
tree type_i = TREE_TYPE (stack_vars[i].decl);
bool aggr_i = AGGREGATE_TYPE_P (type_i);
bool contains_union;
contains_union = aggregate_contains_union_type (type_i);
for (j = 0; j < i; ++j)
{
Classic example of quadratic algorithm...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )
--- Comment #16 from steven at gcc dot gnu dot org 2008-12-15 21:56 --- Oh, and FWIW, for yukawa_gn_full, stack_vars_num == 67551 for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI
--- Comment #17 from whaley at cs dot utsa dot edu 2008-12-15 22:01 --- >LSB was written years after we had already did this back in gcc 3.0. >Please check the history before saying gcc followed a written standard >when none existed when this change was done. LSB was merely the umbrella bringing together a bunch of pre-existing standards for use in Linux. I believe the ABI in question was done in 1997. Is it your position that gcc predates this standard, and follows it in every aspect save stack alignment by pure chance? You are correct that I do not have all the history of gcc at my fingertips, but I rather suspect you do not as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496
Re: [Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI
On Mon, Dec 15, 2008 at 2:01 PM, whaley at cs dot utsa dot edu wrote: > LSB was merely the umbrella bringing together a bunch of pre-existing > standards > for use in Linux. There is the problem, LSB did the incorrect thing of thinking the written standard applied to what really was being done when the LSB was doing its work. Standards are made to be amended. Witness how many RFCs there are and how many make previous ones outdated. Thanks, Andrew Pinski
[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI
--- Comment #18 from pinskia at gmail dot com 2008-12-15 23:02 --- Subject: Re: Gcc misaligns arrays when stack is forced follow the x8632 ABI On Mon, Dec 15, 2008 at 2:01 PM, whaley at cs dot utsa dot edu wrote: > LSB was merely the umbrella bringing together a bunch of pre-existing > standards > for use in Linux. There is the problem, LSB did the incorrect thing of thinking the written standard applied to what really was being done when the LSB was doing its work. Standards are made to be amended. Witness how many RFCs there are and how many make previous ones outdated. Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496
[Bug middle-end/38533] [4.2/4.3/4.4 regression] Inefficient stack usage
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c |middle-end GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet||x86_64-unknown-linux-gnu Target Milestone|--- |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38533
[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-15 23:26 --- The reason why they are saved is so that you can have a good way of debugging noreturn functions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI
--- Comment #19 from whaley at cs dot utsa dot edu 2008-12-15 23:39 --- >There is the problem, LSB did the incorrect thing of thinking the written >standard applied to what really was being done when the LSB was doing its >work. Standards are made to be amended. Witness how many RFCs there are and >how many make previous ones outdated. Actually, standards are made to make interoperation work, which only works if people follow them. Amending is fine, ignoring or extending them without amending them is not. The idea that LSB made the error rather than you folks is hubris at best. If you thought the standard adopted by LSB was the wrong one, you should have participated in the process and fixed it. It would have been difficult on this stack point, because the convenience of avoiding two operations in the preamble and one in the epilogue would almost certainly have convinced any standards body to break backwards compatibility (and this ABI standard has been around a long while). gcc used to follow this standard, and later decided to break it. You guys are saying that not only do you not follow this standard, but you don't follow *any* ABI standard. OK, but don't tell me its because there is/was no standard, because there both is and was. Don't tell me it cannot be used with modern architectures, because it obviously can. Don't tell me its everyone else's fault, and you guys are doing the right thing. You broke a standard you used to follow for the convenience of having an aligned stack (as your contemporaneous e-mail shows), so you lost standards compliance for essentially zero gain. You are of course free to make your compiler do anything you want to do, but this BS about their being no standard, or the standard being unusable with SSE does not cut it. Thanks, Clint -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496
[Bug c/38537] New: -fstrict-aliasing and -Wstrict-aliasing do not work
It seems that -fstring-aliasing option doesn't work:
$ cat test.c
#include
int
main (void)
{
int a = 0x12345678;
short *b = (short *) &a;
b[1] = 0;
if (a == 0x12345678)
abort();
exit(0);
}
$ gcc -fstrict-aliasing test.c
$ ./a.out
$ gcc -O2 test.c
$ ./a.out
Aborted
There are no any warnings with -Wstrict-analising=3 for the testcase above:
$ gcc -Wstrict-aliasing=3 test.c
$
These options are tested for:
gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-cpu=generic --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC)
gcc34 -v
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-languages=c,c++,f77 --disable-libgcj
--host=x86_64-redhat-linux
Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-9)
--
Summary: -fstrict-aliasing and -Wstrict-aliasing do not work
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anvoebugz at gmail dot com
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64
GCC target triplet: x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38537
[Bug c/38537] -fstrict-aliasing and -Wstrict-aliasing do not work
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-15 23:54 --- -fstring-aliasing is only used when optimizing .. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38537
[Bug middle-end/38537] -fstrict-aliasing and -Wstrict-aliasing do not work
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-15 23:55 ---
On the trunk we do get a warning:
t.c: In function main:
t.c:7: warning: dereferencing pointer ({anonymous}) does break
strict-aliasing rules
t.c:7: note: initialized from here
Though it seems like the warning itself could be improved.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38537
[Bug middle-end/38537] -fstrict-aliasing and -Wstrict-aliasing do not work
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-15 23:57 --- Richard, seems like the variable is going to anonymous and it is defined via a POINTER_PLUS_EXPR, we should go back one more on def-use chain. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38537
[Bug c/38528] ICE while building libgfortran (gcc bootstrap)
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-16 00:01 --- -combine should go away and the code which supports should be removed really. It is always broken and will most likely will always be broken. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38528
[Bug c++/38525] sse2(int16) code fails with -O3
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-12-16 00:03 ---
int16_t* ip = (int16_t*)&m1;
printf("%hi %hi %hi %hi %hi %hi %hi %hi \n", *ip++, *ip++, *ip++,
*ip++, *ip++, *ip++, *ip++, *ip);
That is violating C/C++ aliasing rules even if __m128i is marked with
may_alias, the type you are accessing via is not marked as such.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38525
[Bug c++/38522] g++ -Wconversion warnings
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-16 00:06 --- These all do not produce warnings for 4.4 and above. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38522
[Bug c++/37922] [4.4 Regression] code generation error
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-12-16 00:08 --- Does -fno-strict-aliasing work? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922
[Bug c++/37922] [4.4 Regression] code generation error
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|code generation error |[4.4 Regression] code ||generation error Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922
[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI
--- Comment #20 from joseph at codesourcery dot com 2008-12-16 00:09 --- Subject: Re: Gcc misaligns arrays when stack is forced follow the x8632 ABI On Mon, 15 Dec 2008, whaley at cs dot utsa dot edu wrote: > If you thought the standard adopted by LSB was the wrong > one, you should have participated in the process and fixed it. Nonsense. It's not the responsibility of the GCC community or any of its members to correct the misconceptions of any or all third parties, and never had been. There is no more responsibility to correct LSB's mistakes than to correct misconceptions about the ABI written in a random webpage, student project or magazine article. Both have exactly the same status as irrelevant to GCC unless and until GCC chooses to treat them as relevant. Millions of people write huge amounts of inaccurate information about things they don't understand and those who understand them have no responsibility to correct the information; the LSB and the IA32 GNU/Linux ABI is just one random such case among millions, with no special status. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496
[Bug target/38519] gcc build fails - won't link in 'gcc' on SVN obtained 20081213
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-16 00:09 --- This sounds like an issue with the redhat provided GCC and not in GCC you are trying to compile. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target GCC build triplet||i386-redhat-linux GCC target triplet|avr |i386-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38519
[Bug c++/38517] At definition of the empty reference the error is not output.
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-16 00:11 --- t.c:1: error: 'i' declared as reference but not initialized Why do you think this is valid code? Reference variables have to be initialized. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38517
[Bug c++/38517] At definition of the empty reference the error is not output.
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-16 00:12 --- extern int &i; is valid though. Note in C, int i; is a tentative definition while in C++, there is no such thing as a tentative definition so it is normal definition and therefor since it is a reference type variable, it has to be initialized. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38517
[Bug c++/38392] Template friend function injection
--- Comment #1 from H9XLrv5oXVNvHiUI at spambox dot us 2008-12-16 01:03 --- Any news? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38392
[Bug c++/38392] Template friend function injection
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38392
[Bug c++/38392] Template friend function injection
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-16 01:08 --- Confirmed, not a regression. If you swap around main and the template, the link works correctly. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||link-failure Known to fail||3.3.3 4.4.0 4.0.2 Last reconfirmed|-00-00 00:00:00 |2008-12-16 01:08:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38392
[Bug target/38519] gcc build fails - won't link in 'gcc' on SVN obtained 20081213
--- Comment #2 from esmithmail at gmail dot com 2008-12-16 01:40 --- Subject: Re: gcc build fails - won't link in 'gcc' on SVN obtained 20081213 ok -- except that I've been using the 4.0.0 branch for months. I successfully built (and used) gcc-core from SVN on all these dates: 20080802, 20080817, 20080913, 20080921, 20081012, 20081019, 20081026, 20081109, 20081115, 20081116, and 20081123. I never had the problem linking until 20081213. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38519
[Bug target/38519] gcc build fails - won't link in 'gcc' on SVN obtained 20081213
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-16 01:44 --- That could mean this was not exposed in the redhat GCC version until that revision of GCC. The error is coming from linking of the native program and not from the new GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38519
[Bug target/30271] -mstrict-align can an store extra for struct agrument passing
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-12-16 02:08 --- (In reply to comment #9) > Andrew, > > What is your point here? My point here is that currently we do: gi->frame_related = (base == frame_pointer_rtx) || (base == hard_frame_pointer_rtx); But if we change it to be: gi->frame_related = (base == frame_pointer_rtx) || (base == hard_frame_pointer_rtx) || (base == arg_pointer_rtx && fixed_regs[ARG_POINTER_REGNUM]); It would delete the store (at least in a 4.3 based compiler). arg_pointer_rtx is the incoming argument space so if it is a fixed register it will be also frame related and we can safely delete the stores to this space. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271
[Bug c++/37922] [4.4 Regression] code generation error
--- Comment #7 from rwgk at yahoo dot com 2008-12-16 02:17 --- (In reply to comment #6) > Does -fno-strict-aliasing work? > Nope. I just tried it with svn revisions 129269 and 142737. Adding -fno-strict-aliasing does not change the (wrong) result. Thanks for looking at this! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922
[Bug c++/37922] [4.4 Regression] code generation error
--- Comment #8 from hjl dot tools at gmail dot com 2008-12-16 04:01 --- Gcc 4.3 20080428 behaves the same. -m32 returns 0. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922
[Bug fortran/38538] New: ICE with elemental character function
For the code below stored in xtemp.f90
module abc
implicit none
contains
subroutine xmain()
call foo(func("_"//bar()))
end subroutine xmain
!
function bar() result(yy)
character (len=1) :: yy(1)
yy = ""
end function bar
!
elemental function func(yy) result(xy)
character (len=*), intent(in) :: yy
character (len=len(yy)) :: xy
xy = yy
end function func
!
subroutine foo(cc)
character (len=*), intent(in) :: cc(:)
print*,cc
end subroutine foo
end module abc
gfortran -c xtemp.f90 gives
xtemp.f90: In function 'xmain':
xtemp.f90:8: internal compiler error: in gfc_conv_function_call, at
fortran/trans-expr.c:2846
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
gfortran -v gives
Built by Equation Solution (http://www.Equation.com).
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../gcc-4.4-20081212-mingw/configure --host=i386-pc-mingw32
--build=x86_64-unknown-linux-gnu --target=i386-pc-mingw32
--prefix=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gcc/4.4-20081212
--with-gcc --with-gnu-ld --with-gnu-as --disable-shared --disable-nls
--disable-tls
--with-gmp=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gmp
--with-mpfr=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/mpfr
--enable-languages=c,fortran,c++
--with-sysroot=/home/gfortran/gcc-home/binary/mingw32/cross/x86_32/gcc/4.4-20081212
--enable-libgomp --enable-threads=win32 --disable-win32-registry
Thread model: win32
gcc version 4.4.0 20081212 (experimental) (GCC)
--
Summary: ICE with elemental character function
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vivekrao4 at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38538
[Bug c/38539] New: inline-asm with labels does not compile at -O3
When -O3 key is specified, gcc inlines functions with inline asm
without dismangling the labels in these asm fragments. This occurs in
all flavours of the asm pieces: CONSTRAIN, MASM and plain string:
% cat gas-label.c
f() {
#ifdef CONSTRAIN
asm volatile ("lab:mov %0, %0"::"r"(1.5F));
#elif defined(MASM)
asm{mov eax, 0x3fc00;
lab: mov eax, eax}
#else
asm(" movl$0x3fc, %eax \n"
"lab: mov %eax, %eax");
#endif
}
main() {
f();
f();
}
%
% gcc -pedantic gas-label.c
% gcc -DCONSTRAIN gas-label.c -finline-functions
% gcc -DCONSTRAIN gas-label.c -O3
/tmp/ccd4XxX8.s: Assembler messages:
/tmp/ccd4XxX8.s:28: Error: symbol `lab' is already defined
/tmp/ccd4XxX8.s:29: Error: symbol `lab' is already defined
%
% gcc -v -save-temps -DCONSTRAIN gas-label.c -O3
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.0/configure
--prefix=/nfs/ins/proj/icl/qa/QA_verification/gnu/local --disable-nls
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.1.0
/nfs/ins/proj/icl/qa/QA_verification/gnu/local/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1
-E -quiet -v -DCONSTRAIN gas-label.c -mtune=pentiumpro -O3 -fpch-preprocess -o
gas-label.i
ignoring nonexistent directory
"/nfs/ins/proj/icl/qa/QA_verification/gnu/local/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/nfs/ins/proj/icl/qa/QA_verification/gnu/local/include
/nfs/ins/proj/icl/qa/QA_verification/gnu/local/lib/gcc/i686-pc-linux-gnu/4.1.0/include
/usr/include
End of search list.
/nfs/ins/proj/icl/qa/QA_verification/gnu/local/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1
-fpreprocessed gas-label.i -quiet -dumpbase gas-label.c -mtune=pentiumpro
-auxbase gas-label -O3 -version -o gas-label.s
GNU C version 4.1.0 (i686-pc-linux-gnu)
compiled by GNU C version 4.1.0.
GGC heuristics: --param ggc-min-expand=100 --param
ggc-min-heapsize=131072
Compiler executable checksum: 9c14cefcbb08ee412959d25f87b03831
/nfs/ins/proj/icl/qa/QA_verification/gnu/local/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/bin/as
-V -Qy -o gas-label.o gas-label.s
GNU assembler version 2.16 (i686-pc-linux-gnu) using BFD version 2.16
gas-label.s: Assembler messages:
gas-label.s:28: Error: symbol `lab' is already defined
gas-label.s:29: Error: symbol `lab' is already defined
%
%
% cat gas-label.i
# 1 "gas-label.c"
# 1 ""
# 1 ""
# 1 "gas-label.c"
f() {
asm volatile ("lab:mov %0, %0"::"r"(1.5F));
}
main() {
f();
f();
}
%
--
Summary: inline-asm with labels does not compile at -O3
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sergio dot pokrovskij at gmail dot com
GCC host triplet: i386 GNU/Linux
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38539
[Bug c++/38517] At definition of the empty reference the error is not output.
--- Comment #3 from lisp2d at lisp2d dot net 2008-12-16 05:52 --- More exact example: .h: extern int& i; .cpp: int& i; // ok -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38517
[Bug c/38539] inline-asm with labels does not compile at -O3
--- Comment #1 from steven at gcc dot gnu dot org 2008-12-16 06:22 --- See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20468#c1 -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38539
[Bug fortran/38538] ICE with elemental character function
--- Comment #1 from dominiq at lps dot ens dot fr 2008-12-16 07:24 --- Confirmed on (powerpc|i686)-apple-darwin9 revision 142767. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38538
[Bug middle-end/38474] slow compilation at -O0 (callgraph optimization, inline heuristics, expand )
--- Comment #17 from jv244 at cam dot ac dot uk 2008-12-16 07:51 --- (In reply to comment #16) > Oh, and FWIW, for yukawa_gn_full, stack_vars_num == 67551 for me. Thanks for the analysis. Detailed enough to have me peak in the gcc code for once. This would mean that the array stack_vars_conflict takes about 2.2Gb, since it is O(stack_vars_num**2/2) (assuming a bool is 8bits, quite consistent with what we see). There is already a function (defer_stack_allocation) that decides to give up due to 'the quadratic problem'. Maybe gcc should use some drastic short-cut, including not allocating the stack_vars_conflict array, as soon as ~1 stack variables are detected ? BTW, the -O3 compilation is still running (for 17h now). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
