[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 --- Comment #6 from Paolo Carlini 2011-03-10 11:30:58 UTC --- Well, on x86, in terms of addressing unsigned int (aka long) *is* the widest type, morally unsigned long long doesn't count.

[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 Paolo Carlini changed: What|Removed |Added CC||paolo.carlini at oracle dot

[Bug testsuite/48055] FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O2 -flto

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48055 --- Comment #3 from Richard Guenther 2011-03-10 11:14:41 UTC --- Are there conflicting definitions somewhere? Then it would indeed be a testsuite bug.

[Bug lto/48056] lto throws out needed symbols when linking QtScript

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48056 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|

[Bug ada/48057] New: Assert_Failure sinfo.adb:1985 when = put instead of :=

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48057 Summary: Assert_Failure sinfo.adb:1985 when = put instead of := Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: ada Assigned

[Bug testsuite/48055] FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O2 -flto

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48055 Uros Bizjak changed: What|Removed |Added Component|lto |testsuite --- Comment #2 from Uros Bizjak

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48031 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 --- Comment #4 from vincenzo Innocente 2011-03-10 10:54:07 UTC --- Thanks for the fast reation. I would like to point out that, at least on x86_64, the only one that does not work is "unsigned int" "unsigned long long (aka size_t)" seems to wor

[Bug lto/48056] lto throws out needed symbols when linking QtScript

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48056 --- Comment #1 from Andrew Pinski 2011-03-10 10:23:21 UTC --- I think you need to use the attribute used on cti_vm_throw when using LTO as the symbol usage is hidden from the compiler.

[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 --- Comment #3 from Paolo Carlini 2011-03-10 10:22:48 UTC --- Thanks for the analysis. I knew about the difference between signed and unsigned, makes sense. Not knowing in detail the internals of the optimization the puzzling bit is that types wi

[Bug lto/48056] New: lto throws out needed symbols when linking QtScript

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48056 Summary: lto throws out needed symbols when linking QtScript Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo:

[Bug lto/48055] FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O2 -flto

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48055 --- Comment #1 from Richard Guenther 2011-03-10 10:18:52 UTC --- This looks like a linker issue. I remember seeing similar errors when using GNU ld and not gold. And I don't think GCC produces intermediate files named ccc3QsSw.o.ironly.

[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug libfortran/48047] Incorrect output rounding of double precision numbers

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48047 Thomas Henlich changed: What|Removed |Added Attachment #23611|0 |1 is obsolete|

[Bug libfortran/48047] Incorrect output rounding of double precision numbers

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48047 --- Comment #5 from Thomas Henlich 2011-03-10 09:39:03 UTC --- Created attachment 23611 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23611 Comprehensive test for IEEE 754-2008 clause 5.12.2 compliant output rounding

[Bug libfortran/48047] Incorrect output rounding of double precision numbers

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48047 --- Comment #4 from Thomas Henlich 2011-03-10 09:36:52 UTC --- Created attachment 23610 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23610 Patch to fix rounding issue Proposing this patch (untested) for field width. Trading 2 extra bytes

[Bug middle-end/48044] [4.6 Regression] ICE in function_and_variable_visibility, at ipa.c:875

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48044 --- Comment #3 from Jakub Jelinek 2011-03-10 09:36:12 UTC --- c's vnode is first varpool_mark_needed_node, then it is again marked as not needed by cgraph_remove_unreachable_nodes (so far both for -O0 and -O1+) and as nothing like finish_aliases_

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48031 --- Comment #6 from rguenther at suse dot de 2011-03-10 09:33:49 UTC --- On Thu, 10 Mar 2011, mikpe at it dot uu.se wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48031 > > --- Comment #5 from Mikael Pettersson 2011-03-10 > 09:22:04 UTC

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48031 --- Comment #5 from Mikael Pettersson 2011-03-10 09:22:04 UTC --- If I revert this part of r139061 then things work again: * gimplify.c (gimplify_conversion): Use maybe_fold_offset_to_address. --- gcc/gimplify.c (revision 139060) +++ g

[Bug middle-end/48044] [4.6 Regression] ICE in function_and_variable_visibility, at ipa.c:875

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48044 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 f

<    1   2