[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 jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-10 09:02:51 UTC --- Shorter testcase: int a __asm__ (b) = 0; extern int c __asm__ (a) __attribute__ ((alias (b))); extern int d __attribute__ ((weak, alias (a)));
[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 mikpe at it dot uu.se 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)
+++ gcc/gimplify.c (revision 139061)
@@ -1842,17 +1842,13 @@ gimplify_conversion (tree *expr_p)
/* Attempt to avoid NOP_EXPR by producing reference to a subtype.
For example this fold (subclass *)A into A-subclass avoiding
a need for statement. */
- if (TREE_CODE (*expr_p) == NOP_EXPR
+ if (CONVERT_EXPR_P (*expr_p)
POINTER_TYPE_P (TREE_TYPE (*expr_p))
POINTER_TYPE_P (TREE_TYPE (TREE_OPERAND (*expr_p, 0)))
- (tem = maybe_fold_offset_to_reference
+ (tem = maybe_fold_offset_to_address
(TREE_OPERAND (*expr_p, 0),
- integer_zero_node, TREE_TYPE (TREE_TYPE (*expr_p)
-{
- tree ptr_type = build_pointer_type (TREE_TYPE (tem));
- if (useless_type_conversion_p (TREE_TYPE (*expr_p), ptr_type))
-*expr_p = build_fold_addr_expr_with_type (tem, ptr_type);
-}
+ integer_zero_node, TREE_TYPE (*expr_p))) != NULL_TREE)
+*expr_p = tem;
/* If we still have a conversion at the toplevel,
then canonicalize some constructs. */
The first condition change is Ok, it's the change to call m_f_o_t_address
instead of m_f_o_t_reference and the then-clause change that matter.
Reverting this from trunk @ r139061 + r151559 backport, or trunk @ r151559,
eliminates the ICE.
[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 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 mikpe at it dot uu.se 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)
+++ gcc/gimplify.c (revision 139061)
@@ -1842,17 +1842,13 @@ gimplify_conversion (tree *expr_p)
/* Attempt to avoid NOP_EXPR by producing reference to a subtype.
For example this fold (subclass *)A into A-subclass avoiding
a need for statement. */
- if (TREE_CODE (*expr_p) == NOP_EXPR
+ if (CONVERT_EXPR_P (*expr_p)
POINTER_TYPE_P (TREE_TYPE (*expr_p))
POINTER_TYPE_P (TREE_TYPE (TREE_OPERAND (*expr_p, 0)))
- (tem = maybe_fold_offset_to_reference
+ (tem = maybe_fold_offset_to_address
(TREE_OPERAND (*expr_p, 0),
- integer_zero_node, TREE_TYPE (TREE_TYPE (*expr_p)
-{
- tree ptr_type = build_pointer_type (TREE_TYPE (tem));
- if (useless_type_conversion_p (TREE_TYPE (*expr_p), ptr_type))
-*expr_p = build_fold_addr_expr_with_type (tem, ptr_type);
-}
+ integer_zero_node, TREE_TYPE (*expr_p))) != NULL_TREE)
+*expr_p = tem;
/* If we still have a conversion at the toplevel,
then canonicalize some constructs. */
The first condition change is Ok, it's the change to call m_f_o_t_address
instead of m_f_o_t_reference and the then-clause change that matter.
Reverting this from trunk @ r139061 + r151559 backport, or trunk @ r151559,
eliminates the ICE.
I think this is all just the right circumstances for triggering the bug.
[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 jakub at gcc dot gnu.org 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_1 is run afterwards again, the vnode is !vnode-needed vnode-force_output. In -O1 case the varpool node is removed altogether as not needed (which is strange, the vnode's decl is going to be emitted anyway), but for -O0: /* We must release unused extern inlines or sanity checking will fail. Rest of transformations are undesirable at -O0 since we do not want to remove anything. */ if (!optimize) return changed; if (file) fprintf (file, Reclaiming variables:); the reclaiming isn't done, so the vnode remains !vnode-needed and we ICE on it later on. I wonder if cgraph_remove_unreachable_nodes shouldn't be somehow alias pairs aware (can it e.g. call find_aliases_1 again?), or at least for !optimize shouldn't it avoid clearing vnode-needed for vnode-force_output?
[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 thenlich at users dot sourceforge.net 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 for (partial) IEEE 754-2008 compliance seems like a good thing. It facilitates writing programs portable to other (IEEE 754-2008 compliant) compilers.
[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 thenlich at users dot sourceforge.net 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 Thomas Henlich thenlich at users dot sourceforge.net changed: What|Removed |Added Attachment #23611|0 |1 is obsolete|| --- Comment #6 from Thomas Henlich thenlich at users dot sourceforge.net 2011-03-10 09:41:40 UTC --- Created attachment 23612 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23612 Comprehensive test for IEEE 754-2008 clause 5.12.2 compliant output rounding (corrected)
[Bug tree-optimization/48052] loop not vectorized if index is unsigned int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.03.10 09:46:16
CC||spop at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-10
09:46:17 UTC ---
This is a known issue with POINTER_PLUS_EXPR semantics, how the C frontend
handles pointer-based array accesses and fold. And in the end SCEV analysis.
The issue is we end up with
*(c + (((long unsigned int)i) * 8))
with that 'long unsigned int' being sizetype. At the point of SCEV
analysis we do not factor in the fact that i does not wrap around and
that because of this the evolution is
{ c, +, 8 }
With signed integers we simply exploit undefined behavior.
So yes, it's a known problem (but I always fail to remember a testcase
where it matters ;)).
In the very end my plan was to fix this all with no-undefined-overflow
branch, but maybe Sebastian can think of a way to use number-of-iteration
analysis in SCEV? (Ugh, that's a chicken-and-egg problem, no?)
[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 rguenth at gcc dot gnu.org 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 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: unassig...@gcc.gnu.org
ReportedBy: b...@arklinux.org
Trying to build Qt with -flto (after working around bug 48042) results in
$ g++ [...] -flto=8 [...] -shared -Wl,-Bsymbolic-functions
-Wl,-soname,libQtScript.so.4 -o libQtScript.so.4.7.2 obj/release/pcre_compile.o
[...] obj/release/JITStubs.o [...]
/tmp/ccKsaUWN.ltrans0.ltrans.o: In function `ctiVMThrowTrampoline':
ccKsaUWN.ltrans0.o:(.text+0x4c): undefined reference to `cti_vm_throw'
cti_vm_throw is defined in JITStubs.cpp and exists in obj/release/JITStubs.o
(as passed to the compiler).
$ nm obj/release/JITStubs.o |grep cti_vm_throw
6ad0 T cti_vm_throw
$ objdump -s obj/release/JITStubs.o
[...]
Contents of section .gnu.lto_cti_vm_throw.1ff1d9c6:
789c9d57 7b705457 19ffbe73 f7ee23bb x..W{pTW...s..#.
[...]
This is probably caused by the fact that ctiVMThrowTrampoline (the user of
cti_vm_throw) uses cti_vm_throw through an asm statement:
#define HIDE_SYMBOL(name) .hidden #name
#define SYMBOL_STRING(name) #name
#define SYMBOL_STRING_RELOCATION(name) #name @plt
asm volatile (
.globl SYMBOL_STRING(ctiVMThrowTrampoline) \n
HIDE_SYMBOL(ctiVMThrowTrampoline) \n
SYMBOL_STRING(ctiVMThrowTrampoline) : \n
movq %rsp, %rdi \n
call SYMBOL_STRING_RELOCATION(cti_vm_throw) \n
addq $0x48, %rsp \n
popq %rbx \n
popq %r15 \n
popq %r14 \n
popq %r13 \n
popq %r12 \n
popq %rbp \n
ret \n
);
[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 paolo.carlini at oracle dot com 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 wider than unsigned int already work fine. The problem seems fixable, somehow ;)
[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 pinskia at gcc dot gnu.org 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 #4 from vincenzo Innocente vincenzo.innocente at cern dot ch 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 work (see 3,4 and 5th loop in my example) vincenzo On 10 Mar, 2011, at 11:23 AM, paolo.carlini at oracle dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 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 wider than unsigned int already work fine. The problem seems fixable, somehow ;) -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug. -- Il est bon de suivre sa pente, pourvu que ce soit en montant. A.G. http://www.flickr.com/photos/vin60/1320965757/
[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 rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011.03.10 11:02:33
CC||ebotcazou at gcc dot
||gnu.org
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-10
11:02:33 UTC ---
First of all, confirmed with a cross.
The issue seems to be with variable-length arrays:
D.2079_96 = D.2025 /[ex] 2;
D.2080_21 = (*D.2050_128)[0]{lb: 0 sz: D.2079_96 * 2}.err;
What happens is that we have an induction variable base of the form
(unsigned int) ((struct Result *) D.2050_128)-err and end up folding
the conversion to an array reference during gimplifying it here
/* *(foo *)fooarrptr = (*fooarrptr)[0] */
if (TREE_CODE (TREE_TYPE (subtype)) == ARRAY_TYPE
type == TREE_TYPE (TREE_TYPE (subtype)))
{
tree type_domain;
tree min_val = size_zero_node;
sub = build_fold_indirect_ref_loc (loc, sub);
type_domain = TYPE_DOMAIN (TREE_TYPE (sub));
if (type_domain TYPE_MIN_VALUE (type_domain))
min_val = TYPE_MIN_VALUE (type_domain);
return build4_loc (loc, ARRAY_REF, type, sub, min_val, NULL_TREE,
NULL_TREE);
}
and then add a lower bound and step element in gimplify_compound_lval:
if (!TREE_OPERAND (t, 3))
{
tree elmt_type = TREE_TYPE (TREE_TYPE (TREE_OPERAND (t, 0)));
tree elmt_size = unshare_expr (array_ref_element_size (t));
tree factor = size_int (TYPE_ALIGN_UNIT (elmt_type));
/* Divide the element size by the alignment of the element
type (above). */
elmt_size = size_binop_loc (loc, EXACT_DIV_EXPR, elmt_size,
factor);
if (!is_gimple_min_invariant (elmt_size))
{
TREE_OPERAND (t, 3) = elmt_size;
tret = gimplify_expr (TREE_OPERAND (t, 3), pre_p,
post_p, is_gimple_reg,
fb_rvalue);
ret = MIN (ret, tret);
}
}
A fix would be for example avoiding the folding for variable-sized element
types. Another one would be to avoid putting in a operand 3 into the
array-ref when the index is equal to the lower bound (but I'm not sure
if that works, if the index is zero would probably work, but then a
variant of the code might still ICE the same way).
It's mixing VLA unaware foldings into the mids of GIMPLE which is the
root of the issue though. The issue is latent on trunk.
Patch for the first (and safe) idea:
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 170818)
+++ gcc/fold-const.c(working copy)
@@ -15554,7 +15560,8 @@ fold_indirect_ref_1 (location_t loc, tre
}
/* *(foo *)fooarray = fooarray[0] */
else if (TREE_CODE (optype) == ARRAY_TYPE
- type == TREE_TYPE (optype))
+ type == TREE_TYPE (optype)
+ TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST)
{
tree type_domain = TYPE_DOMAIN (optype);
tree min_val = size_zero_node;
@@ -15633,7 +15640,8 @@ fold_indirect_ref_1 (location_t loc, tre
/* *(foo *)fooarrptr = (*fooarrptr)[0] */
if (TREE_CODE (TREE_TYPE (subtype)) == ARRAY_TYPE
- type == TREE_TYPE (TREE_TYPE (subtype)))
+ type == TREE_TYPE (TREE_TYPE (subtype))
+ TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST)
{
tree type_domain;
tree min_val = size_zero_node;
Eric, can you see any issues with that and Ada?
[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 ubizjak at gmail dot com changed: What|Removed |Added Component|lto |testsuite --- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2011-03-10 11:08:00 UTC --- (In reply to comment #1) 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. Indeed. The new warning is generated due to the upgrade to binutils-2.21. Following testsuite patch fixes the problem: Index: gcc.c-torture/execute/builtins/memcpy-chk.c === --- gcc.c-torture/execute/builtins/memcpy-chk.c(revision 170823) +++ gcc.c-torture/execute/builtins/memcpy-chk.c(working copy) @@ -78,10 +78,10 @@ abort (); } -long buf1[64]; +static long buf1[64]; char *buf2 = (char *) (buf1 + 32); -long buf5[20]; -char buf7[20]; +static long buf5[20]; +static char buf7[20]; void __attribute__((noinline)) Index: gcc.c-torture/execute/builtins/memmove-chk.c === --- gcc.c-torture/execute/builtins/memmove-chk.c(revision 170823) +++ gcc.c-torture/execute/builtins/memmove-chk.c(working copy) @@ -81,10 +81,10 @@ abort (); } -long buf1[64]; +static long buf1[64]; char *buf2 = (char *) (buf1 + 32); -long buf5[20]; -char buf7[20]; +static long buf5[20]; +static char buf7[20]; void __attribute__((noinline)) Index: gcc.c-torture/execute/builtins/mempcpy-chk.c === --- gcc.c-torture/execute/builtins/mempcpy-chk.c(revision 170823) +++ gcc.c-torture/execute/builtins/mempcpy-chk.c(working copy) @@ -84,10 +84,10 @@ mempcpy_disallowed = 0; } -long buf1[64]; +static long buf1[64]; char *buf2 = (char *) (buf1 + 32); -long buf5[20]; -char buf7[20]; +static long buf5[20]; +static char buf7[20]; void __attribute__((noinline))
[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
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d33...@gmail.com
Created attachment 23613
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23613
the *.*i file
Well, since the scary box came out, I thought you might want to know I've found
a bug in GNAT. Ali file attached, details follow. More available if needed.
gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
uname -a
Linux deetah-laptop 2.6.32-28-generic #55-Ubuntu SMP Mon Jan 10 21:21:01 UTC
2011 i686 GNU/Linux
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 10.04.2 LTS
Release:10.04
Codename: lucid
CW=zaj1 ; gnatmake ${CW}.adb ./$CW
gcc-4.4 -c zaj1.adb
+===GNAT BUG DETECTED==+
| 4.4.3 (i486-pc-linux-gnu) Assert_Failure sinfo.adb:1985 |
| Error detected at zaj1.adb:68:10 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report. |
| Include the exact gcc-4.4 or gnatmake command that you entered. |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files). |
+==+
Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
zaj1.adb
list may be incomplete
zaj1.adb:68:09: = should be :=
compilation abandoned
gnatmake: zaj1.adb compilation error
[Bug lto/48056] lto throws out needed symbols when linking QtScript
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48056 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-10 11:10:55 UTC --- Yep. Mark it with attribute((used)).
[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 rguenth at gcc dot gnu.org 2011-03-10 11:14:41 UTC --- Are there conflicting definitions somewhere? Then it would indeed be a testsuite bug.
[Bug tree-optimization/48052] loop not vectorized if index is unsigned int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-10 11:22:26 UTC --- Vincenzo, if I understand correctly, maybe Sebastian can also tell us more, the issue seems that, at some stage, the logic is fully general only assuming the widest unsigned type (*), doesn't cope with smaller types. Thus, if my theory is correct, unsigned char, unsigned short, etc, all should cause problems. On the other hand, on x86_64, unsigned long, unsigned long long, size_t, are all the same size, and all work (**) (*) I don't consider int128, I don't think is relevant for loop optimization. (**) On x86, however, unsigned int (aka unsigned long) appears to work, hum.
[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 paolo.carlini at oracle dot com 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 c/43421] strict-aliasing warning from innocent code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43421 Mattias Engdegård mattiase at acm dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #1 from Mattias Engdegård mattiase at acm dot org 2011-03-10 11:41:06 UTC --- Gcc 4.5.2 no longer gives the spurious warning, so apparently this has been fixed. My thanks to whomever did it.
[Bug lto/48056] lto throws out needed symbols when linking QtScript
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48056 --- Comment #3 from bero at arklinux dot org 2011-03-10 11:48:47 UTC --- Thanks, works. Re-filed as WebKit bug https://bugs.webkit.org/show_bug.cgi?id=56088
[Bug target/46788] unsigned int possible treated as signed in a union/struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46788 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.03.10 11:59:32 Target Milestone|--- |4.5.3 Ever Confirmed|0 |1 --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-03-10 11:59:32 UTC --- Confirmed
[Bug target/47779] Problem cross-compiling trunk for bfin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47779 Bernd Schmidt bernds at gcc dot gnu.org changed: What|Removed |Added CC||bernds at gcc dot gnu.org --- Comment #3 from Bernd Schmidt bernds at gcc dot gnu.org 2011-03-10 12:01:57 UTC --- Maybe ucontext.h should only define these context ifdef __USE_GNU? That's what i386 and x86_64 appear to do.
[Bug fortran/48058] New: [4.6 Regression] reallocation of array during constructor assignement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48058 Summary: [4.6 Regression] reallocation of array during constructor assignement Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: xarthisius...@gmail.com Assigning [...] constructor to allocatable array changes size of that array, if size([...]) is not equal to size(array) program ala implicit none integer, dimension(:), allocatable :: ivec allocate(ivec(3)); write(*,*) shape(ivec) ivec = [1,2]; write(*,*) shape(ivec) !! end program ala Target: x86_64-pc-linux-gnu Configured with: /dev/shm/portage/sys-devel/gcc-4.6.0_alpha20110226/work/gcc-4.6-20110226/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.0-alpha20110226 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0-alpha20110226/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0-alpha20110226 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0-alpha20110226/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0-alpha20110226/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0-alpha20110226/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --with-ppl --with-cloog --disable-ppl-version-check --with-cloog-include=/usr/include/cloog-ppl --enable-lto --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-cld --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.0-alpha20110226/python --enable-checking=release --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.6.0_alpha20110226' Thread model: posix gcc version 4.6.0-alpha20110226 20110226 (experimental) (Gentoo 4.6.0_alpha20110226)
[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 #4 from Uros Bizjak ubizjak at gmail dot com 2011-03-10 12:09:50 UTC --- (In reply to comment #3) Are there conflicting definitions somewhere? Then it would indeed be a testsuite bug. No, these are the only definitions for the particular testcase.
[Bug c/43421] strict-aliasing warning from innocent code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43421 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-10 12:34:04 UTC --- The code emitting the warning was removed without replacement. The code isn't dubious but it shows that GCC 4.4 has bugs (but as we warn we also tell you at the same time we won't optimize).
[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 #8 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-03-10
12:34:57 UTC ---
It's mixing VLA unaware foldings into the mids of GIMPLE which is the
root of the issue though. The issue is latent on trunk.
Patch for the first (and safe) idea:
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 170818)
+++ gcc/fold-const.c(working copy)
@@ -15554,7 +15560,8 @@ fold_indirect_ref_1 (location_t loc, tre
}
/* *(foo *)fooarray = fooarray[0] */
else if (TREE_CODE (optype) == ARRAY_TYPE
- type == TREE_TYPE (optype))
+ type == TREE_TYPE (optype)
+ TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST)
{
tree type_domain = TYPE_DOMAIN (optype);
tree min_val = size_zero_node;
@@ -15633,7 +15640,8 @@ fold_indirect_ref_1 (location_t loc, tre
/* *(foo *)fooarrptr = (*fooarrptr)[0] */
if (TREE_CODE (TREE_TYPE (subtype)) == ARRAY_TYPE
- type == TREE_TYPE (TREE_TYPE (subtype)))
+ type == TREE_TYPE (TREE_TYPE (subtype))
+ TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST)
{
tree type_domain;
tree min_val = size_zero_node;
Eric, can you see any issues with that and Ada?
If this is limited to the in_gimple_form case, probably none.
[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 #9 from rguenther at suse dot de rguenther at suse dot de
2011-03-10 12:36:33 UTC ---
On Thu, 10 Mar 2011, ebotcazou at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48031
--- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-03-10
12:34:57 UTC ---
It's mixing VLA unaware foldings into the mids of GIMPLE which is the
root of the issue though. The issue is latent on trunk.
Patch for the first (and safe) idea:
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 170818)
+++ gcc/fold-const.c(working copy)
@@ -15554,7 +15560,8 @@ fold_indirect_ref_1 (location_t loc, tre
}
/* *(foo *)fooarray = fooarray[0] */
else if (TREE_CODE (optype) == ARRAY_TYPE
- type == TREE_TYPE (optype))
+ type == TREE_TYPE (optype)
+ TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST)
{
tree type_domain = TYPE_DOMAIN (optype);
tree min_val = size_zero_node;
@@ -15633,7 +15640,8 @@ fold_indirect_ref_1 (location_t loc, tre
/* *(foo *)fooarrptr = (*fooarrptr)[0] */
if (TREE_CODE (TREE_TYPE (subtype)) == ARRAY_TYPE
- type == TREE_TYPE (TREE_TYPE (subtype)))
+ type == TREE_TYPE (TREE_TYPE (subtype))
+ TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST)
{
tree type_domain;
tree min_val = size_zero_node;
Eric, can you see any issues with that and Ada?
If this is limited to the in_gimple_form case, probably none.
No it isn't. But given that fold at this place doesn't even
fill in the array-ref element-size slot but provides NULL_TREE
it is probably a fix for the better anyway?
Richard.
[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 #10 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-03-10 12:46:33 UTC --- No it isn't. But given that fold at this place doesn't even fill in the array-ref element-size slot but provides NULL_TREE it is probably a fix for the better anyway? Why not explicitly test in_gimple_form like in other places in the folder?
[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 #4 from Jan Hubicka hubicka at ucw dot cz 2011-03-10 12:51:19 UTC --- I wonder if cgraph_remove_unreachable_nodes shouldn't be somehow alias pairs aware (can it e.g. call find_aliases_1 again?), or at least for !optimize shouldn't it avoid clearing vnode-needed for vnode-force_output? I guess the second (probably even when optimizing). The idea of alias pair handling in current cgraph is to pretend they do not exist and have the code in visibility pass marking them force_output and thus disabling much of optimization around them. For 4.7 we need to rewrite this in favour of proper symbol table that is quite some effort to do ;( I will look into this today. Honza
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #59 from Jan Hubicka hubicka at ucw dot cz 2011-03-10 12:53:58 UTC --- How do you do this with make -f client.mk profiledbuild? To answer my own question: Just edit ./configure and ./js/src/configure and add -flto=4 -fwhole-program (or whatever you may prefer) to the PROFILE_USE_CFLAGS variable. Then you can build Firefox with make -f client.mk profiledbuild. I did not know of existence of profiledbuild and thus I did that by hand where it was easy. Perhaps Mozilla build mahcinery can be told to add -fno-lto into -fprofile-generate run. Hmm, in fact perhaps GCC chould do that by default. Not sure if it is not too late for 4.6 however. BTW libmozsqlite3.so still gets miscompiled, but Firefox is now snappy as never before ;-) yes, there is PR on this, but I have absolutely no idea if it is sqlite or GCC bug. Any help is greatly appreciated, sqlite is big blob of magic for me.
Re: [Bug testsuite/48055] FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O2 -flto
No, these are the only definitions for the particular testcase. Hmm, in every case it is GNU ld bug - the GNU ld internal ironly section should not be leaking to user warnings. Please fill in GNU ld PR. Honza
[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 #5 from Jan Hubicka hubicka at ucw dot cz 2011-03-10 12:56:56 UTC --- No, these are the only definitions for the particular testcase. Hmm, in every case it is GNU ld bug - the GNU ld internal ironly section should not be leaking to user warnings. Please fill in GNU ld PR. Honza
[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 #11 from rguenther at suse dot de rguenther at suse dot de 2011-03-10 12:57:59 UTC --- On Thu, 10 Mar 2011, ebotcazou at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48031 --- Comment #10 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-03-10 12:46:33 UTC --- No it isn't. But given that fold at this place doesn't even fill in the array-ref element-size slot but provides NULL_TREE it is probably a fix for the better anyway? Why not explicitly test in_gimple_form like in other places in the folder? That would work, too. You see no problem with a NULL operand 3 of array-refs? If you create an array with a variable lower bound, take its address, convert it to pointer to element type and dereference that, would it expand ok if it does not have the element size set properly? At least get_inner_reference seems to unconditionally multiply with array_ref_element_size () * index, and array_ref_element_size () does not work for variable-size types if the array-ref doesn't have the gimplified value. You can probably come up with an Ada testcase that gets miscompiled? (C arrays always have a lower bound of zero, thus the index will be zero thus the multiplication ensures that the garbage returned by array_ref_element_size is thrown away). Richard.
[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 #12 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-03-10 13:04:17 UTC --- That would work, too. You see no problem with a NULL operand 3 of array-refs? If you create an array with a variable lower bound, take its address, convert it to pointer to element type and dereference that, would it expand ok if it does not have the element size set properly? At least get_inner_reference seems to unconditionally multiply with array_ref_element_size () * index, and array_ref_element_size () does not work for variable-size types if the array-ref doesn't have the gimplified value. Isn't gimplification supposed to populate this operand #3?
[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 #13 from rguenther at suse dot de rguenther at suse dot de 2011-03-10 13:07:16 UTC --- On Thu, 10 Mar 2011, ebotcazou at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48031 --- Comment #12 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-03-10 13:04:17 UTC --- That would work, too. You see no problem with a NULL operand 3 of array-refs? If you create an array with a variable lower bound, take its address, convert it to pointer to element type and dereference that, would it expand ok if it does not have the element size set properly? At least get_inner_reference seems to unconditionally multiply with array_ref_element_size () * index, and array_ref_element_size () does not work for variable-size types if the array-ref doesn't have the gimplified value. Isn't gimplification supposed to populate this operand #3? Ugh, yeah it does - but, do we really rely on this? Probably yes ... so setting operand #2 in the folder is not necessary either. Ok, I'll go with the in_gimple_form check.
[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 #14 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-10 13:10:23 UTC --- Created attachment 23614 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23614 patch testing appreciated
[Bug target/47989] -mrecip causes 482.sphinx3, 464.h264ref and 481.wrf to miscompare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47989 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Summary|-mrecip causes 482.sphinx3 |-mrecip causes 482.sphinx3, |and 464.h264ref to |464.h264ref and 481.wrf to |miscompare |miscompare --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-10 13:27:22 UTC --- Same for 481.wrf, hope for dealing with this with taking into account context of the division vanishes here. The code is obfuscated with several levels of array lookup. In all cases the Intel compiler simply only uses rcp instructions for vectorized loops.
[Bug fortran/48059] New: [OOP] ICE in in gfc_conv_component_ref: character function of extended type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48059 Summary: [OOP] ICE in in gfc_conv_component_ref: character function of extended type Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: boschm...@tp1.physik.uni-siegen.de The code: module a_module type :: a_type integer::length=0 end type a_type type,extends(a_type) :: b_type end type b_type contains function a_string(this) result(form) class(a_type),intent(in)::this character(max(1,this%length))::form end function a_string subroutine b_sub(this) class(b_type),intent(inout),target::this print *,a_string(this) end subroutine b_sub end module a_module The ICE message: a.f90: In Funktion »b_sub«: a.f90:14:0: interner Compiler-Fehler: in gfc_conv_component_ref, bei fortran/trans-expr.c:523 Fortran version: GNU Fortran (GCC) 4.6.0 20110310 (experimental) I know that the length specification in a_string is a little bit creepy, but it is valid. I had a discussion with the NAG about this before and they decided to give a questionable warning message but no error message. It anyway went right until today. I have updated gfortran and got this ICE for the first time although the code is a few months old now. Unfortunately, I'm not totally sure when I have done the last update before.
[Bug fortran/48059] [OOP] ICE in in gfc_conv_component_ref: character function of extended type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48059 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.10 13:54:15 Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-03-10 13:54:15 UTC --- The ICE appeared between revisions 169790 and 170493.
[Bug target/47989] -mrecip causes 482.sphinx3, 464.h264ref and 481.wrf to miscompare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47989 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-03-10 14:01:25 UTC --- A similar problem occurs with the polyhedron test aermod.f90 (see pr34702). Feeding rcps sequences into call stmts is probably never a very good idea. Probably the same thing for tests. In all cases the Intel compiler simply only uses rcp instructions for vectorized loops. I think this would be a good idea, however the last time I have looked at it (some time ago!-), gcc was not as good as intel to vectorize rcp.
[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 #15 from Mikael Pettersson mikpe at it dot uu.se 2011-03-10 14:03:22 UTC --- (In reply to comment #14) Created attachment 23614 [details] patch testing appreciated Thanks, fixes the ICE in 4.5 and 4.4 crosses to m68k-linux. I'm starting native 4.6/4.5/4.4 bootstraps and test suite runs today, expect results in 4-5 days. (I'm running them in parallel on three machines. A languages=c,c++ checking=release bootstrap+regtest does unfortunately take that long.)
[Bug c/48060] New: internal compiler error: in dfs_enumerate_from, at cfganal.c:1209
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48060
Summary: internal compiler error: in dfs_enumerate_from, at
cfganal.c:1209
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: y...@momonga-linux.org
gcc 4.6.0 20110305 ICEs with -O3 when using the following code;
typedef struct {
unsigned long status;
} Table;
extern Table* table;
extern void func2(Table *p);
int func(int a)
{
while (a) {
unsigned long b;
Table *p;
p = table[b];
if (!p || (p-status (b))) {
p = 0;
}
if (p p-status) {
func2(p);
}
}
return 1;
}
[Bug fortran/48059] [OOP] ICE in in gfc_conv_component_ref: character function of extended type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48059 --- Comment #2 from Hans-Werner Boschmann boschmann at tp1 dot physik.uni-siegen.de 2011-03-10 14:06:06 UTC --- I have removed this character function from my project and found the same ICE message with other, non character-valued functions of extended types. So it seems to be a more general problem then character-valued functions.
[Bug fortran/48058] [4.6 Regression] reallocation of array during constructor assignement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48058 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||bur...@net-b.de, pault at ||gcc dot gnu.org --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-03-10 14:07:49 UTC --- Assigning [...] constructor to allocatable array changes size of that array, if size([...]) is not equal to size(array) As far as I understand reallocation on assignment, this is the expected behavior (default that you can override with -fno-realloc-lhs). There may be a missing error in [macbook] f90/bug% gfc -fno-realloc-lhs -fcheck=all pr48058.f90 [macbook] f90/bug% a.out 3 3 where a length 2 vector is assigned to a length 3 one(?).
[Bug c++/47952] [trans-mem] undefined reference to transaction clone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47952 --- Comment #12 from Patrick Marlier patrick.marlier at gmail dot com 2011-03-10 14:19:35 UTC --- On 03/10/2011 12:01 AM, rth at gcc dot gnu.org wrote: I suspect, but have not yet verified, that this is related to // Inhibit implicit instantiations for required instantiations, // which are defined via explicit instantiations elsewhere. // NB: This syntax is a GNU extension. #if _GLIBCXX_EXTERN_TEMPLATE 0 extern template class basic_stringchar; in that we're copying the is extern bit, which is not true for the transactional clone. I don't know if it is related but I have another bug which may be related with template. In a relaxed transaction, some functions (stl? template?) in a transaction doesn't call the clone version (nor call to ITM_changeTransactionMode). You can verify this in the function stepDestroyBuildings (_ZL20stepDestroyBuildingsi) in src/Tean.cpp, the function _ZNSt4listIP8BuildingSaIS1_EE5beginEv is called directly (not the clone, no irrevocable mode) even if in a transaction. I had a quick look and the clone function exists but seems not be replaced (the begin attribute doesn't say irrevocable and no changeMode). It seems to happen when one transaction is followed by another one (Not sure if it is the cause) I would like to have a look at it but I will be on vacation next week and I have to finish urgent things... (I have added Aldy as CC since he also has glob2 and it might interest him) Should I fill a new PR for this even if I don't have any real testcase? Thanks. Patrick.
[Bug debug/48043] [4.6 Regression] pr47201: var-tracking loc_order_check fails for type punning examples
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48043 --- Comment #6 from Andreas Krebbel krebbel at gcc dot gnu.org 2011-03-10 14:27:19 UTC --- (In reply to comment #5) Created attachment 23608 [details] gcc46-pr48043.patch Fix (tested just with cross on the pr47201.c testcase). Could you please bootstrap/regtestit, it might take a while for me to test it on s390x. Done. Bootstraps fine on s390 and s390x. No regression. The testcase is fixed with this. But your fix only applies if the mode mismatch comes from an address. Wouldn't it be possible to trigger this situation with a normal value not going through delegitimize_address?
[Bug fortran/48058] [4.6 Regression] reallocation of array during constructor assignement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48058 Kacper Kowalik xarthisius.kk at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Kacper Kowalik xarthisius.kk at gmail dot com 2011-03-10 14:34:21 UTC --- Somehow, I've missed this in ChangeLog. Sorry for the noise
[Bug debug/48043] [4.6 Regression] pr47201: var-tracking loc_order_check fails for type punning examples
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48043 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-10 14:37:39 UTC --- If there isn't a mode mismatch in the instruction stream, then no. The problem is that because of the delegitimizate address bug adjust_insn in var-tracking (temporarily) changed the insn into (set (reg:SF ...) (symbol_ref:SI ...)) (SET_SRC coming from delegitimizing a (mem:SF ...)) and var-tracking not expecting mode mismatches. If there is (set (reg:SF ...) (subreg:SF (reg:SI ...))) or something similar, var-tracking ought to handle it correctly, sorry for the false alarm in #c3, I wrote it without looking carefully into it. Thanks for testing the patch, I'll post it to gcc-patches momentarily.
[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 #6 from Uros Bizjak ubizjak at gmail dot com 2011-03-10 14:39:57 UTC --- (In reply to comment #5) No, these are the only definitions for the particular testcase. Hmm, in every case it is GNU ld bug - the GNU ld internal ironly section should not be leaking to user warnings. Please fill in GNU ld PR. Submitted as binutils PR 12564. Anyway, should the patch be committed to gcc testsuite, since it doesn't change the test and avoids the linker bug at the same time? [1] http://sourceware.org/bugzilla/show_bug.cgi?id=12564
[Bug target/48061] New: Internal compiler error in spill_failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48061
Summary: Internal compiler error in spill_failure
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mgret...@sourceware.org
CC: ramana.radhakrish...@arm.com
Target: arm-none-eabi
Created attachment 23615
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23615
Test case for bug
Compiling the attached test case (based on
gcc/testsuite/gcc.dg/torture/pr47975.c) produces an internal compiler error in
spill_failure.
arm-eabi-gcc -O2 -mfloat-abi=hard -mcpu=cortex-a9 -mfpu=neon test.i produces:
test.c: In function 'foo':
test.c:7:1: error: unable to find a register to spill in class 'GENERAL_REGS'
test.c:7:1: error: this is the insn:
(insn 18 5 6 2 (set (reg:OI 154)
(const_int 0 [0])) test.c:6 751 {*neon_movoi}
(expr_list:REG_EQUAL (const_int 0 [0])
(nil)))
test.c:7:1: internal compiler error: in spill_failure, at reload1.c:2105
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
arm-eabi-gcc -v produces the following output:
Using built-in specs.
COLLECT_GCC=.../bin/arm-eabi-gcc
COLLECT_LTO_WRAPPER=.../bin/../libexec/gcc/arm-eabi/4.6.0/lto-wrapper
Target: arm-eabi
Configured with: .../configure --target=arm-eabi --enable-checking=release
--disable-gdbtk --disable-werror --disable-tui --disable-rda --disable-sid
--disable-utils --disable-lto --with-cpu=cortex-a9 --with-float=softfp
--with-fpu=neon --disable-lto --disable-werror --disable-shared --disable-nls
--disable-threads --disable-tls --enable-checking=yes
--enable-languages=c,c++,fortran --with-newlib
Thread model: single
gcc version 4.6.0 20110309 (experimental) (GCC)
[Bug target/48061] Internal compiler error in spill_failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48061 Matthew Gretton-Dann mgretton at sourceware dot org changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from Matthew Gretton-Dann mgretton at sourceware dot org 2011-03-10 15:06:58 UTC --- Also occurs with -mfloat-abi=softfp
[Bug c++/47198] [4.5/4.6 Regression] [C++0x] ICE: tree check: expected var_decl or function_decl, have template_decl in check_bases_and_members, at cp/class.c:4654 on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47198 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-03-10 15:21:04 UTC --- Author: jason Date: Thu Mar 10 15:21:00 2011 New Revision: 170847 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170847 Log: PR c++/47198 * parser.c (cp_parser_single_declaration): Just return if cp_parser_parse_and_diagnose_invalid_type_name complained. Added: trunk/gcc/testsuite/g++.dg/cpp0x/syntax-err1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/error36.C trunk/gcc/testsuite/g++.old-deja/g++.pt/ctor2.C trunk/gcc/testsuite/g++.old-deja/g++.pt/typename3.C trunk/gcc/testsuite/g++.old-deja/g++.pt/typename4.C trunk/gcc/testsuite/g++.old-deja/g++.pt/typename6.C
[Bug fortran/48058] [4.6 Regression] reallocation of array during constructor assignement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48058 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org 2011-03-10 15:24:29 UTC --- (In reply to comment #2) Somehow, I've missed this in ChangeLog. Sorry for the noise ChangeLog is a horrible place to look at the new features in gfortran. It would be better to look on the gfortran wiki. http://gcc.gnu.org/wiki/GFortran#news
[Bug c/48060] internal compiler error: in dfs_enumerate_from, at cfganal.c:1209
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48060 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-10 15:24:33 UTC --- Already fixed. *** This bug has been marked as a duplicate of bug 48000 ***
[Bug bootstrap/48000] [4.6 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48000 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||y...@momonga-linux.org --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-10 15:24:33 UTC --- *** Bug 48060 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/44897] -flto + ipa-sra misoptimize sqlite (non-plugin only)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44897 --- Comment #11 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-03-10 16:07:34 UTC --- In the Firefox case sqlite3.o gets compiled correctly, it is libmozsqlite3.so that segfaults when compiled with -flto and -fprofile-use : gcc -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -W -pedantic -Wno-long-long -march=native -fpermissive -fno-strict-aliasing -pthread -pipe -DNDEBUG -DTRIMMED -flto=4 -fwhole-program -fprofile-use -fprofile-correction -Wcoverage-mismatch -freorder-blocks-and-partition -O3 -fPIC -shared -Wl,-z,defs -Wl,-h,libmozsqlite3.so -o libmozsqlite3.so sqlite3.o -lpthread -Wl,-O1,--hash-style=gnu,--as-needed,--no-keep-memory -fprofile-use -Wl,-rpath-link,/var/tmp/mozilla-central/moz-build-dir/dist/bin -Wl,-rpath-link,/usr/lib -ldl This version runs fine (no -flto): gcc -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -W -pedantic -Wno-long-long -march=native -fpermissive -fno-strict-aliasing -pthread -pipe -DNDEBUG -DTRIMMED -Wcoverage-mismatch -freorder-blocks-and-partition -fwhole-program -fprofile-use -O3 -fPIC -shared -Wl,-z,defs -Wl,-h,libmozsqlite3.so -o libmozsqlite3.so sqlite3.o -lpthread -Wl,-O1,--hash-style=gnu,--as-needed,--no-keep-memory -Wl,-rpath-link,/var/tmp/mozilla-central/moz-build-dir/dist/bin -Wl,-rpath-link,/usr/lib -ldl And this one gives an internal compiler error (only -flto , no -fprofile-use): gcc -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -W -pedantic -Wno-long-long -march=native -fpermissive -fno-strict-aliasing -pthread -pipe -DNDEBUG -DTRIMMED -Wcoverage-mismatch -freorder-blocks-and-partition -flto -O3 -fPIC -shared -Wl,-z,defs -Wl,-h,libmozsqlite3.so -o libmozsqlite3.so sqlite3.o -lpthread -Wl,-O1,--hash-style=gnu,--as-needed,--no-keep-memory -Wl,-rpath-link,/var/tmp/mozilla-central/moz-build-dir/dist/bin -Wl,-rpath-link,/usr/lib -ldl lto1: internal compiler error: Floating point exception Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: /usr/x86_64-pc-linux-gnu/gcc-bin/4.6.0/gcc returned 1 exit status /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/bin/ld: fatal error: lto-wrapper failed collect2: ld returned 1 exit status (All these commands should be run from: ./mozilla-central/moz-build-dir/db/sqlite3/src One can copy the resulting libmozsqlite3.so directly into /usr/lib/firefox-4.0b13pre and try to start Firefox, to check if it's OK or not)
[Bug tree-optimization/44897] -flto + ipa-sra misoptimize sqlite (non-plugin only)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44897 --- Comment #12 from Jan Hubicka hubicka at ucw dot cz 2011-03-10 16:26:01 UTC --- gcc -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -W -pedantic -Wno-long-long -march=native -fpermissive -fno-strict-aliasing -pthread -pipe -DNDEBUG -DTRIMMED -Wcoverage-mismatch -freorder-blocks-and-partition -flto -O3 -fPIC -shared -Wl,-z,defs -Wl,-h,libmozsqlite3.so -o libmozsqlite3.so sqlite3.o -lpthread -Wl,-O1,--hash-style=gnu,--as-needed,--no-keep-memory -Wl,-rpath-link,/var/tmp/mozilla-central/moz-build-dir/dist/bin -Wl,-rpath-link,/usr/lib -ldl lto1: internal compiler error: Floating point exception This should be easy to fix. Having backtrace would save me from some burden trying to reproduce it ;) Honza
[Bug c/48062] New: `shadowed declaration is here' should be a note
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48062
Summary: `shadowed declaration is here' should be a note
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d.g.gorbac...@gmail.com
cat main.c
int i;
int main(void)
{
int i = 0;
return i;
}
^D
$ gcc -Wshadow main.c
main.c: In function 'main':
main.c:5:7: warning: declaration of 'i' shadows a global declaration [-Wshadow]
main.c:1:5: warning: shadowed declaration is here [-Wshadow]
[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 ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #7 from Uros Bizjak ubizjak at gmail dot com 2011-03-10 16:51:35 UTC --- Linker bug, see also [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00521.html
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #38 from dave at hiauly1 dot hia.nrc.ca 2011-03-10 16:58:38 UTC --- While the latter is fixed, I think the _REENTRANT issue isn't. Or is it? If it it not fixed, I think we should have (a different) PR open to track that issue. Dave, you wrote you were testing a patch for _REENTRANT ... Correct, I have a patch which I have been testing. While it seems to work, there is one issue that I don't particularly like. `-threads' is a multilib option handled completely by the gcc driver. It is not passed to the standard option processing, so I wasn't able to find a way to check for `-threads' in TARGET_OS_CPP_BUILTINS. Currently, I define _REENTRANT whenever we define _HPUX_SOURCE in TARGET_OS_CPP_BUILTINS. It is also defined by CPP_SPEC when -threads is specified. As a result, there are some situations where _REENTRANT is effectively defined twice. This could be avoided if _REENTRANT was only defined in CPP_SPEC but it is difficult to duplicate the option handling in TARGET_OS_CPP_BUILTINS. Since I haven't seen any actual problems with the current patch, I think I will commit it tonight. Dave
[Bug target/48061] Internal compiler error in spill_failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48061 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org 2011-03-10 16:59:33 UTC --- Essentially the same problem as 46329. *** This bug has been marked as a duplicate of bug 46329 ***
[Bug target/46329] ICE on ARM for __attribute__ ((vector_size (8 * sizeof(int)))) operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46329
--- Comment #3 from Richard Earnshaw rearnsha at gcc dot gnu.org 2011-03-10
17:00:10 UTC ---
Another test (from the dup).
int __attribute__ ((vector_size (32))) x;
void
foo (void)
{
x = x;
}
[Bug target/46329] ICE on ARM for __attribute__ ((vector_size (8 * sizeof(int)))) operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46329 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added CC||mgretton at sourceware dot ||org --- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org 2011-03-10 16:59:33 UTC --- *** Bug 48061 has been marked as a duplicate of this bug. ***
[Bug c++/46824] chromium-compile failed because error: no match for ‘operator*’ in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46824 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW CC||dodji at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-10 17:20:05 UTC --- This started being rejected with http://gcc.gnu.org/viewcvs?root=gccview=revrev=167250 I'll let Dodji/Jason comment on whether the testcase is valid or not.
[Bug tree-optimization/47278] [4.3/4.4 Regression] hidden weak function not handled properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47278 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #5 from John David Anglin danglin at gcc dot gnu.org 2011-03-10 17:26:49 UTC --- I see on 4.5.3 on hppa2.0w-hp-hpux11.11: FAIL: gcc.dg/torture/pr47278-1.c -O0 (test for excess errors) Excess errors: /mnt/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr47278-2.c:6:1: warning: visibili ty attribute not supported in this configuration; ignored
[Bug c++/46824] chromium-compile failed because error: no match for ‘operator*’ in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46824
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-10
18:04:03 UTC ---
Reduced:
template class T
struct scoped_refptr {
operator T*() const;
};
class EventParameters { };
class HttpResponseHeaders;
struct NetLogHttpResponseParameter : public EventParameters {
const HttpResponseHeaders GetHeaders() const {
return *headers_;
}
scoped_refptrHttpResponseHeaders headers_;
};
EDG rejects this with the same error. Clang accepts it.
[Bug c++/46824] chromium-compile failed because error: no match for ‘operator*’ in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46824
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-10
18:08:52 UTC ---
really reduced:
class Incomplete;
struct Ptr
{
operator Incomplete*();
};
int main()
{
Ptr p;
*p;
}
[Bug debug/48043] [4.6 Regression] pr47201: var-tracking loc_order_check fails for type punning examples
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48043 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-10 18:10:19 UTC --- Author: jakub Date: Thu Mar 10 18:10:14 2011 New Revision: 170851 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170851 Log: PR debug/48043 * config/s390/s390.c (s390_delegitimize_address): Make sure the result mode matches original rtl mode. Modified: trunk/gcc/ChangeLog trunk/gcc/config/s390/s390.c
[Bug debug/48043] [4.6 Regression] pr47201: var-tracking loc_order_check fails for type punning examples
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48043 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-10 18:16:33 UTC --- Fixed.
[Bug tree-optimization/48063] New: [4.6 Regression] ICE: verify_stmts failed: conversion of register to a different size with -fno-early-inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48063 Summary: [4.6 Regression] ICE: verify_stmts failed: conversion of register to a different size with -fno-early-inlining Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz CC: ja...@gcc.gnu.org Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 23616 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23616 preprocessed gcc.c-torture/compile/pr47967.c Testcase is the same as for PR47967. Compiler output: $ gcc gcc.c-torture/compile/pr47967.c -O -fno-early-inlining gcc.c-torture/compile/pr47967.c: In function 'foo': gcc.c-torture/compile/pr47967.c:7:1: error: conversion of register to a different size VIEW_CONVERT_EXPRdouble(D.2694_3); i_2 = VIEW_CONVERT_EXPRdouble(D.2694_3); gcc.c-torture/compile/pr47967.c:7:1: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. (gdb) bt #0 error (gmsgid=0x116d6a0 conversion of register to a different size) at /mnt/svn/gcc-trunk/gcc/diagnostic.c:747 #1 0x008ea08c in verify_types_in_gimple_reference (expr=0x75ba1fc0, require_lvalue=0 '\000') at /mnt/svn/gcc-trunk/gcc/tree-cfg.c:2953 #2 0x008eb01d in verify_gimple_assign_single (stmt=value optimized out) at /mnt/svn/gcc-trunk/gcc/tree-cfg.c:3755 #3 verify_gimple_assign (stmt=value optimized out) at /mnt/svn/gcc-trunk/gcc/tree-cfg.c:3824 #4 verify_types_in_gimple_stmt (stmt=value optimized out) at /mnt/svn/gcc-trunk/gcc/tree-cfg.c:3984 #5 0x008f35bf in verify_stmts () at /mnt/svn/gcc-trunk/gcc/tree-cfg.c:4386 #6 0x00a094cd in verify_ssa (check_modified_stmt=1 '\001') at /mnt/svn/gcc-trunk/gcc/tree-ssa.c:878 #7 0x007f3e49 in execute_function_todo (data=value optimized out) at /mnt/svn/gcc-trunk/gcc/passes.c:1240 #8 0x007f453d in execute_todo (flags=2132516) at /mnt/svn/gcc-trunk/gcc/passes.c:1271 #9 0x007f68cb in execute_one_ipa_transform_pass () at /mnt/svn/gcc-trunk/gcc/passes.c:1463 #10 execute_all_ipa_transforms () at /mnt/svn/gcc-trunk/gcc/passes.c:1487 #11 0x00939d2d in tree_rest_of_compilation (fndecl=0x75ba2100) at /mnt/svn/gcc-trunk/gcc/tree-optimize.c:415 #12 0x00b01e72 in cgraph_expand_function (node=0x75ba5000) at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1576 #13 0x00b045ba in cgraph_expand_all_functions () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1635 #14 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1899 #15 0x00b04b3a in cgraph_finalize_compilation_unit () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1096 #16 0x005097bc in c_write_global_declarations () at /mnt/svn/gcc-trunk/gcc/c-decl.c:9872 #17 0x008e2cd8 in compile_file (argc=14, argv=0x7fffdb48) at /mnt/svn/gcc-trunk/gcc/toplev.c:591 #18 do_compile (argc=14, argv=0x7fffdb48) at /mnt/svn/gcc-trunk/gcc/toplev.c:1900 #19 toplev_main (argc=14, argv=0x7fffdb48) at /mnt/svn/gcc-trunk/gcc/toplev.c:1963 #20 0x76445bbd in __libc_start_main () from /lib/libc.so.6 #21 0x004f0369 in _start () Tested revisions: r170814 - crash 4.5 r170013 - OK
[Bug tree-optimization/44897] -flto + ipa-sra misoptimize sqlite (non-plugin only)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44897 --- Comment #13 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-03-10 18:39:21 UTC --- Here's what I got: (gdb) set follow-fork-mode child (gdb) run -plugin /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/liblto_plugin.so -plugin-opt=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/lto-wrapper -plugin-opt=-fresolution=/tmp/ccZJwWXj.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -flto --eh-frame-hdr -m elf_x86_64 -shared -o libmozsqlite3.so /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/crtbeginS.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../.. -z defs -h libmozsqlite3.so sqlite3.o -lpthread --hash-style=gnu -rpath-link /var/tmp/mozilla-central/moz-build-dir/dist/bin -rpath-link /usr/lib -ldl -lgcc --as-needed -lgcc_s --no-as-needed -lpthread -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64/crtn.o Starting program: /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/collect2 -plugin /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/liblto_plugin.so -plugin-opt=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/lto-wrapper -plugin-opt=-fresolution=/tmp/ccZJwWXj.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -flto --eh-frame-hdr -m elf_x86_64 -shared -o libmozsqlite3.so /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/crtbeginS.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../.. -z defs -h libmozsqlite3.so sqlite3.o -lpthread --hash-style=gnu -rpath-link /var/tmp/mozilla-central/moz-build-dir/dist/bin -rpath-link /usr/lib -ldl -lgcc --as-needed -lgcc_s --no-as-needed -lpthread -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../lib64/crtn.o [New process 16093] process 16093 is executing new program: /usr/x86_64-pc-linux-gnu/binutils-bin/2.21.51.0.7/ld [New process 16102] process 16102 is executing new program: /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/lto-wrapper [New process 16103] process 16103 is executing new program: /usr/x86_64-pc-linux-gnu/gcc-bin/4.6.0/gcc [New process 16104] process 16104 is executing new program: /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/lto1 Program received signal SIGFPE, Arithmetic exception. [Switching to process 16104] 0x00862ca7 in ?? () (gdb) bt #0 0x00862ca7 in ?? () #1 0x0066f176 in execute_one_pass(opt_pass*) () #2 0x0066fa52 in execute_ipa_pass_list(opt_pass*) () #3 0x004f284e in lto_main() () #4 0x006fc247 in toplev_main(int, char**) () #5 0x76d28f8d in __libc_start_main () from /lib/libc.so.6 #6 0x004cd9f9 in _start () (gdb)
[Bug c/48062] `shadowed declaration is here' should be a note
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48062 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.10 18:44:34 CC||manu at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-03-10 18:44:34 UTC --- This is a one liner that would qualify as obvious and it won't require copyright assignment. Feel free to submit a patch! (but it probably requires to adjust testcases, so run the testsuite and look for new failures)
[Bug rtl-optimization/33928] [4.3/4.4/4.5/4.6 Regression] 30% performance slowdown in floating-point code caused by r118475
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928 --- Comment #118 from lucier at math dot purdue.edu 2011-03-10 18:50:12 UTC --- On Fri, 2011-03-04 at 11:59 +, rguenth at gcc dot gnu.org wrote: Hm, there doesn't seem to be a runtime testcase attached to this bug, so I can't produce numbers for the upcoming 4.6 release. Brad, can you do so if you have time? At http://www.math.purdue.edu/~lucier/bugzilla/14/ is a Readme file and a tarball; I think it should be easy to script a runtime test for this PR from the instructions in the Readme file. Later we'll devise a make bench for general Gambit benchmarking. Brad
[Bug tree-optimization/48063] [4.6 Regression] ICE: verify_stmts failed: conversion of register to a different size with -fno-early-inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48063
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-10
18:50:19 UTC ---
Again caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=161655
setup_one_parameter has:
if (value
value != error_mark_node
!useless_type_conversion_p (TREE_TYPE (p), TREE_TYPE (value)))
{
if (fold_convertible_p (TREE_TYPE (p), value))
rhs = fold_build1 (NOP_EXPR, TREE_TYPE (p), value);
else
/* ??? For valid (GIMPLE) programs we should not end up here.
Still if something has gone wrong and we end up with truly
mismatched types here, fall back to using a VIEW_CONVERT_EXPR
to not leak invalid GIMPLE to the following passes. */
rhs = fold_build1 (VIEW_CONVERT_EXPR, TREE_TYPE (p), value);
}
which obviously can't work when the VCE is invalid. We really shouldn't be
trying to inline in that case.
[Bug tree-optimization/48063] [4.6 Regression] ICE: verify_stmts failed: conversion of register to a different size with -fno-early-inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48063 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-10 18:55:08 UTC --- I think the bug is that with -O -fno-early-inlining tree_can_inline_p is never called and thus nothing finds out there is argument mismatch. Honza?
[Bug tree-optimization/48063] [4.6 Regression] ICE: verify_stmts failed: conversion of register to a different size with -fno-early-inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48063 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-10 19:09:49 UTC --- Created attachment 23617 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23617 gcc46-pr48063.patch This seems to fix it, but no idea whether it is the right fix. It seems all other places that check call_stmt_cannot_inline_p also call tree_can_inline_p though.
[Bug tree-optimization/44897] -flto + ipa-sra misoptimize sqlite (non-plugin only)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44897 --- Comment #14 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-03-10 19:13:55 UTC --- And the same with debugging symbols: Program received signal SIGFPE, Arithmetic exception. [Switching to process 5046] 0x0086d41c in cgraph_decide_recursive_inlining (new_edges=0x7fffd750, node=0x765dbb00) at ../../gcc/gcc/ipa-inline.c:906 906 if (curr-count * 100 / node-count probability) (gdb) bt #0 0x0086d41c in cgraph_decide_recursive_inlining (new_edges=0x7fffd750, node=0x765dbb00) at ../../gcc/gcc/ipa-inline.c:906 #1 cgraph_decide_inlining_of_small_functions () at ../../gcc/gcc/ipa-inline.c:1193 #2 cgraph_decide_inlining () at ../../gcc/gcc/ipa-inline.c:1479 #3 0x006571e9 in execute_one_pass (pass=0x102ee00) at ../../gcc/gcc/passes.c:1556 #4 0x0065787a in execute_ipa_pass_list (pass=0x102ee00) at ../../gcc/gcc/passes.c:1923 #5 0x004c152f in do_whole_program_analysis () at ../../gcc/gcc/lto/lto.c:2350 #6 lto_main () at ../../gcc/gcc/lto/lto.c:2462 #7 0x006e7510 in compile_file () at ../../gcc/gcc/toplev.c:579 #8 do_compile () at ../../gcc/gcc/toplev.c:1900 #9 toplev_main (argc=40, argv=0x11679c0) at ../../gcc/gcc/toplev.c:1963 #10 0x76d28f8d in __libc_start_main () from /lib/libc.so.6 #11 0x004a9979 in _start () at ../sysdeps/x86_64/elf/start.S:113 (gdb)
[Bug rtl-optimization/48064] New: Optimizer produces suboptimal code for e.g. x = x ^ (x 1)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48064
Summary: Optimizer produces suboptimal code for e.g. x = x ^ (x
1)
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jasper.neum...@web.de
Target: windows 32
When I compile the following OPT.CPP with gcc 4.5.2 (mingw) under Windows-32...
===
int test(int x)
{
x = x ^ (x 1);
int x1=x;
x = x 2;
x = x ^ x1;
return x;
}
===
...a call to
gpp -O3 -S OPT.CPP
produces this OPT.s:
===
.file OPT.CPP
.text
.p2align 2,,3
.globl __Z4testi
.def__Z4testi; .scl2; .type 32; .endef
__Z4testi:
LFB0:
pushl %ebp
LCFI0:
movl%esp, %ebp
LCFI1:
movl8(%ebp), %eax
movl%eax, %edx
sarl%edx
xorl%eax, %edx
movl%edx, %eax
sarl$2, %eax
xorl%edx, %eax
leave
LCFI2:
ret
LFE0:
===
The problem I see is that in
movl%eax, %edx
sarl%edx
xorl%eax, %edx
movl%edx, %eax
sarl$2, %eax
xorl%edx, %eax
gcc produces code which presumably costs 6 cycles
(edx and then eax is modified 3 times in a row)
whereas the equivalent statements
movl%eax, %edx
sarl%eax
xorl%eax, %edx
movl%edx, %eax
sarl$2, %edx
xorl%edx, %eax
cost only 4 cycles since the mov and the shift can go in parallel.
I would have expected this at least for explicit form in
int x1=x;
x = x 2;
x = x ^ x1;
I found no way to get gcc to output my version.
A speed test reveals that the proposed form only costs about
2/3 of the time on Intel Atom N450 and 3/4 of the time on Intel i7.
Have I missed something?
By the way: If I produce an output in Intel syntax
the statement sar eax should be sar eax,1.
Otherwise some assemblers will complain.
[Bug rtl-optimization/33928] [4.3/4.4/4.5/4.6 Regression] 30% performance slowdown in floating-point code caused by r118475
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928 --- Comment #119 from lucier at math dot purdue.edu 2011-03-10 19:55:54 UTC --- It's nearly impossible to examine the assembly code responsible for the FFT in the package I set up in the previous comment. If you want a runtime benchmark for this PR where you can easily examine the code I'll have to do more work.
[Bug lto/48065] New: LTO: assertion failed in optimize_inline_calls, at tree-inline.c:4246
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48065 Summary: LTO: assertion failed in optimize_inline_calls, at tree-inline.c:4246 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: d.g.gorbac...@gmail.com Created attachment 23618 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23618 testcase In file included from :0:0: main.c: In function 'main': main.c:3:5: internal compiler error: in optimize_inline_calls, at tree-inline.c:4246
[Bug lto/48065] LTO: assertion failed in optimize_inline_calls, at tree-inline.c:4246
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48065 --- Comment #1 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2011-03-10 20:00:27 UTC --- Created attachment 23619 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23619 backtrace
[Bug target/42976] Illegal translation for IF operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42976 Georg-Johann Lay avr at gjlay dot de changed: What|Removed |Added CC||avr at gjlay dot de, ||kharpost at rambler dot ru --- Comment #1 from Georg-Johann Lay avr at gjlay dot de 2011-03-10 20:14:46 UTC --- There is nothing wrong with the code. bugif.c is compiled and disassembled as expected. For the snippets with keybuf.keys, keys.keys there is no source, so presumably these variables are defined to be 32-bit scalar. Again, there is nothing wrong with that code. This bug can be marked as invalid. Johann
[Bug target/42976] Illegal translation for IF operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42976 Eric Weddington eric.weddington at atmel dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Eric Weddington eric.weddington at atmel dot com 2011-03-10 20:21:23 UTC --- Resolving as invalid.
[Bug fortran/48059] [OOP] ICE in in gfc_conv_component_ref: character function of extended type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48059 Harald Anlauf anlauf at gmx dot de changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #3 from Harald Anlauf anlauf at gmx dot de 2011-03-10 20:23:56 UTC --- (In reply to comment #0) The code: For what it's worth: ifort 12.0 and PGI 11.1 accept the code, and xlf 13.1.0.4 warns: test.f90, 1513-083 (E) Internal or module function form was not set within the function. ** a_module === End of Compilation 1 === 1501-510 Compilation successful for file test.f90.
[Bug c++/46824] chromium-compile failed because error: no match for ‘operator*’ in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46824 --- Comment #6 from Dodji Seketeli dodji at gcc dot gnu.org 2011-03-10 21:20:52 UTC --- Thank you for reducing this. Here is what I understand from the reduced test case. For the expression *p the compiler uses overload resolution to determine which operator * to use. As there is no user provided operator*() that can take an instance of Ptr in argument, the only choice left is to consider the built-in operator*() as a viable candidate for overload resolution. But then the note in [over.built]/1 says: because built-in operators take only operands with non-class type, and operator overload resolution occurs only when an operand expression originally has class or enumeration type, operator overload resolution can resolve to a built-in operator only when an operand has a class type that has a user-defined conversion to a non-class type appropriate for the operator, or when an operand has an enumeration type that can be converted to a type appropriate for the operator. As there is no user-defined conversion operator that would convert Ptr into a pointer to native type, the built-in operator*() is not a viable candidate. Thus I believe the test case is ill-formed and the user-defined conversion operator that converts Ptr to Incomplete* seems to be of little use in this case. So for the built-in operator to be selected, we'd need e.g, a user-defined conversion operator Ptr::operator int* (). Otherwise we'd need a user-defined operator 'something Ptr::operator*()'.
[Bug c++/46824] chromium-compile failed because error: no match for ‘operator*’ in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46824 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2011-03-10 21:30:34 UTC --- It doesn't need to be a pointer to non-class type; a pointer to class is itself a non-class type.
[Bug fortran/48059] [4.6 Regression][OOP] ICE in in gfc_conv_component_ref: character function of extended type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48059 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code CC||burnus at gcc dot gnu.org, ||matz at suse dot de, pault ||at gcc dot gnu.org Known to work||4.5.2 Target Milestone|--- |4.6.0 Summary|[OOP] ICE in in |[4.6 Regression][OOP] ICE |gfc_conv_component_ref: |in in |character function of |gfc_conv_component_ref: |extended type |character function of ||extended type Known to fail||4.6.0 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2011-03-10 21:45:02 UTC --- Michael, I CCed you because the ICE is in gfc_conv_component_ref, which you have modified for PR 45586 (Rev. 170284). That's also in the range of commits (169790:170493), which Dominique has given.
[Bug rtl-optimization/33928] [4.3/4.4/4.5/4.6 Regression] 30% performance slowdown in floating-point code caused by r118475
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928 --- Comment #120 from lucier at math dot purdue.edu 2011-03-10 22:00:22 UTC --- At http://www.math.purdue.edu/~lucier/bugzilla/15/ I've put a tarfile and instructions that allow one to build Gambit-C in a way that splits out the FFT code into its own C function, so the assembly code can be more easily examined. Brad
[Bug c++/46824] chromium-compile failed because error: no match for ‘operator*’ in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46824 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-10 22:26:42 UTC --- (In reply to comment #7) It doesn't need to be a pointer to non-class type; a pointer to class is itself a non-class type. Indeed. And the example compiles fine if the type is complete. I can't find any wording that says why converting to Incomplete* should not be allowed when converting to Complete* is ok. I wondered if DR416 is relevant, but I don't think it applies, as T1 is Ptr here, which is complete.
[Bug c++/48029] [4.5/4.6 Regression] ICE in finish_member_declaration() with --param ggc-min-expand=0 --param ggc-min-heapsize=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48029 --- Comment #10 from Jason Merrill jason at gcc dot gnu.org 2011-03-10 22:37:27 UTC --- Author: jason Date: Thu Mar 10 22:37:22 2011 New Revision: 170853 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170853 Log: PR c++/48029 * stor-layout.c (layout_type): Don't set structural equality on arrays of incomplete type. * tree.c (type_hash_eq): Handle comparing them properly. * cp/pt.c (iterative_hash_template_arg): Remove special case for ARRAY_TYPE. Added: trunk/gcc/testsuite/g++.dg/template/array22.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/stor-layout.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c
[Bug fortran/48059] [4.6 Regression][OOP] ICE in in gfc_conv_component_ref: character function of extended type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48059 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug c++/46824] chromium-compile failed because error: no match for ‘operator*’ in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46824 --- Comment #9 from Dodji Seketeli dodji at gcc dot gnu.org 2011-03-10 22:53:42 UTC --- Yes, I was confused. This code is valid.
[Bug c++/46824] chromium-compile failed because error: no match for ‘operator*’ in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46824 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC|dodji at gcc dot gnu.org| AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org |
[Bug fortran/48066] New: [4.3/4.4/4.5/4.6 Regression] Segfault with SUM of zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48066 Summary: [4.3/4.4/4.5/4.6 Regression] Segfault with SUM of zero-sized array Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Reported on IRC. The following program segfaults with gfortran 4.3 to 4.6 but works with gfortran 4.1: program p real(8) :: empty(0, 3), square(0) square = sum(empty * empty, 2) print *, square=, square end
[Bug c++/47952] [trans-mem] undefined reference to transaction clone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47952 --- Comment #13 from Richard Henderson rth at gcc dot gnu.org 2011-03-10 23:04:11 UTC --- Author: rth Date: Thu Mar 10 23:04:05 2011 New Revision: 170854 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170854 Log: PR 47952 * trans-mem.c (ipa_tm_create_version): Remap extern inline functions to static inline clones. Modified: branches/transactional-memory/gcc/ChangeLog.tm branches/transactional-memory/gcc/trans-mem.c
[Bug fortran/48066] [4.3/4.4/4.5/4.6 Regression] Segfault with SUM of zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48066 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-03-10 23:09:15 UTC --- Valgrind: ==9860== Invalid write of size 8 ==9860==at 0x4EAB980: _gfortran_sum_r8 (sum_r8.c:147) ==9860==by 0x400955: MAIN__ (test.f90:3) From libgfortran/generated/sum_r8.f90: dest = retarray-data; [...] if (len = 0) *dest = 0; which fails if dest == NULL
[Bug ada/37430] [4.4/4.5/4.6 Regression] C974013 gives exception
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37430 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #7 from Steven Bosscher steven at gcc dot gnu.org 2011-03-10 23:12:25 UTC --- Does not fail with recent compilers, it would seem: http://gcc.gnu.org/ml/gcc-testresults/2011-02/msg02364.html
[Bug fortran/48066] [4.3/4.4/4.5/4.6 Regression] Segfault with SUM of zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48066 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.10 23:14:27 CC||mikael at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-03-10 23:14:27 UTC --- The Bus error seems fixed by the patch in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829#c32.
