[Bug target/44199] ppc64 glibc miscompilation
--- Comment #18 from jakub at gcc dot gnu dot org 2010-05-26 06:01 --- Subject: Bug 44199 Author: jakub Date: Wed May 26 06:00:44 2010 New Revision: 159853 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159853 Log: PR target/44199 * config/rs6000/rs6000.c (rs6000_emit_epilogue): If cfun-calls_alloca or total_size is larger than red zone size for non-V4 ABI, emit a stack_tie resp. frame_tie insn before stack pointer restore. * config/rs6000/rs6000.md (frame_tie): New insn. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44199
[Bug target/44199] ppc64 glibc miscompilation
--- Comment #19 from jakub at gcc dot gnu dot org 2010-05-26 06:02 --- Subject: Bug 44199 Author: jakub Date: Wed May 26 06:02:30 2010 New Revision: 159854 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159854 Log: PR target/44199 * config/rs6000/rs6000.c (rs6000_emit_epilogue): If cfun-calls_alloca or total_size is larger than red zone size for non-V4 ABI, emit a stack_tie resp. frame_tie insn before stack pointer restore. * config/rs6000/rs6000.md (frame_tie): New insn. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_5-branch/gcc/config/rs6000/rs6000.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44199
[Bug target/44199] ppc64 glibc miscompilation
--- Comment #20 from jakub at gcc dot gnu dot org 2010-05-26 06:05 --- Subject: Bug 44199 Author: jakub Date: Wed May 26 06:05:29 2010 New Revision: 159855 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159855 Log: PR target/44199 * config/rs6000/rs6000.c (rs6000_emit_epilogue): If cfun-calls_alloca or total_size is larger than red zone size for non-V4 ABI, emit a stack_tie resp. frame_tie insn before stack pointer restore. * config/rs6000/rs6000.md (frame_tie): New insn. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_4-branch/gcc/config/rs6000/rs6000.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44199
[Bug target/44199] ppc64 glibc miscompilation
--- Comment #21 from jakub at gcc dot gnu dot org 2010-05-26 06:07 --- Should be fixed now. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44199
[Bug debug/39368] loc_descriptor doesn't call delegitimize_address on MEMs
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-26 07:03 --- Not sure whether this patch is still needed now that var-tracking already delegitimizes MEMs (and their addresses) too. That said, if you have a testcase where this is still needed, the patch looks reasonable, so you might want to ping it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39368
[Bug other/44034] target hooks are hard to maintain
--- Comment #3 from amylaar at gcc dot gnu dot org 2010-05-26 07:57 --- (In reply to comment #2) updated patch for revision 159828: http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01938.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44034
[Bug c/44272] Wrong interpretation of hex constant as floating point value.
--- Comment #2 from draqsn at mail dot ru 2010-05-26 08:47 --- Sorry, my mistake. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44272
[Bug target/44227] Invalid instruction generation in Thumb2 for tst instruction.
--- Comment #3 from ramana at gcc dot gnu dot org 2010-05-26 08:50 --- Yes - confirmed fixed with the reduced testcase. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44227
[Bug target/43805] ICE when building Linux kernel 2.6.34-rc4
--- Comment #5 from jon at beniston dot com 2010-05-26 09:15 --- Created an attachment (id=20746) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20746action=view) Possible fix for bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43805
[Bug target/43726] [4.5/4.6 Regression] lm32-rtems* ICE
--- Comment #6 from jon at beniston dot com 2010-05-26 09:15 --- Created an attachment (id=20747) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20747action=view) Possible fix for bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43726
[Bug bootstrap/43699] [4.6 regression] variable set but not used error during bootstrap
--- Comment #8 from jakub at gcc dot gnu dot org 2010-05-26 10:02 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43699
[Bug inline-asm/44018] [4.5/4.6 Regression] Using cpuid.h, can't find a register in class 'CLOBBERED_REGS' while reloading 'asm'
--- Comment #6 from jakub at gcc dot gnu dot org 2010-05-26 10:03 --- Perhaps related to PR44174. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44018
[Bug rtl-optimization/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function
--- Comment #23 from rguenth at gcc dot gnu dot org 2010-05-26 10:30 --- Subject: Bug 44164 Author: rguenth Date: Wed May 26 10:30:31 2010 New Revision: 159861 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159861 Log: 2010-05-26 Richard Guenther rguent...@suse.de PR rtl-optimization/44164 * tree-ssa-alias.c (aliasing_component_refs_p): Fix the no-common access-path disambiguation. (indirect_ref_may_alias_decl_p): Adjust. (indirect_refs_may_alias_p): Likewise. (refs_may_alias_p_1): Likewise. * gcc.c-torture/execute/pr44164.c: New testcase. * g++.dg/tree-ssa/pr13146.C: Adjust. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr44164.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/tree-ssa/pr13146.C trunk/gcc/tree-ssa-alias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44164
[Bug tree-optimization/43657] [4.3/4.4/4.5/4.6 Regression] -ftree-loop-linear causes FAIL: gcc.dg/vect/vect-cond-5.c execution test
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-26 11:15 --- Created an attachment (id=20748) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20748action=view) pr43657.c Slightly adjusted testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43657
[Bug middle-end/44069] [4.5 Regression] optimization bug initializing from cast array
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-05-26 11:44 --- Subject: Bug 44069 Author: rguenth Date: Wed May 26 11:44:44 2010 New Revision: 159865 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159865 Log: 2010-05-26 Richard Guenther rguent...@suse.de PR middle-end/44069 * tree-ssa-ccp.c (maybe_fold_stmt_addition): Avoid generating out-of-bounds array accesses. * g++.dg/torture/pr44069.C: New testcase. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/torture/pr44069.C Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/tree-ssa-ccp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44069
[Bug rtl-optimization/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function
--- Comment #24 from rguenth at gcc dot gnu dot org 2010-05-26 11:46 --- Subject: Bug 44164 Author: rguenth Date: Wed May 26 11:46:01 2010 New Revision: 159866 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159866 Log: 2010-05-26 Richard Guenther rguent...@suse.de PR rtl-optimization/44164 * tree-ssa-alias.c (aliasing_component_refs_p): Fix the no-common access-path disambiguation. (indirect_ref_may_alias_decl_p): Adjust. (indirect_refs_may_alias_p): Likewise. (refs_may_alias_p_1): Likewise. * gcc.c-torture/execute/pr44164.c: New testcase. * g++.dg/tree-ssa/pr13146.C: Adjust. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/execute/pr44164.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/g++.dg/tree-ssa/pr13146.C branches/gcc-4_5-branch/gcc/tree-ssa-alias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44164
[Bug middle-end/44069] [4.5 Regression] optimization bug initializing from cast array
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-05-26 11:46 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail||4.5.0 Known to work|4.6.0 |4.5.1 4.6.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44069
[Bug rtl-optimization/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function
--- Comment #25 from rguenth at gcc dot gnu dot org 2010-05-26 11:46 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|4.4.3 4.6.0 |4.4.3 4.5.1 4.6.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44164
[Bug target/43636] [4.5/4.6 Regression] ICE in extract_insn, at recog.c:2103
--- Comment #4 from jakub at gcc dot gnu dot org 2010-05-26 11:48 ---
More reduced testcase (fails with both -m31 -O0 and -m64 -O0 on the trunk):
extern char a[], *b[];
char *
foo (char *x, int y)
{
x = __builtin_stpcpy (x, b[a[y]]);
return x;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43636
[Bug lto/44150] [4.6 regression] g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-05-26 12:11 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-05-15 21:40:13 |2010-05-26 12:11:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44150
[Bug rtl-optimization/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #15 from mikpe at it dot uu dot se 2010-05-26 12:44 --- Created an attachment (id=20749) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20749action=view) proposed 4.6 fix for PR38644 PR38644 and its dupes are very similar to PowerPC PR44199 and PR30282. PR44199 was recently fixed by conditionally emitting stack ties in epilogues. I first intended to simply clone that approach for Thumb1, but it turns out there's already a conditional barrier in thumb1_expand_epilogue (). So for now I simply extended that condition to also trigger whenever there's stack pointer adjustment in the epilogue. I've confirmed that this fixes the test cases in PR38644, PR42155, and PR44091. I know that Richard Earnshaw has stated that he considers this a middle-end rather than a back-end bug, and I agree with that. However, given that this wrong-code bug has been known for so long with no middle-end fix in sight, I think solving it in the back-end is appropriate for now, at least for 4.4/4.5. The current patch is a little too heavy in that it also blocks non memory accesses from being scheduled past the stack pointer adjustment -- I saw an example of that in the large PR44091 test case. Using a stack tie instead of a full barrier should hopefully fix that. So far only tested with 4.4/4.5/4.6 crosses to armv5tel-unknown-linux-gnueabi. I'll try this in a 4.5 native bootstrap soonish (4.6 bootstraps are currently broken on ARM, see PR44255). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug target/43636] [4.5/4.6 Regression] ICE in extract_insn, at recog.c:2103
--- Comment #5 from jakub at gcc dot gnu dot org 2010-05-26 12:48 --- Created an attachment (id=20750) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20750action=view) gcc46-pr43636.patch Untested fix. Andreas, could you please bootstrap/regtest this on s390* on the trunk? -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43636
[Bug middle-end/44276] [4.6 Regression]: gcc.dg/tls/alias-1.c
--- Comment #4 from danglin at gcc dot gnu dot org 2010-05-26 12:56 --- This also occurs on hppa64-hp-hpux11.11. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44276
[Bug c++/44282] New: GCC allows for function overloading with pointer to function as parameter based on calling convention but assembler complains
When you have function that gets pointer to a function as parameter, it is possible to overload it based on calling convention of parameter function. But apparently compiler generate the same signature anyway and assembler complains about redefinition. $ g++ test.cpp /tmp/ccgIM8Ir.s: Assembler messages: /tmp/ccgIM8Ir.s:103: Error: symbol `_Z1pIvEvPFT_vE' is already defined -- Summary: GCC allows for function overloading with pointer to function as parameter based on calling convention but assembler complains Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vadim dot atlygin at gmail dot com GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44282
[Bug c++/44282] GCC allows for function overloading with pointer to function as parameter based on calling convention but assembler complains
--- Comment #1 from vadim dot atlygin at gmail dot com 2010-05-26 12:59 --- Created an attachment (id=20751) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20751action=view) isolated test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44282
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #56 from jv244 at cam dot ac dot uk 2010-05-26 13:13 --- (In reply to comment #55) Subject: Bug 40011 Author: pault Date: Wed May 26 05:11:04 2010 New Revision: 159852 I'm still having linking problems with -fwhole-file on the single source file version of CP2K. Will try to get to a testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug target/43249] unsigned int arg with no prototype gets full 64-bit reg
--- Comment #2 from amodra at gmail dot com 2010-05-26 13:22 --- I think this testcase may invoke undefined behaviour. Section 6.5.2.2 of the ISO C spec says of function calls without a prototype that if the types of the arguments after promotion are not compatible with those of the parameters after promotion, the behavior is undefined, except for the following cases and the relevant case is one promoted type is a signed integer type, the other promoted type is the corresponding unsigned integer type, and the value is representable in both types. The value you are passing, (int)4294967259U, is a negative number so not representable as an unsigned int. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43249
[Bug c++/44283] New: bad error recovery for explicit template instantiation in wrong namespace
namespace NS
{
typedef int X;
templatetypename T void f(X f, T t) { }
}
template void f(X, int); // (1)
template void f(int, char); // (2)
The code is invalid, the explicit instantiations should be inside NS or should
be qualified e.g.
template void NS::func(X, int);
But the diagnostic for instantiation (1) is unhelpful:
bug.cc:8:17: error: variable or field 'f' declared void
bug.cc:8:16: error: expected ';' before '(' token
This is closely related to Bug 16663 but the diagnostic for (2) implies it
might be possible to improve things without fixing bug 16663, as this is much
better:
bug.cc:10:26: error: 'f' is not a template function
Is it possible to give the same is not a template function diagnostic for
(1)?
Comeau does significantly better, reporting:
identifier X is undefined
and
f is not a class or function template name in the current scope
If the invalid instantiation is for a class template the diagnostic is fine:
namespace NS
{
templatetypename T struct S;
}
template struct SX;
bug2.cc:6:17: error: 'S' is not a template
bug2.cc:6:19: error: 'X' was not declared in this scope
bug2.cc:6:17: error: explicit instantiation of non-template type 'S'
The only improvement I would make would be to add something like in this
scope to the first error.
Here's another bad diagnostic for instantiating a template function, which
doesn't have any undeclared type:
namespace NS
{
templateint N void g() { }
}
template void g0();
bug3.cc:6:15: error: variable or field 'g' declared void
bug3.cc:6:16: error: expected ';' before '' token
Surely it's possible to say g is not a template function when the compiler
sees template ... g... ?
Comeau is much better again:
ComeauTest.c, line 6: error: g is not a template,
Should it be XX::g?, where XX is some namespace?
Did you #include the right header?
template void g0();
^
ComeauTest.c, line 6: error: invalid explicit instantiation declaration
template void g0();
^
--
Summary: bad error recovery for explicit template instantiation
in wrong namespace
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jwakely dot gcc at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44283
[Bug middle-end/44276] [4.6 Regression]: gcc.dg/tls/alias-1.c
--- Comment #5 from iains at gcc dot gnu dot org 2010-05-26 14:12 --- (In reply to comment #4) This also occurs on hppa64-hp-hpux11.11. OK, I've built gcc newlib for cris-elf and it's apparent that we need to deal with the fact that that aliased emutls symbols are named differently... that is the user writes alias(foo) ... but the emulated tls system needs to understand alias(__emutls_v.foo) ) I'll take a look at how to implement this... .. sorry for this fallout from the other fix The patch @ comment#24 of PR44132 also needs to understand this issue, and won't solve this problem yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44276
[Bug fortran/40873] -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away
--- Comment #13 from burnus at gcc dot gnu dot org 2010-05-26 14:28 --- Is this now fixed by the following commit? Or is something else to be done (additional fix, backporting, ...)? URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159852 Log: 2010-05-26 Paul Thomas pa...@gcc.gnu.org PR fortran/40011 * resolve.c (resolve_global_procedure): Resolve the gsymbol's namespace before trying to reorder the gsymbols. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40873
[Bug fortran/40873] -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away
--- Comment #14 from dominiq at lps dot ens dot fr 2010-05-26 14:41 --- Is this now fixed by the following commit? Or is something else to be done (additional fix, backporting, ...)? At least ac.f90 (probably all the items of the list) fails to link with -O -fwhole-program at revision 159855. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40873
[Bug fortran/40873] -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away
--- Comment #15 from burnus at gcc dot gnu dot org 2010-05-26 14:45 --- (In reply to comment #13) Is this now fixed by the following commit? Answer: It is not. Comment 1 now works with -fwhole-program -O1, but comment 0 and comment 4 still fail. (Though, they work with -fwhole-file -O1.) (In reply to comment #12) My belief is that with this patch and corrections of the legacy style testsuite cases, -fwhole-file could be finally made the default. As there are no -fwhole-file failures in this PR (though -fwhole-file bugs, revealed through -fwhole-program), I think this PR does not prevent enabling -fwhole-file by default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40873
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #57 from dominiq at lps dot ens dot fr 2010-05-26 14:52 ---
Author: pault
Date: Wed May 26 05:11:04 2010
New Revision: 159852
The original code of pr40440 and the reduced test of comment #47 still ICE:
(gdb) run -fwhole-file pr40440_red.f90
Starting program:
/opt/gcc/gcc4.6w/libexec/gcc/x86_64-apple-darwin10.3.0/4.6.0/f951 -fwhole-file
pr40440_red.f90
line_get_string_advance line_init syntax_init_from_ifile
Breakpoint 1, fancy_abort (file=0x1009c1d20 ../../work/gcc/fold-const.c,
line=2042, function=0x100a2b850 fold_convert_loc) at
../../work/gcc/diagnostic.c:787
787 {
(gdb) bt
#0 fancy_abort (file=0x1009c1d20 ../../work/gcc/fold-const.c, line=2042,
function=0x100a2b850 fold_convert_loc) at ../../work/gcc/diagnostic.c:787
#1 0x0001004bb6d1 in fold_convert_loc (loc=0, type=0x141e17930, arg=value
temporarily unavailable, due to optimizations) at
../../work/gcc/fold-const.c:2042
#2 0x0001000cc014 in gfc_trans_scalar_assign (lse=0x7fff5fbfd5f0,
rse=0x7fff5fbfd5a0, ts={type = BT_DERIVED, kind = 0, u = {derived = 0x0, cl =
0x0}, interface = 0x0, is_c_interop = 0, is_iso_c = 0, f90_type = 0},
l_is_temp=0 '\0', r_is_var=0 '\0', dealloc=1 '\001') at
../../work/gcc/fortran/trans-expr.c:4836
#3 0x0001000cf844 in gfc_trans_assignment_1 (expr1=0x14181e5d0,
expr2=0x14181e750, init_flag=0 '\0', dealloc=1 '\001') at
../../work/gcc/fortran/trans-expr.c:5282
#4 0x0001000cfc34 in gfc_trans_assignment (expr1=0x14181e5d0,
expr2=0x14181e750, init_flag=0 '\0', dealloc=1 '\001') at
../../work/gcc/fortran/trans-expr.c:5424
#5 0x0001000aa8e6 in trans_code (code=0x14181e810, cond=0x0) at
../../work/gcc/fortran/trans.c:1082
#6 0x0001000c769f in gfc_generate_function_code (ns=value temporarily
unavailable, due to optimizations) at ../../work/gcc/fortran/trans-decl.c:4483
#7 0x0001000aad0b in gfc_generate_module_code (ns=value temporarily
unavailable, due to optimizations) at ../../work/gcc/fortran/trans.c:1392
#8 0x00010006cd0f in gfc_parse_file () at
../../work/gcc/fortran/parse.c:4287
#9 0x0001000a586c in gfc_be_parse_file (set_yydebug=value temporarily
unavailable, due to optimizations) at ../../work/gcc/fortran/f95-lang.c:239
#10 0x0001006dc789 in toplev_main (argc=3, argv=0x7fff5fbfdad0) at
../../work/gcc/toplev.c:1049
#11 0x00011094 in start ()
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug c++/43382] [C++0x] ICE with auto return type and variadic templates
--- Comment #5 from jason at gcc dot gnu dot org 2010-05-26 15:00 --- Subject: Bug 43382 Author: jason Date: Wed May 26 15:00:02 2010 New Revision: 159873 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159873 Log: PR c++/43382 * pt.c (fn_type_unification): Don't get confused by recursive unification. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic101.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43382
[Bug bootstrap/44255] [4.6 regression] gcc-4.6-20100522 bootstrap comparison failure on sparc64 and arm
--- Comment #10 from mikpe at it dot uu dot se 2010-05-26 15:16 --- (In reply to comment #2) My ARM box is currently busy running another test, but as soon as that finishes I'll check if r159600 is also responsible for the ARM bootstrap failure. It is, r159599 bootstraps on ARM, r159600 does not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44255
[Bug c++/43382] [C++0x] ICE with auto return type and variadic templates
--- Comment #6 from jason at gcc dot gnu dot org 2010-05-26 15:19 --- Subject: Bug 43382 Author: jason Date: Wed May 26 15:18:46 2010 New Revision: 159875 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159875 Log: PR c++/43382 * pt.c (fn_type_unification): Don't get confused by recursive unification. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/cpp0x/variadic101.C Modified: branches/gcc-4_5-branch/gcc/cp/ChangeLog branches/gcc-4_5-branch/gcc/cp/pt.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43382
[Bug target/44284] New: vectorization does not work for short variable
Hi,
I have tried vectorization and encountered a problem which I can see
is common to some ports (I tried ia64 and bfin).
For this function:
#define ts unsigned short
void f(ts* __restrict__ a, ts* __restrict__ b, ts* __restrict__ x)
{
int i;
for (i=0;i1024;i++)
x[i] = a[i] + b[i];
}
the loop is vectorized.
But if I define ts as follows: #define ts short
then the loop is not vectorized. The message I get is:
./a.c:21: note: no optab.
./a.c:21: note: not vectorized: relevant stmt not supported: D.1279_12
= (short unsigned int) D.1278_11;
I have tried to look a bit in the vectorizer code and it seems that
for this stmt I get to vectorizable_operation with code==NOP_EXPR
which is not handled.
Does anyone knows anything about this problem?
Thanks, Roy.
./xgcc -v -save-temps -O3 -S ./a.c -ftree-vectorizer-verbose=2
Using built-in specs.
Target: ia64-*-linux
Configured with: ../gcc-4.4.3/configure --target='ia64-*-linux'
--enable-languages=c : (reconfigured)
Thread model: posix
gcc version 4.4.3 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-S' '-ftree-vectorizer-verbose=2'
cc1 -E -quiet -v -iprefix
/home/swproj/sw/users/eyalhar/gcc-ia64/gcc/../lib/gcc/ia64-*-linux/4.4.3/ ./a.c
-ftree-vectorizer-verbose=2 -O3 -fpch-preprocess -o a.i
ignoring nonexistent directory
/home/swproj/sw/users/eyalhar/gcc-ia64/gcc/../lib/gcc/ia64-*-linux/4.4.3/include
ignoring nonexistent directory
/home/swproj/sw/users/eyalhar/gcc-ia64/gcc/../lib/gcc/ia64-*-linux/4.4.3/include-fixed
ignoring nonexistent directory
/home/swproj/sw/users/eyalhar/gcc-ia64/gcc/../lib/gcc/ia64-*-linux/4.4.3/../../../../ia64-*-linux/sys-include
ignoring nonexistent directory
/home/swproj/sw/users/eyalhar/gcc-ia64/gcc/../lib/gcc/ia64-*-linux/4.4.3/../../../../ia64-*-linux/include
ignoring nonexistent directory
/home/swproj/sw/users/eyalhar/gcc-ia64/gcc/../lib/gcc/../../lib/gcc/ia64-*-linux/4.4.3/include
ignoring nonexistent directory
/home/swproj/sw/users/eyalhar/gcc-ia64/gcc/../lib/gcc/../../lib/gcc/ia64-*-linux/4.4.3/include-fixed
ignoring nonexistent directory
/home/swproj/sw/users/eyalhar/gcc-ia64/gcc/../lib/gcc/../../lib/gcc/ia64-*-linux/4.4.3/../../../../ia64-*-linux/sys-include
ignoring nonexistent directory
/home/swproj/sw/users/eyalhar/gcc-ia64/gcc/../lib/gcc/../../lib/gcc/ia64-*-linux/4.4.3/../../../../ia64-*-linux/include
#include ... search starts here:
#include ... search starts here:
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-S' '-ftree-vectorizer-verbose=2'
cc1 -fpreprocessed a.i -quiet -dumpbase a.c -auxbase a -O3 -version
-ftree-vectorizer-verbose=2 -o a.s
GNU C (GCC) version 4.4.3 (ia64-*-linux)
compiled by GNU C version 4.1.2 20080704 (Red Hat 4.1.2-44), GMP
version 4.3.2, MPFR version 2.4.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: cc15465375f06438c45a5c1ccdf35a17
./a.c:21: note: not vectorized: relevant stmt not supported: D.1236_12 = (short
unsigned int) D.1235_11;
./a.c:18: note: vectorized 0 loops in function.
COMPILER_PATH=
LIBRARY_PATH=
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-S' '-ftree-vectorizer-verbose=2'
--
Summary: vectorization does not work for short variable
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roy dot 1rosen at gmail dot com
GCC build triplet: *
GCC host triplet: linux
GCC target triplet: ia64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44284
[Bug target/44284] vectorization does not work for short variable
--- Comment #1 from roy dot 1rosen at gmail dot com 2010-05-26 15:38 --- Created an attachment (id=20752) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20752action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44284
[Bug tree-optimization/44284] vectorization does not work for short variable
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-26 15:40 --- Confirmed. Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Severity|normal |enhancement Status|UNCONFIRMED |ASSIGNED Component|target |tree-optimization Ever Confirmed|0 |1 GCC build triplet|* | GCC host triplet|linux | GCC target triplet|ia64| Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2010-05-26 15:40:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44284
[Bug c++/44285] New: Need an option that will create symbols for all public c++ methods, not only for those which bodies are outside the class declaration
Consider the example below.
When compiled with flag -O3 methods meth_used and meth_unused aren't present in
the resulting assembly at all.
Now consider the situation when this class is a part of the package compiled
into the shared library and both meth_used and meth_unused are API of this
package.
Without the symbols for meth_used and meth_unused it's pretty much assumed that
the user will have c++ code that will recompile those function into the user
code. It's impossible to bind from other languages only knowing symbols without
c++ coding.
gcc should have an option, either compiler option, or the special keyword on
the method, that would guarantee the method presence in the object.
I looked into __attribute__ visibility. It only allows these values: default,
hidden, protected or internal and doesn't help in this situation.
Maybe public visibility should be added for this case?
-- example header: exp.h --
extern void zzz();
class Abc {
public:
void meth_used() {
zzz();
}
void meth_unused() {
zzz();
}
};
-- example header: exp.C --
#include exp.h
void my_exp() {
(new Abc)-meth_used();
}
--
Summary: Need an option that will create symbols for all public
c++ methods, not only for those which bodies are outside
the class declaration
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44285
[Bug c++/44285] Need an option that will create symbols for all public c++ methods, not only for those which bodies are outside the class declaration
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-26 15:51 --- Well in C++, it is an ODR violation if the Translation units don't define Abc::meth_used and Abc::meth_unused the same. The linkage on these functions is called vague. Exporting them will increase link time in most cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44285
[Bug target/44199] ppc64 glibc miscompilation
--- Comment #22 from pthaugen at gcc dot gnu dot org 2010-05-26 15:51 --- The 4.4 patch isn't complete. /home/gccbuild/gcc_4.4_anonsvn/gcc/gcc/config/rs6000/rs6000.c:17166: undefined reference to `offset_below_red_zone_p' /home/gccbuild/gcc_4.4_anonsvn/gcc/gcc/config/rs6000/rs6000.c:17188: undefined reference to `offset_below_red_zone_p' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44199
[Bug target/44199] ppc64 glibc miscompilation
--- Comment #23 from jakub at gcc dot gnu dot org 2010-05-26 16:09 --- Subject: Bug 44199 Author: jakub Date: Wed May 26 16:09:25 2010 New Revision: 159878 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159878 Log: PR target/44199 * config/rs6000/rs6000.c (rs6000_emit_epilogue): Fix up a backport glitch. Modified: branches/gcc-4_4-branch/gcc/config/rs6000/rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44199
[Bug target/44199] ppc64 glibc miscompilation
--- Comment #24 from jakub at gcc dot gnu dot org 2010-05-26 16:10 --- Oops sorry, forgot redhat/gcc-4_4-branch has this function backported. Fixed now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44199
[Bug rtl-optimization/39580] [4.5 regression] Revision 145204 caused libgomp.c++/collapse-2.C
--- Comment #7 from doko at ubuntu dot com 2010-05-26 16:19 --- seen on the 4.4 branch on ia64-linux-gnu: $ gcc -pthread -fno-strict-aliasing -fwrapv -g -fPIC -ffast-math -O3 -c ../RepCylBond.ilayer2/RepCylBond.c: In function 'RepCylinderBox': layer2/RepCylBond.c:2154: internal compiler error: in insert_in_history_vect, at sel-sched-ir.c:1514 Please submit a full bug report, with preprocessed source if appropriate. the very same patch applied to the 4.4 branch fixes the ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39580
[Bug rtl-optimization/39580] [4.5 regression] Revision 145204 caused libgomp.c++/collapse-2.C
--- Comment #8 from doko at ubuntu dot com 2010-05-26 16:19 --- Created an attachment (id=20753) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20753action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39580
[Bug c++/44285] Need an option that will create symbols for all public c++ methods, not only for those which bodies are outside the class declaration
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-26 16:34 --- GCC has -fkeep-inline-functions, perhaps that's what you are looking for. That said, I still don't understand why you need something like that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44285
[Bug c++/44285] Need an option that will create symbols for all public c++ methods, not only for those which bodies are outside the class declaration
--- Comment #3 from jwakely dot gcc at gmail dot com 2010-05-26 16:36 --- If you don't want the functions to be treated as inline don't make them inline Have you tried -fkeep-inline-functions ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44285
[Bug c++/44285] Need an option that will create symbols for all public c++ methods, not only for those which bodies are outside the class declaration
--- Comment #4 from yuri at tsoft dot com 2010-05-26 16:37 --- Why this is useful, as I wrote above, to eliminate the need for c++ coding for binding with other languages. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44285
[Bug c++/44285] Need an option that will create symbols for all public c++ methods, not only for those which bodies are outside the class declaration
--- Comment #5 from yuri at tsoft dot com 2010-05-26 16:43 --- -fkeep-inline-functions leaves them, but it will also leave all inline functions, not only public ones. This will, I guess, blow up the size of the object since there can be a lot of internal inlines that shouldn't appear in the object. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44285
[Bug c++/44285] Need an option that will create symbols for all public c++ methods, not only for those which bodies are outside the class declaration
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-05-26 16:45 --- What is a public inline function vs a non one in C++ except for static ones? (oh and maybe anonymous namespace ones). In fact functions with just inline is a vague linkage function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44285
[Bug target/43892] PowerPC suboptimal add with carry optimization
--- Comment #14 from segher at kernel dot crashing dot org 2010-05-26 16:46 --- (In reply to comment #13) Please see -mcpu= . Almost forgot, but how do I specify that at gcc build/configure ? You can configure with --with-cpu= to set a default for -mcpu= . Also, I haven't seen any progress on this issue You have no patience, now do you? even though it sounded that the initial fix was easy(addmodecc expander) The fix will be a few thousand lines of patch. Literally. In order to fix this problem (and a whole host of way more important missed optimisation opportunities) we need to expose the CA bit to the compiler as an actual register. Currently, whenever GCC uses the carry bit it does so by having the consumer and producer in a canned asm sequence; this is suboptimal for many reasons. Fixing it properly will take a while. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
[Bug c++/44285] Need an option that will create symbols for all public c++ methods, not only for those which bodies are outside the class declaration
--- Comment #7 from jwakely dot gcc at gmail dot com 2010-05-26 16:55 --- If you only want meth_used and meth_unused to be emitted but you insist on making them inline, then put them in a separate translation unit and compile that with -fkeep-inline-functions. If I understand what you want then you can already do it with no need for new attributes or visibility types. You just need to structure your code appropriately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44285
[Bug c++/43382] [C++0x] ICE with auto return type and variadic templates
--- Comment #7 from jason at gcc dot gnu dot org 2010-05-26 17:15 --- Fixed for 4.5.1. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43382
[Bug c++/44282] GCC allows for function overloading with pointer to function as parameter based on calling convention but assembler complains
--- Comment #2 from pluto at agmk dot net 2010-05-26 17:30 --- on gcc-4.5 we get this: $ g++ -Wall test.cpp test.cpp:9:43: warning: 'fastcall' attribute ignored test.cpp:18:45: warning: 'fastcall' attribute ignored test.cpp:18:46: error: redefinition of 'templateclass T void p(T (*)())' test.cpp:13:20: error: 'templateclass T void p(T (*)())' previously declared here -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44282
[Bug c++/44282] GCC allows for function overloading with pointer to function as parameter based on calling convention but assembler complains
--- Comment #3 from vadim dot atlygin at gmail dot com 2010-05-26 17:43 --- Might be 32/64 bit difference as 64 bit platforms have only one calling convention. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44282
[Bug other/44286] New: Use sentinel attributes in GCC
GCC has various variadic functions (build_function_type_list is one example) with argument lists terminated by NULL. These should all be declared to use the sentinel attribute, via ATTRIBUTE_SENTINEL (a definition of which is brought in via libiberty.h), so that missing termination is detected when GCC is built. -- Summary: Use sentinel attributes in GCC Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44286
[Bug bootstrap/44287] New: [4.6 Regression] Failed to bootstrap
On Linux/ia32, revision 159892 gave: ../../../../src-trunk/libstdc++-v3/libsupc++/fundamental_type_info.cc:36:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[7]: *** [fundamental_type_info.lo] Error 1 Revision 159873 is OK. -- Summary: [4.6 Regression] Failed to bootstrap Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap 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=44287
[Bug bootstrap/44287] [4.6 Regression] Failed to bootstrap
--- Comment #1 from ktietz at gcc dot gnu dot org 2010-05-26 19:49 --- Hmm, is here rtti in use? Could you please test following patch, if it solves your bootstrap issue? Kai Index: gcc/gcc/cp/rtti.c === --- gcc.orig/gcc/cp/rtti.c 2010-05-26 17:54:18.0 +0200 +++ gcc/gcc/cp/rtti.c 2010-05-26 21:46:53.066961700 +0200 @@ -1502,6 +1502,8 @@ emit_support_tinfos (void) tree types[3]; int i; + if (bltn == NULL_TREE) + continue; types[0] = bltn; types[1] = build_pointer_type (bltn); types[2] = build_pointer_type (cp_build_qualified_type (bltn, -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44287
[Bug bootstrap/44287] [4.6 Regression] Failed to bootstrap
--- Comment #2 from hjl dot tools at gmail dot com 2010-05-26 19:52 --- [...@gnu-32 libgfortran]$ /export/build/gnu/gcc/build-x86_64-linux/./gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/./gcc/ -B/usr/gcc-4.6.0/x86_64-unknown-linux-gnu/bin/ -B/usr/gcc-4.6.0/x86_64-unknown-linux-gnu/lib/ -isystem /usr/gcc-4.6.0/x86_64-unknown-linux-gnu/include -isystem /usr/gcc-4.6.0/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/net/gnu-6/export/gnu/import/git/gcc/libgfortran -iquote/net/gnu-6/export/gnu/import/git/gcc/libgfortran/io -I/net/gnu-6/export/gnu/import/git/gcc/libgfortran/../gcc -I/net/gnu-6/export/gnu/import/git/gcc/libgfortran/../gcc/config -I../../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -O2 -g -m32 -MT read.lo -MD -MP -MF .deps/read.Tpo -c /net/gnu-6/export/gnu/import/git/gcc/libgfortran/io/read.c -fPIC -DPIC /net/gnu-6/export/gnu/import/git/gcc/libgfortran/io/read.c: In function max_value: /net/gnu-6/export/gnu/import/git/gcc/libgfortran/io/read.c:114:7: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [...@gnu-32 libgfortran]$ (gdb) p integer_types[itk] $4 = (tree) 0x0 (gdb) p itk $5 = 11 (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44287
[Bug bootstrap/44287] [4.6 Regression] Failed to bootstrap
--- Comment #3 from hjl dot tools at gmail dot com 2010-05-26 19:52 --- (In reply to comment #1) Hmm, is here rtti in use? Could you please test following patch, if it solves your bootstrap issue? Kai Index: gcc/gcc/cp/rtti.c === --- gcc.orig/gcc/cp/rtti.c 2010-05-26 17:54:18.0 +0200 +++ gcc/gcc/cp/rtti.c 2010-05-26 21:46:53.066961700 +0200 @@ -1502,6 +1502,8 @@ emit_support_tinfos (void) tree types[3]; int i; + if (bltn == NULL_TREE) + continue; types[0] = bltn; types[1] = build_pointer_type (bltn); types[2] = build_pointer_type (cp_build_qualified_type (bltn, I don't think so since it also failed in ibgfortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44287
[Bug bootstrap/44287] [4.6 Regression] Failed to bootstrap
--- Comment #4 from ktietz at gcc dot gnu dot org 2010-05-26 20:00 ---
(In reply to comment #3)
(In reply to comment #1)
Hmm, is here rtti in use? Could you please test following patch, if it
solves
your bootstrap issue?
Kai
Index: gcc/gcc/cp/rtti.c
===
--- gcc.orig/gcc/cp/rtti.c 2010-05-26 17:54:18.0 +0200
+++ gcc/gcc/cp/rtti.c 2010-05-26 21:46:53.066961700 +0200
@@ -1502,6 +1502,8 @@ emit_support_tinfos (void)
tree types[3];
int i;
+ if (bltn == NULL_TREE)
+ continue;
types[0] = bltn;
types[1] = build_pointer_type (bltn);
types[2] = build_pointer_type (cp_build_qualified_type (bltn,
I don't think so since it also failed in ibgfortran.
hmm, this should be the real reason here.
Index: gcc/gcc/c-lex.c
===
--- gcc.orig/gcc/c-lex.c2010-05-21 20:16:07.0 +0200
+++ gcc/gcc/c-lex.c 2010-05-26 21:58:52.839130300 +0200
@@ -480,7 +480,11 @@ narrowest_unsigned_type (unsigned HOST_W
for (; itk itk_none; itk += 2 /* skip unsigned types */)
{
- tree upper = TYPE_MAX_VALUE (integer_types[itk]);
+ tree upper;
+
+ if (integer_types[itk] == NULL_TREE)
+ continue;
+ upper = TYPE_MAX_VALUE (integer_types[itk]);
if ((unsigned HOST_WIDE_INT) TREE_INT_CST_HIGH (upper) high
|| ((unsigned HOST_WIDE_INT) TREE_INT_CST_HIGH (upper) == high
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44287
[Bug bootstrap/44287] [4.6 Regression] Failed to bootstrap
--- Comment #5 from dominiq at lps dot ens dot fr 2010-05-26 20:03 --- I confirm comment #2 on x86_64-apple-darwin10.3.0. The ICE occurs only with -m32 (no need for -O2 -g). The backtrace is: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x 0x000147e3 in c_lex_with_flags (value=0x141e033f0, loc=0x141e033ec, cpp_flags=0x0, lex_flags=0) at ../../work/gcc/c-lex.c:511 511 tree upper = TYPE_MAX_VALUE (integer_types[itk]); (gdb) bt #0 0x000147e3 in c_lex_with_flags (value=0x141e033f0, loc=0x141e033ec, cpp_flags=0x0, lex_flags=0) at ../../work/gcc/c-lex.c:511 #1 0x00010007f60d in c_lex_one_token (parser=0x141e033e8, token=0x141e033e8) at ../../work/gcc/c-parser.c:205 #2 0x000100087fe3 in c_parser_conditional_expression (parser=0x141e033e8, after=value temporarily unavailable, due to optimizations) at ../../work/gcc/c-parser.c:321 #3 0x00010008829a in c_parser_expr_no_commas (parser=value temporarily unavailable, due to optimizations, after=value temporarily unavailable, due to optimizations) at ../../work/gcc/c-parser.c:4722 #4 0x000100088417 in c_parser_expr_no_commas (parser=value temporarily unavailable, due to optimizations, after=value temporarily unavailable, due to optimizations) at ../../work/gcc/c-parser.c:4764 #5 0x000100088826 in c_parser_expression (parser=0x141e033e8) at ../../work/gcc/c-parser.c:6166 #6 0x000100088d71 in c_parser_expression_conv (parser=0x141e033e8) at ../../work/gcc/c-parser.c:6197 #7 0x000100080bfe in c_parser_statement_after_labels (parser=0x141e033e8) at ../../work/gcc/c-parser.c:4050 #8 0x00010008d4e3 in c_parser_compound_statement_nostart (parser=0x141e033e8) at ../../work/gcc/c-parser.c:3728 #9 0x00010008fcdd in c_parser_compound_statement (parser=0x141e033e8) at ../../work/gcc/c-parser.c:3565 #10 0x000100080f68 in c_parser_statement_after_labels (parser=0x141e033e8) at ../../work/gcc/c-parser.c:3942 #11 0x000100082863 in c_parser_c99_block_statement (parser=0x141e033e8) at ../../work/gcc/c-parser.c:4110 #12 0x000100081454 in c_parser_statement_after_labels (parser=0x141e033e8) at ../../work/gcc/c-parser.c:4243 #13 0x00010008d4e3 in c_parser_compound_statement_nostart (parser=0x141e033e8) at ../../work/gcc/c-parser.c:3728 #14 0x00010008fcdd in c_parser_compound_statement (parser=0x141e033e8) at ../../work/gcc/c-parser.c:3565 #15 0x00010008cc66 in c_parser_declaration_or_fndef (parser=0x141e033e8, fndef_ok=1 '\001', static_assert_ok=value temporarily unavailable, due to optimizations, empty_ok=value temporarily unavailable, due to optimizations, nested=0 '\0', start_attr_ok=0 '\0') at ../../work/gcc/c-parser.c:1376 #16 0x0001000919c4 in c_parse_file () at ../../work/gcc/c-parser.c:1031 #17 0x00010007414c in c_common_parse_file (set_yydebug=value temporarily unavailable, due to optimizations) at ../../work/gcc/c-opts.c:1393 #18 0x000100686193 in toplev_main (argc=23, argv=0x7fff5fbfd660) at ../../work/gcc/toplev.c:1050 #19 0x000111b4 in start () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44287
[Bug middle-end/44276] [4.6 Regression]: gcc.dg/tls/alias-1.c
--- Comment #6 from iains at gcc dot gnu dot org 2010-05-26 20:26 --- Created an attachment (id=20755) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20755action=view) fix up alias output this fixes it so that we don't try to emit emutls control vars if they are aliases. The reference will still be emitted when the original var alias is processed. This gives no fails on cris-elf (simulator, no pthreads) .. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44276
[Bug bootstrap/44287] [4.6 Regression] Failed to bootstrap
--- Comment #6 from hjl dot tools at gmail dot com 2010-05-26 20:36 ---
A simple testcase:
[...@gnu-32 gcc]$ cat /tmp/x.c
unsigned long long
foo (int signed_flag)
{
unsigned long long value;
value = signed_flag ? 0x7fff : 0x;
return value;
}
[...@gnu-32 gcc]$ ./xgcc -B./ -m32 -S /tmp/x.c
/tmp/x.c: In function foo:
/tmp/x.c:5:3: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[...@gnu-32 gcc]$
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-05-26 20:36:19
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44287
[Bug bootstrap/44287] [4.6 Regression] Failed to bootstrap
--- Comment #7 from ktietz at gcc dot gnu dot org 2010-05-26 20:45 --- Created an attachment (id=20756) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20756action=view) integer_array can hold now NULL_TREEs for unsupported integer-scalar types integer_array can hold now NULL_TREEs for unsupported integer-scalar types (like __int128). As these new types aren't present for 32-bit hosts (without hardware bit wide interger = 64, this issue occures. This patch addresses those issues. PR/44287 * cp/rtti.c (emit_support_tinfos): Check for NULL_TREE. * cp/class.c (layout_class_type): Likewise. * cp/decl.c (finish_enum): Likewise. * cp/mangle.c (write_builitin_type): Likewise. * c-lex.c (narrowest_unsigned_type): Likewise. Patch already sent to ML. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44287
[Bug target/43892] PowerPC suboptimal add with carry optimization
--- Comment #15 from joakim dot tjernlund at transmode dot se 2010-05-26 20:47 --- (In reply to comment #14) (In reply to comment #13) Please see -mcpu= . Almost forgot, but how do I specify that at gcc build/configure ? You can configure with --with-cpu= to set a default for -mcpu= . Thanks. Also, I haven't seen any progress on this issue You have no patience, now do you? Sure I do. It is just that its been almost a month and from the description it sounded like an easy fix: config/rs6000/rs6000.md would need to add a addmodecc expander even though it sounded that the initial fix was easy(addmodecc expander) The fix will be a few thousand lines of patch. Literally. Oops, just to add a cc expander? In order to fix this problem (and a whole host of way more important missed optimisation opportunities) we need to expose the CA bit to the compiler as an actual register. Currently, whenever GCC uses the carry bit it does so by having the consumer and producer in a canned asm sequence; this is suboptimal for many reasons. This looks like you are aiming for the ultimate impl. so you can address other cases too. I can understand that takes some time :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
[Bug bootstrap/44287] [4.6 Regression] Failed to bootstrap
--- Comment #8 from ktietz at gcc dot gnu dot org 2010-05-26 20:49 --- (In reply to comment #7) Instead of integer_array of course integer_types I meant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44287
[Bug bootstrap/44287] [4.6 Regression] Failed to bootstrap
--- Comment #9 from ktietz at gcc dot gnu dot org 2010-05-26 21:09 --- Created an attachment (id=20757) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20757action=view) Updated patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44287
[Bug c/43637] [4.4/4.5 regression] miscompilation in strict-aliasing optimization
--- Comment #3 from jengelh at medozas dot de 2010-05-26 21:44 ---
You are accessing {lh,clh}.{next,prev} through a pointer to type struct item.
Thank you for your time.
I do have a few questions. I wonder where exactly I am doing that access. In
the first part of the for clause,
(pos) = list_entry((head)-next, typeof(*(pos)), member);
head-next is valid, so only pos is punned. The second part is
(pos)-member != (void *)(head);
This I can imagine blowing up; as pos will point to a non-existing memory block
once the end of the list is reached. I thus replace that by the reverse of
containerof to avoid dereferencing pos (/or accessing member/next through a
pointer of the wrong type), IOW
#define s_member(var, type, member) \
((type *)((char *)var + offsetof(typeof(*var), member)))
s_member(pos, struct list_head, member) != (void *)(head)
On an empty list, the condition is not met, so the for loop stops and the third
part of the for() is not evaluated. On a non-empty list, pos points to a valid
memory region as long as it loops, so that the pos-member.next in 3rd part,
(pos) = list_entry((pos)-member.next, typeof(*(pos)), member))
should be valid. Please correct me if I am wrong.
Though I also have to employ s_member in the third case
(pos) = list_entry(s_member((pos), struct list_head, member)-next,
typeof(*(pos)), member))
to get rid of any visible artifacts (such as segfaults), but I suspect the
underlying problem isn't eliminated.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43637
[Bug libstdc++/44268] abi docs say that hppa-linux defaults to libgcc_s.so.2
--- Comment #3 from redi at gcc dot gnu dot org 2010-05-26 23:19 --- Dave, when did the hppa-linux so version change from 2 to 4? I'd like to document that, rather than just say it's always 1 or 4 -- redi at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44268
[Bug rtl-optimization/44288] New: [Extended inline asm] wrong assembly generation on IA32
The following source code causes a wrong assembly output :
1 main.cpp
# 1 built-in
# 1 command-line
# 1 main.cpp
# 1 far_pointers.h 1
# 13 far_pointers.h
# 1 c:\\mingw\\bin\\../lib/gcc/mingw32/4.5.0/include/stddef.h 1 3 4
# 149 c:\\mingw\\bin\\../lib/gcc/mingw32/4.5.0/include/stddef.h 3 4
typedef int ptrdiff_t;
# 211 c:\\mingw\\bin\\../lib/gcc/mingw32/4.5.0/include/stddef.h 3 4
typedef unsigned int size_t;
# 14 far_pointers.h 2
template class T class far_pointer
{
protected:
unsigned short segmentSelector;
T* offset;
public:
inline far_pointer(unsigned short argSegmentSelector, T* argOffset)
:segmentSelector(argSegmentSelector), offset(argOffset)
{}
template class Tp inline operator far_pointerTp()
{
return far_pointerTp(segmentSelector, (Tp*) offset);
}
inline T* getOffset()
{
return offset;
}
inline unsigned short getSegmentselector()
{
return segmentSelector;
}
inline T operator*(void)
{
T item;
__asm__
(
.intel_syntax noprefix; \n mov gs,
%1; \n mov %0, gs:[%2];\n
:=q(item)
:r(this-segmentSelector), g(this-offset)
);
return item;
}
inline far_pointerT operator++(void)
{
offset++;
return *this;
}
inline far_pointerT operator--(void)
{
offset--;
return *this;
}
inline size_t operator-(far_pointerT const subs)
{
return offset-subs.offset;
}
inline far_pointer operator+(int argDecal)
{
return far_pointer(segmentSelector, offset + argDecal);
}
inline far_pointer operator-(int argDecal)
{
return far_pointer(segmentSelector, offset - argDecal);
}
inline far_pointer operator+(unsigned argDecal)
{
return far_pointer(segmentSelector, offset + argDecal);
}
inline far_pointer operator-(unsigned argDecal)
{
return far_pointer(segmentSelector, offset - argDecal);
}
inline void operator+=(unsigned argDecal)
{
offset += argDecal;
}
inline void operator-=(unsigned argDecal)
{
offset -= argDecal;
}
inline void operator+=(int argDecal)
{
offset += argDecal;
}
inline void operator-=(int argDecal)
{
offset -= argDecal;
}
inline far_pointer operator+(long argDecal)
{
return far_pointer(segmentSelector, offset + argDecal);
}
inline far_pointer operator-(long argDecal)
{
return far_pointer(segmentSelector, offset - argDecal);
}
inline far_pointer operator+(unsigned long argDecal)
{
return far_pointer(segmentSelector, offset + argDecal);
}
inline far_pointer operator-(unsigned long argDecal)
{
return far_pointer(segmentSelector, offset - argDecal);
}
inline void operator+=(unsigned long argDecal)
{
offset += argDecal;
}
inline void operator-=(unsigned long argDecal)
{
offset -= argDecal;
}
inline void operator+=(long argDecal)
{
offset += argDecal;
}
inline void operator-=(long argDecal)
{
offset -= argDecal;
}
inline bool operator(far_pointerT const ptr)
{
return offset ptr.offset;
}
inline bool operator(far_pointerT const ptr)
{
return offset ptr.offset;
}
inline bool operator=(far_pointerT const ptr)
{
return offset = ptr.offset;
}
inline bool operator=(far_pointerT const ptr)
{
return offset = ptr.offset;
}
inline bool operator!=(far_pointerT const ptr)
{
return offset != ptr.offset || segmentSelector != ptr.segmentSelector;
}
inline bool operator==(far_pointerT const ptr)
{
return offset == ptr.offset segmentSelector == ptr.segmentSelector;
}
static const far_pointerT NULL_FAR_POINTER;
};
template class T const far_pointerT far_pointerT::NULL_FAR_POINTER(0,(T*)
0);
# 2 main.cpp 2
char u;
void toto(far_pointerunsigned char pt)
{
u = *pt;
}
int main(int argc, char **argv)
{
unsigned short dataSeg = 0;
asm (
.intel_syntax
noprefix; \n mov %0, cs; \n
: =r(dataSeg)
);
far_pointerunsigned char pt(dataSeg, (unsigned char*) main);
toto(pt);
}
COLLECT_GCC_OPTIONS='-c' '-masm=intel' '-save-temps' '-v' '-O1' '-o'
'./Release/main.o' '-I.' '-shared-libgcc' '-mtune=i386' '-march=i386'
c:/mingw/bin/../libexec/gcc/mingw32/4.5.0/cc1plus.exe -fpreprocessed main.ii
-quiet -dumpbase main.cpp -masm=intel -mtune=i386 -march=i386 -auxbase-strip
./Release/main.o -O1 -version -o main.s
GNU C++ (GCC) version 4.5.0 (mingw32)
compiled by GNU C version 4.5.0, GMP version 5.0.1, MPFR version 2.4.1,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.5.0 (mingw32)
compiled by GNU C version 4.5.0, GMP version 5.0.1, MPFR version 2.4.1,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 639ec8dd7c9bc03705b4424f5e166212
COLLECT_GCC_OPTIONS='-c' '-masm=intel'
[Bug middle-end/44289] New: [4.6 Regression]: cris-elf doesn't build libgcc (config/fp-bit.c alias dp-bit.c) after r159873
With revision 159873 cris-elf built a combined tree (with results at regress-9). From revision 159896 and on, the tree is broken as follows: /tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/xgcc -B/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/ -nostdinc -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/newlib/ -isystem /tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/newlib/targ-include -isystem /tmp/hpautotest-gcc1/gcc/newlib/libc/include -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libgloss/cris -L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libgloss/libnosys -L/tmp/hpautotest-gcc1/gcc/libgloss/cris -B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/bin/ -B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/lib/ -isystem /tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/include -isystem /tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/sys-include-g -O2 -march=v10 -mbest-lib-options -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../.././gcc -I/tmp/hpautotest-gcc1/gcc/libgcc -I/tmp/hpautotest-gcc1/gcc/libgcc/. -I/tmp/hpautotest-gcc1/gcc/libgcc/../gcc -I/tmp/hpautotest-gcc1/gcc/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _mul_df.o -MT _mul_df.o -MD -MP -MF _mul_df.dep -DFINE_GRAINED_LIBRARIES -DL_mul_df -c ../../.././gcc/dp-bit.c ../../.././gcc/dp-bit.c: In function '_fpmul_parts': ../../.././gcc/dp-bit.c:898:4: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[4]: *** [_mul_df.o] Error 1 make[4]: Leaving directory `/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/v10/libgcc' A backtrace in gdb at the SEGV doesn't reveal a smoking gun: (gdb) bt #0 0x0040537f in narrowest_signed_type (value=0x77f846e8, loc=value optimized out, cpp_flags=0x0, lex_flags=value optimized out) at /tmp/hpautotest-gcc1/gcc/gcc/c-lex.c:511 #1 interpret_integer (value=0x77f846e8, loc=value optimized out, cpp_flags=0x0, lex_flags=value optimized out) at /tmp/hpautotest-gcc1/gcc/gcc/c-lex.c:545 #2 c_lex_with_flags (value=0x77f846e8, loc=value optimized out, cpp_flags=0x0, lex_flags=value optimized out) at /tmp/hpautotest-gcc1/gcc/gcc/c-lex.c:333 #3 0x00476739 in c_lex_one_token (parser=0x77f846e0, token=0x77f846e0) at /tmp/hpautotest-gcc1/gcc/gcc/c-parser.c:205 #4 0x0047ca7c in c_parser_peek_token (parser=value optimized out, after=value optimized out) at /tmp/hpautotest-gcc1/gcc/gcc/c-parser.c:321 #5 c_parser_expr_no_commas (parser=value optimized out, after=value optimized out) at /tmp/hpautotest-gcc1/gcc/gcc/c-parser.c:4763 #6 0x0047ce75 in c_parser_expression (parser=0x77f846e0) at /tmp/hpautotest-gcc1/gcc/gcc/c-parser.c:6166 #7 0x0047d33d in c_parser_expression_conv (parser=0x77f846e0) at /tmp/hpautotest-gcc1/gcc/gcc/c-parser.c:6197 #8 0x004812ab in c_parser_statement_after_labels (parser=0x77f846e0) at /tmp/hpautotest-gcc1/gcc/gcc/c-parser.c:4050 #9 0x00482164 in c_parser_compound_statement_nostart (parser=0x77f846e0) at /tmp/hpautotest-gcc1/gcc/gcc/c-parser.c:3728 #10 0x00482789 in c_parser_compound_statement (parser=0x77f846e0) at /tmp/hpautotest-gcc1/gcc/gcc/c-parser.c:3565 #11 0x004836e7 in c_parser_if_body (parser=0x77f846e0) at /tmp/hpautotest-gcc1/gcc/gcc/c-parser.c:4143 #12 c_parser_if_statement (parser=0x77f846e0) at /tmp/hpautotest-gcc1/gcc/gcc/c-parser.c:4201 #13 0x0048187b in c_parser_statement_after_labels (parser=0x77f846e0) at /tmp/hpautotest-gcc1/gcc/gcc/c-parser.c:3948 #14 0x00482164 in c_parser_compound_statement_nostart (parser=0x77f846e0) at /tmp/hpautotest-gcc1/gcc/gcc/c-parser.c:3728 #15 0x00482789 in c_parser_compound_statement (parser=0x77f846e0) at /tmp/hpautotest-gcc1/gcc/gcc/c-parser.c:3565 #16 0x004813c0 in c_parser_statement_after_labels (parser=0x77f846e0) at /tmp/hpautotest-gcc1/gcc/gcc/c-parser.c:3942 #17 0x00483838 in c_parser_c99_block_statement (parser=0x77f846e0) at /tmp/hpautotest-gcc1/gcc/gcc/c-parser.c:4110 #18 0x004818fc in c_parser_while_statement (parser=0x77f846e0) at /tmp/hpautotest-gcc1/gcc/gcc/c-parser.c:4276 #19 c_parser_statement_after_labels (parser=0x77f846e0) at /tmp/hpautotest-gcc1/gcc/gcc/c-parser.c:3954 #20 0x00482164 in c_parser_compound_statement_nostart (parser=0x77f846e0) at /tmp/hpautotest-gcc1/gcc/gcc/c-parser.c:3728 #21 0x00482789 in c_parser_compound_statement (parser=0x77f846e0) at /tmp/hpautotest-gcc1/gcc/gcc/c-parser.c:3565 #22 0x00482dce in c_parser_declaration_or_fndef (parser=0x77f846e0, fndef_ok=value optimized out, static_assert_ok=value optimized out,
[Bug middle-end/44289] [4.6 Regression]: cris-elf doesn't build libgcc (config/fp-bit.c alias dp-bit.c) after r159873
-- hp at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-26 23:39:23 date|| Version|4.4.0 |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44289
[Bug rtl-optimization/44288] [Extended inline asm] wrong assembly generation on IA32
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-26 23:50 --- I think your inline-asm is totally broken, the constraints you have don't mean the extended (32bit) registers. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44288
[Bug middle-end/44289] [4.6 Regression]: cris-elf doesn't build libgcc (config/fp-bit.c alias dp-bit.c) after r159873
--- Comment #1 from hp at gcc dot gnu dot org 2010-05-26 23:53 --- *** This bug has been marked as a duplicate of 44287 *** -- hp at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44289
[Bug bootstrap/44287] [4.6 Regression] Failed to bootstrap
--- Comment #10 from hp at gcc dot gnu dot org 2010-05-26 23:53 --- *** Bug 44289 has been marked as a duplicate of this bug. *** -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||hp at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44287
[Bug middle-end/44276] [4.6 Regression]: gcc.dg/tls/alias-1.c
--- Comment #7 from hp at gcc dot gnu dot org 2010-05-27 00:12 --- (In reply to comment #2) Sorry I wasn't here to answer the basic simulator-target questions, but it seems you found the information needed to get you going. 1/ Did the same commit improve PR44137 on your target? No. 2/ Are you able to try the proposed proper solution to that bug (see comment #24 of PR44132) ? I'll try when the tree builds again (PR44287) if you need it; from your later questions it seems you've verified this yourself. Thanks for looking into this! -- hp at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-27 00:12:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44276
[Bug middle-end/44276] [4.6 Regression]: gcc.dg/tls/alias-1.c
--- Comment #8 from iains at gcc dot gnu dot org 2010-05-27 00:49 --- (In reply to comment #7) (In reply to comment #2) Sorry I wasn't here to answer the basic simulator-target questions, but it seems you found the information needed to get you going. Yes, the wiki page is good and it all went pretty easily. One thing you could help with is whether there's a way of enabling threads on the simulator - and what I need to get to do it.. googling cris pthreads wasn't illuminating.. I want to keep this target around to test things that I can't do on darwin. 1/ Did the same commit improve PR44137 on your target? No. I see pretty much clean* output from check-gcc tls.exp=* * when clean=only fails I expect for non-tls reasons. 2/ Are you able to try the proposed proper solution to that bug (see comment #24 of PR44132) ? I'll try when the tree builds again (PR44287) if you need it; from your later questions it seems you've verified this yourself. Hang fire on that - I've just re-made the proper solution to deal with the aliasing - but I need to re-reg-test on non-alias targets before posting; if you're interested in trying it, watch PR44132 (but I will use cris-elf as a test platform anyway). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44276
[Bug middle-end/44276] [4.6 Regression]: gcc.dg/tls/alias-1.c
--- Comment #9 from hp at gcc dot gnu dot org 2010-05-27 01:15 --- (In reply to comment #8) One thing you could help with is whether there's a way of enabling threads on the simulator You mean for cris-axis-elf; no, there is no support for threads on cris-axis-elf. (I could reply yes to your original question, however, but that's irrelevant; the simulator supports cris-axis-linux-gnu too, but you don't want to build for that target, it's a slightly more complicated. :) Let's hope your patch gets reviewed post haste. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44276
[Bug target/44129] Building linux kernel with gcc-4.5.0 and CONFIG_CC_OPTIMIZE_FOR_SIZE segfaults
--- Comment #12 from hpa at zytor dot com 2010-05-27 01:23 --- I'm assuming this is current Linus git (post 2.6.34). For the current merge window we merged a single instance of using the new asm goto feature when compiling on gcc 4.5+; this is in fact exactly in the TSC code, in the form of the new construct static_cpu_has() defined in arch/x86/include/asm/cpufeature.h. It's somewhat curious what is happening with the -Os build there. All the relevant subfunctions are annotated must_inline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44129
[Bug target/43892] PowerPC suboptimal add with carry optimization
--- Comment #16 from dje at gcc dot gnu dot org 2010-05-27 01:37 --- You have no patience, now do you? Sure I do. It is just that its been almost a month and from the description it sounded like an easy fix: config/rs6000/rs6000.md would need to add a addmodecc expander No you do not have any patience; in fact, your comments are rather obnoxious, such as: its been almost a month. If you do not know what you are talking about, stop talking. No, it is not an easy fix. The high-level concept and description is simple, the implementation is extremely complex and tedious. even though it sounded that the initial fix was easy(addmodecc expander) The fix will be a few thousand lines of patch. Literally. Oops, just to add a cc expander? Yes. Again, if you do not know the complexity of what you are requesting, get more information instead of acting annoyed that people are not jumping to solve your problem. It is not just adding a cc expander. Do you even know what that means or what it involves? For the expander to be effective, the PowerPC port of GCC needs to be taught to track the carry bit, which it currently does not. *ALL* patterns that produce instructions affecting the carry bit must be updated. One cannot add the pattern in isolation. If you do not understand the implications of your request, then *ask* why it is more complicated than you assumed. There is no simple fix. The only fix is the ultimate fix: completely propagating the carry bit throughout the PowerPC port. You apparently have not read the documentation to understand the -mcpu= option or the --with-cpu= configure option. You are making a lot of incorrect assumption and assertions, apparently without making any effort to gain some knowledge before you start writing. That really does not encourage anyone to help you, especially when it requires a lot of work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
